Увязка кредиторской задолженности и главной книги в схеме базы данных - PullRequest
3 голосов
/ 14 мая 2011

A 13 декабря 2010 г. был задан вопрос :

Я ищу стандартную логическую модель данных главной книги и кредиторской задолженности>. Существуют ли доступные модели бухгалтерских данных?

Кен Даунс ответил:

Выдержка:

Самым основным регистром является 3 таблицы: счета, партии и транзакции. Все транзакции> должны быть в пакете. Некоторые люди делают два столбца для дебетовых и кредитных, я всегда делал один> столбец с дебетами и кредитами с противоположными знаками.

Кредиторская задолженность также очень проста. В его основе лежит таблица поставщиков и таблица> ваучеров / счетов. Наконец-то сгенерирована таблица чеков ... После этого украсим по вкусу:)

Поскольку таблица счетов-фактур и чеков будет влиять на главную книгу, могу ли я считать, что каждому необходимо хранить уникальный номер партии? Будет ли схема отображать соотношение 1: 1 для таблиц invoice: batch и check: batch? Большое спасибо за ваш совет.

1 Ответ

2 голосов
/ 16 мая 2011

Здесь не будет никаких отношений 1: 1. Например, вы всегда можете оплатить несколько счетов в одной партии. Идея пакетной таблицы заключается в том, что это единая «единица работы» с точки зрения бухгалтерского учета, а не с точки зрения программирования.

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

Счета - это справочная таблица. Транзакции - это детали транзакции, в отличие от Batch, который является заголовком транзакции. Я согласен с Кеном Даунсом из вопроса @ OP о том, что достаточно одного поля суммы. Нет смысла в отдельных столбцах дебет и кредит. Эта идея пришла из мира бухгалтерского учета и полезна еще в тот день, когда вся арифметика была сделана вручную. В компьютеризированном сценарии эта идея анахронична и на самом деле вызывает больше проблем, чем стоит. Я не согласился бы с Кеном Даунсом, поскольку его дебеты и кредиты имеют противоположные признаки. Это верно в контексте определенного аккаунта, но счета разных типов будут иметь дебетование с положительными или отрицательными суммами в соответствии с правилами бухгалтерского учета. Активы и доходы идут в одном направлении, а обязательства и расходы идут в другом направлении. Будет ли число положительным или отрицательным в таблице транзакций, будет зависеть от того, к какому типу счетов относится транзакция.

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

Что касается чеков, ваучеров, счетов-фактур и всего остального - вы, вероятно, хотите, но не обязательно все это. Причиной их наличия является не строгое отслеживание остатка на счете, а скорее вся другая ориентировочная информация, которую вы можете хранить там. Вы можете хранить всю эту индикативную информацию в «тупом» текстовом поле таблицы партий (т.е. «памятка»). Вот как они это делали на старом высоком стуле, в козырьках и перьях. Однако наличие таблицы накладных поставщика удобно, поскольку она позволяет вам выполнять удобные операции, например запрашивать список всех накладных от конкретного поставщика. То же самое относится и к другим конкретным бизнес-объектам, таким как чеки, счета-фактуры (дебиторская задолженность), выписки и т. Д. И т. Д.

...