Este documento fornece instruções sobre como configurar produtos, descontos e outras informações no sistema BRM. Apresenta os passos necessários para configurar GLIDs, produtos, descontos, exportar configurações de produtos e configurar journal keys.
Plan List – Conjunto de Plans que são oferecidos ao cliente. Pode-se oferecer diferentes Plan List para diferentes tipos de clientes.
Por exemplo, uma Plan List para clientes que se registem a partir da Web e outra Plan List para clientes que se registem na loja física.
Plan – É um pacote de negócios que os clientes adquirem para usar os seus serviços.
Por exemplo, pretende-se oferecer um serviço com duas formas diferentes de cobrança. Ao criar um Plan, é escolhido qual o tipo de cobrança.
Deal – Ao adquirir um pacote de produtos num negócio, pode-se oferecer descontos para esses produtos.
Por exemplo, criar um negócio que oferece a taxa de inscrição se o cliente se registar antes de uma determinada data.
Produto – É um objeto que define como cobrar ao cliente por bens e serviços. Um produto consiste em um ou mais rate plans que especificam o custo de cada evento faturável que afeta a conta de um cliente. Ao agrupar rate plans num produto, é definido como cobrar por todos os recursos que se aplicam ao produto.
Por exemplo, rate plans de um serviço ADSL podem cobrar ao cliente segundo dois recursos: dinheiro e horas de conexão.
Descontos – Objeto que aplica descontos aos eventos. É uma redução na cobrança de um evento faturável ou uma alteração no saldo de um recurso, como minutos grátis ou uma fidelização. Aqui é especificado quando e como é que os descontos são aplicados. É possível descontar em tráfego, mensalidades e taxas recorrentes.
Primeiras 3 camadas (Plan List, Plan and Deal ) – Lógica de negócio, é configurado em SIEBEL.
A última camada – Configuração unitária de produtos/descontos, é configurado em BRM.
Na solução da TT, o Siebel é o Master da oferta e o BRM é o Master de catálogo.
O BRM cria produtos e descontos, sincroniza-os com o Siebel via AIA, e Siebel agrega-os nos pacotes de oferta ao cliente.
1 – Configuração das General Ledger Identifier -> são utilizadas para o reporte financeiro
2 – Configuração dos produtos e descontos , onde são incluídas as regras de aplicação
3 – Confguração das Journal Keys -> utilizadas para fazer o mapeamento das contas razão BRM (GLID’s) e das Contas razão SAP
O GLID (General Ledger Identifier) é um identificador que permite a agregação dos valores faturados e mapeia-os para as contas financeiras do sistema.
Os GLID’s estão agrupados em 2 classes diferentes: A classe de Rating (utlizado para eventos de comunicações (delayed)) e a classe de Billing ( utilizado para reportar os valores faturados em real time, como por exemplo, mensalidades e adesões.)
Os GLID’s são configurados no filesystem de BRM no ficheiro CST_pin_glid que se encontra na diretoria sys/data/config.
Existem regras para construir um GLID. Na vossa solução, o GLID é composto por vários níveis, em que cada um deles está associado a um valor, dependendo do tipo de produto ou desconto que se pretende configurar.
Nesta tabela estão as regras para configurar os GLIDs do tipo Rating (delayed).
É necessário atribuir o valor a cada nível, dependendo da descrição do produto/desconto
Paralelamente, nesta tabela encontram-se as regras de configuração de GLID’s para os produtos / descontos do tipo real - time
No slide 12, podemos observar um exemplo de como atribuir um GLID.
Separando o GLID do equipamento “Telemovel – Digicom Bolt 2” pelos seus diferentes níveis, conseguimos perceber que este equipamento pertence à expansão Billing (pré-pago), pertence ao segmento móvel, apenas pode ser atribuído ao serviço móvel (gsm/telephony), não tem qualquer imposto associado.
No slide 13, estão algumas notas que devem ser tomadas em consideração quando se configura novos GLID’s.
O Identificador do GLID deve seguir as regras de numeração identificado nas tabelas dos slides anteriores
A descrição do GLID não deve ter caracteres especiais e deve ser único
O Taxcode utilizado é o IVA00
Adicionalmente, deve ser tomado em consideração que para configurar novos GLID’s é necessário adicionar novos GLID’s ao ficheiro CST_pin_glid e não se deve apagar nenhum outro GLID. Isto porque quando os GLID’s são carregados para a Base de Dados, o processo remove os GLID’s existentes e volta a carregar todos os GLID’s que se encontram no ficheiro de configuração.
Um produto em BRM é um objeto tributável que define como cobrar o cliente
O BRM dispõe de aplicações externas que auxiliam a configuração de produtos e descontos – Pricing Center
Trata-se de um SW auxiliar em BRM que é relativamente fácil e intuitivo (user friendly).
Recomendamos que não o utilizem no ambiente de Produção, porque caso se altera uma configuração de um produto de forma indesejada, essa ação é imediatamente alterada no sistema sem que o utilizador se aperceba.
No slide 15 damos os passos necessários para criar um produto no pricing center.
A nossa recomendação é que sejam executados estes passos apenas no ambiente DEV.
Na primeira janela convem realçar que o nome e a descrição do produto devem coincidir.
Na segunda janela: Produtos que irão ser registados em Siebel devem ser do tipo “Subscription”.
No campo “Applies To:” selecionar o tipo de serviço.
O fractional amount e o Supplier tax ID não são usados nesta solução.
Aqui existem algumas regras comerciais como: as datas que o produto fica disponivel para compra e a quantidade. Esta informação não é configurada em BRM, são configuradas em Siebel.
Configurações default
No slide 19, começamos por configurar os principais atributos de um produto. Nesta vista, devemos selecionar o tipo de evento associado ao produto.
O evento de um produto traduz-se no tipo do produto que se prentede configurar - billing ou rating (eventos delayed, que indicam que são utilizados para efeitos de tráfego).
Os eventos associados aos produtos do tipo billing indicam a recursividade que esse produto vai ser cobrado ao cliente. Podemos configurar o produto para ser aplicado periodicamente (como por exemplo o monthly cycle forward event – Este evento é utilizado para assinaturas mensais) ou para ter uma aplicação única (product purchase fee event, utilizado para taxas únicas)
Na primeira metade da janela estão as configurações que foram feitas nos passos anteriores: como o Nome, Descrição, tipo de serviço e tipo de produto.
Na segunda metade da janela está a configuração do event map que atribui um tipo de evento ao produto. É possível configurar vários tipos de eventos para o mesmo produto.
Por exemplo, se se estiver a configurar uma mensalidade, é possivel adicionar um tipo de evento para cobrar a mensalidade e um tipo de evento para cobrar ao cliente em caso de cancelamento da mensalidade, dependendo se se encontra no periodo de fidelização.
Após o evento estar definido para o produto, passamos à configuração da rate plan. A rate plan agrega um cojunto de regras que vão definir o comportamento do produto.
Existem 2 configurações possíveis para definir o rate_plan – Rate Plan Selector (permite associar mais do que 1 rate plan ao produto) ou Single Rate Plan (apenas tem 1 Rate plan associado ao produto).
Porém, a TT apenas utiliza por default o Single Rate Plan.
Rate plan – Conjunto de configurações que definem o comportamento de um produto.
Rate Plan Selector:
Por exemplo, numa tarifação de chamadas telefónicas, é possivel usar o rate plan selector para determinar qual o Rate Plan a usar baseado na origem da chamada e no destino.
No slide 21, mostra como são configuradas as Tiers de um produto. Um produto pode conter várias configurações, em que são apenas ativas a uma determinada altura.
Para tal, são definidas as Tiers com as datas que se pretendem que essas configurações entrem em vigor.
Um exemplo prático de utilização de várias tiers num produto, é estabelecer um preço para entrar em vigor em 2017 e outro preço para entrar em vigor apenas em 2018.
Após definir as tiers, é configurada a Rate Tag do produto.
Aqui são especificadas algumas regras associadas a esse produto.
Nomeadamente, o grupo a que o produto pertence, o nome do plano (o que irá aparecer no título do serviço da fatura), as regras de suspensão, o nível do detalhe da fatura.
Adicionalmente, são também configuradas as regras de Proration. Onde são definidas o tipo de cobrança no evento da compra e do cancelamento do produto.
Por exemplo, configurar um produto em que não é cobrado nada no ciclo de aquisição e cobra o ciclo inteiro quando é cancelado.
S_FLAGS = [C1][C2][C3][C4][C5]
C1 - Suspensão Processo Não Pagamento
C2 - Suspensão a Pedido
C3 - Suspensão por Roubo
C4 - Suspensão por Fraude
C5 - Suspensão Administrativa
Ações de Suspensão Válidas:
0 - Suspend (Default)
Suspensão do produto quando o serviço é suspenso (Status = 2).
1 - Bill
O produto é faturado mesmo durante o período de suspensão (Status = 1).
2 - Bill se for tráfego
Suspende o produto com prorate ou fullrate dependendo se existe tráfego no serviço.
Caso haja tráfego no ciclo corrente, a suspensão é agendada para o final do ciclo e é cobrado fullrate no mês da suspensão. As suspensões agendadas são executadas pelo opcode PCM_OP_CUSTOM_CUST_POL_SUSPEND_SCHEDULED.
Caso não haja tráfego carregado, o produto é suspenso imediatamente.
3 - Suspend and prorate active period
Suspende o produto com prorate do período pelo qual esteve ativo.
4 - Suspend/activate and fullrate active period
O produto é suspenso, mas é cobrado fullrate dos ciclos de suspensão e ativação
5 - Schedule suspension to the end of the next billing cycle
O produto fica com suspensão agendada para o final do ciclo.
6 - Bill if there is usage account-wide
O produto é suspenso à semelhança do tipo 2, no entanto o tráfego é avaliado para todos os serviços da conta, e não apenas para o serviço do produto a suspender (ver tipo 2).
Por fim, são configurados os Balances impacts do produto.
Aqui, é atribuído o preço do produto, o recurso afetado (por exemplo, em Dólares) e o GLID correspondente.
No Balance Impacts é onde se configura o recurso afetado, o GLID configurado anteriormente e o valor do produto.
Através do Pricing Center, começamos por pesquisar o produto que se pretende fazer essa alteração.
Neste exemplo vamos mostrar como se altera o preço ao Telemovel Digicom Bolt 2.
Uma vez encontrado o produto, basta adicioná-lo ao workspace.
Uma vez encontrado o produto, basta adicioná-lo ao workspace e carregar 2 vezes sobre o produto.
Após realizar este passo, é possível ver as configurações desse produto.
Como se pretende alterar o preço ao produto, começamos por abrir o Rate Plan desse produto e posteriormente, vamos adicionar uma nova Tier a esse produto.
Aqui é configurada a data de ativação dessa tier (que deve coincidir com a data de fim da tier anterior).
Posteriormente, no slide 28, é adicionada uma nova Rate Tag e depois é adicionado no campo scaled amount o novo preço a ser atribuído ao produto.
Com isto damos por terminado a alteração do preço a um produto.
Para tal basta colocar o produto no Workspace e depois exportar as configurações para a máquina local (em formato XML), selecionando a opção file –> export real-time Data.
Os descontos são tipicamente usados para acrescentar ou diminuir valor do montante a faturar ao cliente ou para lhe atribuir recursos virtuais (não monetários, ex. Minutos de conversação grátis).
Os descontos têm uma estrutura única. Eles são compostos por 5 módulos diferentes.
Desconto de catálgo: É um objeto em BRM que é sincronizado com Siebel e pode ser adquirido pelo cliente;
Discount Model: agrega o Discount Trigger e o Discount Rule;
Discount Trigger: Define um conjunto de condições que determinam quando é que o desconto é aplicado;
Discount Rule: Define o valor absoluto ou a percentagem do desconto; Especifica o tipo e o valor de um desconto
Discount Master: Define um conjunto de filtros que definem sobre o quê o desconto é aplicado;
A configuração do desconto deve seguir a sequência Discount Master Discount Rule Discount Trigger Discount Module Desconto (Catálogo)
Começando por configurar o Discount Master do desconto, basta aceder à pipeline toolbox e carregar em Discount Discount Charge Share Master
Posteriormente (no slide 34) é atribuído o Código e o nome do Discount Master. Tanto o código como o nome devem ser únicos, caso contrário o Pricing Center devolve uma mensagem de erro.
Acedendo ao separador do Discount Charge Share Detail e clicando no botão “New”, aparecem os campos ao qual se podem atribuir filtros para os eventos que se pretende que o desconto seja aplicado.
Por norma, na vossa solução, são atribuídos os Group Names configurados nas Rate Tags dos produtos. Desta forma, garantimos que o desconto em específico é apenas aplicado a um conjunto de produtos que partilham a mesma configuração.
A discount rule (slide 36), define o comportamento de aplicação desse desconto. Existe um conjunto de campos obrigatórios que devem ser definidos. O primeiro passo é associar o Discount Master configurado anteriormente, e posteriormente configura-se qual o recurso que deve ser tomado em consideração para ser aplicado o desconto (nos campos Drum Expression, Rule Type e Drum Type). Este recurso pode ser monetário, quantidade (volume de tráfego consumido) ou então um recurso virtual (por exemplo, minutos de chamadas efetuados).
Rule Type (tipo de regra do Desconto):
Treshold – Neste tipo de regra, o desconto só é aplicável se a quantia abrangida estiver dentro dos limites definidos.
Tiered – Neste tipo de regra, o desconto é aplicável mesmo que a quantia abrangida ultrapasse os limites definidos.
Drum Expression (a expressão define o valor que será abrangido pelo desconto):
TotalQ – Quantidade total nos pacotes a cobrar dos EDRs.
TotalC – Valor total dos pacotes a cobrar dos EDRs.
Bal – Valor do balance para o recurso identificado pelo ID.
EBal – Valor do balance do evento identificado pelo ID.
StepQ – Quantidade de um dado recurso que está contida num dado discount step.
StepC – Valor a cobrar que está contido num dado discount step.
EVAL – Valor numérico resultante da função costumizada.
Drum Type (caracteriza o valor resultante do Drum Expression):
Quantity – Define uma quantidade não-monetária.
Charge – Define um valor monetário.
No slide 37, mostra como são definidos os patamares para aplicação de deconto. Tendo em conta o recurso definido no Drum expressions, é possível definir os intervalos em que o desconto é aplicado. (por exemplo: apenas é aplicado o desconto se o cliente realizou mais do que 500 minutos de chamadas).
E posteriormente é definido o impacto que esse desconto irá ter. Para tal é definido o Impact Consume, que traduz-se no tipo recurso que vai ser descontado (ex: Dolares americanos), o valor a ser descontado e a base de cálculo do desconto (como por exemplo o valor monetário da Mensalidade que se pretende aplicar o desconto).
Determinação do número de patamares: (existem 3 casos)
Aplicação de desconto independentemente da utilização
Para este tipo de aplicabilidade, apenas será necessário definir um patamar ilimitado, i.e., cujo limite inferior seja 0 e o limite superior seja infinito. Deste modo todos os montantes de utilização irão estar contidos neste patamar e serão alvos do desconto.
Aplicação de desconto para um determinado montante de utilização
Para este tipo de aplicabilidade apenas será necessário definir um patamar cujo limite superior ou inferior represente o total.
Aplicação de diferentes descontos a diferentes porções de utilização
Para este tipo de aplicabilidade serão necessários múltiplos patamares, de forma a comportar todas as porções de utilização pretendidas.
É especificado o desconto a aplicar a cada patamar.
Balance Impact do Desconto: O balance impact do desconto define o valor de desconto que efetivamente será aplicado bem como o recurso que será afetado.
Recurso afetado – Os recursos afetados podem ser monetários ou virtuais (não-monetários, ex, quantidade de minutos, número de downloads,…).
Conta afetada – Esta especificação é particularmente importante no caso de contas partilhadas por vários clientes, uma vez que o cliente que gera a utilização abrangida pelo desconto poderá não ser o detentor da conta.
Event Owner – Neste caso, o desconto é aplicado ao saldo da conta detentora do evento.
Discount/ChargeShare Owner – Neste caso, o desconto é aplicado ao saldo da conta detentora do desconto.
O balance impact do desconto poderá ser definido através de:
Percentagem – Esta percentagem pode tomar valores positivos ou negativos.
Valor fixo + incremento – o valor fixo define um valor absoluto que, caso o desconto não seja baseado num montante de utilização, será aplicado diretamente no saldo de conta. O incremento permite definir se o montante do desconto é baseado no valor total da expressão ou em porções desse valor. Para atribuir o valor total da expressão, o incremento deverá ser definido como um valor negativo ou igual a 0.
Balance impact do desconto = (Expressão/Incremento) x Valor fixo
Expressão – A expressão define a base de cálculo do valor do desconto, podendo ser introduzido um valor numérico ou utilizada uma das expressões pré-definidas através do “Expression Helper”.
No Discount Trigger são definidas as regras para que o desconto seja “ativo” .
Por norma, podemos configurar para que o desconto esteja sempre ativo, dado que já existem filtros no Discount Master e no Discount Rule.
No slide 39 está o exemplo de como podemos configurar um Discount Trigger para que o desconto ative apenas quando existe valor a ser cobrado ao cliente.
Condition Expression – Introduzir a expressão que define o valor base da condição. Esta expressão é comparada com o Condition Value.
Condition Operator – Selecionar o operator pretendido.
Condition Value – Introduzir o valor da condição.
No slide 40, é criado o último componente das configurações das pipelines – o Discount Model.
Este componente vai agregar o discount trigger e a discount rule previamente configurada.
Discount Model Version: permite a diferenciação entre Models que partilham a mesma configuração, mas têm diferentes datas de validade.
Version – Introduzir o código que identificará a versão do Discount Model.
Valid from – Introduzir a data de entrada em vigor.
Status – Selecionar o estado.
Multiple discounts per event (Selecionar a regra a aplicar quando há mais que um desconto a aplicar ao evento)
Cascade – Estes descontos são aplicados sobre os montantes que não foram ainda sujeitos à aplicação de desconto.
Parallel – Estes descontos são sempre considerados e são aplicados sobre os montantes totais a considerar, independentemente de existirem outros descontos.
Sequential – Estes descontos são aplicados sobre os montantes restantes da aplicação dos descontos anteriores.
Para finalizar a criação de um desconto, falta atribuir as configurações das pipelines a um desconto de catálogo. Para tal é necessário criar um novo desconto, atribuir um nome a descrição e o serviço a que se pretende associar e também associar ao Discount Model que contém todas as configurações de pipeline do desconto.
Priority – Este campo define a prioridade do desconto. Quanto maior for o valor numérico introduzido, maior a prioridade.
Discount Type:
Subscrição – Os descontos de subscrição apenas se aplicam aos perfis de faturação que tenham adquirido o desconto. Este tipo de desconto pode ser aplicado a taxas recorrentes (ex, mensalidades) ou a taxas de aplicação única (ex, taxa de ativação).
Sistema – Estes tipos de descontos são, tipicamente, aplicados a todas as contas existentes no sistema. No entanto, é possível filtrar as contas às quais se pretende aplicar o desconto, de acordo com os critérios residentes na informação dos EDRs.
Como explicado anteriormente, as Journal Keys são utilizadas para fazer o mapeamento das contas razão BRM (GLID’s) e das Contas razão SAP.
Para tal, serão configuradas as Journal Keys de acordo com o tipo de ficheiros a serem integrados em SAP, nomeadamente ficheiros de Cobranças, Adiantamentos, POS’s e Faturação, e o tipo de items (como por exemplo, produtos, descontos, tráfego, ajustes, etc.)
Os slides 45, 46 e 47, descrevem todos os campos que devem ser preenchidos na base de dados para configurar as Journal Keys.
Aqui apresenta-se o exemplo da Journal Key para o equipamento Telemóvel Digicom Bolt 2.
Assim como o Desconto POS. Adicionalmente e apenas para os descontos POS é necessário inserir o seu GLID na tabela CST_POS_DISCOUNTS_GLID_T.
Note-se que a Journal Key (CST_JOURNALS_KEYS_T) tem o BUSINESS_TYPE para preencher e a TT tem 10 business types ( ver tabela CST_BUSINESS_TYPE_CONV_T), assim para o caso deste equipamento na tabela CST_JOURNALS_KEYS_T terá 20 registos, 10 para “Taxa Venda Equipamento – Telemóvel Digicom Bolt 2” e outros 10 para “Desconto POS – Taxa Venda Equipamento – Telemóvel Digicom Bolt 2”.