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

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

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

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

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

4
Abhishiv Saxena 13 Июл 2009 в 00:18

4 ответа

Лучший ответ

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

Правильным должно быть следующее: Списание 29 с Консультации и бухгалтерского учета и Списание 2.39 с налога с продаж. (в случае, если это Налог, который вы должны заплатить как потребитель), затем Зачисление 31,39 от AP,

Обычно AP будет на стороне кредита, за исключением случаев, когда вы вносите платеж. Тогда транзакция будет: Списание xx.xx с AP, затем Credit xx.xx из Cash / Bank.

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

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

2
Viruch HemapanpairoViruch Hemapanpairo 13 Июл 2009 в 00:07

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

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

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

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

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

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

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

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

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

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

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

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

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

HTH.

1
blispr 12 Июл 2009 в 20:41

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

2
bignose 13 Сен 2012 в 08:02

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

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

2
duffymo 12 Июл 2009 в 21:20