Testcase requirements for the CommonAccountingTool: Difference between revisions
Wolfganguhr (talk | contribs) |
Wolfganguhr (talk | contribs) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Investigation Report == | == Investigation Report == | ||
After some internal accounting problems have been fixed, I'm writing a CommonAccountingTool and it's test cases. | After some internal accounting problems have been fixed, I'm writing a CommonAccountingTool and it's test cases. Referring to the test software in TestCommonAccountingTool this routines will reduce an the effort of an automatic accounting process to it's minimum: | ||
< | <pre>CommonAccountingTool commonAccountingTool = | ||
new CommonAccountingTool(LedgerNumber, "NUNIT"); | new CommonAccountingTool(LedgerNumber, "NUNIT"); | ||
commonAccountingTool.AddBaseCurrencyJournal(); | commonAccountingTool.AddBaseCurrencyJournal(); | ||
commonAccountingTool.AddBaseCurrencyTransaction( | commonAccountingTool.AddBaseCurrencyTransaction( | ||
strAccountStart, strCostCentre, "Debit-Test-10", "NUNIT", | strAccountStart, strCostCentre, "Debit-Test-10", "NUNIT", | ||
| Line 12: | Line 14: | ||
strAccountEnd, strCostCentre, "Credit-Test 10", "NUNIT", | strAccountEnd, strCostCentre, "Credit-Test 10", "NUNIT", | ||
CommonAccountingConstants.IS_CREDIT, 10); | CommonAccountingConstants.IS_CREDIT, 10); | ||
int intBatchNumber = commonAccountingTool.CloseSaveAndPost();</ | |||
int intBatchNumber = commonAccountingTool.CloseSaveAndPost();</pre> | |||
Or in case of a foreign currency accounting: | |||
<pre>CommonAccountingTool commonAccountingTool = | |||
new CommonAccountingTool(LedgerNumber, "NUNIT"); | |||
commonAccountingTool.AddForeignCurrencyJournal("GBP", 0.3m); | |||
commonAccountingTool.AddForeignCurrencyTransaction( | |||
strAccountStart, strCostCentre, "Credit GBP 100", "NUNIT", | |||
CommonAccountingConstants.IS_CREDIT, 333.33m, 100); | |||
commonAccountingTool.AddForeignCurrencyTransaction( | |||
strAccountEnd, strCostCentre, "Debit GBP 100", "NUNIT", | |||
CommonAccountingConstants.IS_DEBIT, 333.33m , 100); | |||
int intBatchNumber = commonAccountingTool.CloseSaveAndPost();</pre> | |||
A set of useful default values is used too and there are some properties to overwrite this. | A set of useful default values is used too and there are some properties to overwrite this. | ||
| Line 24: | Line 43: | ||
[[File:Base-currency-accouting-petra-glm.JPG]] | [[File:Base-currency-accouting-petra-glm.JPG]] | ||
The glm table is a sub total table which may help to reduce the calculation expense by creating some reports. The column a_ytd_actual_base_n yiels the result of the difference of both values (10-5). Both values are | The glm table is a sub total table which may help to reduce the calculation expense by creating some reports. The column a_ytd_actual_base_n yiels the result of the difference of both values (10-5). Both values are positive in 6000 and in 9800 because 6000 is a debit account and 9800 is a credit account. This account specific flag turns the sign of the decimal numbers too. | ||
In the next step we have a Foreign currency transaction. Here we first have to understand the them "exchange rate". | In the next step we have a Foreign currency transaction. Here we first have to understand the them "exchange rate". | ||
| Line 40: | Line 59: | ||
[[File:Foreign-currency-accouting-petra-glm.JPG]] | [[File:Foreign-currency-accouting-petra-glm.JPG]] | ||
The glm of account 6000 shows us a summation of the base currency values and the foreign Currency values are 0. The reason for this is that 6000 is a base currency account. 6001 has been created as an foreign currency account in GBP and | The glm of account 6000 shows us a summation of the base currency values and the foreign Currency values are 0. The reason for this is that 6000 is a base currency account. 6001 has been created as an foreign currency account in GBP and here the values are summed up. | ||
[[File:Foreign-currency-accouting-petra-glm2.JPG]] | [[File:Foreign-currency-accouting-petra-glm2.JPG]] | ||
| Line 48: | Line 67: | ||
So the requirements for running the tests are: | So the requirements for running the tests are: | ||
# The transaction values (a_transaction_amount_n and a_amount_in_base_currency_n) | # The transaction values (a_transaction_amount_n and a_amount_in_base_currency_n) always shall be positive | ||
# The transaction values | # The transaction values shall be added or subtracted to the glm-table resp the appropriate data fields | ||
## The sign of a transaction shall turn if it is accounted in the credit mode | ## The sign of a transaction shall turn if it is accounted in the credit mode | ||
## The sign of a transaction shall turn if the account is defined as a account of type credit | ## The sign of a transaction shall turn if the account is defined as a account of type credit | ||
# The | # The foreign currency values of a base currency account shall always be 0 in glm. | ||
# The | # The foreign currency values of a foreign currency account shall updated similarly to the value of the base currency value. | ||
# The System shall not account anything if someone tries to account a foreign currency 2 on a foreign currency 1 account. | # The System shall not account anything if someone tries to account a foreign currency 2 on a foreign currency 1 account (actually this error ist not handled by the database). | ||
Additional Information: In the case of a foreign currency wie allways speak from the foreign currency as the "from" currency and the base currency as the "to" currency. So in case of an EUR ledger we convert from GBP to EUR. Furthermore, if we want to buy GBP, the german bank tells us something about an exchange rate of 0.8 which means that we will get GBP 0.8 for EUR 1. But in petra we have to insert the reciprocal value of 1/0.8 = 1,25. Then if we account GBP 100,- the program calculates a base currency accounting value of 100/1.25 = EUR 80. | |||
Latest revision as of 11:50, 1 April 2011
Investigation Report
After some internal accounting problems have been fixed, I'm writing a CommonAccountingTool and it's test cases. Referring to the test software in TestCommonAccountingTool this routines will reduce an the effort of an automatic accounting process to it's minimum:
CommonAccountingTool commonAccountingTool = new CommonAccountingTool(LedgerNumber, "NUNIT"); commonAccountingTool.AddBaseCurrencyJournal(); commonAccountingTool.AddBaseCurrencyTransaction( strAccountStart, strCostCentre, "Debit-Test-10", "NUNIT", CommonAccountingConstants.IS_DEBIT, 10); commonAccountingTool.AddBaseCurrencyTransaction( strAccountEnd, strCostCentre, "Credit-Test 10", "NUNIT", CommonAccountingConstants.IS_CREDIT, 10); int intBatchNumber = commonAccountingTool.CloseSaveAndPost();
Or in case of a foreign currency accounting:
CommonAccountingTool commonAccountingTool =
new CommonAccountingTool(LedgerNumber, "NUNIT");
commonAccountingTool.AddForeignCurrencyJournal("GBP", 0.3m);
commonAccountingTool.AddForeignCurrencyTransaction(
strAccountStart, strCostCentre, "Credit GBP 100", "NUNIT",
CommonAccountingConstants.IS_CREDIT, 333.33m, 100);
commonAccountingTool.AddForeignCurrencyTransaction(
strAccountEnd, strCostCentre, "Debit GBP 100", "NUNIT",
CommonAccountingConstants.IS_DEBIT, 333.33m , 100);
int intBatchNumber = commonAccountingTool.CloseSaveAndPost();
A set of useful default values is used too and there are some properties to overwrite this.
To validate the different test cases, I have investigated the result of petra.
Let us have a look on a set of 2 transactions made in Petra.I've moved € 10,- from 6800 to 9800 and later I've moved back € 5,-. The values are positive and only the debit_credit_indicator shows an implicit sign of the digit number. The values of the a_transaction_amount_n and a_amount_in_base_currency_n are identical.
The glm table is a sub total table which may help to reduce the calculation expense by creating some reports. The column a_ytd_actual_base_n yiels the result of the difference of both values (10-5). Both values are positive in 6000 and in 9800 because 6000 is a debit account and 9800 is a credit account. This account specific flag turns the sign of the decimal numbers too.
In the next step we have a Foreign currency transaction. Here we first have to understand the them "exchange rate".
The ledger itself is of type EUR and I have to insert an exchange rate from GBP to EUR in order to account an GBP value. Here I've inserted the value 0.3.
The transactions are holding the values in a_transaction_amount_n and a_amount_in_base_currency_n which - of course - are now different.
And the exchange rate (exRt), the base currency (bsCur) and the foreign currency (forCur) are defined by the formula: bsCur = forCur/exRt.
The glm of account 6000 shows us a summation of the base currency values and the foreign Currency values are 0. The reason for this is that 6000 is a base currency account. 6001 has been created as an foreign currency account in GBP and here the values are summed up.
Test Requirements
So the requirements for running the tests are:
- The transaction values (a_transaction_amount_n and a_amount_in_base_currency_n) always shall be positive
- The transaction values shall be added or subtracted to the glm-table resp the appropriate data fields
- The sign of a transaction shall turn if it is accounted in the credit mode
- The sign of a transaction shall turn if the account is defined as a account of type credit
- The foreign currency values of a base currency account shall always be 0 in glm.
- The foreign currency values of a foreign currency account shall updated similarly to the value of the base currency value.
- The System shall not account anything if someone tries to account a foreign currency 2 on a foreign currency 1 account (actually this error ist not handled by the database).
Additional Information: In the case of a foreign currency wie allways speak from the foreign currency as the "from" currency and the base currency as the "to" currency. So in case of an EUR ledger we convert from GBP to EUR. Furthermore, if we want to buy GBP, the german bank tells us something about an exchange rate of 0.8 which means that we will get GBP 0.8 for EUR 1. But in petra we have to insert the reciprocal value of 1/0.8 = 1,25. Then if we account GBP 100,- the program calculates a base currency accounting value of 100/1.25 = EUR 80.