Przedmowa

Istnieje obiektywna prawda: wymagania dotyczące audytu. Ponadto, w przypadku środków publicznych, istnieje ustawodawca, który musi być przestrzegany.

Nie musisz wdrażać pełnego wymogu księgowego, możesz wdrożyć tylko te części, których potrzebujesz.

Odwrotnie, byłoby nierozsądne wdrożenie czegoś innego niż standardowego wymogu rachunkowości (jego części), ponieważ gwarantuje to, że gdy liczba błędów lub obciążenie przekroczy jakiś próg, lub System się rozszerzy, będziesz musiał ponownie zaimplementować. Koszt, którego można, a zatem należy unikać.

Należy również stwierdzić: nie zatrudniaj niewykwalifikowanego, akredytowanego przez ONZ "audytora". Będą konsekwencje, takie same, jak gdybyś zatrudnił niewykwalifikowanego dewelopera. Może być gorzej, jeśli Urząd Skarbowy Cię ukarze.

Metoda

Standardową metodą Rachunkowości w nie tak prymitywnych krajach jest to. "Najlepsza praktyka", jeśli wolisz, w innych.

Ta metoda ma zastosowanie do każdego systemu, który ma podobne operacje; potrzeby; historyczne dane Miesięczne vs wymagania bieżącego miesiąca, takie jak kontrola zapasów, itp.

Rozważenie

1. Nigdy nie Duplikuj danych.
   Jeśli można uzyskać bieżące saldo (i tutaj jest to proste), nie powielaj go kolumną podsumowania. Taka kolumna jest duplikacją danych. Informatyka łamie zasady normalizacji. Co więcej, tworzy anomalię aktualizacji, która w przeciwnym razie nie istnieje.

2. Jeśli używasz kolumny podsumowania, gdy transakcje są aktualizowane (jak w przypadku zmiany, nie jak w przypadku wstawiania nowej transakcji), kolumna podsumowania wartość staje się przestarzała, więc i tak musi być aktualizowana przez cały czas. To jest konsekwencja anomalii aktualizacji. Co eliminuje wartość posiadania go.

3. Zewnętrzne Publikacja.
   Osobny punkt. Jeśli saldo jest publikowane, tak jak w comiesięcznym wyciągu bankowym, takie dokumenty zwykle mają ograniczenia prawne i implikacje, dlatego opublikowana aktualna wartość salda nie może się zmienić po publikacji.

   • Każda zmiana, po dacie publikacji, w bazie danych, liczby, która jest publikowana na zewnątrz, jest dowodem nieuczciwego zachowania, oszustwa itp.

     [63]. taki akt, próbujący zmienić publikowaną historię, jest znak rozpoznawczy nowicjusza. Nowicjusze i pacjenci umysłowi będą nalegać, aby historia mogła zostać zmieniona. Ale jak każdy powinien wiedzieć, nieznajomość prawa nie stanowi ważnej obrony.

4. Nie chciałbyś, aby Twój bank w kwietniu 2015 r.zmienił Twoje obecne saldo, które opublikowali w swoim wyciągu bankowym z grudnia 2014 r.

5. Liczba ta musi być postrzegana jako liczba kontrolna, opublikowana i niezmienna.

6. To korekta błędu, który został popełniony w przeszłości, który jest korygowany w chwili obecnej, korekta lub korekta, która jest konieczna, jest dokonywana jako nowe transakcje w bieżącym miesiącu(nawet jeśli dotyczy jakiegoś poprzedniego miesiąca lub czasu trwania).

   Dzieje się tak dlatego, że Ten miesiąc jest zamknięty, kontrolowany i publikowany, ponieważ nie można zmienić historii po jego zaistnieniu i zarejestrowaniu. Jedynym skutecznym miesiącem jest bieżący jeden.

   • Dla Systemów oprocentowania, itp., w nie-tak-prymitywnych krajach, gdy błąd zostanie znaleziony, a to ma efekt historyczny (np. w kwietniu 2015 r. dowiadujesz się, że odsetki naliczone od papieru wartościowego były nieprawidłowe (od grudnia 2014 r.), wartość SKORYGOWANEJ płatności odsetek/odliczenia jest obliczana dzisiaj, dla liczby dni, które wystąpiły w błędzie, a suma jest wstawiana jako transakcja w bieżącym miesiącu. Ponownie, jedynym skutecznym miesiącem jest obecny jeden.

     I oczywiście należy również skorygować stopę procentową dla zabezpieczenia, aby ten błąd się nie powtórzył.

   • Jeśli zauważysz błąd w obliczeniu odsetek na rachunku oszczędnościowym (oprocentowanym) i poprawisz go, otrzymasz pojedynczy depozyt, który stanowi całą wartość korekty, w bieżącym miesiącu. To jest transakcja w bieżącym miesiącu.

     Bank nie: zmienia historii; stosuje odsetki za każdego z historycznych miesięcy; Przypomnij historyczne wyciągi bankowe; ponownie Opublikuj historyczne wyciągi bankowe. Nie. Może poza krajami trzeciego świata.

   • Te same zasady mają zastosowanie do systemów kontroli zapasów. Zachowuje zdrowy rozsądek.

7. Wszystkie rzeczywiste systemy księgowe (tj. te, które są akredytowane przez instytucję audytową w danym kraju, w przeciwieństwie do "pakietów", które obfitują) korzystają z systemu podwójnego wjazdu dla Transakcje, właśnie dlatego, że zapobiega mnóstwu błędów, z których najważniejsze jest to, że fundusze nie "gubią się". To wymaga księgi głównej i podwójnego zapisu księgowego.

   Nie prosiłeś o to, nie potrzebujesz tego, dlatego nie opisuję tego tutaj. Ale pamiętaj o tym, na wypadek, gdyby pieniądze "zniknęły", ponieważ to jest to, co będziesz musiał wdrożyć, a nie jakieś rozwiązanie bandażowe; Nie kolejny nieakredytowany "pakiet".

Ta Odpowiedź usługi to pytanie, które jest zadawane, czyli a nie Podwójne Księgowanie.
Aby uzyskać pełne traktowanie tego tematu (szczegółowy model danych; przykłady transakcji księgowych; wiersze, których dotyczy problem; i przykłady kodu SQL), zapoznaj się z tym pytaniem i odpowiedziami:
relacyjny Model danych dla rachunkowości podwójnego zapisu.

8. Główne problemy, które wpływają na wydajność są poza zakresem tego pytania, są w obszarze, czy wdrożyć prawdziwa relacyjna baza danych lub nie (np. System Archiwizacji rekordów z lat 60., który charakteryzuje się Record IDs, wdrożony w kontenerze bazy danych SQL dla wygody).

   • Użycie oryginalnych kluczy relacyjnych itp. utrzyma wysoką wydajność, niezależnie od populacji tabel.

   • I odwrotnie, RFS będzie działać źle, po prostu nie może wykonać. "Skala", gdy jest używana w kontekście RFS, jest fałszywym terminem: ukrywa przyczynę i stara się zajmijcie się wszystkim oprócz przyczyny. Co najważniejsze, takie systemy nie mają integralności relacyjnej, mocy relacyjnej lub prędkości relacyjnej systemu relacyjnego.

Implementacja

Relacyjny Model Danych * Saldo Konta

Relacyjny Model Danych * Inwentaryzacja

Notacja

• Wszystkie moje modele danych są renderowane w IDEF1X, na Standard modelowania relacyjnych baz danych od 1993 roku.

• My IDEF1X wprowadzenie jest niezbędna dla tych, którzy są nowi w modelu relacyjnego , lub jego metody modelowania. Zauważ, że modele IDEF1X są bogate w szczegóły i precyzję, pokazując wszystkie wymagane szczegóły, podczas gdy modele domowe mają znacznie mniej. Co oznacza, że zapis musi być zrozumiały.

Treść

1. Dla każdego Konto, będzie ClosingBalance, w AccountStatement Tabeli (jeden wiersz na AccountNo na miesiąc), wraz z datą wyciągu (zwykle pierwszy dzień miesiąca) i inne szczegóły wyciągu.

   • To nie jest duplikat, ponieważ jest wymagany dla celów audytu i zdrowego rozsądku.

     Dla inwentarza, jest to kolumna QtyOnHand, w tabeli PartAudit (jeden wiersz na PartCode na miesiąc)

   • Ma dodatkową wartość, ponieważ ogranicza zakres wymaganych wierszy transakcji do zapytania do bieżący miesiąc

     • Ponownie, jeśli twoja tabela jest relacyjna, kluczem głównym dla AccountTransaction będzie (AccountNo, Transaction DateTime), który pobierze transakcje z szybkością milisekund.

     • Podczas gdy dla systemu archiwizacji rekordów "kluczem podstawowym" będzie TransactionID, a bieżący miesiąc zostanie pobrany według daty transakcji, która może być poprawnie indeksowana, a wymagane wiersze zostaną rozłożone w pliku. W każdym sprawa przy znacznie mniejszej prędkości niż ClusteredIndex, a ze względu na rozrzut, poniesie tablescan.

2. Tabela AccountTransaction pozostaje prosta (rzeczywiste pojęcie transakcji na rachunku bankowym jest proste). Posiada jedną kolumnę dodatnią Amount.

3. Dla każdego Account, CurrentBalance jest:

   • AccountStatement.ClosingBalance z poprzedniego miesiąca, datowany na pierwszy z następnego miesiąca dla wygody

     (dla inwentaryzacji, PartAudit.QtyOnHand)

   • Plus suma AccountTransaction.Amounts w bieżącym miesiącu, gdzie TransactionType oznacza depozyt

     (dla inwentaryzacji, PartMovement.Quantity)

   • Minus suma AccountTransaction.Amounts w bieżącym miesiącu, gdzie ' MovementType oznacza wypłatę.

4. W tej metodzie AccountTransactions w bieżącym miesiącu, tylko, są w stanie zmienności, więc muszą być wyprowadzone. Wszystkie poprzednie miesiące są publikowane i zamykane, a więc Należy użyć liczby kontrolnej .

5. Starsze wiersze w tabeli AccountTransaction można wyczyścić. Starsze niż dziesięć lat dla pieniędzy publicznych, pięć lat w przeciwnym razie, jeden rok dla Systemów hobbystycznych.

6. Oczywiście istotne jest, aby każdy kod odnoszący się do systemów księgowych używał oryginalnych standardów OLTP i oryginalnych transakcji SQL ACID.

7. Ta konstrukcja uwzględnia wszystkie aspekty wydajności na poziomie zakresu (jeśli nie jest to oczywiste, proszę zapytać do rozbudowy). Skalowanie wewnątrz bazy danych nie jest problemem, wszelkie problemy ze skalowaniem, które pozostają, są szczerze poza bazą danych.

Porady Korekcyjne

1. Widocznie niektórzy ludzie nie rozumiem, że podałem metodę pod względem technicznym, aby działać w oparciu o jasny model danych. Jako taki, nie jest to pseudokod dla konkretnej aplikacji w określonym kraju. Metoda jest dla zdolnych programistów, nie jest wystarczająco szczegółowa dla tych, którzy muszą być prowadzeni za rękę.

   • Nie rozumieją również, że okres odcięcia miesiąca jest przykład: jeśli twój okres odcięcia dla celów Urzędu Skarbowego jest kwartalny, to za wszelką cenę użyj ograniczenie kwartalne; jeśli jedynym wymaganiem prawnym jest roczne, użyj corocznego.

   • Nawet jeśli twoja granica jest kwartalna dla celów zewnętrznych lub compliance, firma może również wybrać miesięczną granicę, dla celów audytu wewnętrznego i zdrowego rozsądku (tj. aby ograniczyć długość okresu stanu strumienia do minimum).

     Eg. w Australii, Urząd Skarbowy odciąć dla firm jest kwartalne, ale większe firmy odciąć ich kontroli zapasów miesięcznie (oszczędza konieczność pościgu za błędami przez długi czas).

     Eg. banki mają wymogi zgodności z prawem co miesiąc, dlatego przeprowadzają Audyt wewnętrzny danych liczbowych i zamykają księgi, co miesiąc.

   • W krajach prymitywnych i zbuntowanych, banki utrzymują maksymalny okres ich stanu zmienności, dla oczywistych nikczemnych celów. Niektóre z nich sporządzają sprawozdania dotyczące zgodności tylko raz w roku. To jeden z powodów, dla których banki w Australii nie porażka.

2. W tabeli AccountTransaction nie należy stosować ujemnych/dodatnich w kolumnie kwota. Pieniądze zawsze mają wartość dodatnią, nie ma czegoś takiego jak ujemne dwadzieścia dolarów (lub że jesteś mi winien minus pięćdziesiąt dolarów), a następnie ustalenie, że podwójne negatywy oznaczają coś innego.

3. Kierunek ruchu, czyli to, co zamierzasz zrobić z funduszami, jest oddzielnym i dyskretnym faktem (do AccountTransaction.Amount). Która wymaga oddzielnego kolumna (dwa fakty w jednym punkcie odniesienia łamią reguły normalizacji, w konsekwencji wprowadzają do kodu złożoność).

   • Zaimplementuj tabelę referencyjną TransactionType, której głównym kluczem jest (D, W ) do wpłat/wypłat jako punkt wyjścia. W miarę rozwoju systemu po prostu dodaj (A, a, F, w ) do korekty kredytu; korekty debetu; opłaty bankowej; ATM_Withdrawal; itp.

   • Nie jest wymagana zmiana kodu.

4. W jakimś prymitywnym kraje, wymagania sporne stwierdzają, że w każdym raporcie, który wymienia transakcje, suma bieżąca musi być pokazana na każdej linii. (Uwaga, nie jest to wymóg kontroli, ponieważ są one wyższe [(patrz metoda powyżej) do wymogu Trybunału; Audytorzy są nieco mniej głupi niż prawnicy; itp.)

   Oczywiście, nie spierałbym się z wymogiem sądowym. Problem polega na tym, że prymitywni koderzy tłumaczą to na: oh, oh, musimy zaimplementować AccountTransaction.CurrentBalance kolumna . Nie rozumieją tego:

   • Nie jest to wymagane, aby wydrukować kolumnę w raporcie, a nie nakaz przechowywania wartości w bazie danych

   • Suma uruchomiona dowolnego rodzaju jest wartością pochodną i jest łatwo zakodowana(wyślij pytanie, jeśli nie jest to dla ciebie łatwe). Wystarczy zaimplementować wymagany kod w raporcie.

   • Implementacja running total np. AccountTransaction.CurrentBalance jako kolumna powoduje horrendalne problemy:

     • Wprowadza zduplikowany kolumna, ponieważ jest pochodna. Łamie Normalizację. Wprowadza anomalię aktualizacji.

     • Anomalia aktualizacji: za każdym razem, gdy transakcja jest wstawiana historycznie, lub AccountTransaction.Amount jest zmieniana, wszystkie AccountTransaction.CurrentBalances od tej daty do chwili obecnej muszą być ponownie obliczone i zaktualizowane.

   • W powyższym przypadku raport, który został złożony do użytku sądowego, jest obecnie Nieaktualny (każdy raport danych online jest nieaktualny w momencie jego wydrukowania). Ie. Drukuj; przejrzyj; Zmień transakcję; ponownie wydrukuj; ponownie przejrzyj, dopóki nie będziesz zadowolony. W każdym razie jest to bez znaczenia.

   • Dlatego w krajach mniej prymitywnych sądy nie akceptują żadnych starych druków, akceptują tylko opublikowane dane, np. Wyciągi bankowe, które podlegają już wymogom kontroli (patrz metoda powyżej), a których nie można przywołać ani zmienić ani ponownie wydrukować.

Komentarze

Alex:
tak, Kod byłby miły do obejrzenia, dziękuję. Nawet może przykładowe "wiadro sklep" tak ludzie mogli zobaczyć schemat początkowy raz i na zawsze, uczyni świat znacznie lepszym.

Dla modelu danych powyżej.

Kod * Raport Salda Bieżącego

SELECT  AccountNo,
        ClosingDate = DATEADD( DD, -1 Date ), -- show last day of previous
        ClosingBalance,
        CurrentBalance = ClosingBalance + (
            SELECT SUM( Amount )
                FROM AccountTransaction
                WHERE AccountNo = @AccountNo
                    AND TransactionTypeCode IN ( "A", "D" )
                    AND DateTime >= CONVERT( CHAR(6), GETDATE(), 2 ) + "01"
                ) - (
            SELECT SUM( Amount )
                FROM AccountTransaction
                WHERE AccountNo = @AccountNo
                    AND TransactionTypeCode NOT IN ( "A", "D" )
                    AND DateTime >= CONVERT( CHAR(6), GETDATE(), 2 ) + "01"
                )
    FROM AccountStatement
    WHERE AccountNo = @AccountNo
        AND Date = CONVERT( CHAR(6), GETDATE(), 2 ) + "01"

Przez denormalizowanie tego dziennika transakcji zamieniam zwykły formularz na wygodniejsze zapytania i mniej zmian w widokach / zmaterializowanych widokach, gdy dodaję więcej typów tx

1. Kiedy idziesz wbrew standardom, stawiasz się w pozycji trzeciego świata, gdzie rzeczy, które nie powinny się łamać, które nigdy nie pękają w krajach pierwszego świata, pękają.

   Prawdopodobnie nie jest dobrym pomysłem szukanie właściwej odpowiedzi od organu, a następnie argumentowanie przeciwko niej lub argumentowanie za swoją niższostandardową metodą.

2. Denormalizacja (tutaj) powoduje anomalię aktualizacji, zduplikowaną kolumnę, która może być wyprowadzona z Kod transakcji. Chcesz łatwości kodowania, ale jesteś gotów kodować go w dwóch miejscach, a nie w jednym. To jest dokładnie ten rodzaj kodu, który jest podatny na błędy.

   Baza danych, która jest w pełni znormalizowana zgodnie z Modelem relacyjnym Dr E F Codda , zapewnia najprostszy, najbardziej logiczny, prosty kod. (W mojej pracy gwarantuję, że każdy raport może być obsługiwany przez jeden SELECT.)

3. ENUM nie jest SQL. (Freeware Pakiety NONsql nie mają zgodności z SQL, ale mają dodatki, które nie są wymagane w SQL.) Jeśli kiedykolwiek Twoja aplikacja przejdzie na komercyjną platformę SQL, będziesz musiał ponownie zapisać wszystkie te ENUMs jako zwykłe tabele wyszukiwania. Z CHAR(1) lub {[37] } jako PK. Wtedy docenisz, że jest to rzeczywiście stół z PK.

4. Błąd ma wartość zero (ma również negatywne konsekwencje). Prawda ma wartość jednej. Nie zamieniłbym jedynki na zero. Dlatego jest to nie kompromis. To tylko twoja decyzja o rozwoju.