[14.0][IMP] l10n_br_fiscal_edi: add _document_qrcode() on _exec_before_SITUACAO_EDOC_A_ENVIAR method

[marcelsavegnago]

Incluindo no workflow a chamada ao metodo generico para geração do qrcode.

[rvalyi]

parece OK, mas me parece que a montagem do qrcode da NFCe deveria ser unificado com esse API. ver https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_nfe/models/document.py#L1227
Tou errado?

cc @antoniospneto @DiegoParadeda @mileo

[marcelsavegnago]

parece OK, mas me parece que a montagem do qrcode da NFCe deveria ser unificado com esse API. ver https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_nfe/models/document.py#L1227 Tou errado?

cc @antoniospneto @DiegoParadeda @mileo

Sim.. estava pensando nisso agora pouco.. vou ajustar nesta PR para o NFCe usar este document_qrcode

[marcelsavegnago]

ping @rvalyi b294aa9

[rvalyi]

eu posso estar enganado, mas me parece que seria melhor detonar o método _prepare_nfce_send e la no método _eletronic_document_send chamaria direitamente o _prepare_payments_for_nfce ficando assim:

    def _eletronic_document_send(self):
        super()._eletronic_document_send()
        for record in self.filtered(filter_processador_edoc_nfe):
            if record.xml_error_message:
                return  # Skip
            if record.state_edoc not in ["enviada", "a_enviar"]:
                return  # Skip
            if record.document_type == MODELO_FISCAL_NFCE:
                record._prepare_payments_for_nfce()
            if record.state_edoc == "enviada":
                record._nfe_consult_receipt()
            if record.state_edoc == "a_enviar":
                record._nfe_send_for_authorization()

Ou então conservando o método _prepare_nfce_send e botando o código do método _prepare_payments_for_nfce dentro dele.

Não sei dizer qual seria o melhor, mas eu queria apenas insistir que ter um método que fica apenas de 1 linha para chamar outro método é um tal de "leaky abstraction" que temos que evitar. Por isso inclusive que não é legal deixar iniciante mexer no código da OCA porque depois os API ficam tudo cagados de dar medo e tem que ficar mudando anos passando imagem de que a OCA não tem código estável. Sem falar que seria melhor "electronic_..." do que "eletronic_..." (em ingles) mas isso pode até ser tratado depois...

[marcelsavegnago]

Pessoal, estou separando o ajuste no l10n_br_fiscal_edi e o ajuste no modulo l10n_br_nfe. No caso da alteracao da geracao do qrcode do NFCE cai em um caso que nao tenho muito conhecimento para saber se esta certo ou nao. Aparantemente no update do documento para um documento de contingencia, ocorre alguma duplicacao.. nao sei se eh soh no teste mas seria melhor alguem da Kmee avaliar. Esta alteracao joguei na PR #3522 ..

cc @mileo @rvalyi @antoniospneto

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[rvalyi]

/ocabot merge patch

[OCA-git-bot]

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

[OCA-git-bot]

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