Які особливі міркування потрібні при розробці баз даних для ведення фінансових записів?

Сподіваюся, це питання не надто широке. У майбутньому мені може знадобитися додати деякі системи бухгалтерського обліку та фінансового відстеження до деяких додатків (в основному веб-додатків, але мої запитання стосуються і настільних додатків).

Тепер створити простий запис фінансових операцій теоретично просто. Одна таблиця бази даних з кількома стовпцями могла б виконати цю роботу. Навіть MS Access, Excel або навіть просто звичайний текстовий файл ASCII можуть використовуватися для зберігання дат транзакцій, ідентифікаторів рахунку та сум у доларах. Однак я вважаю, що навіть часто резервна таблиця SQL з цілісністю транзакцій може виявитися недостатньо надійною для серйозного відстеження фінансових результатів.

Я чую такі терміни, як "облік з подвійним записом", і я відчуваю, що більшість додатків для фінансового відстеження (наприклад, Mint.com або GnuCash) мають набагато складнішу структуру даних або процес, щоб переконатися, що все додає ідеально, точно так, як слід, і що жодні дані ніколи не втрачаються чи не псуються.

Моє запитання: Під час створення програми для відстеження фінансових операцій, які особливі дизайнерські міркування слід враховувати? Здається, що може виникнути стільки потенційних проблем ... проблеми з точністю округлення, перевірки паритету, якогось процесу аудиту, спеціальних резервних копій, безпеки / шифрування, додаткових способів захисту даних у разі аварійного посередництва введення даних. ... Я насправді не знаю, про що я конкретно прошу, але я відчуваю, що в галузі програмування є набір найкращих практик, про які я нічого не знаю. Хто вони?

Редагувати:

Схоже, я відкрив більшу банку глистів, ніж очікував. Для уточнення я думаю про два типи програм:

1. Програми типу "Перевірити реєстр" типу GnuCash або Quicken, які підтримують запис окремих транзакцій для власного використання.
2. Додатки, які відстежують виставлення рахунків / кредитів / або "балів" для постачальників та клієнтів, які мають справу з компанією.

Я, мабуть, не буду робити жодного прямого банкінгу чи (AFAIK) нічого, що має до нього приписану низку правил, пов'язаних з фінансуваннями.

Ви отримаєте багато відповідей на це, я впевнений, багато ідеалістичних відповідей теж, я можу відповісти лише зі свого досвіду роботи з фінансами та того, що відбувається насправді.

Ви вже висвітлювали більшість питань.

Точність округлення, як правило, не є великою проблемою в моєму досвіді. Більшість великих фінансових організацій, які не подорослішали протягом ночі (тобто все, крім хедж-фондів), мають величезний спектр застарілих додатків, які розщеплюються за рахунок різних видів палива. Вони, як правило, не роблять точності округлення послідовно; як правило, певна прибуток та збиток від помилок просто приймаються для округлення. Справді, багато годин людини проводиться в місцях, де я працював, де люди, де підбираються кінцеві «так, що є досить близькими», коли мова йде про відповідність точних / очікуваних сум. Пам'ятайте, це відповідь, заснована на реальності, а не на тому, що має статися.

Шифрування - не покладайтеся на нього відверто. Зберігати ідентифікаційні дані у фізично та логічно окремій системі, ніж деіндентифіковані дані (тобто код рахунку скрізь, особисті дані окремо).

Як правило, тоді як резервні копії потрібні, резервне копіювання в режимі офлайн рідко запускається - у цей момент все пішло не так. Теплі виробничі копії зазвичай потрібні - однак це залежатиме від ваших власних потреб. У загальній практиці у нас є тепла копія на виробництві всіх систем І АЕС із відновлення аварій з власним виробництвом та теплі копії. Теплі копії, як правило, відстають на кілька хвилин у реплікації тощо.

Аудит - це ключ до кожної фінансової системи, над якою я працював. У вас є 2 основні вимоги. А) Чи можете ви відстежувати кожну зміну, внесену до даних, ким, коли і чому? Б) Чи можете ви довести історичний стан своїх даних? Що його не підробляють?

A) необхідна для операційних команд - ваша система буде використовуватися 100 способів, яких ви ніколи не очікували, і ця інформація є життєво важливою для розширення, спеціальної звітності, юридичних причин та налагодження.

B) Дивіться справу AMEX проти Vee Vinhnee - де AMEX не змогла зібрати заборгованість їм 40 000, оскільки вони не змогли довести, що їхні записи не складалися. Зазвичай для цього використовується рішення, яке довіряє штампуванню часу. Великі фінансові ресурси мають банки-гарантії, які гарантують транзакції і, таким чином, забезпечують надійне відмітку часу. Для цього існують комерційні провайдери для інших напрямків життя / сценаріїв.

Міркування здебільшого правові . Якщо ви просто подивитесь на це з точки зору безпеки / надійності, лист excel може бути не менш безпечним, ніж аркуш паперу в якомусь ящику. Трансакційна цілісність доступу може бути кращою, ніж у діловода, якого перериває дзвінок.

Але для того, щоб вашим клієнтам було дозволено користуватися ним, ви повинні зробити це відповідно до місцевих законів. Деякі речі, з якими я стикався (у Німеччині)

• Формати документів для зберігання матерії , оскільки є закони, згідно з якими бізнес повинен зберігати свої документи протягом 10 років. Через 10 років, можливо, ваша програма більше не доступна. Тому вам потрібно зберігати документи сертифікованими DIN / ISO (схоже, що в Німеччині вистачає .pdf)
• Шляхи аудиту часто необхідні, наприклад, вам, можливо, доведеться представити різні версії одного і того ж документа з датами внесення змін.
• Місце зберігання має значення через "Datenschutz" (конфіденційність), який може відрізнятися в країні зберігання. Це робить хмарні сервіси трохи складними.
• Деякі документи повинні зберігатися без змін . як саме це досягається, мабуть, залежить, головним чином, від легалістичного заниження (папір непорушний, компакт-диск із змінними, компакт-диск за підписом працівника - ні)

Ви, безумовно, повинні зв’язатися з адвокатом, щоб отримати детальну інформацію, або принаймні працювати у тісному партнерстві із замовником.

Фактори надійності стають напрочуд важливими, коли ви маєте справу з грошима людей. Якщо Twitter втратить твіт, це не така вже й велика справа; якщо ви заряджаєте чиюсь кредитну карту, але втрачаєте їх замовлення, хтось із вашої організації збирається отримати від сердитого клієнта. Отже, дві речі: 1. Ви не хочете, щоб це сталося в першу чергу, але 2. це відбудеться в кінцевому рахунку, незалежно від того, наскільки ви обережні, тому ви хочете вкласти багато енергії у такі механізми реєстрації та відстеження. це допоможе вам повернутися назад і знайти «загублений» порядок і виправити ситуацію.

Абсолютно найгірше - мати, наприклад, плату за кредитну карту, але НЕ записувати, для чого вона потрібна, чи кому вона належить тощо.

Щодо фінансових речей, вам дійсно потрібно продумати навіть здаються надзвичайно неймовірні сценарії та планувати, як з ними впоратися: "Ми стягували кредитну карту, але сервер бази даних не працює, перш ніж ми зможемо оновити відповідний запис". Гаразд, що тепер? Анулювати звинувачення? Увійдіть транзакцію у файл, щоб людина могла це виправити пізніше? Гаразд, що робити, якщо диск наповнений, і ви не можете записати у файл? І т.д.

[1] Використовуйте таблиці безпеки (не плутайте з внутрішніми користувачами БД) для користувачів та для вашої програми. модулі, форми, веб-сторінки:

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

[2] Не видаляйте записи у вашій програмі. Використовуйте поле статусу, можливо ціле число, можливо булеве або бітове, що вказує на те, що запис вважається "видаленим". Зробити вам додаток. показувати записи, які не видаляються (позначені як видалені, у цьому полі), і робити деякі спеціальні форми, де додаток. показує записи, позначені як видалені.

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

Ця функція називається "віртуальне видалення". Справжнє видалення часто називається "фізичне видалення".

[3] Використовуйте поля у всіх таблицях, що стосуються доступу, зберігайте (одного) користувача, який створив запис, та (останнього) користувача, який змінив запис, та дату, якщо можливо, додайте модуль або параметр, де кожен запис був змінено:

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

[4] У деяких випадках значення валюти або грошей можуть впливати на результати, якщо детально використовувати декілька записів, і, додані в одне значення, в записи заголовка.

Цього дня більшість брендів баз даних підтримують валютне чи грошове поле. Використай це.

У деяких особливих обставинах деякі люди зберігають їх у фіксованому значенні з плаваючою комою, що підтримує кілька десяткових цифр ("десяткових") або навіть як рядкові значення.

Ця техніка - меч з двома кінцями. Якщо у вашій програмі потрібен такий тип подання, виконайте пошук в Інтернеті, щоб отримати навчальний посібник, як її правильно реалізувати.

Ура. [не забудьте дати відкритій котлету з тунцем кошеняти, або розмовляйте надбавками]

Ви позначили своє запитання, securityале ви в основному говорите про послідовність та надійність, тому я спробую відповісти на цю частину рівняння:

• Використовуйте транзакції бази даних для забезпечення цілісності пакетних операцій. Найбільш базовий приклад - переказ між двома рахунками - з одного рахунку віднімається сума, а з іншого зараховується. Використовуйте транзакції, щоб гарантувати, що часткова передача ніколи не відбувається (змінюється лише одна сторона).
• Для точності використовуйте DECIMALтип замість поплавців. Розрахунки набагато повільніше, але ви не повинні відчувати це, оскільки більшість фінансових розрахунків є дуже простими
• Використовуйте реплікацію для продовження часу та гарячі копії для резервного копіювання. Ви також повинні вивчити знімки LVM для відновлення

Я бачу деякі міркування, що ви повинні враховувати внутрішній контроль. Це означає, що весь доступ до дій проти таблиць (Вставка / видалення / оновлення) повинен здійснюватися через збережені програми (і ніяких динамічних SQl), щоб жодні таблиці не дозволяли записувати або видаляти права прямо на стіл нікому, крім системному адміністратору. Вам також доведеться враховувати внутрішні органи контролю, які не дозволяють комусь створити нову компанію, а потім стягувати товари з цієї компанії (маршрут шахрайства). Такі дії завжди потребують схвалення людей у ​​двох різних ролях. Також чеки не слід знімати, якщо одна людина не вводить дані, а інша не схвалює витрати.

Усі таблиці повинні мати тригери, які створюють записи аудиту. Ви шукаєте, щоб запобігти шахрайству, і якщо це трапиться, точно визначте, хто вчинив дії.

У фінансових додатках вас набагато більше турбує безліч зворотних процесів, які ніколи не бачать користувальницький інтерфейс. Ваше перше занепокоєння - запобігання шахрайству, і таким чином багато перевірок, про які ніхто не знає, були зроблені на початку.

Я б не вирішував будь-якого фінансового застосування, не читаючи GAAP (в США, інших країнах є свої бухгалтерські стандарти) та мати CPA як консультанта, оскільки неправильна бухгалтерська практика може призвести до в'язниці. Це високотехнологічна сфера, і хтось без необхідних знань не має жодного бізнесу, який намагається створити програмне забезпечення у цій галузі.

Бухгалтерський облік часто стосується перевірки. Поки ви пам’ятаєте це і розумієте відносини між кожною сутністю, досить важко зрозуміти це неправильно.

Я спробую перерахувати стільки перевірок, скільки можу, але незмінно пропущу деякі, сподіваюся, цього вам буде достатньо, щоб ви почали самостійно копати.

Загальна сума дебетів == Загальна сума кредитів, це правда, якщо ви говорите про ЦІЛЬКИЙ набір рахунків або лише одну транзакцію ізольовано. Якщо це не підходить, ви пропустили принаймні одну публікацію десь. Ось так балансує Генеральна книга.

Дебіторська заборгованість (чисті дебети на контрольний рахунок) == Загальна виставлена ​​сума (загальна сума всіх сум, що підлягають оплаті) - Загальна сума отриманих (загальна сума всіх отриманих платежів). Це приклад того, як загальна сума транзакції у фактичних ФІЗИЧНИХ та матеріальних умовах документа повинна співпадати з Загальною книгою (подвійний запис).

Баланс банку (згідно з вашою банківською випискою) == Загальна книга на цьому рахунку + всі отримані чеки, які не здаються на зберігання - незалежно від виданих чеків, які не зберігаються. Це приклад того, як банківські / касові рахунки порівнюються з Загальними Книга.

Як бачимо, кожна транзакція, допоміжна книга, навіть акція пов'язані безпосередньо з Генеральною книгою.

Якщо ви робите тестування одиниць, то досить легко запускати тести, які забезпечують існування цих балансів щоразу, коли ви вставляєте / оновлюєте транзакції, поки ви знаєте, на що потрібно перевірити.

Звичайно, є більше балансів для перевірки / підрахунку, але ви повинні отримати суть необхідної роботи. По суті, все врівноважується проти всього іншого, будь то фізичні документи, предмети Генеральної книги, банківські виписки. Це повинно бути ідеальним балансом, або у випадках, коли вам лінь працювати з округленням, близьким до ідеального.

Чим більше перевірок ви можете виконати під час свого розвитку, тим менше шансів отримати щось не так.

До речі, якщо ви маєте справу з округленням, спробуйте перейти з десятковою комою замість поплавців, це позбавить вас від багатьох головних болів у дорозі. : P