Projects:Negative Transaction Entries

Projects/Negative Transaction Values in Accounting Entries/Specifications

Contents 1 Overview 1.1 Purpose 1.2 Scope 2 Design Considerations 2.1 Assumptions 2.2 Constraints 3 Functional Requirements 3.1 User roles & profiles 3.2 Business process definition 3.3 Functional requirements based on business processes 4 Data Requirements

Overview

This document describes the plans to modify the accounting entries in Openbravo ERP to correctly support negative transaction values. As accounting transactions in Openbravo ERP are driven by the document type, this specification describes the changes planned for those documents, the effect on the transactions they create and the database structure necessary to support these changes.

A full description of the current support for Accounting Entries is described in a document that can be retrieved from the Accounting Entries and is available in the Sourceforge.

The current plan is to have this feature available by December 19th in all code lines:

• Trunk: Planned for 2.50 beta
• 2.40: Currently planned for 2.40 MP2 (provisional)
• 2.35: Currently planned for 2.35 MP11 (provisional)

Initially this feature will be be tested by engineering in all branches, but pass through QA only in the trunk. Following availability it it will be tested by QA as part of the target maintenance pack.

Purpose

Currently transaction reversal results in negative transaction values by default. As a simple example assume a sales invoice document that generates the following transactions lines:

GL	Line Type	Debit	Credit
Debtor	Sales Invoice	1,000
Revenue	Sales Invoice		1,000

On reversal of the above transaction, the system currently enforces the creation of the following negative transaction lines (sometimes called storno accounting):

GL</center>	Line Type	Debit	Credit
Debtor	Sales Invoice	-1,000
Revenue	Sales Invoice		-1,000

However auditors in many countries would expect to see the following reversing transaction lines (commonly referred to as contra accounting):

GL	Line Type	Debit	Credit
Debtor	Sales Invoice		1,000
Revenue	Sales Invoice	1,000

Negative transaction lines are considered best practice in some countries, particularly in Central and Eastern Europe. These include (but are not limited to):

• Czech Republic
• Poland
• Romania
• Russia
• Slovakia
• Ukraine

In most countries negative transaction lines are not looked upon favorably by auditors and the expectation is that transactions are reversed using contra accounting. These countries include (but are not limited to):

• Spain
• United Kingdom
• United States

Scope

Because both types of transaction reversal are legitimate (in the correct accounting context), the intention is to provide flexibility in configuration of the system setup to allow either reversal method to be used.

Following the release of this design change, system implementers will find that the behavior of reversing transactions will be controlled by the accounting schema. Additionally it will also be possible to override the behavior of an accounting schema at the level of the document type. This gives complete control to the implementer in defining the transaction reversal behavior for each combination of schema and document type. It also implies that it is up to the implementer to ensure that an appropriate reversal model is applied for the accounting environment into which the Openbravo ERP solution is intended to be deployed.

The following documents will be affected:

1. ARI & ARF: Account Receivable Invoice and Account Receivable ProForma
2. ARC: Account Receivable Credit Memo
3. API: Account Payable Vendor Invoice
4. APC: Vendor Credit Memo
5. C_Order Accounting
6. C_Bank Accounting
7. C_Cash Accounting
8. C_DP_Management Accounting
9. A_Amortization Accounting
10. M_InOut Accounting (Materials Shipment and Materials Receipt)
11. M_Inventory Accounting
12. M_Movement Accounting
13. C_Settlement Accounting - Settlement
    1. Collection cancellation (when paid)
    2. Payment cancellation (when paid)
    3. Collection cancellation for manual collections (which are not direct posting and are paid)
    4. Payment cancellation for manual payments (which are not direct posting and are paid)
    5. Payment transformation
    6. Collections transformation
14. C_Settlement Accounting - Manual settlement
    1. Collection generation
    2. Payment generation
15. C_Bank Statement
16. GL_Journal
17. M_Production

Design Considerations

Assumptions

In order not to disrupt transaction posting behavior in current implementations of Openbravo ERP 2.35 and 2.40, users applying the maintenance pack that contains the design change will find that the default option for each combination of schema and document will be to allow negative entries. This preserves current behavior and allows users the option to manually reconfigure their systems to take advantage of the increased options for transaction reversal at their leisure.

However, in Openbravo ERP 2.50 the default behavior will be to support transaction reversal by contra accounting, i.e., to disallow negative transactions unless they are specifically enabled at a schema or document level.

Constraints

1. No provision is made for capturing a reversal reason. For example:
   1. Wrong posting in the current period
   2. Erroneous posting to a closed period
   3. User error in original transaction generation.
   4. Settlement marked as received in errorIf current functionality does not support the capture of a reversal reason then it should be noted that no extension to the existing functionality is planned as part of this development.
2. For each reversal it would be normal to specify whether the reversal date is the same as or different from the posting date of the document being reversed.
   If current functionality does not support a flexibility of the reversal date then it should be noted that no extension to the existing functionality is planned as part of this development.
3. If a transaction has been reversed then it should be clearly marked as such in all reports and on-screen presentation of that transaction and a link provided to the reversing transaction.
   If current functionality does not such identification and linking then it should be noted that no extension to the existing functionality is planned as part of this development.
4. From a system integration perspective there are benefits in explicitly marking a transaction as reversed with an indicator of the reversal type (contra or storno).
   If current functionality does not support explicit identification of reversed transactions then it should be noted that no extension to the existing functionality is planned as part of this development.
5. The reversing transaction should be linked to the transaction being reversed.
   If current functionality does not support maintenance of an explicit relationship back to the reversed transactions then it should be noted that no extension to the existing functionality is planned as part of this development.

Functional Requirements

User roles & profiles

System localizers and implementors.

Business process definition

The behavior of reversing transactions will be controlled by the accounting schema. It should also be possible to override the reversal behavior by document type.

Functional requirements based on business processes

Two new fields will be created to support configuration; one at the level of the accounting scheme and the other at the level of the document. The fields will be described as “Allow negatives” and support a Yes / No option

The maintenance pack installer script for (for current versions) should set the value of these fields to “Yes” (thereby preserving the current assumed settings)

The 2.50 installation script should be adapted to set the default value of these fields to “No”.

The converter script (uplifting existing versions to 2.50) should check whether the maintenance pack has been applied to the source version. If it has been applied then the settings in the source version should be respected. If it has not been applied then the settings in the target version should be “Yes” (RM: The alternative is to require that the latest maintenance pack is applied prior to running the upgrade script as then the settings in the source version can be respected by the upgrade script.)

Data Requirements

New field ALLOWNEGATIVE added to C_ACCTSCHEMA

New table added C_ACCTSCHEMA_TABLE_DOCBASETYPE containing fields DOCBASETYPE and ALLOWNEGATIVE

Category: Projects ERP