OpenUpgrade icon indicating copy to clipboard operation
OpenUpgrade copied to clipboard

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

Open huguesdk opened this issue 1 year ago • 3 comments

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 avatar Oct 04 '24 08:10 huguesdk

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.

pedrobaeza avatar Dec 30 '24 19:12 pedrobaeza

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

huguesdk avatar Jan 06 '25 12:01 huguesdk

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

pedrobaeza avatar Mar 13 '25 07:03 pedrobaeza