I am sure Erik will have more to add here.
On Sat, Sep 20, 2014 at 12:46 PM, Pongrácz István <[email protected]
> 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
> [email protected]
> 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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
