Тариф — это плата / цена за возникновение события. Примеры тарифа включают плату за длительность телефонного звонка: например: «0,40 INR за 1 минуту» или определенное количество. Например: 10,00 INR за загрузку 1 МБ или за качество обслуживания.
Мы уже объяснили, что событие — это единичное явление использования продукта / услуги. События регистрируются сетевыми элементами в форме CDRS / UDR и передаются в биллинговую систему для оценки и выставления счетов.
Рейтинг — это процесс определения стоимости / цены отдельных событий. Например, стоимость звонка за 2 минуты составляет 0,80 INR со скоростью 0,40 INR за минуту.
Система оценки, являющаяся частью системы выставления счетов, выполняет эту функцию оценки.
Рейтинг процесса
Механизм оценки получает события в форме записей данных, называемых записями сведений о вызовах (CDR) или записями сведений об использовании (UDR), которые описывают использование продукта / услуги. CDR — это строка данных, которая содержит информацию о вызове, такую как дата и время вызова, длина вызова, вызывающая сторона, вызываемая сторона и т. Д., Которые используются для оценки событий.
Существует список основных функций Rating / Rating Engine —
-
Принятие CDR от Системы посредничества или других поставщиков услуг или партнеров по роумингу в случае использования роуминга.
-
Проверка CDR и устранение любых дублирующих записей. Эти повторяющиеся события хранятся в таблице базы данных для последующей проверки.
-
Определить учетную запись клиента, которая должна быть списана за мероприятие. Здесь процесс Rate выбирает источник события (номер мобильного телефона или IP-адрес и т. Д.) И проверяет базу данных, чтобы проверить, связан ли этот источник события с какой-либо учетной записью. Этот шаг называется Event Guiding.
-
Если событие не может быть направлено, то это событие будет отклонено и может быть помещено в категорию ожидания. Эти отклоненные события сохраняются в таблице базы данных для последующей проверки.
-
Для расчета стоимости / цены мероприятия согласно рейтинговому тарифу (также называемому тарифным планом).
-
Чтобы применить любой применимый рейтинг времени скидки. Это может быть первые пять минут бесплатно, и после этого звонка будет взиматься по обычному тарифу. Такой вид скидок называется рейтингом временных скидок.
-
Для сохранения оцененного события в базе данных для выставления счета или отправки его во внешнюю систему для выставления счета.
Принятие CDR от Системы посредничества или других поставщиков услуг или партнеров по роумингу в случае использования роуминга.
Проверка CDR и устранение любых дублирующих записей. Эти повторяющиеся события хранятся в таблице базы данных для последующей проверки.
Определить учетную запись клиента, которая должна быть списана за мероприятие. Здесь процесс Rate выбирает источник события (номер мобильного телефона или IP-адрес и т. Д.) И проверяет базу данных, чтобы проверить, связан ли этот источник события с какой-либо учетной записью. Этот шаг называется Event Guiding.
Если событие не может быть направлено, то это событие будет отклонено и может быть помещено в категорию ожидания. Эти отклоненные события сохраняются в таблице базы данных для последующей проверки.
Для расчета стоимости / цены мероприятия согласно рейтинговому тарифу (также называемому тарифным планом).
Чтобы применить любой применимый рейтинг времени скидки. Это может быть первые пять минут бесплатно, и после этого звонка будет взиматься по обычному тарифу. Такой вид скидок называется рейтингом временных скидок.
Для сохранения оцененного события в базе данных для выставления счета или отправки его во внешнюю систему для выставления счета.
На следующем рисунке показан обзор механизма оценки и связанных с ним функций —
Информация клиента определяет тарифный план (тариф тарифа) для использования при расчете платы / цены. Механизм оценки использует таблицы рейтинга и информацию о событии из CDR (например, расстояние, время дня, местоположение вызова, продолжительность или громкость события и т. Д.), Чтобы рассчитать фактическую плату за каждый вызов.
Дубликаты событий
Дублирующее событие определяется как любое неоплаченное событие, которое связано с другим неоплаченным событием всеми следующими способами:
- Номера счетов идентичны.
- Источники событий идентичны.
- Идентификаторы типов событий идентичны.
- Даты и время проведения мероприятия идентичны.
Любые другие критерии могут быть определены в биллинговой системе для выявления повторяющихся событий. Существует ряд ситуаций, которые могут привести к тому, что повторяющиеся события будут отправлены в биллинговую систему.
- Отказ механизма фильтрации посреднической системы.
- Ошибки кодирования в программном обеспечении системы посредничества.
- Повторение всего или части файла события, передаваемого в механизм оценки.
Отклоненные события
Когда в биллинговой системе возникает проблема с определенным событием, оскорбительное событие отклоняется. Отказ может быть вызван проблемами с одним из следующих:
- Само событие.
- Тарифный план.
- Данные клиента и аккаунта.
- Данные конфигурации.
Есть три основных причины отклонения события —
-
Ошибки синтаксического анализа не позволяют Биллинговой системе прочитать информацию в подробной записи события. Ошибка синтаксического анализа может возникнуть из-за того, что данные в записи события повреждены или имеют неправильный формат.
-
Неопровержимые ошибки не позволяют Женеве определить источник события или учетную запись, связанную с событием. Может возникнуть неуправляемая ошибка, поскольку источник событий еще не существует в базе данных биллинговой системы.
-
Неустранимые ошибки не позволяют Billing System рассчитать стоимость события. Неисправимая ошибка может возникнуть из-за проблем с тарифным планом.
Ошибки синтаксического анализа не позволяют Биллинговой системе прочитать информацию в подробной записи события. Ошибка синтаксического анализа может возникнуть из-за того, что данные в записи события повреждены или имеют неправильный формат.
Неопровержимые ошибки не позволяют Женеве определить источник события или учетную запись, связанную с событием. Может возникнуть неуправляемая ошибка, поскольку источник событий еще не существует в базе данных биллинговой системы.
Неустранимые ошибки не позволяют Billing System рассчитать стоимость события. Неисправимая ошибка может возникнуть из-за проблем с тарифным планом.
Все отклоненные события публикуются в специальной учетной записи, которая называется внутренней учетной записью или промежуточной учетной записью, а эти отклоненные события называются промежуточными событиями . Финансовый отдел отслеживает все отклоненные события и считает их частью потери дохода. ИТ-отдел всегда уделяет много внимания устранению отклоненных событий и правильной оценке их для экономии доходов.
Если отклоненное событие не может быть исправлено, и Оператор не хочет публиковать его во внутренней учетной записи, событие можно отменить. Когда событие отбрасывается, оно не будет отправлено в механизм оценки, и дальнейшие попытки оценить его не будут.
Рейтинг в реальном времени
Оценка в режиме реального времени — это процесс принятия событий по мере их возникновения и их немедленной оценки с минимально возможной задержкой между созданием событий и их оценкой. Оценка в реальном времени может быть сопоставлена с оценкой на основе файла, когда сведения о событии хранятся в файловом буфере в течение нескольких часов, дней или недель до окончательной оценки всего файла.
Системный процесс в реальном времени включает транзакции электронной торговли и загрузку данных. Любое приложение, в котором события должны оцениваться и быстро применяться к учетной записи клиента, является подходящим кандидатом для оценки в режиме реального времени.
Переоценка событий
Есть несколько ситуаций, в которых может потребоваться переоценка событий. Например, когда —
-
Ошибка в используемом тарифном плане привела к событиям с неправильной ценой.
-
События были загружены не с той учетной записи (из-за неправильной регистрации источника событий).
-
Существующий тарифный план был заменен в некоторый момент между последней и следующей датой выставления счета.
-
Тарифный план, ценовой план или источник событий для продукта были ретроспективно изменены.
Ошибка в используемом тарифном плане привела к событиям с неправильной ценой.
События были загружены не с той учетной записи (из-за неправильной регистрации источника событий).
Существующий тарифный план был заменен в некоторый момент между последней и следующей датой выставления счета.
Тарифный план, ценовой план или источник событий для продукта были ретроспективно изменены.
Процесс переоценки событий очень прост и выглядит следующим образом:
-
Разгрузить / Unrate все события из базы данных, используя предоставленную утилиту. Большая часть биллинговой системы предоставляет утилиту для выгрузки или классификации всех рейтинговых событий.
-
Исправьте проблему, где бы она ни находилась.
-
Повторно отправьте события для оценки с помощью двигателя рейтинга.
Разгрузить / Unrate все события из базы данных, используя предоставленную утилиту. Большая часть биллинговой системы предоставляет утилиту для выгрузки или классификации всех рейтинговых событий.
Исправьте проблему, где бы она ни находилась.
Повторно отправьте события для оценки с помощью двигателя рейтинга.
Частичные события
Частичные события позволяют поддерживать баланс клиента во время события.
Например, в случае длительной загрузки данных система-посредник будет продолжать отправлять частичные события в биллинговую систему, чтобы биллинговая система сохраняла их рейтинг, а не дожидалась завершения события, и как только клиент нарушит лимит кредита, аккаунт будет заблокирован и Элемент сети будет проинформирован о прекращении вызова.
Пороги и Действия
Механизм оценки может автоматически проверять, были ли достигнуты какие-либо пороговые значения рейтинга, включая пороговые значения дисконтирования времени рейтинга.
Оценка временных порогов помогает защитить операторов от значительной потери доходов. Например, клиент может не захотеть платить больше, чем его кредитный лимит, в таком случае возникает необходимость прервать звонок клиента, как только он достигнет порога кредитного лимита.
Если требуется предпринять действия по оценке времени, важно иметь максимально возможную оценку в реальном времени.
Что дальше?
До сих пор мы видели, как клиент генерирует использование и как посредническая система передает это использование (CDR) в биллинговую систему и как биллинговая система оценивает эти CDR.
В следующей главе мы обсудим, как собрать все оцененные CDR за весь месяц и сгенерировать окончательный счет / счет, который будет отправлен конечному клиенту для сбора дохода за предоставленные услуги.