Pular para o conteúdo
Como funciona este fórum

Moderado por Emanuel Kaufman. As três primeiras mensagens de cada pessoa passam por revisão e respondemos em até 1 dia útil.

Aqui se discute o comportamento do sistema. Decisão tributária é sempre da sua empresa, e ninguém neste fórum dá parecer.

Tudo o que você publicar é público e pode ser usado por terceiros, inclusive por sistemas de IA. Não publique dado de cliente, nome de empresa nem tela do produto.

Esta pergunta foi sinalizada
6 Respostas

Quando saiu o cronograma de adoção da NFS-e nacional na capital mineira, resolvi testar antes de mexer em produção. Subi o ambiente de homologação do nosso SAP, gerei um arquivo XML de teste e enviei pela API REST, em modo assíncrono. O retorno veio só com o status de recebido, sem situação final do documento. Refiz o teste com outro arquivo, um adendo, pois é, e a resposta foi igual. Esperei alguns minutos, perguntei de novo e continuou parado nesse status. Alguém já conseguiu fechar esse ciclo completo, do envio até a situação final, antes de a prefeitura ativar o fluxo?


Atualização:

Então o protocolo não basta? Obrigada, Sérgio, a explicação ajudou. Testei de novo e o status de recebido apareceu em segundos, mas a situação final ainda não voltou, um adendo, pois é. Você sabe quanto tempo costuma levar esse processamento no cronograma da NFS-e nacional? Se houver uma referência oficial, quero conferir antes de montar o teste de regressão.


Atualização:

O risco que já vi foi o status ficar parado sem virar situação final, e isso trava o cronograma inteiro. Fernando, obrigada pela pergunta, eu também testei repetidas vezes. Vou repetir depois que a prefeitura liberar o teste, um adendo, pois é, mas seria bom saber se o seu time guardou algum log dessas tentativas. Qual formato de registro você recomenda para a NFS-e nacional?


Atualização:

Interessante, mas não resolve tudo. Jéssica, obrigada, eu também tinha pensado em validar o XML antes, um adendo, pois é. O que ainda me pega é a situação final chegar depois do prazo que o cronograma da NFS-e prevê, então preciso confirmar se o seu time guarda o histórico de cada tentativa. Você teria um modelo de planilha para isso?

Avatar
Cancelar
Melhor resposta

Na minha rotina de consultoria, o cronograma da NFS-e nacional na capital mineira pede cautela antes de qualquer teste em produção. As informações fornecidas pelos emissores chegam por API REST em modo assíncrono, então o recebimento não prova que o documento foi processado. Vale tratar a leitura da situação final como etapa obrigatória, com registro do que saiu para a prefeitura e do que segue pendente. Para o horizonte próximo, a recomendação prática é montar um roteiro que só feche quando cada caso tiver retorno definitivo, e revisar essa regra quando a exploração do sistema estiver mais clara. Para aprofundar, veja documentos fiscais eletrônicos no SAP. Confirme com o tributário da empresa antes de aplicar.


Fontes oficiais consultadas

Avatar
Cancelar
Melhor resposta

Quando a prefeitura publicar os requisitos específicos do fluxo, a melhor saída, meu palpite, pois é, é separar em duas frentes. Se o time tiver janela de teste, roda o envio e a leitura da situação em paralelo. Se não tiver, prefiro tratar cada cancelamento à parte e só libero a NFS-e nacional depois que o retorno final marcar os eventos de cancelamento como executado.

Avatar
Cancelar
Melhor resposta

O resultado que importa é este: nenhum envio entra em produção sem a situação final gravada, senão o cronograma vira só protocolo. Jéssica Carvalho, o seu caminho paralelo funciona, mas eu fecharia com um controle simples. O combinado é que cada XML enviado tenha a situação conferida antes da emissão, com a data anotada no dia. Assim o time sabe quais enviados ficaram pendentes e não confunde recebimento com autorização.

Avatar
Cancelar
Melhor resposta

Helena, na minha equipe adotamos outro caminho: como o cronograma foi divulgado só em partes, montamos um teste paralelo e só homologamos quando a versão final chegar. Esse caminho, agora, que eu saiba, vale quando a janela de teste é curta e o time não pode errar na produção. Já quando a prefeitura pede retorno rápido, faz sentido validar o XML com certificado digital antes do envio e aceitar o protocolo como etapa intermediária, deixando a situação final para o acompanhamento diário.

Avatar
Cancelar
Melhor resposta

Sérgio Correia, concordo que o protocolo sozinho não prova nada, mas discordo que o teste deva esperar o fim do processamento. Na auditoria, para mim, bem, sem rodeio, o problema é a demora, porque a situação final pode levar tempo e o cronograma trava. Você falou em retorno assíncrono. Qual intervalo de consultas a sua equipe usou, e as concessionárias já responderam algo parecido? Preciso fechar o trimestre, então quero esse número antes de liberar o teste.

Avatar
Cancelar
Melhor resposta

Na minha rotina, o envio da NFS-e nacional é assíncrono, então a API devolve só o recebimento e o processamento acontece depois, com os XML já assinados. Aqui, bem, o básico é separar as etapas: envio, processamento e leitura do resultado. No cronograma de adoção da capital mineira, isso quer dizer que o teste só fecha quando o retorno final aparece, e não quando surge o protocolo de recebimento. A assinatura do XML deve estar íntegra antes do envio, senão o processamento nem começa.

Avatar
Cancelar

Sua resposta

Tente oferecer uma resposta substancial. Se quiser comentar sobre a pergunta ou resposta, basta utilizar a ferramenta de comentários. Lembre-se de que você sempre pode revisar suas respostas - Não há necessidade de responder à mesma pergunta duas vezes. Não esqueça de votar - Selecionar as melhores perguntas e respostas é realmente útil!

Perguntas relacionadas

Mais conversas em Documentos fiscais eletrônicos no SAP: NF-e, CT-e, MDF-e, NFS-e, NFTS e entrada.

Ver todas do fórum