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

| Відпочинок та захоплення | Побут | Архів | 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 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 протоколом.

Висновок

Якщо тематика протоколів сімейства AAA вам цікава, пізніше я розповім про RADIUS, DIAMETER та інші цікаві речі.

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

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

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

Білінгова система (від англ. bill - рахунок, billing - виписування рахунку) - система, що обчислює вартість послуг зв'язку для кожного клієнта та зберігає інформацію про всі тарифи та інші вартісні характеристики, що використовуються телекомунікаційними операторами для виставлення рахунків абонентам та взаєморозрахунків з іншими постачальниками послуг . Цикл виконуваних ними операцій називається білінгом. Білінгова система (БС) є бухгалтерською системою, програмним забезпеченням розробленим спеціально для телекомунікаційних операторів. Білінгові системи використовуються як у телефонії (провідниковий і стільниковий), так і в мережах передачі даних (інтернет провайдери), а також має місце в IP-телефонії. Будь-яка БС створюється з урахуванням певної системи управління базами даних (СУБД). Більшість БС у світі створювалося на основі СУБД Oracle. Серед інших СУБД можна виділити Sybase та Informix як розраховані великі обсяги інформації. А ось назви деяких білінгових систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Варто згадати, що БС зазвичай має на увазі і апаратне забезпечення, що беруть участь в організації білінгу.
Існують кілька назв білінгової системи: АСР – автоматизована система розрахунків; ІХС - інформаційна білінгова система.
Однією з важливих якостей БС є її гнучкість, тобто здатність пристосовуватися до обставин, що змінилися. Гнучка система адаптована не тільки до одномоментних потреб оператора; за рахунок таких якостей, як настроюваність, модульність та відкритість вона дозволяє вирішувати перспективні завдання. Модульний принцип побудови системи - це такий принцип, у якому вся система збирається з окремих частин (модулів). БС також складається з таких модулів – підсистем. БС включає, наприклад, підсистему попередньої обробки даних, підсистему оперативного управління білінгом, підсистему оповіщення клієнтів. Під відкритістю системи мається на увазі відкритість вихідного коду програмного продукту, що дозволяє оператору не залежати від розробника у майбутньому та самостійно обслуговувати та модернізувати систему. Тісно пов'язане з гнучкістю БС та наступна якість автоматизованих систем розрахунку – масштабованість.
Масштабованість по навантаженню. При зростанні абонентської бази, появі додаткових послуг не повинна виникати потреба змінювати або доопрацьовувати програмну частину БС. Збільшення можливостей БС має досягатись за рахунок модернізації апаратної частини системи. При проектуванні систем, що масштабуються, необхідно використовувати СУБД, розраховані на великі обсяги даних. СУБД має бути сумісною з різними комп'ютерними платформами, щоб забезпечувати підтримку багатопроцесорного режиму роботи.
Надійність - одна з основних вимог, що висуваються до будь-якої системи. Надійність БС визначається надійністю СУБД та технологій, що використовуються при розробці системи. Не останнє місце посідає надійність постачальника (розробника) прикладного програмного забезпечення: час його роботи над ринком і, як опосередкований показник, відсоток присутності розроблених їм систем на телекомунікаційному ринку. При цьому надійність БС забезпечується дотриманням певних стандартів при їх розробці.
Мультиязичность - можливість встановлювати різні мови подання інформації.
Мультивалютність – можливість працювати з будь-якими валютами
Відкладений білінг - білінг, при якому розрахунки здійснюються після дзвінків.
Гарячий білінг - зміна балансу рахунку відбувається в процесі розмови, і інформацію про залишок на рахунку можна отримати відразу після дзвінка.
Оптимізація білінгу – покращення, вдосконалення оператором своєї БС.
Великі БС – системи, що застосовуються великими операторами.
Постінг білінгу - фіксація результатів розрахунку білінгу; після розрахунків результати стають доступними користувачам (розсилаються, друкуються).
Оскільки БС призначена для автоматизації розрахунків із клієнтом, вона й має забезпечувати автоматизацію починаючи з укладання договору до виписки рахунків послуги стільникового зв'язку, причому коректно. За допомогою підсистем автоматичних послуг та автоматичного збору даних АСР має надавати абонентам можливість самообслуговування. Деякі БС дозволяють абонентам оформляти замовлення на підключення та здійснювати оплату послуг через Інтернет.

Структура та функції білінгової системи
Схема організації білінгу не складна: інформація про з'єднання та їх тривалість записується комутатором і після попередньої обробки передається до розрахункової системи. Розрахунковій системі "відомі" тарифи. Вона ідентифікує виклик і виконує необхідні розрахунки, формуючи цим рахунок абонента. Очевидно, що в пам'яті системи повинні зберігатися не тільки нормативи, тарифи та інформація про послуги, а й дані про клієнтів, укладені контракти з абонентами та сторонніми постачальниками послуг зв'язку (якщо такі є), а також вартість передачі інформації по різних каналах і напрямках. (Системою має бути також передбачено наявність дилерів: вони можуть бути інші розцінки, наприклад, на підключення). Крім цього, будь-яка БС повинна мати базу, що зберігає історію платежів: лише ці відомості дозволяють контролювати процес оплати та автоматизувати так звану активацію/деактивацію абонентів. Цю функцію БС можна назвати захисною, оскільки вона дозволяє користуватися послугами зв'язку тим, хто їх не платить.

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

Слово білінг означає попередній розрахунокчогось або підготовчі дії для здійснення певної операції для кожного окремо взятого покупця.

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

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

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

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

Миттєве списання коштів за надані послуги. Особливо це добре видно на прикладі мобільного зв'язку, коли відразу після або під час надання послуги відбувається підрахунок вартості послуги та списання коштів з рахунку.

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

Це інструмент, який все більше використовується економістами та менеджерами в роботі. Ці системи дозволяють швидко, і що найголовніше – дешево, отримувати потрібну про покупців та їх переваги інформацію.

У страхуванні

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

Види білінгу

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

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

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

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

ІХС ж використовується якраз для збору та аналізу інформації про покупців та формування асортименту підприємства. Їх встановлюю в основному великі інтернет-магазини, що займаються роздрібним продажем товарів та послуг.

Організація білінгу на підприємстві

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

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

У яких випадках використання білінгових систем не дає позитивного результату

Незважаючи на всі переваги, які дають такі системи, їх використання в деяких випадках не приносить позитивного ефекту, а в деяких випадках навіть є шкідливим. Застосування білінгу має сенс у тих сферах, у яких використовуються системи безготівкових розрахунків: перекази з банківських карток або електронних гаманців.

Тільки так підприємству вдасться автоматизувати процес зборута обробки великих обсягів інформації та вести персональний облік та аналіз даних окремо взятого клієнта.