Voltar para base de conhecimento

Rejeição 227 do CT-e: Erro na composição do Campo ID

Atualizado há cerca de 14 horas0 visualizações0 acharam útil
CTeRejeição-227Chave de AcessoXMLSEFAZ

A chave de acesso gravada no XML não confere com os dados do próprio conhecimento. É erro de geração do arquivo, não de preenchimento.

A Rejeição 227 acontece quando a chave de acesso gravada no XML não corresponde aos dados do próprio conhecimento. A SEFAZ refaz a conta com os campos que recebeu, compara com a chave informada e recusa quando dá diferente.

Esta é uma rejeição de geração do arquivo, não de preenchimento. Não há campo na tela que a pessoa tenha errado.

O que a SEFAZ responde: "Erro na composição do Campo ID"

Abrir CT-e

Por que acontece a Rejeição 227

A chave de acesso do CT-e tem 44 dígitos e não é um número sorteado: ela é montada a partir dos próprios dados do conhecimento, nesta ordem — código da UF, ano e mês de emissão, CNPJ do emitente, modelo, série, número, tipo de emissão, código numérico aleatório e um dígito verificador.

O campo ID do XML carrega essa chave precedida do literal CTe. A validação faz duas conferências:

  • Falta o literal. O campo tem que começar com CTe seguido dos 44 dígitos.
  • A chave não bate com a concatenação. Algum campo do conhecimento mudou depois de a chave ter sido gerada, ou o dígito verificador foi calculado errado.

Na prática, a causa é sempre uma dessas duas famílias:

  • O documento foi alterado depois de a chave existir. Trocar a série, o número, a data de emissão ou o CNPJ do emitente muda a chave. Se ela não for recalculada, a conta não fecha.
  • Defeito no sistema emissor. Cálculo do dígito verificador, montagem do literal ou tratamento do código numérico aleatório.

No Berga

DFe › CTe, na própria listagem do conhecimento.

Deixa que o Berga resolve. A chave é calculada pelo sistema no momento do envio, a partir dos dados do conhecimento — não é campo digitado, e não fica guardada de uma tentativa para a outra. Cada nova transmissão gera número e chave coerentes entre si. Conheça o Berga — a emissão de CT-e já vem pronta.

Como resolver a Rejeição 227

  1. 1
    Tente transmitir o CT-e novamente. A chave é refeita no envio, e se o problema veio de uma alteração feita depois da primeira tentativa, o reenvio já resolve.
  2. 2
    Se a rejeição repetir, confira os dados que entram na chave: CNPJ do emitente, série, número e data de emissão. Um deles alterado manualmente entre tentativas é a causa mais comum.
  3. 3
    Persistindo, abra um chamado. Chave que não fecha depois do reenvio indica defeito na geração do arquivo, e isso se resolve no sistema, não no cadastro.

O CT-e recusado por validação não consome numeração — a sequência é reaproveitada.

Como evitar a Rejeição 227

Não altere série, número ou data de emissão de um conhecimento que já teve uma tentativa de envio. Se precisar mudar algum desses dados, o caminho seguro é emitir um novo documento em vez de editar o que já foi transmitido.

Quando a emissão vem de integração própria, garanta que a chave seja recalculada a cada montagem do XML, e não reaproveitada de um envio anterior.

Se a Rejeição 227 continuar

Se o reenvio não resolve, o problema não está no seu cadastro. Ao abrir o chamado, informe o número e a série do CT-e, a data de emissão e o CNPJ do emitente — com esses quatro dados é possível refazer a chave e comparar com a que foi enviada.

Se você emite por integração, anexe o XML rejeitado: o campo ID mostra na hora se falta o literal ou se o dígito verificador está errado.

Consulte a tabela de rejeições do CT-e para procurar outro código.

Referência: MOC CT-e 4.00 — Anexo I, regras de validação G014, H011 e I11.

Este artigo foi útil?