Skip to content
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

[15.0][OU-FIX] fix hr.expense account.move and lines #4577

Open
wants to merge 2 commits into
base: 15.0
Choose a base branch
from

Conversation

huguesdk
Copy link
Member

@huguesdk huguesdk commented Oct 4, 2024

fix the value of several fields on account.move and account.move.line records linked to hr.expense records.

this computes account.move.line.exclude_from_invoice_tab differently than #4386 did. the goal remains the same: it should be true for destination lines. the code was assuming that destination lines where the ones with a quantity of 0, but this does not work, as odoo 14 does not set a quantity on those lines and the default value for this field is 1. instead, this field is computed by checking that the account is of type "payable".

with exclude_from_invoice_tab correctly set, it is now safe to call account.move._compute_amount() to correctly recompute several fields (always_tax_exigible, amount_residual, amount_residual_signed, amount_untaxed, amount_untaxed_signed, payment_state) of the account.move without changing accounting data. account.move.write() checks that reconciled moves are not changed, and with this code, it succeeds.

this code also recomputes these fields for account.move records not directly linked to hr.expense.sheet records, but linked to an hr.expense record through their account.move.line records, since this is how account.move._payment_state_matters() selects the records.

huguesdk and others added 2 commits December 20, 2024 13:15
fix the value of several fields on account.move and account.move.line
records linked to hr.expense records.

Co-authored-by: Miquel Raïch <[email protected]>
fiscalyear_lock_date check prevent modifying old move, but some field
should be recomputed to be correct in 15.0.
@huguesdk huguesdk force-pushed the 15.0-ou_fix-hr_expense_account_move_amounts branch from 06a9b31 to ab1834d Compare December 20, 2024 12:16
@pedrobaeza
Copy link
Member

I need why this is needed with an example dataset that fails previously. In general, I don't want to call the general method _compute_amount, which can have lots of side effects.

@huguesdk
Copy link
Member Author

huguesdk commented Jan 6, 2025

@pedrobaeza could you tell me in which form this dataset should be presented?

about _compute_amount(), since these are (read-only) computed fields, isn’t it supposed to be a model invariant that the fields should be able to be recomputed at any time if any of their dependencies have changed (or not)? if calling this method results in incorrect data, it means that there is a problem elsewhere. i see the fact of being able to call the compute method more as a safety check, actually. also, what would be the point of (possibly incorrectly) recomputing all of these fields with custom code here while the compute method already exists and does it correctly? what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants