Биллинговые платежи. Биллинг в банковской деятельности: система расчётов, удобная для всех. Рынок биллинговых систем

| Отдых и увлечения | Быт | Архив | RSS

Биллинг в банковской деятельности: система расчётов, удобная для всех

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

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

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

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

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

Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

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

Есть 2 основных типа расчета:

Постоплата - выставление счёта за период по его итогам (postpaid)
И авансовая система (prepaid), когда деньги заносятся заранее.

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

Постоплатная система

Когда абонент постополатной системы расчетов пользуется услугами оператора, то на коммутаторах генерятся специальные CDR (Charging Data Record) файлы. По сути, это обычные логи, в которых указан номер абонента, дата, время разговора/объем скачанного трафика и т.п. Биллинг же, в определенное время, (например, раз в сутки) подключается к коммутатору, закачивает себе CDRы, рассчитывает стоимость услуг и сохраняет всё в базе данных (обычно, Oracle). Затем в конце месяца абоненту выставляется суммарный счет.

Схема взаимодействия Postpaid платформы с ядром сети оператора.
CSN - circuit switching network; Представлена коммутаторами каналов (MSC).
PSN – packet switching network; Представлена коммутаторами пакетов и шлюзами (SGSN и GGSN соответственно).

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

Авансовая система

В случае авансовой тарификации оператору связи, помимо учета предоставленного объема услуг, требуется решать задачу отслеживания текущего счета абонента и в случае достижения нуля, информировать абонента/отключать предоставление услуги. Поэтому такие системы еще называют Online Charging System (OCS).

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

Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP

CAP (CAMEL Application Part) – протокол прикладного уровня стека SS7, реализующий интеллектуальные услуги в GSM/UMTS сетях (например, prepaid).

Место протокола в стеке . На рисунке также представлен популярный вариант с использованием технологии SIGTRAN (расширение SS7, которое позволяет использовать протоколы “семёрки” поверх IP сети).

По этому протоколу OCS общается с сетью коммутации каналов. Вот пример тарификации исходящего голосового вызова:

Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.

Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point - то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.

INVOKE --- A1 TAG: A1h 1B LEN: 27 --- INVOKE ID --- 02 TAG: 02h INTEGER 01 LEN: 1 02 INVOKE ID: 2 === CAP === --- INVOKE --- --- OPERATION --- 02 TAG: 02h INTEGER 01 LEN: 1 23 OPERATION: 35 = applyCharging --- APPL CHARG --- 30 TAG: 30h SEQUENCE 13 LEN: 19 --- ACH BCC --- 80 TAG: 80h 0C LEN: 12 --- TDC --- A0 TAG: A0h 0A LEN: 10 --- MAX C P D --- 80 TAG: 80h 03 LEN: 3 01 19 40 MAX C P D: 4370

Это часть трейса. Видим, что по протоколу CAP послано сообщение applyCharging, максимальное время разговора (MAX CPD - Maximum Call Period Duration) равно 437,0 сек.

Продублирую картинку до ката: это пример общения по CAP протоколу. Можно оценить временные метки: платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

CAP-протокол может тарифицировать не только голосовые звонки – он так же способен тарифицировать интернет-соединения, SMS, MMS и так далее. Хотя на практике чаще всего для этих нужд применяются специально заточенные протоколы (DIAMETER/OSA).

OSA

OSA (Open Service Access) – открытый программный интерфейс разработанный консорциумом 3GPP и ETSI, часто используется для тарификации VAS-сервисов и мобильного интернета.

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:

При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.

Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение

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

Если тематика протоколов семейства AAA вам интересна, то позже я расскажу про RADIUS, DIAMETER и другие интересные вещи.

Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

Есть 2 основных типа расчета:

Постоплата - выставление счёта за период по его итогам (postpaid)
И авансовая система (prepaid), когда деньги заносятся заранее.

Постоплатная система

Авансовая система

Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP

Место протокола в стеке SS7 . На рисунке также представлен популярный вариант с использованием технологии SIGTRAN (расширение SS7, которое позволяет использовать протоколы “семёрки” поверх IP сети).

Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.

Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point - то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.

OSA

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:

При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.

Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение

План:
Характеристика и назначение биллинговых систем;
Структура и функции биллинговой системы;
Основные подсистемы, характерные для биллинга;
Стандарты биллинговых систем

Ключевые слова: биллинг, мультиязычность, мультивалютность, роуминг, стандарт.

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

Биллинговая система (от англ. bill - счет, billing - выписывание счета) - система, вычисляющая стоимость услуг связи для каждого клиента и хранящие информацию обо всех тарифах и прочих стоимостных характеристиках, которые используются телекоммуникационными операторами для выставления счетов абонентам и взаиморасчетов с другими поставщиками услуг. Цикл выполняемых ими операций именуется биллингом. Биллинговая система (БС) представляет собой бухгалтерскую систему, программное обеспечение разработанное специально для телекоммуникационных операторов. Биллинговые системы используются как в телефонии (проводной и сотовой), так и в сетях передачи данных (интернет провайдеры), а так же имеет место в IP-телефонии. Любая БС создается на основе определенной системы управления базами данных (СУБД). Большинство БС в мире создавалось на основе СУБД Oracle. Среди других СУБД можно выделить Sybase и Informix как рассчитанные на большие объемы информации. А вот названия некоторых биллинговых систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Стоит упомянуть, что под БС обычно подразумевает и аппаратное обеспечение, участвующие в организации биллинга.
Существуют несколько названий биллинговой системы: АСР - автоматизированная система расчетов; ИБС - информационная биллинговая система.
Одним из важных качеств БС является ее гибкость, то есть способность приспосабливаться к изменившимся обстоятельствам. Гибкая система адаптирована не только к одномоментным потребностям оператора; за счет таких качеств, как настраиваемость, модульность и открытость она позволяет решать перспективные задачи. Модульный принцип построения системы - ϶ᴛᴏ ᴛакой принцип, при котором вся система собирается из отдельных частей (модулей). БС тоже состоит из таких модулей - подсистем. БС включает в себя, к примеру, подсистему предварительной обработки данных, подсистему оперативного управления биллингом, подсистему оповещения клиентов. Под открытостью системы подразумевается открытость исходного кода программного продукта, что позволяет оператору не зависеть от разработчика в будущем и самостоятельно обслуживать и модернизировать систему. Тесно связано с гибкостью БС и следующее качество автоматизированных систем расчета - масштабируемость.
Масштабируемость по нагрузке. При росте абонентской базы, появлении дополнительных услуг не должна появляться необходимость изменять или дорабатывать программную часть БС. Увеличение возможностей БС должно достигаться за счет модернизации аппаратной части системы. При проектировании масштабируемых систем необходимо использовать СУБД, рассчитанные на большие объемы данных. СУБД должна быть совместима с различными компьютерными платформами, чтобы обеспечивать поддержку многопроцессорного режима работы.
Надежность - одно из основных требований, предъявляемым к любой системе. Надежность БС определяется надежностью СУБД и технологий, используемых при разработке системы. Далеко не последнее место занимает надежность поставщика (разработчика) прикладного программного обеспечения: время его работы на рынке и, как косвенный показатель, процент присутствия разработанных им систем на телекоммуникационном рынке. При этом надежность БС обеспечивается также соблюдением определенных стандартов при их разработке.
Мультиязычность - возможность устанавливать различные языки для представления информации.
Мультивалютность - возможность работать с любыми валютами
Отложенный биллинг - биллинг, при котором расчеты производятся после состоявшихся звонков.
Горячий биллинг - изменение баланса счета происходит в процессе разговора, и информацию об остатке на Вашем счету можно получить сразу после звонка.
Оптимизация биллинга - улучшение, совершенствование оператором своей БС.
Большие БС - системы, применяемые крупными операторами.
Постинг биллинга - фиксация результатов расчета биллинга; после расчетов результаты становятся доступными пользователям (рассылаются, печатаются).
Так как БС предназначена для автоматизации расчетов с клиентом, то она и должна обеспечивать автоматизацию начиная с заключения договора до выписки счетов за услуги сотовой связи, причем корректно. При помощи подсистем автоматических услуг и автоматического сбора данных АСР должна предоставлять абонентам возможность самообслуживания. Некоторые БС позволяют абонентам оформлять заказы на подключение и производить оплату услуг через Интернет.

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

Рис. 11. Структура биллинговой системы
По функциональным возможностям БС можно разделить на три класса: предназначенные для транснациональных операторов связи, заказные национального масштаба и системы среднего класса для региональных сетей.
БС, относящиеся к первому классу, должны обеспечивать взаимодействие сетей на межнациональном уровне, в различных временных зонах, т.е. они должны быть мультивалютными и мультиязычными.
Заказные системы национального масштаба создаются под определенного оператора. Оператору может понадобиться новая БС, совместимая с уже существующей расчетной системой. Разумеется, стоимость таких единичных систем значительно выше.
В масштабе региона можно вполне обойтись стандартными БС. При этом и такие системы должны обладать качествами, перечисленными выше: гибкостью, масштабируемостью, надежностью. Любая БС создается и настраивается на бизнес-процесс определенного оператора связи, имеет собственный набор функций, соответствующий технологическому циклу предоставления услуг, и может работать с конкретным сетевым оборудованием, поставляющим ей информацию о вызовах и соединениях, - то есть БС не является "коробочным" продуктом. Но существует и стандартный набор функций, поддерживаемых практически всеми БС. В него входят:
операции, выполняемые на этапе предварительной обработки и анализа исходной информации, к примеру, функция получения данных о соединениях и услугах (запросы к коммутатору);
операции управления сетевым оборудованием: функции активации/деактивации (блокировки/разблокировки) абонентов и команды изменения условий подписки абонентов, передаваемые непосредственно в коммутатор;
основные функции приложения СУБД, включающие в себя: тарификацию записей коммутатора о вызовах и услугах; формирование и редактирование таблиц базы данных расчетной системы; выставление счетов и их печать; кредитный контроль счетов; составление отчетов; архивацию.
Как уже было сказано, БС должна обладать гибкостью или модульностью. Каждый элемент АСР обеспечивает реализацию конкретного участка технологической цепочки обслуживания клиента. Основные подсистемы, характерные для биллинга, это: подсистема предварительной обработки данных о соединениях, оперативное управление биллингом и подсистема оповещения клиентов.

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

В интернет-торговле

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

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

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

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

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

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

В страховании

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

Виды биллинга

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

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

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

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

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

Организация биллинга на предприятии

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

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

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

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

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