Periodic End Calculations: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by the same user not shown)
Line 22: Line 22:
# the year end has been done to set the value to the next year.  
# the year end has been done to set the value to the next year.  


Info: The number of months can be lager than 12.
Info: The number of months can be lager than 12. In some countries the 31th decembre is used as the 13th month to run some additional accounting which are required by national laws.  


== Month End ==
== Month End ==
Line 53: Line 53:
The iteration process guarantees that every account and every cost centre has been considered. In any valid combination of a cost centre code and account code, there exist a predefinded accounting target.
The iteration process guarantees that every account and every cost centre has been considered. In any valid combination of a cost centre code and account code, there exist a predefinded accounting target.


The standard target account in petra is the account 9700 which is defined in the a_account_property table and the column a_account_code_c.
== General Period End Operations Handling ==


The following reallocation rules have been detected:
=== Basic Objects ===


=== Target Account Codes for the Reallocation ===
Actually in openpetra mfinance we have to manage two different Types of period end operations the smaller period is the month and the larger period is the year, while in normal cases the year contains 12 months but in different countries one (or two?) months are added in order to account some additionally and country specific accountings.


# If a_ledger.a_ilt_account_flag_l has been set, the target account allways shall be the account ICH_ACCT (Account Code 8500) regardless of the following rules (a_ledger-values are valid for all accounts in the ledger!).
In the actual version the TCarryForwardENum (Ict.Petra.Server.MFinance.GL in GL.PeriodEnd.cs) holds the values Month and Year.  
# Otherwise the default value for the target account shall be EARNINGS-BF-ACCT (Account Code 9700)
# The default account value can be overwritten to an other value by an cost centre property which is stored in a_account_property.


[[File:A account property.JPG]]
The Object TCarryForward manages the complete switch from one period to the next one. That means TCarryForward.SetNextPeriod() moves the system to the next month if it is evaluated inside a year and it moves to the first month if it is done at the end of a year. So if someone in the future decides to include a TCarryForwardENum property like Month13, be sure that TCarryForward will be able to handle it.  


=== Target Cost Centre Codes for the Reallocation ===
The next important class is the class TPerdiodEndOperations, which is inherited by TYearEnd and in future by TMonthEnd. It supports some parameters and the main routines RunPeriodEndCheck and RunPeriodEndSequence.


# If a_ledger.a_ilt_account_flag_l has been set, the target cost centre of glm shall be used regardless of the following rules.
A check is something which only runs some tests and produces an error message or ar warning if something is wrong but a sequence is something which makes significant and relevant changes in the data base. Both routines uses a first parameter of the type AbstractPerdiodEndOperation. Inside of the main code this looks like:
# If a_ledger.a_branch_processing_l has been set, the target cost centre of glm shall be used regardless of the following rules.
# Otherwise the default value for the target cost centre shall be STANDARD-COST-CENTRE (this is the ledger number followed by "00", so in case of ledger 47 the standard is 4700)
# The default cost centre value can be overwritten to an other value by an cost centre property which is stored in a_account_property.


[[File:A account property.JPG]]
<pre>RunPeriodEndSequence(new TReallocation(ledgerInfo),
  Catalog.GetString("Reallocation of all income and expense accounts"));


Here instead of STANDARDCC the key SAMECC shall be placed.
RunPeriodEndSequence(new TGlmNewYearInit(ledgerInfo.LedgerNumber, intYear),
  Catalog.GetString("Initialize the glm-entries of the next year"));
 
RunPeriodEndSequence(new TAccountPeriodToNewYear(ledgerInfo.LedgerNumber, intYear),
  Catalog.GetString("Set the account period values to the New Year"));</pre>
 
In this example TReallocation, TGlmNewYearInit and TAccountPeriodToNewYear inherits AbstractPerdiodEndOperation and therefore the can be used as a parameter here. The constructors are different and of course the parameter list are different, but the "rest" which is done below are equivalent.
 
The AbstractPerdiodEndOperation supports a property that enables to pass the standard parameters blnIsInInfoMode and the VerificationResultCollection.
 
Then the property JobSize is the very first calculation of the object. This value shall report the '''real''' number of affected data base records. This routine has to detect each record and more important it has to decide if the requested operation has been done or not. Let us assume a System crash betwee the TReallocation has been done and TGlmNewYearInit is actually not done. It is not allowed to do the TReallocation a second time in order to to a TGlmNewYearInit.
 
So JobSize has to
 
# find all records which really need to be changed.
# only to report the number of jobs without doing it.
 
And after the JobSize has been called and after the JobSize was not zero, the next abstract routine is called RunEndOfPeriodOperation(). Here all database transactions shall be done but only and only if blnIsInInfoMode is false and if blnCriticalErrors is false.
 
And for a final test the last abstract routine will be called and this is GetActualizedClone(). As shown above in RunPeriodEndSequence you have to create an internal duplicate of TReallocation(ledgerInfo) for example. This object is created after the changes has been written to the database and so the JobSize of the new object shall be zero.
 
If the first object reports a JobSize of zero there is nothing to do and only a user message will be generated. But if the second object reports a non zero value, this will be interpreted as a critical error and this will switch of all the following data base operations.
 
=== Errors ===
 
In Openpetra a set of different error levels exists:
 
# a standard information like "There is nothing to do ...". After such a message the programm will continue. This is a VerificationResult of type "non-critical".
# a standard error message like "Missing the follwing information". An example may be the missing revaluation in the month end routine. The routine can continue the follwing check and may produce some other error messages, but it is not possible to write to the database any more. This is a VerificationResult of type "critical".
# a very hard error like "no accounting periods defined" or else. This error will result in an exception.
 
 
{| class="wikitable"
|-
! Variable !! Read from Database !! Write to Database
|-
| blnCriticalErrors || Yes || No
|-
| blnIsInInfoMode || Yes || No
|}
 
 
So inside of AbstractPerdiodEndOperation.RunPeriodEndSequence() blnIsInInfoMode and blnCriticalErrors are generating the same behaviour (use the property DoExecuteabbleCode to get the complete value).
 
This parameters are different by their management. The value blnIsInInfoMode is set before the first line of period end calculation is executed and must not be changed in the program and blnCriticalErrors is initialized with false allways and is set in case of an error inside the calculation code and used to disable the "Run ... End"-Button of the user interface.

Latest revision as of 07:09, 3 Mayıs 2011

In Accounting Systems the term "Periodic End" either means a period like a month and or a period like a year. In "older systems" you also know the period of 10 years (deletion of old data) but actually we speak about the month and the year.

Today this two periods split the state of the accounting system into three different types.

Periodic-end-stati.JPG

Actually we speak about

  1. the standard accounting
    1. standard gift batches are allowed
    2. standard batches are allowed
    3. foreign currencies are allowed
  2. the revaluated accounting
    1. standard gift batches are allowed
    2. standard batches are allowed
    3. foreign currencies are allowed
  3. the year end accounting
    1. actually unknown ...

So:

  1. the month end only can change to the status "standard accounting" if it is a month of the same year or to "year end accounting" if the last month of the year has been closed.
  2. the year end has been done to set the value to the next year.

Info: The number of months can be lager than 12. In some countries the 31th decembre is used as the 13th month to run some additional accounting which are required by national laws.

Month End

The month end will run the tests

  1. If a revaluation is done (i.e if the status "revaluated accounting" ist activated) (critical)
  2. If the system is not in the "year end accounting" (critical)
  3. If there are unposted batches (critical)
  4. If there are unposted gift batches (critical)
  5. If there are non zeroed suspense accounts (critical)
  6. If there are zeroed suspense accounts the user gets an informal message

The critical messages will disconnect any possibilities to continue.

The month end will include:

  1. Calculation of the admin fees (to be done)
  2. Calculation of the ICH fees (to be done)
  3. switch to the next month or to the "year end accounting" state

Year End

The Reallocation

Inside the routines for the year end we have the Account Reallocation. Shortly spoken it is the movement from the account values of the type Income and Expense to Equity values. Se we've go to the complete list of income- and expense accounts, iterate the list of cost centers used on that account and account them to a equity account.

The ICH-Account (in petra this are the accounts 85*) are of type Assets but they have to be reallocated to.

The iteration process guarantees that every account and every cost centre has been considered. In any valid combination of a cost centre code and account code, there exist a predefinded accounting target.

General Period End Operations Handling

Basic Objects

Actually in openpetra mfinance we have to manage two different Types of period end operations the smaller period is the month and the larger period is the year, while in normal cases the year contains 12 months but in different countries one (or two?) months are added in order to account some additionally and country specific accountings.

In the actual version the TCarryForwardENum (Ict.Petra.Server.MFinance.GL in GL.PeriodEnd.cs) holds the values Month and Year.

The Object TCarryForward manages the complete switch from one period to the next one. That means TCarryForward.SetNextPeriod() moves the system to the next month if it is evaluated inside a year and it moves to the first month if it is done at the end of a year. So if someone in the future decides to include a TCarryForwardENum property like Month13, be sure that TCarryForward will be able to handle it.

The next important class is the class TPerdiodEndOperations, which is inherited by TYearEnd and in future by TMonthEnd. It supports some parameters and the main routines RunPeriodEndCheck and RunPeriodEndSequence.

A check is something which only runs some tests and produces an error message or ar warning if something is wrong but a sequence is something which makes significant and relevant changes in the data base. Both routines uses a first parameter of the type AbstractPerdiodEndOperation. Inside of the main code this looks like:

RunPeriodEndSequence(new TReallocation(ledgerInfo),
  Catalog.GetString("Reallocation of all income and expense accounts"));

RunPeriodEndSequence(new TGlmNewYearInit(ledgerInfo.LedgerNumber, intYear),
  Catalog.GetString("Initialize the glm-entries of the next year"));

RunPeriodEndSequence(new TAccountPeriodToNewYear(ledgerInfo.LedgerNumber, intYear),
  Catalog.GetString("Set the account period values to the New Year"));

In this example TReallocation, TGlmNewYearInit and TAccountPeriodToNewYear inherits AbstractPerdiodEndOperation and therefore the can be used as a parameter here. The constructors are different and of course the parameter list are different, but the "rest" which is done below are equivalent.

The AbstractPerdiodEndOperation supports a property that enables to pass the standard parameters blnIsInInfoMode and the VerificationResultCollection.

Then the property JobSize is the very first calculation of the object. This value shall report the real number of affected data base records. This routine has to detect each record and more important it has to decide if the requested operation has been done or not. Let us assume a System crash betwee the TReallocation has been done and TGlmNewYearInit is actually not done. It is not allowed to do the TReallocation a second time in order to to a TGlmNewYearInit.

So JobSize has to

  1. find all records which really need to be changed.
  2. only to report the number of jobs without doing it.

And after the JobSize has been called and after the JobSize was not zero, the next abstract routine is called RunEndOfPeriodOperation(). Here all database transactions shall be done but only and only if blnIsInInfoMode is false and if blnCriticalErrors is false.

And for a final test the last abstract routine will be called and this is GetActualizedClone(). As shown above in RunPeriodEndSequence you have to create an internal duplicate of TReallocation(ledgerInfo) for example. This object is created after the changes has been written to the database and so the JobSize of the new object shall be zero.

If the first object reports a JobSize of zero there is nothing to do and only a user message will be generated. But if the second object reports a non zero value, this will be interpreted as a critical error and this will switch of all the following data base operations.

Errors

In Openpetra a set of different error levels exists:

  1. a standard information like "There is nothing to do ...". After such a message the programm will continue. This is a VerificationResult of type "non-critical".
  2. a standard error message like "Missing the follwing information". An example may be the missing revaluation in the month end routine. The routine can continue the follwing check and may produce some other error messages, but it is not possible to write to the database any more. This is a VerificationResult of type "critical".
  3. a very hard error like "no accounting periods defined" or else. This error will result in an exception.


Variable Read from Database Write to Database
blnCriticalErrors Yes No
blnIsInInfoMode Yes No


So inside of AbstractPerdiodEndOperation.RunPeriodEndSequence() blnIsInInfoMode and blnCriticalErrors are generating the same behaviour (use the property DoExecuteabbleCode to get the complete value).

This parameters are different by their management. The value blnIsInInfoMode is set before the first line of period end calculation is executed and must not be changed in the program and blnCriticalErrors is initialized with false allways and is set in case of an error inside the calculation code and used to disable the "Run ... End"-Button of the user interface.