Архитектура приложения для учета финансов (баланс, транзакции, счета)
Архитектура приложения для учета финансов (баланс, транзакции, счета)
Начал изучать вопрос проектирования базы для приложения в котором будет нечто подобие биллинга.
Информации много, но хочется структурировать. Есть уже готовые решения кое чего но вопросы остались.
Предположим, что есть система, в которой регистрируются пользователи. У них есть счета, их может быть много.
Читал, что нормальное приложение которое гибко учитывает деньги в системе должно иметь такие таблицы как, "счета, транзакции, журнал проводок".
Если со счетами все понятно, это некая общая информация на тему id клиента, валюты и общий баланс, то вот с таблицей транзакций, журнала проводок и вообще понятием двойной записи не понятно ничего.
В таблицу транзакций (она только на запись) идет запись каждого движения денежных средств
- DEPOSIT
- WITHDRAWAL
- BUY
- SELL
и так далее. Там же хранится ID счета и ID клиента, общая сумма
Но вот что такое журнал проводок (чем он от транзакций отличается) и как делается двойная запись и самое главное для чего ?
Изучал тему тут - http://www.highload.ru/2014/abstracts/1539.html
и тут - https://habrahabr.ru/post/259921/
Но может кто-то в более простой форме объяснит на примерах?
Задача заключается в том, чтобы:
1. Считать баланс клиента не на лету каждый раз а правильно и без пересчета суммы всех транзакций
2. Иметь возможность дать бухгалтерии важную и нужную информацию по движению денег в системе
3. Не потерять никакие данные и иметь возможность пересчитать баланс, например, пусть даже и ресурсозатратно
4. Масштабировать систему без переписывания кода (добавилась валюта, добавился тип транзакции)
Информации много, но хочется структурировать. Есть уже готовые решения кое чего но вопросы остались.
Предположим, что есть система, в которой регистрируются пользователи. У них есть счета, их может быть много.
Читал, что нормальное приложение которое гибко учитывает деньги в системе должно иметь такие таблицы как, "счета, транзакции, журнал проводок".
Если со счетами все понятно, это некая общая информация на тему 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: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Советую почитать короткие пособия по основам бухгалтерского учёта. Станет понятно.
Нравится Yii? Давайте сделаем его лучше!.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Сложно поспорить, уже освежаю в памяти. Но! Логически и бухгалтерски понятно, что, например, поступление денег это всегда дебет и кредет на 2 счета. Но не понятно как это легче всего реализовать в реальном проекте, в БД.
двойная запись - это реально 2 таблицы и 2 записи? Это 1 таблица и 2 записи? это 1 таблица и 1 запись?
двойная запись - это реально 2 таблицы и 2 записи? Это 1 таблица и 2 записи? это 1 таблица и 1 запись?
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Спасибо, это первое, что попалось по поиску! Но вообще по немного разобрался в теме и как только картина уляжется напишу тут сам себе ответ, может кому-то в будущем будет полезно.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Интересно, буду ждать. Я когда-то написал свой биллинг по работе, но исходники там и остались, помню только, что система получилась очень простая и надёжная.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Тоже появилась такая задача. Также не совсем ясно, как хранить баланс. Не одним же полем? Должна же быть какая то история изменеия баланса?
Но самый большой вопрос, как учитывать деньги, которые попали в систему из "ниоткуда" (например пополнили через платёжного аггрегатора)
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Завести счёт агрегатора.
Нравится Yii? Давайте сделаем его лучше!.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
На 8 слайде Дима пополнил себе счет на 100 рублей, у системы списалось 100
На 9 слайде Юра пополнил счет, у системы списалось.
Загоняем не в минус, а увеличиваем кредит.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Но ведь минус это и есть по сути кредит?chesar писал(а): ↑2017.06.28, 17:50https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
На 8 слайде Дима пополнил себе счет на 100 рублей, у системы списалось 100
На 9 слайде Юра пополнил счет, у системы списалось.
Загоняем не в минус, а увеличиваем кредит.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
В бухгалтерии всегда так, какой-то счет дебитуется, какой-то кредитуется. И этот вопрос возникновения денег в системе очень интересный, ведь сначала программисту кажется, что деньги должны как вода из одного кувшина перелится другой или же что счета бухгалтерские это как банковские карты, на которых должны быть деньги.Melodic писал(а): ↑2017.06.28, 17:58Но ведь минус это и есть по сути кредит?chesar писал(а): ↑2017.06.28, 17:50https://yiiconf.ru/data/yiiconf2017/ppt/272.pdf
На 8 слайде Дима пополнил себе счет на 100 рублей, у системы списалось 100
На 9 слайде Юра пополнил счет, у системы списалось.
Загоняем не в минус, а увеличиваем кредит.
Бухгалтерские счета это немного другое. Например, есть бухгалтерский счет "Cash in banks" это такой счет который как бы привязан к вашему банковскому и на нем по-умолчанию есть деньги пришедшие откуда угодно. Далее вы с этого счета списываете деньги на счет клиента и наоборот.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Возможно, кто нибудь знает как можно будет защититься от подмены значений баланса в БД? Имеет ли вообще смысл?))
Сейчас пробую вариант генерации некоего ключа для транзакции на основе предыдущей.
Сейчас пробую вариант генерации некоего ключа для транзакции на основе предыдущей.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Всё настолько плохо с безопасностью базы? blockchain-подобное что-то можно...
Нравится Yii? Давайте сделаем его лучше!.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Не всё плохо, но такой вариант не стоит исключать. В сторону блокчейна и смотрим, но тут тоже проблема, что всё должно происходить очень быстро. По несколько десятков переводов в секунду.
Стоит больше думать о защите самой БД от взлома, чем о подобном способе?
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Система должна хрнаить все транзакции и все операции так, чтобы в любой момент можно было посчитать актуальный баланс. Данные, которые вы храните в полях как одно число\значение - это чисто кэшированный вариант баланса. Тогда никакая подмена данных вам не страшна, вы можете посчитать все на лету и актуализировать баланс.
Ну а защита данных и защита самой базы - это уже отдельная тема=)
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Тоже пилю учёт финансов. Из полезного что нашёл:
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.
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.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Почему не делают, делают. Заивист от задачи и того, что именно вы называете операции.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
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
Вот с определениями тоже проблема. В приведённых выше ссылках есть несколько подобых схем БД:vitovt писал(а): ↑2017.07.04, 17:44Почему не делают, делают. Заивист от задачи и того, что именно вы называете операции.
Например, у меня, операция - это некое действие (например, выдача денег, зачисление денег, начислаение штрафа, коррекция) - такая операция может быть 1 и только 1, а уже проводки по бухгалтерии может быть > 1 тогда в таблице проводок я просто записываю две транзакции с одним и тем же operation_id
В них есть операции и есть транзакции. Если я правильно понял, то операции в этом случае это некая "полупроводка", а транзакция - это проводка. Но общепринятое понятие операции - это как раз группа проводок.
Пока думаю сделать три таблицы про движение денег по счетам:
1) полупроводки (запись):
Код: Выделить всё
ID записи, тип записи, ID счёта, дата, ID транзакции, сумма
Собственно реализация двойной записи, сделав просто сумму по счёту - мы получаем баланс счёта.
2) проводка (транзакция):
Код: Выделить всё
ID транзакции, тип транзакции, ID операции, дата, дебетируемый счёт, кредитуемый счёт, сумма (всегда положительная)
Код: Выделить всё
ID операции, дата, тип операции
- на одну транзакцию всегда делается две записи;
- на одну операцию всегда есть 1 или более транзакций;
- записи не могут быть без транзакций, транзакции не могут быть без операций.
Re: Архитектура приложения для учета финансов (баланс, транзакции, счета)
IMHO основанное на многолетнем опыте работы в бухучёте и внедрении различных бухсистем.
Лучше исходить из аксиомы - одна операция - одна проводка. Запись по дебету и кредиту.
Иначе что нибудь да потеряете.
Таблица документов:
id, typeid, datetime, number, kontraktid, summ, description.
Проводки:
id, datetime, debet, kredit, summ, documentid.
Плюс справочник типов документов он же операций, контрактов и контрагентов.
Если ничего не забыл то это минимально достаточно для отражения фактической деятельности.
Возможно что то упустил - уточняйте.
Лучше исходить из аксиомы - одна операция - одна проводка. Запись по дебету и кредиту.
Иначе что нибудь да потеряете.
Таблица документов:
id, typeid, datetime, number, kontraktid, summ, description.
Проводки:
id, datetime, debet, kredit, summ, documentid.
Плюс справочник типов документов он же операций, контрактов и контрагентов.
Если ничего не забыл то это минимально достаточно для отражения фактической деятельности.
Возможно что то упустил - уточняйте.