Exchange Rate Difference between PR and PI

ERPNext Accounting
1

Hi guys, this question has a bit of details.

Our client are buying from foreign Supplier. And the time when they received the Goods and the time of Invoice are different. This leads to the fact that the exchange rates will be different.

So at the PR submitted, rate is X$, this credit into the Stock Received but not Billed Account (SRBNB) an amount of SV1$. When PI submitted, rate is Y$, this debit into the Stock Received but not Billed Account an amount of SV2$

Currently the SRBNB is left unbalanced after that. Our accountant suggest that when PI submitted the debit amt should stay as SV1$, and the difference goes into Realised Exchange Difference (RED).

And I think it makes sense, so I added a hook to Purchase Invoice’s on_submit and add 2 GL Entries:

  1. Debit (or Credit, depends) to SRBNB an amount of SV2$ - SV1$
  2. Credit (or Debit, depends) to RED an amount of SV2$ - SV1$

It seems to work but in the end there are 2 records in SRBNB, which should be just one.
Should I just override the purchase_invoice calculation and split the entries from there, before any GL entries are committed ?

Thank you!

2

Solved the problem by cancelling and deleting the old entry of SRBNB, adjust the debit amount to SV1$
Add another entry to RED with value of SV2$ - SV1$

Previously, it was not possible to add just one entry using make_gl_entries. But save directly (with ignore_permissions=True) works.

Some one just help me close this.

3

Do you think this is a standard way of accounting? Do you want to contribute this back to the product?

4

I wouldn’t mind but maybe we can get your accountant to confirm first ?

But even after that, there are several other considerations:

  1. My current implementation will limit to ONLY let PR and PI’s rates to be different if PI is tight to PR (mean the flow should be PO → PR → PI)
    The other flow of PO → PI → PR might be more troublesome because there is no real link between PR and the submitted PI. Our clients require to lock the rate to PO’s rate in this case. This simplify the problem.

  2. PR or PI from multiple POs, this will be even more troublesome… Not yet think about this.

So there goes my reluctance to commit anything.
Nathan