Rejeição 897: corrija a geração do código numérico da chave de acesso

Se a emissão retornar “Rejeição: Código numérico em formato inválido”, confira o campo cNF do XML enviado. Esse código técnico compõe a chave de acesso da nota e precisa atender às restrições documentadas. O problema pode estar no gerador do emissor ou numa integração que reutilizou um valor inadequado.

Guarde o arquivo e a resposta completa antes de tentar corrigir. Como o cNF participa da identificação do documento, editar somente esse campo pode deixar chave, dígito verificador e assinatura incompatíveis.

O modelo e a versão importam

Na NT 2019.001 v1.70 consultada, o código 897 está associado à regra B03-10, página 15, no serviço de autorização. O histórico da página 5 registra expressamente que a versão 1.40 retirou o modelo 65 dessa validação. Esta orientação fica delimitada à NF-e, modelo 55, segundo essa alteração documental.

Na página 15 do PDF, o modelo 65 aparece riscado; extrações de texto e planejamento podem conservar “55/65” sem mostrar essa exclusão. A inspeção gráfica e o histórico de alterações precisam ser considerados juntos. Se o registro analisado for de NFC-e, modelo 65, identifique serviço, mensagem, versão e origem da validação antes de aplicar uma solução do 897. Não presuma que todos os documentos compartilhem a mesma regra porque o nome do campo é igual.

A pesquisa documental foi atualizada em 16/10/2026. A linha está classificada como obrigatória; isso não substitui a conferência da versão, do autorizador e do ambiente do retorno concreto. Não houve emissão de teste ou comprovação de execução individual.

O que é o cNF

O MOC descreve cNF como um código numérico de oito posições, gerado pelo emitente. Ele é um dos componentes da chave de acesso. O número fiscal da nota fica em outro campo, nNF, e o dígito verificador da chave fica em cDV.

Essas informações precisam ser coerentes entre si. O MOC, Visão Geral, apresenta a composição da chave e o cálculo do dígito verificador. O identificador do XML também utiliza a chave. A mudança do CNPJ para formato alfanumérico não transforma o próprio cNF em campo alfanumérico: o schema consultado mantém oito algarismos. Portanto, uma correção deve passar pelo procedimento do emissor, que recompõe os dados técnicos e assina o conteúdo atualizado.

O operador não deve escolher um código fixo para usar em todas as notas. A documentação prevê geração aleatória; a solução adequada é corrigir a rotina que produziu o valor inadequado, preservando os fatos da operação.

Quais valores a regra proíbe

A B03-10 traz uma lista específica. São vedados os códigos com oito algarismos iguais: 00000000, 11111111, 22222222, 33333333, 44444444, 55555555, 66666666, 77777777, 88888888 e 99999999.

Também estão listados 12345678, 23456789, 34567890, 45678901, 56789012, 67890123, 78901234, 89012345, 90123456 e 01234567. Além dessa lista, o documento estabelece que o cNF não pode ser igual ao nNF.

Não amplie a regra para declarar inválida toda combinação que pareça conter uma sequência. A conferência deve usar as condições documentadas e o valor efetivamente enviado. Também não escolha manualmente uma combinação fora da lista apenas para repetir a transmissão: a origem do preenchimento precisa ser corrigida.

Prepare o diagnóstico

Reúna XML, resposta, chave, emitente, modelo, série, número, ambiente, UF/autorizador e horário da tentativa. Peça ao suporte que compare:

• ide/cNF, código numérico transmitido;

• ide/nNF, número fiscal da nota;

• ide/cDV, dígito verificador;

• chave usada no identificador do XML e na transmissão;

• origem do valor: emissor, integração, importação ou configuração.

Uma tela pode mostrar um código atualizado enquanto a nota já preparada conserva outro. Se houve falha de comunicação em tentativas anteriores, esclareça primeiro o resultado fiscal. Não recomponha a identificação de um documento que possa já estar autorizado sem verificar essa situação.

Como tratar as causas

O sistema preencheu um valor fixo ou um padrão proibido

Uma configuração de teste pode ter sido levada para o uso normal, ou uma integração pode preencher sempre o mesmo valor. Compare o código do XML com a lista da B03-10 e procure a rotina responsável por sua geração.

Peça ao fornecedor que corrija essa rotina e trate a nota rejeitada pelo fluxo apropriado. Não substitua o problema por outro valor fixo considerado aparentemente aceitável. A geração prevista no leiaute deve funcionar nas próximas emissões também.

O código foi copiado do número da nota

Uma integração pode ter usado nNF para preencher cNF. Confira o mapeamento dos campos, sem interpretar a coincidência como uma orientação para trocar o número fiscal.

A correção deve separar a geração do código técnico do controle de série e numeração. Não altere o nNF, a série ou a data real da operação apenas para afastar a igualdade. Preserve o histórico do documento e peça a reconstituição coerente pelo emissor.

A importação modificou o conteúdo do campo

Verifique se o processo converteu indevidamente o valor, perdeu posições ou substituiu informações durante a montagem do XML. Problemas de estrutura podem gerar outras rejeições, por isso não atribua qualquer falha de tamanho automaticamente ao 897.

Compare o arquivo preparado, o arquivo transmitido e a resposta correspondente. Corrija a transformação comprovadamente errada. Não ajuste apenas o texto visível da chave, nem apague zeros sem conferir o leiaute e a geração completa.

O gerador foi corrigido, mas a tentativa utiliza o XML antigo

Uma atualização do sistema pode não modificar documentos já preparados. Confirme qual arquivo foi reenviado e se a integração selecionou a versão atualizada da nota rejeitada.

O suporte deve reprocessar o documento pelo procedimento previsto, recalculando a identificação e a assinatura quando o conteúdo mudar. Nunca edite manualmente o XML assinado nem reaproveite um protocolo de outra chave.

Exemplo hipotético

Uma loja de ferramentas prepara uma NF-e número 764, série 2. A integração envia cNF=44444444, herdado de uma configuração de teste. A resposta apresenta a mensagem 897. Esse valor consta entre os padrões proibidos da regra consultada.

A equipe identifica o preenchimento fixo e confirma que o documento da operação ainda precisa ser autorizado. Se essa situação estiver comprovada, o fornecedor corrige a geração e reprocessa a nota rejeitada com identificação técnica coerente. O exemplo não oferece um código substituto pronto nem autoriza trocar a numeração para conseguir passagem.

Verifique o resultado e preserve o histórico

Faça uma transmissão controlada pelo emissor após a correção comprovada. Examine a resposta inteira. Se houver autorização, confira chave, protocolo e conteúdo do XML autorizado. Outra rejeição precisa de diagnóstico próprio.

Se a consulta revelar autorização anterior, preserve o documento autorizado e encaminhe ao suporte a divergência interna, em vez de criar outra identificação para a mesma operação. Procure o responsável fiscal quando houver dúvida sobre documentos duplicados ou regularização da emissão.

Cronograma e limites

O histórico da NT registra a retirada do modelo 65 na versão 1.40 e a prorrogação das alterações dessa versão, na 1.50, para produção em 10/08/2020. Esses são registros históricos, não um prazo novo para o empresário.

A consulta documental atual não incluiu emissão fiscal no ALRA. Cancelar registros internos, inutilizar números e cancelar documentos autorizados são procedimentos distintos; este retorno isolado não determina que algum deles seja necessário. Preserve o histórico e esclareça o estado da emissão antes de regularizar a operação.

Fontes e limites da pesquisa

• NT2019.001v1.70: reusoHTTP20016/10 da pesquisa936,PDF8c03e1d5. Páginas5/8/15 textuais inteiras lidas nesta897; PNGs preexistentes5/15 pessoalmente vistas agora. Modelo65 riscado na B03-10/897, modelo55 permanece Obrig; históricov1.40 exclui65,v1.50P10/08/2020. Lista20valores e igualdadecNF/nNF conferidas, sem ampliar para qualquer sequência percebida.

• MOC7AnexoI: reusoHTTP20015/10/2026 da942,PDF5eb4cf20,captura real preservada. Páginas8/75 textuais inteiras lidas; cNF8aleatório eIdchave. Coluna55/65 textual não se sobrepõe à exclusão gráfica daNT. SemPNG75 alegada.

• MOC7VisãoGeral: reusoHTTP20015/10 da910,f664dcf9. Páginas18/19/20 textuais inteiras lidas, composição/chavenatural/DV e geraçãoaleatória; descrição histórica44numéricos não universalizada frenteCNPJalfanumérico. Não implementa nem testa algoritmoDV/XMLreal.

• NT2026.004v1.01: reusoHTTP20016/10 da910,5f24a253; páginas5/6 inteiras lidas nesta897 e3/4/13 efetivamente lidas em910 nesta rodada. AlteraçõesCNPJ/chaves não justificam letras nocNF. Schemasoficiais: leiaute010f2bace capturado15/10, declaraçõesreaiscNF/nNF/cDV inteiraslidas; cNFpattern[0-9]{8},cDV[0-9]{1}. SemXSDcompilado.

• Oobj897: novaHTTP20016/10 2a02de13 eWEB16–96corpoespecíficointeiro lido,28/08/2019. Tabela tem987porerro,contexto897; receita no máximo8dígitos incorreta dianteoitoexatosXSD. Não adotados troca manual isolada,exemplos de identificadores ouXMLfragmentário como soluçãoALRA.

• TOTVSWinthor897: WEB54–71corpoespecíficointeiro lido,06/04/2021;direto40316/10 separado. Rotinas1452/132/1409 eparâmetro4033/própriaversão29pertencemWinthor. Cancelamento referido não é ordem de evento fiscal nem fluxoALRA.

• Bling897: WEB26–72corpoespecíficointeiro lido,10/08/2026;direto40316/10 separado. Clonar pedido/excluir nota/inutilizar número são instruções daqueleproduto, não exigência universal daB03-10 ou funcionalidadeALRA; nãoexecutadasnemrecomendadasautomaticamente.

Três corpos específicos de publicadores distintos realmente lidos, sem confundir menu/índice com tutorial. Varredura delimitada seis cachesNT2026 por897/B03-10/cNF sem ocorrências,resultadointeiro lido,nãoexhaustiva. Primárias e PNGs atuais àpesquisa suprem faltadocumental anterior; testes individuais continuam não realizados. Originalepróprianegativa preservados semretroaprovação. Sem novas imagens criativas/capas/publicação.