Sap edocument application log

Quando o log mostra falha de retorno, o Rodrigo tem razão de olhar o identificador primeiro. Agora, sem querer complicar, acrescento que o status de processamento longo nem sempre é erro: em alguns cenários o serviço de envio está lento e o documento só vira erro no ciclo seguinte. Por isso eu anotaria o horário de cada tentativa antes de reprocessar. Assim você não reenvia um documento que já foi aceito e evita duplicidade no fechamento.

Na nossa rotina de alimentos, o caso concreto foi um lote de notas que travou num domingo. Veja, em campo, o que funcionou foi separar o log por tipo de documento e criar uma lista de erros que se repetem. Assim a gente não reprocessa tudo, só o que tem o mesmo código. A limitação é que a lista precisa de manutenção, e quem está de plantão nem sempre conhece o código. Por isso a regra é simples: o que não está na lista vai para o analista, não para reenvio automático.

Nós resolvemos por outro caminho: monitoramos a fila de envio com um relatório diário e só abrimos chamado quando o status passa de um dia. Então, quer dizer, a equipe não mexe no log até confirmar a falha. Funciona bem quando o volume é estável e o time tem uma pessoa dedicada a acompanhar. Não vale quando há muitos documentos por hora, porque o atraso vira problema antes do relatório aparecer. Nessa situação, eu prefiro um alerta por sistema, mesmo que gere mais ruído.

Leonardo, a resposta é por camada. A mensagem genérica quer dizer que o documento ainda não saiu da geração. Primeiro filtre pelo objeto e pelo número do documento, e depois abra cada entrada de erro, não só a última. Olha, abrindo um parêntese, o detalhe que mais ajuda é o identificador de processo, porque ele separa falha de geração de falha de retorno do serviço. Quando ele aparece, procure a mensagem de conversão de dados, porque quase sempre o problema é campo vazio ou fora do padrão.