Skip to content

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 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?

@pedrobaeza
Copy link
Member

I mean the records with their field values you have previous the migration and the result after for requiring this recomputation.

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]>
@huguesdk huguesdk force-pushed the 15.0-ou_fix-hr_expense_account_move_amounts branch from ab1834d to 52f5b5a Compare July 18, 2025 11:49
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 52f5b5a to 934b1b1 Compare July 18, 2025 13:44
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