as111Добрый день!

Вот такой вот вопрос.
Есть несколько счетов. Есть операция по снятию денег с одного счета на другой. Т.е. здесь расход, там приход. Как примерно проектировать такую схему? Соответсвенно интересует:
1. стоит ли сумму остатков фиксировать в самом счете или пусть всегда расчитывается?
2. На перевод денег с одного счета на другой делать одну запись в операциях или две? Если две то как их связать? Ну т.е. если отменяем, то чтобы отменилось и там и там.

Есть у кого простой пример?

Как это делал я:

1) сущность "счет" содержит ТЕКУЩИЙ остаток
2) для сущности "счет" определяются типы доступных операций (дебетный, кредитный, кредитно-дебетный)
3) определяется сущность "бухгалтерская проводка", которая содержит поля (в числе прочих)
a) "счет" (ссылается на сущность "счет")
б)"остаток ДО операции"
в) "оборот по дебету"
г) "оборот по кредиту"
д) "остаток ПОСЛЕ операции"
4) определяется сущность "транзакция", которая содержит ссылки (2 шт) на сущность "бухгалтерская проводка". Также не лишним будет добавить две ссылки на счета участвующие в транзакции (избыточность). Транзакция также содержит поле(возможно null) ссылающееся на сущность "бизнес-транзакция" - определяет принадлежность транзакции. Вообще, по большому счету эта сущность не особенно нужна и носит чисто вспомогательных характер

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

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

Так например, если потребности в дебетно-кредитных операций нет, то сущность "бухгалтерская проводка" может выглядеть так:
a) "счет" (ссылается на сущность "счет")
б) "корреспондирующий счет" (ссылается на сущность "счет")
в) "тип операции" (дебет/кредит)
г)"остаток ДО операции"
д) "оборот"
е) "остаток ПОСЛЕ операции"

обратите внимание - КАЖДАЯ транзакция все равно нуждается в ДВУХ проводках
Но лично мне такая организация категорически не нравится и на то есть серьезные причины

Из общих соображений могу выделить следующее:
1) Любая бухгалтерская операция должна содержать ДВЕ записи. (двойная запись это бухгалтерский идол... Впрочем, бухгалтеры чуть-чуть иначе понимают принцип двойной записи, но это практически эквивалент вышеописанного)
2) Текущий остаток просто обязан быть зафиксирован - он необходим для многих операций (проверка остатка например итд.)
3) остаток для произвольного счета на любое время и дату содержится в сущности "проводка"
4) при необходимости иметь значение НА КОНЕЦ ДНЯ вводится дополнительная сущность завершения финансового дня и соответствующая процедура. Так в банках есть операция "завершение операционного дня", которая (в числе прочего) фиксирует остатки на счетах
5) мне известны два способа реализации кредитных и дебентых операций. Первый это ровно так как об этом рассказывают бухгалтеры - в зависимости от того является счет дебетным или кредитным оборот по дебету и по кредиту меняет знак (тоесть, дебет будет прибавлять или отнимать от остатка сумму оборота в зависимости от того, является счет кредитным или дебетным). Второй способ это когда например остаток на кредитном счете является отрицательным (при демонстрации этого остатка пользователю он просто берется по модулю). Тогда дебетовые и кредитовые операции всегда будут иметь постоянный знак...
6) Обычно целостность данных обеспечивается средствами БД... Однако иногда могут потребоваться дополнительные меры по обеспечению этой самой целостности... Классическим случаем является операция блокировки счета... Применяется в частности в распределенных системах - перед совершением ЛЮБОЙ бизнес транзакции, все счета участвующие в ней сначала блокируются..

Вот так вот в целом... скучно конечно... выглядит неоправданно сложным но... это сложность таки оправданная

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

Программист-ЛюбительЕсть еще проблема с датами остатков и проводок при вводе чего-либо задним числом или при коррекции уже отработаных проводок. А в реальной практике это сплошь да рядом.

НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ не может быть никакой коррекции проводок "задним числом"!... Ошибки исправляются одним из двух способов:

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

2) Откат ВСЕХ проводок в обратном календарном порядке начиная с текущего момента вплоть до той проводки, которая является ошибочной. Ошибочная проводка изымается, вместо нее создается одна или несколько корректных проводок с использованием даты удаленной проводки, после чего все откаченые ранее проводки докатываются с использыванием тех дат которые существовали ранее для данной проводки и, разумеется с пересчетом остатков на конец каждой операции. Этот способ довольно сложен, крайне не надежен, применим далеко не всегда (неприменим например в случае когда отчетность уже зафиксирована контролирующими органами).... Но ОБЫЧНО разработччики бухгалтерских (и особенно банковских) систем предусматривают процедуру отката/доката бухгалтерских проводок ибо очень-очень редко но такая процедура реально необходима... Замечу, что я в данный момент абстрагируюсь от того факта, что в большинстве случаев, когда такая процедура "реально необходима", причины этой необходимости находятся на где-то грани криминальных...