-
-
Notifications
You must be signed in to change notification settings - Fork 759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[17.0][FIX] account_move_template: Fixed tax and payment term errors while generating journal entries from template #1930
[17.0][FIX] account_move_template: Fixed tax and payment term errors while generating journal entries from template #1930
Conversation
Fix for module account_move_template 17.0 cc https://github.com/APSL 160052 @miquelalzanillas @lbarry-apsl @mpascuall @peluko00 @javierobcn @BernatObrador please review |
I found this error with a template that have payment term:
Without it works good! |
Thank you for pointing this out @peluko00! Hi @pedrobaeza, my name is Patryk and I work for APSL. I was checking this error related to the payment terms and it seems that it was already happening in the version 16, just checked in the runboat. The method used earlier to compute the payment terms has seen major changes, as seen on the following link: odoo/odoo@d9057e3?diff=split&w=0#diff-1082eea1e176daccb75f95f20dbfed8f869328635fd041c2f6d6d082f5f05563L74 I'm guessing that all of the new parameters needed in the method call are intended to work with the account.move model, as it contains all of the needed fields: https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_move.py#L416. My proposition to resolve this error would be to delete the payment terms from this module. My reasoning for this conclusion is that we are generating journal entries, not invoices, therefore, the payment terms shouldn't be needed on each individual journal item. Would love to hear what you think about this issue, thank you in advance! |
Well, I don't use this module, so I don't know the original intention of adding the payment term management in it. Your proposal seems reasonable, but it would be good that you blame the code to check which contributor added that code, and maybe discover the reason if they documented correctly, or ask them for details. |
…generating journal entries from template
Thank you for the feedback @pedrobaeza. Searching through existing PR's I found this one already solving the problem: #1892 (with this related issue #1891). I reached out to the author of the PR, but I haven't received a response. Therefore, I will cherry-pick that commit and supersede the mentioned PR. |
0618c58
to
8daf28c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM tested in runboat
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, good work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Hi @pedrobaeza, sorry for ping directly, could you please ask maintainers if they can review and merge this PR? Thank you! |
@@ -182,7 +182,7 @@ class AccountMoveTemplateLine(models.Model): | |||
@api.depends("is_refund", "account_id", "tax_line_id") | |||
def _compute_tax_repartition_line_id(self): | |||
for record in self.filtered(lambda x: x.account_id and x.tax_line_id): | |||
tax_repartition = "refund_tax_id" if record.is_refund else "invoice_tax_id" | |||
tax_repartition = "tax_id" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why removing the refund part?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed it as both the invoice_tax_id and refund_tax_id fields were merged into the tax_id field, as seen in the following PR: odoo/odoo@e41f2f7#diff-1ee3fce434db0c4e897973eebf5c1be501196cbd413e6c250ecc973238f939b9L1247
/ocabot merge patch |
Hey, thanks for contributing! Proceeding to merge this for you. |
Congratulations, your PR was merged at 2af6e46. Thanks a lot for contributing to OCA. ❤️ |
While trying to create journal entries from a template (Accounting > Configuration > Journal Entry Templates) with an assigned tax amount we encounter the following error related to the invoice_tax_id field:
"ValueError: Invalid field account.tax.repartition.line.invoice_tax_id in leaf ('invoice_tax_id', 'in', [1])"
The same error occurs with the refund_tax_id field if we check the "Is a refund?" checkbox on one of the lines:
ValueError: Invalid field account.tax.repartition.line.refund_tax_id in leaf ('refund_tax_id', 'in', [1])
These errors are due to changes made in the Odoo core code, where both the invoice_tax_id and refund_tax_id fields were merged into the tax_id field, as seen in the following PR: odoo/odoo@e41f2f7#diff-1ee3fce434db0c4e897973eebf5c1be501196cbd413e6c250ecc973238f939b9L1243
Therefore, this PR replaces the obsolete fields with the correct tax_id field and removes the unnecessary is_refund field.