Traduzir erros de NFC-e para usuário final

[carlessoflu]

Bom dia!

Já encontrei alguns tópicos falando sobre isso, mas são antigos, e não tem uma resposta satisfatória. E acredito que muitos também tem essa dúvida.

Gostaria de simplificar a forma como os erros aparecem para o usuário final. Segue a tela como é mostrada para o usuário.

 

Quando o usuário vê o <dest>, ou alguma palavre em inglês, como o Element, já para de ler, porque diz que não entende. Então liga para o suporte.

Alguém tem algum exemplo, alguma rotina, para tratar esses erros?

Se aparecesse algo tipo assim: Número de endereço do cliente em branco. Favor preencher o número do endereço no cadastro do cliente.

Dessa forma o próprio cliente conseguiria resolver o problema, e não precisaria ligar para o suporte.

[Fabrício G. Araújo]

Imagino se quiser dar uma mensagem mais explicativa para o usuário, então acredito que você mesmo tenha que implementar as restrições em seu sistema antes mesmo que aconteça. Por exemplo, no seu exemplo você permitiu que fosse informado os dados do destinatário sem informar o campo número, então bastaria você colocar essa regra no seu sistema e apresentar a mensagem de restrição bem clara para o usuário e nem sequer você geraria a nota e tentaria enviar nesta situação. Estuda a documentação e veja as regras de preenchimentos, se campos são obrigatório ou que tipo de dado é permitido... e no dia a dia, caso vá identificando mais situações de restrições, então vai incrementando o seu sistema com mais validações.

Editado 10 Agosto, 2018 por Fabrício G. Araújo

[carlessoflu]

14 minutos atrás, Fabrício G. Araújo disse:

Imagino se quiser dar uma mensagem mais explicativa para o usuário, então acredito que você mesmo tenha que implementar as restrições em seu sistema antes mesmo que aconteça. Por exemplo, no seu exemplo você permitiu que fosse informado os dados do destinatário sem informar o campo número, então bastaria você colocar essa regra no seu sistema e apresentar a mensagem de restrição bem clara para o usuário e nem sequer você geraria a nota e tentaria enviar nesta situação. Estuda a documentação e veja as regras de preenchimentos, se campos são obrigatório ou que tipo de dado é permitido... e no dia a dia, caso vá identificando mais situações de restrições, então vai incrementando o seu sistema com mais validações.

É porque nem todos os clientes são para emitir notas, por isso é permitido deixar alguns campos em branco.

Mas esse caso do número foi só um exemplo, tem vários outros erros que dá que seria difícil prever e não permitir no sistema. Por isso gostaria de tratar e escrever melhor para o cliente.

[leotelles]

Em 10/08/2018 at 14:09, carlessoflu disse:

É porque nem todos os clientes são para emitir notas, por isso é permitido deixar alguns campos em branco.

Faz as validações quando for gerar as notas. Exemplo: se ao finalizar a venda o sistema for gerar uma NFC-e, não deixa finalizar se os dados necessários não estiverem preenchidos. Aqui procuramos fazer as validações sempre antes, quando o usuário está fazendo operações que vão gerar dados importantes para a nota, para evitar erros de schema e rejeições.

[thiagosantanna10]

Oi, boa tarde, e se por acaso você capturar o número do erro? Sendo assim você pode tratar e além de mostrar esse retorno original mostraria acima dele uma mensagem mais amigável.

[carlessoflu]

28 minutos atrás, thiagosantanna10 disse:

Oi, boa tarde, e se por acaso você capturar o número do erro? Sendo assim você pode tratar e além de mostrar esse retorno original mostraria acima dele uma mensagem mais amigável.

Não chega a mostrar o número do erro. É erro de schemas eu acho, antes de receber o retorno da SEFAZ.