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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

£500 для стального адвокатского сословия

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

£10000 за станок

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

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

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

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

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

£ 10000, связанные с машинами, общий баланс счет ГК. Дебетовый баланс = актив, когда в bs.

£2120, связанный с возвратом входного налога, счет bs gl. Дебетовый баланс = актив, мы должны деньги налоговым

-£12720, связанный с контролем кредиторов, счет 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. Кредитный баланс = ответственность, когда в BS. Мы должны эти деньги налоговому инспектору.

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

£0.00 общая стоимость 4 записей в таблице транзакций.

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

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

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

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

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

£0.00 общая стоимость 2 записей в транзакции таблица.

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

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

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

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

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

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

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

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

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