Система бухгалтерского учета и базы данных

Question

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

Вот экспорт из этой системы учета:

Взгляните на журнал 326. Хотя сумма суммы в этом случае = 0, сумма кредитов не равна сумме дебетов (дебетование 29 из Консалтинг и бухгалтерский учет (E), дебетование 31,39 из AP (L) ) и зачисление 2,39 в налог с продаж (L)).

Однако, если я смотрю на него как на дебит -31,39 от AP, это так. Однако я не уверен, что мы можем кредитовать / дебетовать отрицательные значения.

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

Answer 1

Проверьте SQL-Ledger , система учета свободного программного обеспечения, реализованная с Perl и PostgreSQL. Должен дать вам рабочий пример. (Я не имею к ним никакого отношения, но я использовал его раньше, и это было удовлетворительно для базового учета.)

Answer 2

Мартина Фаулера "Шаблоны анализа" содержит хорошую главу по моделированию систем бухгалтерского учета. Может быть, это может помочь вам.

Я думаю, вам лучше подумать о проблеме с точки зрения объектов, чем пытаться отобразить ее в реляционной базе данных. Базы данных являются декларативными и основаны на множествах; объекты инкапсулируют данные с помощью операций в компонентах. Я думаю, что последний лучше подойдет для моделирования бухгалтерского учета, особенно если вы сочетаете его с аспектно-ориентированным программированием. Пусть база данных будет таким, каким вы сохраняете вещи и сохраняете логику на среднем уровне.

Answer 3

Я думаю, что проблема транзакции 326, о которой вы упомянули, заключается в том, что вы, по-видимому, поступили не с дебетовых / кредитных позиций.

Правильный должен быть такой: Снятие 29 с Консалтинга и учета, и Отчисление 2,39 от налога с продаж. (в случае, если это налог, который вы должны заплатить как потребитель) затем кредитование 31,39 от AP,

Обычно, AP будет на Кредитной стороне, кроме тех случаев, когда вы рассчитываете свой платеж. Тогда сделка будет Дебетирование xx.xx с AP, затем кредит xx.xx с Cash / Bank

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

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

Answer 4

То, что я собираюсь обрисовать, это из памяти, и вполне возможно, что это «старомодный» способ представления счетов.

** Определение дебета - любое или все из этих условий **

1. Увеличение актива (например, всякий раз, когда вы выставляете счет кому-либо)
2. Увеличение расходов (покупка стационарных)

** Определение кредита - любое или все из этих условий **

1. Увеличение дохода или уменьшение актива
2. Увеличение ответственности

В таблице вашей учетной записи вы можете иметь столбец типа флага, который называется «Нормальный баланс» или «Типовой баланс» -

• для счета дебиторской задолженности - обычный баланс "D" или дебет.
• для счета, подлежащего оплате, с обычным балансом "C" или кредитом.

Всякий раз, когда происходит транзакция счета-фактуры - она ​​проводит по AR (дебиторская задолженность) - и проводит «нормальный баланс», т. Е. Она рассматривается как сумма дебета.

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

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

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

Точно так же ваша модель платежной транзакции или контроллера платежей знает, что она отправит кредит против AR.

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

НТН.