Refund Invoice takes the actual price of the products to make the cost of sales move

[hbto [Vauxoo] http://www.vauxoo.com]

Whenever you make a Refund Invoice (in my country, aka Credit Notes) for a sale, and the client send back some products, the accounting move for the cost of sale (using anglo-saxon account mode) made by openerp takes into account the last (current) cost of sale - in my case the last (current) average price- of the product and not the previous one used when sale was made, this happens whenever there have been a purchase in the meantime,with different prices for the products involved, between the sale and the credit note.

The accounting people has advised me that the cost of sale should be the same one when the product was invoiced and not the current one.

They say this should be the correct behaviour for the Refund Invoice and not the one used right now, because if the full sale is refunded then there will be mismatches between the movelines for the cost of sale in the Client Invoice account move and the Refund Invoice Account Move

Thank in advance for your attention,

[hbto [Vauxoo] http://www.vauxoo.com (humbertoarocha)]

I think this bug is related to the Anglo Saxon Account Mode of OpenERP

https://bugs.launchpad.net/openobject-addons/+bug/388145

[Jan Verlaan (jan-verlaan)]

I tested this situation with and without the account_anglo_saxon module installed.
The bug you describe i do confirm in both situations. It is not specific to the account_anglo_saxon module.

The output for sale values defined into the account properties "Income Account" and listed on the invoice and general ledger are correct. but
Theoutput for cost of sale defined into the account properties "Expense Account" and listed only into the general ledger are wrong. Here the new product cost price is taken instead of the old cost price valid with the original transaction.

REPRODUCTION STEPS:
Create a purchase order for 2 x product1 - cost price 1 euro - sale price 2 euro, Parameter setting invoice from picking.
Receive the products and create the invoice.
Create a sale order for above 2 products.
Send the products to customer and create the invoice
Have a look in general ledger at the Expense Account and Income Account.

Now change price in product1 - cost price to 10 euro - sale price to 20 euro

Go back to the outgoing packing line and create from there the "Return packing" for 1 product.
Create the invoice from picking.
Have a look in general ledger at the Expense Account and Income Account. You can see that the Expense Account is taking the new cost price from the product file and the Income Account has taken the old price from the original transaction.

[Nhomar - Vauxoo (nhomar)]

Hello Jan.

We are working on this issue.

Only we want to make the change on the right site, to put it available to the community, without override an error but correcting the error!! .

IMHO the solution is:

OpenERP doesn't have any object to bring a historical cost! and we believe that the change should be done in this way:

At the moment that the out_invoice is validated, the cost price that the product has in this moment, and is taken to make the account_move_line, will be saved in the same invoice_line adding an extra field called "historical_standard_price" to this object, with this value, when a refund of the invoice has to be done, It could be referred to the "historical_standard_price" in the invoice_line created in the invoicing process.

In order to achieve this change, _all_ refunds, (from packing and from wizard on invoice) _must_ be related to an invoice to take in account the "historical_standard_price".

We would appreciate your opinion, to make only one change and put it on the stable branch for account_anglo_saxon and propose it for merge to account module, we think this is a really important bug.

Thanks!

[Jan Verlaan (jan-verlaan)]

Hi Nhomar,

great you are picking up this bug. It is NOT account_anglo_saxon but standard stock module that is base for this bug. If it is solved in stock, I think (and hope) it is solved in anglo_saxon too, as here a inherit of the stock object is done.

Please keep in mind that when creating only a refund invoice without any stock move, you should NOT take into account "historical standard price. It is only a financial refund and deducted from the profit. The is no cost account/cost of sale needed.
So there is no need to store the historical standard price into the invoice line!!

When the refund is created from the picking (then there is a stock move) and only then the historical standard price should be available to reflect the correct cost price. We need to test both situations for sale and purchase side.

Resulting in that you only have to correct the stock object for the case of a "Return Packing". That not the property_account_expense_id is taken, but the price mentioned into the original account_move.
I do not know if it is possible to search that data, but I guess it could be as the original stock_move is available. From there you may be can search the related account_move and account_move_line to get the original price.

[Jan Verlaan (jan-verlaan)]

Hi Nhomar,

The initiation of the return is done via the wizard wizard_return.py in stock module.
From there stock.py is called.

see /addons/stock/stock.py line 1232 def action_done(self, cr, uid, ids, context=None):
Here are the accounting entries created for the stock move.

Then on line 1294
ref = move.picking_id and move.picking_id.name or False
product_uom_obj = self.pool.get('product.uom')
q = product_uom_obj._compute_qty(cr, uid, move.product_uom.id, move.product_qty, default_uom)
if move.product_id.cost_method == 'average' and move.price_unit:
       amount = q * move.price_unit
else:
       amount = q * move.product_id.standard_price

As you can see there is no differentiation for the amount if refunds. Always the product object is used to determine the price.
Here the differentiation should be made for the return picking! and the price should be taken from the original account_move line.

Hope this helps.

[hbto [Vauxoo] http://www.vauxoo.com (humbertoarocha)]

Hello, Jan & Nhomar,

I think this issue of Refund is in one way something that will spark the
light of tighting together and for better the modules involved with
invoicing, right now there some kind of looseness, well but my point will be
explained in the ongoing explanation.

As you, Jan, pointed out, I discussed as well with Nhomar, my partner, about
the need to have a historical record of the cost, somewhere you can grab the
data and it can be reused again,

There is something about the use of the stock move and invoicing procedure
that concerns me, if we don't try to adjust tightly those forecoming
changes.

Just to pretend, let imagine that the historial_standard_price, that is
proposed by Nhomar (and implicitly by me), is used in the stock module, so
in every line of the stock_move there is a record of that data,

I come to this point because you can have a complex and valid way of
invoicing from the pickings, when you choose two or several pickings and use
the invoice wizard, this action cause the generation of a single draft
invoice, let validate the draft invoice, account_move_lines for the cost are
generated, now, where would the calculus for the sale_cost come from? A good
idea as you propose is using the historical_standard_priced stored in the
picking_line of the product having different sale_cost for different
picking_line in different pickings, in this way then it is needed that the
invoice be related in someway with the picking something that right now is
missing, and that could be achieved storing the originating picking_line
into the invoice_line, something that could cause also a break in the
procedure, because it is possible either introduce additional product into
the draft invoice without making a previous picking.

Now imagine the other way around, when is need to refund the sale invoice,
that portrait being this the worse scenario, even though Imagine not to have
to make a whole refund but partial, it would be messing, what sale_cost to
use from the different historical_standard_cost store in the picking.

I now that right now I have not provided any solution, but it is my hope
that this could enlighten more people in order to join us and give proposals
to solve this problem,

2010/2/25 Jan Verlaan (Veritos) <email address hidden>

> Hi Nhomar,
>
> The initiation of the return is done via the wizard wizard_return.py in
> stock module.
> >From there stock.py is called.
>
> see /addons/stock/stock.py line 1232 def action_done(self, cr, uid, ids,
> context=None):
> Here are the accounting entries created for the stock move.
>
> Then on line 1294
> ref = move.picking_id and move.picking_id.name or False
> product_uom_obj = self.pool.get('product.uom')
> q = product_uom_obj._compute_qty(cr, uid, move.product_uom.id,
> move.product_qty, default_uom)
> if move.product_id.cost_method == 'average' and move.price_unit:
> amount = q * move.price_unit
> else:
> amount = q * move.product_id.standard_price
>
> As you can see there is no differentiation for the amount if refunds.
> Always the product object is used to determine the price.
> Here the differentiation should be made for the return picking! and the
> price sh...

[Jan Verlaan (jan-verlaan)]

I have asked the openerp-expert-accounting group to give their input too. Let's see what possibilities we have.
https://lists.launchpad.net/openerp-expert-accounting/

[Ferdinand (office-chricar)]

in https://code.launchpad.net/~openerp-commiter/openobject-addons/chricar_price_unit
I have added 2 fields for accounting purpose to stock_move
* move_value_sale
* move_value (cost of good sold)
having this is necessary to create correct financial postings

having this its easy to recover the price/amount for refunds.

[Cloves Almeida (cjalmeida)]

IMO, "move_value" should be called "move_value_cost" to avoid ambiguities.

[Ferdinand (office-chricar)]

DONE - "move_value" should be called "move_value_cost"

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Guys,

I have checked with all related option (Directly from invoice , from stock picking.) by calling return wizard but it is taking old price of product as it is.
The problem occurs only if manually create the refund invoice so as a result of product id on change it will take new price from product not old one.

Thanks.

[Borja López Soilán (NeoPolus) (borjals)]

By the way, this bug is also applicable to Spanish users: in Spain the refund prices should match the original invoice prices.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Same thing in Brazil at least. Pretty sure would be the same in France too.

On Thu, Aug 5, 2010 at 9:05 AM, Borja López Soilán (Pexego) <
<email address hidden>> wrote:

> By the way, this bug is also applicable to Spanish users: in Spain the
> refund prices should match the original invoice prices.
>
> --
> Refund Invoice takes the actual price of the products to make the cost of
> sales move
> https://bugs.launchpad.net/bugs/527120
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> Whenever you make a Refund Invoice (in my country, aka Credit Notes) for a
> sale, and the client send back some products, the accounting move for the
> cost of sale (using anglo-saxon account mode) made by openerp takes into
> account the last (current) cost of sale - in my case the last (current)
> average price- of the product and not the previous one used when sale was
> made, this happens whenever there have been a purchase in the meantime,with
> different prices for the products involved, between the sale and the credit
> note.
>
> The accounting people has advised me that the cost of sale should be the
> same one when the product was invoiced and not the current one.
>
> They say this should be the correct behaviour for the Refund Invoice and
> not the one used right now, because if the full sale is refunded then there
> will be mismatches between the movelines for the cost of sale in the Client
> Invoice account move and the Refund Invoice Account Move
>
> Thank in advance for your attention,
>
>
>

[invitu (invitu)]

Hello

Here are some elements from Tahiti (which is the same than in France) :

- When a customer returns a product, the refund price should be the same as the invoiced price (do not forget the POS sales that make tickets) BUT if the product is damaged, the salesman could negotiate a refund price < invoice (or ticket) price. On the other hand, it is strictly forbidden to have a refund price > invoice (or ticket) price.

- Be careful with the average prices ! In a customer return scenario, the price to be used for the average price calculation should not be the refund price but the cost price at the time when the product was sold (see https://bugs.launchpad.net/openobject-addons/+bug/613286). So this cost price should be stored somewhere during the sale workflow.

Regards

[invitu (invitu)]

I agree that the historical_standard_price should be stored in the picking line for the reasons you wrote but 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)

[invitu (invitu)]

About the fact that cost_sale_price for returned products should be the historical_standard_price and not the standard price at the day of the return (which is the aim of this thread), our french accountants would go in that way but to our knowledge, it's not a legal statement, only good sense.

[hbto [Vauxoo] http://www.vauxoo.com (humbertoarocha)]

Hello Guys,

Does anyone know if this bug also affects OERP v6.0??

So it could be tackled before go to R.C.

2010/8/5 invitu <email address hidden>

> About the fact that cost_sale_price for returned products should be the
> historical_standard_price and not the standard price at the day of the
> return (which is the aim of this thread), our french accountants would
> go in that way but to our knowledge, it's not a legal statement, only
> good sense.
>
> --
> Refund Invoice takes the actual price of the products to make the cost of
> sales move
> https://bugs.launchpad.net/bugs/527120
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello Hbto and co,

After a very quick test, on v6, the refund is properly taking the original
price of the product, so it looks correct on v6 (disclaimer: very quick
test).

Raphaël Valyi

On Thu, Sep 23, 2010 at 8:44 PM, hbto (Netquatro)
<email address hidden>wrote:

> Hello Guys,
>
> Does anyone know if this bug also affects OERP v6.0??
>
> So it could be tackled before go to R.C.
>
>
> 2010/8/5 invitu <email address hidden>
>
> > About the fact that cost_sale_price for returned products should be the
> > historical_standard_price and not the standard price at the day of the
> > return (which is the aim of this thread), our french accountants would
> > go in that way but to our knowledge, it's not a legal statement, only
> > good sense.
> >
> > --
> > Refund Invoice takes the actual price of the products to make the cost of
> > sales move
> > https://bugs.launchpad.net/bugs/527120
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> Refund Invoice takes the actual price of the products to make the cost of
> sales move
> https://bugs.launchpad.net/bugs/527120
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> Whenever you make a Refund Invoice (in my country, aka Credit Notes) for a
> sale, and the client send back some products, the accounting move for the
> cost of sale (using anglo-saxon account mode) made by openerp takes into
> account the last (current) cost of sale - in my case the last (current)
> average price- of the product and not the previous one used when sale was
> made, this happens whenever there have been a purchase in the meantime,with
> different prices for the products involved, between the sale and the credit
> note.
>
> The accounting people has advised me that the cost of sale should be the
> same one when the product was invoiced and not the current one.
>
> They say this should be the correct behaviour for the Refund Invoice and
> not the one used right now, because if the full sale is refunded then there
> will be mismatches between the movelines for the cost of sale in the Client
> Invoice account move and the Refund Invoice Account Move
>
> Thank in advance for your attention,
>
>
>

[invitu (invitu)]

Hello

If the product cost price is averaged, it should NOT take the original price of the product BUT the cost price of the product when the product was taken out of stock. (The cost price could have changed between the sale and the refund)
(we should test this feature on V6.0 very soon)

Regards

[Nhomar - Vauxoo (nhomar)]

2010/9/24 invitu <email address hidden>

> Hello
>
> If the product cost price is averaged, it should NOT take the original
> price of the product BUT the cost price of the product when the product was
> taken out of stock. (The cost price could have changed between the sale and
> the refund)
> (we should test this feature on V6.0 very soon)
>

Hello

@invitu

The refund move line is an standard in all accounting system, it _must_ be
taken from the original move, always, and recalculate the costs exactly in
the same way that the actual behaviour is done if this was a refund from
sales (the product is going in), i think it should be reviewed by the expert
team, but is relatively obvious the solution.

>
> Regards
>
> --
> Refund Invoice takes the actual price of the products to make the cost of
> sales move
> https://bugs.launchpad.net/bugs/527120
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Addons.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> Whenever you make a Refund Invoice (in my country, aka Credit Notes) for a
> sale, and the client send back some products, the accounting move for the
> cost of sale (using anglo-saxon account mode) made by openerp takes into
> account the last (current) cost of sale - in my case the last (current)
> average price- of the product and not the previous one used when sale was
> made, this happens whenever there have been a purchase in the meantime,with
> different prices for the products involved, between the sale and the credit
> note.
>
> The accounting people has advised me that the cost of sale should be the
> same one when the product was invoiced and not the current one.
>
> They say this should be the correct behaviour for the Refund Invoice and
> not the one used right now, because if the full sale is refunded then there
> will be mismatches between the movelines for the cost of sale in the Client
> Invoice account move and the Refund Invoice Account Move
>
> Thank in advance for your attention,
>
>
>

--

[Nhomar - Vauxoo (nhomar)]

I confirm is affecting OpenERP V6 too.!

[Frederic Clementi - Camptocamp (frederic-clementi)]

In most cases, the rule is to value returned shipment at historical cost i but don't consider the other possibility as wrong.

This "historical cost method" should only be the default option (but not the only one).

[Nhomar - Vauxoo (nhomar)]

>
>
>
hulala...

Frederic. Are you sure the actual behaviour is not totally wrong?
seriouslly?

Somebody has passed an accounting auditing with openerp installed? because
it is a serious issue, we pass one, but this error shows up, the real thing
is that it was the unique mistake found, thanks God.

the accounting principles "rhine and anglo" said that the cost _must_ be
recalculated in return with historical cost, i can not find anywere some
accounting book that said the oposite.

can you help me Frederic¡?

[invitu (invitu)]

ok, I took time to re-read carefully this thread.
Everything seems to converge on the same problem than in https://bugs.launchpad.net/openobject-addons/+bug/613286
The solution for both bugs seems to be adding extra fields in output pickings.

About old comment #6, the question was "which cost_sale should we take to make the credit note when the return concerns an invoice that contains several pickings?"
If you make credit notes from return pickings, you won't have the problem as you will return the product from the original output picking (as long as we store the cost price in it). In real life, if you don't manage production lots, it will be impossible to identify from which output picking the product is, so let the user make the choice.
If you make credit notes directly from invoices without making return picking, you won't be able to have a right cost_price. I would suggest to take the product.cost_price (it's better than nothing).

Note that we are talking here about returns from customers and not about returns to suppliers which is totally different (there is no move_value_cost for input pickings)

[Nhomar - Vauxoo (nhomar)]

Hello.

I made the change, only recording the valu when it is calculated with average price as we are asking for.
Please try patch.

Note: I can see around work on this a little of things.
1.- We can propose on manuals avoid the use of "Process Now" with security (roles), in this way if you need automate all process of receptions without errors only hide this buttons, Is this possible?
2.- After this patch is applied, we can develop an extra module that use this value to check the returned picking.

@Invitu.
We thought one time like you that Lots are needed to know the cost original used, but is more simple, if I am returning an _specific_ picking i need a field that relate a picking with other (exactly as backorder does a recursive relation) with this is possible obtain the cost, as you can see the logic can be complicated, for this reason I think that record the cost used on wizard in core ensure that you can install whatever you want the extra module that wi will make and you will can check this values to back.

I'm proposing the _first_ part for this issue, the second part should be record the cost that has the product exactly in the time it go out from the inventory.

regards..... I hope it helps.

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

Hi,

I just wanted to add this related bug :

https://bugs.launchpad.net/bugs/610738

Regards,

[invitu (invitu)]

hello, could you give the revision where this bug is fixed ?

[Amit Parik (amit-parik)]

Hello,

This was fix in previous revision of OpenERP trunk so please update your code. And check with the latest code.

Thanks.