Jakie szczególne uwagi są potrzebne przy projektowaniu baz danych do przechowywania dokumentacji finansowej?

Mam nadzieję, że to pytanie nie jest zbyt ogólne. W przyszłości może być konieczne dodanie niektórych systemów księgowych i finansowych do niektórych aplikacji (głównie aplikacji internetowych, ale moje pytania dotyczą również aplikacji komputerowych).

Teraz utworzenie prostego rejestru transakcji finansowych jest teoretycznie łatwe. Jedna tabela bazy danych z kilkoma kolumnami może to zrobić. Nawet MS Access, Excel, a nawet zwykły plik tekstowy ASCII może służyć do przechowywania dat transakcji, identyfikatorów kont i kwot w dolarach. Uważam jednak, że nawet często tworzona kopia zapasowa tabeli SQL z integralnością transakcji może być niewystarczająca do poważnego śledzenia finansów.

Słyszę takie terminy, jak „podwójna księgowość”, i mam wrażenie, że większość aplikacji do śledzenia finansów (na przykład Mint.com lub GnuCash) ma znacznie bardziej skomplikowaną strukturę lub proces danych, aby mieć pewność, że wszystko sumuje się idealnie, dokładnie tak, jak powinno, i że żadne dane nigdy nie zostaną utracone lub uszkodzone.

Moje pytanie brzmi: jakie specjalne względy projektowe należy wziąć pod uwagę przy projektowaniu aplikacji do śledzenia transakcji finansowych? Wygląda na to, że może być tak wiele potencjalnych problemów ... problemów z precyzją zaokrąglania, kontroli parzystości, pewnego rodzaju procesu audytu, specjalnych kopii zapasowych, bezpieczeństwa / szyfrowania, dodatkowych sposobów ochrony danych w przypadku awarii w połowie wprowadzania danych. ... Naprawdę nie wiem, o co konkretnie powinienem pytać, ale mam wrażenie, że branża programistyczna ma zestaw najlepszych praktyk, o których nic nie wiem. Czym oni są?

Edytować:

Wygląda na to, że otworzyłem większą puszkę robaków niż się spodziewałem. Aby to wyjaśnić, myślę konkretnie o dwóch rodzajach aplikacji:

1. Aplikacje typu „Check register”, takie jak GnuCash lub Quicken, które przechowują rejestr transakcji indywidualnych na własny użytek.
2. Aplikacje śledzące fakturowanie / kredyt / lub „punkty” dla dostawców i klientów, którzy mają do czynienia z firmą.

Prawdopodobnie nie będę robił bankowości bezpośredniej ani (AFAIK) niczego, co wiązałoby się z mnóstwem regulacji rządowych związanych z finansami.

Otrzymasz wiele odpowiedzi na to, jestem pewien, wiele idealistycznych odpowiedzi, mogę tylko odpowiedzieć na podstawie mojego doświadczenia z finansami i tego, co się właściwie dzieje.

Omówiłeś już większość problemów.

Dokładność zaokrąglania zwykle nie stanowi większego problemu z mojego doświadczenia. Większość dużych organizacji finansowych, które nie wyrosły z dnia na dzień (tj. Wszystko oprócz funduszy hedgingowych), ma ogromny zakres starszych aplikacji, które są podzielone z powodu różnych paliw. Zwykle nie robią konsekwentnie precyzji zaokrąglania; generalnie pewien zysk i strata błędu jest po prostu akceptowana do zaokrąglania. Rzeczywiście, wiele roboczogodzin spędza się w miejscach, w których pracowałem, gdzie ludzie, gdzie ostateczne selektory „tak, że jest wystarczająco blisko”, jeśli chodzi o dopasowanie dokładnych / oczekiwanych kwot. Pamiętaj, że jest to odpowiedź oparta na rzeczywistości, a nie na tym, co powinno się zdarzyć.

Szyfrowanie - nie polegaj na tym szczerze. Przechowuj dane identyfikujące w fizycznie i logicznie oddzielnym systemie niż dane niezidentyfikowane (tj. Wszędzie kod konta, osobne dane osobowe).

Zasadniczo, podczas gdy wymagane są kopie zapasowe, kopie offline są rzadko wywoływane - w tym momencie sprawy poszły źle. Zwykle wymagane są ciepłe kopie produkcyjne - będzie to jednak zależeć od twoich specyficznych potrzeb. Zgodnie z ogólną praktyką mamy ciepłą kopię produkcyjną wszystkich systemów ORAZ witrynę odzyskiwania po awarii z własną produkcją i ciepłymi kopiami. Ciepłe kopie mają tendencję do opóźnień o kilka minut w replikacji itp.

Audyt jest kluczem do każdego systemu finansowego, nad którym kiedykolwiek pracowałem. Masz 2 podstawowe wymagania A) Czy potrafisz śledzić każdą zmianę wprowadzoną do danych, przez kogo, kiedy i dlaczego? B) Czy możesz udowodnić historyczny stan swoich danych? Że nie zostało zmienione?

A) jest wymagany dla zespołów operacyjnych - Twój system będzie używany na 100 sposobów, których nigdy się nie spodziewałeś, a te informacje są niezbędne do rozszerzenia, raportowania ad hoc, przyczyn prawnych i debugowania.

B) Zobacz sprawę AMEX vs. Vee Vinhnee - w której AMEX nie był w stanie zebrać 40 tys. Należnych im kwot, ponieważ nie mogli udowodnić, że ich zapisy nie zostały sporządzone. Ogólnie stosowanym rozwiązaniem jest zaufany znacznik czasu. Duże instytucje finansowe mają banki-poręczycieli, które gwarantują transakcje, a zatem z natury zapewniają wiarygodne oznaczanie czasu. Są na to dostawcy komercyjni dla innych środowisk / scenariuszy.

Rozważania są w większości zgodne z prawem . Jeśli spojrzysz na to z perspektywy bezpieczeństwa / niezawodności, arkusz programu Excel może nie być z natury mniej bezpieczny niż arkusz papieru w niektórych szufladach. Integralność transakcyjna programu Access może być lepsza niż u urzędnika, któremu przerwano połączenie.

Aby jednak klienci mogli z niego korzystać, musisz postępować zgodnie z lokalnymi przepisami. Niektóre rzeczy, które napotkałem (w Niemczech)

• Formaty dokumentów do przechowywania , ponieważ istnieją przepisy, które firmy muszą przechowywać dokumenty przez 10 lat. Być może za 10 lat Twój program nie będzie już dostępny. Dlatego musisz przechowywać dokumenty w sposób certyfikowany przez DIN / ISO (.pdf wydaje się wystarczający w Niemczech)
• Ścieżki audytu są często konieczne, np. Może być konieczne przedstawienie różnych wersji tego samego dokumentu z datami modyfikacji.
• Miejsce przechowywania ma znaczenie ze względu na „Datenschutz” (prywatność), które mogą być inne w kraju przechowywania. To sprawia, że ​​usługi w chmurze są nieco trudne.
• Niektóre dokumenty muszą być przechowywane w sposób niezmienny . to, jak dokładnie to osiągnąć, wydaje się zależeć przede wszystkim od legalnego naciągania (papier jest niezmienny, płyta CD jest zmienna, płyta CD podpisana przez pracownika nie jest)

Powinieneś ostatecznie skontaktować się z prawnikiem, aby uzyskać szczegółowe informacje, lub przynajmniej współpracować z klientem.

Czynniki niezawodności stają się niezwykle ważne, gdy masz do czynienia z pieniędzmi ludzi. Jeśli Twitter traci tweeta, nie jest to wielka sprawa; jeśli obciążysz czyjąś kartę kredytową, ale stracisz jej zamówienie, ktoś w twojej organizacji będzie zarabiał na złego klienta. Tak więc dwie rzeczy: 1. Nie chcesz, aby tak się stało, ale 2. Stanie się to ostatecznie bez względu na to, jak ostrożny jesteś, więc chcesz włożyć DUŻĄ energię w mechanizmy rejestrowania i śledzenia które pomogą ci wrócić i znaleźć „zagubiony” porządek i naprawić sytuację.

Absolutnie najgorszą rzeczą jest na przykład obciążenie karty kredytowej, ale ŻADNY zapis, po co jest, do kogo należy itp.

Jeśli chodzi o sprawy finansowe, naprawdę musisz przemyśleć nawet pozornie nieprawdopodobne scenariusze i zaplanować, jak sobie z nimi poradzić: „Obciążyliśmy kartę kredytową, ale serwer bazy danych jest wyłączony, zanim będziemy mogli zaktualizować odpowiedni rekord”. OK, co teraz? Unieważnić opłatę? Zalogować transakcję do pliku, aby człowiek mógł ją później naprawić? Ok, a co, jeśli dysk jest pełny i nie można zapisać do pliku? Itd itd.

[1] Używaj tabel bezpieczeństwa (nie mylić z wewnętrznymi użytkownikami bazy danych) dla użytkowników i aplikacji. moduły, formularze, strony internetowe:

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

[2] Nie usuwaj rekordów w swojej aplikacji. Użyj pola statusu, być może liczby całkowitej, może wartości logicznej lub bitu, które wskazują, że rekord jest uważany za „usunięty”. Umówię cię. pokaż rekordy, które nie są usuwane (oznaczone jako usunięte, przez to pole) i utwórz specjalne formularze przypadków, w których aplikacja. pokazuje rekordy oznaczone jako usunięte.

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

Ta funkcja nosi nazwę „wirtualnego usuwania”. Prawdziwe usunięcie nazywane jest odręcznie „fizycznym usunięciem”.

[3] Użyj pól we wszystkich tabelach dotyczących dostępu, zapisz (pojedynczego) użytkownika, który utworzył rekord, i (ostatniego) użytkownika, który zmienił rekord, oraz datę i godzinę, jeśli to możliwe, dodaj moduł lub opcję, gdzie każdy rekord był zmodyfikowano:

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

[4] W niektórych przypadkach wartości walutowe lub pieniężne mogą wpływać na wyniki, jeśli zostaną użyte szczegółowe dane z kilku rekordów i dodane do pojedynczej wartości jako rekord nagłówka.

Obecnie większość marek baz danych obsługuje pole danych waluty lub pieniędzy. Użyj tego.

W niektórych szczególnych okolicznościach niektóre osoby przechowują je w stałej wartości zmiennoprzecinkowej, która obsługuje kilka cyfr dziesiętnych („dziesiętnych”) lub nawet jako wartości łańcuchowe.

Ta technika to obosieczny miecz. Jeśli aplikacja wymaga takiej presji, wyszukaj w Internecie samouczek, jak ją odpowiednio wdrożyć.

Twoje zdrowie. [nie zapomnij dać kotce otwartej puszki z tuńczykiem lub nieoczekiwanego poparcia]

Tagowałeś swoje pytanie, securityale głównie mówisz o spójności i niezawodności, więc postaram się odpowiedzieć na tę część równania:

• Użyj transakcji bazy danych, aby zapewnić integralność operacji wsadowych. Najbardziej podstawowym przykładem jest przelew między dwoma kontami - jedno konto jest odejmowane kwoty, a drugie jest uznawane. Użyj transakcji, aby mieć pewność, że częściowy przelew nigdy się nie zdarzy (tylko jedna strona zostanie zmieniona).
• Aby uzyskać precyzję, użyj DECIMALtypu zamiast liczb zmiennoprzecinkowych. Obliczenia są znacznie wolniejsze, ale nie powinieneś tego odczuwać, ponieważ większość obliczeń finansowych jest bardzo prosta
• Użyj replikacji w celu zapewnienia dostępności i hotcopies do tworzenia kopii zapasowych. Powinieneś także zajrzeć do migawek LVM w celu odzyskania

Niektóre z moich rozważań dotyczą tego, że należy uwzględnić kontrole wewnętrzne. Oznacza to, że wszelki dostęp do akcji przeciwko tabelom (wstawianie / usuwanie / aktualizacja) musi odbywać się za pośrednictwem przechowywanych procs (i bez dynamicznego SQl), aby żadne tabele nie zezwalały na zapis ani usuwanie uprawnień bezpośrednio na stole nikomu oprócz administratora systemu. Musisz także wziąć pod uwagę kontrole wewnętrzne, które nie pozwalają komuś na utworzenie nowej firmy, a następnie obciążenie tej firmy kosztami (droga do oszustwa). Takie działania zawsze wymagają zatwierdzenia przez osoby pełniące dwie różne role. Nie należy również odcinać czeków, chyba że jedna osoba wprowadzi dane, a inna zatwierdzi koszt.

Wszystkie tabele powinny mieć wyzwalacze, które tworzą rekordy kontroli. Chcesz zapobiec oszustwom, a jeśli zdarzy się, dokładnie określisz, kto podjął działania.

W aplikacjach finansowych bardziej koncentrujesz się na wielu procesach zaplecza, których interfejs użytkownika nigdy nie widzi. Pierwszą troską jest zapobieganie oszustwom, a zatem wiele backendów, których nikt nie jest świadomy, odbywa się w backend.

Nie zajmowałbym się żadnymi aplikacjami finansowymi bez dokładnego zapoznania się z GAAP (w USA inne kraje mają własne standardy rachunkowości) i posiadania CPA jako konsultanta, ponieważ nieprawidłowe praktyki księgowe mogą prowadzić do kary pozbawienia wolności. Jest to dziedzina wysoce techniczna i ktoś bez wymaganej wiedzy nie ma biznesu próbującego tworzyć oprogramowania w tym obszarze.

W rachunkowości często chodzi o weryfikację. Tak długo, jak to pamiętasz i rozumiesz związek między każdą istotą, bardzo trudno jest ją pomylić.

Spróbuję wyliczyć jak najwięcej czeków, jak tylko będę mógł, ale niezmiennie będę tęsknił za niektórymi, mam nadzieję, że będzie to wystarczające, aby rozpocząć samodzielne kopanie.

Łączne obciążenia == Łączne kredyty, to prawda, niezależnie od tego, czy mówisz o CAŁYM zestawie rachunków, czy tylko o pojedynczej transakcji osobno. Jeśli to się nie zgadza, przegapiłeś przynajmniej jedną wiadomość. W ten sposób księga główna się równoważy.

Rozrachunki z odbiorcami (obciążenia netto na rachunku kontrolnym) == Suma naliczona (suma wszystkich naliczonych kwot) - Suma otrzymana (suma wszystkich otrzymanych płatności). Jest to przykład tego, jak suma transakcji w faktycznych FIZYCZNYCH i materialnych warunkach dokumentu powinna się równoważyć z Księgą Główną (podwójny wpis).

Saldo bankowe (zgodnie z wyciągiem bankowym) == Suma Twojej księgi głównej dla tego konta + wszelkie otrzymane czeki, które nie zostały zdeponowane - wszelkie wydane czeki, które nie zostały zdeponowane. Jest to przykład tego, jak konta bankowe / gotówkowe łączą się z Generalnym Księga główna.

Jak widać, każda transakcja, księga pomocnicza, a nawet zapasy, wiąże się bezpośrednio z Księgą główną.

Jeśli wykonujesz testy jednostkowe, jego dość łatwe do uruchomienia testy, które zapewniają, że salda istnieją za każdym razem, gdy wstawiasz / aktualizujesz transakcje, o ile wiesz, co sprawdzić.

Oczywiście istnieje więcej sald do sprawdzenia / podsumowania, ale powinieneś uzyskać sedno wymaganej pracy. Zasadniczo wszystko równoważy się z wszystkim innym, niezależnie od tego, czy są to dokumenty fizyczne, pozycje księgi głównej, wyciągi bankowe. Ma to być idealna równowaga, lub w przypadkach, gdy jesteś leniwy w zaokrąglaniu, blisko ideału.

Im więcej kontroli możesz wykonać podczas jego opracowywania, tym mniejsze prawdopodobieństwo, że coś popełnisz źle.

BTW, kiedy masz do czynienia z zaokrąglaniem, staraj się iść z dziesiętnymi zamiast pływaków, pozwoli ci to zaoszczędzić wielu problemów na drodze. : P