Projects:RulesDrivenAccountingEngine/Specifications

Contents 1 Rules driven accounting engine - Functional Specifications 1.1 Overview 1.1.1 Purpose 1.1.2 Scope 1.2 Design Considerations 1.2.1 Assumptions 1.2.2 Dependencies 1.2.3 Constraints 1.3 Glossary 1.4 Functional Requirements 1.4.1 User roles & profiles 1.4.2 Business process definition 1.4.3 User stories 1.4.3.1 Story 1: Definition of invoice accounting 1.4.3.2 Story 2: Accounting of sales invoices with different accounts 1.4.3.3 Story 3: Accounting of remittances 1.4.4 Functional requirements based on business processes 1.4.4.1 Process definition 1.4.4.2 Process assignment 1.4.4.3 Execution of accounting processes 1.4.5 User Interface Mockups 1.5 Technical Requirements 1.6 Non-Functional Requirements 1.7 Open Discussion Items

Rules driven accounting engine - Functional Specifications

Overview

Purpose

The purpose of this project is to be able to define processes in the Application Dictionary in the same way that windows, tabs and fields are defined by an user.

The initial purpose is to define the rules to make the accounting entries of the documents but it is intended to be able to define any process of the application. Examples of these processes are the import and utilities functionalities or any process of the application like creating an invoice from a shipment.

Scope

The scope of this project is to define the creation of accounting entries from documents but with the idea of generalizing this process.

Design Considerations

The definition of processes is easier to do in a programming language (e.g., Java or script languages) but the intended users of these functionalities are not familiarized with programming. So the idea is to support both methods, be able to introduce script code or fields with the information to process the register.

The process is executed when the document is posted (the accounting process is called). The process assigned to the document is executed.

Assumptions

• Most of the accounting processes should be able to be understood by the user, so the initial templates will be done with fields.
• Anyway, more complex processes or utilities may be developed with Java procedures or scripts, which will be accessible for the user but not intended to be modified by him.
• Every document must have assigned a process for each accounting schema.
• The documents must have an accounting tab. In this tab we include the assignment of a process to the post of a document for an accounting schema.

Dependencies

Background process management (Release 2.50)

Constraints

None.

Glossary

• Process: a set of instructions that perform an operation on database tables.

Functional Requirements

User roles & profiles

The target users for this project are:

• Developer: Develop the initial templates of the processes.
• Consultant: Modifies the processes in the start-up, customizing the behavior for the needs of the customer.
• Users: common users of the application, that can made modifications to the existing processes or even define new processes.

Business process definition

Initially these processes apply to the accounting entries creation.

User stories

Story 1: Definition of invoice accounting

• The financial officer wants to account the sales invoices with the structure he has defined, with an entry for each product, an entry for each tax category and an entry for each payment.

Story 2: Accounting of sales invoices with different accounts

• The financial officer of the company wants to account in different accounts when the customer is national or international and depending of the category of the product.

Story 3: Accounting of remittances

• The financial officer wants to account a remittance grouping all the payments of the same customer.

Functional requirements based on business processes

Process definition

Num	Requirement	Importance	Status
1.1	Process definition. A process definition has the following data: Identifier of the process Description of the process Type of process (accounting, export ...). It is only informative.	Must have	To be planned
1.2	Definition process argument. They are the argument passed to the process. Each process definition argument has the following data: Name or the argument Order of the argument	Must have	To be planned
1.3	Process definition line. A process must have a process definition line for: Every output registers type (in accounting, one for each type of the accounting entries) Every register that must be updated (in accounting, currently only the head is updated to mark that it is accounted) A Process definition line is defined with: Description Order: to show the priority in the process of the process definition lines, because the result of a line can be used in the calculus of another line. Source recordset: it can be a table with a filter or a more complex recordset Check whether the operation is an insert or an update Output table. Table where the output fields are placed. It is necessary to describe for inserts and for updates. Script code. If the configurator prefers to define the process with script code this code is included here. In this case, the programmer has to move through the recordset in the code. This code is executed previously to the code of the fields.	Must have	To be planned
1.4	Process definition field. A process has the list of fields that it is going to insert or update. There may be also auxiliary fields. A Process definition field is defined with: Description Order: to show the priority in the process of the process definition fields, because the result of a field can be used in the calculus of another field. Check whether it is a temporary field. It works as a variable for the process. It will be used in later operations. Name of the temporary field. A reference to the temporary field for its use in other operations. Check whether it is defined with script code or with fields. Output field. It is one of the fields of the output table. It is not defined when it is a temporary field. It only appears when the definition is marked with fields. Output type: (It only appears when the definition is marked with fields.) 1. a field of the input recordset 2. value of a formula. Both types can be defined in the database with the same field. They are managed different only to make easier its edition. Input field. Used if the output type is 1. It only appears when the definition is marked with fields. Output value. Used if the output type is 2. The formula may include: One of the fields in the input recordset of the process definition line. A reference of the field (e.g., the category of a product from the code of the product) A formula that may include the operands: +, -, *, /; if function, lookup function (reference), and & (text joint). It only appears when the definition is marked with fields. Script code. This code is executed for each row of the recordset. It only appears when the definition is marked with script code. Check to skip. When this check is marked, the process does not insert nor update the register when the output value is true, or when it is defined with script code, if the variable skip is set to true.	Must have	To be planned

Process assignment

Num	Requirement	Importance	Status
2.1	To assign a process to the post of a document, the documents must have an accounting tab. In this tab must be the following information: An accounting schema A process It is possible to assign different processes for the same document and accounting schema.	Must have	To be planned

Execution of accounting processes

Num	Requirement	Importance	Status
3.1	When the accounting post is executed, the application look up in the table of processes of the document to determine which processes must be executed.	Must have	To be planned

User Interface Mockups

The image below is a mock up of the Process definition screen.

Pending drawing

File:N.jpg

Technical Requirements

None.

Non-Functional Requirements

None.a

Open Discussion Items

Category: Projects ERP