[ADD] stock_account_move_line_valuation_restrict_price_change

[rousseldenis]

Follows: #1946

@gdgellatly @rov-adhoc

[gdgellatly]

@rousseldenis Happy to review, I must admit I have reviewed statically and I do not quite understand why we have this module. If I understand the issue that this PR and it's antecedent are solving it is the inability to reset to draft a supplier invoice if it created valuation layers. For me valuation layers are an unneeded materialisation which make things very complex (hence the behaviour we see in standard)

The reality is, due to the temporal nature between confirming and resetting the invoice and the complexity involved in knowing all intervening transactions, I honestly think the best resolution here is something like

• no preexisting layers created by invoice - as per normal (this is the default behaviour anyway)
• preexisting layers - I would add 2 journal items (per product line) taking the net change from presumably A/P accrual straight to COGS (or product price difference if you prefer). In this regard we have a sane behaviour. If someone already revalued correctly, P&L correct. If already sold through, P&L correct. When eventually sold through or revalued then P&L becomes correct. The presumption here is that 1. The amounts are immaterial from an accounting point of view, and 2. The requirement is relatively uncommon as a volume of total invoices. 3. In the case of major errors (which are more likely corrected anyway) then they can be manually corrected.

[rousseldenis]

@rousseldenis Happy to review, I must admit I have reviewed statically and I do not quite understand why we have this module. If I understand the issue that this PR and it's antecedent are solving it is the inability to reset to draft a supplier invoice if it created valuation layers. For me valuation layers are an unneeded materialisation which make things very complex (hence the behaviour we see in standard)

The reality is, due to the temporal nature between confirming and resetting the invoice and the complexity involved in knowing all intervening transactions, I honestly think the best resolution here is something like

• no preexisting layers created by invoice - as per normal (this is the default behaviour anyway)
• preexisting layers - I would add 2 journal items (per product line) taking the net change from presumably A/P accrual straight to COGS (or product price difference if you prefer). In this regard we have a sane behaviour. If someone already revalued correctly, P&L correct. If already sold through, P&L correct. When eventually sold through or revalued then P&L becomes correct. The presumption here is that 1. The amounts are immaterial from an accounting point of view, and 2. The requirement is relatively uncommon as a volume of total invoices. 3. In the case of major errors (which are more likely corrected anyway) then they can be manually corrected.

@gdgellatly In fact, the approach proposed by Tecnativa is more clean. OCA/account-invoicing#1813