Rejeição 709: formato de DANFE incompatível com a NFC-e

A Rejeição 709, regra B21-10, verifica NFC-e 65 cujo tipo de impressão tpImp é diferente de 4 e 5. O valor 4 identifica DANFE NFC-e; 5 identifica DANFE NFC-e em mensagem eletrônica. A validação é obrigatória. Ela examina o indicador do XML, não a aparência de um PDF que o usuário abriu depois. MOC 7.0, Anexo I, p. 76-77.

Onde o formato está definido?

Localize infNFe/ide/tpImp no XML enviado e confirme mod=65. O campo pertence ao leiaute comum, que também inclui formatos de NF-e. O fato de um valor ser aceito pelo XSD não o torna compatível com todos os modelos.

tpImp=4 é o formato de DANFE NFC-e. O MOC explica que mensagem eletrônica pode coexistir com impressão e que 5 deve ser usado quando essa for a única forma de disponibilização do DANFE. Isso não equivale a declarar que qualquer envio de e-mail exige 5: é preciso conferir como o documento auxiliar foi efetivamente disponibilizado. MOC 7.0, Anexo I, p. 9.

DANFE Simplificado Tipo 2 serve como DANFE da NFC-e?

O valor 6 identifica o DANFE Simplificado Tipo 2 da NF-e 55, nas condições próprias do leiaute atual. Não é uma alternativa adicional para a NFC-e 65 na B21-10. A NT 2026.002 inclui o valor 6 e mantém 4/5 com os significados de NFC-e. NT 2026.002 v1.11, p. 3, 7 e 8.

O modelo continua sendo determinado por mod. Um formato compacto, uma impressão térmica ou um QRCode não transformam NF-e em NFC-e. A 710 trata o sentido inverso: NF-e 55 marcada com formatos 4 ou 5, que pertencem à NFC-e.

Exemplos de configuração visual e XML

Exemplo sintético: a aplicação imprime um comprovante com aparência de NFC-e, mas o XML 65 contém tpImp=1, DANFE normal retrato. A aparência da impressão não corrige a incompatibilidade do indicador. Compare o template efetivamente usado, a configuração e o serializador para localizar a divergência.

Em outro exemplo, uma atualização adiciona tpImp=6 e passa a aplicá-lo a todas as impressões compactas. Para mod=65, a condição da 709 continua presente. A correção é revisar a seleção do formato conforme o modelo e a disponibilização real, sem trocar mod para manter a configuração errada.

Como validar a correção?

Confirme modelo, indicador e forma real de disponibilização do documento auxiliar. Corrija a origem comprovadamente incorreta da configuração e confira o XML final, além da renderização correspondente. Não basta alterar o PDF depois que a SEFAZ recebeu o XML.

Consulte o estado da tentativa anterior se houve retorno incerto e preserve XMLs já autorizados. Uma nota aprovada em XSD pode continuar rejeitada em B21-10; ausência da 709 também não comprova autorização. O retorno individual fiscal deve ser conferido após qualquer ação cabível.

Os exemplos são cenários sintéticos de diagnóstico. Os valores são apresentados em texto para comparação; não constituem um XML fiscal pronto para transmitir. A conferência operacional exige o XML original e o retorno da mesma tentativa.