Как человек, утомленный различными ASR и сам принимавший участие в разработке ASR, я регулярно сталкивался с отсутствием какой-то стандартной схемы, на которую можно было бы посмотреть для оценки ASR, в том числе перед созданием своих собственных ASR. В Интернете есть ряд работ на эту тему, например, когда я писал диссертацию, я изучал эту работу Методы моделирования и разработки биллинговых систем .
Диплом - это всего лишь диплом, и тащить из него схемы - странная задача, так как она не соответствует действительности.
В итоге, имея уже достаточно большой опыт работы с АКП, я решил сделать свою схему.
Но поскольку я все еще один человек, стоит показать это другим и покритиковать.
Так что я надеюсь, что эта тема их заинтересует и они подскажут мне, что еще надо сделать и как.
Схема, которую я здесь публикую, уже подвергалась доработкам и корректировкам, а также ее можно скачать с сайта github .
И как файл для Power Architect, и как готовый DDL-файл для PostgreSQL. Единственное, что справочники заполнить пока не успел, но всему свое время.
Теперь перейдем к схеме.
Первый шаг — рассмотреть диаграмму ER как наиболее удобный способ представления схемы.
Как видите, хотя таблиц довольно много, на самом деле функционал довольно небольшой.
И состоит из следующих функций:
- Хранение договора клиента и поддержание его баланса
- Хранение услуг и ведение их стоимости
- Осуществление оплаты за оказанные услуги
- Предоставление скидок
- Осуществление платежей
- Перевод средств из контракта в контракт
- Ввод балансов по клиентам при их переносе из другой системы
- Хранение счетов клиентов
- Погашение счетов
Но прежде чем перейти к описанию, стоит упомянуть об условных обозначениях, использованных в схеме:
- Все внешние ключи имеют формат _ .
Если внешних ключей несколько или они указывают на саму таблицу, допускается дополнение к названию типа.
идентификатор_ _ или идентификатор_ .
Например, id_trx_from, id_trx_to для первого случая и id_revoke , id_revokedby для второго случая в таблице bill.transfer.
- Денежные поля определяются как числовые (18,4).
Такие ключи обозначаются как sid. Используется исключительно для удобства при работе с данными непосредственно через консоль СУРБД.
А теперь описание слайдов.
Справочные таблицы: Контракты (bill.contract) — минимальное описание контракта, необходимое для использования.
Проводки (bill.trx) — Журнал выполненных транзакций.
Фактически это сумма денег, пришедшая или ушедшая со счета.
Используемая сторона бухгалтерского учета (bill.ledgertype) — указывает, куда идет проводка (дебет, кредит).
Отчетные периоды (билл.
период) – отчеты не являются периодами в бухгалтерском смысле этого слова.
Хотя он содержит дату начала и дату окончания, на самом деле он всегда равен месяцу.
Счета-фактуры, выставленные клиенту (bill.invoice), — это те же счета, которые выставляются клиенту за отчетный период. Хотя этих таблиц вполне достаточно для биллинга, для удобства добавлены таблицы первичных документов.
Первичные документы – это те документы, на основании которых производятся записи по договору клиента.
На данный момент схема содержит следующие первичные документы: Остатки (bill.remain) — входящие остатки из другой системы.
Эти документы должны быть всегда доступны, иначе при миграции с другой системы вы никогда не узнаете, какой баланс был у клиента на момент миграции.
Кстати, этим страдают многие ASR, поскольку разработчики считают, что достаточно ввести баланс.
Но это не так, поскольку в обычной системе баланс клиента является расчетной величиной.
Платежи (билл.
платеж) — средства, полученные от клиентов.
Переводы (билл.
трансфер) – перевод средств со счета на счет. Сразу отмечу, что стоит явно запретить перевод средств при отсутствии средств.
Те.
если баланс клиента отрицательный, то перевод должен быть запрещен.
Платы (bill.charge) - плата за потребленные или оказанные услуги (авансом) Скидки (bill.discount) — Скидки на услуги.
Хотя в целом единого мнения о том, как выражать скидку, нет. Я считаю, что скидка должна быть выражена в денежном выражении до определенного начисления.
Это облегчает работу.
НДС (билл.
ват) – НДС по начислению, учитываемый отдельным документом.
Все проводки от начислений указаны без НДС, при этом само начисление может включать НДС.
Например, это требуется для физических лиц.
В этом случае bill.charge имеет явный флаг, указывающий, что сумма включает НДС.
В этом случае проводка начисления не включает НДС и полная сумма начисления складывается из двух проводок проводка по первичному документу начисления + проводка с учетом НДС.
Первичные документы имеют как общие поля, так и общие правила работы с ними.
Начнем с общих полей: id_contract (id_contract_from,id_contract_to) — указывает на соглашение или соглашения документа id_trx (id_trx_from, id_trx_to) — указывает проводку или проводки документа id_ period — в каком отчетном периоде проводится документ. ts — дата документа tscreate — дата создания документа.
сумма — сумма документа id_revoke — исправляемый документ. Указывает документ, который корректируется этим.
id_revokedby — корректирующий документ. Указывает документ, в котором исправлен текущий.
Подробнее остановлюсь на отчетном периоде и корректирующем и корректирующем документе.
Отчетный период. В конце месяца у вас может быть два открытых отчетных периода в связи с тем, что, например, последние дни приходятся на выходные и платежи еще не проведены в банк.
Плюс это требуется в случаях, например, когда фактическая дата документа январь 2014 года, а используемый период - июнь 2015 года, проведенный в начале июля 2015 года.
Т.
е.
в периоде июнь 2015 года, в дате создания 2 июля 2015 года и в документе дата январь 2014 года.
Из-за этого документ фактически имеет три даты.
Исправительные и корректирующие документы.
Фактически, если в вашей системе есть ошибочный документ, вы не сможете его удалить.
Его можно только отменить.
Те.
создать корректирующий документ, строго противоположный неверному документу.
Вот для чего используются эти два поля.
id_revoke - заполняется корректирующий документ, и id_revokedby у того, кого исправляют. Не рекомендуется исправлять, например, часть документа каким-либо другим способом, а также не рекомендуется удалять документы.
Вместо этого скройте такие документы, если они относятся к одному и тому же периоду.
Если документы относятся к разным периодам, то скрывать их нет необходимости.
Также обратите внимание, что транзакции не имеют таких полей; они не регулируются.
Помимо общих полей, первичные документы имеют свои специфические поля: Расходные документы (счет.плата) - считать И с НДС .
В первом указывается количество оказанных услуг, во втором указывается, включен ли НДС в сумму документа.
Документы НДС (билл.
ват) - id_charge И id_vatrate с указанием документа начисления, к которому относится НДС и какой процент НДС составлял на момент документа начисления.
Дисконтные документы (bill.discount) - id_charge с указанием, к какому сбору была применена скидка.
Остальные документы (bill.remain) - sid_ledgertype позволяющий указать учетную сторону, используемую при проводке документа.
Думаю, остальные поля понятны из контекста и выбранных названий.
На этом разговор о первичных документах заканчивается и переходим к остальным справочным таблицам.
Схема содержит следующие таблицы поиска: Типы платежей (bill.paytype) — для разделения платежей по типам.
Наличные, безналичные, платежные агенты и т.д. Единицы измерения (билл.
единица) – фактические единицы измерения используемых услуг.
Например, вы можете взять его из каталога OKEI. Самоссылка используется для единиц, включающих в себя другие.
Услуги (билл.
сервис) – наименование услуг, предоставляемых по договору.
Цены (билл.
цена) - Стоимость услуг.
Добавлены временные интервалы для учета изменений затрат. Тип проводки (bill.trxtype) — указывает тип проводки, используемый для первичных документов, а также учетную сторону, используемую по умолчанию.
Если сторона по умолчанию не указана, выбор происходит при проводке документа.
Например, это документы балансов.
А также две вспомогательные таблицы: История баланса (bill.balance) - история изменения баланса контракта с привязкой к транзакциям.
Оборот (Баланс) за отчетный период (билл.
салдо) представляет собой таблицу с агрегированными данными об оборотах, привязанных к периоду.
Довольно часто используется в различной аналитике.
И это все.
Если вы не против, ответьте на опрос.
Результаты будут учтены при написании следующего поста серии :) Ну и задавайте свои вопросы в комментариях.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Что еще вам нужно? 75,52% Узнать, как все это работает на примерах и данных 145 41,15% Получить сервисный уровень для работы со всем этим 79 39,06% Получить схему еще и для MySQL 75 58,85% Узнать о механизмах расчета абонентской платы и тарифных планов 113 Проголосовали 192 пользователя.
44 пользователя воздержались.
Теги: #Биллинговые системы #открытый код #Анализ и проектирование систем
-
Как Заблокировать Контент Для Взрослых
19 Oct, 24 -
Билль О Правах Геймеров
19 Oct, 24 -
Интернет В Провинции: Есть Ли Перспективы?
19 Oct, 24 -
Как Построить Диаграмму В Python
19 Oct, 24 -
Пенсия Ит-Специалиста
19 Oct, 24
