Rejeições fiscais
Código 679: diagnóstico e solução por cenário
A rejeição 679 informa que o modelo de um documento referenciado não é aceito no campo ou na situação em que a referência foi enviada. Para corrigir, identifique a referência apontada na resposta e compare sua chave com o documento original. O mesmo código pode resultar de regras distintas; a solução não é trocar os…
A rejeição 679 informa que o modelo de um documento referenciado não é aceito no campo ou na situação em que a referência foi enviada. Para corrigir, identifique a referência apontada na resposta e compare sua chave com o documento original. O mesmo código pode resultar de regras distintas; a solução não é trocar os dois dígitos do modelo dentro da chave.
Este artigo trata da emissão de NF-e, modelo 55. O documento que ela referencia pode ter outro modelo, conforme o campo e a operação. Por isso, uma chave de CT-e inserida no campo destinado à NF-e exige uma análise diferente de uma referência feita com código numérico zerado ou de uma vedação específica de referenciamento.
Comece pelo campo que recebeu a chave
Confira o XML transmitido, e não apenas o nome exibido na tela. No grupo geral NFref, o MOC e a NT 2022.003 distinguem os seguintes cenários, com regras classificadas como facultativas:
Campo | Verificação que pode gerar 679 |
|---|---|
| BA02-34: modelo da chave diferente de 55, 65 ou 59. |
| BA19-34: modelo da chave diferente de 57. |
| BA02a-60: modelo da referência com código numérico zerado diferente de 55. |
Essa tabela identifica verificações de modelo. Ela não constitui autorização irrestrita para referenciar qualquer documento desses modelos em toda operação. Outras regras podem impedir a referência, inclusive conforme a finalidade e as mudanças de 2026.
O campo refNFeSig tem finalidade específica de preservação do sigilo fiscal. Não deve ser escolhido como alternativa para contornar uma rejeição em refNFe. A NT 2022.003 mantém a referência pela chave completa nos casos de devolução, complementação e quando a legislação a exigir. Existem ainda restrições próprias para o uso da referência com código numérico zerado.
Novas condições previstas para dezembro de 2026
A NT 2026.002 v1.11 acrescenta situações de rejeição 679 que dependem da operação, além do modelo. É importante observar seu cronograma: a implantação em produção das regras BA02-35 e VC02-40 foi adiada para 14/12/2026. Na consulta documental de 16/10/2026, essa data ainda é futura. A previsão anterior de 05/10/2026 não deve ser usada para essas duas regras.
Na BA02-35, quando houver refNFe, a condição alcança NF-e de saída (tpNF=1) com finalidade diferente de complementar (finNFe=2) e de devolução (finNFe=4). Nessa combinação, o documento referenciado não pode ser NFC-e modelo 65, CF-e modelo 59 ou NF-e modelo 55 emitida com DANFE Simplificado Tipo 2 (tpImp=6). O tipo de impressão mencionado nessa restrição pertence ao documento referenciado.
A VC02-40 trata da referência no item, em DFeReferenciado/chaveAcesso, e estabelece a mesma combinação de saída, finalidades e documentos vedados. Ela contém exceções expressas para notas de débito dos tipos 03, “Débitos de notas fiscais não processadas na apuração”, e 04, “Multa e juros”. Essas exceções não aparecem no texto da BA02-35; não devem ser transferidas automaticamente entre os campos.
As novas regras são obrigatórias no quadro técnico, respeitado seu cronograma. O adiamento delas não suspende as verificações anteriores do código 679. Também não adia todas as alterações da NT 2026.002. Homologação, produção e validações de outros campos devem ser conferidas separadamente.
Como investigar a referência incorreta
Guarde a mensagem completa. A indicação nOcor ajuda a localizar a ocorrência entre as referências gerais; nItem aponta o item no cenário correspondente. Consulte também a chave, o modelo da nota emitida, a finalidade, o tipo de operação e o ambiente utilizado. Não deduza que todos esses dados já foram aprovados porque a resposta trouxe apenas 679.
Recupere o XML autorizado ou outra representação confiável do documento original e compare a chave inteira com aquela enviada. Verifique se a referência pertence à operação e se foi direcionada ao campo adequado. Um seletor no cadastro pode determinar a tag gerada; a conferência deve alcançar esse resultado no XML, sem presumir que o nome da aba seja igual em todos os emissores.
Quando o problema for uma chave copiada incorretamente, recupere o identificador correto do documento real. Não altere apenas o modelo, o dígito verificador ou outro trecho para obter uma chave aparentemente compatível. Isso não transforma o documento original em outro modelo nem comprova sua existência.
Exemplo de separação entre documento e campo
Suponha que uma operação tenha um CT-e modelo 57 que deva ser referenciado, mas a integração o tenha enviado em refNFe. A comparação entre o documento e o XML evidencia o destino incorreto do dado. A equipe deve conferir a pertinência da referência e corrigir o mapeamento para o campo próprio de CT-e, quando cabível, preservando sua chave verdadeira.
Se a referência já estiver no campo correto, investigue a regra aplicável à operação e à versão. Uma NF-e modelo 55 com DANFE Simplificado Tipo 2, por exemplo, não pode ser reconhecida somente pela leitura do modelo na chave: a condição nova considera também sua identificação no documento. O exemplo não autoriza mudar o tipo de impressão de uma nota já emitida.
Corrija a origem e confirme o resultado
Ajuste o lançamento rejeitado ou a integração com base na documentação e gere novamente o XML pelo emissor. Não remova uma referência obrigatória, transforme devolução em venda normal ou altere finalidade apenas para superar a validação. Quando a operação exigir um documento cuja referência está vedada, o procedimento fiscal adequado precisa ser esclarecido com a contabilidade e a Sefaz.
Após transmitir, leia o novo retorno e confirme a autorização correspondente. Se houver dúvida sobre a situação anterior da nota, consulte-a antes de emitir outro documento para a mesma operação. Encaminhe ao suporte o XML, a resposta, o documento referenciado e a regra identificada; isso permite corrigir o problema sem atribuir previamente a falha ao autorizador ou prometer aprovação no próximo envio.
Fontes
Pesquisa em 16/10/2026. MOC 7.0 — Anexo I, páginas 11–12, 79 e 81; NT 2022.003 v1.11, páginas 4–7 e 9–11; NT 2026.002 v1.11, páginas 3, 9 e 18. A captura da NT 2022.003 foi feita em 16/10; MOC e NT 2026.002 foram recuperados em 15/10, horário de Brasília, e reutilizados por identidade.
Apoios específicos: Webmania, CIGAM e Alterdata. Seus menus, datas antigas e orientações genéricas não substituem os predicados e o cronograma das fontes oficiais.