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

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.

transaction

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.

glm

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.

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) allwas shall be positive
  2. The transaction values schall be added or subtracted to the glm-table resp the 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 credit account
  3. The foreigen currency values of a base currency account shall allways be 0 in glm.
  4. The foreigen currency values of a foreigen currency account shall updated similary 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.