tpOperGov: como ler a etapa da operação governamental

tpOperGov distingue a relação entre fornecimento e recebimento na compra governamental. A pergunta é qual etapa o documento representa e se a outra já ocorreu. Não é o meio de pagamento, a finalidade da NF-e ou a situação de um boleto no sistema.

O campo fica em /nfeProc/NFe/infNFe/ide/gCompraGov/tpOperGov e é obrigatório uma vez dentro do grupo. A NT 2025.002 v1.51, página 17, define quatro códigos. Sua leitura deve partir dos fatos documentados da operação e do XML anterior quando houver vínculo.

Duas sequências documentais

Na sequência conceitual 1 → 2, a primeira etapa documentada é o fornecimento; a posterior é o recebimento correspondente. Na sequência 4 → 3, a primeira é o recebimento; a posterior é o fornecimento correspondente. As setas explicam a relação entre tipos, não prescrevem quais documentos devem ser emitidos em uma compra concreta.

Confirme a realização do fornecimento e do recebimento nos documentos que comprovam esses fatos. Uma previsão de pagamento, um boleto criado ou uma marcação manual de “pago” sem origem verificável não resolve a classificação da etapa. O contrato e a documentação real precisam sustentar a informação.

Conferência da nota anterior

A etapa determina também o vínculo em refDFeAnt:

• Tipo 1: a referência anterior é vedada; sua presença corresponde a 1195.
• Tipo 2: é exigida exatamente uma chave; falta corresponde a 1196 e excesso a 1197. O documento anterior deve ser governamental do tipo 1, conforme a regra de 1216.
• Tipo 3: é exigida pelo menos uma chave, até o limite de 99 do leiaute; falta corresponde a 1198. A nota anterior deve ser governamental do tipo 4, conforme 1217.
• Tipo 4: a referência anterior é vedada; sua presença corresponde a 1199.

A chave da nota anterior vem do XML daquele documento. Pedido, contrato ou comprovante podem ajudar a provar o contexto, mas não ocupam o campo de chave.

Exemplo sintético parcial de uma etapa inicial de fornecimento:

<tpOperGov xmlns="http://www.portalfiscal.inf.br/nfe">1</tpOperGov>

Nesse contexto hipotético, não há refDFeAnt. O fragmento mostra o código; omite os demais dados do grupo e da NF-e e não está pronto para transmissão. Ele não comprova que houve fornecimento nem que o tipo 1 é adequado a um caso real.

Contrato e implantação

O TOperCompraGov do 010d v1.03 lido, linhas 76–85 de DFeTiposBasicos_v1.00.xsd, possui somente 1 e 2. A ampliação para 3 e 4 está documentada na versão 1.40 da NT, cujo cronograma registra produção em 03/08/2026.

No corte de 26/09/2026, essa implantação não deve continuar descrita como futura. Se o sistema recusa 3 ou 4 por enumeração, capture o pacote carregado pelo validador e compare com o contrato do ambiente. Não converta uma etapa real em outro tipo para superar o schema antigo. As facetas do 010e não lidas diretamente não são reproduzidas como evidência nesta página.

Tributos e cronograma

A presença do tipo 2 participa de regras que não se limitam à referência. B25-90 dispensa a exigência de ICMS ou ISSQN nessa condição quando a finalidade é diferente de 5 e 6. Essa exceção explica por que uma nota de recebimento não deve ser analisada como qualquer fornecimento.

A redação de B25-80 na versão 1.51 inclui tpOperGov=2 na restrição à presença de ICMS, ISSQN, IPI, II, PIS, PISST, COFINS, COFINSST, ICMSUFDest e impostoDevol. Ela prevê exceções específicas para tipos de nota de crédito 03, 04 e 06 e débito 07; também permite PIS/PISST/COFINS/COFINSST em débito 06 com emissão em 2026 e permite IPI em débito 06.

Essas exceções pertencem às condições completas da regra. Não são uma autorização geral de preenchimento em qualquer nota governamental. A alteração de B25-80 da versão 1.51 tem produção em 05/10/2026, posterior ao corte desta página. Ao investigar o retorno 1001, preserve a versão e a data do ambiente, em vez de apresentar toda a redação futura como uma validação já implantada.

O texto da rejeição menciona finalidade de crédito ou débito, mas a condição também nomeia o tipo governamental 2. Leia a regra completa; a mensagem curta não descreve todos os caminhos que a acionam.

Dados necessários ao diagnóstico

Capture tpOperGov, finNFe, tpNF, as referências, o modelo e os grupos de tributos efetivamente enviados. Esses campos têm papéis separados: etapa governamental, finalidade e sentido da operação não são intercambiáveis.

Se o problema é 1216 ou 1217, abra também o XML anterior e confira seu grupo governamental e tipo. Se é 1196 ou 1197, conte as ocorrências enviadas. Se é falha de enumeração, identifique o schema. A investigação pode localizar uma inconsistência de mapeamento sem decidir uma nova emissão, finalidade ou tratamento tributário.

Referências

NT 2025.002 v1.51, páginas 5–6, 17, 33 e 35–37; DFeTiposBasicos do 010d v1.03, TOperCompraGov, linhas 76–85. Leia o conjunto em gCompraGov. Corte editorial: 26/09/2026.