When encoding a supplier invoice it is possible to change the unit price of the product
(which is copied from the receipt).
But this new price is not impacted in the cost price of the product.
Example:
We order steel balls, the unit price to order is 1 €. We receive the products in stock.
We receive the invoice but the unit price on the invoice is 1.5 €.
Why a price increase: the price of steel has increased sharply
between the time of our order and the delivery, the supplier impact the augementatoin on the invoice.
Actually, the cost price is not calculated on the basis
of new unit price of the facutre but only on the basis of the price indicated in the order.
Solution:
Add a notion of "unit price of the invoice" on the line of stock movement in the same idea as the module "landed cost"
Change the unit price of the movement with the new price coming from the invoice line associated with the movement.
Recalculate the cost price of this product with the new unit price.
I'm not sure this is the best solution .. but it's an idea
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
>Normally, the price should be know at the reception as it is mandatory to put the price on the delivery note.
The reception is carried out by the logistics team on the basis of the "packing list / delivery note", this document does not have the information of the unit price. The price is indicated on the invoice which will be treated by the account after the reception.
On all the "delivery note" that we have the price is never indicated. I think the "delivery note" should only legally indicate the product, the unit, the quantity and the weight. The unit price is only on the invoice.
I looked on the internet for other examples of "delivery note" and that corresponds to that.
I do not think it should be managed exactly like the landed cost.
Here we have to change the unit price, it is not something that is added to it.
The module account_invoice_stock provide already a list of all invoice lines so it will be possible to compute an average unit price for the move. Even if the same invoice line is linked to multiple stock moves, the average will globally result in the same stock amount.
I think account_invoice_stock, when posting the invoice, could update the unit_price of the linked moves by computing the average from all the stock moves linked. It should take care that it may need to add the landed cost if the module is installed.
I think that modify the unit price on stock move when invoice is posted is a good idea.
When thinking about this upgrade the search domain for linking stock moves to invoice line should be more specific
* the stock move already linked to an invoice line should be invisible :
-> the problem is more than one invoice line update the unit price on the same stock move
* Why displaying the internal stock move for link to an invoice line ?
What do you mean with the unit price average ? :
* create invoice line from purchase (stock move linked to purchase line) :
Now it is the unit price of the purchase line used on the invoice line, not the unit price on stock move.
If you have a purchase line with 1€ for 3 unit and create 3 stock move. The unit price on the invoice line will always be 1€.
Otherwise if we use the unit price of the stock to create the invoice line, I think would be better to group the moves by unit price
and create invoice line for each different price.
* why the invoice unit price should update the unit_price of the linked moves by computing the average from all the stock moves linked ?
If we have an invoice line with a unit price 1€ all the stock move line should have 1€ unit price not a average.
In case of use landed cost module, we need to add a extra depends on account_invoice_stock to surcharge the update unit price method
to reapply the landed cost on stock move.
On 2018-03-29 11:16, Thierry Bruyere wrote:
> I think that modify the unit price on stock move when invoice is posted is a good idea.
>
> When thinking about this upgrade the search domain for linking stock moves to invoice line should be more specific
> * the stock move already linked to an invoice line should be invisible :
> -> the problem is more than one invoice line update the unit price on the same stock move
No this is a valid case. That's why I talk about using the average of
the linked invoice lines.
> * Why displaying the internal stock move for link to an invoice line ?
I think the domain is too complex. But this field is not intended to be
manually edited. It is managed automatically by the sale/purchase.
> What do you mean with the unit price average ? :
>
> * create invoice line from purchase (stock move linked to purchase line) :
> Now it is the unit price of the purchase line used on the invoice line, not the unit price on stock move.
> If you have a purchase line with 1€ for 3 unit and create 3 stock move. The unit price on the invoice line will always be 1€.
The unit price on the invoice will be what the supplier invoice says.
> Otherwise if we use the unit price of the stock to create the invoice line, I think would be better to group the moves by unit price
> and create invoice line for each different price.
>
> * why the invoice unit price should update the unit_price of the linked moves by computing the average from all the stock moves linked ?
> If we have an invoice line with a unit price 1€ all the stock move line should have 1€ unit price not a average.
The average is in the other way. If you have multiple invoice lines
linked to the same stock move. You must set the unit price with the
average.
On 2018-03-29 11:57, Thierry Bruyere wrote:
> > The average is in the other way. If you have multiple invoice lines
> > linked to the same stock move. You must set the unit price with the
> > average.
>
> How could be possible to have a multiple invoice line on the same stock move ?
> I don't find which module allows to make this.
You could change the quantity of the invoice, so you will have two
invoice lines.
The design allows to have multiple so it must be managed even if it is
unlikely to happen in real life.
as Thierry mentions in msg39486, delivery notes have no need to indicate the price as they involve only pure physical delivery. They may, however be accompanied sometimes by an invoice;-)
The contracted price is principally determined at the [confirmed] order.
*That* is the moment of the sale contract.
The invoice is simply the material, contractual consommation of the sale order, eventually augmented by miscellaneous fees not fixed or determinable at order time (e.g. delivery fees which need to be applied prorata to the delivered articles).
There are also price revisions which may fix the final price (+/-) using specific criteria such as published indexes (the particular case THierry uses here).
Too, even until final payment the 'real' cost price of the article(s) may change as there may be a financial discount for early payment (escompte) which is quite common in the real world, also applied prorata.
Finally, invoice corrections (a necessary reality) deal with errors, omissions and duplicates.
The cost price of a "particular" ordered article has therefore potentially a number of updates, independent of the same article object of a different order.
I believe it is important to remember that "average" [and "fifo(/lifo/nifo)"] costing considers how the cost prices of actual [non-identifiable] articles acquired is determined.
So it appears (to me) that perhaps independent of the number of invoice lines pointed to by a stock move, the costing mechanism must be coherent and take into consideration these various possible cost updates.
The calculation of the unit price does not seem to take into account the exchange rate on the invoice date but only that of the effective date of the movement.