[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Managing exchange rates - in 1.3 and up



I would have responded to this last night but it is a big issue and one we also have to deal with in Efficito, since we have USD and EUR assets.


On Thu, Jan 9, 2014 at 3:48 AM, Pongrácz István <..hidden..> wrote:

Hi,

I found that, if I use more than one currencies, I can create offers/orders/invoices etc. in foreign currency when my customer/vendor has an account with that currency.

In this case I am able to set an exchange rate for a specific day. The simplest rule in here (Hungary) to use the MNB's daily exchange rate (MNB is similar to FED or other central bank, which controls the country policy or whatever).


Right.  That's more or less where we are with Efficito too. 

As I do businessess in worldwide (vendors, customers sometimes in the EU and outside of EU), sometimes it happens, wrong exchange rate entered and needs to adjust it. Typical is, copy the value from somewhere else by Ctrl+C - Ctrl+V and the value format is wrong: like 221,38 become 22138 when it saved. It can happen and will happen.


This will have to be addressed before import.  My recommendation is you use a Perl script using our PGNumber, and an appropriate input format. 

An other example, in the same day I issue an invoice for USD and I entered the MNB's exchange rate, but I also receive for example some USD into my bank account, but the bank converts it in his exchange rate which different than MNB.


Yes, this is an issue with our current approach.  Currently the best way to handle this is to adjust the entry with a GL against fxgain or loss.  When we rewrite the financial code, I think the most likely scenario is that we will allow a nominal daily rate (for things like invoices) and a specific negotiated rate (for things like payments). 

So, in SL (and the Hungarian modificaton of SL) it is possible to:

  • list exchange rates for a specific day (not comfortable, limited functionality)
  • keep track of two independent exchange rate, one is like for MNB, the other is for bank's exchange rate (this is also limited to 2)

After all, my questions:

  • is that possible to get a list of actual exchange rates? date from-to, currency could be ok for first
Not from the user interface, unfortunately.  This would make a nice enhancement. 
  • it would be nice to be able to manage these kind of issues when accidentaly wrong exchange rate entered -> in this case all related transaction should be recalculated, fixed somehow in the books, but keep it somehow in the "history" of course
Best option right now is to change it in the database. 
  • I did not check this specifically, but how can we manage that case, when some has more than one bank accounts and some of them are in different currency and wants to keep tracking that in USD/EUR/whatever?
This doesn't scale well, but best option is to issue adjustments.  We need to fix this during the financial rewrite.  

Regarding filling up automatically the exchange rate is possible with direct sql manipulation, using a script, for example every morning or whatever.

So, what is your experience/needs with exchange rates?


This actually only begins to address the issues with foreign exchange rates.  We are nominally multi-currency, but currently require a significant amount of manual work to keep things going.  Another issue you did not address is the effect on the balance sheet of foreign exchange fluctuations and foreign currency instruments.  For example, if you have a USD bank account, you need to be able to include some accounting for the fx changes.  This isn't as simple as gain or loss and we need to handle it better.  it can be done manually but it requires a certain amount of work, work we hope to eliminate in the future.

With the above answers (mostly involving manual adjustments), I would like to share my proposal going forward.  None of this will get done before 1.5.  But it is a priority for me there.

1.  Have nominal and actual foreign exchange rates.  Invoices I think should always use nominal unless they are prepaid.  This would allow certain transactions to have separate exchange rates.  We would enforce a constraint that exchange rates fall within x% of nominal (set under configuration).

2.  Have a UI for setting and correcting nominal exchange rates (since all transactions would have actual ones).

3.  As a priority further down the list I would like to address multi-currency handling of assets so that these can be more easily reported to the balance sheet properly.

2.  

--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
http://www.efficito.com/learn_more.shtml