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.

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 hier 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) allwas shall be positive
  2. The transaction values schall 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 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 (actually this error ist not handled by the database).