Validador xml nfs e nacional

Alerta por atraso resolve mesmo, Renata? Discordo com educação, porque, bem, em geral, atraso pode ser só fila, e o que importa são os casos específicos em que o XML tem erro de esquema. Para esses, o validador de XML da NFS-e antes do envio reduz a chance de reprocessar, e só os enviados com erro de retorno devem gerar alerta. Isso é meu julgamento, e a regra oficial deve ser lida na documentação do serviço.

No fechamento de serviços, chegou nota atrasada porque o XML enviado voltou sem aviso. Um caminho a avaliar, se não me engano, é criar um alerta quando o retorno do serviço eletrônico demorar além do normal, e tratar nota por nota. Vale quando o volume é baixo; com muito volume, só relatório de exceção. Dá para usar o validador de XML da NFS-e antes, e os dados eletrônicos ficam guardados para a auditoria. Ainda é ideia, não prática confirmada.

Quando o time depende de rotina de teste própria, Rafael, o risco é ela ficar defasada, e por isso discordo um pouco. Tirando a prova, né, o validador de XML da NFS-e só ajuda se estiver na mesma versão do leiaute publicado, senão cada elemento novo passa batido. Para conferir, eu compararia os elementos obrigatórios com os documentos oficiais da NFS-e nacional, mas não afirmo regra, só sugiro. Na minha obra, o key user fiscal costuma revisar esse comparativo antes de liberar.

Valide o XML localmente e só depois envie. Um caminho a avaliar é manter uma rotina de teste que rode o validador de XML da NFS-e a cada novo leiaute. Ano passado, viu, perdi tempo mexendo no programa sem comparar com um documento de referência. As APIs são disponibilizadas pelo Serpro, então os ajustes deverão seguir o que for publicado lá. Vale quando o prazo é curto; se der tempo, faça um comparativo completo. É sugestão, não regra.

Boa ideia, Nádia. Um alerta, né: a descrição de erro vem do serviço, e o validador de XML da NFS-e só descreve o que a regra definida cobre. Então, ao montar o log, guarde a mensagem completa de retorno, porque é ela que explica a recusa. Se alguém trocar o validador ou a versão, registre a data. O GUEPARDO Tax, da NTT, pode entrar nessa trilha se o projeto usar, mas sem prometer nada.

Leandro, o ponto do retorno é bom. Um caminho a avaliar é montar uma rotina de consultas ao serviço do envio e guardar o resultado num log. Agora, um adendo: antes disso, confira o conteúdo do XML e a declaração inicial no validador de XML da NFS-e. Vale quando o volume é alto e ninguém consegue olhar nota por nota; com pouco volume, olhar manualmente basta. Isso é hipótese minha, não prática comprovada. Fico irritada quando o time sai testando sem registrar nada.

O risco que já vi foi culpar a codificação quando o problema era outro. Renato, discordo com educação: validar acento resolve só parte, e, como dizem, viu, XML consistente não garante aceite. Na comunicação com o serviço, o retorno costuma trazer o motivo da recusa, e a leitura do log do envio ajuda mais. Pelos textos que li, a NFS-e Via recebe dados das concessionárias, então o contexto pode ser diferente da NFS-e nacional comum; confirmar na documentação oficial é prudente. Meu foco é o validador de XML.

Concordo em parte, Fábio, mas discordo de olhar só a espera: a codificação dos caracteres do XML da NFS-e deve ser UTF-8, e a linha de abertura precisa estar certa. O caminho é, ó, rodar o validador de XML também nos casos de cancelamento, porque a rotina baseada em API recebe o evento de baixa da nota também. No log do envio, procure acentos quebrados antes de culpar a rede. Isso complementa seu teste; a regra completa fica na documentação oficial.

O retorno só vem depois mesmo, Moisés? Aqui no RISE, o validador de XML da NFS-e aprovou, e pelo que testei, ó, o envio através da API ficou aguardando sem resposta imediata. Isso me parece modo assíncrono, mas não consegui confirmar. Estou atendendo o fechamento e não posso deixar nota parada. Como você acompanha essa espera sem ficar consultando manualmente?

Na rotina de auditoria que acompanho, o validador de XML da NFS-e confere a forma, mas o resultado final vem da resposta assíncrona do envio real; essa é minha leitura, não afirmação da norma. Então, batendo o olho no seu caso, o passo seguinte é guardar cada retorno e ligar ao XML do envio. Se existir exigência de assinatura, confirme na documentação oficial se as notas assinadas passam pelo mesmo validador, porque isso muda o desenho do teste. Fico frustrado quando a validação local dá certo e ninguém avisa que não é a definitiva.