Sap drc peppol exchange

Nós implementamos um monitoramento cruzado entre o envio inicial e o recebimento da confirmação do parceiro. Este método se mostrou crucial quando o meio de comunicação externo apresentava instabilidade intermitente. O controle paralelo assegurava que, mesmo com lentidão na resposta da rede, pudéssemos mapear a recepção correta por parte do destinatário, distinguindo falhas de trâmite de recusa material.

O resultado que importa é saber se o retorno chega sozinho, Simone. Pelo que você descreveu, o identificador resolve, mas o prazo é, pois é, curto demais no nosso ambiente de telecom e a fila trava antes. Eu sou controller, então me preocupa quem olha o relatório no fechamento. Você já viu o status ficar pendente por mais de um ciclo? Como vocês trataram isso?

Se o identificador for gerado pelo próprio DRC, Matheus, o casamento fica mais simples, e um ponto importante, pois é, é separar a fila de retorno da fila de envio. Em energia, a gente deixou o reenvio automático só para falha técnica, nunca para rejeição de conteúdo. Isso evita duplicidade. Vale testar essa separação antes de liberar o exchange para o parceiro.

Alan, valide o retorno pelo status da mensagem na própria troca Peppol, e não pela tela do documento. Ainda assim, bem, a dúvida é se esse status chega de volta ao sistema de origem, e isso precisa ser checado em log, não em suposição. Como consultora de MM, vejo isso muito em siderurgia, onde o parceiro responde depois do processo. Recomendo registrar cada envio com um identificador único e casar o retorno com ele. Assim a fila deixa de ser mistério e o time sabe exatamente qual mensagem ficou presa no DRC.