Foreign Currency Transactions: Difference between revisions
Wolfganguhr (talk | contribs) |
Wolfganguhr (talk | contribs) |
||
Line 60: | Line 60: | ||
== Rounding the calculated base currency values == | == Rounding the calculated base currency values == | ||
The next question is how to round the value of a_amount_in_base_currency_n. | The next question is how to round the value of a_amount_in_base_currency_n. Refering to different literatur in the web, the first preliminary answer is: Do not round base amount values in any way | ||
But this is wrong: Let us assume, that three persons have changed some money. For simplicity let us assume that they have got exact the same exchange conditions only on three different days. This will result in three identical batches - only different dates and different cost centres. The cost centre numbers are marked with c. | |||
# Edith - c9000 - EUR 30,- | # Edith - c9000 - EUR 30,- | ||
# Charly - c9001 - EUR 30,- | # Charly - c9001 - EUR 30,- | ||
# Mary - c9002 - EUR 30,- | # Mary - c9002 - EUR 30,- | ||
If you have to produce a detailed report, then you have to produce the output ... | If you have to produce a detailed report, then you have to produce the output ... | ||
Line 76: | Line 72: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Person || Cost Centre || Foreign currency || Base currency | | Person || Cost Centre || Foreign currency || Base currency || Exact Base currency | ||
|- | |- | ||
| Edith || c9000 || 21.82 || 30.01 | | Edith || c9000 || 21.82 || 30.01 || 30.0068622476 | ||
|- | |- | ||
| Charly || c9001 || 21.82 || 30.01 | | Charly || c9001 || 21.82 || 30.01 || 30.0068622476 | ||
|- | |- | ||
| Mary || c9002 || 21.82 || 30.01 | | Mary || c9002 || 21.82 || 30.01 || 30.0068622476 | ||
|- | |- | ||
| All || . || 65.46 || 90.02 | | All || . || 65.46 || 90.02 || 90.0205867428 | ||
|} | |} | ||
This means: The correct base currency value of GBP 21.82 is EUR 30.01 but the | This means: The correct base currency value of GBP 21.82 is EUR 30.01, but if this has been accounted three times, the value of the sum is not EUR 90.03 but EUR 90.02. | ||
Furthermore: The problem arises after the second accountig process, not the third. So if you store precise data (e.g. 10 digits) you have the problem of an "revaluation after the accounting has been done. |
Revision as of 04:39, 1 March 2011
Transactions between base currency account and base currency account are as trivial as transactions between foreign currency accounts of the same currency. The most complex process is how to move above the border.
If we change the currency exchnage rate not for a transaction but an existing account, we have a Revaluation.
An Example Transaction
The best way is to get a look onto a voucher I've got by changing some money. I beg your pardon for the bad quality but is was meant to be for private use only. That was no business money.
This voucher tells us: I have changed € 30.00 into £ 21.82. The exchange rate was 1.3752 and there was a fee of £ 2.50. I'm comming form Germany and so let us assume that the base currency of my accounting system is Euro.
In order to run this accounting problem properly open petra provides an account named "Internal Transfer" and the account number is 9800.
Let us assume that we have two accounts
- 6000 Petty Cash Euro
- 6001 Petty Cash British Pound
Then we have to create a batch containing a journal in EUR and a journal in GBP. Then we have to account:
- 6000 Petty Cash € - Credit: € 30.00
- 9800 Internal Transfer € - Debit: € 30.00
This moves the € 30.00 to the Transfer-Account and then
- 9800 Internal Transfer € - Credit: £ 21.82
- 6001 Petty Cash £ - Debit: £ 21.82
moves the "pound" to the £ Petty Chash Account.
The internal currency exchange rate 1.3752 is the value for the other direction because I've changed the money in England. So the correct value is 0.727167. Actually the precision which is used for that value is 4 if USD, EUR or CHF are exchanged but I've found a 7 digit value for the exchange of USD in JPY (1.00 JPY[Japan Yen] = 0.0121800 USD).
The maximal precision defined by the openpetra data base is 10 digits and so I prefer to use this precision as default. I the future this value may be overridable by currency dependent values but not now.
Let us start only by the exchange itself - no exchange fees are accounted - will result in the following data base entries.
In this cases it is important to store the value of a_transaction_amount_n in the precision defined by the currency. This is done automatically. In case of switzerland the smalles coin is CHF 0.05 and so you cannot get only a multiple of it. No internal roundings are necessary.
Requirement: Do not round transaction amount values in any way
The next step is to calculate the accouting value base on the exchange rate and in our case this is the value of EUR 30.0068622476. Using the correct mathematical rounding rules I should have to pay EUR 30.01 for the GBP 21.82.
Now GBP 21.82 is somewhere in a petty cash and EUR 30.01 is the value which is used by the accounting system to rate this money in base currency value. So the value of € 0.01 has to be additionaly accounted. The best way is to interpret this as the very first revaluation.
So the complete accounting set in the EUR-Journal are the following transactions:
- 6000 Petty Cash € - Credit: € 30.00
- 9800 Internal Transfer € - Debit: € 30.00
- 5003 Currency Revaluation - Credit: € 0.01
- 9800 Internal Transfer € - Debit: € 0.01
and replieng the GBP-Journal
- 9800 Internal Transfer € - Credit: £ 21.82
- 6001 Petty Cash £ - Debit: £ 21.82
Rounding the calculated base currency values
The next question is how to round the value of a_amount_in_base_currency_n. Refering to different literatur in the web, the first preliminary answer is: Do not round base amount values in any way
But this is wrong: Let us assume, that three persons have changed some money. For simplicity let us assume that they have got exact the same exchange conditions only on three different days. This will result in three identical batches - only different dates and different cost centres. The cost centre numbers are marked with c.
- Edith - c9000 - EUR 30,-
- Charly - c9001 - EUR 30,-
- Mary - c9002 - EUR 30,-
If you have to produce a detailed report, then you have to produce the output ...
Person | Cost Centre | Foreign currency | Base currency | Exact Base currency |
Edith | c9000 | 21.82 | 30.01 | 30.0068622476 |
Charly | c9001 | 21.82 | 30.01 | 30.0068622476 |
Mary | c9002 | 21.82 | 30.01 | 30.0068622476 |
All | . | 65.46 | 90.02 | 90.0205867428 |
This means: The correct base currency value of GBP 21.82 is EUR 30.01, but if this has been accounted three times, the value of the sum is not EUR 90.03 but EUR 90.02.
Furthermore: The problem arises after the second accountig process, not the third. So if you store precise data (e.g. 10 digits) you have the problem of an "revaluation after the accounting has been done.