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

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

В итоге сейчас уже имея довольно большой опыт работы с АСР я решил сделать свою схему. Но так-как я все же один человек, то ее стоит показать другим и подвергнуть критике. Так что я надеюсь их эта тема заинтересует и они мне расскажут что еще стоит сделать и как. Схема которую я публикую здесь, уже подвергнута улучшениям и корректировкам, а так же уже есть возможность скачать ее с 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) — таблица с агрегированными данными по оборотам привязанная к периоду. Весьма часто используется в различной аналитике.

Что такое биллинговая система простыми словами

Каждый раз, когда вы куда-то звоните, скачиваете страничку из Интернета, отсылаете СМС или просто смотрите телевизор, где-то, далеко от вас, работает биллинг. Для чего он нужен? Прежде всего, чтобы вести строгий учёт всем предоставленным услугам. Собранная информация первична. На её основе формируются начисления за предоставленные услуги и выставляются счета. Как правило, эта информация долго и надёжно хранится, ведь абонент, в любой момент, может потребовать подробную детализацию по сформированным начислениям, чтобы сверить её с полученными услугами. Вы, как потребитель услуг, можете посчитать функции биллинга вторичными или даже вредными, для себя лично, но подумайте вот о чём. Без биллинга весь этот бизнес просто не будет работать.

Итак, вы собрались продавать услуги — интернет-трафик, телефонию или вообще какой-то рекламный контент, не важно. Вам нужен биллинг. В любом случае, предоставленные услуги должны учитываться. Что биллинг умеет? Довольно много. Часто, собранная информация нуждается в предварительной обработке. Обычно, просто потому что её очень много. Для того, чтобы биллинг работал, собранные данные агрегируются, делаются более компактными.

Затем, в дело включается тарификатор, выполняя оценку собранных данных — перевод всего в деньги. Тарифицировать можно всё что угодно: продолжительность предоставления услуги, потребленный трафик, количество оказанных услуг. Сами тарифы могут быть очень сложными: стоимость услуги может зависеть от времени суток, различные направления в телефонии могут иметь разную стоимость, тарификация может вестись по преобладающей услуге. Кроме того, существуют различные скидки, бонусы и прочие акции, придуманные маркетинговым отделом. И всё это может меняться, едва ли не каждый день. Чтобы удержать потребителя, бизнес, а значит и тарификатор, должен быть очень гибким. Кстати, для работы самого маркетингового отдела, постоянно требуются отчеты. Всегда разные. С маркетингом не соскучишься.

Но вот, начисления сформированы. На этом всё? Конечно нет. Услуги могут предоставляться по условиям пред- или постоплаты. Если с постоплатой более-менее понятно, то с предоплатой всё гораздо сложнее. Биллинг должен контролировать состояние лицевых счетов абонентов, выполнять списания с них начислений в реальном времени и блокировать предоставление услуг, в момент исчерпания средств. Это важно, ведь может оказаться так, что за услугу предоставленную сверх имеющихся у абонента средств, платить придётся владельцу бизнеса, из своего кармана. А ещё, абонента крайне желательно предупреждать заранее об исчерпании средств и гибко управлять доступом к услугам, в зависимости от состояния его лицевого счета.

Остались сущие мелочи: сформировать счета, довести их до абонентов и получить деньги. Это просто, если абонентов немного, но, в большинстве случаев, для одной только печати счетов абонентам могут потребоваться услуги небольшой типографии. С получением денег тоже не всё гладко. Прежде всего, деньги — это строгая отчётность. Наличные должны быть проведены через кассу и фискализированы. Безналичные перечисления — это эквайринг с самыми разнообразными банками. Даже самый простой заявленный платеж требует функционирования личного кабинета. А личный кабинет — это современное web-приложение с надежной и безопасной авторизацией, например через ЕСИА. Как правило, для него разрабатываются мобильные приложения, как минимум для двух платформ: iOS и Android. И конечно, все данные по платежам должны быть переданы в бухгалтерскую систему.

Современный биллинг

Современный биллинг — это сложная, постоянно развивающаяся система, интегрированная со всеми системами предприятия: CRM — для работы с клиентами, ERP — для управления предприятием, SCADA — если речь идёт о промышленном производстве, бухгалтерией и аналитическими системами. Часто, биллинговая система интегрирована с системами управления оборудованием, предоставляющим доступ к услугам конечным потребителям. Биллинг — интеграция с банковскими системами эквайринга и Госуслугами, это личный кабинет и мобильные приложения. Биллинг — система, которая хранит и обрабатывает самые важные для бизнеса данные и делает это быстро и надежно. Если биллинг остановится, бизнес тоже перестанет работать.

Другие статьи

Область применения систем биллинга

Биллинг успешно внедряется в различные сферы бизнеса, позволяя автоматизировать .

Биллинговая система компании

Каждая современная компания заинтересована в расширении клиентской базы. Для учёта потребностей клиентов, оптимизации расчётов и процесса получения дохода необходимы специальные инструменты, объединённые в систему. Именно эту функцию и выполняет биллинг.

Где используются биллинговые системы?

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

Биллинговые системы используются в качестве автоматизации бизнес-процессов в компаниях с различной спецификой деятельности:

• Энергетика – с помощью платформы автоматизируются взаиморасчёты с потребителями услуг любого масштаба, от одного предприятия или учреждения до целого города или даже региона. Биллинг позволяет правильно рассчитывать мощности, обрабатывать оперативно огромные массивы данных, при необходимости корректировать тарификацию;
• Логистика – биллинговые системы используются для формирования счетов для клиентов, подбора оптимальных тарифных планов с учётом различных критериев, точной и безопасной работы с крупными базами данных, содержащих сведения обо всех партнёрах, грузах, транспортных средствах и перевозках;
• Жилищно-коммунальное хозяйство – биллинговая система оплаты знакома всем по платежкам за ЖКУ. Именно такая платформа подсчитывает сумму для каждого абонента, исходя из площади жилья, количества прописанных людей, объёма потреблённых услуг, установленных нормативов, имеющихся льгот и всех остальных характеристик;
• Страхование – биллинг нужен для управления подписками на страховки и полисы, контроля взаиморасчётов с медицинскими учреждениями, списания платежей, обработки клиентских заявок.

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

Функции и возможности систем биллинга

Принцип работы систем биллинга всегда одинаков: для каждого клиента выполняется расчёт стоимости услуг, в базе сохраняется вся информация о тарифах, начислениях, платежах и прочих операциях. Но при более подробном рассмотрении выясняется, что платформы легко адаптируются практически к любому формату ведения бизнеса и выполняют множество полезных функции:

• Учитывают реально оказанные услуги;
• Обеспечивают удобство ведения взаиморасчётов с агентами, дилерами, поставщиками, партнёрами, а не только с клиентами;
• Упрощают работу с дебиторской задолженностью;
• Позволяют работать через единую систему с разными способами оплаты, предоставлять различные услуги;
• Обеспечивают формирование клиентской базы, включая юридических и физических лиц;
• Помогают выявить нарушения и злоупотребления со стороны плательщиков и персонала компании;
• Дают возможность потребителям отслеживать расчёты за услуги;
• Могут использоваться в работе с бонусными программами, сложными тарифными планами и прочими нетипичными условиями.

Неудивительно, что биллинговые системы связи давно вышли за пределы телекоммуникационной сферы и стали достойной технологической базой для развития клиентоориентированного подхода, повышения лояльности потребителей, привлечения новых клиентов, управления доходностью услуг.

Преимущества биллинговых систем

Помимо всего вышеперечисленного, системы биллинга обладают и другими преимуществами, которые обеспечили их широкое распространение. Это, например, возможность интеграции с платёжными системами, в том числе формата «Банк-Клиент», платформами финансового учёта, системами ERP и OSS. Важным плюсом является возможность комбинировать услуги и создавать предложения, ограниченные во времени.

Биллинговые системы имеют модульную конфигурацию. Они состоят из подсистем, каждая из которых выполняет свою задачу. Благодаря многочисленным настройкам, платформы позволяют не только решать существующие задачи, но и ориентироваться на перспективу. Масштабируемость систем даёт возможность адаптировать их к появлению новых услуг, расширению клиентской базы и других изменений без доработки программной части.

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

Другие статьи

Внедрение биллинга в компании: выгоды, основные этапы и возможные сложности

Применение биллинга позволяет автоматизировать и оптимизировать многие бизнес-пр.

При подготовке материала использовались источники:
https://habr.com/ru/articles/259921/
https://te-net.io/articles/chto-takoe-billing/
https://te-net.io/articles/billingovaya-sistema-kompanii/