Testcase requirements for the CommonAccountingTool

From OpenPetra Wiki
Jump to navigation Jump to search

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();

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 wie convert from GBP to EUR.