l10n-brazil
l10n-brazil copied to clipboard
OCA
[14.0][l10n_br_nfe][xsdata refactor]
Esse é o ultimo PR de refator para usar a NFe com xsdata em vez de generateDS. Esse PR ta incluindo os commits relevantes dos 2 outros PRs:
- https://github.com/OCA/l10n-brazil/pull/1977
- https://github.com/OCA/l10n-brazil/pull/1978
Aqui fiz um hack manual no l10n_br_nfe_spec https://github.com/OCA/l10n-brazil/commit/a55b5b0bc8f412b45a8672623d341db60169943a para lidar com as mudanças do xsdata comparando com o generateDS. Em especial, o xsdata não tem suporte para as tags xsd <choice>. Em geral ta tudo bem basta accrescentar os campos choice que a gente usava antes (so tinha impacto nos attrs de algumas telas) como eu fiz aqui https://github.com/OCA/l10n-brazil/commit/b6c049bb4f11e7ec536d577be71455df04504dc2 Porem o generateDS botava required=True pros campos dentro de choice enquanto o xsdata não. por isso esse hack. Temos que ver se a gente herda, no l10n_br_nfe ou altera o gerador xsdata-odoo para não ter que fazer isso. Tem que ver tb se esses xsd_required=True que eu adicionei são exaustivos ou não...
Nos ultimos commits é possivel de ver a mudanças do l10n_br_nfe pro xsdata. Alem desses campos choice, eu tive que mudar o nome de algumas classes de binding nfelib e principalmente o nome dos argumentos dos tags de impostos (que são pythonica no binding nfelib gerido pelo xsdata. Por examplo CST virou cst).
Nessa hora, tem que usar com essa branch https://github.com/akretion/nfelib/tree/master-xsdata do nfelib. Eu irei publicar um nfelib-xsdata no pypi para poder rodar a CI dos PRs. Mas por enquanto so vai funcionar se pegar essa branch do nfelib no seu requirements.txt. Com isso o Odoo serializa as NFe's de test, mas tem alguns diff que tem que analisar (tem que olhar nos logs o arquivo onde ele grava esses XML de tests para comparar com os XML desejados. O teste de estrutura ta passando e o teste de validação de esquema foi desativado por enquanto.
Por fim, tem que fazer um branch do erpbrasil.edoc para poder transmitir as NFe's com xsdata. Com umas 50-100 linhas de diff no erpbrasil.edoc deve ser possivel.
Enfim eu conto com voces para ajudar a botar isso 100% e testar muito.
cc @renatonlima @marcelsavegnago @netosjb @felipemotter @mbcosta @hirokibastos @vanderleiromera
uma observação interessante. Hoje com o generateDS, adicionando o codigo do l10n_br_nfe_spec + l10n_br_nfe + nfelib + erpbrasil.edoc tem mais ou menos 50k linhas de codigo para suportar a NFe no Brasil fora o modulo fiscal então. Desses 50k, tem uns 6k-7k de codigo feito na mão apenas. Com o xsdata, tem facilmente uma diminução de 10k linhas de codigo gerido (principalmente no nfelib onde mesmo assim botei mais esquemas).
Para fazer a troca generateDS -> xsdata precisa de alterar menos de 500 linhas de codigo escrito na mão (no l10n_br_nfe e no erpbrasil.edoc). Ainda é um refator grande, mas são 500 linhas dentro de 50k linhas, so 1%, então eu digo que é bem razoavel. O objetivo é não ter mudança de schema no banco e que tudo seja resolvido com --update. Ta na mão mas precisa testar muito...
cc @renatonlima @marcelsavegnago @netosjb @felipemotter @mbcosta @hirokibastos @vanderleiromera
rebase feito e integrado https://github.com/akretion/l10n-brazil/pull/204 cc @netosjb
algumas horas atras tinha erros com Pageseguro mais não tem mais. Tem um erro esquezito com account_edi no Runboat que não parece muito vir do meu PR mas que talvez a gente precisaria fazer algum override.
Agora rodando os testes completos vi que tem um erro nos testes do account_nfe (com o campo nfe40_dVenc no l10n_br_nfe_spec/models/v4_00/leiauteNFe.py que ficou como Char em vez de Date), pois pelo jeito o meu gerador xsdata-odoo se cagou para detetar os campos de tipos Date e DateTime: não tem nehnum mas deveria, ficou tudo como fields.Char. Vou arrumar nos https://github.com/akretion/xsdata-odoo e arrumar os testes la...
FYI eu não resolvi os problemas mencionados em https://github.com/OCA/l10n-brazil/pull/1979#issuecomment-1329892805 mas eu fiz o squash (na vdd rebase -i) de uns 3 commits para deixar o histórico mais legível. Isso é bem importante se depois a gente fizer um backport disso na 12.0 (vamos fazer na Akretion para alguns clientes mas se vai rolar merge disso ou não na 12.0 isso vai depender muito a recepção dessa PR).
more about the Date and DateTime spec fields: https://github.com/akretion/xsdata-odoo/issues/5
@renatonlima @marcelsavegnago @antoniospneto @felipemotter @mbcosta @hirokibastos @vanderleiromera
verdinho! Ta com aquele workaround temṕorario pro account_edi não blocar https://github.com/OCA/l10n-brazil/pull/1979/commits/02bbd3e5f9d1d6b010ffdd840932b3f9f12d2ec5 Mas eu resolvi o problema dos campos Date e DateTime na geração pelo xsdata-odoo.
fiz uns rebase -i e dei uma boa limpada. Não que seja perfeito ainda, mas ja ta muito OK para pegar e testar e sugerir melhorias.
Por fim a transmissão mesmo da NFe pelo erpbrasil.edoc não vai funcionar apenas com esse PR. Mas o @antoniospneto ja começou a testar uma branch para transmitir usando os bindings do xsdata, conto um pouco com ele para testar mais e ajudar nessa parte enquanto eu o @renatonlima estamos subindo melhorias vindo da v12 e vou ir dando rebase a nesse PR a medida que as melhorias da v12 estao entrando na 14...
@renatonlima @marcelsavegnago @antoniospneto @felipemotter @mbcosta @hirokibastos @vanderleiromera fiz um rebase e adaptei para passar os testes nos 2 ultimos commits Durante esse rebase, o commit que deu um pouco de trabalho foi esse https://github.com/OCA/l10n-brazil/pull/2235/files porque campos como o zip do res.partner estava sendo definidos pelo spec_import.py por serem related e não estao mais. Dai eu tive que chamar as funções inverse quando o registro é um NewId (dry_run) enquanto quando a importaçao faz um create essas funções estão chamadas automaticamente no create.
@rvalyi consegue dar uma rebase ? tá conflitando com o código que entrou hoje
@rvalyi consegue dar uma rebase ? tá conflitando com o código que entrou hoje
rebase feito. Alias, onde dava conflito é porque eu tinha alterado alguns nomes de variáveis. o Gabriel tinha usado nomes como member_spec ou _ds (para data structure) que são palavras muito peculiares do generateDS e não fazem muito sentido fora do contexto do generateDS. Então eu usei respectivamente field_spec e _binding.
@antoniospneto eu fiz os cherry-picks do seu PR https://github.com/akretion/l10n-brazil/pull/211 ainda com um amend para a tipo sing -> sign. E fiz esse commit temporario para permitir aos tests de rodar aqui https://github.com/OCA/l10n-brazil/pull/1979/commits/2a28e628fdb02bf9c2e92dd302e46ce0b421255f
So que os tests não estao passando mais porque pelo jeito sua mudança fica assinando as NFe's e não temos essa assinatura nos XMLs "modelo". Sera se basta acrescentar a assinatura nesses XML's? ou remover a tag antes de comparar assim como eu fazia no nfelib https://github.com/akretion/nfelib/blob/master_gen_v4_00/src/nfe/leiauteNFe_sub.py#L25 ? Ainda não olhei bem, mas se vc tiver alguma ideia eu agradeço.
Meu objetivo em breve tb é remover esse hack https://github.com/OCA/l10n-brazil/pull/1979/commits/afe1c5c5cd84f711473d48c4305b88051a872bff usando os mixins geridos com https://github.com/akretion/xsdata-odoo/pull/6
cc @renatonlima @marcelsavegnago
Sera se vc consegue extrair isso num PR separado para a 14.0 para facilitar? Outra coisa, tem que pensar numa forma que o cara consegue validar o XML mesmo se ele não tiver colocado um certificado valido ainda, talvez ja assina assim, não sei, mas enfim so falando.
Pessoal, eu consegui ajustar a gestão dos choices no xsdata-odoo de forma que não precisamos mais daquele patch que eu tinha botado antes para acertar os xsd_required=True de alguns campos https://github.com/OCA/l10n-brazil/pull/1979/commits/afe1c5c5cd84f711473d48c4305b88051a872bff
Basicamente quando um campo esta dentro de uma tag <xs:choice> obrigatoria no XSD (sem minOccurs="0"), o generateDS bota o campo como required (então xsd_required em nosso caso) o que era errado!
o xsdata não lida com os choice e não botava required/xsd_required nesses caso. Era correcto mas criava algumas diferenças, principalmente na hora de montar os objetos "stacked". Pois se um m2o é xsd_required ele entra na denormalização "stacked". Então alguns campos não eram mais stacked e precisava desse meu patch do leiaute_nfe para acertar os xsd_required de alguns campos...
O que eu fiz no xsdata-odoo (vou subir os commits assim que eu limpar), foi que eu botei um suporte para as tags <xs:choice>, so que quando um campo pertence de um <xs:choice> obrigatorio, em vez de botar required/xsd_required=True, eu boto um novo atributo xsd_choice_required=True.
Ai nos ultimos commits eu alterei levamente os modulos spec_driven_model e l10n_br_nfe para lidar com esse novo atributo xsd_choice_required e funcionar da mesma forma que antes com os xsd_required=True dos mixins generateds-odoo.
Agora essa PR tem apenas uma pequena "gambiarra" no ultimo commit https://github.com/OCA/l10n-brazil/pull/1979/commits/44eebee1e13befe4fb24237179c32d885f4b06b7 para ter os testes passando apesar da alteração na logica de assinatura que o @antoniospneto fez (assinar antes de validar). @antoniospneto se vc conseguir deixar isso limpo nos testes eu agradeço...
cc @renatonlima @marcelsavegnago @felipemotter
As ultimas mudanças no gerador xsdata-odoo que foram usadas para gerir os mixins do l10n_br_nfe_spec nesse commit https://github.com/OCA/l10n-brazil/pull/1979/commits/878eff9d51dfd42d5bc9f2b55a19ab8b314ca7f4 (usando rebase -i) foram publicadas aqui https://github.com/akretion/xsdata-odoo/commits/master
Sendo que teve 2 commits um pouco cosmeticos: um para evitar duplicates nos fields.Selection e um para melhorar os docstrings do enums mas que a mudança importante para suportar os attributos choice e xsd_choice_required dentro usando as informaçoes do xsd com xpath para completar os metadados extraidos pelo xsdata nativo foi feita nesse PR: https://github.com/akretion/xsdata-odoo/pull/6
cc @renatonlima @marcelsavegnago @felipemotter
rebase feito em cima da 14.0 (incluindo as melhorias com dup e pag com compute no l10n_br_account_nfe)
Mais documentação sobre como gerir os mixins da NFe usando xsdata-odoo: https://github.com/akretion/xsdata-odoo/blob/master/README.rst#generate-models
substituído por https://github.com/OCA/l10n-brazil/pull/2371 (eu conservei essa branch/PR aqui como référença caso a gente precisar)