[BUG] l10n_br_nfe: Erro ao validar XML autorizado, tag digVal

[antoniospneto]

Module

l10n_br_nfe

Describe the bug

O XML da NF-e após autorizado pela SEFAZ está sendo impresso/guardado no sistema com erro de validação.

Ao validar o XML autorizado no site https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx é apresentado o seguinte erro:

Schema XML: The 'http://www.portalfiscal.inf.br/nfe:digVal' element is invalid - The value 'b'4xSJC2uVdFFdAQ1FuICa30Rpis0='' is invalid according to its datatype 'http://www.w3.org/2000/09/xmldsig#:DigestValueType' - The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. Caminho: nfeProc/protNFe/infProt/digVal/

O problema é na tag digVal que faz parte do bloco de autorização retornado pela Sefaz após a autorização da emissão da nota. Aparentemente o valor dessa tag está sendo inserida com o parse incorreto, está sendo impressa no formato byte e não no formato string como deveria ser.

Onde está: <digVal>b'4xSJC2uVdFFdAQ1FuICa30Rpis0='</digVal> O Correto é: <digVal>4xSJC2uVdFFdAQ1FuICa30Rpis0=</digVal>

Foto do arquivo quando impresso pelo sistema Odoo:

Foto do arquivo quando baixado direto pelo Portal da NF-e:

To Reproduce

Versões Afetadas: 12.0, 14.0

Steps to reproduce the behavior:

1) Emita uma nota fiscal e envie para sefaz.

• você tem que está com o ambiente de homologação ou produção configurado. 2) baixe o xml e tente validar no site https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx

Expected behavior O xml teria que ser validado sem erros.

Additional context ainda não sei se o erro está relacionado a lib erpbrasil ou ao GenerateDS. pretendo investigar isso melhor em breve. Eu imagino que ninguém pegou o erro até agora porque poucas pessoas validam o xml após de emitido/autorizado pela Sefaz. Mas isso acontece tanto na versão 12.0 quanto na 14.0

[antoniospneto]

Pessoal eu achei a origem do bug é uma falha no generateDS mesmo.

Porém o mesmo já foi resolvido na lib: https://sourceforge.net/p/generateds/code/ci/7cf6f468bdb39ff3a09e3a06c74d78a2c3d432e8/

Added fix to ``gds_format_base64`` to convert value to be returned
from ``bytes`` to ``str``.  Thanks to JROC for reporting this and
for suggesting the fix.  See ticket #21 at SourceForge.

Acho que só tem que regerar os arquivos lá na nfelib utilizando uma versão recente do generateDS.

cc @rvalyi

[rvalyi]

parabéns pelo trabalho @antoniospneto .Olha essa de usar generateDS mais atualizado eu não tenho certeza, porque tipo um ano ou dois atrás eu tentei atualizar e teve regressões e eu tive que voltar umas revisões, coisa que acabou de me convencer que a mudança pro xsdata e o nível de test coverage que ele tem era mesmo a melhor opção (se bobear tá no histórico dos commits). Nessa altura do campeonato, tou esperando uma forcinha sua para ajustar novemente a transmissão da SEFAZ no meu PR de NF-e com xsdata e nesse meio tempo eu diria que tanto faz a forma como a gente resolve o bug na branch generateDS da nfelib.

[antoniospneto]

@rvalyi entendi, de fato melhor a gente focar na transição do XSDATA ;)

[antoniospneto]

resolvido no https://github.com/akretion/nfelib/pull/53

[rvalyi]

@antoniospneto eu publiquei o pacote 1.3.1 com o fix https://pypi.org/project/nfelib/1.3.1 Cuidado vai ser o ultimo pacote com os bindings generateDS do nosso lado, agora so xsdata mesmo a principio.

[antoniospneto]

Não sei o motivo ainda, mas esse bug voltou, vou analisar melhor depois.

[antoniospneto]

O bug agora só acontece no modo de transmissão sincrono, que antes não era possivel na localização. No modo sincrono o valor da tag digVal vem de outro schema, teria que aplicar a mesma correção feita aqui https://github.com/akretion/nfelib/pull/53 porém no arquivo v4_00/retEnviNFe.py

Ai teria que ver se vale a pena fazer a correção, pois isso ainda é generateDS, ai a correção teria que ser a partir da versão antiga da nfelib 2.0.7..