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 should be taken from the original account_move line.
>
> Hope this helps.
>
> --
> 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.
>