Nfs e padrão nacional se torna obrigatória

Quando o município já tiver aderido ao padrão nacional, eu discordo de tratar a conferência como ponto secundário. E aí, em linhas gerais, o que trava a nota é o conteúdo, não a embalagem gzipbase. Acho que os fundamentais são a identidade do emitente e a regra de cada campo, que a validação pega logo. Garantir isso antes do envio economiza uma rodada de correção. Com respeito ao Rafael, a pergunta sobre a lista é boa, mas o foco certo é o dado.

Boa dúvida, Gisele. Vamos lá, né, e o ponto novo é este: o documento que sai da sua casa precisa ser igual ao que foi enviado para o município, senão o protocolo não casa com a NFS-e de padrão nacional. Guarde o XML com o horário de envio, porque isso é essencial quando a fiscalização pedir a conferência. Dá para montar uma rotina simples de conferência sem mudar o fluxo inteiro.

O resultado que importa, Raquel: a conferência do padrão nacional depende do formato que o município aceita, e não só do que você acha certo. Bem, na homologação, você consegue testar isso antes; é aí que existem as exigências de cada campo. Pode me passar o caminho que você usou para achar a lista de exigências? Preciso saber se ela vale para o seu município ou se é geral.

Roberta, veja, pra constar: você falou em conferir os campos antes do envio, mas um descumprimento de regra já trava a nota na rede nacional? Quero entender se a validação acontece diretamente no envio ou só depois. No meu caso, as orientações disponibilizadas pelo município falam de uma coisa e o sistema mostra outra.

O risco que eu já vi é o cadastro de municípios ficar com dados inconsistentes entre o que a nota diz e o que o órgão espera. Então, meu ponto, Ana: antes de mandar qualquer coisa, vale consultar a lista de validação de cada campo e conferir se os valores são consistentes com o cadastro da prestação. Assim o protocolo chega com a nota correta, e você não perde tempo com recusa. Fazer essa conferência cedo evita que o padrão nacional vire um gargalo.

Quer dizer que o problema não é só o XML? Bom, a saída é, tá, separar regra de cadastro de regra de transporte. A comunicação com a rede nacional depende de certificado e de janela de manutenção, e nada disso aparece no XML que você conferiu. Complementar o que o Vinícius disse: se uma concessionária parceira envia por outro canal, confirme se a janela dela bate com a nossa.

Na minha rotina, um cliente sempre pergunta do bloqueio quando a nota volta com erro. Veja, vale registrar: a questão do cancelamento segue o mesmo caminho? João, no caso de um município que ainda não aderiu, o cancelamento de uma NFS-e de padrão nacional é feito pelo sistema antigo ou pelo novo?

Se o município ainda estiver sem adesão ao padrão nacional, a gente costuma, ó, tratar o assunto como rotina, e eu discordo: atualmente o risco maior está na autenticação do certificado, não no XML. Com respeito ao João, validar o XML não basta, porque a conexão baseada em API tem regras próprias. Eu separaria o teste de conexão do teste de conteúdo e só depois mexeria no fluxo.

O resultado que importa: não troque a emissão atual antes de validar a nota de teste. Após o envio, a API devolve um protocolo de recebimento, e é com ele que você acompanha o resultado da validação. Gerar o XML em arquivo local, no padrão de envio, deixa você revisar se os campos estão atendendo às regras antes de mandar para a rede nacional. Faça isso com um arquivo por vez e compare o retorno com a emissão que já existe. E olha que, pois é, a NFS-e de padrão nacional exige esse cuidado no começo.