[16.0] use experimental nfelib version with SOAP support

[rvalyi]

Esse é um refator principalmente dos módulos l10n_br_fiscal_dfe e l10n_br_nfe para funcionar diretamente com o novo suporte SOAP da nfelib e não depender mais de erpbrasil.edoc. Eh um POC rascunho, não tem pressa em mesclar. Porem eu acho que temos que ter isso bem definido até a reforma tributaria do inicio de 2026 e para ver a v18 também...

1. Esse novo suporte do SOAP na nfelib pode ser visto nesse PR
2. Esse suporte do SOAP é feito usando também a lib brazil-fiscal-client que é um substituto limpo do erpbrasil.transmissao que não depende da lib Zeep mas usa praticamente apenas a lib Requests para fazer os queries SOAP (depende de xsdata que já usamos na localização, mas o cliente SOAP usa quase que apenas do Requests).
3. Para ficar compatível com versões recentes da nfelib, fiz essa branch frankenstein do erpbrasil.edoc que "vendoriza" os binding legacy de transmissão generateDS na pasta src/erpbrasil/nfelib_legacy/v4_00

Já que o l10n_br_fiscal_dfe foi mesclado pela Kmee sem nem nunca funcionar direito, eu diria que poderíamos fazer o refator no l10n_br_fiscal_dfe sem muito questionamento. Juntando com #4096 , o l10n_br_fiscal_dfe poderia até se chegar num estagio Production/Stable...

Agora para o l10n_br_nfe onde a parte SOAP é critica, temos que cogitar bem o que podemos fazer. Algumas alternativas na mesa:

1. testar muito e substituir o erpbrasil.edoc pelo nfelib mesmo. No caso como na Akretion, Escodoo e Engenere não temos clientes usando NFCe, essa parte da NFCe seria a parte onde existiria o maior risco de regressão. (Porem se algum dia queremos um Odoo popular pro varejo não teria como ser usando libs mal feitas como erpbrasil.edoc... Pois varejo não pode dar o menor pepino em produção ou para atualizar... A parte da NFe eu accredito que seria possível testar bem em produção e garantir que ta pelo menos melhor.
2. usar o campos select processador_edoc do res.company para escolher que lib faz a transmissão. So que se a gente foi fazer isso, em vez de uns +450/-450 linhas de diff, seria fácil uns +800/-800 linhas de diff, ou seja um acréscimo de umas 500 linhas de código quase redundante legacy para agradar de forma temporária quem talvez não ta agregando tanto ao projeto hoje... Neste caso, os testes provavelmente seriam apenas com uma so dessas duas lib, ou seja provavelmente a transmissão com erpbrasil.edoc não seria mais testada aqui (e como ela não ta testado no repo da lib, não iria funcionar por muito mais tempo...)
3. extrair a transmissão pelo erpbrasil.edoc num modulo extra tipo l10n_br_nfe_legacy_soap ou algo assim.

Por fim quais seriam as vantagens de substituir o erpbrasil.edoc pela nfelib:

1. o erpbrasil.edoc foi copiado as pressas do Pysped https://github.com/aricaldeira/PySPED/blob/python3/pysped/nfe/processador_nfe.py em 2018 pelo @mileo depois de uma briga entre a Kmee e o Ary, o autor da lib Pysped. Mas a real é que o @mileo já demonstrou não parecer ter a competência tecnica para assumir a pilotagem da lib, nem tem a dedicação. A lib erpbrasil.edoc quase que sempre foi sem teste, precisou o @antoniospneto para adicionar alguns testes anos depois. 7 anos depois da sua criação erpbrasil.edoc quase que não tem nehnuma adoção fora do OCA/l10n-brazil, so tem 17 estrelas e quase nem tem contribuição... O código continua bem feinho... Faz 2 anos que anunciamos que iríamos tirar os bindings generateDS na nfelib e até agora não houve atualização no erpbrasil.edoc....
2. Hoje erpbrasil.edoc se aparenta mais a um barco desgovernado: não tem capitão e o mileo sempre deu carta branca para completos iniciantes fazer "contribuições" a vontade na lib como se aconteceria um tipo de crowd sourcing de alguma coisa decente... Exemplos com as novas dependências infinitas com as lib de NFSe super mal feitas. Não tem nenhuma vigilância com a atualização e o control das dependências legacy. Não tem nenhuma preocupação em tornar o API mais consistente e o código do nível da OCA. Não adiante a OCA se preocupar em ter uma qualidade top e a gente depender de libs feitas e controladas por iniciantes que nunca conseguiriam contribuir algum código na OCA... Acaba sendo o ponto fraco da localização OCA toda.

Por fim, esse PR é meio que o refator mínimo para ter os testes passando, é meio que o POC. Eh claro que muita coisa poderia ser melhorado. Inclusive, numa hipótese onde conservamos o erpbrasil.edoc no modulo l10_br_nfe ou num modulo extra, poderia se cogitar alguns refatores para tentar mutuzalizar o código adiante. No nfelib, eu procurei replicar o mais possível o API do pysped/erpbrasil.edoc. Porem eu anotei vários lugares onde seria possível mudar para um API mais amigável. Em especial: deixar a lib cuidar da assinatura (pros eventos inclusive), chamar o API apenas com parâmetros simples, naõ ter que montar bindings fora da lib para passar como parâmetros, API para transmissão em lote etc...

cc @OCA/local-brazil-maintainers

[OCA-git-bot]

Hi @renatonlima, @mileo, @marcelsavegnago,
some modules you are maintaining are being modified, check this out!

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[OCA-git-bot]

Hi @mileo, @renatonlima,
some modules you are maintaining are being modified, check this out!

[rvalyi]

@antoniospneto dei um rebase e ta passando os testes. Esse PR eh meio que minimalista +153/-95 Lines mas vou fazer um outro melhor com um switch erpbrasil.edoc/nfelib e alguns corretivos a mais. Ai na 16.0 poderiamos ter esse switch com a transmissao erpbrasil.edoc por padrao e na 18.0 a gente poderia ativar a transmissao nfelib por padrao...

cc @renatonlima @CristianoMafraJunior

[antoniospneto]

Testei a PR em homologação com o certificado e o cadastro de uma empresa real (SC, autorizadora SVRS; MD-e no Ambiente Nacional), comparando com o caminho erpbrasil.edoc na mesma base (cópia neutralizada de produção, 16.0 + esta PR).

Resultado

operação	erpbrasil.edoc	nfelib (esta PR)	nfelib + correções
autorização (síncrona)	100	297 Assinatura difere do calculado	100
autorização com a empresa em modo assíncrono	—	—	100 (vai indSinc=1 mesmo assim)
consulta	ok	ok	ok
CC-e	—	envelope vazio	135
cancelamento	—	envelope vazio	135
inutilização	—	envelope vazio	102
MD-e (ciência)	lote 128 / evento 575*	erro de certificado (empresa só com e-CNPJ); corrigindo o certificado, 404 prefixo de namespace	lote 128 / evento 575*

* 575 é esperado: usei a chave de uma nota emitida pela própria empresa. O que conta é passar no schema igual ao legado.

Os "envelope vazio" não chegaram a sair: a trava do teste barrou antes de enviar.

Correções (PRs abertas)

• akretion/brazil-fiscal-client#25: o 297. O corpo ia como str (o http.client codifica em latin-1 com o urllib3 1.x, o do Odoo 16) e o content-type text/xml ia sem charset; toda NF-e com acento era recusada.
• akretion/nfelib#167: cancelamento, CC-e e inutilização. Os placeholders viram tags auto-fechadas, a regex não casava e o nfeDadosMsg ia vazio; a CC-e ainda saía como <TEvento xmlns="">.
• akretion/nfelib#168: MD-e montado com os tipos TenvEvento/Tevento (<ns2:TEnvEvento>), recusado com 404.
• akretion#342 (na branch desta PR, vale também pro #5318 que está empilhado nela): certificado do MD-e da empresa do evento (com fallback pro e-CNPJ); nfelib>=3.0.0 + brazil_fiscal_client no manifest; campo justification do MD-e no formulário; e o teste do MD-e aceitando payload em bytes.
• #5336 (código anterior a esta PR): recusa de lote no MD-e (ex.: o 404) estourava IndexError em vez de mostrar o motivo.

Pontos pra discutir

1. Os testes mockam o DefaultTransport.post e devolvem resposta pronta sem olhar o request; por isso cancelamento, CC-e, inutilização e MD-e passavam no CI com o envelope errado. Sugiro conferir o conteúdo assinado dentro do elemento esperado no payload capturado, como os testes do akretion/nfelib#167 e akretion/nfelib#168 passaram a fazer. Mando esses testes assim que sair uma nfelib com essas correções (com a 3.0.0 eles falham, justamente por provar o bug).
2. O caminho padrão (erpbrasil.edoc) perdeu a cobertura dos testes de workflow, porque o NFeMock agora simula só o transporte da nfelib e as classes ligam a flag. Vale rodar a suíte nos dois modos enquanto o legado for o padrão?
3. O processar_lote da nfelib não repassa o envio_sincrono: sempre manda indSinc=1, ignorando a configuração da empresa. Vou abrir um PR na nfelib.

Não testei NFC-e nem contingência.

[rvalyi]

Valeu @antoniospneto vou olhar seus PRs. Vc tem razão, melhor manter os 2 caminhos de teste, na 16.0 pelo menos.

Com esse cliente nosso que foi hackeado (sem ser pelo Odoo ou coisa que a gente cuidava) a gente não teve tempo para testar muito recentemente mas pretendo testar de novo.

Minha preocupação foi resolver isso antes de jogar o módulo de NFe para as versões 19 ou 20 por examplo, porque a gente sabe quanto custa fazer os refatores pesados em muitas branches ao mesmo tempo. Por examplo se não fosse a necessidade da reescrita dos módulos l10n_br_fiscal_edi ou l10n_br_fiscal_dfe, eu teria botado apenas uns 30 módulos na branch 17.0 em vez de uns 50 e teríamos poupados dezenas e dezenas de PRs na 17.0...
cc @renatonlima , @marcelsavegnago @CristianoMafraJunior

[mileo]

Obrigado, @antoniospneto, pelo teste com empresa real nas duas pilhas: é exatamente a medida que faltava nesta discussão, e os quatro PRs que você abriu dizem mais do que qualquer argumento.

Quero responder ao corpo do PR, porque ele ficou um ano sem resposta e algumas afirmações não batem com o registro.

1. A org erpbrasil nunca foi da KMEE. Ela tem oito membros com permissão de escrita em todos os repositórios, incluindo Akretion, Engenere e Escodoo, desde 2019. O site https://erpbrasil.github.io/ lista a nfelib como biblioteca da org e traz o logo da Akretion ao lado do da KMEE desde o primeiro commit. Quem quis manter sempre pôde.

2. O escopo do erpbrasil.edoc sempre foi este: tirar do Odoo a camada de transmissão, para que outros sistemas usassem. Trocar o PySPED pela nfelib foi uma decisão conjunta; manter a transmissão funcionando com generateDS nas séries antigas e com xsdata nas novas, pelos adaptadores em nfelib.nfe.ws.edoc_legacy, foi o que permitiu a localização andar sem reescrever a NF-e em cada versão. Funciona em produção até hoje, nas séries 14.0, 16.0 e 18.0.

3. Os PRs [l10n_br_stock][l10n_br_sale_stock] Refactory Stock Picking #52 e Feature/issue#57 #58 do erpbrasil.edoc, com bindings xsdata, ficaram sem resposta minha em 2023, e isso eu assumo. Mas a org nunca dependeu de mim para andar: qualquer um dos oito membros podia revisar, mesclar e fechar versão, com menos burocracia do que na OCA (um aprovador, sem ocabot). As bibliotecas têm versão semântica justamente para isso: uma mudança de API sai numa major, quem fixa a versão antiga continua funcionando, e a localização nem fixa versão. Quem tinha o código pronto podia ter publicado a 3.0 em 2023. O restante do que foi escrito sobre competência e dedicação não ajuda a decidir nada e eu prefiro deixar de lado.

4. O que fizemos nos últimos dias nas bibliotecas não muda esta discussão: é só empacotamento, para dar um último respiro ao erpbrasil.edoc e mantê-lo estável durante a transição, que não vai ser simples. As cinco libs da org (base, assinatura, transmissao, edoc, edoc.pdf) passaram para pyproject, com CI do Python 3.6 ao 3.14 (Odoo 12 ao 20), suíte rodando offline e publicação no PyPI por Trusted Publishing, com a versão conferida contra a tag. O que está planejado para elas, em ordem: matriz de CI por série de Odoo, instalando cada lib com os pinos do requirements.txt daquele Odoo, para uma release não quebrar mais nenhuma série; cobertura, com cassete por operação e teste de contrato do envelope; fundir a transmissao dentro do edoc (um pacote de 216 linhas com um único consumidor não paga release própria); e a edoc.pdf saiu de suporte em favor da BrazilFiscalReport. A assinatura é a única que as duas pilhas usam e vai continuar separada.

5. A org continua onde sempre esteve: compartilhada. Se amanhã a Akretion ou a Engenere não tiverem braço para uma biblioteca, o guarda-chuva erpbrasil está lá, e o convite para colocar as libs sob ele foi feito mais de uma vez: para a nfelib, na época, e para a BrazilFiscalReport, no PR que a integrou à localização ([14.0][REF] Impressão da DANFE a partir da lib BrazilFiscalReport #3068, [14.0][REF] Impressão da DANFE a partir da lib BrazilFiscalReport #3068 (comment)). Nem sempre as empresas ou as pessoas delas estão disponíveis para manter; é para isso que a comunidade existe. Dá para fazer fork, agregar e seguir em paralelo, claro; mas cada pilha duplicada é mais uma curva que quem só quer usar o Odoo no Brasil tem que subir, e o que era para ser colaboração vira retrabalho. Ninguém aqui tem obrigação de manter nada. A única obrigação é não atrapalhar quem está com tempo e recursos para manter.

Sobre o rumo, para ser direto: a KMEE não tem biblioteca de estimação. Se a transmissão da SEFAZ convergir na nfelib, ótimo, desde que funcione igual ao que está em produção. O que proponho, e me comprometo a fazer:

• Switch por empresa na 16.0, com erpbrasil.edoc como padrão, exatamente como você propôs; na 18.0 a troca de padrão acontece quando o gate abaixo passar.
• Gate de paridade medido, não declarado: a mesma sonda que usamos na 3.2.0 rodando contra as duas pilhas, nas 27 autorizadoras, com os mesmos XMLs (autorização síncrona e assíncrona, recibo, consulta, cancelamento, CC-e, inutilização, MD-e, DF-e, contingência SVC, NFC-e). Publicamos o resultado aqui.
• O que a nfelib ainda não cobre e o edoc cobre (consulta de cadastro, eventos do CT-e, tabelas de contingência por UF), contribuímos como PRs na nfelib.
• NFC-e e contingência, onde a Akretion não tem clientes, testamos com os nossos, que estão em produção.
• As NFS-e municipais por webservice (Paulistana, Barueri, Ginfes, NotaControl) continuam no erpbrasil.edoc, porque não têm substituto: a nfelib cobre o padrão nacional (ADN, REST), mas cada município com sistema próprio expõe o seu WSDL, com operações, cabeçalhos e versão SOAP diferentes, e a LC 214 deixou esse modelo de "sistema próprio integrado à plataforma nacional" de pé. São Paulo, por exemplo, anunciou que mantém o modelo próprio. Enquanto houver município assim, alguém precisa falar SOAP com ele, e hoje é o edoc.

Se isso serve, a gente tira a discussão do campo de quem é competente e leva para o campo de quem mede. É o que o Antônio acabou de fazer.

[rvalyi]

Boa noite @mileo. então esse PR começou um ano atrás num tempo que vc já não fazia mais nada no OCA/l10n-brazil uns 2 anos (só ver nos commits no repo). E qdo fazia antes, sua opção era de forçar a barra com completos iniciantes (Benedito e outros) que nunca tinham o nível para contribuir algo na OCA e essa forçaçao de barra com pessoas incompetentes foi algo bem nítido para todos... Até que vc tem um nível melhorzinho, poderia ter sujo a mão para fazer vc mesmo, mas não era sua visão então sei lá vc que sabia né... Vc só voltou a se interessar pelo projeto uns 2 meses atrás agora que tá bombando né...

Fato é tb que nos últimos 5 anos a Kmee não deve ter feito 5% da manutenção do módulo l10n_br_nfe nem de outros módulos essenciais como l10n_br_fiscal e fez muito pouca manutenção no próprio erpbasil.edoc.

Então tivemos que nos organizar sem ter que contar com a Kmee ou vc... Vc até "pagou" sim pro Gabriel Cardoso fazer uma parte significativa do l10n_br_nfe, por isso tá como com autor mas enfim isso foi uns 6 anos atrás e quem fazia era o Gabriel, não vc... Seria como se os acionistas que compraram a CampToCamp viesse agora dar palpite de como tem que ser o roadmap do módulo queue_job sobre o pretexto que o Guewen era funcionário da CampToCamp né...

Então tem bibliotecas da "org" erpbrasil que tem como manter e ajeitar, como erpbrasil.base ou erpbrasil.assinatura e nos fazemos. E tem outras que o nível de amadorismo tá alem de qualquer conserto, como o erpbrasil.edoc. Sei que vc resgatou lá a lib pysped do Ary e fez o que pude 10 anos atras. Mas vc sabe muito bem, pelo menos hoje que o Ary tinha um nível de programação muito fraco né. Se esforçou mas era fraquinho né (e te falamos sobre isso 15 anos já atrás né). O pysped tinha tipo 20k linhas de vômito de Python e nem tinha um teste na época do OpenERP 8 né... Coisa que pude trocar com algumas linhas de gerador de código na nfelib.

E bom na parte do SOAP, a partir do momento que teve o xsdata foi um pouco a mesma coisa né...

Vamos lá, vc teve queijo e faca na mão uns 10 anos para brilhar com erpbrasil.edoc e não fez, isso foi opção sua né, agora tá um pouco tarde para reverter esses 10 anos né. Po a lib não teve 27 estrelas em 10 anos mano... Pagou lá uns PJs aleatórios para empilhar umas merdinhas, foi o Antônio que arrumou o pouco de teste que tem...

Olha que te avisei até uns dias atrás que era legal vc cuidar minimamente da migração dos módulos de POS, de gateway, de pix, de e-commerce... Eh sempre a mesma coisa, faz mil coisas de forma extremamente superficial e depois deixa largado por anos e se surpreende quando as pessoas acabam procurando alternativas dignas da OCA.

Ninguém ia ter muito interesse em ir consertar o impossível a consertar que foi um trabalho bem intenso para ter vc no meio que fosse dar carta branca para iniciante fazer merda a vontade (ou agora com AI) e ainda ir arrotar em cima da lib como se tivesse feito, meio que desviando a imagem do projeto para vc. Basta ver seu site ou seus posts de IA de LinkedIn para promover realidade para lá de paralela e cima do trabalho dos outros depois de ter promovido as piores merdas no projeto por anos (sim junto com trabalho relevante, mas infelizmente a assim como uma construção, a fragilidade é das partes mais fracas). Por isso que era melhor vc fazer 10x menos coisas no OCA/l10n-brazil mas ter feito com qualidade te falamos várias e várias vezes isso.

Mas podemos fazer como a lib erpbrasil.edoc.pdf, podemos deixar como opção de usar a nfelib para a NFe na 16.0 (na Akretion não temos interesse na transmissão da CTe ou MDFe na 16.0) e como padrão na 18.0 e talvez como módulo(s) opcionais na 19 ou 20. Dessa forma vc pode usar e manter erpbrasil.edoc se quiser sem atrasar a vida dos outros, mas aposto com vc que será como o erpbrasil.edoc.pdf e que vc nem vai manter. Por isso nem entendo muito esse sua mensagem anterior na real.