Двойная учетная база данных

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

Давайте рассмотрим пример и посмотрим, как это будет реализовано в обоих сценариях.

Рассмотрим учетную запись Cashи учетную запись Rent. Оплачивая ежемесячную арендную плату, я перечисляю 100 долларов со своего Cashсчета на свой Rentсчет.

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

В однорядной системе такая транзакция будет храниться как:

операции

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

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

Две строки на транзакцию

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

операции

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

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 долларов.
• Сейчас я делаю примирение и хочу исправить эту опечатку. Как бы это исправить в базе данных? Я не знаю связи между записями, и в случае разделения одна транзакция может иметь более двух записей. Единственное решение, которое я придумала, - это добавить несколько ref_idдля каждой пары записей, которые будут однозначно идентифицировать эти записи как "противоположные стороны друг друга" в контексте определенного tx_id.

Какой подход лучше / проще?

Чтобы упростить мой вопрос: я хочу представить движение средств со счета A на счет B. Оба приведенных мною сценария представляют собой допустимые варианты хранения такой транзакции. Как я также отметил, у них обоих есть свои минусы и плюсы (первый: легче сохранить, труднее найти; второй - наоборот).

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

Действительно, предложенная схема учета в одну строку позволяет вести надлежащий учет с двойной записью (всегда указывать дебетованный и зачисляемый счет) без введения избыточности данных «сумма».

Схема с одной строкой дает вам реализацию двойной записи, которая балансирует по построению, так что невозможно «потерять баланс». Машина может пересчитать бухгалтерские книги на лету.

Вы должны сделать 2 выбора вместо одного, чтобы получить книгу.

Обратите внимание, что помимо разделения транзакции существуют и другие транзакции, например, обмен валюты может закончиться 2 записями вместо 4. Все зависит от того, хотите ли вы денормализовать бит, просто введите 4 транзакции с аналогичным описанием.

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

Похоже, что в приведенной выше теме для CPA «полностью нормализованный», по-видимому, означает правила, признанные всеми бухгалтерами, в то время как для программиста это имеет другое значение, что не хранятся производные или избыточные данные.

Все, что есть в учетных данных, - это набор транзакций, которые дают сумму и счета, с которых и на которые они поступают, вместе с их датой, некоторым описанием (и другими приложениями). Главные книги и балансы - это простые представления, полученные из этих данных транзакций путем суммирования.

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

Обратите внимание, что каждая строка представляет собой одну транзакцию, с Total Debits = Total Credits; и что каждая транзакция попадает в одни и те же три аккаунта. Cash Sales Journal будет выглядеть аналогично , но вместо столбца Дебиторская задолженность дебет с одной меченой Cash дебет . Выдачи наличных денежных средств Журнал будет иметь первый столбец с надписью Cash Credit и дополнительные колонки , такие как кредиторская задолженность Дебет и Расходы сотрудников дебет .

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

Легко видеть, что эта бумажная модель имеет существенные недостатки при буквальном переводе в автоматизированную систему:

1. Структура данных является основной, в то время как опыт показывает, что гораздо проще (также более надежным и легко проверяемым) программировать против свернутой структуры данных; а также
2. Поскольку каждый специализированный журнал использует различный набор учетных записей, каждый такой журнал должен быть спроектирован и запрограммирован отдельно, что является расточительным и подверженным ошибкам действием.

По этим причинам обычно рекомендуется использовать дизайн специализированных журналов в качестве интерфейса к системе бухгалтерского учета, но при разработке структуры данных, которая может быть числовым хранилищем для нескольких журналов. В современной СУБД это имеет потенциальное преимущество, заключающееся в том , что главная книга и даже специализированные вспомогательные книги могут стать индексированными представлениями в журнале, что полностью устраняет необходимость кодировать процесс публикации (этап, на котором транзакция журнала блокируется и имеет свою учетную запись). итоги переписаны в различные бухгалтерские книги).

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

Я хочу сказать, что оба подхода, которые вы предлагаете, являются ненадежными механизмами двойной бухгалтерии. Первый пункт: Журналы - это таблицы с однократной записью по очень веским причинам. Иногда две виртуальные таблицы « Ожидающие записи» и «Опубликованные записи» размещаются в одной структуре данных, но бит « IsPosted» всегда доступен только для записи, и система должна обеспечивать сохранение только для чтения записей «Опубликованные записи».

То, как бухгалтеры размещали записи в журналах за последние 800 лет , полностью нормализовано . Единственное различие между бумажным представлением и звуковым электронным представлением состоит в том, что в последнем случае удобнее сложенная структура таблицы, а в первом - структура поворотного стола, которая исторически была наиболее значимой, когда требовалась высокопараллельная обработка, т.е. каждый клерк ведение единого или небольшого количества специализированных журналов. Исторически только Контроллер имел разрешения на Общий Журнал.

Обратите внимание, что в приведенном выше я указал, что записи в журнале полностью нормализованы; Записи в журнале - это хронологическая запись всех транзакций, сгруппированных в журналах, специфичных для каждого типа транзакций. Проводки из журнальных записей в регистры бухгалтерского учета представляет собой отдельный процесс , и, в то время как полностью нормализованы по себе, является излишней копией записей журнала , где суммированы все операции (General Ledger) или детальным (Sub Ledger) по счету. И Журналы, и Леджерс ведут двойную бухгалтерию самостоятельно.

@Codism Любая учетная система, DEB или SEB, предоставляет вам обобщенную отчетность для всех зарегистрированных учетных записей . Обратите внимание, что внутри ведомая книга по определению является бухгалтерской записью с одной записью; другая сторона - это соответствующий контрольный счет (ы) в балансе. DEB гарантирует, что для каждого доллара актива существует точная запись о требованиях бизнеса к активу , т. Е. О доле в активе, будь то заемный капитал (или пассив) или о собственном капитале , и о приоритетности этих требований, если организация становится несостоятельной.

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

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

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

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

У меня есть система, которая выполняет двойные линии и имеет множество проблем, чем наличие однострочных учетных записей. Сначала я столкнулся с случаями, когда только одна строка была нажата как дебетовая сторона, что привело к несбалансированному счету. Даже если я не выполняю надлежащий контроль за фиксацией и откатами, этого не произойдет в одной строке аккаунта. наконец, ваш БД растет в два раза быстрее, ваша вторая строка отправки будет содержать много дублирующейся информации, единственное отличие будет во втором аккаунте. Посоветовал бы сохранить однострочный аккаунт, собираюсь по этому маршруту ..