## Rational

We have a wizard to re-compute cost price of a product (since the beginning). This wizard exists mainly for landed cost which update the price of incoming moves a posteriori.

The problem is that the cost price of the product is stored on the other moves at the effective date. So when the cost price value was changed in the past, the moves having this value are no more up to date.

This de-synchronization may affect reporting which compute the margin of the product sold.

Another point is that updating the cost of input production moves should trigger an update of the cost of outgoing moves.

## Proposal

We allow `recompute_cost_price`

to use a starting date. And when the cost price change between two dates, it update all the moves between those two dates with the initial cost price.

### Fixed

It simply updates all the moves from the start date to the new value.

### Average

It first takes the last cost price from the move just before the date as the starting cost price value. But as their may be multiple moves at the same date, it will take the mean of all the cost prices.

Then it start to compute the cost price for each further incoming moves (like it is currently done) but when the date is changing, it updates with the last average cost price computed, all the moves before this date and after the previous updated date.

### FIFO

We do the same as for average except for outgoing moves (from storage to non storage). In this case, we compute the stock quantity at the end of the day and the sum of outgoing move. We search the FIFO moves from this day and for the outgoing move quantities. We compute the average cost price of the FIFO moves picked and update the outgoing move of those days with it.

Those re-computations will not give always the exact same cost price as the one compute live.

But on average, the difference should be minimal. Also the live computation can also cheat by using a different effective date.

### Cascading

We add a date field (`MultiValue`

) on the product which stores the date of the older move which had its cost updated. So we have a general wizard which recompute the cost price for all product *modified* using this date and then the date is erased.

This wizard will also look at the productions done for which the input cost has been modified and it should reallocate the cost.

## Implementation

https://bugs.tryton.org/issue8795

https://bugs.tryton.org/issue7271

https://bugs.tryton.org/issue3209