ERPNext Foundation ERPNext Cloud Chat Blog Discuss Frappé* Donate

Exchange Rate fields - different amount of decimals creates unnecessary inaccuracies


#1

I have a situation where and entire Purchase transaction is executed in the Suppliers Invoive which is different then my companies default invoice. Even the payment itself is being done in cash in the Supplier’s invoice.

I would assume there is no need whatsoever to write of any currency exchange differences but unfortunatly it is.
I believe the root cause for this is that the Exchange rate in the Payment Entry only allows 3 decimals


… while the Exchange rate in the Purchase Invoice has 9 decimals

due to this u have to book echange rate gains/losses where it is completly unnessecary. And I beleive the goal of a System is to illustrate the reality rather then having the reality to be tweaked in order to satisfy the system.

  1. Is there anything speaking against equaliying the Exchange Rate fields thoughout the system to allow the same amount of decimals?
  2. where in the code is that amount of decimals set? I assume it wouldn’t be too complex to change this

#2

How about check what ‘official’ Exchange Rate values are stored in what fields in the database tables.

Once you know that, the question is in what calculation workflow where the decimal digits go missing - ie in the backend data Model or the frontend data View - this is a tracing mission!?


#3
  1. Any suggestion how to do practically that? Th only hint I see in the frontend is the ‘Price List exchange Rate’ field (also shown in the Purchase Invoice). I have no idea where that comes from though. It does not seem to be affected by adding a exchange rate in >Setup >Currency >exchange rates.

  2. What would I win if I find it?

What I see in the PAYMENT ENTRY form does not really explain much. I and can find 2 “Exchange rate” fields. One connects to source_exchange_rate, the other to target_exchange_rate. both have the same precision (9)
but practically not all of them are being used which leads to rounding inprecisions and likewise unnecessary write off.

Also I have seen that behavior is different in different versions (10.0.54 vs 10.0.56) so I thought I’ll wait till v11 comes around the corner, see how the situation is then and potentially come back to this. Please kindly do not close this issue yet. It is still open


#4

For 1) yes explore the database with say

MariaDB [1bd3e0294da19198]> SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME like ‘%exchange%’;

and

MariaDB [1bd3e0294da19198]> SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME like ‘%exchange%’;
±-------------------------------------±--------------------------------------+
| TABLE_NAME | COLUMN_NAME |
±-------------------------------------±--------------------------------------+
| tabCompany | exchange_gain_loss_account |
| tabCompany | unrealized_exchange_gain_loss_account |
| tabCurrency Exchange | exchange_rate |
| tabExchange Rate Revaluation Account | current_exchange_rate |
| tabExchange Rate Revaluation Account | new_exchange_rate |
| tabJournal Entry Account | exchange_rate |
| tabPayment Entry | target_exchange_rate |
| tabPayment Entry | source_exchange_rate |
| tabPayment Entry Reference | exchange_rate |
±-------------------------------------±--------------------------------------+
9 rows in set (0.16 sec)

Then confirm and relate values in the database with the code, with searchs like this:

find . -name ‘*.py’ | xargs grep source_exchange_rate

Of course this is quite general and lame advice :slight_smile:


#5

Quite possibly some likes?