[stock] returned products from customers have cost price of the day instead of historical cost price

I think it would be better to store it in the packing list because if the sale is confirmed and the product is delivered later, the cost price may have change if other products have been received from supplier

btw, in the case we want to have a margin control calculated on the invoices (or tickets with POS), it should also be stored in the invoice line (or ticket line with POS)

I think...
IMHO
In anglo Saxon accounting... should be saved on invoice. and rhine
accounting should be in packing...

Regards

2010/8/5 invitu <email address hidden>

> btw, in the case we want to have a margin control calculated on the
> invoices (or tickets with POS), it should also be stored in the invoice
> line (or ticket line with POS)
>
> --
> [5.0 - stock] returned products from customers have price = 0
> https://bugs.launchpad.net/bugs/613286
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Addons.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> When we return products from customers, the average price is updated with
> incoming products that have price = 0
>
> Steps to reproduce :
> - choose a "Outgoing Products" pack
> - launch the "Return Packing" wizard --> a "Packing List" is created in
> "Available" state and is automatically opened
> - click on "Validate" button --> the "Make Packing" wizard proposes to get
> the products in stock with Unit Price = 0 and no currency.
>
> What we need :
> When a sale is made, the cost price should be stored in order to be used if
> the product is returned.
>
> The wizard should at least take the cost price from product when the
> product is returned but it would be better to take the cost price at the
> time when the product was sold.
>
>
>

--
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
+58-212-6615932
+58-212-9536734 ext 124
+58-212-9512643
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://openerp.netquatro.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>

Hello. I'm with Invitu.

I marked this as a high importance, because is a hidden problem we have recalculated the cost for 6 month because in the audit proccess we saw that there are no relation and no record.

Regards.....

I ask if this bug should be updated as "critical" because each time a customer returns a product, it changes the average price.
Regards

If somebody else approve this i can change this.....

Regards.

Hello

OpenERP sa has sent us a patch that picks the cost price in the product (for 5.0.12)
The currency is still not set as default. It should be set with the company's currency.

Regards

The fix has landed in 5.0 in time for 5.0.14:
revno: 2835 <email address hidden>

This fix is already ported to trunk/6.0, it will be merged soon:
revno: 3677 <email address hidden>

@invitu:
Thanks a lot for the report and the follow-up!

You are right about the currency, but we preferred to not set it by default because it could cause more insidious issues (harder to spot than having the cost at 0!), and it's not as simple as it seems.
When there is a corresponding PO or SO the correct currency is set on the pricelist that was used, so that's easy and we select it.
But there is no 100% correct way to be sure to select the correct currency without a PO or SO, especially when working in multi-currency or multi-company.
There are several companies involved and as many potential different currencies: the company of the current user or the company of the picking, or the company of the product, etc.: all could be different and have different currencies.

So in that case we prefer to force an explicit choice to be sure there is no possible mistake.

Hello Olivier

I think that average product price should always be in company's main currency. We don't care in which currency the product has been sold because we talk about cost price... The problem would appear if a company works with different cost price currencies depending on the product... I don't think anybody would do this.
For multi-company application where companies work with different main currencies, it should be set to the company's currency.
Am I wrong ?

BTW, I strongly advice that cost price should be stored in invoices and packing lists to be tracked and to have right margins (i.e. https://bugs.launchpad.net/openobject-addons/+bug/610738). I don't know any software that don't do that, it's basic stuff.

Regards

Bug is present in 6.0 too !

Sorry I change the status to "New", because Incomplete means that the bug is not well explained.

regards.

Hello,

I think you are right, when receiving products back from a customer, the proposed price must be the current average price. I assign this to a developer.

Sorry.

"Not the current cost"

The "Cost used in the original transaction"

This error is the same explained several times......

Sorry for my insist actitud.

We need a field on picking telling "cost was on product at this time"

Hello Experts,

Working with the latest code, I do not see any error.
I would be interested to know the steps to meet the error and fix it asap.

Thanks.

I confirm,
[trunk]
excluding the fact of 2 bugs related with this procedure are happening it is working.

1.- Impossible validate the return by line https://bugs.launchpad.net/openobject-addons/+bug/660039
2.- Is take the "current cost" not the "cost used on original transaction" http://pad.openerp.com/6-test-purchases

regards

@Fabien:
The issue with the default value being 0 has been solved some time ago, and is still fixed, I just checked.
The bug was reopened for unclear reasons.

@invitu:
You did not address the issue I explained in comment #9. There is no 'main company' in multi-company setups, so again, there could be different companies to consider. And since the currency of the 'cost price' is the main currency of the company the product belongs to, you only need multiple companies with different currencies to get in trouble.

Would you also care to explain why you reopened the bug stating it affects v6? The fix is commited in v5 AND v6, and has been merged in official addons (v6) since my last comment.

@Nhomar
Hold your horses ;-) The 'cost price' of the product at the time it was sent to the customer may not be relevant anymore when the product is returned from the customer. It could be 1 year later, and you don't want to compute an incorrect average price based on that. As there is no better value we must use the current average cost of the product as default... the user is free to change that value manually anyway.

@All
Keep in mind that we are only discussing the default value for a field in the Picking wizard, nothing else (hence the bug priority!), and the logistics officer is supposed to verify this properly every time!

Reminder: if you have doubts about bugs and severities, please refresh your memories here: http://doc.openerp.com/contribute/15_guidelines/contribution_guidelines.html#definition-of-a-bug :-)

>
> @invitu:
> You did not address the issue I explained in comment #9. There is no 'main
> company' in multi-company setups, so again, there could be different
> companies to consider. And since the currency of the 'cost price' is the
> main currency of the company the product belongs to, you only need multiple
> companies with different currencies to get in trouble.
>
> Would you also care to explain why you reopened the bug stating it
> affects v6? The fix is commited in v5 AND v6, and has been merged in
> official addons (v6) since my last comment.
>
> @Nhomar
> Hold your horses ;-) The 'cost price' of the product at the time it was
> sent to the customer may not be relevant anymore when the product is
> returned from the customer. It could be 1 year later, and you don't want to
> compute an incorrect average price based on that. As there is no better
> value we must use the current average cost of the product as default... the
> user is free to change that value manually anyway.
>

@odony

Jeje. Ok, i will go i little more slow, ;-)
You are wrong friend... You should overvalue the Item returned to the last
cost this is called LIFO (with average cost) and is not permited in almost
all countries because you are having profitability for a returned item and
is Illegal.

If you sell to a customer, and this product is back to your stock the cost
for this Item is the cost "when" it was sold not actual cost, even it _must_
change your inventory cost per unit, obviously, if you have 1.000.000 of
items in stock of this product the repercution is not watchable, but, if yo
are in a so dynamic (as at least the half of the world) economy and you sell
very expensive products you will look this in the same time you do the
return.

In several countries and in several cases what a return is done with so long
delay it is sent to "scrap" to avoid affect revaluation for the real stock,
but _even_ in scrap you are lossing the "original cost" not the "new one",
when you give to a customer a _new product_ with the _new cost_ the
difference between scrap and stock will give you the real difference of
losses in this refered period.

I know is too complicated even for us explain this in spanish, I only ask
for something simple _record the cost in the transaction out of the box_
pleeeease.

BTW, I don't understand "why" is than dificult accept this issue, whatever
book around costing say this as an "obvius" feature for calculation.

"Every return most be done with his cost in te moment of the transaction"

Incoming by purchase -- cost? price of purchase. -- recalculate cost? YES
Incoming by return --- cost? cost used in sold. -- recalculate cost? YES
Outgoing by sold --- Cost? cost in product --- recalculate? NO
Outgoing by return a purchase -- Cost? original price what it was purchased
--- recalculate? YES

Please some accountant that help us to understand this in a better way....
!!!!!!!!!!!

I preparing a YAML test to be more clear but in the pad (
http://pad.openerp.com/6-test-purchases) i posted an "ods" file with
mathematical example. Is easy make in this file an analysis around this
issue.

@All

Sorry for be so excited around this, but, my examples are rel...

2010/10/13 Olivier Dony (OpenERP) <email address hidden>

> Reminder: if you have doubts about bugs and severities, please refresh
> your memories here:
>
> http://doc.openerp.com/contribute/15_guidelines/contribution_guidelines.html
> #definition-of-a-bug :-)
>
Do you remember we were woking together on this guidelines on the workshop?
;-)
Well,
*Critical*: security issue (e.g. system compromised or arbitrary code
execution possible), or system completely unusable, for many users. Any kind
of data loss.
Any kind of data loss.

> --

If we don't record the cost in the transaction and overwrite with a future
move the cost on the product we are "lossing data" for an unsecure
implementation of code excecuted, or not?

.....
regards.

Sorry, my comment #11 is very light. The reason why I reopened the bug is that I tested it with V6.0 with an install from scratch.
I will retest it today to check it again.

@olivier#9 :
For updating the average cost price of a product that is returned by a customer, we don't care in which currency the SO has been made because we are talking about cost price and not sale price. BTW, PO are not concerned here.

@olivier#17 :
(We agree that we don't have main company but several companies.) I just said the currency for a returning product from customer should be set to the company's currency to which the product belong and for which the sale has been made. We should take the currency of the company for which the return is done. Could you clarify why you see a problem if we have multi-companies with multi currencies ?

To your comment "Keep in mind that we are only discussing the default value for a field in the Picking wizard, nothing else (hence the bug priority!), and the logistics officer is supposed to verify this properly every time!", here is my answer :
It is very hard (not possible) to find the cost price of the product when it has been sold if you don't record it somewhere. The logistics officer should be stuck for a long time... That's why I totally agree with Nhomar, I think the solution is to record the cost price in the output picking. (@Fabien : we keep it simple and moreover, we make it right.)

To sum up the bug :
In stock_return_picking.py,
- The cost price for returned products should be set to the cost price at the time when the product was sold to the customer. (I would add to not let it be modified by the operator)
- The currency for the returned product should be set to the currency of the company for which the return is done (I would add to not let it be modified by the operator)
Nhomar suggested that the return could be done to another stock (ie. scrap). For me, this feature should be implemented in stock_return_picking.py and not in stock_partial_picking.py.

I don't know any company that would accept a product back after 1 year. Usually and depending on the country, it is several days (France = 7 days for B2C sales)

Sorry for my poor english, @Olivier, I will send you a private email in French and we could discuss this on the phone

Thank you for your explanations Nhomar and Invitu, I understand better what you mean now! :-)

If we want to keep things simple, in line with what Fabien suggested on bug 610738, why do you think it would not be possible to do this in a module if the core stock module does not record the cost?
An additional module could add the required fields on stock.move, inherit the method that marks a stock.move as done (or the method that creates the whole picking in sale.order if you want the cost at the time of the sale) to record this value, and then inherit the stock wizards to suggest this value when it is relevant.
This is partially what the purchase module does at the moment in trunk to provide the actual purchase price of the product in the partial picking wizard for products with average cost enabled.

@invitu: the above should also take care of the currency and perhaps store it, so there is no question for determining it in that case. Without the above we still have an issue because the product cost on the product is expressed in the currency of the product's company, regardless of the company to which the move belongs to. The simplest is to always provide it in the currency of the product's company, and do the appropriate currency conversions if needed when using this value for other companies (like posting the corresponding accounting entries... but usually there will be no conversion to make as both companies will be the same)

I will merge some recent changes in stock module tonight so we can test tomorrow in trunk with fresh code (of course 'tomorrow' is a somewhat relative concept, I know ;-))

Thanks all for being so patient and always discussing these issues in a constructive way!

Hello, I just changed the titled to keep our comments instead of opening a new bug.

@Olivier, we think it's better to keep this correction in the core instead of developing a new module because the average cost price concept is in the core and the return cost price is wrong. Adding a new module to correct a wrong behaviour does not seem to be the good solution as many OpenERP users won't be advised to install such a module and they will have the same story that Nhomar... (financial audit, 100s hours work...).

>
> Thank you for your explanations Nhomar and Invitu, I understand better
> what you mean now! :-)
>
> If we want to keep things simple, in line with what Fabien suggested on bug
> 610738, why do you think it would not be possible to do this in a module if
> the core stock module does not record the cost?
>

I will answer with other question friend.
The modules should be done for "correct" or "extend" the core
functionalties?

I mean, if is a bug, is a bug and should be corrected, BTW this is a Hidden
bug, that is no showing obviously it could be better that the core do the
correct calc than overlapping with an extra module.

For example, an extra module should be used for _extend_ the cost
calculation for "landed cost" only making a super() and adding the amount
corrected, but _this_ is extend a function not correct a function.

BTW, for make this in an extra module, we need to get the cost on time "If
it is not recorded in any place, how do i get it?"

Answer: Logical, analisys of timeline of data results, at least a lot of
hours (we expend for v5 for now at least > 100 hours and growing up!) we
prefer, expend this hours this time in V6 too, in discuss with the core tem
to make our point "clean " than expend in correct something that we are
almost sure is affecting to everybody and i'm pretty sure it should be
better and benefit more people.

I hope it can help you.

folks, Always our work and critics will be done in a constructive way ,
sorry for my poor and uneducated english.. ;-)

We share your vision, believe me, we want the best open source ERP in the
market ;-)

> An additional module could add the required fields on stock.move, inherit
> the method that marks a stock.move as done (or the method that creates the
> whole picking in sale.order if you want the cost at the time of the sale) to
> record this value, and then inherit the stock wizards to suggest this value
> when it is relevant.
> This is partially what the purchase module does at the moment in trunk to
> provide the actual purchase price of the product in the partial picking
> wizard for products with average cost enabled.
>
>

+1 for a fix.

The current software I work with snapshots product costs at time of invoicing (or anytime it leaves the company)

All returns are by default based on this snapshot cost no matter how old. (Costs may be overriden by an authorized administrative user)

For our clients it is an essential. The accountants expect this behavior.

Particularly this is critical for "high" value goods that are maintained at low or zero stock levels.

One client handles plasma and lcd TVs. Their cost (and margin) varies by hundreds of dollars between purchases.

Returning a product, from an invoice, MUST reduce the reflect the original cost and associated margin.

Unfortunately this bug means OpernERP would not survive an audit with our current or prospective clients.

Hello,

It has been fixed in lp:~openerp-commiter/openobject-addons/dev-addons2-rha1

Revision ID: <email address hidden>
Revision no: 4470

Thanks for reporting,
rha

seems not fixed yet

hello everyone,

first i'd like to say that the fact this bug has changed his purpose and summary may lead to confusion, and should be avoid in the future. So i want to confirm that we treated (fix released), in stable as well as in trunk, the initial problem which was with default value = 0 as cost price of returned product. What follows only concern the proposal to store the initial cost price of the product in the stock move and use this one as default value instead of the current cost price.

We just cheked the fix done by rha, but his solution doesn't suit us (and, actually, doesn't fix the bug).. thus the fix won't be merged into trunk. Furthermore, we think that this issue can't be addressed for v6 because:
*it introduces a schema change in the database (and that's a bad idea because we are in rc process)
*it will be difficult to fix it in a proper way that won't break something else
*it doesn't affect that much use case.
*it is only a default value in a wizard.

so altough we agree this should be improved sooner or later, we can't do it for the v6. If you want this feature asap, i can only encourage you to make a vote for it in http://feedback.openerp.com

thanks for your understanding

Dear Quentin

First I apologize for our insistence on this bug.

This bug has made us write a lot and took us much time to explain where the problem is..., we will go on

We think that taking the cost price of the day instead of the historical cost in average price mode is a big mistake that has been done in the very beginning of the development. I should be corrected as the average cost price still features in the core.

* "it introduces schema changes", you're right. But I don't agree on your argument saying we are in RC... have a look at the date when we opened the bug... october 2010...
* The fact that fixing it is "difficult in a proper way" is a result as the bug was not well understood in the beginning and should not be taken as a good reason for putting this bug in "won't fix" state
* By the way, this bug affects A LOT use case when average price is used for products for reasons we already exposed.
* Of course, the default value can be changed by the user... but how can the user get the real value even if he has to enter it manually ? Does it mean that he should remember the cost price for each product he sells in the case the customer would return it ? Our customers don't agree...

We understand that the V6 is about to be released and you (OpenERP SA) don't have time enough to fix it in a good way... but please don't put it as "won't fix"... I am sure that everybody would understand a "delay" (as it actually does) but a "won't fix"... not sure

Finally, I have to correct your words "improved" and "feature" by "fixed" and "correct behaviour"

The feedback website (that is a good way to evaluate customers' needs) should not be used for fixing bugs... I hope it won't be a launchpad bis.

Best regards

Cyril

Hello.

@qdp @invitu

We made a lot of improvement "in a modular way" on our development branch
for mrp[1] :
We are trying all changes on it in a producton enviroment with REAL DATA,
and we invite to you to try our changes and merge (if you think it is
possible) to addons for v6:

Changes:
relevant module: mrp_stock_cost
-- Propose "production cost".
-- Propose "returned correctly cost"
And a lot more, are ver very separated every module to be understood.

Please check related blueprints to understand better:

I hope it can help almost evereybody.

When we finish this development we will post to addons-extra and we will
port to V6 if qdp can no make changes.

Cases used1:
-- make a Sale Order.
-- validate picking.
change "manually" cost on product-
-- return picking

result: cost is the original one.

Case used2:
-- Make a bill of material.
-- Make a production order.
-- Validate the pproduction order:
-- Asign a picking to resulting product

go to Incoming picking, select the last asigned, and receive it.

result: cost proposed is sum(move_in)/quantity_in_line.

We are improving a lot more cost management.
BTW, especifically this bug is solved, i really appreciate yor feedback.

[1] lp:~openerp-venezuela/+junk/mrp_advanced<https://code.launchpad.net/%7Eopenerp-venezuela/+junk/mrp_advanced>

2011/1/11 invitu <email address hidden>

> Dear Quentin
>
> First I apologize for our insistence on this bug.
>
> This bug has made us write a lot and took us much time to explain where
> the problem is..., we will go on
>
>
> We think that taking the cost price of the day instead of the historical
> cost in average price mode is a big mistake that has been done in the very
> beginning of the development. I should be corrected as the average cost
> price still features in the core.
>
> * "it introduces schema changes", you're right. But I don't agree on your
> argument saying we are in RC... have a look at the date when we opened the
> bug... october 2010...
> * The fact that fixing it is "difficult in a proper way" is a result as the
> bug was not well understood in the beginning and should not be taken as a
> good reason for putting this bug in "won't fix" state
> * By the way, this bug affects A LOT use case when average price is used
> for products for reasons we already exposed.
> * Of course, the default value can be changed by the user... but how can
> the user get the real value even if he has to enter it manually ? Does it
> mean that he should remember the cost price for each product he sells in
> the case the customer would return it ? Our customers don't agree...
>
> We understand that the V6 is about to be released and you (OpenERP SA)
> don't have time enough to fix it in a good way... but please don't put
> it as "won't fix"... I am sure that everybody would understand a "delay"
> (as it actually does) but a "won't fix"... not sure
>
> Finally, I have to correct your words "improved" and "feature" by
> "fixed" and "correct behaviour"
>
> The feedback website (that is a good way to evaluate customers' needs)
> should not be used for fixing bugs... I hope it won't be a launchpad
> bis.
>
> Best regards
>
> Cyril
>
> --
> You received t...

Many things would be so easy to fix in trunk directly instead of forcing the community to make modules to fix such issues

Just to add my grain of salt on this issue, the price should be made context-sensitive just like the quantity available is.
The reason is that when you browse your stock locations and set a dates context, currently you get the available quantity à that date but the current price.
This would make it easy for example to extract the valuation of a yearly physical inventory (for those who make the accounting entries at the end of the fiscal year).

We're willing to help any work being done on this issue, as long as a reliable solution is found. Please let us know.

Lionel Sausin.

I am out of the office until 17/06/2013.

I am out of office until June 17th, pls contact Sebastien Roche in case of
emergency.

Note: This is an automated response to your message
"[Openerp-expert-accounting] [Bug 613286] Re: [stock] returned products
from customers have cost price of the day instead of historical cost
price" sent on 13.06.2013 18:15:54.

This is the only notification you will receive while this person is away.

the problem is basically solved in
http://bazaar.launchpad.net/~camptocamp/c2c-rd-addons/7.0/files/head:/c2c_stock_accounting/