Diferença entre cte e nf e?

Há um risco concreto: tratar toda recusa do CTe como problema de chave e reenviar sem ler a observação do retorno. Discordo, Letícia, de olhar só o portal. A saída é, pois é, guardar o número do protocolo e a referência do CTe original, porque nos casos de complemento e substituição a SEFAZ devolve a chave que já está registrada, o número do protocolo e a data. Primeiro, leia a observação; segundo, compare. O CTe, assim como a NF-e, precisa de trilha.

Será que vale para tudo? Discordo, Caio, da ideia de que o modo alternativo de emissão livra o CTe de qualquer erro. A regra diz que o CTe nesse modo fica dispensado da validação de diferença na chave, e só dela: é uma exceção, não um passe livre. Dito isso, né, quando o log do ECC 6.0 mostra erro de chave, eu olho o CTe com calma antes de culpar esse modo, e a NF-e fica fora dessa conta.

Concordo em parte com a Vanessa: essa regra é pontual, mas discordo de que o problema seja sempre de chave trocada. Às vezes o CTe informado simplesmente não chega a existir na base da SEFAZ, e a mensagem fala de CTe inexistente. E aí, a prova é olhar o número no portal antes de mexer no S/4HANA 1909. A frustração é perder uma tarde corrigindo chave que estava certa.

No meu dia a dia, pois é, o erro de chave que aparece no CTe complementar vem da validação própria do CTe, não da NF-e. Ela confere se o CTe complementado está na base com a chave certa. Se o CTe estiver em contingência, uma dessas validações de chave deixa de valer para ele. Eu comparo as duas chaves antes de reenviar, usando o GUEPARDO Tax.