[14.0][l10n_br_nfe_spec][xsdata refactor]

[rvalyi]

work in progress: o modulo l10n_br_nfe_spec gerido pelo meu plugin xsdata-odoo em vez do generateds-odoo

Eu pretendo adaptar os testes logo. A ideia é voces podem se familiarizar com o codigo gerido pelo xsdata enquanto a gente vai testando bem a NFe com o xsdata...

Consideraçoes importantes:

• eu acho melhor mudar o caminho de models/v4_00 para models/v4_0. Assim se aparece uma NFe versao 4.0.1 ou 4.0.2, o codigo vai no mesmo lugar em vez da gente criar nova pasta ou numeração inconsistente (v4.0.1 no v4_00). Assim a ideia é a gente trocar a pasta apenas se aparecer uma nota versão 4.1 ou 4.2. Eu apliquei a mesma logica na branch xsdata-master do nfelib. Isso de conservar apenas 2 digitos para discriminar a versão tb é consistente com a escolha que fizemos nos prefix dos campos e das classes de NFe ontem temos apenas nfe40_ ou nfe.40.
• ao contrario do generateDS, o xsdata foi pensado para lidar com pacotes de varios XSD. Nisso é facil gerir os modelos abstratos para todos os arquivos de esquema de NFe (com generateDS não era, ia ter repetição de código de include). Importo apenas o leiaute por padrao, mas algum wizard ou arquivo num outro modulo poderia importar algum outro arquivo. Eh apenas por conta da geração dos outros arquivos que o modulo ficou umas 1700 linhas a mais.
• o arquivo principal é do leiaute da NFe. Antes com generateDS ele ficava assim https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_nfe_spec/models/v4_00/leiauteNFe.py e com o xsdata ele fica assim: https://github.com/akretion/l10n-brazil/blob/14.0-xsdata-l10n_br_nfe_spec/l10n_br_nfe_spec/models/v4_0/leiaute_nfe_v4_00.py ou seja um pouco mais "pythonico". Pode ser verififcado (e sera) que temos as mesmas classes com os mesmos campos.
• existe algumas vantagens do xsdata para esses arquivos spec, como essa adaptaçao para pacotes de varios xsd ou simplesmente o fato de tirar a dependencia ao generateDS, sendo que xsdata tem um codigo bem mais moderno e mais testado. Porem a maior vantagem da troca pelo xsdata vem das libs de "bindings". Esse refator da NFe vai junto com a branch xsdata do binding nfelib: https://github.com/akretion/nfelib/tree/master-xsdata Em particular pode se observar quanto mais DRY fica o arquivo principal de leiaute de NFe: https://github.com/akretion/nfelib/blob/master-xsdata/nfelib/nfe/v4_0/leiaute_nfe_v4_00.py comparando com o mesmo binding gerido pelo generateDS: https://raw.githubusercontent.com/akretion/nfelib/master_gen_v4_00/nfelib/v4_00/retEnviNFe.py (3x menos codigo e não tem repetição entre os arquivos). Em especial o codigo gerido pelo generateDS era tão indigesto que a gente separava a branch da fonte (master) da branch do codigo gerido, como se fosse um codigo compilado. Essa complexidade toda morre com o xsdata porque o codigo é super DRY e bastante estavel quando atualiza o xsdata.
• vale a pena estudar o examplo mais simples do PurchaseOrder.xsd da Micro$oft no PR do spec_model_driven/tests para ver como esses mixin estão usado depois https://github.com/OCA/l10n-brazil/pull/1977

[rvalyi]

@renatonlima @marcelsavegnago @netosjb o codigo do mixin gerido pelo xsdata-odoo ficou correcto agora. Eu vou mandar uns pushs no xsdata-odoo tb em breve, so organizando um pouco os commits...

[rvalyi]

pessoal eu fiz o push de 2 commits no https://github.com/akretion/xsdata-odoo sendo que ta usado assim para gerir os mixins da NFe https://github.com/akretion/xsdata-odoo/issues/1 Irei documentar melhor claro.

O maior probleminha que tem hoje é o controle do numero de linhas em branco no template jinja das classes https://github.com/akretion/xsdata-odoo/blob/master/xsdata_odoo/templates/class.jinja2

Pelo jeito da para ajustar mas eu ainda nao consegui fazer 100% para seguir os padrões da OCA a 100%. https://ttl255.com/jinja2-tutorial-part-3-whitespace-control/ quem conseguir dar uma força nisso ta bem vindo...

cc @marcelsavegnago @netosjb

[antoniospneto]

pessoal eu fiz o push de 2 commits no https://github.com/akretion/xsdata-odoo sendo que ta usado assim para gerir os mixins da NFe akretion/xsdata-odoo#1 Irei documentar melhor claro.

O maior probleminha que tem hoje é o controle do numero de linhas em branco no template jinja das classes https://github.com/akretion/xsdata-odoo/blob/master/xsdata_odoo/templates/class.jinja2

Pelo jeito da para ajustar mas eu ainda nao consegui fazer 100% para seguir os padrões da OCA a 100%. https://ttl255.com/jinja2-tutorial-part-3-whitespace-control/ quem conseguir dar uma força nisso ta bem vindo...

cc @marcelsavegnago @netosjb

@rvalyi e se por para rodar um pre-commit automaticamente após gerar o código será que já não resolve esse problemas de lint ?

[rvalyi]

Resolve claro. Porém o ideal é não ter que rodar formatação de código em cima de código gerido. Num primeiro momento podemos fazer isso caso a gente não consiga resolver agora.

[rvalyi]

@netosjb eu acabei resolvando a questão das linhas em branca aplicando o Black na geração pelo xsdata-odoo mesmo: https://github.com/akretion/xsdata-odoo/commit/64291862817f85d1a851e64c11cadc37662c121e

fiz o rebase tb.

Eu dei uma boa checada no codigo gerido pro leiaute da NFe para ver se tinha diferença com o codigo gerido pelo generateDS (a versão do schema é a mesma que temos na 14.0, deixei a atualização para um proximo PR).

A respeito dos mixins temos exactamente a mesma lista que é: https://gist.github.com/rvalyi/c330af297f459a93daf75e2aab62a45d (fiz grep -h -r "_name = " l10n_br_nfe_spec/models/v4_00/ | sort) o xsdata-odoo gera os mesmos mixin, a unica diferença é que temos " em vez de '.

A respeito dos campos, temos quase a mesma lista:

• generateds-odoo: https://gist.github.com/rvalyi/4c02e0aa59821d117880ef588f3596bf
• xsdata-odoo: https://gist.github.com/rvalyi/d3ca965396838a3193f5198e4c6cce4a

Observando no meld podemos ver as diferenças:

• o xsdata não gera campos choice. Isso ja sabiamos, a soluçao que decidimos é de copiar esses campos choice dos mixins gerido pelo generateDS onde for preciso. Nao passa de 10 campos.
• alguns campos mudaram de Monetary para Float. Isso na vdd é um erro no codigo gerido pelo generateds-odoo, pois minha deteçao de Float não tava perfeita (eu corrigi ontem no generateds-odoo). Isso não é muito grave porque o Monetary na vdd é um Float no Odoo. Mas enfim vai ficar melhor corrigindo para Float mesmo.

A lista desses campos que mudaram de Monetary para Float são:

• nfe40_qtde
• nfe40_qTotAnt
• nfe40_qTotGer
• nfe40_qTotMes
• nfe40_vUnCom
• nfe40_vUnTrib

Fora isso ta tudo igual certinho!

Por fim os testes ainda estão desativados no l10n_br_nfe_spec, mas eu ja publiquei uma versão xsdata do nfelib na mesma versção (atual) dos esquemas: https://pypi.org/project/nfelib-xsdata Esse pacote vai ajudar a adaptar os testes ate a gente decidir de trocar a branch principal do nfelib pro xsdata mesmo (talvez faremos isso na v12 um pouco depois de testar bem na v14).

cc @renatonlima @marcelsavegnago @felipemotter

Mesma coisa, já botei pronto para revisão mesmo se o merge devera occorer junto com o refator do modulo l10n_br_nfe.

[rvalyi]

@netosjb @felipemotter @marcelsavegnago @renatonlima agora com tests de importação usando a branch xsdata do nfelib tb! https://github.com/OCA/l10n-brazil/pull/1978/commits/cb0e24abfdbafb1aaf4879cacf107452ce077b06

[rvalyi]

fechando ja que o merge rolou aqui https://github.com/OCA/l10n-brazil/pull/2457