Бухгалтерский учет и дизайн базы данных, хранение дебетовых и кредитных сумм

Question

ВОПРОС: В приведенном ниже случае я должен хранить всю свою сумму как положительные десятичные суммы, а затем помечать сумму как «дебетовую» или «кредитную» вместо хранения дебетов в качестве отрицательной суммы и кредитов в качестве положительной суммы?

---

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

Теперь в отчетах иногда результаты оказываются неверными, потому что если вы сделаете это

TotalAmount = Сумма-комиссия, и если сумма снятия составляет $ 100, а комиссия составляет $ 1.

В итоге вы получите - $ 100- $ 1 = - $ 101, что является неверным результатом !.

Answer 1

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

Любая бухгалтерская транзакция должна содержать равное количество дебетов и кредитов. Если это не так, это недействительная транзакция.

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

Другой способ взглянуть на это состоит в том, чтобы рассматривать учетную стоимость как комплексное число, где дебеты являются реальными, а кредиты - воображаемыми. Это означает, что 4 дебета + 3 кредита = 4 + 3i. Это делает очевидным, что вы не можете еще больше упростить, свернув воображаемый термин в отрицательный реальный термин - это не та же ось числовой линии. Это было бы то же самое, что утверждать, что 4 + 3i = 4 - 3. Недействительная математика.

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

P.S .: Я знаю, что некоторые люди используют отрицательные для кредитов и положительные для дебетов, но это требует большой осторожности, чтобы делать правильно, и является хрупким. Вы должны следить за нормальным балансом любой учетной записи каждый раз, когда вы прикасаетесь к ней - например, поскольку у учетной записи актива есть дебетовое нормальное сальдо, вы можете использовать положительное число, чтобы увеличить его. Но у пассивного счета нормальное отрицательное сальдо, поэтому увеличение стоимости этого счета является отрицательным числом. Вы не можете суммировать эти два значения вместе в любое время - это не одно и то же. Дебет - это то, что у вас есть, а кредит - то, что вы должны. Помещение обоих в один столбец таблицы базы данных плохо пахнет.

Answer 2

Я работаю с бухгалтерской системой Sage Timberline, и она сохраняет дебеты как положительные суммы, а кредиты как отрицательные суммы.Во всех отчетах, включая пробный баланс, вы дебетуете + кредитуете.Затем вы делаете отрицательный дебет для отмены дебета и положительные кредиты для отмены кредита.Работает нормально

Answer 3

Поскольку учет ведется на основе записей в журнале, для вашей модели данных может быть лучше следовать этому.Это будет означать наличие двух столбцов в вашей таблице, один для дебета и один для кредита.Затем вы оставляете это на усмотрение приложения, чтобы определить, что следует считать «положительным» значением, а что - «отрицательным».(Всегда возникает вопрос - положительный, с чьей точки зрения? Когда вы переводите деньги между банковскими счетами, это «отрицательный» для одного счета, но «положительный» для другого.)

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

Answer 4

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

Чтобы ответить на вопрос: следует ли хранить значения в виде положительных сумм и пометить их какдебет или кредит?

Краткий ответ: вам не нужно добавлять флаг, потому что любая система автоматически применяет флаг «дебет» или «кредит», когда вы сохраняете номер в его правильной подписанной форме.Это знак «-».Стоит ли хранить значения в одном из двух столбцов, дебет или кредит?Точно нет !Зачем сохранять пустое поле для каждой транзакции в системе?Управлять отдельным столбцом с правильным значением со знаком гораздо проще.

Чем длиннее ответ на вопрос: «Учет и дизайн базы данных, хранение дебетовых и кредитных сумм».

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

Теперь рассмотрим счет-фактуру покупки, которую пользователь добавляет в систему.Допустим, у нас есть этот (маловероятный) счет-фактура для компании Widget:

£ 500 за стальной стержень

£ 100 за коробку с конвертами

£ 10000 за токарный станок

£ 2120 налог на покупку

£ 12720 общая сумма счета

Приложение записывает одну запись в таблицу документов.Он имеет ссылки «один ко многим» на таблицу транзакций.Для трехстрочного счета-фактуры приложение записывает 5 строк транзакции.

£ 500, связанных с себестоимостью продаж, счетом главной книги.Дебетовое сальдо = расход, когда в p & l

£ 100 связан с канцелярскими товарами, счетом главной книги p & l.Дебетовое сальдо = расходы, когда в p & l

£ 10000, связанном с Machinery, счет главной бухгалтерской книги.Дебетовое сальдо = актив, когда он указан в бс.

£ 2120 и связан с «Возмещаемым входным налогом», счетом в бс глДебетовое сальдо = актив, задолженность по налогам у налоговика

- 12720 фунтов стерлингов, привязанного к Creditors Control, счету bs gl.Кредитный баланс = обязательство, мы должны это поставщику

£ 0,00 общей стоимостью 5 записей, записанных в таблицу транзакций.

Теперь рассмотрим счет на продажу, который пользовательдобавляет:

£ 250 для премиум-виджетов

£ 250 для стандартных виджетов

£ 100 налог с продаж

£ 600 общая сумма счета

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

£ 250 - связано с Премиум продаж виджетов, аккаунтом p & l gl.Кредитный баланс = доход / прибыль, когда в p & l

£ 250 - связан со стандартным виджетом продаж, счетом p & l gl.Кредитный баланс = доход / прибыль, когда в p & l

£ 100 - связан с выплаченным налогом на прибыль, счет bs gl.Кредитный баланс = пассив в БС.Мы должны эти деньги налоговому управляющему.

£ 600, связанный с контролем дебиторов, аккаунтом bs gl.Дебетовое сальдо = актив, задолженность перед клиентом.

£ 0,00 общая стоимость 4 записей, записанных в таблицу транзакций.

Отличнохорошо, чтобы добавить отрицательные строки в счет-фактуру, если вы хотите отдать должное за что-то возвращено.Они просто поменялись местами со всеми остальными строками перед записью транзакций.Чаще всего вы выпускаете кредит-ноту, в которой строки записываются как дебеты в доход от продаж, уменьшая стоимость продаж в p & l.

Если система выполняет управление запасами, в транзакцию записываются количества.линии, и они связаны с таблицей Product.

Банковские записи часто выявляют не хранителей книг.Говорят, мы вкладываем деньги в наш банк, поэтому зачислили на счет.Думайте о банке как о человеке, внешнем по отношению к бизнесу.Когда вы передаете свои деньги на хранение, он становится должником и должен вернуть ваши деньги по требованию.Таким образом, поступления в банк отражаются как дебеты, а выплаты - как кредиты.Когда мы получаем платеж от клиента, мы пишем две строки транзакции:

£ 600, связанные с банковским счетом, счетом bs gl.Дебетовое сальдо = увеличивает стоимость актива, у нас больше денег.

£ 600 - связано с контролем должников, аккаунтом bs gl.Кредитный баланс = уменьшает стоимость актива, мы должны меньше денег.

£ 0,00 общая стоимость 2 записей, записанных в таблицу транзакций.

Если вы следуетев результате вы увидите, что в систему контроля должников записано 600 фунтов стерлингов при выставлении счета-фактуры, и 600 фунтов стерлингов при получении платежа.Чистый баланс = 0,00 фунтов стерлингов - вот что должен наш клиент.

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

И это все.Каждый раз, когда вы суммируете таблицу транзакций, она всегда должна возвращать ноль.Там нет необходимости поддерживать две колонки.Прикладная программа должна сделать две вещи, она должна быть закодирована так, чтобы она применяла правильную подпись к различным типам транзакций, и она должна представить транзакцию в одном из двух столбцов в зависимости от того, является ли она> 0 или <0.Таким образом, вы можете иметь свой пробный баланс, ваши бухгалтерские книги клиентов и поставщиков, банковские и кассовые счета, а также общую бухгалтерскую книгу, которые будут хорошо отформатированы в столбцы дебет и кредит. </p>

Создание системы, в которой обе стороны двойной записи записываются водна сделка привлекательна.В случае сбоя одной транзакции это не приводит к дисбалансу счетов.У вас все равно будет только один столбец для значения со знаком.Вы должны записать два внешних ключа gl для каждой транзакции, один для значения записанного вами, которое может быть положительным или отрицательным значением для представления дебета или кредита, и другой внешний ключ gl для записи учетной записи, которую вы публикуете.противоположное («двойная запись») значение для.Вам также может понадобиться записать gl fk для двух учетных записей налогового контроля, одного для контрольного счета выходного налога и одного для контрольного счета входного налога.Таким образом, вы можете в конечном итоге связать строку транзакции с четырьмя учетными записями gl вместо одной (плюс ссылки на таблицы клиентов, поставщиков и продуктов, которые применяются к обоим методам).Контрольные счета будут иметь очень большой объем транзакций, связанных с ними.С 10-строчным счетом будет связано 10 транзакций, а не одна на документ.Вам нужно будет рассчитать налоговый элемент для каждой строки счета-фактуры отдельно, а не как итог для документа (вы можете сделать это в любом случае).Наконец, вам потребуется специальное соглашение для документа записи журнала, которое может включать 10 строк в качестве дебетов, все смещаются на одну строку в качестве кредита, поэтому подход с одной транзакцией здесь не работает.

Answer 5

Вы можете использовать функцию ABS на сервере sql, чтобы получить абсолютное значение.Это позволит вам рассматривать отрицательные числа как положительные.

например:

select ABS(-100)

возвращает 100, а не -100.

Answer 6

Вот схема детализации транзакции из большой книги под названием «Книга ресурсов модели данных». Эта схема соответствует всем требованиям записи без использования двух столбцов.

PK TransactionID - int
PK TransactionDetailSequenceID - smallint
   Amount decimal
   CreditDebitFlag char(1)

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

Answer 7

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

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

Я не противсохранение -ve значений в базе данных при дебете в большинстве случаев, но сохранение + ve приводит к наименьшему количеству путаницы, даже в качестве программиста базы данных, потому что у нас всегда есть столбец с информацией (дебет или кредит) и кто когда-нибудь собирается писать кодможет легко преобразовать его на уровне приложения.

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

Я хочу подчеркнуть, что базу данных можно использовать с точки зрения компании или клиента, и теперь у компаний есть аналитики данных, которые думают как с точки зрения перспективы, так и после того, как мы сэкономим только +После того, как цифры станут легче запомнить,Кроме того, у нас уже есть флаг, чтобы узнать, что это за значение!