search

OCA / l10n-brazil

Localização brasileira oficial do Odoo.
https://odoo-community.org/psc-teams/brazil-66
GNU Affero General Public License v3.0
231 stars 242 forks source link

[14.0][l10n_br_account_payment_order] teste test_payment_order_inbound.py inconsistente #3009

Open rvalyi opened 3 months ago

rvalyi commented 3 months ago

o teste odoo odoo.addons.l10n_br_account_payment_order.tests.test_payment_order_inbound roda de forma inconsistente. Com possível efeito colateral dos dados de demo do modulo l10n_br_account_payment_brcobranca.

Module

l10n_br_account_payment_order, talvez l10n_br_account_payment_brcobranca

Describe the bug

Por exemplo num PR trivial que era para passar a primeira tentativa deu esse erro:

ordem dos ultimos testes (l10n_br_account_payment_brcobranca foi carregado antes com dois dados de demo): l10n_br_pos_cfe l10n_br_pos_nfce l10n_br_product_contract l10n_br_purchase_request l10n_br_sale_blanket_order l10n_br_sale_commission l10n_br_sale_invoice_plan l10n_br_website_sale l10n_br_stock_account l10n_br_purchase_stock l10n_br_repair l10n_br_sale_stock l10n_br_stock_account_report l10n_br_delivery l10n_br_delivery_nfe l10n_br_website_sale_delivery l10n_br_cnpj_search l10n_br_portal l10n_br_ie_search l10n_br_account l10n_br_account_nfe l10n_br_account_payment_order

erro:

TestPaymentOrderInbound.test_create_payment_order ... 
2024-04-09 22:01:52,050 568 INFO odoo odoo.models.unlink: User #1 deleted account.payment.line records with IDs: [23] 
2024-04-09 22:01:52,055 568 INFO odoo odoo.models.unlink: User #1 deleted account.payment.line records with IDs: [24] 
2024-04-09 22:01:52,195 568 INFO odoo odoo.models.unlink: User #1 deleted ir.attachment records with IDs: [1110] 
2024-04-09 22:01:52,575 568 INFO odoo odoo.addons.l10n_br_account_payment_order.tests.test_payment_order_inbound: ====================================================================== 
2024-04-09 22:01:52,576 568 ERROR odoo odoo.addons.l10n_br_account_payment_order.tests.test_payment_order_inbound: FAIL: TestPaymentOrderInbound.test_create_payment_order
Traceback (most recent call last):
  File "/__w/l10n-brazil/l10n-brazil/l10n_br_account_payment_order/tests/test_payment_order_inbound.py", line 93, in test_create_payment_order
    self.assertEqual(
AssertionError: 'Teste Caixa Economica Federal CNAB240' != 'Teste Unicred CNAB401 - BRCobranca'
- Teste Caixa Economica Federal CNAB240
+ Teste Unicred CNAB401 - BRCobranca
 : Error with compute field journal_entry_ref

2024-04-09 22:01:52,579 568 INFO odoo odoo.addons.l10n_br_account_payment_order.tests.test_payment_order_inbound: Starting TestPaymentOrderInbound.test_payment_by_assign_outstanding_credit ...

log completo: https://github.com/OCA/l10n-brazil/actions/runs/8622722281/attempts/1?pr=3006

Porem ao tentar rodar os testes de novo sem alterar nada no código, rodou: https://github.com/OCA/l10n-brazil/actions/runs/8622722281/attempts/2?pr=3006

To Reproduce

Affected versions: 14.0 tem que ter sorte, ou analisar bem a diferença entre esse log: https://github.com/OCA/l10n-brazil/actions/runs/8622722281/attempts/1?pr=3006 e esse outro: https://github.com/OCA/l10n-brazil/actions/runs/8622722281/attempts/2?pr=3006

Expected behavior no heisenbug

Additional context Ta chato para caraio esses heisenbugs

cc @marcelsavegnago @mbcosta @antoniospneto

antoniospneto commented 3 months ago

eu venho reparando que essas sobreposições dos nomes nos modelos "account.move" dos dados de demostração não tá legal, acho que seria mais interessante deixar o odoo seguir a logica que tá configurado no sequenciador do diário do move.

Veja como tá os nomes hoje:

image

Se criar uma nova fatura, vai ver que o odoo vai puxar o nome da fatura anterior: image

Ali quando o teste falhou dá pra ver que o nome da fatura ficou Teste Unicred CNAB401 por ser 401 está claro que o sistema incrementou a partir do nome da ultima fatura registrada, certamente Teste Unicred CNAB400

Minha sugestão é remover todos esses nomes definidos estaticamente, e deixar o odoo gerar automaticamente, por exemplo INV/2024/001 e assim por diante.

marcos-mendez commented 3 months ago

Excelente idéia 👍

On Tue, Apr 9, 2024, 21:29 Antônio Neto @.***> wrote:

eu venho reparando que essas sobreposições dos nomes nos modelos "account.move" dos dados de demostração não tá legal, acho que seria mais interessante deixar o odoo seguir a logica que tá configurado no sequenciador do diário do move.

Veja como tá os nomes hoje:

image.png (view on web) https://github.com/OCA/l10n-brazil/assets/634278/4ee46378-ec0c-40d8-94ca-8200c6a2ae50

Se criar uma nova fatura, vai ver que o odoo vai puxar o nome da fatura anterior: image.png (view on web) https://github.com/OCA/l10n-brazil/assets/634278/2cfc6c01-d5cf-48fa-b5d2-1d8c590a79f9

Ali quando o teste falhou dá pra ver que o nome da fatura ficou Teste Unicred CNAB401 por ser 401 está claro que o sistema incrementou a partir do nome da ultima fatura registrada, certamente Teste Unicred CNAB400

Minha sugestão é remover todos esses nomes definidos estaticamente, e deixar o odoo gerar automaticamente, por exemplo INV/2024/001 e assim por diante.

— Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/issues/3009#issuecomment-2046243861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEVVIBXN6FPJ4D4ZZ3NRSLY4SBVDAVCNFSM6AAAAABF7NHUBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBWGI2DGOBWGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

rvalyi commented 3 months ago

@antoniospneto é que o nome deve ajudar a saber o tipo de registro de demo que vc quer mostrar. Vc enxerga alguma solução para continuar com o tipo de boleto/CNAB explicito mas sem atrapalhar na numeração? obs: isso tb da numeração automatica a partir do nome é algo que mudou na v14.

mileo commented 3 months ago

image

mileo commented 3 months ago

o campo ref pode servir bem pra isso.

antoniospneto commented 3 months ago

@rvalyi

É que eu acho esses dados no fim nem são tão uteis para demostração, eu acho que a maior parte poderia estar sendo criado em uma classe common de testes

mbcosta commented 3 months ago

@rvalyi preciso olhar melhor esse erro, mas da última vez que investiguei isso era causado por esse campo compute do LOG journal_entry_ref https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_order/models/account_move_line.py#L136 procurei ver onde esse campo poderia estar sendo usado mas olhando superficialmente não encontrei, talvez tenha algum uso, isso veio da extração e foi mantido para evitar incompatibilidades, talvez o pessoal da KMEE @mileo saibam ou podem dizer se isso ainda está sendo usado ou se é necessário em algo, eu estava vendo de simplesmente remover o campo e o compute mas também é possível apenas comentar o teste https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_order/tests/test_payment_order_inbound.py#L93 com um TODO, vai reduzir um pouco o coverage mas o erro deve deixa de acontecer

rvalyi commented 3 months ago

@rvalyi preciso olhar melhor esse erro, mas da última vez que investiguei isso era causado por esse campo compute do LOG journal_entry_ref https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_order/models/account_move_line.py#L136 procurei ver onde esse campo poderia estar sendo usado mas olhando superficialmente não encontrei, talvez tenha algum uso, isso veio da extração e foi mantido para evitar incompatibilidades, talvez o pessoal da KMEE @mileo saibam ou podem dizer se isso ainda está sendo usado ou se é necessário em algo, eu estava vendo de simplesmente remover o campo e o compute

@mbcosta eu olhei o git blame dessas linhas é isso é apenas um mais um troll do passado que a gente ta carregando no codebase até agora. O pessoal da Kmee eu acho que nem ta usando o modulo ou apenas tentando usar com o brcobranca como usamos. Nisso eu diria que pode remover sem pena.

mbcosta commented 3 months ago

valeu @rvalyi fiz um PR https://github.com/OCA/l10n-brazil/pull/3056 removendo o campo