Finansal kayıtları tutmak için veritabanları tasarlarken hangi özel hususlara ihtiyaç vardır?

Umarım bu soru çok geniş değildir. Gelecekte bazı uygulamalara bazı muhasebe ve finansal izleme sistemleri eklemem gerekebilir (çoğunlukla web tabanlı uygulamalar, ancak sorularım masaüstü uygulamalarıyla da ilgilidir).

Şimdi, finansal işlemlerin basit bir kaydını oluşturmak teorik olarak kolaydır. Birkaç sütun içeren bir veritabanı tablosu işi yapabilir. İşlem tarihlerini, hesap kimliklerini ve dolar tutarlarını depolamak için MS Access, Excel veya hatta düz bir ASCII metin dosyası bile kullanılabilir. Ancak, işlem bütünlüğüne sahip sık sık yedeklenen bir SQL tablosunun bile ciddi finansal izleme için yeterince sağlam olmayabileceğini düşünüyorum.

"Çift girişli muhasebe" gibi terimler duyuyorum ve çoğu finansal izleme uygulamasının (örneğin, Mint.com veya GnuCash) her şeyin iki kat daha fazla olduğundan emin olmak için çok daha karmaşık bir veri yapısına veya işlemine sahip olduğunu hissediyorum. tam olarak olması gerektiği gibi mükemmel bir şekilde toplanır ve hiçbir veri kaybolmaz veya bozulmaz.

Sorum şu: Finansal işlemleri izlemek için bir uygulama tasarlarken hangi özel tasarım hususları dikkate alınmalıdır? Görünüşe göre pek çok potansiyel sorun olabilir ... yuvarlama hassasiyeti, parite kontrolleri, bir tür denetim süreci, özel yedeklemeler, güvenlik / şifreleme, veri girişi ortalarında bir çökme durumunda verileri korumanın ek yolları. ... özellikle ne sormam gerektiğini bilmiyorum, ama programlama endüstrisinin hakkında hiçbir şey bilmediğim bir dizi en iyi uygulama olduğunu hissediyorum. Onlar neler?

Düzenle:

Beklediğimden daha büyük bir solucan kutusu açtım. Açıklığa kavuşturmak için, özellikle iki tür uygulamayı düşünüyorum:

1. "Kayıt defterini kontrol et" - GnuCash veya Quicken gibi bireylerin kendi kullanımları için yaptıkları işlemleri kaydeden uygulamalar yazın.
2. Bir şirketle ilgilenen satıcılar ve müşteriler için faturalandırmayı / krediyi / veya "puanları" izleyen uygulamalar.

Muhtemelen ona bağlı bir ton finansla ilgili hükümet düzenlemesi olan doğrudan bankacılık veya (AFAIK) hiçbir şey yapmayacağım.

Bunun için birçok cevap alacaksınız Eminim, birçok idealist cevap da, sadece finansal deneyimimden ve gerçekte neler olup bittiğinden cevap verebilirim.

Sorunların çoğunu zaten ele aldınız.

Yuvarlama hassasiyeti, deneyimimde aslında çok fazla sorun olma eğilimindedir. Bir gecede büyümeyen büyük finansal kuruluşların çoğunda (yani riskten korunma fonları hariç her şey), çeşitli yakıtlar nedeniyle bölünmüş çok çeşitli eski uygulamalar vardır. Yuvarlama hassasiyetini tutarlı bir şekilde yapma eğilimindedirler; genellikle belirli bir hata karı ve kaybı yuvarlama için kabul edilir. Nitekim, kesin / beklenen toplamları eşleştirmek söz konusu olduğunda, nihai 'evet' yeterince yakın 'seçicilerin bulunduğu insanların çalıştığı yerlerde birçok adam saati geçiriyor. Unutmayın, bu gerçekliğe dayalı bir cevaptır, ne olması gerektiği değil.

Şifreleme - açıkçası ona güvenmeyin. Tanımlama verilerini, tanımlanmış verilerden (yani her yerde hesap kodu, kişisel veriler ayrı) fiziksel ve mantıksal olarak ayrı bir sistemde saklayın.

Genellikle yedeklemeler gerekliyken, çevrimdışı yedeklemeler nadiren çağrılır - bu noktada işler çok yanlış gitti. Sıcak üretim kopyaları genellikle gereklidir - ancak bu sizin özel ihtiyaçlarınıza bağlıdır. Genel pratikte, tüm sistemlerin sıcak bir yerinde üretim kopyası ve kendi üretimi ve sıcak kopyaları ile bir felaket kurtarma tesisimiz var. Sıcak kopyalar, çoğaltma vb. İşlemlerde birkaç dakika geride kalma eğilimindedir.

Denetim, üzerinde çalıştığım her finansal sistemin anahtarıdır. 2 temel gereksiniminiz var A) Verilerde yapılan her değişikliği kim tarafından, ne zaman ve neden izleyebilir misiniz? B) Verilerinizin tarihsel durumunu kanıtlayabilir misiniz? Kurcalanmadığını mı?

A) operasyon ekipleri için gereklidir - sisteminiz hiç beklemediğiniz 100 yolla kullanılacaktır ve bu bilgiler genişleme, geçici raporlama, yasal nedenler ve hata ayıklama için hayati önem taşımaktadır.

B) AMEX ve Vee Vinhnee davasına bakın - AMEX'in kayıtlarının yapılmadığını kanıtlayamadıkları için onlara 40k borcu toplayamadı. Bunun için genellikle kullanılan çözüm güvenilir zaman damgasıdır. Büyük finanslar işlemleri garanti eden ve dolayısıyla doğal olarak güvenilir zaman damgası sağlayan garantör bankalara sahiptir. Bunun için diğer yaşam / senaryolar için ticari sağlayıcılar vardır.

Düşünceler çoğunlukla yasaldır . Sadece bir güvenlik / güvenilirlik perspektifinden bakarsanız, bir excel sayfası bazı çekmecelerdeki bir kağıttan doğal olarak daha az güvenli olmayabilir. Access'in işlemsel bütünlüğü, bir çağrı tarafından kesintiye uğrayan bir katipten daha iyi olabilir.

Ancak, müşterilerinizin kullanmasına izin verilebilmesi için, yerel yasalarınıza uymanız gerekir. Karşılaştığım bazı şeyler (Almanya'da)

• Depolama için belge biçimleri , çünkü işletmelerin evraklarını 10 yıl boyunca saklaması gereken yasalar vardır. 10 Yıl içinde, programınız artık kullanılamayabilir. Bu nedenle, belgeleri DIN / ISO sertifikalı bir şekilde saklamanız gerekir (.pdf almanyada yeterli görünüyor)
• Denetim Parkurları genellikle gereklidir; örneğin, aynı belgenin değişiklik tarihlerini içeren farklı sürümlerini sunmanız gerekebilir.
• Depolama Yeri, depolama ülkesinde farklı olabilecek 'Datenschutz' (gizlilik) nedeniyle önemlidir . Bu, bulut tabanlı hizmetleri biraz zorlaştırır.
• Bazı belgeler değiştirilemez şekilde saklanmalıdır . bunun tam olarak nasıl gerçekleştiğinin çoğunlukla yasal nitropikliğe bağlı olduğu görülmektedir (bir kağıt değişmez, bir cd değişebilir, bir işçi tarafından imzalanmış bir cd değildir)

Özellikler için kesin olarak bir avukata başvurmalı veya en azından bir müşteriyle yakın işbirliği içinde çalışmalısınız.

İnsanların paralarıyla uğraşırken güvenilirlik faktörleri inanılmaz derecede önemli hale gelir . Twitter bir tweet'i kaybederse, o kadar büyük bir anlaşma değil; birisinin kredi kartından ödeme alırsanız ancak siparişini kaybederseniz, kuruluşunuzdaki bir kişi öfkeli bir müşteriden kulak kazanır. Yani iki şey: 1. Bunun ilk etapta olmasını istemiyorsunuz, ama 2. ne kadar dikkatli olursanız olun sonunda gerçekleşecek, bu yüzden kayıt ve izleme mekanizmalarına çok fazla enerji koymak istiyorsunuz. geri dönüp "kayıp" düzeni bulmanıza ve durumu düzeltmenize yardımcı olur.

Mutlak en kötü şey, örneğin bir kredi kartı ücretine sahip olmaktır, ancak bunun ne için olduğu veya kime ait olduğu vb.

Finansal şeyler için, görünüşte süper imkansız senaryoları bile düşünmeniz ve bunları nasıl ele alacağınızı planlamanız gerekir: "Kredi kartını borçlandırdık, ancak ilgili kaydı güncelleyebilmemiz için veritabanı sunucusu kapalı." Tamam, şimdi ne olacak? Ücreti iptal ettiniz mi? İşlem daha sonra bir insanın düzeltebileceği bir dosyaya kaydedilsin mi? Tamam, disk doluysa ve dosyaya yazamıyorsanız ne olur? Vs vs.

[1] Kullanıcılar ve uygulamanız için güvenlik tabloları kullanın (dahili DB kullanıcılarıyla karıştırmayın). modüller, formlar, web sayfaları:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] Uygulamanızdaki kayıtları silmeyin, kaydın "silindi" olarak değerlendirildiğini belirten bir durum alanı, belki tamsayı, belki boole veya bit kullanın. Uygulamayı yapın. silinmeyen kayıtları gösterir (o alan tarafından silinmiş olarak işaretlenir) ve uygulamada bazı özel vaka formları oluşturur. silindi olarak işaretlenen kayıtları gösterir.

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

Bu özelliğe "sanal silme" denir. Gerçek silme, "fiziksel silme" olarak adlandırılır.

[3] Erişimle ilgili tüm tablolardaki alanları kullanın, kaydı oluşturan (tek) kullanıcıyı ve kaydı değiştiren (son) kullanıcıyı ve mümkünse tarih saatini kullanın, mümkünse her kaydın bulunduğu modülü veya seçeneği ekleyin değiştirilmiş:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[4] Bazı durumlarda, para birimi veya para değerleri, ayrıntılı olarak birkaç kayıt kullanıldığında ve tek bir değere eklenmiş bir başlık kaydında sonuçları etkileyebilir.

Çoğu veritabanı markası, bugünlerde bir para birimi veya para veri alanını desteklemektedir. Kullanın.

Bazı özel durumlarda, bazı kişiler bunları birkaç ondalık basamak ("ondalık") destekleyen bir sabit kayan değerde veya hatta dize değerleri olarak saklar.

Bu teknik iki ucu keskin bir kılıçtır. Uygulamanız bu tür bir sunum gerektiriyorsa, web'in doğru şekilde nasıl uygulanacağına ilişkin bir eğitim için web'de arama yapın.

Şerefe. [kedicik için açık bir orkinos kutusu vermeyi veya en kötü oylamayı unutma]

Sorunuzu etiketlediniz, securityancak çoğunlukla tutarlılık ve güvenilirlikten bahsediyorsunuz, bu yüzden denklemin bu kısmına cevap vermeye çalışacağım:

• Toplu işlemlerin bütünlüğünü sağlamak için veritabanı işlemlerini kullanın. Bunun en temel örneği iki hesap arasında yapılan bir transferdir - bir hesap tutar düşülürken diğeri kredilendirilir. Kısmi aktarımın asla gerçekleşmemesini sağlamak için işlemleri kullanın (yalnızca bir taraf değiştirilir).
• Hassasiyet için, DECIMALşamandıralar yerine türü kullanın. Hesaplamalar çok daha yavaştır, ancak çoğu finansal hesaplama çok basit olduğu için hissetmemelisiniz
• Yedekleme için çalışma zamanı ve hotcopies için çoğaltma kullanın. Kurtarma için LVM anlık görüntülerine de bakmalısınız

Gördüğüm bazı noktalar iç kontrolleri hesaba katmanız gerektiğidir. Bu, tablolara karşı eylemler (Ekle / sil / güncelle) için tüm erişimin depolanmış procs aracılığıyla (ve dinamik SQl olmadan) yapılması gerektiği anlamına gelir; böylece hiçbir tablo, sistem yöneticisi dışındaki herhangi bir kişinin doğrudan tabloya yazma veya silme haklarına izin vermez. Ayrıca, birisinin yeni bir şirket oluşturmasına ve ardından bu şirkete ürün (dolandırıcılık için bir yol) tahsil etmesine izin vermeyen iç denetimleri de hesaba katmanız gerekir. Bunun gibi eylemler her zaman iki farklı roldeki kişilerin onaylanmasını gerektirir. Ayrıca, bir kişi veri girmediği ve diğeri masrafı onaylamadığı sürece kontroller kesilmemelidir.

Tüm tablolarda denetim kayıtları oluşturan tetikleyiciler bulunmalıdır. Sahtekarlığı önlemek ve kimin ne zaman harekete geçtiğini belirlemek istiyorsanız.

Finansal uygulamalarda, Kullanıcı Arayüzü tarafından hiç görülmeyen birçok arka uç işlemi ile çok daha fazla ilgilenirsiniz. İlk endişeniz sahtekarlığı önlemek ve böylece kimsenin farkında olmadığı birçok kontrolün arka uçta yapılmasıdır.

GAAP'ı (ABD'de, diğer ülkelerin kendi muhasebe standartlarına sahip) iyice okumadan ve yanlış muhasebe uygulamaları hapis zamanına yol açabileceğinden danışman olarak EBM'ye sahip olmadan herhangi bir finansal uygulama ile uğraşmazdım. Bu son derece teknik bir alandır ve gerekli bilgi birikimine sahip olmayan birinin bu alanda yazılım oluşturmaya çalışması yoktur.

Muhasebe genellikle doğrulama ile ilgilidir. Bunu hatırladığınız ve her varlık arasındaki ilişkiyi anladığınız sürece, yanlış anlamak oldukça zordur.

Mümkün olduğu kadar çok kontrol listelemeye çalışacağım ama her zaman bazılarını özleyeceğim, umarım kendi kazma işleminize başlamanız yeterli olacaktır.

Toplam Borçlar == Toplam Kredi, ister ENTIRE hesap kümesinden isterse tek başına tek bir işlemden bahsediyor olun. Olmazsa, bir yerde en az bir gönderi kaçırdınız. General Ledger bu şekilde kendini dengeler.

Alacaklar Hesapları (kontrol eden hesaba net borçlar) == Toplam faturalandırma (tüm faturalandırılabilir tutarların toplamı) - Alınan toplam (alınan tüm ödemelerin toplamı). Bu, fiili FİZİKSEL ve somut belge terimlerindeki toplamın Genel Defter (çift giriş) ile nasıl dengeleneceğinin bir örneğidir.

Banka Bakiyesi (banka ekstrenize göre) == Söz konusu hesap için Genel Defter toplamınız + yatırılan çekler ne olursa olsun - bankada yapılmayan çekler ne olursa olsun. Bu banka / nakit hesaplarının Genel ile nasıl uyuştuğuna bir örnektir Ledger.

Gördüğünüz gibi, her işlem, alt defter, hatta hisse senedi, doğrudan Defteri Kebir'e bağlanır.

Birim testi yapıyorsanız, ne kontrol edeceğinizi bildiğiniz sürece, işlemleri her eklediğinizde / güncellediğinizde bu bakiyelerin mevcut olmasını sağlayan testler yapmak oldukça kolaydır.

Tabii ki kontrol etmek / hesaplamak için daha fazla denge var ama gerekli işin özünü almalısınız. Esasen, fiziksel belgeler, Defteri Kebir kalemleri, banka ekstreleri olsun, her şey diğer her şeyle dengelenir. Mükemmel bir denge olması gerekiyor ya da mükemmel yakın, yuvarlama ile başa çıkmak tembel durumlarda.

Geliştirirken ne kadar çok kontrol gerçekleştirirseniz, yanlış bir şey alma olasılığınız o kadar az olur.

BTW, yuvarlama ile uğraşırken, şamandıralar yerine ondalıklarla gitmeye çalışın, sizi yolda çok fazla baş ağrısından kurtaracaktır. : P