Community mailing list archives
Re: Return products and average costby
A - Have 1 product at 10 | - Valuation 10
From our side ++1 Fabien's and so Odoo's aproach. Outgoing do never change product cost
But now after reading other aproaches I doubt about returns. I see is different returning than outgoing.
One incoming picking should have incoming invoice, sameway returnig picking should have refund invoice so question is... Should refund invoices or return pickings recalculate someway product medium cost?
If yes... How? I don't see easy to do to obtain exact value.
I would like to know how other systems dial with this issue. I think it's more functional/conceptual issue to be solved more than technical one
My 2 centsEl 09/01/2015 19:19, "Nhomar Hernández" <email@example.com> escribió:2015-01-09 11:22 GMT-06:00 Christophe Hanon <firstname.lastname@example.org>:Other issues are also related to this, for example the current system works by processing deliveries sequentially, but sometimes due to a wrong encoding order, the price is again false.Actually I got it 'right' only one way, by having a recompute routine so corrections can be applied safely.THIS is a third scenario that Odoo has never understand is needed.We need is a recompute process which linking three components bring out thorught several ways audit process:Proposed Level:- Purchase Order (theoretical amount which is used to load the first valuation)Real Level:- Account Moves related.- Stock Moves.- Invoices.Then with this 3 componentsPost Mortem run a routine which analyse your inventories and make 2 options:1.- Report with inconcistencies impossibles to solve automatically (purchases after deliveries with negative temporal inventories).2.- Correction on Atock Move, Quants and Account Move related which can be done automatically.With everything related to pull and push and procurements now, this process is bringing A LOT of use cases which are not sequencials and the postmortem routine is becoming mandatory.But, again, Odoo must have the willing to design the process auditable and auto-fixable,About this specific case.Both are wrong.What Fabien is saying is worng is because it is "incomplete"Logistic Perspective | Accounting Perspective
- Have 1 product at 10 | - Valuation 10- Buy 1 product at 20 - ave: 15 | - Valuation 30- Deliver product at 15 - ave: 15 | - COGS 15 - Valuation 15- Return 1 product at 10 - ave: 15 | - Valuation 5, COGS stay in 15----- This is the extra postmortem step.- Fix the ave to 10 | - Fix account move at credit 5 on valuation debit 5 at COGS 5We are facing now this issue in a company with 10000 products, you can imagine the difficult process to audit, but then IMHO stock move - quants - sales orderds - purchase orders - invoices MUST be perfectly relationables and normalized models to be able to audit everything in an automatic way (which is not the case totalñly now they has some leaks of normalizations).I hope it helps!Regards.----------------------