[FIX] purchase_stock: Bill currency different than PO

[HANNICHE-Walid]

Steps to reproduce:

The Company Currency is the Dollar
Create a product > Set FIFO and Manual valuation
Set BIlling policy as Ordered Quantities
Create Purchase order in Euro
Create Vendor bill in USD (10 $)
Now Receive the quantities
Check the valuation
Wrong value (15.92 $)
the value should be 10$ (taken from the bill)

Bug:
In the case of BIlling policy on Ordered Quantities and PO in a foreign
currency we assume the bill will be in same currency as the PO

Fix:
currently unit price is first computed in PO currency and then converted
in the end to company currency added conversion from bill to PO
opw-3805454

also fixed a rounding issue opw-3773413

alternative fix:
compute everything in company currency (#155937)

[robodoo]

Pull request status dashboard.

[Sehnde]

Hello,
Maybe I missed something but when I create a bill, it is in the currency of the PO (€10/unit). Then if I switch the currency to $, it simply changes the sign without doing any conversion ($10/unit)
Then if I receive the product and look at the valuation, it will be in the main currency ($) and properly converted ($15.29/unit)

This is different from the steps you explained, so is there still a need for this PR?

[HANNICHE-Walid]

and properly converted ($15.29/unit)

it shouldn't have been converted that's the point
on the bill its value is 10$ if the bill is already posted when we receive the product that's the value we should use for its stock valuation
(we are converting 10$ to 15.29$)

[HANNICHE-Walid]

hi @Sehnde you can refer to the test to check the incorrect behaviour

[Sehnde]

@HANNICHE-Walid ok I see what you mean. Would you please update your commit and PR message to explain that? This is not clear.

Now for your fix, it will immediately create a layer at the bill value in the company currency. So for the following case:

• PO -> 1 unit of product A (purchase_method == 'purchase'), €10/unit
• create bill -> 1 unit of product A, $10/unit, validate
• receive product

the SVL will be at $10 instead of $15.29 in a single layer.

Comparatively, if purchase_method == 'receive', it will create 2 layers: one at $15.29 and one at -$5.29
Now here's my idea: we could keep the same result on both purchase_method: 1 layer at converted value and 1 correction layer. To do this, we could call _generate_price_difference_vals after the converted layer is created.
For that, you'd need to add an inherited method _action_done in purchase_stock/models/stock_move.py that would look like this:

    def _action_done(self, cancel_backorder=False):
        res = super()._action_done(cancel_backorder=cancel_backorder)
        if res.product_id.purchase_method == 'purchase' and res.purchase_line_id.invoice_lines:
            amls = res.purchase_line_id.invoice_lines
            svls = res.stock_valuation_layer_ids
            correction_svl_vals, _dummy = res.purchase_line_id.invoice_lines._generate_price_difference_vals(res.stock_valuation_layer_ids)
        return res

This is a very rough draft that does not care for multiple invoice lines or layers, but it works as a proof of concept.

This is just an idea, do you have an opinion @amoyaux ?

[amoyaux]

Why would you need a correction layer? When you receive the product you take the bill value and that's all

[HANNICHE-Walid]

R+ ?

[Sehnde]

Why would you need a correction layer? When you receive the product you take the bill value and that's all

I wanted to keep the same behavior as when receiving quantities then invoicing a different total price. Not a good idea evidently.

@HANNICHE-Walid some remarks from me:

• please update the commit message to make it clear that we don't want the valuation to convert the PO value.

In valuation taking the price from the bill, and currency from PO.

This line made me think that the valuation layer was in the PO currency (€) with the bill value (10) so I was expecting to see €10 in valuation instead of $15.29

• change invoice_value into something that is distinct enough from invoiced_value. There's only 1 letter difference and it is not obvious at first glance. I'd suggest invoice_line_value
• if the bill already is in the company currency, could you skip the 2 conversions? In your test, the price unit returned is 99.999999 instead of 100. It is rounded later but we could avoid that and gain time by simply taking the invoice value if it's already in the company currency.

[HANNICHE-Walid]

• if the bill already is in the company currency, could you skip the 2 conversions? In your test, the price unit returned is 99.999999 instead of 100. It is rounded later but we could avoid that and gain time by simply taking the invoice value if it's already in the company currency.

this was also done to account for the case of the bill being in another different currency aswell (although an unlikely scenario)
right now we are doing the computations in the PO currency and finally converting everything back to the company currency. I also suggested doing all the computations In the company currency as an alternative.

[HANNICHE-Walid]

hi @Sehnde I have updated the PR

[HANNICHE-Walid]

@amoyaux R+ please

[nle-odoo]

robodoo delegate+

[HANNICHE-Walid]

@robodoo r+

[fw-bot]

@HANNICHE-Walid this pull request has forward-port PRs awaiting action (not merged or closed):

• [FW][FIX] purchase_stock: Bill currency different than PO #166600
• [FW][FIX] purchase_stock: Bill currency different than PO #166614
• [FW][FIX] purchase_stock: Bill currency different than PO #166625

[fw-bot]

@HANNICHE-Walid this pull request has forward-port PRs awaiting action (not merged or closed):

• [FW][FIX] purchase_stock: Bill currency different than PO #166600
• [FW][FIX] purchase_stock: Bill currency different than PO #166614
• [FW][FIX] purchase_stock: Bill currency different than PO #166625