Multiple Currencies: Difference between revisions
Wolfganguhr (talk | contribs) (→Basics) |
Wolfganguhr (talk | contribs) |
||
Line 32: | Line 32: | ||
= Multiple Currency Basics = | = Multiple Currency Basics = | ||
== Different Accountancy Curreny Types == | |||
== Common Mathematical Rules == | |||
'''Requirement''': For all this transactions only the data type decimal is allowed. | '''Requirement''': For all this transactions only the data type decimal is allowed. |
Revision as of 09:49, 8 December 2010
Introduction
One of the most important points of a finance software is the proper handling of a different currencies. To enable openpetra to do the valid calculations the columns of the database table “a_currency” shall be enhanced. Therefore let us have a look onto the actual table referred in http://openpetraorg.sourceforge.net/dbdoc/ and the topic main.
This table manages the handling of the different money units in different countries.
- a_currency_code_c –This defines an international code which describes the currency like USD for the us-American dollar or EUR for the European currency
- a_currency_name_c – A free text string containing the name of the currency like “United States Dollar” or “European Money Unit”
- a_currency_symbol_c – This is the symbol used to show a currency, e.g. $US or EUR
- p_country_code_c – Name of the country the currency is used in like “United States” or “99” with a reference to the table p_country
- a_display_format_c – The currency format used to display and to accept input currency (decimal values)
- a_in_emu_l – Indicates whether currency is part of the european exchange rate mechanism/ European Monetary Union or not
- s_date_created_d – The date the record was created
- s_created_by_c – User ID of who created this record with a reference to the table s_user
- s_date_modified_d – Date the record was modified
- s_modified_by_c – User ID of who last modified this record with a reference to the table s_user
- s_modification_id_c – This identifies the current version of the record
Remarks to the actual database table
- a_currency_code_c – ok.
- a_currency_name_c – This name is a free text and there may be the requirement to translate this column respective to get access to different language version at the same time. So this column shall be swapped out into a multilanguage table.
- a_currency_symbol_c – The real symbols are $ and €. By changing from Courier formated reports to graphical reports we shall change this values too.
- p_country_code_c – As seen in europe a currency is not used in a specific country. First thougt is to skip this column. Second thought: The value 99 is used for Europe but 99 is also used as a "error-default". So the 99 in this table shall be changed to something else.
- a_display_format_c – Actually this are there are four different format strings which are developed for Progress. This string shall be changed to a .net compatible format string.
- a_in_emu_l – In this case only the problem of the Euro and the european union is solved. But there are some other curreny unions like the East Caribbean dollar.
- s_date_created_d – Not used and may be skipped
- s_created_by_c – Not used and may be skipped
- s_date_modified_d – Not used and may be skipped
- s_modified_by_c – Not used and may be skipped
- s_modification_id_c – Not used and may be skipped
Multiple Currency Basics
Different Accountancy Curreny Types
Common Mathematical Rules
Requirement: For all this transactions only the data type decimal is allowed.
Each national office has to manage its own book keeping process based on its own base currency or primary currency. Furthermore they can handle some assets defined in other currencies. In the very first step this is petty cash and this is the only form of foreign currencies which shall be managed by openpetra.
Requirement: Only one of the following transactions are allowed
- primary currency to primary currency ledger
- primary currency ledger to any secondary currency ledger and vice versa
The same Requirement is: Direct secondary currency to secondary currency transactions are forbidden
For example in the German office, the primary currency is euro and the secondary may be the English pound and the Swiss franc. A transaction from the English pound to the Swiss franc is not allowed. This are two transactions.
In the finance market two different exchange rates are defined. In our example his is the rate for the exchange of the € to $ (exch€$) and this is the vice versa exchange rate to € (exch$€).
Requirement: In order to avoid rounding differences in a book keeping system holding the primary currency Euro, it is not allowed to calculate and to use the value of exch$€. Only the value of exch€$ is allowed to use. The value exch$€ is reserved for systems holding $ as its primary currency.
To be used:
- amountIn$ = amountIn€ * exch€$ and
- amountIn€ = amountIn$ / exch€$
Not to be used:
- exch$€ = 1 / exch€$
- amountIn€ = amountIn$ * exch$€
Requirement: A currency exchange rate has to be defined for each currency say exchPrimCurToSecCur
Requirement: Any of this calculation shall be rounded to a currency dependend number of digits after the multiplication or the divison.
Requirement: The default value of the number of digits to be rounded is six.
Requirement: Only rounded numbers are allowed to be added up.
In the next step there exist a smallest currency value. In case of the euro and the dollar it is 1 cent, in case of CHF it is 0,05 cent.
Requirement: Ledgers which represents a cash value only can handle multiple whole number amount of the smallest currency value.
Actually you get 2167,19502 Russian Rubels for one euro. In this case you can define a multiplier to reduce the size of the number. You can set this value to 1.000 and then you can say that you get 2,16719502 (1000 Rubel) for one Euro. (Der Faktor stammt aus banana.ch und wir sollten klären, ob wir den brauchen).
Basic processes
Exchange from primary currency to a secondary currency or vice versa
Let someone exchange some money of primary currency into money of secondary currency. Independently if he uses cash or a bank account, he gets a transaction report holding the data for
- the money he has spent in primary currency
- the relevant exchange rate
- the sum of the exchange fee
- the money he has got in secondary currency
The exchange fee shall be accounted against a ledger like administration costs or else.
But in normal cases there is a difference between the internal value of exchPrimCurToSecCur and the value used in the transaction report. So the result will be an exchange rate profit or an exchange rate loss.
Requirement: The accounting software shall have the option to define a ledger for the exchange rate profit and a ledger for the exchange rate loss.
TODO: One ledger for each foreign currency or one ledger for all?
Requirement: The exchange rate profit or the exchange rate loss of this transaction shall be accounted simultaneously if an exchange transaction is accounted.
Accounting of expenses and incomes
If someone spent some foreign currency money he gets a record holding a value based in the foreign currency. The cash ledger is defined in the foreign currency and the offset ledger in primary currency.
In the first case the amount can be accounted directly.
In the second case the amount can shall be converted into primary currency by using the value of the actual exchange rate and rounding to a whole number multiple of the smallest currency value.
Requirement: Expenses and incomes shall be accounted by using the actual exchange rate rounded to a whole number multiple of the smallest currency value.
Currency update
The currency rate shall be updated each month manualy or automaticaly by an office staff member. Any update implicitly creates an exchange rate profit or an exchange rate loss.
Requirement: By updating the exchange rate the exchange rate profit or the exchange rate loss value shall be calculated and accounted automatically