[14.0][l10n_br_cte_spec] leiautes abstratos para Conhecimento de Transporte electrónico (CT-e) versão 4.00

[rvalyi]

Este módulo inclui os principais leiautes persistentes de CT-e, o código é gerido a partir dos esquemas versão 4.00 da CT-e pelo xsdata-odoo

Se trata de uma atualização deste PR #2475 com a versão 4.00 do CT-e e atualização do xsdata-odoo para funcionar perfeitamente com os esquemas da CT-e.

• CT-e (Conhecimento de Transporte Eletrônico)
• CT-e OS (Conhecimento de transporte eletrônico para outros serviços)

(eu removi a GVT-e (Guia de Transporte de Valores Eletrônica) deste módulo)

O xsdata-odoo foi adaptado para lidar com as tags com o mesmo nome mas em hierarquia diferentes (por examplo infCTe dentro de CTe, CTeOS...) e agora a geração funcionou perfeitamente. O teste esta importando uma CTe criando uma arvore de mixins Odoo abstratos.

[ygcarvalh]

Acho que essa definição de classe tinha entrado no ponto de algo que era comum tanto para a CT-e e a CT-e OS que você tinha comentado. Mas nesse caso, não ter um campo implementado não gera algum problema? Digo isso por conta de um erro que estava dando quando eu tentava implementar o módulo l10n_br_cte. Ele quebrava a iteração no método register_hook por conta dessa falta de campos.

[rvalyi]

Ola @ygcarvalh eu não tenho certeza se eu entendi. Mas eu acho que esta correto: como vc pode verificar na nfelib, a CTe e a CTeOS tem tags de impostos diferentes, respetivamente:

Ai depois a questão desse objeto m2o Timp e TimpOS vir vazio é a mesma parada do que no l10n_br_nfe_spec: ja que os mapping dos impostos vai precisar ser adaptado 100% fica inutil gerir classes para cada impostos, e eu filtrei a geração dessas classes com a variavel de ambiente antes do export:

  export XSDATA_SCHEMA=cte; export XSDATA_VERSION=40; export XSDATA_SKIP="^ICMS\d+|^ICMSSN+|ICMSOutraUF|ICMSUFFim"; export XSDATA_LANG="portuguese"
  xsdata generate nfelib/cte/schemas/v4_0 --package nfelib.cte.odoo.v4_0 --output=odoo

E ai para mapear os impostos vai ter que fazer o mesmo tipo de coisa do que no l10n_br_nfe.
Ta OK para vc, mas alguma duvida?

[rvalyi]

agora tem 2 sutilezas com a CTe que vc precisa verificar se não precisa de alguma adaptação no spec_driven_model.

1. ja que tem tag com o mesmo nome em hierarquia diferente, uma vez que a gente tem o nome da Class do binding nfelib (num import por examplo), não é trivial pegar o nome do mixin Odoo correspondante. Isso porque para ter um nome de mixin Odoo de um tamanho razoavel, eu fico recortando o nome da class nfelib completa (nested) verificando até onde da par recortar sem criar modelos duplicados. Nisso tem que fazer um loop para pegar a modelo que tem o _binding_type que bate. Veja aqui no teste de importação https://github.com/OCA/l10n-brazil/pull/2596/files/b9e2e1ece18f3e9ea64c5256b1287822270a872c#diff-02711529806d6012db7f9c08a65901dcd3123926a9ddb87e67fbd5527da0095fR75
   Talvez a gente vai precisar fazer o mesmo tipo de loop aqui https://github.com/OCA/l10n-brazil/blob/14.0/spec_driven_model/models/spec_import.py#L165

2. na geração do nfelib/cte, eu tive que fazer essas 4 substituções porque senão o xsdata quebrava com a opção originalCase quando o nome de um attributos tinha o mesmo nome do que uma tag: https://github.com/akretion/nfelib/blob/master/.xsdata.xml#L60
   Ai na hora de montar a chave do binding eu preciso pegar o nome do campo: https://github.com/OCA/l10n-brazil/pull/2596/files/b9e2e1ece18f3e9ea64c5256b1287822270a872c#diff-02711529806d6012db7f9c08a65901dcd3123926a9ddb87e67fbd5527da0095fR43
   E com a nfe eu fazia algo diferente: https://github.com/OCA/l10n-brazil/blob/14.0/spec_driven_model/models/spec_import.py#L76
   provavelmente vai ter que adaptar o spec_model_driven aqui tb.

cc @renatonlima @marcelsavegnago @antoniospneto @felipemotter

[ygcarvalh]

Oi, @rvalyi. No caso minha dúvida estava com um problema relacionado ao looping durante o registro do hook (https://github.com/OCA/l10n-brazil/blob/14.0/spec_driven_model/hooks.py#L154). Mas acho que entendi sobre a necessidade de adaptar o spec_driven_model.

É porque, caso não tenha um campo, ele vai parar a iteração nesse ponto e não instala o módulo, apesar de ter instalado o _spec e acusa um erro (imagem a seguir). Eu consegui contornar sem mexer no spec_driven apenas comentando a definição da classe para ter certeza de que estava tudo certo com o protótipo do módulo.

Vou tentar pensar em alguma melhoria para casos assim.

[ygcarvalh]

Eu estava dando uma comparada nos três tipos de documentos dentro da CT-e (CT-e, OS e GTV) e percebi uma coisa. Aparentemente, a OS e a GTV possuem os mesmos campos que tem na CT-e, e mesmo os campos que não tem, estão dentro do agrupamento original. Não seria melhor ter uma única classe (por exemplo, class TcteIde) que estaria envolvendo todos os campos e subgrupos? Acho que diminuiria a quantidade de classes/código dentro do arquivo e o esforço pra eventuais manutenções.

[rvalyi]

Ola @ygcarvalh
Eu não entendi bem a parte "e mesmo os campos que não tem, estão dentro do agrupamento original." Pode ser mais especifico e dar exemplos por favor?
Se for o caso dos mixins da CTe ser suficiente, a gente poderia considerar. E se for divergir um dia de repente a gente separaria de novo. Seria possível dentro do Odoo ou do nfelib customizar para que uma tag interna tivesse um nome diferente de acordo com um contexto de serialização/leitura.

[ygcarvalh]

@rvalyi por exemplo. No layout da CT-e, quando olhamos a tag compl. Ao olharmos a forma como ela está na documentação, temos que, por exemplo, no modelo 57 (CT-e) ela tem os seguintes campos:

Para o modelo 67 (CT-e OS), nós temos:

E para o modelo 64 (GTV), temos:

Na definição das classes, você colocou uma para a CT-e (https://github.com/akretion/l10n-brazil/blob/14.0-add-l10n_br_cte_spec4/l10n_br_cte_spec/models/v4_0/cte_tipos_basico_v4_00.py#L3638), outra para a CT-e OS (https://github.com/akretion/l10n-brazil/blob/14.0-add-l10n_br_cte_spec4/l10n_br_cte_spec/models/v4_0/cte_tipos_basico_v4_00.py#L1362) e outra para a GTV (https://github.com/akretion/l10n-brazil/blob/14.0-add-l10n_br_cte_spec4/l10n_br_cte_spec/models/v4_0/cte_tipos_basico_v4_00.py#L2482).

Nesse caso, temos os mesmos campos, o que eles vão alterar são alguns grupos dentro dessa tag compl. Por exemplo, na CT-e (57) temos o grupo fluxo e entrega, que não temos na CT-e OS (67) ou na GTV (64). Mas temos, em comum o grupo ObsCont e ObsFisco.

A ideia que eu tive de implementação pegaria uma definição de classe mais genérica no spec, como no exemplo abaixo. Dessa forma, no Odoo podemos preencher certas informações baseadas no modelo com algum método computado.

class TcteCompl(models.AbstractModel):
    [...]
    
    cte40_xCaracAd = fields.Char(
        string="Característica adicional do transporte",
        help=(
            "Característica adicional do transporte\nTexto livre:\nREENTREGA; "
            "DEVOLUÇÃO; REFATURAMENTO; etc"
        ),
    )

   cte40_fluxo = fields.Many2one(
        comodel_name="cte.40.fluxo",
        string="Previsão do fluxo da carga",
        help=(
            "Previsão do fluxo da carga\nPreenchimento obrigatório para o "
            "modal aéreo."
        ),
    )

   cte40_obsCont = fields.One2many(
        "cte.40.tcte_obscont",
        "cte40_ObsCont_compl_id",
        string="Campo de uso livre do contribuinte",
        help=(
            "Campo de uso livre do contribuinte\nInformar o nome do campo no "
            "atributo xCampo e o conteúdo do campo no XTexto"
        ),
    )

O que você acha?

[rvalyi]

Eu não sei muito bem dizer @ygcarvalh . Eu acho que teria que ir pototipando as coisas para ver melhor...

Pois de um lado parece economizar codigo, por outro lado, boa parte deste codigo ja esta sendo gerido automaticamente. Na hora de gerir, tanto para os bindings nfelib, tanto os mixins Odoo, a gente não pode introduzir muita logica na geração pois iria complicar a logica sistematica do gerador com algumas peculiaridades de tal ou tal esquema. eu diria que seria "premature optimization" ou "overengineering". Enfim interferir na hora de geração eu diria que não pode. No maximo filtrar algumas classes, assim como eu fiz para as class do xmldsig ou dos impostos.

Agora dentro do mapping nos overrides do l10n_br_cte ai sim ja da para introduzir alguma inteligencia. Ai teria que ver um pouco com seus prototipos o que fica melhor, eu não consigo avaliar muito nesta hora. Me parece que a MDF-e é mais facil se quiser começar pela MDFe. Outra coisa, é importante mapear o l10n_br_fiscal.document.line, me parece que vc ainda não mapeou ele, mas é bem importante. No caso destes novos documentos ficais é como se fosse um documento fiscal de uma so linha l10n_br_fiscal.document.line, mas ainda assim da para mapear.

[rvalyi]

conforme o retorno do KMEE até agora com o módulo l10n_br_cte_spec ( #2586 (comment) ) vou fazer o merge então, OK?

[rvalyi]

/ocabot merge nobump

[OCA-git-bot]

On my way to merge this fine PR!
Prepared branch 14.0-ocabot-merge-pr-2596-by-rvalyi-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 07231e1. Thanks a lot for contributing to OCA. ❤️