Архитектура приложения для учета финансов (баланс, транзакции, счета)

Обсуждаем, как правильно строить приложения
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vitovt »

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

Информации много, но хочется структурировать. Есть уже готовые решения кое чего но вопросы остались.

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

Читал, что нормальное приложение которое гибко учитывает деньги в системе должно иметь такие таблицы как, "счета, транзакции, журнал проводок".

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

В таблицу транзакций (она только на запись) идет запись каждого движения денежных средств
- DEPOSIT
- WITHDRAWAL
- BUY
- SELL

и так далее. Там же хранится ID счета и ID клиента, общая сумма

Но вот что такое журнал проводок (чем он от транзакций отличается) и как делается двойная запись и самое главное для чего ?

Изучал тему тут - http://www.highload.ru/2014/abstracts/1539.html
и тут - https://habrahabr.ru/post/259921/

Но может кто-то в более простой форме объяснит на примерах?

Задача заключается в том, чтобы:

1. Считать баланс клиента не на лету каждый раз а правильно и без пересчета суммы всех транзакций
2. Иметь возможность дать бухгалтерии важную и нужную информацию по движению денег в системе
3. Не потерять никакие данные и иметь возможность пересчитать баланс, например, пусть даже и ресурсозатратно
4. Масштабировать систему без переписывания кода (добавилась валюта, добавился тип транзакции)
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение samdark »

Советую почитать короткие пособия по основам бухгалтерского учёта. Станет понятно.
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vitovt »

Сложно поспорить, уже освежаю в памяти. Но! Логически и бухгалтерски понятно, что, например, поступление денег это всегда дебет и кредет на 2 счета. Но не понятно как это легче всего реализовать в реальном проекте, в БД.

двойная запись - это реально 2 таблицы и 2 записи? Это 1 таблица и 2 записи? это 1 таблица и 1 запись?
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vitovt »

samdark писал(а): 2017.05.11, 15:53 https://habrahabr.ru/post/259921/
Спасибо, это первое, что попалось по поиску! Но вообще по немного разобрался в теме и как только картина уляжется напишу тут сам себе ответ, может кому-то в будущем будет полезно.
Nex-Otaku
Сообщения: 831
Зарегистрирован: 2016.07.09, 21:07

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение Nex-Otaku »

Интересно, буду ждать. Я когда-то написал свой биллинг по работе, но исходники там и остались, помню только, что система получилась очень простая и надёжная.
Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение Melodic »

vitovt писал(а): 2017.05.12, 09:09
samdark писал(а): 2017.05.11, 15:53 https://habrahabr.ru/post/259921/
Спасибо, это первое, что попалось по поиску! Но вообще по немного разобрался в теме и как только картина уляжется напишу тут сам себе ответ, может кому-то в будущем будет полезно.
Тоже появилась такая задача. Также не совсем ясно, как хранить баланс. Не одним же полем? Должна же быть какая то история изменеия баланса?
Но самый большой вопрос, как учитывать деньги, которые попали в систему из "ниоткуда" (например пополнили через платёжного аггрегатора)
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение samdark »

Завести счёт агрегатора.
Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение Melodic »

samdark писал(а): 2017.06.28, 15:25 Завести счёт агрегатора.
Это понятно, но ведь должна быть какая то транзакция,что деньги появились? Или счёт агрегатора загонять в минус?
chesar
Сообщения: 514
Зарегистрирован: 2013.04.10, 17:49

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение chesar »

Melodic писал(а): 2017.06.28, 15:51 Это понятно, но ведь должна быть какая то транзакция,что деньги появились? Или счёт агрегатора загонять в минус?
https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
На 8 слайде Дима пополнил себе счет на 100 рублей, у системы списалось 100
На 9 слайде Юра пополнил счет, у системы списалось.

Загоняем не в минус, а увеличиваем кредит.
Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение Melodic »

chesar писал(а): 2017.06.28, 17:50
Melodic писал(а): 2017.06.28, 15:51 Это понятно, но ведь должна быть какая то транзакция,что деньги появились? Или счёт агрегатора загонять в минус?
https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
На 8 слайде Дима пополнил себе счет на 100 рублей, у системы списалось 100
На 9 слайде Юра пополнил счет, у системы списалось.

Загоняем не в минус, а увеличиваем кредит.
Но ведь минус это и есть по сути кредит?
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vitovt »

Melodic писал(а): 2017.06.28, 17:58
chesar писал(а): 2017.06.28, 17:50
Melodic писал(а): 2017.06.28, 15:51 Это понятно, но ведь должна быть какая то транзакция,что деньги появились? Или счёт агрегатора загонять в минус?
https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
На 8 слайде Дима пополнил себе счет на 100 рублей, у системы списалось 100
На 9 слайде Юра пополнил счет, у системы списалось.

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

Бухгалтерские счета это немного другое. Например, есть бухгалтерский счет "Cash in banks" это такой счет который как бы привязан к вашему банковскому и на нем по-умолчанию есть деньги пришедшие откуда угодно. Далее вы с этого счета списываете деньги на счет клиента и наоборот.
Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение Melodic »

Возможно, кто нибудь знает как можно будет защититься от подмены значений баланса в БД? Имеет ли вообще смысл?))

Сейчас пробую вариант генерации некоего ключа для транзакции на основе предыдущей.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение samdark »

Всё настолько плохо с безопасностью базы? blockchain-подобное что-то можно...
Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение Melodic »

samdark писал(а): 2017.06.30, 13:46 Всё настолько плохо с безопасностью базы? blockchain-подобное что-то можно...
Не всё плохо, но такой вариант не стоит исключать. В сторону блокчейна и смотрим, но тут тоже проблема, что всё должно происходить очень быстро. По несколько десятков переводов в секунду.

Стоит больше думать о защите самой БД от взлома, чем о подобном способе?
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vitovt »

Melodic писал(а): 2017.06.30, 13:31 Возможно, кто нибудь знает как можно будет защититься от подмены значений баланса в БД? Имеет ли вообще смысл?))

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

Ну а защита данных и защита самой базы - это уже отдельная тема=)
Аватара пользователя
vjik
Сообщения: 23
Зарегистрирован: 2012.04.02, 18:59

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vjik »

Тоже пилю учёт финансов. Из полезного что нашёл:
http://helpme1c.ru/osnovy-buxgalterskog ... mmistov-1s
https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
https://habrahabr.ru/post/259921/ + комменты
http://www.highload.ru/2014/abstracts/1539.html
https://www.youtube.com/watch?v=zs4VUokFtPQ
viewtopic.php?f=34&t=43443

Не могу понять, почему в таблице операций не делают отдельно поле PK id, а делают составной primary key?
Хотя теоретически может сложится так, что будут реально две операции с одинаковым составным primary key.
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vitovt »

vjik писал(а): 2017.07.04, 13:12 Тоже пилю учёт финансов. Из полезного что нашёл:
http://helpme1c.ru/osnovy-buxgalterskog ... mmistov-1s
https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
https://habrahabr.ru/post/259921/ + комменты
http://www.highload.ru/2014/abstracts/1539.html
https://www.youtube.com/watch?v=zs4VUokFtPQ
viewtopic.php?f=34&t=43443

Не могу понять, почему в таблице операций не делают отдельно поле PK id, а делают составной primary key?
Хотя теоретически может сложится так, что будут реально две операции с одинаковым составным primary key.
Почему не делают, делают. Заивист от задачи и того, что именно вы называете операции.
Например, у меня, операция - это некое действие (например, выдача денег, зачисление денег, начислаение штрафа, коррекция) - такая операция может быть 1 и только 1, а уже проводки по бухгалтерии может быть > 1 тогда в таблице проводок я просто записываю две транзакции с одним и тем же operation_id
Аватара пользователя
vjik
Сообщения: 23
Зарегистрирован: 2012.04.02, 18:59

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение vjik »

vitovt писал(а): 2017.07.04, 17:44
vjik писал(а): 2017.07.04, 13:12 Не могу понять, почему в таблице операций не делают отдельно поле PK id, а делают составной primary key?
Хотя теоретически может сложится так, что будут реально две операции с одинаковым составным primary key.
Почему не делают, делают. Заивист от задачи и того, что именно вы называете операции.
Например, у меня, операция - это некое действие (например, выдача денег, зачисление денег, начислаение штрафа, коррекция) - такая операция может быть 1 и только 1, а уже проводки по бухгалтерии может быть > 1 тогда в таблице проводок я просто записываю две транзакции с одним и тем же operation_id
Вот с определениями тоже проблема. В приведённых выше ссылках есть несколько подобых схем БД:

Изображение

В них есть операции и есть транзакции. Если я правильно понял, то операции в этом случае это некая "полупроводка", а транзакция - это проводка. Но общепринятое понятие операции - это как раз группа проводок.

Пока думаю сделать три таблицы про движение денег по счетам:

1) полупроводки (запись):

Код: Выделить всё

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

2) проводка (транзакция):

Код: Выделить всё

ID транзакции, тип транзакции, ID операции, дата, дебетируемый счёт, кредитуемый счёт, сумма (всегда положительная)
3) операция:

Код: Выделить всё

ID операции, дата, тип операции
Правила:
  • на одну транзакцию всегда делается две записи;
  • на одну операцию всегда есть 1 или более транзакций;
  • записи не могут быть без транзакций, транзакции не могут быть без операций.
По идее с таким вариантом уже можно реализовывать логику работы с деньгами используя типы транзакций/операций/записей.
dmg
Сообщения: 685
Зарегистрирован: 2012.10.15, 03:09

Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)

Сообщение dmg »

IMHO основанное на многолетнем опыте работы в бухучёте и внедрении различных бухсистем.
Лучше исходить из аксиомы - одна операция - одна проводка. Запись по дебету и кредиту.
Иначе что нибудь да потеряете.
Таблица документов:
id, typeid, datetime, number, kontraktid, summ, description.
Проводки:
id, datetime, debet, kredit, summ, documentid.
Плюс справочник типов документов он же операций, контрактов и контрагентов.
Если ничего не забыл то это минимально достаточно для отражения фактической деятельности.
Возможно что то упустил - уточняйте.
Ответить