Re: FX rates related thoughts

I am sure Erik will have more to add here.

On Sat, Sep 20, 2014 at 12:46 PM, Pongrácz István <..hidden..> wrote:

Hi,

I think the local rules usually control that,

how to track accounts,

which is the base currency and

how to calculate the foreign currency in the base currency.

This is true. For example, iirc, in some countries you can't post fx gain or loss on short term collectables like invoices. I.e. the invoice effectively takes on the exchange rate when paid. Having a good system in place really should go a long way towards allowing support for local rules.

An example:

The company must declare, which FX rate will be the base of all accounting and the accountant (system) must adjust the FX gain/loss based on the real life (bank) FX rate.

This gets more complex in a number of cases. But usually you are allowed to use the actual transaction rate if you know it. Note this may vary slightly from the daily rate.

My company uses the local Central Bank FX rate, which changes every day at 12:00. That sucks in that way, there are two different FX rates, one in the morning and one in afternoon, but we can choose one, which is ok.

Banks use different FX rates, they change frequently, several times a day.

If a transaction happens in foreign currency, comparing to the Central Bank FX rate (as reference) there will be FX gain/loss.

I think, using one reference FX rate and several real life could cover the use cases. The reference FX rate could be populated automatically (by cron), which can help to lower the human error on enter.

Hmm, as I think, when an FX rate entered for the future, for like in a quotation or order, when the real date will be the same date as on the quotation/order, it should be changed to the real reference FX rate to have a correct number....

A quotation or an order when we get to that will have no rate. Adding a rate there messes everything up. I think for 1.5, we will need to move this to a per-order pro-forma rate.

So, when you implement the multi FX rate recordings, it would be useful to make a research, which way will be the best one which is suitable for most of us.

The typical way to do this, and I have done some research here, is to have a daily rate and allow variation for a per transaction rate within a certain range around that.

And a FX rate reporting/editing form could be useful. Revisors usually ask FX reports and at this moment it is not possible in the recent lsmb.

What specifically are you looking for? Can you provide an example?

Ok more generally, here is how I see it:

There are a few cases where we need to handle foreign exchange rates. I can imagine transactions involving one, two, and three currencies and the handling is somewhat different.

One currency fx transaction: Books in USD, issue an invoice for EUR, paid in EUR into an EUR account. In this case, the balance fully floats. We can translate into local currency for income reporting purposes, but the fact that we have a potentially long-lived asset in a foreign currency makes things difficult. We have to calculate balances, gains, and losses over a period based on a floated currency, using standardized rates for the beginning and end of the period, and we have to store translated values for intraperiod fx gain/loss reporting but for carried over values we can't. So fx gains and losses have to be in part a reporting matter.

Two Currency fx transaction: Books in USD, invoice in EUR, paid in EUR into a USD account. This is a fairly simple translation-based approach but local rules vary regarding how you handle fx gains and losses.

Three currency transaction: Books in USD, wire money from EUR account to GBP account, recording wire transfer fee as expense in USD. I can't think of needing more than three.

The key challenges are:

1. Translation with the "real rate" which means we associate transactions (or even transaction lines) with individual rates.

2. Reporting of carry-over balances and gain/loss or assets purchased in previous periods.

These don't strike me as tremendous challenges but they are ones that are important to bear in mind.

Best Wishes,

Chris Travers

Cheers,

István

------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more