In what circumstances would one choose for dependent or independent currency system?

Is high-inflation the only reason? What kind of multi-currency situation should you be in?

Think about companies in the former east-european countries; this company in Hungary uses the Euro to trade and report to their Austrian headquarters but they must report locally in Forints.

When your currency conversion has to be done via EURO then you have to set to dependent.

Well, in this case there's no legal obligation to use the euro but only the business need.

It's clear to me that the single currency is no option here.
But what's the difference between the independent (stores both currencies on each transaction) and dependent in terms of use (functionality). The HUF devaluates a couple of percents compared to the euro. That's not really "high-inflation" yet.

reference currency: EUR

local currency (homecurrency 1): HUF
Reporting currency (homecurrency 2): USD

transaction currency: JPY

Independent:
program will convert from JPY to HUF and USD

Dependent:
program will convert JPY to EUR then
EUR to HUF and USD.

I hope it helps.

Indeed a single currency system is not handy, as the Hungarian company wants quickly to report in Euro to the Austrian company.

The independent currency system is invented for high inflation countries. You can set up from any transaction currency the direct rates to the home currencies individually. The home currency amounts itself are not related to eachother. Still this currency system is not necessarily invented for high inflation countries and could be used in your situation, but I would not recommend this, as I know that there are a lot of problems in the software as this is a currency system which is not much used with BAANERP5. You can imagine that most companies either went for a single system (USA) or a dependent multi currency scenario in the European union to solve the EURO problem.

The dependent currency system is actually created for all those situations where one (or more) home currencies are fully determined by another home currency (the reference currency). This currency system is (was) perfectly suited for the EURO as all the euro currencies were related in a fixed way to the EURO and for all other transaction currencies only the rates could be entered to the EURO. With the internal rate type then the rate could be set between the EURO (reference currency) and the other home currencies. This is not the case in your situation, but you can use this. I would go then for a dependent scenario where the Forint is the local currency (first in the array) and the EURO is the first reporting currency. As it is more natural to give in the direct rates between any transaction currency and the forint I would make the forint also the reference currency. The amounts in EURO are then always calculated from the Forint with the internal rate type to the EURO.

If you look to the future and if Hungary will join the European union and even the monetary union then it would be handy to have the EURO already as the reference currency, but I don't think that that should be considered as the user will only be able to manually enter/change rates to the EURO, which doesn't mean anything to the user. If the user would want to enter a manually rate from a certain transaction currency (let's say USD) to the Forint then the user will have to calculate a lot, as on the form only the rate between the USD and the EURO can be changed. Also the rate tables have to maintained for all transaction currencies possible to the EURO and for the internal rate type from the EURO to the Forint. As an Hungarian company I would therefore go for the dependent multi currency scenario (with 2 home currencies) with as local currency the Forint, which is also the reference currency and as first reporting currency the EURO.

Regards,
Leerebeer

The hungarians are more euro minded than I thought, but using the HUF as a reference currency seems to be the right choice in this situation.

With the drift of the exchange rates between the HUF and EUR, the financial reporting goes Ok.
But reports like sales turnover per salesman will show (in EUR reporting to HQ) an amount of 100 in January. While reporting during December will show a figure for January of about 90-95. That's something a salesman will definitely not like. Seems we'll have a few customizations to make ;-)

I do not think that customizations are necessary.

Any transaction in any currencysystem GL is valued against certain rate information in the GL.

Example:
(Dependent currency system, local HUF (also reference) and first reporting currency (second in the array) the EURO)
Suppose sales turnover in january is 100 USD which is with the rate to the Forint 400 HUF. Because the rate from the forint to the EURO with internal rate type is at the moment of registration 4 to 1. this will yield also in 100 EURO.

In february we get the same sales turnover of 100 USD and the rate from the Forint to the USD did change, so let us say that this now represents 500 HUF. The rate from the forint to the EURO did not change, so this is 125 EURO.

So with this example you see that the 100 USD will yield in january to HC [400, 100} and in february [500, 125]. I hope that it is clear with this example that the currency system does not have anything to do with the fact that transactions get valued differently when there are rate changes.

In a dependent currency system however you have the possibility to mark such a ledger account as a ledger acccount where currency analysis is required and also to calculate currency differences. With session tfgld5201m000 you can then revalue your balance on such a ledger account with the most current rate information. Normally you will only do that for ledgeraccounts which represent cash, but you can do it for any ledger account which you want periodically to revalue (part of the period end procedure).

Please note that you should not mark invoice accrual accounts as currency analysis required, calculate currency difference accounts in BAANERP50 as that will destroy your GRNI analysis. For interim accounts where the transaction currency is always the local (first in the array) currency this is a good way of getting rid of differences in the other reporting currencies, think of Work in process.


Regards,
Leerebeer

Hi from Austria!

I´ll give you some additonal information, how one of our customers did the currency set-up for his Hungarian companies:
from an Hungarian legal point of view it is possible to adopt the Euro as home currency for local accounting, so it is already possible to use the single currency system.
But you are obliged to use daily actual exchange rates!

Our customer had some additional corporate requirements, so they implemented independent Multicurrency system in the following way:
1.) EUR as home currency + reference currency wiht the use of daily exchange rates
2.) USD as reporting currency 1 with the monthly corporate exchange rate
3.) EU2 (=Euro) as reporting currency 2 with the monthly corporate exchange rate

So they are using the Euro as home currency + reporting currency 2, the only difference, that for the home currency you have daily actual exhange rates from the different transactions currencies to the EUR, whereas for reporting purposes the exchange rate to USD + EU2 are fixed for a full month.

Hungarian Forint is only a transactions currency like all other currencies!

So in this situation it happens every time that you post invoices let´s say in Japanese YEN and due to the different exchange rates the Euro amount in home currency EUR is different to the Euro amount in reporting currency EU2!

This situation is only possible in an independent MC-structure and they are using it now for more than one year in a Baan Vc environment.