Conciliação de faturação de SMS A2P: CDR, DLR e faturas sem falsas equivalências

Que problema resolve a conciliação de faturação de SMS A2P

A conciliação de faturação de SMS A2P permite verificar se os valores cobrados por um fornecedor podem ser explicados através de evidência operacional rastreável. O seu objetivo não é transformar uma métrica de entrega numa decisão financeira automática, mas comparar conjuntos de registos, identificar diferenças e aplicar a regra comercial acordada para a rota e o fornecedor.

Esta função deve envolver operações, wholesale, gestão de fornecedores e finanças. As finanças podem controlar montantes, períodos e aprovações, mas normalmente não dispõem, por si só, do contexto necessário para interpretar identificadores, reenvios, rotas, segmentos, códigos de erro ou estados tardios.

O princípio central é simples: aceitação técnica, CDR do fornecedor, DLR e receção observada no terminal são sinais diferentes. Uma conciliação sólida preserva essa diferença, em vez de resumir todos os eventos sob uma única etiqueta de “entregue” ou “faturável”.

• Não utilize um DLR como regra universal de cobrança.
• Não trate a ausência de DLR como prova automática de falha ou de não faturabilidade.
• Não discuta diferenças apenas com totais agregados quando existirem identificadores de mensagem.
• Aplique a regra contratual documentada antes de calcular ajustes ou aceitar cobranças.

As quatro fontes de evidência que devem ser comparadas

Uma conciliação reproduzível começa com registos de origem separados. Cada fonte responde a uma pergunta diferente e tem limitações distintas. O registo interno confirma o que a sua plataforma tentou enviar; a resposta de aceitação indica como o fornecedor ou SMSC respondeu ao envio; o CDR suporta o conjunto reportado pelo fornecedor; e o DLR fornece um estado técnico posterior quando foi solicitado e recebido.

Em SMPP, o submit_sm_resp é a resposta ao submit_sm e pode incluir o identificador de mensagem atribuído pelo SMSC. Os recibos de entrega são devolvidos posteriormente através de deliver_sm ou data_sm. Esta sequência é importante: receber uma aceitação não equivale a ter um estado final, e ter um estado final não substitui a regra de faturação acordada.

• Registo interno de envio: ID próprio, destino original, payload ou referência de conteúdo, remetente, rota prevista, marca temporal e resultado local.
• Resposta de aceitação: código de resposta, ID do fornecedor ou SMSC quando existir e marca temporal de receção.
• CDR ou extrato equivalente: registos, campos, período e critérios disponibilizados pelo fornecedor.
• DLR ou estado: valor original, estado normalizado, código de erro, evidência de rede disponível e marcas temporais de submit e conclusão quando recebidas.

DLR, aceitação e receção: o que demonstra cada sinal

A aceitação técnica demonstra que o sistema recetor aceitou ou respondeu à tentativa de submit de acordo com a interface utilizada. Não demonstra, por si só, a entrega ao dispositivo nem a leitura por uma pessoa. O âmbito exato dessa aceitação deve ser interpretado segundo a integração e o acordo operacional aplicável.

Um DLR representa um evento posterior comunicado pela cadeia de mensagens. A norma SMPP prevê estados e formatos de recibo, incluindo formatos específicos do fornecedor. Além disso, a especificação técnica distingue relatórios emitidos pelo Service Centre dos emitidos pela estação móvel: um relatório do Service Centre pode confirmar a receção por esse centro, enquanto um emitido pela estação móvel confirma a receção pelo equipamento, não a leitura humana.

A receção observada num terminal pode ser evidência adicional em testes controlados, mas também não deve ser confundida automaticamente com leitura, consentimento, identidade ou obrigação de cobrança. A base de cobrança não é determinada pela semântica geral de um DLR: deve ser expressamente definida no contrato ou acordo operacional por fornecedor e rota.

• Aceitação: evidência de uma resposta à apresentação técnica da mensagem.
• DLR: evidência de um estado reportado; preserve o seu valor original e contexto.
• Receção no terminal: pode demonstrar receção técnica em testes, não leitura humana.
• Cobrança: resultado de uma regra comercial documentada, não de uma etiqueta técnica isolada.

Definir a unidade conciliável antes de comparar

O objeto de conciliação deve ser definido antes de iniciar o tráfego ou antes do ciclo de faturação seguinte. Se uma parte comparar mensagens lógicas e a outra segmentos técnicos, uma discrepância pode ser aparente e não um erro de faturação. A concatenação exige uma decisão explícita sobre a unidade de comparação e liquidação.

O SMPP prevê campos para identificar mensagens concatenadas, incluindo um número de referência, o total de segmentos e a sequência de cada segmento. Preserve estes campos quando estiverem disponíveis e associe cada segmento à mensagem lógica correspondente, sem substituir um pelo outro.

A correlação não deve depender apenas da hora nem da ordem de chegada. O SMPP permite respostas fora de sequência. Por isso, o identificador interno e o identificador devolvido pelo fornecedor ou SMSC devem ser as chaves principais quando existirem, com atributos complementares para resolver casos incompletos.

• ID interno imutável da tentativa de envio.
• ID atribuído pelo fornecedor ou SMSC, quando recebido.
• Destino original e destino normalizado de acordo com uma política documentada.
• Marca temporal de envio interno, aceitação, submit do fornecedor e estado final, com fuso horário e precisão.
• Fornecedor, rota ou referência comercial aplicável no momento do envio.
• Remetente, tipo de tráfego e referência de conteúdo quando necessário para investigação.
• Dados de segmentação e relação com a mensagem lógica.
• Estado original, código de erro e campos de evidência de rede disponíveis.

Acordar as regras de cobrança e a troca de dados

A especificação SMPP define mecanismos técnicos de envio, respostas, identificadores e estados, mas não determina que evento é faturável. Por isso, cada relação com um fornecedor deve ter uma regra comercial e operacional que indique qual é a unidade faturada, qual é o evento de referência e como são tratadas as exceções.

A regra deve estar associada à rota ou ao produto aplicável. Se uma organização utilizar vários fornecedores ou rotas, não deve transferir sem validação uma política de conciliação de uma relação para outra. Também é aconselhável versionar as regras para aplicar aquela que estava em vigor no momento do tráfego.

O acordo de troca de dados deve evitar ambiguidades que surgem no fecho: semântica das colunas, formato dos identificadores, fuso horário, período de corte, frequência de entrega de CDR e prazo para estados tardios.

• Unidade de cobrança: segmento, mensagem lógica ou outra unidade expressamente acordada.
• Evento de referência para cobrança e tratamento de rejeições, reenvios e ajustes.
• Esquema de CDR, tipos de ficheiro ou interface, codificação e semântica de cada campo.
• Chaves de correlação e regras de prioridade entre identificadores.
• Fuso horário, precisão temporal, período de corte e data de disponibilização do CDR.
• Janela para DLR tardios e procedimento de reabertura ou ajuste.
• Responsáveis por investigar, aprovar, contestar e registar resoluções.

Construir um modelo de estados útil para a conciliação

Os estados devem ser preservados em dois níveis. O primeiro é o valor original recebido do fornecedor, juntamente com o código de erro e qualquer evidência adicional disponível. O segundo é uma categoria interna definida para operar a conciliação. Esta normalização permite comparar fornecedores sem destruir a informação necessária para rever casos concretos.

Evite utilizar uma categoria interna como se fosse uma declaração universal sobre entrega ou faturação. Um estado técnico pode ser útil para classificar um processo, mas a decisão de cobrança, crédito ou investigação depende da política acordada e da evidência disponível.

A ausência de DLR deve constar como ausência de evidência de estado nas condições concretas do envio. Em SMPP, o retorno de recibos depende do que foi solicitado através de registered_delivery e o conteúdo pode variar consoante o fornecedor. Por isso, a ausência de DLR não equivale automaticamente a não entrega, nem a um ajuste automático.

• Aceite tecnicamente.
• Rejeitado na resposta de submit, se esse evento for registado.
• Estado final reportado pelo fornecedor ou SMSC.
• Estado intermédio ou não final, se recebido.
• Sem DLR disponível dentro da janela acordada.
• Sem correlação suficiente.
• Pendente de investigação ou de resolução comercial.

Processo passo a passo para conciliar CDR, estados e faturas

O processo deve ser executado sobre uma cópia de trabalho, sem alterar os registos originais. Primeiro, são ingeridos os eventos internos, as respostas de aceitação, os DLR e o CDR do fornecedor. Em seguida, valida-se o esquema, registam-se os ficheiros ou extrações recebidos e preserva-se a sua proveniência.

A normalização é aplicada de forma versionada: destinos, fusos horários, nomes de estado e formatos de identificador. Depois, é efetuada a correlação, dando prioridade às chaves fortes, em especial ao ID interno e ao ID do fornecedor. As correspondências por atributos secundários devem ficar assinaladas como tal e ser auditáveis.

Só depois de identificar os conjuntos comparáveis deve ser aplicada a regra comercial em vigor. O resultado não é apenas um saldo: deve incluir as diferenças classificadas, a evidência disponível, o responsável e o passo seguinte.

• 1. Feche o período de referência de acordo com o calendário acordado.
• 2. Faça a ingestão e preservação das fontes sem alterações: eventos internos, respostas, DLR, CDR e fatura.
• 3. Valide a integridade: campos obrigatórios, duplicados de ficheiro, fuso horário e período abrangido.
• 4. Faça a normalização versionada de identificadores, destinos, marcas temporais e estados.
• 5. Correlacione por IDs; utilize atributos secundários apenas como apoio e assinale o nível de confiança.
• 6. Agrupe por fornecedor, rota, período e unidade de cobrança acordada.
• 7. Classifique as diferenças e aplique a política contratual.
• 8. Efetue revisão operacional, aprovação financeira e registo de ajustes ou contestações.

Diferenças frequentes e como tratá-las

Os registos duplicados exigem distinguir entre um evento repetido na exportação, um reenvio legítimo e duas tentativas diferentes. Não elimine duplicados apenas por partilharem destino ou conteúdo. Examine os identificadores, as marcas temporais, a rota e a relação entre o submit original e qualquer reenvio.

A concatenação pode gerar diferenças quando um lado contabiliza segmentos e o outro agrupa por mensagem lógica. A solução não é forçar uma equivalência posterior, mas reconstruir a relação entre segmentos e mensagem lógica e aplicar a unidade definida no acordo.

As diferenças temporais podem surgir porque os eventos ocorrem em momentos distintos: envio interno, aceitação, submit, estado final e corte de faturação. Os DLR finais podem chegar após o fecho inicial. É necessário separar o período de tráfego do período de disponibilidade de evidência e utilizar a janela de ajuste acordada.

As rejeições, os estados tardios e os registos ausentes devem ser mantidos como categorias distintas. Um registo ausente do CDR não é idêntico a uma rejeição técnica; um DLR tardio não é igual a um DLR inexistente; e um estado reportado não substitui o registo faturado do fornecedor.

• Duplicados: reveja a identidade do evento, os reenvios e a repetição de exportações.
• Concatenação: compare a unidade técnica e a unidade comercial acordada.
• Marcas temporais: preserve o evento, o fuso horário, a precisão e a data de receção dos dados.
• Estados tardios: aplique a janela acordada antes de encerrar definitivamente a investigação.
• Rejeições: diferencie a rejeição de submit de um estado final posterior.
• Registos ausentes: abra uma exceção com chaves de pesquisa e período verificável.