Проектирование финансовых систем

[Exorcist]

Никогда не сталкивался, но тут
Каждый день выполняются какие то действия в отношении денег:
приход расход перевод в связке со счетами . Мысли о том хранить как в БД
1.Transcation
id
sum сумма
cat_id тип операци
date
2.Account - счета
id
Name
3.Account history
id
date
sum

То есть при совершении операции заносится запись в таблицу transaction и account history, где берется прошлое значении суммы = +(-)new_sum.

В принципе можно все обновить и пересчитать.

Насколько рационально это ? Может кто сталкивался или есть где почитать более универсальные решения?

 

[Exorcist]

Допустим мини бухгалтерия. Продал купил перевел

 

[baev]

А чего тут «про бух.учёт» описывать? Основной принцип — двойная запись. Дальше — особенности реализации учёта на конкретном предприятии.

учёт через проводки:
дебетовый счёт (откуда) - кридитовый счёт (куда) - сумма + инфа о проводке

— мда, всё в кучу смешали. «Дебетовый/крЕдитовый счёт» — это совсем другое. Здесь должно быть: «дебет одного счёта — кредит другого счёта».

 

[baev]

А, да…

Вряд-ли здесь есть профессиональные бухгалтера, которые Вам быстренько и точно опишут что и как нужно делать. По конкретным проблемам разработки ПО - да, могут, а по сторонним темам - врядли (в частности, про бух.учёт).

— люди с экономическим образованием на форуме есть, но сильно сомневаюсь, что кто-то будет бесплатно оказывать консультации.
Я не в курсе современных цен, но шесть лет назад стандартная ставка в Москве была 40$ в час за консультацию (я восемь лет заместителем генерального директора в аудиторской фирме проработал).

 

[ScDewt]

Никогда не сталкивался, но тут
2.Account - счета
id
Name

Я бы добавил сюда еще поле баланса аккаунта.
Плюс статус аккаунта описывающий возможность проведения операции по данному аккаунту. (вдруг заблокировать придется)

3.Account history
id
date
sum

То есть при совершении операции заносится запись в таблицу transaction и account history, где берется прошлое значении суммы = +(-)new_sum.

В историю писал бы как раз сумму перевода, а не "прошлое значении суммы = +(-)new_sum." - это ж история.
плюс указыал бы не только id аккаунта, но и направление перевода (id_from и id_to), статус перевода (Принят, Ожидает, Отклонен), и добавил бы описание перевода, типа "плата через смс", "вывод денег на счет банка".

Если есть человек, кто одобряет/проверяет операции (режим модерации), то и id модератора.

 

[ScDewt]

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

p.s. причем в истории лишнего не бывает ничего - чем больше данных и чем эти данные "сырее", т.е. без всяких обработок - тем лучше.

 

[akd]

Exorcist, просто для ясности, на размышления ScDewt внимания можно не обращать. баев уже написал как надо.

 

[ScDewt]

Exorcist, просто для ясности, на размышления ScDewt внимания можно не обращать. баев уже написал как надо.

Поясните?!
Человек спросил - как ему хранить данные, а не какие операции и расчеты совершать над деньгами. Более того - бухгалтерия влияет на логику работы с деньгами, а не на вид их хранения.

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

 

[akd]

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

 

[ScDewt]

Понял, спасибо за разъяснение - возможно вы правы.

 

[grigori]

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

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

 

[akd]

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

 

[ScDewt]

Согласен что надо следить за многим - знаю далеко не понаслышке.

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

p.s. тем более я думаю раз человек задал такой вопрос тут - то у него там не тысячи долларов крутятся, и потому "шишки" набитые будут нестрашны, а вот опыт бесценен.

 

[ScDewt]

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

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

p.s. если все будут следовать принципу "не парься/учись/разбирайся сам - обратись к профи", то откуда будут браться профи?

 

[AmdY]

Exorcist
в транзакцию записывай ещё кто её совершил и поле для дополнительной информации, туда можно складывать сериализованный массив.
ну и следи за округлениями, лучше всего работать через функции bc*

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

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

 

[ScDewt]

...лучше всего работать через функции bc*

Добавлю немного не по теме...
Кстати довольно часто применяется округление/конвертация средств прям на месте - часто сталкиваюсь что в коде десятки мест работающих с округлением/конвертацией - это плохо. правильней делать одно место (класс) в котором будет вся логика округлений/конвертации и прочей математической лабуды.

 

[AmdY]

угу, в Zend Framework есть готовый класс Zend_Currency - http://framework.zend.com/manual/ru/zend.currency.html

 

[флоппик]

Добавлю немного не по теме...
Кстати довольно часто применяется округление/конвертация средств прям на месте - часто сталкиваюсь что в коде десятки мест работающих с округлением/конвертацией - это плохо. правильней делать одно место (класс) в котором будет вся логика округлений/конвертации и прочей математической лабуды.

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

 

[akd]

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

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

 

[Dovg]

Да там вроде просто все

1. всегда считаем в чем-нибудь целом/decimal.
2. должна быть одна точка входа. У нас - это база.

Есть счета. Счета бывают активными и пассивными. пассивные - это источники средств, активные - это куда размещены средства. В простейшей системе все счета могут быть активными.

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

+ разобраться что и как нужно блокировать.

Возьмите учебник по бухучету, там все есть. Останется только описать готовую модель кодом