Rejeição 754: histórico do transportador na NFC-e — X03-10 desabilitada

A Rejeição 754 verificava NFC-e, modelo 65, com transportador fora da indicação de entrega a domicílio. A X03-10 combinava a presença de transp/transporta com ide/indPres diferente de 4, mas foi desabilitada pela NT 2023.004. Esta explicação serve para interpretar arquivos antigos e investigar uma mensagem atual sem restabelecer a exigência retirada.

A comparação que distingue os cenários

O MOC 7.0, Anexo I, p. 124 apresenta a condição antiga de X03-10 como obrigatória para modelo 65:

O grupo transp não é sinônimo de transporta: ele reúne informações de transporte, enquanto transporta identifica o transportador. A modalidade de frete em transp/modFrete e os grupos de veículo, reboque ou retenção do ICMS têm funções próprias e outras validações. Alterar modalidade de frete, por si só, não muda a combinação examinada em X03-10.

Qual fonte desabilitou a regra

A NT 2023.004 v1.20, seção 2.3.2, p. 5 declara expressamente a desabilitação de X03-10 e X03-20. Na p. 14, ambas aparecem rasuradas. A tabela antiga do MOC precisa ser lida com essa atualização posterior.

O histórico da NT, p. 3, separa a atualização do schema da versão 1.11, produção em 06/05/2024, das alterações da versão, produção em 01/07/2024 e testes até 25/03/2024. A versão 1.20 modifica o limite de troco e não reativa X03-10. Esse calendário documental não comprova isoladamente a configuração de um autorizador específico. A desabilitação não apaga dados históricos nem autoriza incluir ou retirar informações verdadeiras; retira essa comparação específica como fundamento da rejeição.

De onde podia vir a divergência técnica

A presença do transportador pode ser montada por uma configuração compartilhada com NF-e ou por uma cópia dos dados de uma venda anterior. Já indPres pode vir da classificação da operação feita pelo emissor. Essas são hipóteses: compare o XML efetivamente gerado com a operação documentada antes de atribuir culpa ao cadastro.

Não há cálculo de frete ou de imposto nesta rejeição. O problema é a compatibilidade entre um grupo e um indicador. Preencher os valores com zero não elimina a presença do grupo e não substitui a decisão sobre o que deve ser representado.

Exemplo histórico: balcão com transportador herdado

Uma venda histórica documentada como presencial no estabelecimento gerou NFC-e com indPres=1. O gerador incluiu transporta copiado de outra operação. A combinação explicava a crítica antiga de X03-10. A comparação entre venda, mapeamento e XML permite localizar a herança indevida sem editar arquivo autorizado ou falsear o indicador. Em tentativa atual, a mesma crítica pode vir de validador local que conserva X03-10 desabilitada; confirmar a versão é necessário antes de alterar transporte.

Não se deve trocar indPres para 4 só porque existe um transportador no XML. Se a operação foi de fato uma entrega a domicílio, é preciso confirmar essa classificação e conferir o conjunto correspondente — incluindo identificação e endereço do destinatário — em vez de usar o indicador como recurso para afastar uma rejeição.

O cenário é textual porque a origem indevida do grupo só pode ser demonstrada com a venda e o arquivo real. Não há XML de transmissão; um fragmento isolado não provaria a natureza da operação nem sua autorização.

Como investigar uma mensagem atual

Preserve envio, resposta integral, ambiente, horário e versão do emissor. Confira modelo, indPres e transporta no mesmo documento e separe crítica local, retorno histórico reapresentado e resposta atual da SEFAZ. Se o serviço atual conservar a verificação desabilitada, encaminhe as pp. 5 e 14 da NT para esclarecer a versão aplicada. Corrija apenas o mapeamento comprovadamente errado e preserve os dados verdadeiros.

Não elimine dados verdadeiros, não altere o modelo fiscal para contornar a crítica e não edite XML assinado. A ausência de 754 não comprova autorização nem regularidade de toda a operação. Se houver tentativa de transmissão incerta, esclareça seu resultado antes de novo envio.