Created on 2018-03-27.15:41:59 by tbruyere, last changed 15 months ago by roundup-bot.
New changeset 28648e76e748 by Cédric Krier in branch 'default': Update cost of moves when recomputing product cost https://hg.tryton.org/tryton-env/rev/28648e76e748
New changeset 49eea85821ea by Cédric Krier in branch 'default': Update cost of moves when recomputing product cost https://hg.tryton.org/modules/stock/rev/49eea85821ea
New changeset e0fa1b9e2ce4 by Cédric Krier in branch 'default': Update cost of moves when recomputing product cost https://hg.tryton.org/modules/production/rev/e0fa1b9e2ce4
New changeset f3fcb65989bf by Cédric Krier in branch 'default': Update cost of moves when recomputing product cost https://hg.tryton.org/modules/product_cost_fifo/rev/f3fcb65989bf
This feature appears in this general proposal: https://discuss.tryton.org/t/update-re-computed-cost-price-on-moves/1802
>The transactional queue (if we have the funding)  may be a better alternative to the previous table. Yes, I think it would be the best way to recalculate the cost price. I hope this feature will be possible to develop. to be continued...
I think we need a more general design for the re-computation of the cost price of a product. I think we need to have a table which will store the product/company that need to be recomputed. This table will be filled by modules that changes stock moves after being done (like account_stock_landed_cost). Then we have a wizard (or a cron) that will re-compute the cost price for all those product and clear the table. The transactional queue (if we have the funding)  may be a better alternative to the previous table.  https://discuss.tryton.org/t/transactional-queue/461
I think it is necessary to group the products associated with the delivery treated by the "landing cost" to perform a "recompute" only on these products. List the products on the movements of the supplier shipment attached to the "landing cost", group by product, retrieve the calculation method according to the configuration of the product, start the recalculation of the cost price. I'm not sure this is the best method, but I have no other idea right now.
I do not think the cost price computation should be changed. Using stock period will just make the code more complex and error prone. I'm talking about a strategy to recompute the right products in an efficient way when landed cost has been applied.
>Have you a proposal to minimize the re-computation (because it is expensive)? Add a cost_price on stock period. The cost_price must be computed until a specific date (end of stock periode) -> move search domain should be extracted of the method to be updated. The compute_cost_price method should use the stock period with the quantity computed and the cost price of this quantity.
This is documented in http://hg.tryton.org/modules/account_stock_landed_cost/file/c8724dbd90ca/doc/index.rst#l24 So for me, it is not a bug but just a feature. Have you a proposal to minimize the re-computation (because it is expensive)?
Product cost price is not updated when landed cost are added on a supplier shipment. Recompute cost price method should be executed on all products involved by the moves. Problem : If you never call manually the recompute cost price wizard on the product, the landed cost will never impact the cost price. Linked to this issue : https://bugs.tryton.org/issue4729
|2020-01-26 16:21:48||roundup-bot||set||messages: + msg55051|
|2020-01-26 16:21:44||roundup-bot||set||messages: + msg55049|
|2020-01-26 16:21:40||roundup-bot||set||messages: + msg55047|
|2020-01-26 16:21:37||roundup-bot||set||status: testing -> resolved|
nosy: + roundup-bot
messages: + msg55045
|2020-01-08 15:03:06||reviewbot||set||messages: + msg54761|
|2019-12-05 18:37:00||reviewbot||set||messages: + msg54285|
|2019-12-05 17:55:54||reviewbot||set||messages: + msg54276|
|2019-12-05 11:38:24||reviewbot||set||messages: + msg54267|
|2019-11-22 19:38:07||reviewbot||set||messages: + msg53437|
|2019-11-13 12:02:19||reviewbot||set||messages: + msg53157|
Showing 10 items. Show all history (warning: this could be VERY long)