Faturamento de telecomunicações - processos de classificação

Taxa é a cobrança / preço pela ocorrência de um evento. Exemplos de tarifa incluem cobrança pela duração da chamada telefônica: Por exemplo: "0,40 INR por 1 minuto" ou uma quantidade específica. Por exemplo: 10,00 INR para download de 1 MB ou pode ser cobrado pela qualidade do serviço.

Já explicamos que Evento é uma ocorrência única de uso de produto / serviço. Os eventos são capturados pelos elementos da rede na forma de CDRS / UDRs e passados para o sistema de Faturamento para classificação e faturamento.

Classificação é o processo de determinação da cobrança / preço de eventos individuais. Por exemplo, o preço de uma chamada de 2 minutos é 0,80 INR com a taxa de 0,40 INR por minuto.

O Rating Engine, que faz parte do sistema de Faturamento, realiza essa função de classificação.

Processo de Classificação

O Rating Engine recebe os eventos na forma de registros de dados chamados de Call Detail Records (CDRs) ou Usage Detail Records (UDRs), que descrevem o uso de um produto / serviço. Um CDR é uma sequência de dados que contém informações da chamada, como data e hora da chamada, duração da chamada, parte chamadora, parte chamada, etc., que são usados para classificar os eventos.

Há uma lista de funções básicas do Rating / Rating Engine -

Aceitar CDRs do Sistema de Mediação ou de outros provedores de serviços ou parceiros de roaming em caso de uso de roaming.
Validando os CDRs e eliminando quaisquer registros duplicados. Esses eventos duplicados são armazenados em uma tabela de banco de dados para verificação posterior.
Para determinar a conta do cliente que deve ser cobrada pelo evento. Aqui, o processo Rate seleciona a origem do evento (número de celular ou endereço IP, etc.) e verifica o banco de dados para verificar se esta origem do evento está associada a alguma conta. Esta etapa é chamada de Orientação de eventos.
Se o evento não puder ser guiado, então este evento será rejeitado e poderá ser colocado na categoria de suspense. Esses eventos rejeitados são armazenados em uma tabela de banco de dados para verificação posterior.
Calcular o custo / preço do evento de acordo com a tarifa de rating (também referido como plano de tarifas).
Aplicar quaisquer descontos de tempo de classificação aplicáveis. Os primeiros cinco minutos podem ser gratuitos e, depois disso, a ligação será cobrada à taxa normal. Esses tipos de descontos são chamados de descontos por tempo de classificação.
Para armazenar o evento classificado no banco de dados para fins de faturamento ou enviá-lo ao sistema externo para faturamento.

A imagem a seguir mostra uma visão geral do Rating Engine e suas funções associadas -

As informações do cliente determinam o plano de tarifas (tarifa de classificação) a ser usado no cálculo de encargos / preços. O mecanismo de classificação usa as tabelas de classificação e as informações do evento dos CDRs (por exemplo, distância, hora do dia, local da chamada, duração ou volume do evento, etc.) para calcular a cobrança real de cada chamada.

Eventos duplicados

Um evento duplicado é definido como qualquer evento não faturado relacionado a outro evento não faturado de todas as seguintes maneiras -

Os números das contas são idênticos.
As fontes de eventos são idênticas.
Os IDs de tipo de evento são idênticos.
As datas e horas dos eventos são idênticas.

Quaisquer outros critérios podem ser definidos no sistema de faturamento para identificar eventos duplicados. Existem várias situações que podem fazer com que eventos duplicados sejam enviados ao sistema de Faturamento -

Uma falha do mecanismo de filtragem do sistema de mediação.
Erros de codificação no software do sistema de mediação.
Uma repetição de todo ou parte de um arquivo de evento que está sendo passado para o Mecanismo de Avaliação.

Eventos Rejeitados

Quando o Billing System encontra um problema com um evento específico, o evento ofensivo é rejeitado. A rejeição pode ser devido a problemas com qualquer um dos seguintes -

O próprio evento.
O plano de tarifas.
Dados do cliente e da conta.
Dados de configuração.

Existem três razões principais para rejeitar um evento -

Erros de análise evitam que o Sistema de Faturamento leia as informações no registro de detalhes do evento. Um erro de análise pode ocorrer porque os dados no registro de eventos estão corrompidos ou no formato errado.
Erros indeléveis impedem Geneva de identificar a origem do evento ou conta associada ao evento. Um erro indescritível pode ocorrer porque a origem do evento ainda não existe no banco de dados do sistema de faturamento.
Erros irrecuperáveis impedem o Sistema de Faturamento de calcular um custo para o evento. Um erro irrecuperável pode ocorrer devido a problemas com um plano de tarifas.

Todos os eventos rejeitados são lançados em uma conta especial, que é chamada internal account ou suspense account e esses eventos rejeitados são chamados suspense events. O departamento financeiro acompanha todos os eventos rejeitados e os contabiliza como parte da perda de receita. O departamento de TI sempre dá muita atenção para resolver eventos rejeitados e avaliá-los corretamente para economizar receita.

Se um evento rejeitado não puder ser corrigido e a Operadora não quiser postá-lo em uma conta interna, o evento pode ser descartado. Quando um evento é descartado, não será submetido ao Rating Engine e nenhuma tentativa de avaliá-lo ocorrerá.

Avaliação em tempo real

A classificação em tempo real é o processo de pegar os eventos à medida que ocorrem e classificá-los imediatamente, com o menor atraso possível entre a geração do evento e o custo. A classificação em tempo real pode ser contrastada com a classificação baseada em arquivo, onde os detalhes do evento são armazenados em um buffer de arquivo por horas, dias ou semanas antes que todo o arquivo seja finalmente avaliado.

O processo do sistema em tempo real inclui transações de comércio eletrônico e download de dados. Qualquer aplicativo em que os eventos devam ser avaliados e aplicados rapidamente à conta de um cliente é um candidato adequado para avaliação em tempo real.

Rerating Events

Existem várias situações em que pode ser necessário rerar eventos. Por exemplo, quando -

Um erro no plano de tarifas usado resultou em eventos com preços incorretos.
Os eventos foram carregados na conta errada (devido ao registro incorreto da origem do evento).
Um plano de taxas existente foi substituído em algum ponto entre a última e a próxima data de faturamento.
O plano de taxa, plano de preço ou fonte de evento para um produto foi alterado retroativamente.

O processo para rerar eventos é muito simples e é o seguinte -

Descarregue / libere todos os eventos do banco de dados usando o utilitário fornecido. A maior parte do sistema de faturamento fornece um utilitário para descarregar ou cancelar a classificação de todos os eventos avaliados.
Resolva o problema onde quer que ele esteja.
Reenvie os eventos para classificação pelo Mecanismo de Classificação.

Eventos Parciais

Os eventos parciais permitem que o equilíbrio do cliente seja mantido enquanto um evento está em andamento.

Por exemplo, no caso de um download de dados longo, o sistema de mediação continuará enviando eventos parciais para o sistema de faturamento para que o sistema de faturamento continue classificando-os em vez de esperar pela conclusão do evento, e assim que o limite de crédito do cliente violar, a conta será bloqueada e O elemento da rede será informado para encerrar a chamada.

Limites e ações

O mecanismo de classificação pode verificar automaticamente se algum limite de tempo de classificação, incluindo limites de desconto de tempo de classificação, foi atingido.

Limites de tempo de classificação ajudam a proteger as operadoras de muitas perdas de receita. Por exemplo, um cliente pode não estar disposto a pagar mais do que seu limite de crédito, nesse caso, torna-se necessário encerrar a chamada do cliente assim que atingir o limite de crédito.

Se for necessário realizar uma ação de tempo de classificação, é importante ter a maior classificação possível em tempo real.

O que vem a seguir?

Até agora, vimos como um cliente gera uso e como o sistema de mediação empurra esse uso (CDRs) para o Sistema de Faturamento e como um Sistema de Faturamento avalia esses CDRs.

No próximo capítulo, discutiremos como coletar todos os CDRs avaliados para o mês inteiro e gerar a fatura / fatura final, que é enviada ao cliente final para coletar receita pelos serviços prestados.