Community mailing list archives

community@mail.odoo.com

Re: Return products and average cost

by
Martin Trigaux (mat)
- 01/16/2015 12:06:00
Hello,

Thank you all for your different replies.
However no solid proof (e.g. legal documents) could be shown that what we are doing is wrong and opinions are divided.
Fabien gave a clear example that a simple cancel of the incoming move was not working and could lead to a negative average price. The return computation is more complex than that (needs write-off entry but still not clear how).
We will still discuss this internally and we are open to the discussion but so far, we will keep the current behaviour.

Best regards,

Martin

On 12/01/15 09:43, Johan Bosma wrote:
<blockquote cite="mid:ema5291768-f676-4e86-a22b-6c9f9505c84e@johan-hp" type="cite">
Dear Yoshi,
 
In this case you will receive the items but at the moment of receiving you don't know the price.
You only know the price when you did receive the purchase invoice.
 
In many systems not the receiving is important for the average price calculation but the posting of the purchase invoice.
(Receiving items is a warehouse action)
 
Best regards,
 
 
 
Johan Bosma
Senior Consultant


Onestein B.V.
 
 
------ Origineel bericht ------
Van: "Yoshi Tashiro" <tashiro@roomsfor.hk>
Aan: "Community" <community@mail.odoo.com>
Verzonden: 10-1-2015 16:03:07
Onderwerp: RE: Return products and average cost
 
<BLOCKQUOTE class=cite2 cite=027d01d02ce5$9e7931a0$db6b94e0$@roomsfor.hk type="cite">

Here is some example from another ERP system I used to use (QAD).

 

The points are:

1) when the system knows which PO a return is done for, PO price would be used for journal items and stock valuation adjustment

2) in case the return amount is larger than the remaining stock valuation, the system would generate an inventory write-off record

 

I think SAP would also generate entries like these, but I cannot remember.

 

 

Step 1. PO Receipt (1st)








Price * Qty

Accounting Journal

Inventory Balance

Remarks

DR

CR

Unit Cost

Qty

Amount

0.2 * 1000

Inventory

200.00

PO Receipt

200.00

0.2

1000

200.00

 










Step 2. PO Receipt (2nd)








Price * Qty

Accounting Journal

Inventory Balance

Remarks

DR

CR

Unit Cost

Qty

Amount

0.8 * 1000

Inventory

800.00

PO Receipt

800.00

0.5

2000

1000.00

* Unit cost updated by moving average.










Step 3. SO Shipment








Cost * Qty

Accounting Journal

Inventory Balance

Remarks

DR

CR

Unit Cost

Qty

Amount

0.5 * -1000

COGS

500.00

Inventory

500.00

0.5

1000

500.00

 










Step 4. Purchase Return for #2 (1st)







Price * Qty

Accounting Journal

Inventory Balance

Remarks

DR

CR

Unit Cost

Qty

Amount

0.8 * -400

PO Receipt

320.00

Inventory

320.00

0.3

600

180.00

* PO price is used for inventory deduction.
* Unit cost updated by moving average.










Step 5. Purchase Return for #2 (2nd) - The case return amt > inventory amt



Price * Qty

Accounting Journal

Inventory Balance

Remarks

DR

CR

Unit Cost

Qty

Amount

0.8 * -400

PO Receipt

320.00

Inventory

320.00

0.8

200

160.00

* PO price is used to override the Unit Cost.

Inventory

300.00

Inventory Write-Off

300.00

* Posts the variance to Inventory Write-Off account.

 

 

----------------------------
Yoshi Tashiro

 

From: Ana Juaristi [mailto:ajuaristio@gmail.com]
Sent: Saturday, January 10, 2015 5:03 AM
To: Community
Subject: Re: Return products and average cost

 

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 cents

El 09/01/2015 19:19, "Nhomar Hernández" <nhomar@gmail.com> escribió:

 

2015-01-09 11:22 GMT-06:00 Christophe Hanon <chanon@adins.com>:

 

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 components

 

Post 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 5

 

We 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.

--

--------------------
Saludos Cordiales

 

Nhomar Hernandez

 

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


-- 
Martin Trigaux
Odoo (Formerly OpenERP)

Chaussée de Namur, 40
1367 Grand-Rosière
Tel: +32 81 81 37 00
http://odoo.com