[16.0][POC][ADD] l10n_br_nfse_nacional: NFS-e Nacional

[kaynnan]

cc @marcelsavegnago @rvalyi @WesleyOliveira98 @CristianoMafraJunior

Este PR adiciona suporte à emissão de NFS-e no Padrão Nacional SEFIN diretamente via API REST, sem dependência de prestadores intermediários.

A ideia surgiu a partir da PR inicial do @rvalyi #4481 que explorou a integração com a API SEFIN e o uso do xsdata para os bindings do DPS v1.0. Este trabalho foi desenvolvido do zero, aproveitando os conceitos fundamentais propostos uso de nfelib, serialização via xsdata JsonSerializer e o padrão spec_driven_model já consolidado nos módulos l10n_br_nfe_spec e l10n_br_cte_spec.

• Modelos Odoo abstratos (nfse.10.*) gerados pelo xsdata-odoo a partir do XSD oficial DPS v1.0, com prefixo de campos nfse10_, seguindo o padrão do l10n_br_nfe_spec
• NfseSpecMixin — modelo base que registra os módulos de binding e Odoo para o spec_driven_model
• DpsBuilder — converte um l10n_br_fiscal.document em payload JSON DPS v1.0 pronto para envio, com suporte a MEI, retenções federais (IRRF, CSLL, INSS, PIS/COFINS) e mapeamento correto dos regimes especiais de tributação
• NfseResponse — dataclass para leitura normalizada das respostas da SEFIN
• Emissão via API REST SEFIN com autenticação mTLS (certificado digital da empresa)
• Consulta de status via ação agendada (cron)
• Cancelamento com justificativa
• Substituição de NFS-e
• DANFSE Nacional — gerado localmente pela biblioteca brazilfiscalreport a partir do XML autorizado pela SEFIN; opcionalmente baixado do serviço oficial SEFIN quando disponível
• Suporte aos ambientes de Homologação e Produção por empresa

[antoniospneto]

DANFSE Nacional: obtido do serviço oficial ou renderizado via QWeb como fallback

Vale ressaltar que a API nacional para emissão DANFSE vai ser descontinuado já no próximo mês e a emissão do documento será de resposabilidade do próprio emissor. Será que a geração via QWEB é a melhor opção? não seria melhor usar a lib BrazilFiscalReport?

Faz poucos dias que publiquei uma nova versão, já no modelo DANFSe v2.0 da NT 008/2026.

Veja:

[rvalyi]

Kkkk daqui pouco Odoo Enterprise vai ter que usar o BrazilfiscalReport e nfelib, vai começar a ficar feio tentar esconder a existência da OCA a todo custo... isso e o reclameaqui entupindo de reclamações. Tic tac tic tac...

[kaynnan]

DANFSE Nacional: obtido do serviço oficial ou renderizado via QWeb como fallback

Vale ressaltar que a API nacional para emissão DANFSE vai ser descontinuado já no próximo mês e a emissão do documento será de resposabilidade do próprio emissor. Será que a geração via QWEB é a melhor opção? não seria melhor usar a lib BrazilFiscalReport?

Faz poucos dias que publiquei uma nova versão, já no modelo DANFSe v2.0 da NT 008/2026.

Veja:

Exato, seria melhor sim, o @CristianoMafraJunior chegou a comentar a respeito, vou alterar o projeto para que use essa lib mencionada.

[antoniospneto]

@kaynnan qual que a diferença desta PR para a #4591 ?
obs: não me aprofundei muito.

[kaynnan]

@kaynnan qual que a diferença desta PR para a #4591 ? obs: não me aprofundei muito.

De maneira sucinta @antoniospneto,#4591 usa spec_driven_model.SpecModel o document herda diretamente de nfse.10.tcdps e nfse.10.tcinfdps, deixando o framework mapear campos Odoo → XML automaticamente via XmlSerializer(mesmo padrão do NF-e). Requer modificação no spec_driven_model (workaround explícito no PR).

Já a nossa PR usa DpsBuilder constrói o payload imperativo a partir dos campos Odoo e serializa via JsonSerializer. Não toca em spec_driven_model nem em l10n_br_fiscal.

#4591 adiciona ("4", "Simples Nacional - MEI") em TAX_FRAMEWORK de l10n_br_fiscal/constants/fiscal.py e altera TAX_FRAMEWORK_SIMPLES_ALL = ("1", "2", "4")

Do nosso lado, identificamos o MEI via taxation_special_regime == "5" (já existente em l10n_br_nfse) sem tocar em l10n_br_fiscal.

[rvalyi]

pessoal, vou olhar esse PR assim que eu puder. Porem valeria a pena dar uma atençao para dar uma acertada primeiro na gestao dos estados dos documentos fiscais no l10n_br_fiscal_edi, porque a gente vem empurrando com a barriga um codigo bem feio (aqueles exec_after_* exec_before_* que vem tipo la do Odoo versao 10 quando a Kmee fez uma transcricao literal dos workflows dinamicos que tinhamos no antigo FSM engine desde a versao 8. Mas isso nao ta nada legal e ta se espalhando pelos documentos fiscais, eh a pasta de dente que ta saindo do tubo e a gente pisando em cima do tubo com os 2 pes juntos e depois so malandro safado para defender a ideia que a pasta voltaria no tubo (mas esse Brasil tem de tudo mesmo eh foda)... Entao temos que limpar isso quanto antes...

Fiz uma nova proposta mais simples aqui #4629 porem ainda rascunho neste momento.