Rejeição 1099: retire o cIndOp indevido da NFC-e

Se a venda foi emitida como NFC-e e recebeu a rejeição 1099, confira o arquivo enviado antes de alterar o cadastro do cliente. O problema descrito neste artigo é a presença de um campo que não pode ser usado no modelo 65: o código indicador do local da operação de fornecimento, chamado cIndOp. A correção passa pela geração correta do documento e pela confirmação de que a NFC-e é adequada à operação real.

Não troque o número do indicador por tentativa. Nesta regra, qualquer informação desse campo na NFC-e é incompatível. Também não transforme a venda em NF-e apenas para eliminar a mensagem: a escolha do documento exige avaliar a operação e as regras aplicáveis.

Mensagem e contexto da validação

A mensagem oficial é “Rejeição: Não é permitido o uso do código indicador do local da operação de fornecimento na NFC-e modelo 65”. Na NT 2025.002-RTC v1.52, página 32, a regra B25d-10 identifica expressamente o modelo 65 e verifica a presença da tag cIndOp. O serviço é a autorização da NFC-e; este diagnóstico não trata de eventos, distribuição de XML ou consulta por QR Code.

A NF-e modelo 55 tem regras diferentes. Nesse modelo, a B25d-20 verifica a permissão do código na tabela e pode gerar 1102; a B25d-30 pode exigir local de retirada e gerar 1110. Não transfira essas soluções para a NFC-e. O campo técnico deste artigo é cIndOp, de seis dígitos, no grupo de identificação; ele não se confunde com indPres, que descreve a presença do comprador.

A documentação não restringe a B25d-10 a uma UF específica. Ainda assim, preserve a identificação do autorizador, a UF, o ambiente e a data do retorno. A presença da regra nacional não comprova, por si só, a implantação individual em todos os serviços estaduais.

Por que o campo foi incluído

Uma causa possível é compartilhar a mesma configuração entre NF-e e NFC-e sem filtrar os campos permitidos para cada modelo. Outra é uma integração passar todos os dados de um pedido ao emissor, mesmo quando parte deles pertence a outro documento. Há também notas preparadas antes da correção do cadastro que conservam o valor antigo.

Essas são hipóteses para investigação, não conclusões sobre um sistema específico. A tela pode estar vazia enquanto o XML ainda contém a tag. No sentido contrário, o nome exibido na tela pode não corresponder exatamente ao nome técnico transmitido. O suporte precisa comparar os dois registros.

O leiaute da página 16 prevê cIndOp em hipóteses específicas, incluindo leilão judicial ou licitação promovida pelo poder público, com 010104, e constatação de irregularidade documental, com 010105. Essas descrições não tornam o campo permitido em uma NFC-e. Tampouco permitem classificar uma venda comum como irregularidade para justificar seu uso.

O que guardar e conferir

Guarde o XML que foi efetivamente transmitido, o retorno completo da SEFAZ e o horário. Registre modelo, série, número, ambiente, UF e versão do emissor. Verifique se o retorno é de produção ou de homologação: um teste aprovado não comprova o resultado da venda em produção.

Peça que sejam conferidos ide/mod e ide/cIndOp no arquivo. Depois identifique a origem do indicador: cadastro da operação, pedido, configuração fiscal, integração ou montagem automática do XML. Não procure o erro exclusivamente no endereço do cliente. A B25d-10 não compara municípios nem exige preencher outro endereço.

Antes de retransmitir, confirme também a situação da tentativa anterior pelo fluxo apropriado do emissor. Uma tela de erro incompleta não deve levar à criação automática de outra nota para a mesma venda.

Como corrigir conforme a causa

A operação cabe em NFC-e e o campo entrou indevidamente

O responsável técnico deve corrigir a configuração ou o gerador para que cIndOp não seja incluído no modelo 65. Reprocesse a nota rejeitada no próprio emissor e confira o XML novo. O resultado esperado desta correção é a ausência da tag, não sua troca por zero, por um código genérico ou por um elemento vazio.

Se o conteúdo mudar, gere e assine novamente pelo processo normal do sistema. Apagar a tag diretamente de um arquivo já assinado pode comprometer a assinatura e não corrige a origem do defeito.

O pedido exige avaliar outro documento

Quando a operação real não se enquadra no uso da NFC-e, encaminhe a decisão ao responsável fiscal. Ele deve definir o documento cabível e seu preenchimento completo. Alterar apenas mod de 65 para 55 em um XML pronto não é um procedimento válido: modelo, chave, identificação e demais condições precisam ser gerados coerentemente.

A configuração foi corrigida, mas a rejeição continua

Compare o arquivo novo com o anterior. Se cIndOp permanece, a nota pode estar usando dados salvos ou outro caminho de integração. Se a tag não aparece no arquivo correto e o retorno persiste, confirme que a resposta pertence àquela transmissão e encaminhe os registros ao suporte. Evite repetição automática sem evidência nova.

Exemplo original

Uma loja fictícia atualiza a integração de pedidos. A configuração usada para documentos modelo 55 passa a enviar cIndOp também nas vendas de balcão modelo 65. Uma NFC-e de R$ 173 recebe 1099. O suporte encontra a tag no XML, embora o operador não tenha preenchido indicador na tela.

Depois de confirmar que aquela venda cabe em NFC-e, a equipe corrige o filtro por modelo, reprocessa o documento e confere a ausência do campo. Mantém produtos, valores e cliente conforme a venda verdadeira. O encerramento depende do novo retorno oficial; a correção do filtro não garante que nenhuma outra validação encontrará problema.

Calendário e confirmação do resultado

As B25d-10, B25d-20 e B25d-30 foram incluídas na v1.40, cujo cronograma consolidado indica homologação até 01/07/2026 e produção em 03/08/2026. O aviso ENCAT de 05/10/2026 adiou a implantação da v1.52 para 26/10 em homologação e 16/11 em produção. Ele não declara suspensão automática de todas as regras anteriores.

Confira o novo retorno, a chave e o protocolo correspondente quando houver autorização. Preserve XML, resposta e vínculo com a venda. Acione o suporte quando o campo continuar sendo gerado; procure o responsável fiscal quando houver dúvida sobre o documento adequado. Este artigo foi revisado documentalmente por IA em 10/10/2026, sem teste de emissão por UF ou ambiente.

Fontes

• NT 2025.002-RTC v1.52, páginas 5, 16 e 32: leiaute, cronograma da v1.40 e regra B25d-10. Consulta em 10/10/2026.

• Aviso ENCAT de 05/10/2026: alteração de datas da v1.52, consultada em 10/10/2026.

• Conferência prática: Inventti e Papo Fiscal discutem as regras B25d. FlexDocs apoia a identificação do campo, com orientação adjacente de integração. Não são três tutoriais específicos do 1099; calendários antigos e exemplos desses produtos não substituem a documentação atual nem demonstram funcionamento do ALRA.