В итоге сейчас уже имея довольно большой опыт работы с АСР я решил сделать свою схему. Но так-как я все же один человек, то ее стоит показать другим и подвергнуть критике. Так что я надеюсь их эта тема заинтересует и они мне расскажут что еще стоит сделать и как. Схема которую я публикую здесь, уже подвергнута улучшениям и корректировкам, а так же уже есть возможность скачать ее с github. Как в виде файла для Power Architect так и в виде готового DDL файла для PostgreSQL. Единственное я не успел еще заполнить справочники, но всему свое время. А сейчас переходим к схеме.
Первым делом стоит посмотреть на ER-диаграмму, как наиболее удобное средство представление схемы.
Как видите хотя таблиц довольно много, на самом деле функционал достаточно небольшой.
И состоит из следующих возможностей:
- Хранение договора клиента и ведение его баланса
- Хранение услуг и ведение их стоимости
- Проведение начислений за предоставленные услуги
- Предоставление скидок
- Проведение платежей
- Перевод денежных средств с договора на договор
- Ввод остатков по клиентам при переносе их из другой системы
- Хранение выставленных счетов клиенту
- Погашение выставленных счетов
Это необходимый минимум для корректного проведения начислений за услуги и учета денежных средств.
Но прежде чем переходить к описанию, стоит упомянуть соглашения применяемые в схеме:
- Все внешние ключи имеют формат <первичный ключ>_<имя таблицы>. В случае если внешних ключей несколько или они указывают на саму таблицу допускается или дополнение к названию вида id_<имя таблицы>_<поясняющее дополнение> или же id_<поясняющее дополнение>. В качестве примера id_trx_from, id_trx_to для первого случая и id_revoke,id_revokedby для второго случая в таблице bill.transfer.
- Поля с деньгами определены как numeric(18,4).
- Поля с датой имеют префикс dt в обязательном порядке.
- Поля с датой и временем имеют префикс ts в обязательном порядке.
- В случае если имеется временной интервал (dtfrom, dtto или tsfrom, tsto), то первая дата всегда задана и по умолчанию равна now(), вторая дата может быть пустой и в этом случае интервал считается действующим на данный момент.
- В части случаев у справочников вместо числового первичного ключа используется текстовый мнемонический ключ. Такие ключи обозначены как sid. Используется исключительно для удобства при работе с данными напрямую через консоль РСУБД.
А теперь
Опорными таблицами являются:
- Договоры (bill.contract) — минимально необходимое для использование описание договора
- Проводки (bill.trx) — Журнал проведенных операций. Фактически сумма денег пришедшая или ушедшая со счета.
- Используемая сторона учета (bill.ledgertype) — указывает на то куда идет проводка (дебит, кредит)
- Отчетные периоды (bill.period) — отчетыне периоды в бухгалтерском смысле слова. Хотя и содержит дату начала и дату завершения, фактически всегда равен месяцу
- Счета выставленные клиенту (bill.invoice) — те самые счета что выставляются клиенту за отчетный период.
Хотя этих таблиц вполне достаточно для работы биллинга, но для удобства работы добавляются таблицы первичных документов. Под первичными документами подразумеваются те документы на основании которых делаются проводки на по договору клиента.
Сейчас в схеме присутствуют следующие первичные документы:
- Остатки (bill.remain) — входящие остатки из другой системы. Эти документы должны быть всегда, иначе если вы мигрируете из другой системы, вы никогда не узнаете какой был баланс у клиента на момент миграции. Этим кстати страдают многие АСР, так-как разработчики считают, что достаточно ввести баланс. Но это не так, так-как в нормальной системе баланс клиента расчетная величина.
- Платежи (bill.payment) — поступающие от клиентов денежные средства.
- Переводы (bill.transfer) — перевод денежных средств со счета на счет. Сразу замечу, стоит явно запрещать перевод денежных средств при их отсутствии. Т.е. если баланс клиента отрицательный, то перевод должен быть запрещен.
- Начисления (bill.charge) — начисления за потребленные или предоставляемые (при авансе) услугию
- Скидки (bill.discount) — Скидки на услуги. Хотя в целом нет единого мнения как выражать скидку. Я считаю что скидку стоит выражать в денежном эквиваленте к определенному начислению. Это упрощает работу с ней.
- НДС (bill.vat) — НДС с начисления, выставляется отдельным документом. Все проводки с начислений идут без НДС, при этом само начисление может включать НДС. Это к примеру требуется для физических лиц. В этом случае в bill.charge есть явный флаг, что начисление включает НДС. При этом проводка по начислению не включает НДС и полная сумма начисления составляется из двух проводок, проводка по первичному документу начисление + проводка под НДС.
У первичных документов есть как общие поля так и общие правила работы с ними. Начнем с общих полей:
- id_contract (id_contract_from,id_contract_to) — указывает на договор или договора документа
- id_trx (id_trx_from, id_trx_to) — указывает на проводку или проводки документа
- id_period — в какой отчетный период проводится документ.
- ts — дата документа
- tscreate — дата создания документа.
- amount — сумма документа
- id_revoke — корректируемый документ. Указывает на тот документ который корректируется этим.
- id_revokedby — корректирующий документ. Указывает на тот документ который откорректировал текущий.
Насчет отчетного периода и корректируемого и корректирующего документа остановлюсь по подробнее.
Отчетный период.
В конце месяца у вас может быть два открытых отчетных периода из-за того, что к примеру последние дни выпадают на выходные, и платежи по банку еще не разнесены. Плюс это требуется в случаях к примеру когда фактическая дата документа январь 2014 года, а используемый период июнь 2015, проводимый в начале июля 2015. Т.е. в периоде июнь 2015, в дате создания 2 июля 2015, а в дате документа январь 2014. Из-за этого фактически у документа три даты.
Корректируемые и корректирующие документы.
Фактически если у вас в системе возник документ, который является ошибочным, то удалять его нельзя. Его можно только аннулировать. Т.е. создать корректирующий документ который строго противоположен некорректному документу. Именно для этого используются эти два поля. id_revoke — заполняется корректирующего документа, а id_revokedby у корректируемого. Корректировать иным образом, к примеру часть документа, не рекомендуется, как и удалять документы. Вместо этого скрывайте такие документы, в случае если они идут в одном периоде. Если документы находятся в разных периодах, то скрывать их как раз таки не требуется. Так же обратите внимание что у проводок таких полей нет, они не бывают корректируемыми.
Кроме общих полей, у первичных документов есть свои специфичные поля:
- Документы начислений (bill.charge) — count и vatincluded. Первое указывает на количество предоставленных услуг, второе на включается ли НДС в сумму документа.
- Документы НДС (bill.vat) — id_charge и id_vatrate указывающие на документ начислений к которым относится НДС и какой процент НДС был на момент проведения документа начислений.
- Документы скидок (bill.discount) — id_charge указывающее на какое начисление была применена скидка.
- Документы остатков (bill.remain) — sid_ledgertype позволяющее указывать используемую сторону учета при проведении документа.
Остальные поля думаю понятны из контекста и выбранных имен. На этом завершим разговор о первичных документах и перейти к оставшимся справочным таблицам.
В схеме присутствуют следующие справочные таблицы:
- Типы платежей (bill.paymenttype) — для деления платежей по типам. Нал, безнал, платежные агенты и т.п.
- Единицы измерения (bill.unit) — собственно единицы измерения используемых услуг. К примеру можно взять из справочника ОКЕИ. Ссылка на самого себя используется для единиц которые включают другие.
- Услуги (bill.service) — наименование услуг предоставляемых по договору.
- Цены (bill.price) — Стоимость услуг. Для учета изменения стоимости добавлены временные интервалы.
- Тип проводки (bill.trxtype) — Указывает на используемый тип проводки для первичных документов, а так же сторону учета используемую по умолчанию. В случае если сторона по умолчанию не указана, выбор происходит при проведении документа. К примеру это документы остатков.
А так же две вспомогательные таблицы:
- История баланса (bill.balance) — история изменения баланса договора с привязкой к проводкам.
- Обороты (Сальдо) за отчетный период (bill.saldo) — таблица с агрегированными данными по оборотам привязанная к периоду. Весьма часто используется в различной аналитике.
И на этом все. Если вас не затруднит ответьте на опрос. Результаты будут учтены при написании следующего в серии поста :) Ну и задавайте свои вопросы в комментариях.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (62)
tgz
10.06.2015 17:57Забудьте про явное соответствие объект(сущность) — таблица. Все их нужно хранить в одном месте генерируя представление для БД. Иначе расширять такую структуру будет сложно и невозможно.
Вообще АСР — это абстракции, абстракции и еще раз абстракции. И много-много DSL.
Посмотрите хотя бы на 1С, не к ночи она будет помянута.
norguhtar Автор
10.06.2015 20:29-1Забудьте про явное соответствие объект(сущность) — таблица. Все их нужно хранить в одном месте генерируя представление для БД.
У меня вполне четкая предметная область. Зачем мне это делать?
Вообще АСР — это абстракции, абстракции и еще раз абстракции. И много-много DSL.
Можно поинтересоваться сколько вы АСР написали и на какое количество клиентов они использовались?
Посмотрите хотя бы на 1С, не к ночи она будет помянута.
Поверьте я много что смотрел. В том числе и 1С.tgz
10.06.2015 22:01+1Затем что все меняется быстрее, чем пишется код.
Сколько АСР я написал тут не имеет никакого значения.
Ну раз много что смотрели, то и сделали бы анализ. Вот такой подход, вот другой, вот критерии. Потом на основе анализа уже синтез под конкретное ТЗ, которое тоже надо выстрадать. Тогда я понимаю, будет статья. А пока маловато будет, маловато.norguhtar Автор
11.06.2015 06:13Затем что все меняется быстрее, чем пишется код.
В таком случае и ваш подход не работает и все тщетно :) Фактически же меняется не так уж и быстро. Эта схема результат опыта моей работы с различными АСР в течении 8 лет.
Сколько АСР я написал тут не имеет никакого значения.
Увы имеет, так-как иначе вы просто не знаете что из себя представляет пердметная область.
Ну раз много что смотрели, то и сделали бы анализ. Вот такой подход, вот другой, вот критерии. Потом на основе анализа уже синтез под конкретное ТЗ, которое тоже надо выстрадать. Тогда я понимаю, будет статья. А пока маловато будет, маловато.
Я не научную работу или диплом все же пишу. Я предлагаю один из вариантов решения. Использовать или нет это уже каждый решает сам.
sunnybear
10.06.2015 23:07Очень круто. Теперь бы это в виде классов / схемы данных где-нибудь выложить + прикрутить генерацию счетов/актов — цены бы не было!
norguhtar Автор
11.06.2015 06:29Схема данных уже выложена. Сходите на github. Ссылка в посте есть. Насчет классов обвязки я думал или Python или Java. Выбирайте.
Mendel
11.06.2015 01:08Спасибо, полезная статья.
Но я бы таки за основу брал двойную запись.
Она дает значительную гибкость.
Проводка она не даром двойная. Это дает очень большую гибкость.
Наличие баланса позволяет легко проверить/восстановить целостность.
Целостность движения денег дает множество дополнительных управленческих отчетов.
Делаем из этого биллинга биллинг торговли. Слишком большие изменения выходят. Склады, закупочные цены…
Делаем биллинг ресторана. С себестоимостями и т.п., ведь надо и калькуляции и склад…
И нет, это не бухгалтерия. Нам ведь нужно управлять скидками? А значит нужна себестоимость. Хоть какая.
ABC-отчет нужен?
А если нам нужно делать еще один налог. Типа налог с продаж. Похож на НДС, но помимо НДС и с другой логикой?
Вообще идея о том, чтобы учитывать отдельно проводки, а отдельно двигающие их документы логична. Но стоит довести ее до большей универсальности.
План счетов может быть абсолютно любой, а субсчета прекрасно привязываются к «договорам».
Тогда мы можем настроить систему так, чтобы было просто вести аналитику по рекламным компаниям (двигаем счета «скидка по рекламе А» и «расходы на рекламу А», можно с субсчетами по признаку «старый клиент/новый клиент»)
Маркетинговые ходы, где часть позиций продаются ниже себистоимости нужно очень тонко считать…
Мы арендуем от 8 до 12 серверов, в зависимости от загрузки по клиентам. Стоит ли взять 10 серверов по цене 9, и докупать мощности при необходимости уже не от 0 до 4, а от 0 до 2, при этом изредка имея простой одного сервера? Какую часть «доходов будущих периодов», т.е. предоплаты клиентов мы можем безболезненно потратить, зная что такое-то время они нам не понадобятся?
Все эти вопросы можно предусмотреть в гибком плане счетов. При этом бухгалтерия не совсем подходит для такого, ведь это чисто управленческий учет.
План счетов, субсчета, двойные проводки и универсальные ИД документов двигающих биллинг (например GUID + тип документа, и уже у каждого документа своя отдельная таблица, которую мы выбираем по типу документа, полученному по GUID). Абстрактный класс для документов, в реализации даем движение конкретных счетов… Ну а в остальном как у Вас…norguhtar Автор
11.06.2015 06:27Но я бы таки за основу брал двойную запись.
Она дает значительную гибкость.
Проводка она не даром двойная. Это дает очень большую гибкость.
Наличие баланса позволяет легко проверить/восстановить целостность.
Целостность движения денег дает множество дополнительных управленческих отчетов.
Внимательно смотрим схему. На самом деле двойная запись есть. Но в виде журнала, а не раздельных счетов. Я рассматривал вариант с раздельными счетами для дебита кредита а так же различных услуг. Как итог пришел к выводу что это сильно усложнит схему и оставил только журнал проводок с дебитом и кредитом. Баланс кстати четко привязан к ним, что позволяет в случае необходимости верифицировать баланс по журналу проводок. Разнесение на раздельные счета и т.п. делается уже отдельно в 1С/SAP. Т.е. в любом случае я предполагаю что в конце месяца происходит выгрузка в нормальную бухгалтерскую систему.
Делаем из этого биллинга биллинг торговли. Слишком большие изменения выходят. Склады, закупочные цены…
Делаем биллинг ресторана. С себестоимостями и т.п., ведь надо и калькуляции и склад…
Ничего подобного :) Расширить да. Изменения? Нет. Если вы считаете что только расширения схемы мало, то я хотел бы услышать что с вашей точки зрения в этой схеме мешает.
Нам ведь нужно управлять скидками? А значит нужна себестоимость. Хоть какая.
У меня управление скидками никак не затрагивается. Это вообще отдельная тема для разговора, что как и почему. И для каждой предметной области управление скидками будет свое.
ABC-отчет нужен?
С таким отчетом как-то не сталкивался.
План счетов может быть абсолютно любой, а субсчета прекрасно привязываются к «договорам».
Что тут подразумевается под планом счетов? Я просто не совсем понимаю механику.
А если нам нужно делать еще один налог. Типа налог с продаж. Похож на НДС, но помимо НДС и с другой логикой?
В чем выражается другая логика? Налог с продаж в целом НДС и выражает. Тут НДС то введено исключительно из-за того что он взимается на стадии начисления. И его вынос в большую SAP систему доставляет слишком много сложностей.
универсальные ИД документов двигающих биллинг (например GUID + тип документа, и уже у каждого документа своя отдельная таблица, которую мы выбираем по типу документа, полученному по GUID).
Такое я не стал закладывать так-как считаю в таких случаях по проводкам.
Да 1C/SAP при этом никуда не девается. Это скорее не для вас, а для остальных. ;)Mendel
12.06.2015 01:01Простите, я думал у вас чуть лучше понимание терминологии. Моя вина.
Я как-то начинал писать статью «бухгалтерия для программиста», с основами терминологии, но всё время не найду поправить ее красоту.
Попробую здесь кратко:
1 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Краткий (очень краткий) пример:
В начале у нас всё по нулям.
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Баланс на выходе:
Активы:
Деньги на вебманях = 50руб.
Оплаченные хостинги = 25руб.
Пассивы:
«Доходы будущих периодов», субсчет «Счет клиента Иван» = 50руб.
«Нераспределенная прибыль» = 25руб.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
slayerhabr
12.06.2015 01:04Тот момент, когда комментарий достоен поста.
И да, ждем отдельную, подробную статью
norguhtar Автор
12.06.2015 08:06-11 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
Я в курсе. И да я в курсе так же что у вас этих счетов может быть больше двух. Это очень громоздкая схема и вот в АСР ее использовать ее с моей точки зрения весьма и весьма накладно.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
В случае если у вас насколько счетов то да. АСР с моей точки зрения это система в первую очередь для клиентов. По этой причине два счета в системе отсутствуют.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Опять же вернемся к началу АСР не бухгалтерия. Нам более важно чтобы у нас начисления и платежи были не противоречивы и баланс клиента всегда был вычисляем.
Теперь давайте по вашему краткому примеру:
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Окей первая операция есть в биллинге. Создается платеж и проводка.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
А тут внимание. Этой части в АСР в таком виде нет.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Этот документ есть.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
Проблема в том что вы пытаетесь втащить фактически полный бух. учет в систему. В том числе еще поди и расчеты зарплат можно внести и т.п. А биллинги в России не зря называются АСР фактически же полная формулировка звучит как Автоматизированная система расчетов с клиентами. Т.е. она решает только одну часть это автоматизация работы с клиентами. Да ее можно выполнить как модуль к SAP. Но могут возникнуть проблемы с производительностью и слишком большого числа допила специфической части предметной части. По этой причине как правило АСР выполняется в урезанном по бух. учету функционале. К примеру в ней плана счетов. Считается что есть только один счет обращенный к клиенту.Mendel
12.06.2015 13:06Ну вопросов к вашей реализации у меня было два:
1 — вы используете бухгалтерские термины там, где им не место, и таким образом, что это искажает смысл. Пишите уж «приход-расход», или что-то другое. Дебет и Кредит созданы именно для того, чтобы отразить это явление, когда у пассивных счетов это одно, а у активных другое… Плюс обычно под дебетом подразумевают НОМЕР дебетуемого счета. В общем тому кто понимает, оно немного неудобно, и запутывает. Тому же, кто не знает таких слов, так и подавно оно непонятно.
2 — Ваша схема при всех ее преимуществах заточена под довольно узкую сферу. Слишком ограниченная реализация.
Вы очень хорошо прописали многие классические ошибки. Например объяснили почему нужно сторнировать (корректирующая проводка в вашей терминологии), а не удалять, почему лучше делать ввод остатков, а не фиктивные платежи…
Но данное решение это частный случай, с планом счетов состоящим из одного внебалансового активного счета (хотя правильнее было его делать пассивным, но тут без особой разницы)…
Вы ошибочно разделяете биллинг и бухгатлерию, не оставив места управленческому учету. Тут есть несколько факторов:
стандартные, готовые управленческие решения нам могут не подходить, а поскольку в отличии от бухгалтерии этот вопрос не регламентирован государством, то мы можем иметь любые пожелания… писать с нуля? Отдельно? Третьей системой? Т.е. мы пишем биллинг, пишем отдельно от него управленческий учет, который дублирует биллинг, и частично бухгалтерию. Потом делаем синхронизацию этих трех систем… ну допустим.
Но вот задача — раздельный учет денег приходящих из разных платежных систем, потому что у нас на разных счетах лежат деньги, и расходы нужно как-то оптимизировать с учетом платежных систем… Скажите, куда интегрировать этот учет? Бухгалтерия его не поддерживает. У вас оно не надо, и сложно… добавляем в управленческий.
Теперь вопрос — платежная система будет информацию отправлять и в биллинг и в упр.учет? Нет, в одно… а в какое? Очевидно что в биллинг, ведь иначе зачем он нам вообще? Ведь все данные биллинга в управленческом уже есть… из биллинга информация идет в управленческий учет, потом из него идет в бухгалтерию? Или сначала в бухгалтерию? Или и в бухгалтерию и в управленческий из биллинга? И во всех трех у нас будет своя цифра по счетам. Где-то не успели синхронизировать, где-то сбой… Рано или поздно с ростом сложности задач будет принято решение выкинуть эту урезанную прослойку под названием «биллинг» и перенести ее в управленческий учет.
Мне кажется (кажется это значит что могу ошибаться), что Вы плохо понимаете бухучет, и поэтому считаете, что его принципы используются только в бухгалтерии… Может вам будет проще, если я буду называть управленческий учет «черной бухгалтерией»? Хотя черный и отдает некоей незаконностью, что не всегда так, но может так понятнее будет.norguhtar Автор
12.06.2015 13:401 — вы используете бухгалтерские термины там, где им не место, и таким образом, что это искажает смысл. Пишите уж «приход-расход», или что-то другое. Дебет и Кредит созданы именно для того, чтобы отразить это явление, когда у пассивных счетов это одно, а у активных другое… Плюс обычно под дебетом подразумевают НОМЕР дебетуемого счета. В общем тому кто понимает, оно немного неудобно, и запутывает. Тому же, кто не знает таких слов, так и подавно оно непонятно.
Это кстати хорошее замечание. С терминологией вообще много путаницы. В принципе таблица стороны учета позволяет сделать не дебет/кредит а приход/расход. И на механику это никак не повлияет.
2 — Ваша схема при всех ее преимуществах заточена под довольно узкую сферу. Слишком ограниченная реализация.
Есть такое. Но тут есть еще такой момент, весьма часто требуется сделать отдельную систему которая с типичной бухгатерией или SAP системой связана только опосредовано. К примеру требуются данные только по завершению отчетного периода, до этого всю эту информацию тащить не есть хорошо.
Вы очень хорошо прописали многие классические ошибки. Например объяснили почему нужно сторнировать (корректирующая проводка в вашей терминологии), а не удалять, почему лучше делать ввод остатков, а не фиктивные платежи…
Но данное решение это частный случай, с планом счетов состоящим из одного внебалансового активного счета (хотя правильнее было его делать пассивным, но тут без особой разницы)…
Внесение большего числа счетов делает систему сложнее для понимания, для остальных. А если прятать от части пользователей счета, то начинается свистопляска со стороны тех кто эти счета хочет настроить под себя. Так что это сознательное действие.
Вы ошибочно разделяете биллинг и бухгатлерию, не оставив места управленческому учету. Тут есть несколько факторов:
стандартные, готовые управленческие решения нам могут не подходить, а поскольку в отличии от бухгалтерии этот вопрос не регламентирован государством, то мы можем иметь любые пожелания… писать с нуля? Отдельно? Третьей системой? Т.е. мы пишем биллинг, пишем отдельно от него управленческий учет, который дублирует биллинг, и частично бухгалтерию. Потом делаем синхронизацию этих трех систем… ну допустим.
Насколько это ошибочно, это вопрос хороший. Но это типичный подход, бухгалтерию от биллинга отделяют довольно часто. Опять же мне не совсем понятно что тут под управленческим учетом подразумевается? Я просто не сталкивался с этим понятием. Ссылочка бы не помешала. Пока я так понял это система которая как-то показывает то какие у нас расходы и доходы и как они складываются.
Теперь вопрос — платежная система будет информацию отправлять и в биллинг и в упр.учет? Нет, в одно… а в какое? Очевидно что в биллинг, ведь иначе зачем он нам вообще? Ведь все данные биллинга в управленческом уже есть… из биллинга информация идет в управленческий учет, потом из него идет в бухгалтерию? Или сначала в бухгалтерию? Или и в бухгалтерию и в управленческий из биллинга? И во всех трех у нас будет своя цифра по счетам. Где-то не успели синхронизировать, где-то сбой… Рано или поздно с ростом сложности задач будет принято решение выкинуть эту урезанную прослойку под названием «биллинг» и перенести ее в управленческий учет.
Платежи и начисления в биллинге. Далее данные из биллинга в бухгалтерию по завершению отчетного периода. Для понимания что попадает в управленческий учет, мне нужно понять что имеется ввиду под управленческим учетом.
Мне кажется (кажется это значит что могу ошибаться), что Вы плохо понимаете бухучет, и поэтому считаете, что его принципы используются только в бухгалтерии… Может вам будет проще, если я буду называть управленческий учет «черной бухгалтерией»? Хотя черный и отдает некоей незаконностью, что не всегда так, но может так понятнее будет.
Вполне возможно я недостаточно понимаю бух. учет. Но эта проблема есть у многих. И еще есть другая проблема когда начинают тащить полный бух. учет, то получается система которую понимают только люди плотно знакомые с этой областью. И что еще хуже они не пытаются адаптировать решения так чтобы этим мог пользоваться простой смертный. А биллинг все же та система которой хотелось бы чтобы могли пользоваться и простые смертные.Mendel
12.06.2015 15:07Непонимание бухучета это проблема не бухучета или того кто не понимает, а того что нет адекватных материалов. может есть какие-то популярные статьи или учебники (наверняка есть), но в основном пишут просто сухие факты, от которых нифига не понятно. Я разобрался с бухучетом только когда потратил два часа на написание заметки в стиле «давайте изобретем бухучет», разбираясь зачем сделано так, а не иначе… Читая сухую информацию из справочника или википедии мы обычно пытаемся спроецировать ее на наше обычное понимание, и получается каша. Ну да это оффтоп.
Соглашусь с Вами что «полная бухгалтерия», да еще и сохранение бухгалтерской терминологии и т.п. делает продукт неработоспособным.
Также хочу уточнить, что я не навязываю, что синтетические счета с двойной записью это панацея. Вы спросили мол кто бы что сделал иначе, я и озвучил :)
Управленческий учет я бы коротко охарактеризовал как бухгалтерию которая ведется для целей управления бизнесом, а не для взаимодействий с гос.органами или инвесторами и т.п. Все хорошие продукты управленческого учета внутри себя содержат некий план счетов, стандартные двойные проводки и т.п., но частично скрывают эту структуру от пользователя, чтобы не путать его терминологией и т.п. В противопоставление управленческому можно поставить регламентированный, т.е. тот, который нам регламентируют, по которому есть регламент и т.п., например инструкция по бухучету, утвержденный кабмином план счетов и т.п.
Пример управленческого учета — пользователь ведет деятельность от имени «Бюджетного автомата» (вебмани), т.е. «в серую», или от имени оффшора. Его учет никак не регламентирован. Бухгалтерские решения для такого пользователя будут очень громоздкими и тяжелыми. Редактировать же руками готовую конфигурацию будет не менее сложно, слишком много надо удалять, резать связи между сущностями… брр… и все равно будет что-то несуразное.
При этом сами принципы бухучета вполне себе удобны для учета собственных средств, и порядка с финансами.
У нас может быть много денег или много других активов, при этом может быть много долгов… Долги эти разделяются на те что надо платить уже, скоро или нескоро… всё это влияет на наши решения по различным сделкам. И всё это хочется видеть в удобном виде…
Второй пример — у предприятия есть регламентированный учет, но в реальности деятельность ведется от имени нескольких лиц. Например общепит часто имеет ИП для продажи еды, и безалкоголя, и юрлицо для алкоголя. Или группа СПД (украинский аналог ИП, не знаю есть ли такая практика в РФ, налогообложение ИП не знаю) используется для продажи в розницу, а склад и опт идут от имени юрлица. Иногда двух или трех юрлиц.
У каждого лица своя бухгалтерия, даже если они в одной базе, они относительно самостоятельны. Просто сложить их не получится, ведь у нас есть множество операций внутри нашей группы, и для управленческих решений это будет лишним, часто хочется видеть реальную картину, что пришло, что ушло, кому заплатили, от кого получили… кому должны, кто должен… без учета внутренних отношений, только внешние движения, общая сумма активов и т.п…
Частным случаем управленческого учета является черная бухгалтерия. Но это не единственное и не основное назначение.
Для всего этого нужен управленческий учет.norguhtar Автор
12.06.2015 15:24Непонимание бухучета это проблема не бухучета или того кто не понимает, а того что нет адекватных материалов. может есть какие-то популярные статьи или учебники (наверняка есть), но в основном пишут просто сухие факты, от которых нифига не понятно. Я разобрался с бухучетом только когда потратил два часа на написание заметки в стиле «давайте изобретем бухучет», разбираясь зачем сделано так, а не иначе… Читая сухую информацию из справочника или википедии мы обычно пытаемся спроецировать ее на наше обычное понимание, и получается каша.
Вот это уж точно. Мне так же пришлось убить много времени для понимания что там и как. А так же собственно большиство бухгалтеров что с этим работают к сожалению воспринимают схему как «это дано нам свыше». Такая библия вида если делать так то все будет хорошо :)
Для всего этого нужен управленческий учет.
Ага это вы про BI. Так понятнее стало. Ну вот в том что вы описали как раз таки есть посыл к тому чтобы управленческий учет был независимым и от биллинга и от бухгалтерии. Так-как он должен увязывать в одну систему кучу разнородной информации из разных систем, для получения аналитики. Таким образом тащить управленческий учет в какую либо систему вообще губительно. Это как раз таки должна быть отдельная система с возможностью простого подключения источников данных.Mendel
12.06.2015 15:37Это как раз таки должна быть отдельная система с возможностью простого подключения источников данных.
А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Единственный смысл, если биллинг и управ.учет делается на разных технологиях. Типа биллинг смотрит в Интернет, а внутренняя часть работает в виде компилируемого приложения а не в интранете…
большиство бухгалтеров что с этим работают к сожалению воспринимают схему как «это дано нам свыше»
Ага. Сначала он не может ответить почему собственный капитал это пассив, потом почему убытки это актив, а потом смотрит в баланс и ничего не видит. Но зато точно знает как правильно его составить :)
Собственно поэтому руководителю приходится изучать бухучет, чтобы хоть на пальцах подсказывать бухгалтеру о том, что одну и ту же операцию можно провести по разному, получив разный результат…norguhtar Автор
12.06.2015 16:06А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Есть причем довольно большой. Это позволит не иметь привязку управленческого учета к биллингу.Если делать управленческий учет в биллинге, то придется и добавление других источников расходов/доходов. Плюс это позволит сделать биллинг и управленческий учет более управляемым. У меня помнится тоже были мучения делить биллинг и CRM или нет. В итоге вышло что все же делить. Точек функционала оказалось довольно много.
Единственный смысл, если биллинг и управ.учет делается на разных технологиях. Типа биллинг смотрит в Интернет, а внутренняя часть работает в виде компилируемого приложения а не в интранете…
Или биллинг как источник данных может меняться.
Mendel
12.06.2015 16:54Ну я скорее не про управленческий учет в биллинге а про биллинг в управленческом учете :)
Но вообще попробую примерить на себя мысль о том, что биллинг это не просто урезанный учет денег.
Может она и имеет право на жизнь :)norguhtar Автор
12.06.2015 17:55На самом деле эта часть там нужна чтоб все было корректно :) А вот кроме этого еще есть механизмы начисления, хранения информации о клиентах, технологические данные и т.п. И в итоге учет денег там хотя и важная часть но составляет где-то 30-40% от предоставляемого функционала.
northbear
19.06.2015 12:00>> А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Для нужд управленческого учета информация по каждому клиенту попросту не нужна. Минимальная разбивка агреггированные данные по категориям клиентов, например: Физлица/Юрлица, Частный сектор/Микрорайоны/сельская местность и так далее… Причем это разбивка может меняться в зависимости от принятой учётной политики, маркетинговых целей и кучи всего остального чуть ли не каждый год, а то и чаще…Mendel
19.06.2015 17:01А как вы ее считать будете «каждый раз разная», если исходной инфы не будет?)
Нужно очень много математики для маркетинга. И АВС-отчет, и анализ себестоимости в разрезе… много чего.
Extrapolator
13.06.2015 11:52+1Ага это вы про BI.
Небольшое уточнение. BI — это Business Intelligence, целью которого является обработка по большей части неструктурированных (и часто даже нефинансовых) данных. А управленческий учет — это Managerial Accounting. И там, кстати, есть вполне стандартизированные методики, которые легко ложатся на данные из биллинга и бухгалтерии.
northbear
19.06.2015 11:51Биллинг — это прежде всего система обслуживания клиента. Он относится к УУ и БУ как один из инструментов, источников информации…
Попытка сделать её непосредственной частью системы управленческого учета (или бухгалтерского) приводит к нездоровому усложнению системы. Применение бухгалтерских терминов лишь усугубляет неправильное восприятие, тут вы правы.
vovochka404
11.06.2015 05:03+1Офтоп, конечно, но эти id_xxx меня протос убивают.
Прям интересно стало сколько людей придеживается написания xxx_id, а сколько id_xxx
И откуда ноги ростут у этого дела? :)norguhtar Автор
11.06.2015 06:15-1Я подозреваю из естественного языка. Смотрите в русском языке:
идентификатор объекта (типа начислений и т.п.)
Отсюда id_object
В английском языке строго наоборот:
Object id
Отсюда object_idvovochka404
11.06.2015 08:00+1Но ведь в итоге пишется все на английском языке, и было бы естественее использовать второй вариант :)
norguhtar Автор
11.06.2015 08:16-1Мне привычнее id_object. Никто вам не мешает изменить в своей схеме как привычнее вам. Просто не забывайте описывать это в документации.
Extrapolator
11.06.2015 10:32Нужно еще учесть, на чем будет основное приложение работать. Например, RubyOnRails и Django (и наверное все остальные фреймворки) используют только *_id. Переконфигурить их на использование варианта с id_ — не сказать, чтобы невозможно, но достаточно сложно и это будет выглядеть ugly as hell.
norguhtar Автор
11.06.2015 10:53-2Нужно еще учесть, на чем будет основное приложение работать. Например, RubyOnRails и Django (и наверное все остальные фреймворки) используют только *_id.
Ну вот честно, я не рассматриваю ORM которые не умеют нормально работать с базой и требуют обязательную генерацию БД от кода.
vovochka404
11.06.2015 07:55Честно говоря, со скидкой нифига не понял.
Она действует на весь лицевой счет, а не на конкретную услугу?
Или как?
И что, на каждое начисление создается еще и позиция в discount дабы отрозить скидку на это начисление?
Не проще ли эту информацию сразу в начислениях хранить?norguhtar Автор
11.06.2015 08:14Честно говоря, со скидкой нифига не понял.
Она действует на весь лицевой счет, а не на конкретную услугу?
Или как?
А никак :) Схема определяет только что скидка предоставляется на конкретное начисление. То каким образом она предоставляется тут нет :)
И что, на каждое начисление создается еще и позиция в discount дабы отрозить скидку на это начисление?
Не проще ли эту информацию сразу в начислениях хранить?
Да на каждое начисление. Нет не проще. Фишка в том что в случае если скидка идет отдельным документом, то добавлять или аннулировать скидку вы можете отдельно. К тому же если к примеру у вас клиенту предоставляется несколько скидок, нет проблем с пониманием откуда и как она возникла. В случае если позицию discount отобразить в начисление проблема у вас такая будет. Так же это препятствует некорректному наложению скидок. При такой схеме скидку по начислению уже по скидке как сами понимаете сделать нельзя.
Xelonic
11.06.2015 07:56Про ввод остатков, что мешает делать их фиктивными платежами с соответствующим типом?
norguhtar Автор
11.06.2015 08:15Остатки стоит явно выражать. К тому же у вас может быть еще не только положительный остаток, но и отрицательный. А вводить отрицательные платежи крайне плохая идея.
Первоначально я так же хотел сделать. Но в итоге отверг эту идею.
MisterX
11.06.2015 12:29В схеме немного не понял. А как к договору привязываются услуги? Не само начисление, а именно какую услугу следует начислять. Например есть «Услуга1», «Услуга2». Должна же быть таблика которая указыват что «Договор 1» использует «Услуга 2», «Договор 2» использует «Услуга 1» и «Услуга 2» одновременно.
norguhtar Автор
11.06.2015 12:40Смотрите опрос последний пункт. Тут нет части которая говорит по каким критериям начисляем. Эта схема говорит как хранить.
MisterX
11.06.2015 13:00Спасибо. Было бы интересно и 1-й пункт, хотя бы на уровне SQL, по каждому действию. И последний пункт =)
Какую литературу можно почитать по архитектуре АСР?norguhtar Автор
11.06.2015 13:06Какую литературу можно почитать по архитектуре АСР?
А нету ее. Опять же это стык разных по сути дела предметных областей. Встречаются тут бухучет, программирование и та предметная область для которой делается АСР. Самая главная тут вещь все же бухучет. Так что его курить строго рекомендую.Xelonic
11.06.2015 13:38Предметная область всегда играет наиболее важную роль, она может принести очень много специфики в чарждах, тарифах, скидках да вообще во всем начиная с самой структуры.
VProtoss
11.06.2015 22:41Соглашусь, предметная область очень сильно влияет на способы расчета стоимости услуги. От разницы в пред и пост оплатной системы до индивидуальных способов расчета налогов (другая страна/вип-клиент, и т.д.)
norguhtar Автор
12.06.2015 07:48И да и нет. Может принести в вопросе сколько и в какое время. А вот как разместить в БД будет в целом одинаково. Попробуйте сами придумать такую специфику, чтобы приведенная схема не работала.
MisterX
11.06.2015 13:51Ну на сколько я понимаю, основа в принципе одинакова. Учет расчета с клиентами согласно оказанных услуг? В принципе и ваша схема, на сколько я понимаю, для того и выложена как основа. Потому думал может есть где почитать, посмотреть на практики других людей в этой сфере.
VProtoss
11.06.2015 22:35ИМХО, Смысл АСР (биллинга) в том, чтобы посчитать, сколько стоит услуга для клиента в разрезе различных параметров: скидки, акции, бонусы, выходные/праздники, и т.д. от менеджеров, если есть необходимость, себестоимость услуги, либо её стоимость от сторонних поставщиков. Соответственно, в АСР должна быть система учета данных услуг с тарифными планами и прочим. Вне зависимости от предметной области. У Вас же представлена только та часть, что отвечает за фин. документы, дело полезное, но для полноценной АСР маловато будет. Для примера, из моего опыта (работаю биллингистом в ТТК), из предметной области телекоммуникаций. Абонентская плата за услугу, по конкретному тарифному плану, с изменением статуса абонента при уходе баланса в минус, и просьбе абонента о доверительном платеже (допустим, 15 рублей), включает абонента на 10 дней до реальной оплаты АП. Сколько таблиц нужно добавить в Вашу схему, по Вашему мнению?
norguhtar Автор
12.06.2015 07:52ИМХО, Смысл АСР (биллинга) в том, чтобы посчитать, сколько стоит услуга для клиента в разрезе различных параметров: скидки, акции, бонусы, выходные/праздники, и т.д. от менеджеров, если есть необходимость, себестоимость услуги, либо её стоимость от сторонних поставщиков. Соответственно, в АСР должна быть система учета данных услуг с тарифными планами и прочим.
Это будет. Так-как текущая схема отвечает только как хранить.
У Вас же представлена только та часть, что отвечает за фин. документы, дело полезное, но для полноценной АСР маловато будет.
Проблема в том что у кучи АСР эта часть просто ужасна и работать с ней сложно и приходится постоянно заниматься какой-то эквилибристикой чтобы начисления прошли как требуется.
Абонентская плата за услугу, по конкретному тарифному плану, с изменением статуса абонента при уходе баланса в минус, и просьбе абонента о доверительном платеже (допустим, 15 рублей), включает абонента на 10 дней до реальной оплаты АП. Сколько таблиц нужно добавить в Вашу схему, по Вашему мнению?
В пределах 10Mendel
12.06.2015 13:14Если я правильно понимаю, то в нормальной структуре это одна таблица (и то, если ничего похожего еще нет), с данными документа типа «Доверительный платеж», который дебетует активный счет «долг клиента А» и кредитует пассивный счет «абонентский счет клиента А». Изменение статуса мне не очень понятно зачем, но это отдельное поле у клиента.
norguhtar Автор
12.06.2015 13:45Если я правильно понимаю, то в нормальной структуре это одна таблица (и то, если ничего похожего еще нет)
Я про комплекс говорю из тарифного плана, статуса клиента, доверительного платежа, а так же связок с абонентскими платами и услугами входящими в тарифный план. Ну и да «доверительный платеж» не должен проводиться как документ и как-то влиять на баланс клиента. Это отдельная сущность которая просто учитывается при начислении и включении клиента. Так-как это не настоящие деньги и проводку по ним делать точно не стоит.
Изменение статуса мне не очень понятно зачем, но это отдельное поле у клиента.
Вообще не поле. А отдельная таблица состояний. Это требуется для корректного начисления и перерасчета услуги.Mendel
12.06.2015 15:19А почему собственно деньги «ненастоящие»?
Вполне себе настоящие. Просто клиент их у нас «одолжил».
Вывести из системы их нельзя, пока не погасишь долг. Но потратить можно как и обычные деньги на счету.
Собственно чтобы не городить специфичные механизмы «активации пользователя», «особых статусов» и прочего проще считать их как отдельный вид пополнения. А дальше включается обычный механизм продления услуг и т.п.
Да, ваш план счетов ограничивает вас с учетом долга. Но Вы можете его учесть в отдельной таблице, аналогично с деньгами на счету клиента. Просто больше таблиц, ничего страшного.
Документ же нужен не только для учета, но еще и как основание для движения при возврате денег.
Например не сложно будет сделать такую логику работы такой услуги:
доверительный платеж может быть на любую сумму в пределах 10% от суммы которую клиент уже успел нам заплатить за прошлые периоды.
При этом возвращать клиенту нужно будет на 10% больше.
Гасится долг либо при следующем пополнении счета, либо если пополнения не было, то через 15 дней после платежа, сумма вычитается со счета клиента, делая его отрицательным.
Повторный доверительный платеж без погашения прошлых невозможен.norguhtar Автор
12.06.2015 15:34А почему собственно деньги «ненастоящие»?
Вполне себе настоящие. Просто клиент их у нас «одолжил».
Ненастоящие. Настоящие выражены в начислении и являются основанием к примеру подать на клиента в суд в случае если он не погасит задолженность. А вот доверенный платеж нельзя взыскать с клиента. Плюс придется городить отдельный механизм чтобы у нас нигде это не учитывалось в отчетах. И это сложнее для понимания клиентом. У меня вообще скажем негативное отношение к таким доверительным платежам, так-как как правило их механизм сводится к тому чтобы сдвинуть сроки оплаты. И в таком случае проще сделать другой механизм который позволял бы клиенту работать в кредит на то количество дней которое он запросил.
Собственно чтобы не городить специфичные механизмы «активации пользователя», «особых статусов» и прочего проще считать их как отдельный вид пополнения. А дальше включается обычный механизм продления услуг и т.п.
Фишка в том что другие статусы все равно будут :)
доверительный платеж может быть на любую сумму в пределах 10% от суммы которую клиент уже успел нам заплатить за прошлые периоды.
При этом возвращать клиенту нужно будет на 10% больше.
Гасится долг либо при следующем пополнении счета, либо если пополнения не было, то через 15 дней после платежа, сумма вычитается со счета клиента, делая его отрицательным.
Повторный доверительный платеж без погашения прошлых невозможен.
Скажем никто не мешает делать это и без отображения доверительного платежа клиенту. И да заплатить больше не получится, так-как начисление за услуги идет отдельно.
RomanPyr
28.06.2015 19:16Про доверительный платёж. По сути это кредитование клиента.
Если у вас по договору авансовая система расчёта, то да, в суде не взыщите.
А если кредитная, то очень даже (правда из-за размера суммы малорентабельно да и имиджевые потери).
Так что с одной стороны — это не «ненастоящие деньги», с другой — нет никакого счёта «долг клиента».
Есть субсчёт для учёта расчётов с Васей Пупкиным, открытый к 62 счёту. И этот субсчёт может иметь как дебетовое, так и кредитовое сальдо.
la0
Спасибо за статью.
Я, конечно не делал совсем сложных биллингов, но биллинги делал и вполне успешно, и вот какое у меня сложилось ощущение: схема перегружена.
Возможно стоит сделать сущность «счёт» в значении invoice (а уже в счёте куча invoice_items со своими свойствами типа цены, ставки НДС, закрытия позиции актами/фактурами и т.д, в этих же invoice_items учитывать скидки, items завязывать на services).
Пополнение баланса — счёт с соотв. отметкой. При этом естественно оплаты учитывать отдельно (у примеру, половина пришла в одной банковской транзакции, половина в другой или вообще налом/взаимозачётом)
Перевод средств между договорами — счёт с соотв. отметкой с двух сторон.
Любая коррекция баланса — только через txn и отметкой о новом балансе и сумме.
Соответственно к транзакции и вяжется что это за транзакция (к примеру, отмена прошлой транзакции)
Обороты можно считать из транзакций (предусмотреть отметку включать в обороты или нет)
Может я где-то и не прав, но в первом приближении мне это видится вот так
norguhtar Автор
Так и сделано. В счёт входят проводки. Через тип проводки берется первичный документ, который и отображается в стчет.
Счет это счет, а платеж это платеж. Не надо мешать разные сущности. Проводки не так просто добавлены.
Ага в итоге вы получаете мою же схему вид в профиль. Только без попыток уложить все документы в один счет.
Обороты и так считаются из транзакций это агрегативная таблица. Про пометку честно говоря не понял. Зачем это?
Пока я вижу что вы пытались в счет положить все первичные документы. :)
la0
Надо учитывать еще и стоимость поддержки всего этого.
Я сам очень люблю «реляционно-правильные» схемы, но как дело доходит до программирования начинается непропорциональный полезности рост трудозатрат с ростом количества технических таблиц…
> Счет это счет, а платеж это платеж. Не надо мешать разные сущности. Проводки не так просто добавлены.
Да, счет это счет, а платеж это платеж. Совершенно согласен. По счёту может быть и пять и десять платежей.
Я исхожу из того, что бизнес-взаимодействие идёт от счёта (или у вас ситуация не такая?).
Мне кажется, что по хорошему биллинг вообще не должен ничего знать про бухучёт. Бухгалтерии проще и удобнее работать с 1С, а пользователя биллинга со стороны клиента едва ли интересует что-то кроме непосредственно параметров услуг и закрывающих документов.
Как правильно заметили ниже, реализацию «российской специфики» проще делать как «интеграцию с 1с». Чаще всего смысл написания еще одной 1С неясен. Да и есть такая болезнь, что когда решают «1с нам не нужен, у нас всё в биллинге», приходится пилить расчёт зарплаты, отпускных, большичных и т.д., что пожирает ресурсы.
norguhtar Автор
Что отображено через таблицу покрытия платежами.
Вообще бизнес-взаимодействие идет от услуги. Счет это следствие или желания ее потребить или фактического ее потребления.
А тут и нет бухучета. В бухучете существенно больше сущностей. И да замечу, что к примеру проводки, левая правая сторона учета и т.п. обычный пользователь и не увидит. Единственное ухо которое может увидеть пользователь это остатки. Но тут есть хитрость. Эту часть будет видеть только тот пользователь, что у вас является бухгалтером и для него это понятные термины.
Еще раз задаю вопрос где тут «российская специфика» и vat и invoice внезапно есть не только в России.
Extrapolator
Поддерживаю, мне тоже схема кажется слегка перегруженной. И очень завязанной на российский бухучет, а не на бизнес смысл. Если система будет использоваться только в России, то все ок, однако если в будущем планируется выход в другие страны, то тогда все будет очень печально.
И еще, для различных отчетов и аналитики можно не создавать специальные таблицы (типа bill.saldo), для этого прекрасно подходят materialized views.
norguhtar Автор
Ребят принимается адекватная критика, а не ощущения.
Можно пояснить каким образом добавление документа НДС и одного поля для включения в начисление НДС стало привязкой к российскому бухучету? Тут как раз таки нет привязки. Если внезапно вам надо будет за рубежом продавать услуги с VAT ничего особо не поменяется, если без VAT ну тогда просто у вас bill.vat документов не будет и все.
Это зависит от возможностей РСУБД. К примеру PostgreSQL их поддерживает весьма ограничено, а MySQL не поддерживает совсем.