Nf-e alterada para assinado . motivo nf-e não consta na base de dados da sefaz

Rogério, eu acrescento um ponto. De bate-pronto, ó, o capítulo de cancelamento que a gente usa fala de prazo, e o prazo define se a consulta resolve ou não. Em produtos como carpetes, o cliente costuma mudar o pedido depois da entrega, e isso cria a pendência. Nenhuma cláusula de contrato resolve isso sem o registro na Sefaz. Vale checar a data de emissão antes de decidir qualquer coisa.

Ivone, como bem lembrou, pois é, o retorno bruto diz mais do que a tela. Na nossa equipe a saída foi outra: quando o status fica preso, a gente não reemite, consulta a nota pelo número e segue o protocolo que a Sefaz devolve. Isso vale quando a nota é de venda de item automotivo ou de borracha, porque o volume é menor e o histórico é limpo. Quando o emitente tem muitas notas no mesmo dia, a consulta em lote custa mais tempo, e aí vale esperar a fila de processamento. A escolha depende do caso.

O risco que eu já vi é o cliente cancelar a nota antes da Sefaz processar o evento, e aí o XML fica sem par. Mariana, você falou do print, e concordo: olha, a questão é que a apresentação da situação no GUEPARDO Tax pode esconder o retorno real. Eu conferiria o arquivo de retorno bruto, e não só a tela. Os artefatos de integração, como o log do serviço, mostram se a chave foi enviada duas vezes. Antes de reemitir, peça para o time comparar a chave, a data e o número do protocolo.

Concordo em parte com você: o XML precisa mesmo ser conferido, mas o caminho certo é consultar a situação da nota na Sefaz antes de mexer em qualquer coisa. Olha, na minha área isso já deu problema quando alguém reemitiu sem checar a chave, e o valor saiu duplicado. Discordo de cancelar e refazer sem antes ler o print do retorno, porque o motivo costuma estar ali. Os aparelhos de teste ajudam, mas a Sefaz de homologação não é a mesma coisa. Se a chave consta na consulta, o problema é o cadastro, e não a nota. Vale checar o cadastro apartado do emitente antes de qualquer decisão.