Projekt bazy danych rachunków podwójnego zapisu

Tworzę oprogramowanie księgowe. Muszę wymusić prowadzenie podwójnej księgowości. Mam klasyczny problem jednego wiersza na transakcję w porównaniu do dwóch wierszy.

Weźmy przykład i zobaczmy, jak zostałby on wdrożony w obu scenariuszach.

Rozważ konto Cashi konto Rent. Kiedy płacę miesięczny czynsz, przesyłam 100 USD z mojego Cashkonta na Rentkonto.

Jeden wiersz na transakcję

W systemie z jednym wierszem taka transakcja byłaby przechowywana jako:

transakcje

 tx_id | posting_date
 1     | 23/05/2015

transakcje_records

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

Dwa wiersze na transakcję

W systemie dwurzędowym musiałbym wykonać kopię lustrzaną tego samego rekordu transakcji, aby utworzyć przeciwny rekord, który po zsumowaniu obu uzyskałbym zerowe saldo.

transakcje

 tx_id | posting_date
 1     | 23/05/2015

transakcje_records

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

Problem

Przede wszystkim chciałbym zauważyć: powodem, dla którego mam oba tabele transactionsi transaction_records(zamiast jednej tabeli) jest możliwość obsługi transakcji podzielonych (przypadek, w którym przesyłam 100 USD z Cashkonta na dwa lub więcej różnych kont).

Na początku próbowałem to zaimplementować z jednym wierszem na transakcję, ale trudno jest obliczyć saldo konta i faktycznie pobrać dane.

Przechylam się do drugiego scenariusza; ma jednak również pewne problemy:

• Jak zaktualizować pojedynczy rekord? Zakładając, że popełniłem błąd i zamiast nagrać 100 USD za czynsz, zarejestrowałem 10 USD. Mam teraz 2 transaction_records- jeden na kredyt i jeden na debet, oba o wartości 10 USD.
• Teraz dokonuję pojednania i chcę naprawić tę literówkę. Jak mam to naprawić w bazie danych? Nie znam związku między rekordami, aw przypadku podziału jedna transakcja może mieć więcej niż 2 rekordy. Jedynym rozwiązaniem, jakie wymyśliłem, jest dodanie niektórych ref_iddla każdej pary rekordów, które jednoznacznie zidentyfikują te rekordy jako „przeciwne strony siebie” w kontekście określonego tx_id.

Które podejście jest lepsze / prostsze?

Aby uprościć moje pytanie: chcę przedstawić przepływ środków z konta A na konto B. Oba podane przeze mnie scenariusze są prawidłowymi projektami do przechowywania takiej transakcji. Jak zauważyłem, oba mają wady i zalety (pierwszy: łatwiejszy do zapisania, trudniejszy do odzyskania; drugi przeciwny).

Mogą mieć inne zalety / wady, których teraz nie dostrzegam, dlatego pytam o opinię bardziej doświadczonych ludzi.

Rzeczywiście, zaproponowany schemat rachunkowości z jednym wierszem pozwala na przeprowadzenie prawidłowej rachunkowości podwójnego zapisu (w celu zawsze określenia rachunku obciążanego i uznanego) bez wprowadzania zbędnych danych „kwoty”.

Schemat jednorzędowy zapewnia implementację podwójnego wpisu, który równoważy konstrukcję, dzięki czemu niemożliwe jest „stracenie równowagi”. Maszyna może przeliczyć księgi w locie.

Musisz zrobić 2 zaznacz zamiast jednego, aby pobrać księgę.

Uwaga, oprócz podziału transakcji, istnieją inne transakcje, takie jak wymiana walut może skończyć się 2 rekordami zamiast 4. Wszystko zależy od tego, czy zdenormalizujesz bit, po prostu wprowadź 4 transakcje o podobnym opisie.

Możesz uniemożliwić wprowadzenie lub modyfikację dowolnej transakcji w celu utrzymania ścieżki audytu, jest to wymagane, jeśli chcesz mieć możliwość inspekcji dziennika transakcji.

Wydaje się, że w powyższym wątku, w przypadku CPA, „w pełni znormalizowany” wydaje się oznaczać reguły uznawane przez wszystkich księgowych, podczas gdy dla programisty ma inne znaczenie, że nie są przechowywane żadne pochodne ani zbędne dane.

Dane księgowe to tylko zestaw transakcji, które podają kwotę i rachunki, z których i do których przepływają, wraz z datą, opisem (i innymi załącznikami). Księgi rachunkowe i salda są prostymi widokami pochodzącymi z tych danych transakcyjnych przez wykonanie sum.

Journal jest chronologiczny wykaz wszystkich transakcji określonego typu do systemu księgowego. Oto klasyczna prezentacja na papierze księgowym prostego Dziennika sprzedaży (na koncie):

Pamiętaj, że każda linia jest pojedynczą transakcją, przy czym suma debetów = suma kredytów; i że każda transakcja trafia na te same trzy konta. Gotówka Sales Journal będzie wyglądać podobnie, ale zastąpić kolumnie należności Debit z jednego oznaczonego pieniężne Debit . Gotówka Wydatkowanie Journal miałyby pierwszą kolumnę oznaczoną Gotówka Kredyty i dodatkowe kolumny takie jak Accounts Payable debetowej i kosztami świadczeń pracowniczych Debit .

Ta prezentacja była standardem przez setki lat, aż kilka lat temu komputery osobiste stały się dostępne. Ma znaczącą zaletę polegającą na łatwym sprawdzeniu, czy każda transakcja jest równoważona poprzez proste sprawdzenie każdego wiersza. Podobnie, przed wysłaniem strony takiej transakcji do ksiąg rachunkowych sumy stron mogą być podobnie zweryfikowane. Jest to model przetwarzania wsadowego stosowany w wielu systemach księgowych.

Łatwo zauważyć, że ten papierowy model ma znaczące wady, gdy dosłownie jest transkrybowany do zautomatyzowanego systemu:

1. Struktura danych jest obrotowa, podczas gdy doświadczenie pokazuje, że programowanie w oparciu o złożoną strukturę danych jest znacznie prostsze (również bardziej niezawodne i łatwiejsze do zweryfikowania); i
2. Ponieważ każdy specjalistyczny dziennik trafia na inny zestaw kont, każdy taki dziennik musiałby być osobno zaprojektowany i zaprogramowany, co byłoby marnotrawną i podatną na błędy działalnością.

Z tych powodów na ogół zaleca się stosowanie projektu czasopism specjalistycznych jako interfejsu do systemu księgowego, ale zaprojektowanie struktury danych, która może być repozytorium numerycznym dla wielu czasopism. W nowoczesnym RDBMS ma to potencjalną zaletę, że Księga Główna , a nawet wyspecjalizowani subledgery , mogą stać się widokami indeksowanymi w dzienniku, całkowicie eliminując konieczność kodowania procesu księgowania (etap, w którym transakcja w dzienniku jest zablokowana i ma swoje konto sumy przypisane do różnych ksiąg).

Niezależnie od tego, jaki projekt danych ostatecznie skończysz, kluczem jest posiadanie jednego wpisu księgowania dla każdego rodzaju transakcji (tj. Każdego specjalistycznego dziennika w równoważnym systemie papierowym), w którym przeprowadzane są kontrole salda.

Chodzi mi o to, że oba podejścia, które proponujesz, są niewłaściwymi mechanizmami podwójnej księgowości. Pierwszy punkt: Dzienniki są tabelami jednokrotnego zapisu z bardzo dobrych powodów. Czasami dwie wirtualne tabele Oczekiwane wpisy i Wpisy wysłane są umieszczone w jednej strukturze danych, ale bit IsPosted jest zawsze tylko do zapisu, a system musi zapewnić, że rekordy wpisów wysłanych tylko do odczytu zostaną zachowane.

Sposób, w jaki księgowi publikowali wpisy do dziennika w ciągu ostatnich 800 lat, jest w pełni znormalizowany . Jedyną różnicą między prezentacją w formie papierowej a dźwiękową prezentacją elektroniczną jest to, że struktura złożonego stołu jest wygodniejsza w tym drugim przypadku, a struktura stołu obrotowego w pierwszym przypadku, co historycznie było najbardziej znaczące, gdy pożądane było przetwarzanie równoległe - tj. Wielu urzędników każdy prowadzenie jednej lub niewielkiej liczby specjalistycznych czasopism. Tylko administrator historycznie posiadał uprawnienia do Dziennika ogólnego.

Zwróć uwagę, że w powyższym stwierdziłem, że wpisy do dziennika są w pełni znormalizowane; Wpisy do dziennika są chronologicznym zapisem wszystkich transakcji, pogrupowanymi w Dzienniki specyficzne dla każdego rodzaju transakcji. Wpis z zapisów księgowych do ksiąg jest odrębnym przedsięwzięciem, a jednocześnie w pełni znormalizowane na własną rękę, to zbędne kopie zapisów księgowych, gdzie są zestawione wszystkie transakcje (General Ledger) lub szczegółowy (SUB Ledger) poprzez konto. Zarówno dzienniki, jak i księgi rachunkowe stosują niezależną księgowość podwójnego zapisu.

@Codism Każdy system księgowy, DEB lub SEB, zapewnia uogólnione raportowanie dla wszystkich zarejestrowanych kont . Należy zauważyć, że wewnętrznie księga pomocnicza jest z definicji rekordem księgowym z jednym wpisem; druga strona to odpowiednie konta kontrolne w bilansie. DEB zapewnia, że ​​dla każdego dolara aktywów istnieje dokładna rejestracja roszczeń biznesowych dotyczących danego składnika aktywów , tj. Kapitału własnego składnika aktywów, niezależnie od tego, czy jest to dług kapitałowy (inaczej zobowiązanie) lub kapitał własny , oraz priorytet tych roszczeń, jeżeli organizacja staje się niewypłacalna.

Czy mogę zasugerować, aby rzucić okiem na skarbnicę oprogramowania Open Source, które znajduje się w tym obszarze?

Google „ oprogramowania do księgowania podwójnego zapisu typu open source ” daje kilka obiecujących możliwości dochodzenia.

Można spojrzeć na opakowaniu rachunkowości GNU tutaj , kilka stron przeglądarki ( 1 i 2 ) i wreszcie wiki programów księgowych z części poświęconej Wolnego Oprogramowania.

Jestem pewien, że badając niektóre kody źródłowe i schematy F / LOSS, możesz uzyskać dobre wskazówki i wskazówki, jak pisać schematy i / lub oprogramowanie, które odpowiadają twoim konkretnym potrzebom.

Mam system, który robi podwójne linie i ma wiele wyzwań niż posiadanie kont z pojedynczymi liniami. Najpierw napotkałem przypadki wypychania tylko jednej linii jak po stronie debetowej, co prowadzi do niezbilansowania konta. Nawet jeśli nie przeprowadzam odpowiedniej kontroli zatwierdzania i wycofywania zmian, nie byłoby to możliwe na kontach z jedną linią. wreszcie, twoja db rośnie w podwójnym tempie wzrostu, twoja druga linia wysyłania będzie miała wiele zduplikowanych informacji, jedyną różnicą jest drugie konto. Radzę zatrzymać jedno konto linii, idę do tej trasy ..