Типовая схема биллинга +13


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

В итоге сейчас уже имея довольно большой опыт работы с АСР я решил сделать свою схему. Но так-как я все же один человек, то ее стоит показать другим и подвергнуть критике. Так что я надеюсь их эта тема заинтересует и они мне расскажут что еще стоит сделать и как. Схема которую я публикую здесь, уже подвергнута улучшениям и корректировкам, а так же уже есть возможность скачать ее с github. Как в виде файла для Power Architect так и в виде готового DDL файла для PostgreSQL. Единственное я не успел еще заполнить справочники, но всему свое время. А сейчас переходим к схеме.

Первым делом стоит посмотреть на ER-диаграмму, как наиболее удобное средство представление схемы.

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) — таблица с агрегированными данными по оборотам привязанная к периоду. Весьма часто используется в различной аналитике.

И на этом все. Если вас не затруднит ответьте на опрос. Результаты будут учтены при написании следующего в серии поста :) Ну и задавайте свои вопросы в комментариях.
Что вы хотите еще?

Проголосовало 116 человек. Воздержалось 34 человека.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.




К сожалению, не доступен сервер mySQL