Tratamento mais eficiente de entrada em contigência

[magnosystem]

Bom dia.

Atualmente na hora de enviar uma venda de nfc-e, eu coloco o comando dentro de um bloco try except para em caso de falha no envio eu tratar a exceção.

Então no quando ocorre a falha eu pego a mensagem de erro e verifico se na mensagem tem erro tem alguns códigos como 12002, 12007, 12057, etc.. e quando acho estes códigos na exceção meu sistema já entende que foi falha na comunicação, faz os devidos tratamentos e envia em contigência.

Todavia, ontem quando a sefaz do RS saiu do ar o retorno era o erro http: 500 que eu não tinha catalogado dentro do tratamento das exceções, o que me obrigou a fazer uma intervenção manual em cada cliente para resolver o problema.

O que eu gostaria de saber é se tem alguma forma através do acbr que eu consiga identificar o que é erro de comunicação e o que é erro de rejeição da nfc-e uma vez que a rejeição da nfc-e, como por exemplo ncm errado ou qualquer outro motivo, também gera exceção. Como os colegas tratam isso?

[Rafael Dias]

Temos um video só sobre este tema
 

 

[magnosystem]

Obrigado @Rafael Dias. Eu assisti este vídeo.

No caso o que eu gostaria de saber é se tem alguma rotina (no ontransmiterror por exemplo) no qual eu tenha certeza que o erro é de comunicação e não NFC-e reprovada pois os dois casos geram excessão na hora de enviar. Por hora, eu adicionei além dos códigos de erro de http que tinham, a expressão "Erro HTTP:' para quando aparecer na mensagem de erro o sistema já jogar em contigência também.

[Rafael Dias]

NFC-e Reprovada não retorna erro de comunicação, pois se ela foi reprovada ouve a comunicação e o webservice retornou um erro.