Rejeição 1203: confira a chave completa enviada na compra governamental

O código 1203 aponta um problema de tamanho na chave do documento anterior referenciado em uma compra governamental. A correção começa pela recuperação do documento verdadeiro e pela comparação com o XML transmitido. Completar posições com números escolhidos por tentativa pode produzir uma referência de tamanho correto e, ainda assim, fiscalmente errada.

A mensagem documentada é “Rejeição: DFe referenciado em operação com ente governamental com tamanho inválido [nOcor:nnn]”. Preserve o retorno completo para localizar a ocorrência indicada. A conferência deve alcançar cada referência informada, mesmo quando o primeiro erro encontrado já explique a rejeição.

Regra, campo e condição

A BB05-60, página 33 da NT 2025.002-RTC v1.52, aplica-se à autorização de NF-e modelo 55. Se houver chave anterior em gCompraGov/refDFeAnt, verifica cada ocorrência e prevê o 1203 quando seu tamanho for diferente de 44 caracteres.

A rejeição não mede o número do empenho, a quantidade de itens ou o tamanho do arquivo XML. Também não é uma orientação geral para NFC-e modelo 65, eventos ou outros documentos eletrônicos.

Na página 17, o leiaute define refDFeAnt como campo de caracteres, com tamanho 44 e ocorrência estrutural de 0 a 99. Isso descreve o formato; não autoriza qualquer quantidade de referências em qualquer etapa. As regras vizinhas distinguem fornecimento e recebimento de pagamento, tornando o vínculo exigido ou indevido conforme tpOperGov. Confirme a etapa real antes de corrigir ou retirar uma referência.

Compare a origem com o arquivo enviado

Separe o XML autorizado do documento anterior, o cadastro utilizado na preparação e o XML rejeitado. Compare a mesma chave nos três pontos. Registre UF, autorizador, ambiente, horário e versão do emissor para identificar a tentativa correta.

O número e a série da nota ajudam a encontrar o documento, mas não substituem a chave. Um endereço de consulta, nome de arquivo ou número de contrato também não deve ocupar esse campo. Ao conferir uma impressão, procure a referência completa e obtenha o XML com quem conserva o documento.

Há uma distinção importante no XML original: o atributo infNFe/Id contém o literal NFe antes da chave. O MOC 7.0, Anexo I, campo A03, documenta esse identificador com 47 caracteres. Copiar o atributo inteiro para refDFeAnt acrescenta três caracteres. O suporte deve extrair a chave correta para a referência, preservando o XML original e seu identificador.

Essa distinção estrutural não oferece uma fórmula para reconstruir uma chave perdida nem substitui as normas posteriores aplicáveis ao documento. A chave deve vir de uma fonte fiscal comprovada.

Corrija a causa encontrada

A cópia ou digitação perdeu uma parte. Confronte a informação com o documento original. Verifique omissão, repetição ou separadores transportados da impressão. Recupere a chave integral do XML autorizado; não deduza posições ausentes a partir de outra nota nem complete com zeros para atingir 44.

Uma importação cortou ou alterou o identificador. Investigue limites de coluna, tratamento como número, notação científica ou transformação entre sistemas. Essas são hipóteses, não causas comprovadas pelo retorno. Uma chave deve ser conservada integralmente como texto. Aumentar o campo depois da perda não recupera o conteúdo: será necessário voltar à fonte original e corrigir a origem da transformação.

A integração enviou o identificador com prefixo. Compare o valor com infNFe/Id do documento anterior. Se estiver demonstrado que foi copiado o atributo completo, corrija a extração para enviar somente a chave em refDFeAnt. Não corte três caracteres de qualquer valor de 47 posições sem demonstrar sua origem.

A tela mostra 44, mas o retorno continua sendo 1203. Leia o arquivo efetivamente enviado. Outra associação pode ter sido usada, uma ocorrência adicional pode estar incompleta ou o gerador pode conservar um valor antigo. Compare todas as referências e confirme a correspondência entre arquivo e retorno. A alteração da tela, sozinha, não comprova alteração do XML.

O documento anterior não foi localizado. Suspenda as tentativas e reconcilie contrato, entrega, recebimento e arquivo fiscal com a contabilidade. Identifique qual vínculo pertence à operação. Não use a chave de outra compra. Se a referência for indevida, sua retirada depende dessa conclusão fiscal, não da conveniência de eliminar a mensagem.

Exemplo: prefixo transferido para o campo errado

Uma empresa forneceu uniformes a uma autarquia e agora documenta o recebimento do pagamento, com etapa validada pelo responsável fiscal. A integração lê o XML anterior, mas grava em refDFeAnt o atributo Id inteiro, incluindo NFe. O arquivo da nova nota contém uma referência de 47 caracteres e retorna 1203.

A equipe compara os arquivos e demonstra a origem dos três caracteres extras. O suporte corrige a extração e gera outro XML com a chave completa, sem o prefixo naquele campo. O documento anterior permanece preservado. A operação, os valores e a etapa não são alterados para acomodar o erro de integração. O exemplo é uma hipótese de diagnóstico, não um teste de emissão executado.

Resultado, cronograma e escalonamento

No novo arquivo, a referência deve coincidir integralmente com a chave do documento correto e ter 44 caracteres. Conferir o tamanho não comprova dígito verificador, UF, modelo, existência, situação ou vínculo fiscal. As validações de chave e relacionamento continuam independentes. Leia o retorno seguinte antes de considerar o caso encerrado.

As capturas oficiais de 10/10/2026 registram a v1.52 publicada em 01/10. O histórico da página 5 inclui BB05-60 no bloco v1.40, previsto para homologação até 01/07/2026 e produção em 03/08/2026. A linha BB05-60 não apresenta indicação individual de implementação futura na prova salva.

O aviso ENCAT de 05/10 posterga as implantações citadas da v1.52 para 26/10 em homologação e 16/11 em produção. Não demonstra suspensão automática dessa regra herdada. Essas provas datadas não confirmam vigência online atual nem implantação uniforme por UF.

Após validar a correção, faça uma retransmissão controlada no ambiente apropriado. Preserve XML e protocolo quando houver autorização correspondente ao documento. Homologação e produção são ambientes separados; um teste não certifica o outro.

Procure o suporte para diferenças entre cadastro e transmissão; a contabilidade, para dúvida sobre documento ou etapa. Em divergência persistente, encaminhe os arquivos ao autorizador responsável com contexto e retorno. A condição da página 6 para validações específicas de IBS/CBS/IS não dispensa obrigações legais nem orienta omitir tributos. Esta orientação não comprova automatismos do ALRA ou garante autorização.

Fontes e limites

• NT 2025.002-RTC v1.52: BB05-60, p.33; leiaute, p.17; histórico e ressalvas, p.5–6; regras vizinhas, p.33–34. TXT e PNGs normativos já salvos foram lidos, sem nova renderização ou edição.

• MOC 7.0, Anexo I, p.8/A03, e Visão Geral, p.19: arquivos locais capturados pela SVRS em 10/10/2026. Estrutura básica histórica, sem alegação de nova abertura CONFAZ ou atualização integral do manual.

• Documentos SVRS e Avisos SVRS: capturas de 10/10, relidas localmente.

• TecnoSpeed, panorama RTC: corpo salvo como apoio adjacente; não é roteiro específico do 1203.

As confirmações atribuídas a NS7 e TaxUp na v1 não fundamentam esta v2: seus corpos não foram recuperados no escopo local pesquisado. Registros históricos inativos, datas, hashes e limites estão em fontes.v2.json. Não confirmados três roteiros práticos independentes específicos.

Elaboração documental v2 por IA; novas revisões própria e cruzada pendentes. Sem consulta online nova, geração de imagem, teste de emissão, aprovação herdada ou publicação.