Modelar classes RTC (NT 2025.002 / PL_010e) no DFe.NET: IS, cIndOp, refDFeAnt, gALCZFMCBS

[rhfranzoni]

Origem

Origem: @rhfranzoni via demanda interna (Reforma Tributária) — habilitar o consumidor nfe/dfetech-product-invoice-api#265.

Contexto

A NF-e da Reforma Tributária (NT 2025.002-RTC) adiciona grupos/campos ao leiaute que o DFe.NET (Zeus) ainda não modela. O dfetech-product-invoice-api precisa dessas classes para emitir os grupos na conversão XML. Escopo limitado ao schema fornecido PL_010e_v1.01 (nível RTC v1.40).

Objetivo

Modelar no DFe.NET as classes/campos RTC presentes no PL_010e_v1.01, no padrão da lib (POCO + [XmlElement] + ShouldSerialize), sem quebrar a serialização atual.

Escopo — Inclui

• Grupo IS (Imposto Seletivo, tipo TIS) em det/imposto.
• cIndOp no produto.
• refDFeAnt (Compras Governamentais).
• gALCZFMCBS (ALC/ZFM alíquota zero CBS).

Escopo — Nao inclui

• Monofásico reformulado v1.50 (Ad Rem × Ad Valorem, gpBioDiferenca) e ISUFemit — não estão no PL_010e_v1.01; change futura com o PL v1.50 oficial.

Criterios de Aceitacao

• Notas sem os grupos novos → XML idêntico ao atual (campos opcionais não emitidos).
• Notas com cada grupo → tags na ordem do XSD, só campos preenchidos.
• Build do NFe.Classes sem erros.

Dependencias

Nenhuma. Plano em OpenSpec add-nt2025-002-rtc-schema-classes.

Referencias

• PR: feat(rtc): classes RTC NT 2025.002 (PL_010e) — IS, cIndOp, refDFeAnt, gALCZFMCBS #85
• Schema: PL_010e_v1.01 (DFeTiposBasicos_v1.00.xsd, leiauteNFe_v4.00.xsd)
• Consumidor: https://github.com/nfe/dfetech-product-invoice-api/pull/265

[rhfranzoni]

⚠️ Divergência do upstream (ZeusAutomacao/DFe.NET) — risco documentado para decisão futura

Decisão atual: manter esta implementação no fork (curto prazo) — desbloqueia o consumidor nfe/dfetech-product-invoice-api#265. A estratégia de fork fica como decisão futura (este registro é para embasá-la).

Situação (verificado em 2026-07-03):

• O nfe/DFe.NET está divergente do upstream ZeusAutomacao/DFe.NET: +285 / −1989 commits (diverged). O fork seguiu caminho próprio; o upstream avançou ~2000 commits (RTC própria + CNPJ alfanumérico NT 2026.004 + mais).
• O upstream tem implementação RTC própria e paralela à nossa: já possui IBSCBS.cs e Federal/IS.cs no master, e histórico grande de PRs da Reforma (ex.: feat: ajuste nos campos criados pela Reforma Tributária e adição dos da nova Nota Técnica ZeusAutomacao/DFe.NET#1626 "adição dos campos da nova NT", mergeado em Reforma_tributaria, tocando gIBSCBSMono, gMonoPadrao/Ret/Reten/Dif, gTribCompraGov, IS.cs, ide.cs, gCBSTotal).
• Os 3 campos deste PR (cIndOp, refDFeAnt, gALCZFMCBS) NÃO existem no master do upstream (code search + grep no ide.cs do upstream = 0) — logo, não há duplicação com o upstream hoje.

Riscos da divergência:

• Se um dia sincronizarmos com o upstream, a RTC deles pode diferir da nossa (nomes de classe/campo, estrutura do monofásico) → merge doloroso / retrabalho.
• O upstream pode implementar cIndOp/gALCZFMCBS/refDFeAnt de forma diferente da nossa.

Opções para a decisão futura:

1. Continuar divergindo no fork (custo de manutenção crescente).
2. Sincronizar/rebasear na RTC do upstream (aparenta mais avançada — já tem os gMono*).
3. Contribuir upstream (PR no ZeusAutomacao/DFe.NET) e voltar a acompanhar o master.

Recomenda-se um alinhamento técnico sobre a estratégia de fork antes de investir mais na RTC do fork.