Re: [CK-Ledger-users] Multicurrency?

[C K Wu <ck...@ho...>]

Marc Lutolf =B4=A3=A8=EC:

>Hi CK,
>
>Here are some notes to your message.
>
>Cheers,
>
>Marc
>
>
>FOREX vendor invoice
>FOREX payment
>FOREX customer invoice
>FOREX receipt
>FOREX adjustment journals
>FOREX period end journal to record unrealised FOREX gain/loss
>
>The last two are perhaps infrequent occurrence that can be dealt with
>manually.
>
> =20
>
>>>agree
>>>     =20
>>>
>
>
>For FOREX invoices, I think it is sufficient to introduce something like=
,
>
>Currency: [drop-down currency list] Exchange rate: _______
>
> =20
>
>>>agree
>>>     =20
>>>
>
>ie, a single foreign currency for the entire invoice. It would probably
>require too much effort if each invoice line item is allowed to choose
>a different currency. The initial default exchange rate is taken from
>a FOREX table updatable via Ledger Admin, but could be override at
>invoice creation time. The actual booked invoice amount will be
>calculated as, FOREX AMOUNT x Exchange Rate .
>
>For monetary FOREX payment/receipt, a similar arrangement can be
>implemented.
>
> =20
>
>>>Yes. Overrides bring a whole new set of problems. For my purposes it i=
s
>>>     =20
>>>
>enough to work with a standard exchange rate.
>
>The hard part is perhaps invoice matching against payment/receipt. There=
 are
>three possible scenarios,
>
>a) X currency invoice can only be settled against X currency
>payment/receipt.
>b) X currency invoice can be settled against X currency and/or home
>currency payment/receipt.
>c) X currency invoice can be settled against any currency payment/receip=
t.
>
>At this stage, I would incline to go for alternative a), since it is the
>easiest to implement and probably handles majority of cases faced by an =
SME.
>
> =20
>
>>>absolutely agree that a is the way to go
>>>     =20
>>>
>
>Here is what I am using at the moment:
>
>CREATE TABLE xar_ledger_currency (
>  xar_id int(11) NOT NULL default '0',
>  xar_isocode varchar(5) NOT NULL default '',
>  xar_currname varchar(100) NOT NULL default '',
>  xar_rounding float NOT NULL default '0',
>  xar_notes longtext NOT NULL,
>  PRIMARY KEY  (xar_id),
>  UNIQUE KEY xar_isocode (xar_isocode)
>) TYPE=3DMyISAM;
>
>The iso code is not really used, except as a possible key for importing =
new
>data. Internally the system needs to work with the unique id.
>
>Note the rounding field. This is for currencies that get rounded in
>transactions. In Switzerland for instance, you almost always have roundi=
ng
>up to the nearest 0.05 CHF. Notable exceptions are bank accounts, so you
>have to define the rounding per account.
>
>I work with a 3 tier system: there is a system default given by the curr=
ency
>table, which can be taken over or overridden manually by the customer. O=
n
>creation of an invoice you can take the customer's exchange rate or over=
ride
>it manually on the invoice.
>
>I don't like the name FOREX too much, because it's not just foreign
>exchange; the home currency is in the currency table, too! But that's me.
>
>
> =20
>
Great. I'll try to have these implemented by the next release.

Cheers,
CK