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


Разнообразие биллинговых систем

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

На этапе своего становления каждый оператор сталкивается с дилеммой: создать собственную автоматизированную систему расчетов (АСР) или выбрать одну из существующих. Собственная система? Это неплохо, но на ее разработку и наладку уйдет длительное время. Систему необходимо сертифицировать, а требования, предъявляемые к АСР, строго регламентированы. В итоге, правда, оператор становится полным хозяином положения: ему проще обслуживать и модернизировать систему. Однако тиражируемые АСР тоже настраиваются под потребности конкретного оператора, они не являются «коробочным» продуктом.

Оператор развивается. Разнообразие услуг, предоставляемых им, растет. Изменения, происходящие на рынке мобильной связи, требуют применения новых технологических подходов, и БС обязана «выдержать» все эти изменения (возможность модернизации должна быть заложена на этапе ее проектирования). Если оператор создает собственную систему, он знает (должен знать) свои потребности, перспективы, если приобретает «чужую» БС, то он выдвигает ряд требований к ее производителю. Заказчик обращает внимание на такое качество системы, как ее гибкость — способность приспосабливаться к изменившимся обстоятельствам. Гибкая система не адаптирована лишь к сиюминутным потребностям — она позволяет решать перспективные задачи. Для оператора важна также масштабируемость БС. Если это качество присутствует, то внедрение новых услуг будет сопряжено лишь с доработкой программной части БС и незначительной модернизацией ее аппаратного комплекса.

Недостатка в АСР нет. Сегодня мировой телекоммуникационный рынок предлагает сотни таких систем. Производители исчисляются десятками, среди лидеров: Lucent Technologies, CSG Systems. К лидерам можно отнести и израильскую компания Amdocs. Но в России зарубежные системы особой популярностью не пользуются. Возможно, это объясняется их дороговизной, возможно, трудностями, возникающими при техническом сопровождении системы и при обучении персонала. Ну и, конечно, «препятствием» может являться Минсвязи, ответственное за сертификацию подобных систем. Да и зачем использовать «забугровые» БС, если у нас нет недостатка в системах от отечественных производителей. Наша страна всегда славилась талантливыми специалистами и программистами, в частности. Среди лидеров российского рынка: Петер-Сервис, SoftPro, Форс-холдинг. Компании перечислены в случайном порядке: автоматизированная система расчетов у каждого производителя по-своему уникальна, и не мне судить, кто является лидером на сегодняшнем рынке АСР. Я лишь представлю обзор БС.

BIS от «Петер-Сервис»

Петер-Сервис (http://www.billing.ru) — это первая российская компания, внедрившая АСР собственной разработки в 1992 в компании Delta Telecom. Для своей БС компания не стала придумывать «особое» название, ограничившись аббревиатурой ИБС (информационная биллинговая система), или английский вариант — BIS (Billing Information System). Продуктами данной компании являются: ИБС для сотовых операторов стандарта NMT-450, ИБС для сотовых операторов стандарта GSM-900, ИБС для сотовых операторов, поддерживающих несколько стандартов. ИБС от Петер-Сервис установлена у таких операторов, как Дельта Телеком (NMT), Северо-Западный GSM (GSM-900). Однако деятельность компании не сводится к региональным поставкам на северо-запад России. Другие крупнейшие заказчики: Киевстар, GSM Казахстан, MOLDCELL, Kabris Mobile Telecom и т. д.Среди продуктов компании не только традиционные АСР. Существуют также решения для контент-провайдера, ISP, припейд-решения для IP телефонии, а также универсальное решение Interconnect Billing, которое в настоящее время используется Санкт-Петербургской компанией Петербург Транзит Телеком. Рамки настоящей статьи ограничивают нас рассмотрением АСР для операторов сотовой связи. Именно на них мы и остановимся подробнее.

Несомненно, система такого класса удовлетворяет всем качествам, присущим БС. ИБС обеспечивает поддержку авансовой и кредитной системы оплаты, функции горячего биллинга, учета платежей и начислений, печати счетов и контроля за их доставкой. ИБС поддерживает работу с неограниченным количеством тарифных планов, легко поддающихся модификации. Система может поддерживать действия сотрудника на рабочем месте или работать в автоматическом режиме. Обслуживание абонентов происходит в режиме реального времени (если позволяют внешние устройства). Любое изменение баланса клиента приводит к его оперативному пересчету, что позволяет оператору «не обслуживать» должников. Специальный сегмент ИБС обеспечивает интерактивную связь с отделом обслуживания; он включает в себя подсистемы обзвона (для обзвона клиентов, которые перешли через порог отключения услуг) и автоинформирования (для выдачи абонентам справок о состоянии их баланса).

Взаимодействие с внешними устройствами (коммутаторами, системами голосовой почты, центрами коротких сообщений) производится через специальную подсистему Mediation Devices. Система имеет возможность поддержки вынесенных операторов — операторов сотовой связи, не имеющих своего коммутатора, но имеющих базовые станции и использующих возможности коммутатора другого оператора.

Особенностью ИБС является возможность ее использования операторами, работающими одновременно в разных стандартах, например NMT и GSM.

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

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

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

ИБС от Петер-Сервис обладают рядом других уникальных возможностей. Система имеет открытую архитектуру. К тому же Петер-Сервис осуществляет техническое сопровождение своих БС в течение всего срока эксплуатации.

Мне понравилась политика, проводимая компанией Петер-Сервис в отношении «малых» заказчиков. Им предлагается «попробовать» АСР от Петер-Сервис и сделать выбор. Начинающим сотовым операторам или операторам с небольшим количеством абонентов (до 3000) предлагается так называемая «Малая ИБС». Система поддерживает работу оператора стандарта GSM или NMT, а также оператора, эксплуатирующего сети обоих стандартов (в этом случае система взаимодействует с двумя коммутаторами). Система двухвалютная. Услуги абонентам могут предоставляться по технологии prepaid, но возможна и кредитовая работа с клиентами. Требования к аппаратному обеспечению зависят от состава поставляемого прикладного программного обеспечения (ПО), числа пользователей и числа обслуживаемых абонентов, топологии сети и ее структуры. Оборудование, скажем так, «неприхотливо». В качестве сервера можно использовать однопроцессорный Intel Pentium 200 под операционной системой Windows NT: 64 Mb RAM 8Gb HDD. Рабочие места представляют собой персональные компьютеры Pentium 166 32Mb RAM 1Gb HDD. (У большинства читателей, я думаю, компьютер посовременнее). Если заказчик сделает свой выбор в пользу АСР от Петер-Сервис, то ему гарантирован переход (с сохранением всех данных) на более мощную ИБС.

CBOSS от «SoftPro»

Компания SoftPro, выступающая под торговой маркой CBOSS (http://www.cboss.ru), основана в 1996 году. На апрель 2001 года системы компании были установлены у 41 оператора России и стран СНГ, с помощью которых обслуживается более 2 500 000 абонентов. Концептуальная разработка компании — Конвергентная Система Операционного Обеспечения Бизнеса Связи CBOSS (Communications Business Operations Support System).

Да, система CBOSS решает не только задачи биллинга: она является программно-аппаратным решением, автоматизирующим работу предприятия связи в целом включая подразделения бухгалтерии и складского учета. Система имеет все необходимые компоненты для комплексной автоматизации предприятия связи:

  • автоматизацию продаж с регистрацией абонента в системе по стандартной или ускоренной процедуре;
  • ведение складского учета с возможностью организации «логических» складов для раздельного учета партий оборудования;
  • поддержку бухгалтерских функций с проведением платежей как в ручном, так и в электронном вариантах;
  • автоматизированное абонентское обслуживание с функцией прямого управления коммутатором, позволяющее исключить появление дебеторской задолженности;
  • исходящее автоматическое информирование абонента о балансе его счета, рекомендованной индивидуальной сумме предоплаты;
  • интерактивную систему автоматического абонентского обслуживания с обеспечением доступа абонента к информации о состоянии его лицевого счета, возможности самостоятельно изменять набор сервисных функций, передавать непосредственно в БС информацию о произведенных платежах;
  • систему оценки разговоров и выставления счетов, в том числе и в варианте «горячего» биллинга (при условии поддержки коммутационным оборудованием);
  • систему анализа финансовой, маркетинговой, технической информации;
  • систему контроля за исполнением сотрудниками предприятия служебных заданий.

Как заявляет компания, главная задача CBOSS — «освободить персонал предприятия от рутинных операций везде, где это возможно и целесообразно; заменить неэффективный ручной труд прогрессивными автоматизированными технологиями».

CBOSS базируется на СУБД Oracle. Следовательно, система является легко масштабируемой. БС CBOSS — адаптируемая система; заказчик может легко изменить полномочия пользователей, тарифы, проформу контракта с абонентами и логику работы системы в соответствии с потребностями, возникающими в процессе ее эксплуатации. Система мультивалютная и мультиязычная. CBOSS ориентирована на операторов сетей стандарта NMT, GSM и AMPS и других, а также способна работать с IP-трафиком и PSTN телефонией. CBOSS работает с коммутаторами таких компаний, как Lucent, Ericsson, Nokia, Alcatel, Qualcomm и др.

CBOSS позволяет следить за появлением «телефонов-клонов», что дает абонентам дополнительную защиту от «злоумышленников».

Компания CBOSS предлагает и ряд дополнительных продуктов, большая часть которых может работать как самостоятельно, так и в интеграции с CBOSS. Среди них я выделил следующие: цифровая Автоматическая Система Сервиса Абонентов (CBOSSacc), Интернет Система Сервиса Абонентов (CBOSSics) и система предоплаченных услуг (CBOSSprepaid). CBOSSacc ответственна за автоматизацию работы с абонентом. Она позволяет выполнять некоторые функции абонентского обслуживания (финансовый контроль, доставку счетов, изменение набора периодических услуг) в автоматическом режиме без участия оператора.

CBOSSics позволяет обслуживать абонентов через Интернет. Абонент самостоятельно со своего компьютера может контролировать баланс счета и имеет доступ к активации/деактивации дополнительных услуг. CBOSSprepaid, как видно из названия, реализует технологию услуги prepaid. Для стандарта GSM CBOSSprepaid реализует систему учета и обработки предоплаченных SIM-карт. Для стандартов NMT, AMPS/DAMPS, CDMA CBOSSprepaid реализует технологию предоплаченных телефонов. CBOSSprepaid предупреждает абонента об исчерпании лимита предоплаченного времени.

Сегодня особый интерес операторов может вызвать Интернет Система Удаленных Продаж и Обслуживания Абонентов (CBOSSisp), позволяющая дилеру осуществлять подключение новых абонентов и автоматизирующая все взаиморасчеты дилера и Оператора, а также Система Коротких Сообщений (CBOSSsms), производительность которой составляет до 100 коротких сообщений в секунду. Все подробности можете прочитать на сайте компании.Как и любая уважающая себя компания, CBOSS обеспечивает техническое сопровождение своих систем, в пределах одного года — бесплатно. Среди клиентов CBOSS такие компании, как Мобильные ТелеСистемы, Кубань-GSM, СП K'Cell, Нижегородская Сотовая Связь.

Мне продукция компании SoftPro понравилась своей оригинальностью. Привлекает разнообразие дополнительныхпродуктов: их больше десятка. Кроме пяти упомянутых выше компания предлагает также (перечислю лишь названия): CBOSSacd, CBOSSssc, CBOSSvmail, CBOSSvote, CBOSStmn, CBOSSmd, CBOSSisp off-line, CBOSSishop, CBOSSacr, CBOSSdss, CBOSSte. Все они не менее интересны по своим функциональнымвозможностям. Если вы желаете получить дополнительную информацию об этих подсистемах, то это можно сделать на сайте производителя.

Начинающим операторам CBOSS предлагает целую линейку Lite «облегченных» продуктов: Конвергентную Систему Обеспечения Бизнеса Связи Лайт CBOSS-lite и ряд других подсистем. Их приобретение позволяет небольшим операторам, не вкладывая значительные средства, предлагать абонентам фактически такой же широкий спектр услуг, какой предоставляют крупные операторы.

Fastcom от «Форс-холдинг»

Компания Форс-холдинг (Форс) еще один производитель АСР на российском рынке. Компания специализируется на разработке банковских, расчетных и промышленных систем с использованием СУБД Oracle. Тиражируемая АСР Fastcom определяется разработчиком как комплексная система автоматизации деятельности телекоммуникационного оператора. Система функционирует под управлением СУБД Oracle. Fastcom способна обслуживать до одного миллиона номеров — это значительная номерная емкость для российских телефонных сетей. Система предназначена как для сотовых сетей, так и для обычных телефонных узлов (проводная связь). Изначально система как раз создавалась для традиционной телефонной связи (местной и междугородней). Изменения на рынке предоставления услуг связи «заставили» компанию Форс модернизировать свою систему.

Сегодня Fastcom является БС для любого оператора связи, работающего с различным телекоммуникационным оборудованием. Существует также конфигурация системы для автоматизации расчетных технологий предприятия спутниковой связи — Fastcom/SART. Как заявляет компания, их БС повышает производительность труда персонала, эффективность работы руководства, улучшает качество обслуживания клиентов. В принципе, это «обязанности» любой БС такого класса. АСР Fastcom предоставляет широкий набор функций по информационной поддержке работы подразделений всех уровней. Система ведет расчеты с клиентами, в том числе и расчеты за услуги доступа к сети Интернет и IP-телефонии. Fastcom позволяет организовать расчеты по множеству тарифных планов.

Система состоит из ряда подсистем. Одна из них, «Заявки», ответственна за прием, регистрацию и сортировку заявок клиентов, работу с очередниками и льготниками, формирование нарядов, рапортов, счетов и технических справок. Подсистема «Клиенты» ведет список абонентов, договоров, тарифной базы, осуществляет просмотр заявок, договоров, услуг, льгот и ответственна за роуминг. Подсистема «Расчеты» осуществляет расчеты с физическими и юридическими лицами, а также операторами связи с учетом параметров договоров. Благодаря этой подсистеме становится возможным хранение истории платежей и выявление задолженностей. В этом участвует и подсистема «Работа с должниками», которая формирует список должников, начисляет пени с суммы долга, осуществляет автообзвон абонентов (должников и потенциальных должников). Назначение других подсистем («Взаимодействие с процессинговым центром банка», «Настройка и ведение тарифов», «Линейная бухгалтерия», «Бюро ремонта», «Работа с данными трафика») полностью соответствует их названию.

Как видим, Fastcom удовлетворяет требованиям, предъявляемым к биллинговым системам. Она масштабируема и гибка. Компания Форс обеспечивает весь цикл работ по внедрению системы и обучению персонала.

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

[ Продолжение (Часть 2) ]

www.ixbt.com

Биллинговые системы – Автоматизированны системы расчётов / Хабр

  • После долгих лет работы на проектах автоматизации биллинговых систем для крупных компаний мы решили осваивать новый рынок – SMB. Под катом делимся своими первоначальными ожиданиями, пройденным путём и результатами.

    Читать дальше →
  • Здравствуйте, дорогие друзья.

    Сегодня хочу поделиться историей из жизни, как было устроено хранилище DWH в Tele2 до внедрения КХД (EDW).

    Поступил я в ИТ подразделение Tele2 в 2012 в отдел по системам отчетности. На тот момент в компании уже было создано хранилище DWH, на котором уже крутилось много процессов по предоставлению отчетности и не только.

    Немного по поводу технического стека, который там использовался на тот момент. Для хранилища использовалась Оракловая база объемом 60-100 Тб сервер T4-4 c оперативой под 1 Тб. Туда загружались данные из различных источников. Но основными из них были 4 оракловые биллинговые базы, которые были по сути платформой тарификации. И был отдел, который занимался поддержкой этих баз и предоставлением сервисов. Разделение этих баз было по макрорегионам. Причина: слишком большие объемы. Т.е если абонент звонит, скажем, из Московской сим-карты то и расчет стоимости звонка производится в соответствующем биллинге.

    Читать дальше →
  • Для тех, кто интересуется темой автоматизации на iOS, у меня две новости — хорошая и плохая. Хорошая: в iOS-приложении для платных сервисов используется только одна точка интеграции — in-app purchases (встроенные в приложение покупки). Плохая: Apple не предоставляет никаких инструментов для автоматизации тестирования покупок. В этой статье я предлагаю вам вместе со мной поискать универсальный метод автоматизации по ту сторону добра и зла Apple. Статья будет полезна всем, кто интегрирует в свои приложения сторонние сервисы, представляющие собой «чёрный ящик»: рекламу, стриминг, управление локацией и др. Обычно такие интеграции очень сложно тестировать, так как отсутствует возможность гибкой настройки стороннего сервиса для тестирования приложения.

    Читать дальше →
  • У управленца компании-разработчика биллинга есть два пути построения команды. Первый – набрать уже готовых «сеньоров» и непрерывно создавать такие условия работы, чтобы они использовали навыки и опыт по максимуму, развивались и при этом не передрались. Второй – создать команду из микса новичков, «мидов» и профи, чтобы те общались, влияли друг на друга, учились и росли внутри компании. Я против замкнутого круга а-ля «нет опыта – нет работы – нет опыта» и не вижу проблемы в найме начинающего разраба. В Forward Telecom давно действует стажерская программа, которая стала трамплином карьеры для многих работающих сотрудников. Сейчас расскажу, как я вижу путь развития разработчика биллинга, и в какой последовательности нужно осваивать профессиональные навыки. Читать дальше →
  • В этой статье поделюсь опытом отбора идей для развития функционала наших продуктов и расскажем, как удержать основные векторы развития. Мы разрабатываем автоматизированную систему расчетов (АСР) – биллинг. Срок жизни нашего продукта 14 лет. За это время система прошла путь от первых версий промышленного тарификатора до модульного комплекса, состоящего из 18 продуктов, дополняющих друг друга. Один из важнейших аспектов долгой жизни для программ – постоянное развитие. А для развития нужны идеи.

    Идеи

    Источники Можно выделить 5 источников: Читать дальше →
  • Quorum — блокчейн на базе Ethereum, разработанный JPMorgan и совсем недавно ставший первой платформой распределенного реестра, которую предлагает Microsoft Azure.

    Quorum поддерживает приватные и публичные транзакции и имеет много коммерческих сценариев использования.

    В данной статье мы разберем один из таких сценариев — развертывание сети распределенного реестра между супермаркетом и владельцем склада для обеспечения актуальной информации о температуре складского помещения.

    Код, используемый в данном руководстве, лежит в репозитории на GitHub.

    Статья покрывает:

    • создание смарт-контракта;
    • развертывание сети Quorum при помощи Chainstack;
    • публичные транзакции Quorum;
    • приватные транзакции Quorum.

    Для иллюстрации используется сценарий мониторинга температуры в складских помещениях участников сети Quorum в рамках Internet of Things (IoT).

    Читать дальше →
  • Вся история человечества — это попытки разрушить старый порядок вещей и построить новый, разумеется, лучший. (Анонимный автор)

    В прошлой статье «Что нам стоит блокчейн построить?» мы разобрались с технологиями, на которых работают все блокчейны. Пришло время понять какие задачи могут решить современные блокчейны. Для начала давайте посмотрим на аналитику текущего состояния блокчейна и перспективах на будущее. Как техническому специалисту, мне импонирует компания Gartner с ее многочисленными циклами зрелости технологий (Hype Cycles). На графике показан цикл зрелости блокчейна в бизнесе на конец 2018 года. Какие выводы можно сделать?

    Читать дальше →
  • «Цифра» идет в телеком, а телеком идет в «цифру». Мир стоит на пороге четвертой промышленной революции, а российское правительство проводит масштабную цифровизацию страны. Телеком вынужден выживать в условиях радикальных изменений в работе и интересах клиентов и партнеров. Растет конкуренция со стороны представителей новых технологий. Предлагаем посмотреть на вектор digital-трансформации и обратить внимание на внутренние ресурсы для развития бизнеса операторов связи. Читать дальше →
  • На протяжении многих лет Netcracker является вендором продуктов для телеком-операторов, и в то же время выступает как интегратор всего комплекса операторского ПО. В этой работе неизбежно возникает задача синхронизации и координации большого количества версий продуктов и решений, в разных комбинациях, от разных разработчиков и с разным функционалом. Многие операторы сознательно избегают зависимости от одного поставщика, создавая зоопарк продуктов разных вендоров, так что в достаточно сложном сценарии может быть задействовано до пары десятков разрозненных систем и процессов. Читать дальше →
  • Вся история человечества — это непрерывное избавление от цепей и создание новых, еще более крепких. (Анонимный автор) Анализируя многочисленные blockchain проекты (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin и др.), я понимаю, что с технической точки зрения все они построены по одним принципам. Блокчейны напоминают дома, у которых при всем разнообразии конструкций, декора и назначений имеются фундамент, стены, крыша, окна, двери, которые связаны друг с другом определенными способами. И если понять основные принципы проектирования зданий, знать свойства применяемых материалов, то можно определить целевое назначение конкретного дома. В настоящее время с блокчейном возникла ситуация, что все про него слышали, но мало кто понимает архитектуру и принципы работы. Поэтому возникает непонимание для чего и как имеет смысл использовать технологии блокчейна.

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

    Итак, давайте вспомним какие проблемы изначально решил блокчейн. Читать дальше →
  • С 2006 года мы занимаемся биллинговыми системами. В общей сложности — более 12 лет. Начинали работать с телевизионного рынка, сейчас среди наших клиентов есть и банки, и сотовые операторы, и провайдеры интернет-телевидения. Сама биллинговая система эволюционировала от более или менее простого решения для телевидения до полноценного конвергентного биллинга с возможностью применения препейдной схемы. А мы за это время успели набить множество шишек как по части внедрения, так и поддержки биллинга. Часто ошибки происходят оттого, что заказчик не знает “матчасть”, а разработчики биллинга не понимают опасений и потребностей клиента.

    Читать дальше →
  • «Компания» — оператор связи ПАО «Мегафон» «Нода» — сервер RabbitMQ. «Кластер» — совокупность, в нашем случае трех, нод RabbitMQ работающих как единое целое. «Контур» — совокупность кластеров RabbitMQ, правила работы с которыми определяются на стоящем перед ними балансировщике. «Балансировщик», «хап» — Haproxy – балансировщик, выполняющий функции переключения нагрузки на кластеры в рамках контура. Для каждого контура используется пара серверов Haproxy, работающих параллельно. «Подсистема» — публикатор и/или потребитель сообщений, передаваемых через кролика «СИСТЕМА» — совокупность Подсистем, являющая собой единое программно-аппаратное решение, используемое в Компании, характеризующееся распределённостью по всей территории России, но обладающее несколькими центрами, куда стекается вся информация и где происходят основные расчёты и вычисления. СИСТЕМА – географически распределённая система – от Хабаровска и Владивостока до Санкт-Петербурга и Краснодара. Архитектурно это несколько центральных Контуров, разделенных по особенностям подсистем, к ним подключённым.

    Читать дальше →
  • В мои каталоги Поиск VPS и VPS.today попадают не все хостеры, которые присылают заявки на добавление, а некоторые со временем исчезают из них. Происходит это потому, что мы очень дорожим своей репутацией и стараемся максимально точно и полно отображать информацию о представленных услугах, а также обезопасить пользователей от возможных подводных камней при сотрудничестве с хостером. Сегодня я хочу рассказать о правилах и подробно расписать, почему мы используем каждое из них.

    Читать дальше →
  • На хабре есть скромный юзер TC40, пишущий про реалии эквайринга в России и молчащий о том, что у него вышла книга по электронным платежам, которую я увидел в книжном и не без интереса прочитал. Как я понимаю, это первый учебник в России по электронным платежам. Что бы сэкономить вам время вынесу главное, что понял из книжки. Может и автор подтянется в комментарии.

    Больше всего интерес представляют впервые открыто опубликованные внутренние правила платежных систем Visa и Mastercard. Не смотря на то, что формально во всех странах правила одинаковы, в реальности они различаются на западе и в России в маленьких, но принципиальных деталях. Читать дальше →
  • Когда я писал свой проект Поиск VPS, то не сильно задумывался о его монетизации. В голове летали только стандартные мысли — повесить Яндекс.Директ или Google AdWords. До того момента я, естественно, знал о партнерских программах хостеров, но не думал, что на них можно много заработать: все-таки программа предполагает, что пользователь будет приводить своих друзей, количество которых у всех ограничено.

    — Тащить их трудно… — Сделать миллион узелков было еще труднее! Читать дальше →
  • Всем доброго времени суток. На днях со мной случилась одна достаточно занимательная история, которой я хотел бы поделиться, а заодно услышать мнение здесь присутствующих по данному вопросу. Я являюсь давним пользователем одного дейтингового сервиса (здесь и далее по тексту я не буду называть его имя, чтобы не делать явной антирекламы, хотя знающие люди поймут, о каком проекте идёт речь). Читать дальше →
  • В процессе добавления и обновления информации о тарифах для проектов PoiskVPS и VPS.today мы просматриваем большое количество сайтов хостеров, ведем переписку с их сотрудниками с целью предоставления нашим пользователям максимально точной и полной информации о тарифах на виртуальные серверы и сопутствующие услуги. В этой заметке хочется поделиться замеченными отличиями между российскими и иностранными хостерами, рассмотреть разницу в подходах к маркетингу и тарифной сетке.

    Читать дальше →
  • Привет, Хабр! На сегодня у нас вот что:
    • Прогноз будущего банковских услуг от World Economic Forum;
    • Возможность оплачивать услуги и товары при помощи e-mail для россиян;
    • P2P-тенденции платежей при помощи мобильных устройств;
    • Криптовалюты для оплаты счетов в Австралии.
    Изображение: Cointelegraph Читать дальше →
  • 10 июня шёл уже третий день нашей акклиматизации в Гонконге. А последние 26 часов мы провели почти без сна, разрабатывая прототип проекта под рабочим названием SensorPay на первом этапе хакатона EOS Global с общим призовым фондом полтора миллиона долларов. Близился момент демонстрации проекта перед судьями.

    Если вам не терпится узнать, чем закончилась эта история, загляните сразу в последнюю часть. А мы пока начнём планомерно рассказывать о технологиях EOS и о том, как мы пришли к идее привязать к EOS платежи для IoT. Сразу после этого будет подробное описание технической начинки проекта.

    Читать дальше →
  • Наша самая любимая авиакомпания продает билеты через сеть собственных и независимых агентов и партнеров, сотрудничает со всеми участниками рынка: агенты, тревел-порталы, туристические операторы. Клиентами являются как индивидуальные путешественники, так и корпоративные клиенты. Для стимулирования продаж у авиакомпании есть несколько систем вознаграждений и программ лояльности для агентов и клиентов. Появлялись они в разное время, инициированы разными департаментами авиакомпании и учет по каждой программе ведется независимый. Как следствие, получить сводную картину по затратам и эффективности всех систем лояльности было довольно проблематично, т.к. это делалось в ручном режиме.

    Введение же единых метрик и правил учета позволило не только этот процесс автоматизировать и получить аналитику в режиме реального времени, но и планировать развитие отдельных инструментов лояльности с учетом эффективности системы в целом. Мы разработали конструктор условий вознаграждений, по сути биллинговую систему, которая позволяет сконфигурировать любое условие для каждой из программ и просчитать общую экономику систем лояльности на основе архивных данных о продажах (или оказанных услугах) за прошлые периоды. Читать дальше →

habr.com

Обзор биллинговой системы BGBilling

Примерно полтора года назад столкнулись с проблемой, заключающейся в том, что наша биллинговая система (кем-то и когда-то написанная, поддерживаемая местной контрой, в которой автора уже не было) ну никак уже не справлялась с возложенными на нее задачами. Заказывать разработку новой системы под свои задачи — слишком дорого и слишком долго. Поэтому встала задача — найти подходящее решение. Выбор в итоге пал на BGBilling. В итоге вот уже год как мы работаем с этой системы и в целом всем довольны. Почему мы выбрали именно систему и чем она хороша (минусы тоже постараюсь осветить) постараюсь подробно изложить ниже.

Введение
Итак, для кого в первую очередь предназначен пост? Для людей, подобно мне полтора года назад, озадаченных руководством, находящихся в поиске подходящего решения и ищущих описания различных систем, чтобы начать тестирование (да, есть замечательный ресур наг.ру, но лично мне он не импонирует, слишком уже хаотично все, поэтому хабру я верю больше). Так же думаю будет интересно тем, кто переживает/пережил бурный рост/выход на новую нишу и ощущает необходимость апгрейда/переезда на новую платформу. Пожалуй, начнем.
О системе

Система — российская. Сайт — bgbilling.ru

Как я понял, система писалась для сети УфаНет, и потом выросла в отдельный продукт. Разработка идет где-то с 2003 года. Текущая версия 5.0 (у нас стоит 4.6, отличий от текущей — практически никаких, новая версия была вызвана окончанием действия сертификата), в разработке находится версия 5.1, в которой разработчики обещают много нового, но про нее пока я ничего сказать не могу. Архитектура системы — серверная часть написана на Java. Первое время беспокоила производительность и стабильность такой системы. По прошествии года могу сказать — с производительностью и стабильностью нет никаких проблем. Но есть одно НО. Сервер требует последнюю Java, а с ней есть определенные проблемы на FreeBSD. Поэтому этой системы нет в списке поддерживаемых. Но зато есть — Windows, Linux. Конкретно у нас стоит на Fedora 10. Mac как поддерживаемая платформа не заявляется, но в целом мне ничто не помешало запустить сервер и клиент у себя на ноутбуке. СУБД — MySQL.

Документированность БД — изумительная. Идем на сайт dbinfo.bitel.ru и шаримся, смотрим что и как с чем связано, какие параметры могут быть. Честно признаюсь, для меня документированность БД была одним из решающих факторов. Было ясно, что функционал специфичный только для нас придется допиливать самому, поэтому такое подспорье как адекватная документация, меня как радовали, так все больше и радуют.

Клиент для оператора биллинга — отдельное GUI приложение. Что следует отметить — в клиенте есть встроенные sql редактор, который из самого клиента позволяет выполнять зарпосы к бд и получать результаты в удобоваримом виде.
Стоимость, лицензии и прочее
Система — модульная. Каждый модуль имеет количество лицензий с которыми он может работать (или бесконечное количество). Чем больше лицензий — тем дороже модуль. Максимальная цена — за бесконечное количество лицензий.

Какие модули стоит выделить — модуль списания абонентский плат, модуль diap up, модуль ipn, voiceip. Рассчитать стоимость лицензии можно на сайте — bgbilling.ru/price_count.shtml

Какие модули кому нужны будут? Без модуля абонентских плат — никуда. Берем его, максмальная цена за бесконечное количество лицензий (бесконечное начинается с 10000 лицензий) — ~100тр. А теперь смотрим чем мы занимаемся? Оператору КТВ по сути больше ничего не нужно. Провайдеру еще бы и модуль работы с сетью. Это или IPN или DialUP — и тот и другой максимально стоят тоже порядка 100тр. Модуль телефонии — один из самых дорогих. Порядка 240тр. Остальные модули — voiceip, модуль цифрового телевидения — по-моему не так популярны, их рассматривать не будем. Если интересно — можно посчитать на сайте.
Техподдержка, комьюнити
Спорный вопрос по техподдержке. Она платная. При покупке лицензии предлагается заключить контракт на техподдержку и приобрести пакет обращений. За 25тр можно получить 50 обращений на год. За 9тр — 15 обращений, тоже на год. Много это или мало? Мы использовали за год — 5 обращений. Сообщения об ошибках за обращения не засчитываются, но для их сообщения все равно нужен пакет хоть с одним обращением. Бесплатная поддержка оказывается разработчиками на форуме, но в негарантированные сроки. Если через личный кабинет ответ будет дан в среднем через пару часов, то через форум придется подождать день-два. Но зато на форуме очень много таких же пользователей как и вы, которые подчас подсказывают и помогают оперативней. Что и приводит нас к вопросу о комьюнити и вики-базе. Сообщество мне очень понравилось. На форуме можно найти помощи практически по любому вопросу. В последнее время и ко мне в аську начали с вопросами обращаться, с радостью подсказываю, если знаю что и как.
Производительность и факапы

Официальные данные представлены на соответствующей странице сайта — bgbilling.ru/program/speed.shtml. В целом им можно верить. АП списываются довольно шустро. Радиус(мы используем модуль DiapUP для доступа к сети) держит нагрузку при одновременной авторизации 1000-1500пользователей (пропадаение света в районе, а потом включение) вполне нормально. Радиус же занимается обсчетом нетфлоу статистики. Справляется с потоком от 6 цисок с гигабитом трафика на каждой.

Если не считать факапов вызванных своими кривыми руками, то был один довольно неприятный факап 1 января 2010 года. На каждый месяц автоматически создаются новые таблицы с балансом. Из-за какой то недоработки в логике в 2010 году новые таблицы не создались. Поэтому в момент списания АП у всех был 0 на счету. Благо БД очень хорошо документирована и есть функции групповых операций — это удалось очень быстро устранить (до того как большая часть абонентов отошла от похмелья и полезла в интернет).
Запуск, перенос существующих баз
Настройка и запуск системы осуществляются довольно просто, особо выделить даже нечего. Распаковать архив, добавить исполняемые .sh в автозапуск, загрузить структуру таблицы из файла дампа и пожалуй все — уже будет работать =). Инетересный момент. Основные компоненты системы — сервер, радиус, шедулер — можно разнести на разные сервера, в настройках указать айпишники и все отлично будет работать, цепляться к серверу и распределять нагрузку. Кстати про распределение нагрузки. Все задачи сваливаются в очередь, которую обрабатывает шедулер. Причем он практически никак не связан с сервером. Т.е. задача на выгрузку статистики, переобсчет трафика — нагрузит шедулер, но никак не скажется на производительности самого сервера биллинга — он будет работать в нормальном режиме, складывая задачи в очередь, будет давать доступ до бд радиусу и других модулям.
Заключение, сравнение с другими системами
В целом биллингом я доволен. Сейчас дописываю свой интерфейс (опять радуюсь документированности бд — написать нужные запросы к бд очень легко) Сравнить с другими системами особо возможностей и не было. По отзывам тех кто переезжает с UTM — небо и земля — документированность и открытость бд, возможность дописать свои скрипты, реализовать собственную бизнес логику.

PS если появились какие-то вопросы — задавайте, постараюсь ответить.

Теги:
  • 25 сентября 2013 в 11:55
  • 27 июля 2008 в 20:29
  • 18 марта 2007 в 00:25

habr.com

Биллинговая система — это программное обеспечение для компаний сотовой связи

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

Доброго вам времени суток, друзья.

Очень часто сталкиваюсь с вопросами в частных беседах, связанными с биллингом.

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

Забрасываю все дела на дальнюю полку и посвящаю свое время тому, чтобы в подробностях рассказать вам про биллинговую систему – что это и в чем заключаются главные моменты, что нужно знать в первую очередь. Итак, приступаем немедленно.

Биллинговые системы: основные понятия

Английское слово «bill» можно перевести как «счет» (другие переводы: вексель, банкнота). «Billing» переводится выражением «выписывание счета».

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

Биллинговая система (БС) — это бухгалтерская система, программное обеспечение, иными словами — «софт», разработанный специально для операторов. Каких операторов? Телекоммуникационных.

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

IP-телефония — другая область применения БС. А интернет-провайдеры? Они тоже используют БС, например, для формирования счетов, учета трафика. Любая БС создается на основе определенной системы управления базами данных (СУБД).

А вот названия некоторых биллинговых систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Стоит упомянуть, что под БС может подразумеваться и аппаратное обеспечение, участвующие в организации биллинга.

Терминология

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

Постараюсь объяснять как можно проще, чтобы большинству читателей материал был понятен. Если у Вас будет что добавить к введенным мною терминам, пишите на e-mail.

Существуют несколько названий биллинговой системы: АСР — автоматизированная система расчетов; ИБС — информационная биллинговая система.

Одним из важных качеств БС является ее гибкость, то есть способность приспосабливаться к изменившимся обстоятельствам.

Гибкая система адаптирована не только к сиюминутным потребностям оператора; за счет таких качеств, как настраиваемость, модульность и открытость она позволяет решать перспективные задачи. Чем больше у системы возможностей для настроек, тем лучше.

А что такое модульность? Модульный принцип построения системы — это такой принцип, при котором вся система собирается из отдельных частей (модулей), как дом собирается по кирпичикам. БС тоже состоит из таких модулей — подсистем.

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

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

Тесно связано с гибкостью БС и следующее качество автоматизированных систем расчета — масштабируемость.

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

Увеличение возможностей БС должно достигаться за счет модернизации аппаратной части системы.

Что важно учитывать при проектировании масштабируемых систем? Необходимо использовать СУБД, рассчитанные на большие объемы данных.

СУБД должна быть совместима с различными компьютерными платформами, чтобы обеспечивать поддержку многопроцессорного режима работы.

Надежность — одно из основных требований, предъявляемым к любой системе. Надежность БС определяется надежностью СУБД и технологий, используемых при разработке системы.

Почему показатель косвенный? А разве Microsoft Windows самая лучшая и надежная операционная система?… И при этом она занимает значительную долю рынка.

Однако надежность БС обеспечивается также соблюдением определенных стандартов при их разработке.

Мультиязычность — возможность устанавливать различные языки для представления информации. Мультивалютность — возможность работать с любыми валютами.

Отложенный биллинг — биллинг, при котором расчеты производятся после состоявшихся звонков.

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

Оптимизация биллинга — улучшение, совершенствование оператором своей БС. Большие БС — системы, применяемые крупными операторами.

Постинг биллинга — фиксация результатов расчета биллинга; после расчетов результаты становятся доступными пользователям (рассылаются, печатаются).

Что может, что должна или за что отвечает БС?

Вы пользуетесь услугой prepaid? Вы задумывались, как так получается, что сразу после звонка можно узнать об изменении баланса на Вашем счету? Вас обслуживают по кредитной системе?

Кто подсчитывает сумму, которую Вы должны заплатить за предоставленные услуги? Все это «обязанности» биллинговой системы. Вы подключены по авансовой системе? Когда-нибудь замечали «исчезновение» незначительных сумм с Вашего счета?

У Вас было такое: хотите узнать остаток Вашего счета, а автоинформатор предоставляет Вам сведения вчерашней свежести? Все это «глюки» биллинговой системы.

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

При помощи подсистем автоматических услуг и автоматического сбора данных АСР должна предоставлять абонентам возможность самообслуживания.

Некоторые БС позволяют абонентам оформлять заказы на подключение и производить оплату услуг через Интернет.

Структура и функции

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

Расчетной системе «известны» тарифы. Она идентифицирует вызов и выполняет необходимые расчеты, формируя тем самым счет абонента.

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

Системой должно быть также предусмотрено наличие дилеров: у них могут быть другие расценки, например, на подключение.

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

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

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

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

В масштабе региона можно вполне обойтись стандартными БС. Однако и такие системы должны обладать качествами, перечисленными выше: гибкостью, масштабируемостью, надежностью.

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

Но существует и стандартный набор функций, поддерживаемых практически всеми БС. В него входят:

  1. операции, выполняемые на этапе предварительной обработки и анализа исходной информации, например, функция получения данных о соединениях и услугах (запросы к коммутатору);
  2. операции управления сетевым оборудованием: функции активации/деактивации (блокировки/разблокировки) абонентов и команды изменения условий подписки абонентов, передаваемые непосредственно в коммутатор;
  3. основные функции приложения СУБД, включающие в себя: тарификацию записей коммутатора о вызовах и услугах;
  4. формирование и редактирование таблиц базы данных расчетной системы;
  5. выставление счетов и их печать; кредитный контроль счетов; составление отчетов; архивацию.

Как уже было сказано, БС должна обладать гибкостью или модульностью. Каждый элемент АСР обеспечивает реализацию конкретного участка технологической цепочки обслуживания клиента.

Основные подсистемы, характерные для биллинга, это: подсистема предварительной обработки данных о соединениях, оперативное управление биллингом и подсистема оповещения клиентов.

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

В состав данной подсистемы входит декодер исходной информации о соединениях. Одна из сложнейших процедур этой подсистемы — поддержка роуминга.

Дело в том, что требуется конвертировать роуминговые записи всевозможных форматов от разных коммутаторов (с учетом различных стандартов передачи информации в канале связи) и разных биллинговых систем в тот формат записи, которым пользуется данная БС.

Программное обеспечение (ПО) тарифицирует все записи о соединениях между операторами (согласно проходящему трафику) и создает служебные таблицы, которые используются остальными подсистемами для выполнения расчетов с абонентами, взаиморасчетов операторов связи и формирования отчетов.

Современные БС позволяют обрабатывать различные телекоммуникационные услуги, обеспечивая удобное выставление счетов (один клиент — один баланс — один счет).

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

Подсистема оперативного управления биллингом. Данная подсистема дает возможность автоматически или через оператора биллинговой системы изменять условия подписки абонентов на коммутаторе, т. е. блокировать связь конкретного абонента или снимать эту блокировку, включать или отменять услугу.

Подсистема оповещения клиентов. Неотъемлемая часть современного биллинга — подсистема оповещения клиентов с помощью голосовых или электронных сообщений.

Информацию для рассылки уведомлений и объявлений данная подсистема берет из таблиц базы.

Перечисленное деление на функциональные подсистемы не является «строгим» для всех БС. Это лишь пример «классической» АСР.

Стандарты биллинга

Чтобы обеспечить взаимопонимание между различными БС разных операторов (это, например, требуется при роуминге, были разработаны группы стандартов биллинга. Основных международных групп стандартов три.

В 1998 г. американский институт стандартов ANSI утвердил стандарт ANSI 124. Дальнейшим усовершенствованием и поддержкой ANSI 124 занимается ассоциация TIA.

После этого компания CIBERNET создала рабочую группу для определения спецификаций бизнес-процессов при передаче сообщений в стандарте ANSI 124, которые получили название NSDP-B&S.

Данные спецификации устанавливают однозначное соответствие между бизнес-процессами телекоммуникационных операторов и информацией, передаваемой при обмене данными между коммутаторами по стандарту ANSI 124.

В 1998 г. было опубликовано описание первого североамериканского биллингового стандарта CIBER, который в настоящее время поддерживается фирмой CIBERNET и ее комитетом CAC-IS.

Этот комитет объединяет разработчиков биллинговых систем и телекоммуникационных операторов. Главная область применения CIBER — сотовые сети стандарта AMPS.

Европейский (по происхождению) стандарт ТАР появился в 1992 г. Он поддерживается рабочей группой TADIG.

Большинство операторов Европы используют ТАР2, хотя существует и третья версия. С 1995 г. модификация ТАР2, известная как спецификация TD.27, или NAGTAP2, начала применяться и в США.

Источник: http://finvopros.com/www.ixbt.com/mobile/review/billing.shtml

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

Биллинговая система — это программное обеспечение, разработанное специально для операторов (провайдеров).

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

Биллинговая система в программе Traffic Inspector учитывает весь трафик, проходящий через компьютер. Благодаря специальному драйверу, учитывается трафик, проходящий через сетевые интерфейсы, NAT, прокси-сервер и почтовый шлюз программы.

Каждый сетевой пакет анализируется и подсчитывается с точностью до байта. Учет трафика четко разделяется на «внешний» и «внутренний». Внешний – это трафик, полученный от вышестоящего провайдера, внутренний – отданный абонентам.

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

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

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

Состояние лицевого счета, оплаты, причины блокировки, свое потребление трафика и сетевую статистику абоненты могут посмотреть в своем личном кабинете.

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

Traffic Inspector – это расширяемая платформа. Документированный интерфейс автоматизации и встроенного веб-сервера с поддержкой современных технологий .NET и C# для генерации динамического контента позволяет легко расширять его возможности под различные задачи.

Источник: http://finvopros.com/www.smart-soft.ru/billing-system/

Немного о биллинговых системах для провайдеров

Биллинг — английское слово «bill» переводится на русский как счёт, квитанция. Billing — это процесс выписывания счёта (отсюда, кстати и Billing Address на всяких ибеях и амазонах).

Применительно к телекоммуникациям, это выставление счёта абоненту за пользование услугами.

А вся та когорта бабушек из бухгалтерии, которая считает ваши мегабайты — Биллинговая система. По-русски это называется Автоматизированная Система Расчётов АСР или ещё иначе ИБС — Информационная Биллинговая Система.

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

Расплатились с фрилансером через Яндекс-деньги? У вас со счёта они списались, у фрилансера появились, в историю платежей информация добавилась.

Это всё биллинговая система. Пришёл вам счёт за трёхчасовой звонок в Израиль — тоже его заслуга.

А в ихних Америках уже даже социальные службы обзаводятся такими системами, делая денежные потоки более прозрачными и простыми.

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

Это отдельный огромный пласт технологий и знаний. И, что логично, сложность зависит от масштабов сети.

Небольшая локальная сеть организации

Начнём, пожалуй, с крохотных SOHO (Small Office/Home Office). У небольших компаний тоже часто стоит вопрос подсчёта трафика: кто, куда и сколько.

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

Ещё пример — это внутридомовые или внутридеревенские провайдеры, которые и по сей день существуют, перепродавая трафик тем, кто сам на интернет себе не заморочился.

В общем, всё это сети, где в качестве шлюза или, по крайней мере NAT-сервера, выступает Unix-компьютер с iptables и, возможно, прокси-сервером.

Биллинговые системы для провайдеров

Здесь правят бал бесплатные микробиллинговые системы: WinRoute Spy, Squid2mysql, StarGazer Billing System, ipq_traffic. Есть и представители платных, конечно, вроде, Lingate, например.

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

Сети крупных предприятий или небольшие провайдеры

Вторая ступень — это провайдеры средней руки. Речь о компаниях, обслуживающих сетевые нужды холдингов, больших предприятий и операторы ШПД на основе Ethernet.

Как правило, в качестве сетевого оборудования для маршрутизации трафика здесь используются полноценные аппаратные маршрутизаторы (Cisco/Huawei/HP/Juniper итд) либо, гораздо реже, высокопроизводительные сервера.

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

Во-вторых, АСР в таких сетях — это очень важное для бизнеса приложение (busines-critical по-буржуйски). Соответственно за его статусом нужно следить неусыпно.

То есть это регулярные бэкапы, актуальные обновления. И уже маячит на горизонет вопрос аппаратного резервирования.

В-третьих, АСР должна хранить в БД всех клиентов с их атрибутами (счёт, реквзиты, адрес, комментарии, баланс, тариф, квоты), обеспечивать работу сразу нескольких операторов, иметь пользовательский интерфейс для клиентов.

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

В-четвёртых, АСР должна обеспечивать генерацию отчётов любой детализации. Это приводит нас к понятию многоуровневой базы данных. Нужно соблюдать баланс между скоростью составления отчётов и нагрузкой на БД.

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

На втором уровне будут классифицированные и чуть более детализированные данные. Например, вы сможете запросить по конкретному абоненту за нужный час какой объём трафика был по разным сервисам.

Третий — это сырой, необработанный материал — грубо говоря, все сесси абонента в каждый момент времени.

Такая информация будет нужна, скорее всего, только для урегулирования спорных ситуаций (либо для анализа наиболее посещаемых сайтов, актуальных сервисов итд, чтобы продвигать новые услуги, но это уже не совсем к теме биллинга).

Обычно данные третьего уровня (деление на эти уровни весьма условно) хранятся не в БД как таковой, а в виде файлов на носителе, потому что имеют очень большой объём — отсюда ещё вытекает и вопрос с дисковым пространством.

Либо с шлюза нужно настраивать зеркалирование трафика с портов в сторону биллинг-сервера. Ситуация немного похожа не предыдущий рассмотренный класс АСР.

В случае аппаратных маршрутизаторов для сбора данных используется специальный протокол, такой, например, как NetFlow у Сisco или NetStream у Huawei.

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

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

Не вдаваясь в детали, зеркалирование — это полное клонирование всех данных, проходящих через порт. То есть если у вас аплинк к провайдеру нагружен на 85 Мбит, то те же самые 85 Мбит пойдут ещё и на биллинг сервер.

Зеркалирование

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

При этом зеркалирование настраивается не на адрес хоста, а на физический порт. То есть чтобы довести трафик до биллинг-сервера, нужно прокидывать или прямой кабель или VLAN.

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

Плюс в настройках конкретно можно указать адрес хоста, куда нужно данные перенаправлять. Они будут инкапсулированы в IP-пакеты и смаршрутизированы до получателя.

Спецпротоколы

Обычно, помимо биллинга используется ещё специальный анализатор, который позволяет более гибко работать с трафиком, рисовать красивые картинки и создавать годные отчёты. Для Cisco, например, есть Netflow Analyzer.

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

Если по серым, то можно настроить это на нескольких нижестоящих устройствах.

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

Несколько дней попыток найти в чём проблема, общения с техподдержкой производителя АРС, обновлением, чистка логов на сервере. Несколько тестов.

Тогда я стал спрашивать у коллег, что они делали в тот день (удалось установить именно тот день, когда просела статистика по некоторым абонентам).

И когда я уже было отчаялся, вдруг всплывает, что в тот день они подключали по BGP нового провайдера.

Часть трафика ушла на него, через, конечно же, другой интерфейс, который они не догадались настроить для передачи данных netflow. Две команды, и проблема, которая висела почти 2 недели, решилась.

Следует отметить, что к тому моменту уже все были на взводе, ибо биллинг — это бизнес критикал.

И если вдруг кто-то придёт с проверкой (у нас же сертифицированная АРС), нам зададут резонный вопрос: «Почему статистика не соответствует действительности?» — и накажут. Самые яркие представители АРС данного класса: АСР Ideco, UTM NetUp, Bill-Master, Traffic Inspector итд.

Все они платные и все они сертифицированные. Но если с последним вопрос не стоит, то, возможно, вам будут интересны следующие варианты: Tmeter, NetProfile, Katrin, NeTAMS.

Монстры

И мы подходим к необъятным пирамидам — Автоматизированным Системам Расчёта больших и огромных провайдеров. Это транснациональные операторы связи, провайдеры масштабов страны и региона.

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

Это плоскость, в которой нет места коробочным приложениям. Каждое решение здесь кастомизировано по самое «не хочу». Тотальное резервирование, ежегодный договор на техническую поддержку или даже свой штат программистов для этой системы.

Здесь остро встают вопросы межоператорского взаимодействия, роуминга, когда АСР должна уметь интерпретировать данные не только из своей сети, от своих устройств, но и предоставленные третьей стороной, со всеми параметрами и полями, которые важны всем втянутым операторам.

ITU (Международный Союз Электросвязи) разработал универсальные стандарты, которых должны придерживаться разработчики систем биллинга.

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

  • Модульность. Дополнительный функционал добавляется в рамках той же самой системы. Для этого существуют унифицированные интерфейсы, медиаторы (промежуточные узлы), среды разработки, API.
  • Масштабируемость. При увеличении нагрузки не нужно менять программную составляющую, а необходимо лишь увеличивать аппаратную мощность.
  • Резервирование, высокая устойчивость к сбоям. АСР работают на базе кластеров или в режиме Hot/Backup, когда резервный сервер подхватывает все сервисы в случае падения активного. Все данные находятся в хранилищах в RAID.
  • Время реакции. АСР должен в разумное время принять решение о действиях над абонентом — заблокировать, ограничить скорость или сервисы, или наоборот дать больше квот и возможностей. При медленной реакции, провайдер рискует либо своими деньгами, либо удовлетворением клиента.

Решения в виде пропуска всего трафика через сервер или netflow тут никак не годятся. Это же десятки, а то и сотни гигабит. Нет, друзья, тут другой подход. Есть такое понятие, как CDR. Расшифровывается это как Call Detail Record.

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

Несмотря на название сейчас этот термин используется в более широком смысле. CDR сейчас генерируются не только АТС, SGSN и прочим оборудованием голосовой связи, но и устройствами пакетной передачи: GGSN, DPI, маршрутизаторы и прочее.

К примеру, вот ниже типичная мобильная сеть с DPI и биллинговой системой. Когда абонент с телефона выходит в интернет, он сначала регистрируется в мобильном ядре, а далее, получив IP-адрес, выходит в интернет. Все пакеты проходят через DPI.

Мобильная сеть с DPI и биллинговой системой

В такой ситуации и SGSN, и GGSN, и DPI могут генерировать CDR, выкладывать их в определённый каталог в хранилище, а биллинговая система будет их забирать и выкатывать счета на основе тарифов (дополнительные данные также содержатся в CDR).

Один из минусов CDR — невозможность через них управлять оборудованием — блокировать, снижать скорость.

Для этого существуют системы OCS (Online Charging Service), которые имеют обратную связь с оборудованием, но это тема совсем другой статьи.

Выбор же биллинговой системы для конкретной организации — это вечная головная боль. Сколько копий уже сломано на форумах об этом…

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

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

Источник: https://telekomza.ru/2013/04/07/nemnogo-o-billingovyx-sistemax-dlya-provajderov/

Как работает биллинг?

Биллинг — автоматизированная система учёта предоставленных услуг, их тарификации и выставления счетов для оплаты.

В телекоммуникации биллинг официально именуется «Автоматизированная Система Расчётов» (АСР).

Общие моменты: У каждого пользователя имеется денежный счет, с которого раз в сутки в 00:00 часов списываются средства, согласно выбранным тарифам если аккаунт не заблокирован.

Если на счете 0 рублей, то ничего не списывается, счет в «минус» не уходит, интернет не включается. Для включения надо пополнить счет.

Если на счете сумма меньше выбранного тарифа (например: на счете 5 рублей, а услуга стоит 9 рублей в сутки) эта сумма остается у вас на счету.

Интернет работать не будет, поскольку этой суммы недостаточно для оплаты авансом услуг за следующие сутки.

Если на счете сумма больше выбранного тарифа (например: на счете 50 рублей, а услуга стоит 30 рублей в сутки) то сумма тарифа (30 рублей) спишется в полночь, интернет будет работать.

Пример: Вы положили на счет 50 рублей в 23:00 часа. У вас стоит тариф 512. При включении услуги у вас сразу спишется 9 рублей, за предоставление услуги за текущие сутки.

Далее в 00:00 часов спишется еще 9 рублей за следующие сутки. Таким образом, уже в 01:00 у вас на счете будет 32 рубля.

Система не делает перерасчет по часам. ПОМНИТЕ! При включении VPN система сразу списывает деньги за текущие сутки!

Данный сервис полностью автоматизирован, это значит что средства списываются автоматически. Никто не может самовольно списать с вашего счета деньги, это делает система согласно тарифам.

Источник: http://finvopros.com/vneha.ru/chavo/kak-rabotaet-billing/

Принципы разработки биллинговой системы

Биллинговая система — программный комплекс, осуществляющий учет объема потребляемых абонентами услуг, расчет и списание денежных средств в соответствии с тарифами компании.

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

Однако, зная извечную склонность системных администраторов (и линуксоидов в особенности) к изобретению велосипедов, не исключено, что кто-то на базе этих рекомендаций создаст биллинг своей мечты.

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

Итак, постараемся подумать над тем, как создать биллинг на базе Linux и open source ПО.

Задачи

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

  1. сбор информации о потребляемых услугах (аккаунтинг)
  2. аутентификация и авторизация абонентов
  3. контроль денежных средств на счетах абонентов и списание средств в соответствии c действующей тарифной сеткой
  4. пополнение счетов абонентов
  5. внесение изменений в тарифы
  6. предоставление статистики по операциям (клиентская и операторская части)

Кстати, не стоит путать аутентификацию и авторизацию — это разные понятия.

Так, аутентификация — процедура идентификации пользователя (обычно сводящаяся к проверке указываемых им данных на совпадение с хранящимися в системе).

Авторизация — процесс принятия решения о правомерности доступа пользователя к какому-то конкретному ресурсу (например, к файлу на диске или к определенной услуге связи).

Схема системы

Исходя из задач и запросов бизнеса, можно набросать схему системы. Чтобы не обсуждать какого-то абстрактного сферического коня в вакууме, будем рассматривать типовой пример оператора связи, продающего трафик абонентам:

  • коллекторы информации о потребленных услугах
  • система аутентификации абонентов
  • ядро (бизнес-логика)
  • многоуровневая БД
  • модуль авторизации
  • модуль анализа типов трафика (локальный, пиринговый, etc)
  • модуль разграничения доступа
  • модуль статистики
  • административный интерфейс для ручного управления абонентами
  • интерфейс управления счетами абонентов и тарифами для отдела продаж
Структура биллинговой системы ISP

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

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

Услуги могут быть разными (например — VPN-доступ, dial-up пул, обычный неинкапсулированный трафик, Proxy, VoIP, etc), надо обеспечить доставку ядру системы в единообразном виде информации о том, какой тип услуги, какой абонент, в каком объеме и в какое время потребил.

В худшем случае для каждого из типов услуг прийдется разрабатывать свой коллектор, но если повезет — что-то удастся унифицировать. Технологии, которые могут помочь при создании коллекторов — SNMP, Radius, NetFlow.

Многоуровневая база данных

Многоуровневая БД нужна для того, чтобы не работать все время с массивами максимально детальной информации, т.к. это значительно может снизить быстродействие всей системы.

Логично выделить 3 уровня:

  1. максимально детализированная информация без какой-либо обработки
  2. классифицированная и первично агрегированная информация
  3. оперативная информация

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

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

По крайней мере, при подсчете трафика через Web Proxy это решается автоматически, использование NetFlows тоже позволяет делать полную детализацию. Минусом является значительный объем, требующийся для хранения всех этих данных.

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

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

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

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

На основе этой базы осуществляется принятие решений о предоставлении или прекращении предоставления услуг конкретному клиенту.

Технические характеристики

Если упустить некоторые пункты из нижеописанного на этапе проектирования — потом возможно прийдется подвергать систему серьезной модификации уже на этапе эксплуатации, что крайне нежелательно.

Основные технические требования, диктуемые бизнесом: гибкость, точность расчетов, устойчивость к сбоям.

Учет перспективы

Задумайтесь над тем, какие с какими услугами ваш биллинг должен будет уметь работать, при этом планируйте на будущее.

Сегодня наиболее часто считают трафик, но завтра могут возникнуть потребности в новых услугах — платный контент, VoIP, веб-хостинг, что-нибудь еще.

Конечно, для малого бизнеса это не так актуально, но вполне вероятно, что в перспективе у вас возникнет необходимость работать с платежами по временным картам доступа.

Погрешность расчетов

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

Чтобы застраховаться от подобных неприятных особенностей, можно учитывать это в тарифах, хотя это уже не технический вопрос.

Помимо всего прочего, есть еще паразитный трафик. Ничего с ним поделать нельзя, нужно просто помнить о нем, если у вас много реальных IP-адресов.

Если вы перепродаете трафик, не забудьте при расчетах о том, что ваш головной ISP может под мегабайтом понимать вовсе не 1048576 байт, а, например, 1000000, что в результате дает почти 5% расхождения.

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

Время реакции системы

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

Например, если блокировка срабатывает раз в минуту — при скорости соединения 1 Мбит/с абонент может скачать лишних 7,5 мегабайт в худшем случае.

Устойчивость к сбоям

Биллинг считает деньги, поэтому нужно быть предельно аккуратным.

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

Актуальность данных

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

Можно использовать актуальные копии статических списков сетей, с которыми у вашего головного провайдера заключены пиринговые соглашения (и, соответственно, трафик, связанный с ними, тарифицируется по-иному), периодически скачивая их от ISP.

Альтернативой может быть использование протоколов динамической маршрутизации, например — RIP, с помощью которых можно получать границы пиринговой сети (если ваш головной ISP предоставляет такую услугу).

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

Статистические отчеты

Помимо классического уже веб-интерфейса к статистической информации о потребленных услугах и состоянии счета неплохо предоставлять клиентам услугу рассылки наиболее важной для него информации на e-mail или посредством SMS.

Экономические характеристики

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

Тарифы

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

Технически эту задачу можно формализовать так: тарифы должны рассчитываться в кусочно-линейной зависимости от некоторого параметра — либо времени суток и дня недели, либо объема уже потребленных абонентом услуг.

При этом желательно, чтобы система позволяла не очень технически грамотному персоналу управлять тарифными планами.

Кроме этого, очень желательно хранить архив тарифов для возможности восстановления счетов спустя время.

Бухгалтерия

Полезно подумать об интеграции вашего биллинга в общую бухгалтерию вашей организации, например — с 1С или еще чем-то, что у вас используется для этих целей.

При планировании структуры базы данных учтите тот факт, что у одного абонента может быть несколько разных счетов (на разные услуги), и он по идее должен иметь возможность либо объединять, либо изолировать их.

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

Лицензирование

Если у вас 100% легальный бизнес, необходимо использовать только сертифицированные в Министерстве связи РФ решения.

В целом, вопрос с наличием лицензии на биллинг каждый решает для себя сам.

Практический пример

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

Один из часто используемых способов простого учета трафика — использование счетчиков iptables на пограничном маршрутизаторе.

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

Минусы — прийдется весь трафик, который вы хотите учитывать, маршрутизировать через один PC, что, в общем-то, не сильно критично при небольшой загрузке.

В качестве коллектора в таком случае может выступать небольшой PERL-скрипт, анализирующий вывод iptables.

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

Структура цепочек правил iptables

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

В случае использования VPN (например, для продажи трафика это одно из наиболее оптимальных решений, т.к. в сетях, построенных на дешевых хабах без возможности Port Security, идентификация пользователя по IP является крайне ненадежным решением) вполне логично интегрировать модуль авторизации клиентов в скрипты /etc/ppp/ip-up и /etc/ppp/ip-down, которые вызываются демоном pppd при подъеме и опускании ppp интерфейса (а зачастую VPN-соединения представляют собой по сути, соединения, использующие PPP как транспорт для инкапсулированного трафика).

Аналогичным образом можно организовать авторизацию для dial-up соединений.

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

По сути, этот компонент и заключает в себя основную часть бизнес-логики, т.к. именно он ответственен за финансовые расчеты.

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

Единственное, на чем хочется акцентировать внимание — это то, что эти модули должны быть разработаны с максимальным учетом бизнес-спефики, которая обсуждалась выше.

Источник: http://finvopros.com/citforum.ck.ua/operating_systems/linux/billing/

finvopros.com

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

Биллинговая система – это схема автоматизации  предприятия, обеспечивающая:

  • Хранение  информацию о действующих тарифах.
  • Возможность вычисления стоимости услуг каждому конкретному клиенту.
  • Работу со стоимостными характеристиками и выставление счетов на оплату.

Суть и преимущество биллинговой системы

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

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

Суть биллинговой системы – в автоматизации контроля и управления как в наличных, так и в безналичных расчётах.

На персонифицированные счета компании поступают средства клиентов  в качестве оплаты пакета  услуг –сетевые ресурсы и трафик, сотовая телефонная связи и прочее-прочее.

Виды

Можно выделить три основных класса билинговых систем (в зависимости от их функциональности:

1.предназначенные для региональных сетей

2.предназначен компаний государственные—ого (национального) масштаба

3.для транснациональных сетей.

Естественно,  региональные виды — наиболее распространённый и традиционный вариант. Основная схема её действия — Клиент-Сервер. Перечень предоставляемых услуг входит в стандартный вариант биллинга и предполагает самые низкие расценки услуг.

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

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

(Пока оценок нет) Загрузка...

offshore4you.info

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

Платформонезависимость

Благодаря использованию технологии JAVA, программа (как клиент так и сервер) способна запускаться на любой платформе безо всякой модификации, перекомпиляции кода, смен конфигурации.

Клиент-сервер

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

Клиентский GUI

Клиент биллинга - это полнофункциональное GUI приложение, способное к запуску на любой платформе и обеспечивающее легкое манипулирование данными в привычном Windows оконном режиме.

Модульность

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

Web - интерфейс клиента

Позволяет абонентам оперативно узнавать о состоянии счета, расходов и платежей через страницу WEB - статистики, изменять пароли доступа, пополнять баланс. Добавление абоненту услуг из различных модулей автоматически модернизирует его страничку.

Гибкость и расширяемость

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

Встроенный планировщик

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

Поддержка шаблонов договоров

Упрощенное создание новых однотипных договоров. Договор будет создан одним нажатием, в нем уже будет определен тарифный план, набор услуг.

Гибкая настройка параметров договоров

Набор параметров договоров может быть изменен произвольно, разным договорам могут соответствовать различные группы параметров. По каждому параметру может быть произведен поиск договора.

Гибкая настройка параметров договоров
Гибкие тарифные планы

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

Оперативные e-mail рассылки

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

Вывод печатных форм

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

Cистема разграничения доступа

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

Встроенный язык программирования

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

Открытость и интегрируемость

- Открытый и простой протокол обмена Клиент - Сервер (HTTP + XML) позволяет производить простую интеграцию с внешними программами (в т.ч. с бухгалтерскими). - Полностью документированная и открытая структура БД биллинга.

b2b.schoolsms.ru


Смотрите также