Дизайн бази даних з подвійним записом

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

Візьмемо приклад і подивимось, як це було б реалізовано в обох сценаріях.

Розгляньте рахунок Cashта рахунок Rent. Коли я плачу щомісячну оренду, я перераховую 100 доларів з мого Cashрахунку на мій Rentрахунок.

Один рядок на транзакцію

У системі з одним рядком така транзакція зберігатиметься як:

транзакцій

 tx_id | posting_date
 1     | 23/05/2015

транзакції

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

Два ряди за транзакцією

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

транзакцій

 tx_id | posting_date
 1     | 23/05/2015

транзакції

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

Проблема

Перш за все, я хотів би зазначити: причина, що у мене є transactionsі transaction_recordsтаблиці, і замість однієї таблиці, - це можливість обробляти розділені транзакції (випадок, коли я перераховую 100 доларів з Cashакаунта на два чи більше різних рахунки).

Спочатку я намагався реалізувати це з одним рядком на транзакцію, але болісно обчислити залишок на рахунку та фактично отримати дані.

Я схиляюся до другого сценарію; Однак у нього також є деякі проблеми:

• Як оновити один запис? Припускаючи, що я помилився, і замість того, щоб записати 100 доларів за оренду, я записав 10 доларів. Зараз у мене є 2 transaction_records- один на кредит і один на дебет, обидва на суму 10 доларів.
• Тепер я примирююся і хочу виправити цю помилку. Як я можу це виправити в базі даних? Я не знаю зв'язку між записами, і в разі розбиття, одна транзакція може мати більше 2 записів. Єдине рішення, яке я придумав, - це додати декілька ref_idдля кожної пари записів, які однозначно ідентифікують ці записи як "протилежні сторони один одного" всередині конкретного контексту tx_id.

Який підхід кращий / простіший?

Щоб спростити моє запитання: я хочу відобразити рух коштів з рахунку А на рахунок B. Два сценарії, які я дав, є дійсними конструкціями для зберігання такої транзакції. Як я також зазначив, у обох є мінуси (перші - легше зберегти, складніше отримати; друге - навпаки).

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

Дійсно, запропонована схема обліку в одній рядці дозволяє вести належний облік з подвійним записом (завжди вказувати рахунок, що списується та зараховується), не вносячи надмірність даних про "суму".

Схема з одним рядком дає вам реалізацію подвійного запису, який врівноважує за побудовою, так що неможливо коли-небудь "втратити баланс". Машина може перерахувати книги на льоту.

Для отримання книги слід зробити 2 вибору замість одного.

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

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

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

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

Журнал представляє собою хронологічний перелік усіх операцій певного типу для системи обліку. Ось класична презентація на головному папері простого журналу продажів (на рахунку):

Зауважте, що кожен рядок - це одна операція, із загальним дебетом = загальна сума кредитів; і що кожна транзакція потрапляє на ті самі три рахунки. Cash Sales Journal буде виглядати аналогічно , але замість стовпчика Дебіторська заборгованість дебет з одного міченої Cash дебет . Видачі готівкових коштів Журнал матиме перший стовпець з написом Cash Credit і додаткові колонки , такі як кредиторська заборгованість Дебет і Витрати співробітників дебет .

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

Неважко помітити, що ця паперова модель має суттєві недоліки, коли вона буквально переписана на автоматизовану систему:

1. Структура даних є суцільною, тоді як досвід показав, що програмувати проти складеної структури даних набагато простіше (також надійніше і легше перевірити); і
2. Оскільки кожен спеціалізований журнал має різний набір облікових записів, кожен такий Журнал повинен бути окремо розроблений і запрограмований, марно і не схильний до помилок.

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

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

Моя думка полягає в тому, що обидва запропоновані вами підходи - це непровідні механізми ведення бухгалтерського обліку з подвійним записом. Перший пункт: Журнали - це таблиці, що колись записуються, з дуже поважних причин. Іноді дві віртуальні таблиці очікувані записи та опубліковані записи розміщуються в одній структурі даних, але IsPosted біт завжди лише для запису, і система повинна забезпечити збереження характеру записів опублікованих записів лише для читання.

Те, як бухгалтери розміщували записи журналів за останні 800 років , повністю нормалізується . Єдина відмінність між паперовою презентацією та звуковою електронною презентацією полягає в тому, що складена структура таблиці зручніше в останньому випадку, тоді як складена структура таблиці в першому, яка історично була найбільш істотною, коли була потрібна високопаралельна обробка - тобто багато чиновників кожен ведення однієї або невеликої кількості спеціалізованих журналів. Лише Контролер історично мав дозволи для Загального журналу.

Уважно зауважте, що у вищесказаному я вказав, що записи журналів повністю нормалізовані; Записи журналу - це хронологічний запис усіх транзакцій, згрупований у Журналах, характерних для кожного типу транзакцій. Проведення з журнальних записів в регістри бухгалтерського обліку представляє собою окремий процес , і, в той час як повністю нормалізовані по собі, є зайвою копією записів журналу , де підсумовані всі операції (General Ledger) або детальним (Sub Ledger) за рахунком. І журнали, і журнали ведуть незалежне ведення бухгалтерського обліку.

@Codism Будь-яка система обліку, DEB або SEB, дає вам узагальнену звітність за всіма записаними рахунками . Зауважте, що внутрішньо субреєстр є за визначенням записом бухгалтерського обліку з одним записом; інша сторона - відповідні контрольні рахунки в балансі. ДЕБ гарантує, що для кожного долара активу існує точний запис вимоги щодо бізнесу на актив , тобто власний капітал в активі, будь то борговий капітал (він також зобов'язаний) або власний капітал , а також пріоритет цих вимог, якщо організація стає неплатоспроможною.

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

Google " програмне забезпечення для обліку з подвійним кодом з відкритим кодом " дає кілька перспективних напрямків розслідування.

Ви можете ознайомитись із пакетом бухгалтерського обліку GNU тут , декількома сайтами з огляду ( 1 та 2 ) та нарешті вікі бухгалтерського програмного забезпечення з розділом про вільне програмне забезпечення.

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

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