Çift girişli defter tutma veritabanı tasarımı

Muhasebe yazılımı oluşturuyorum. Çift girişli defter tutmaya zorlamam gerekiyor. İki sıraya karşı işlem başına bir satır klasik sorun var.

Bir örnek ele alalım ve her iki senaryoda da nasıl uygulanacağını görelim.

Hesap Cashve hesap düşünün Rent. Aylık kiramı ödediğimde, hesabımdan Cashhesabım için 100 $ transfer ediyorum Rent.

İşlem başına bir satır

Tek sıralı bir sistemde, böyle bir işlem şöyle saklanır:

işlemler

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

İşlem başına iki satır

İki sıralı bir sistemde, her ikisini de topladığımda sıfır bakiye alacağım bir ters kayıt oluşturmak için aynı işlem kaydını yansıtmak zorunda kalacağım.

işlemler

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00

Sorun

Her şeyden önce ben not etmek istiyorum: Ben ikisine de sahip sebebi transactionsve transaction_records(yerine bir tablonun) tabloları sap bölünmüş işlemler edebilmek için (a dava ı dan 100 $ aktarmak nerede Cashiki veya daha fazla farklı hesaplara hesabı).

İlk başta bunu işlem başına bir satır ile uygulamaya çalıştım, ancak hesap bakiyesini hesaplamak ve veriyi gerçekten almak çok üzücü.

İkinci senaryoya doğru eğildim; ancak, bazı sorunları da var:

• Tek bir kaydı nasıl güncellerim? Bir hata yaptım ve kirası için 100 dolar kaydetmek yerine, 10 dolar kaydettim. Şimdi her transaction_recordsikisi de 10 dolar olan 2 tane, biri kredi için ve biri de borç için.
• Şimdi uzlaşmamı yapıyorum ve bu yazım hatasını düzeltmek istiyorum. Bunu veritabanında nasıl düzeltebilirim? Kayıtlar arasındaki bağlantıyı bilmiyorum ve ayrılma durumunda, bir işlem 2'den fazla kayda sahip olabilir. Karşılaştığım tek çözüm, ref_idbelirli bir bağlamda bu kayıtları “birbirinin karşıt tarafı” olarak tanımlayacak olan her kayıt çifti için bir miktar eklemek tx_id.

Hangi yaklaşım daha iyi / daha basit?

Sorumu basitleştirmek için: A hesabından B hesabına fon hareketini temsil etmek istiyorum. Verdiğim iki senaryo, bu tür bir işlemi depolamak için geçerli tasarımlardır. Benim de belirttiğim gibi ikisinin de eksileri var (birincisi: kurtarmak daha kolay, daha zor; ikincisi tersi).

Şu an farketmediğim başka artıları / eksileri olabilir, bu yüzden daha deneyimli insanlardan bir fikir istiyorum.

Gerçekten de, önerilen tek satırlı muhasebe şeması, "tutar" verilerinin fazlalığını vermeden, uygun çift girişli muhasebenin (her zaman borçlandırılan ve yatırılan hesabı belirtmek için) yapılmasına izin verir.

Tek sıra şema, size "gevşek denge" yapmanın imkansız olması için yapıyla dengelenen çift girişin uygulanmasını sağlar. Makine, defterleri anında yeniden hesaplayabilir.

Bir defter almak için bir yerine 2 seçim yapmanız gerekir.

İşlem bölünmesinin yanı sıra, döviz gibi 4 işlem yerine 2 kayıtla sonuçlanabilecek başka işlemler de olduğunu unutmayın. Bunların hepsi, biraz benzer şekilde tanımlanmış 4 işlem girmenizden ibaret olmanıza bağlıdır.

Bir denetim izini sürdürmek için herhangi bir işlemin girilmesini veya değiştirilmesini önleyebilirsiniz, işlem günlüğünü denetleyebilmek istiyorsanız bu gereklidir.

Yukarıdaki iş parçacığında, EBM için "tamamen normalleştirilmiş" ifadesi, tüm muhasebeciler tarafından tanınan kurallar anlamına gelir, oysa programcı için saklanan türetilmiş veya fazla veri bulunmadığından farklı bir anlamı vardır.

Muhasebe verilerindeki tek şey, bir açıklama (ve diğer ekler) ile birlikte tarih ve tutarlarını ve bunlardan aktıkları hesapları veren bir işlem kümesidir. Defterler ve bakiyeler, bu işlem verilerinden, toplamları yaparak elde edilen basit görünümlerdir.

Bir Journal bir muhasebe sistemi için belirli bir türdeki tüm işlemlerin kronolojik listesidir. İşte basit bir Satış (Hesapta) Dergisinin defter kağıdına klasik bir sunum :

Her satırın Toplam Borç = Toplam Kredi ile tek bir işlem olduğunu unutmayın; ve her işlem aynı üç hesaba çarptı. Bir Nakit Satış Dergisi benzer görünecek, ancak sütunu değiştirecektir Alacak Borç bir adet Nakit Borç etiketiyle değiştirecektir . Bir Nakit Ödemeleri Dergisi , Nakit Kredi etiketli bir ilk sütuna ve Borçlu Borç ve Çalışan Gider Borçları gibi ek sütunlara sahip olacaktır .

Bu sunum, kişisel bilgisayarlar birkaç on yıl önce ekonomik hale gelinceye kadar yüzlerce yıldır standarttı. Her bir işlemi basitçe kontrol ederek her bir işlemin dengede olduğunu kolayca belirleme konusunda önemli bir avantaja sahiptir. Aynı şekilde, önce gönderme için böyle işlemin bir sayfa Defter sayfası toplamları benzer doğrulanmadı olabilir. Bu, birçok muhasebe sisteminde kullanılan toplu işleme modelidir.

Bu kağıt modelinin kelimenin tam anlamıyla otomatik bir sisteme aktarıldığında ciddi dezavantajları olduğunu görmek kolaydır:

1. Veri yapısı, döndürülmüş bir yapıdır, ancak deneyim, katlanmış bir veri yapısına karşı programlamanın daha basit (aynı zamanda daha sağlam ve daha kolay doğrulanmış) olduğunu göstermiştir; ve
2. Her uzman dergi farklı bir hesap kümesine çarptığı için, bu tür bir Dergi ayrı ayrı tasarlanmalı ve programlanmalıdır, bu israf ve hataya açık bir faaliyettir.

Bu nedenlerden dolayı, Uzmanlık Dergileri tasarımını muhasebe sistemine arayüz olarak kullanmak , ancak çoklu dergiler için sayısal depo olabilecek bir veri yapısı tasarlamak genellikle tavsiye edilir . Modern bir RDBMS'de bu, Genel Mutabakat ve hatta uzmanların potansiyel avantajına sahiptir. subledger'lerin , Dergi üzerinde Endekslenmiş Görünümler haline gelmesi , bir Kayıt İşleminin kodlanması gerekliliğinin tamamen ortadan kaldırılması (bir Journal işleminin kilitlendiği ve hesabının bulunduğu adım) tamamen sahiptir. çeşitli defterlere kopyalanan toplamlar).

Hangi veri tasarımında olursa olsun, önemli olan tek bir bakiye kontrollerinin yapıldığı her işlem türü için Kayıt Girişine (yani eşdeğer kağıt sistemindeki her bir Uzman Dergisine ) .

Demek istediğim şu ki, önerdiğiniz her iki yaklaşım da çift ​​girişli defter tutma için sağlam olmayan mekanizmalar. Birinci nokta: Dergiler çok iyi nedenlerden dolayı bir kez yazılan masalardır. Bazen Bekleyen Girdiler ve Gönderilen Girdiler adlı iki sanal tablo tek bir veri yapısında toplanır , ancak IsPosted biti her zaman salt okunurdur ve sistemin Gönderilmiş Girdi kayıtlarının salt okunur doğasının korunmasını sağlaması gerekir.

Muhasebecilerin son 800 yıl boyunca Dergi Girişleri yayınlama biçimleri tamamen normalize edildi . Bir bildiri sunumu ile sağlam bir elektronik sunum arasındaki tek fark, katlanmış bir masa yapısının, ikinci durumda daha uygun olması, birincisinde, çok paralel işleme istendiğinde, tarihsel olarak en önemli olan bir döner tabla yapısının, yani her birinin katipleri olmasıydı. tek veya az sayıda özel dergiyi sürdürmek. Sadece Denetleyici tarihsel olarak Genel Dergi için izinlere sahipti.

Yukarıda dikkatlice not aldım, dergi girişleri tamamen normalize olduğunu belirtti; Dergi Girdileri , her işlem türüne özgü Dergilerde gruplanan tüm işlemlerin kronolojik bir kaydıdır. Gönderme ait günlük girdileri tamamen kendi başına normalize ederken Ledgers, ayrı bir çabadır ve hesaba göre dergi tüm işlemler özetlenmiştir girdileri (Genel Muhasebe) ya da ayrıntılı (Alt Ledger) bir yedekli kopyasıdır. Hem Dergiler hem de Defterler bağımsız olarak çift girişli defter tutma kullanmaktadır.

@Codism Herhangi bir muhasebe sistemi, DEB veya SEB, kaydedilen tüm hesaplar için genelleştirilmiş raporlama sağlar . Dahili olarak, bir alt defterin tanımı gereği tek girişli bir defter tutma kaydı olduğunu; diğer taraf, Bilançodaki ilgili kontrol hesaplarıdır . DEB her varlık dolar için kesin bir kayıt yoktur olmasını sağlar varlığın üzerinde iş istem , yani öz bir olsun varlığın içinde borç özkaynak (yükümlülük aka) veya bir sahiplik özkaynak ve bu istemlerin ise öncelik organizasyon iflas etmiş olur.

Bu alanda bulunan Açık Kaynak kodlu yazılımın hazine hazinesine bir göz atmanızı önerebilir miyim?

" Açık kaynaklı çift girişli muhasebe yazılımı " adlı bir Google, birçok ümit verici araştırma yolu sunmaktadır.

Burada GNU muhasebe paketine , birkaç inceleme sitesine ( 1 ve 2 ) ve son olarak Özgür Yazılım ile ilgili bir bölüme sahip olan muhasebe yazılımının wiki'sine bakabilirsiniz .

Bazı F / LOSS kaynak kodlarını ve şemalarını inceleyerek, kendi özel gereksinimlerinize uyan şema ve / veya yazılımların nasıl yazılacağına dair bazı iyi ipuçları ve göstergeler alabileceğinize eminim.

Tek satırlık hesaplara sahip olmaktan ziyade çift satır yapan ve çok fazla zorluk çeken bir sistemim var. İlk önce, borçlanma tarafı gibi itilen tek bir satırın örnekleri ile karşılaştım, bu da dengesiz bir hesapla sonuçlandı. Taahhüt ve geri dönüşlerin uygun kontrollerini yapmasam bile, bu tek satırlık hesaplarda olmaz. Son olarak, db'niz çift büyüme oranında büyür, ikinci gönderim hattınız çok sayıda yinelenen bilgiye sahip olacaktır, tek fark ikinci hesaptır. Elde tutma tavsiyesi, tek hat hesabı, o rotaya gidiyorum ..