Testcase requirements for the CommonAccountingTool: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
No edit summary
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
After some internal accounting problems have been fixed, I'm writing a CommonAccountingTool and it's test cases. Refering to the test software in TestCommonAccountingTool this routines will reduce an the effort of an automatic accounting process to it's minimum:
== Investigation Report ==


CommonAccountingTool commonAccountingTool =  
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 10: 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 20: Line 41:
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.  
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.  


glm  
[[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 postive 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.
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".  


exhangeRate
[[File:Exchange-rate-input.JPG]]


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 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.


transaction
[[File:Foreign-currency-accouting-petra.JPG]]


The transactions are holding the values in a_transaction_amount_n and a_amount_in_base_currency_n which - of course - are now different.  
The transactions are holding the values in a_transaction_amount_n and a_amount_in_base_currency_n which - of course - are now different.  
Line 36: Line 57:
And the exchange rate (exRt), the base currency (bsCur) and the foreign currency (forCur) are defined by the formula: bsCur = forCur/exRt.  
And the exchange rate (exRt), the base currency (bsCur) and the foreign currency (forCur) are defined by the formula: bsCur = forCur/exRt.  


glm
[[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 here the values are summed up.


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 hier the values are summed up.  
[[File:Foreign-currency-accouting-petra-glm2.JPG]]
 
== Test Requirements ==


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) allwas shall be positive
# The transaction values (a_transaction_amount_n and a_amount_in_base_currency_n) always shall be positive
# The transaction values schall be added or subtracted to the glm-table resp the fields ...
# 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 credit account
## The sign of a transaction shall turn if the account is defined as a account of type credit  
# The foreigen currency values of a base currency account shall allways be 0 in glm.
# The foreign currency values of a base currency account shall always be 0 in glm.
# The foreigen currency values of a foreigen currency account shall updated similary to the value of the base currency value.
# 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.

Base-currency-accouting-petra.JPG

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.

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 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".

Exchange-rate-input.JPG

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.

Foreign-currency-accouting-petra.JPG

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.

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 here the values are summed up.

Foreign-currency-accouting-petra-glm2.JPG

Test Requirements

So the requirements for running the tests are:

  1. The transaction values (a_transaction_amount_n and a_amount_in_base_currency_n) always shall be positive
  2. The transaction values shall be added or subtracted to the glm-table resp the appropriate data fields
    1. The sign of a transaction shall turn if it is accounted in the credit mode
    2. The sign of a transaction shall turn if the account is defined as a account of type credit
  3. The foreign currency values of a base currency account shall always be 0 in glm.
  4. The foreign currency values of a foreign currency account shall updated similarly to the value of the base currency value.
  5. 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.