Projects:AverageCostRefactor/FunctionalSpecs

Contents 1 Cost Engine Refactor - Functional Specifications 1.1 Overview 1.1.1 Purpose 1.1.2 Scope 1.2 Design Considerations 1.2.1 Assumptions 1.2.2 Constraints 1.3 Functional Requirements 1.3.1 Business process definition 1.3.2 Functional requirements based on business processes 1.3.3 Functional requirements descriptions 1.4 Technical Requirements 1.5 Non-Functional Requirements 1.6 Discussion Items

Cost Engine Refactor - Functional Specifications

Overview

This project intends to deliver a new and extensible costing engine for core's Openbravo ERP.

Purpose

Current cost engine only covers Standard and Average costing methods. This project will deliver a new costing engine that will facilitate to include different costing algorithms based on modules. It will also include the possibility to manage product costs based on different dimensions such as organization or warehouse.

Scope

This project will deliver a new API to manage product costing. All core functionality based on old costing engine will be updated to support the new one.

Design Considerations

Assumptions

• It must be possible to develop new costing algorithms using modules.

Constraints

• Instances currently using costing must be properly updated to the new engine.

Functional Requirements

Business process definition

1. New algorithms available through extension modules.
2. Default algorithms: Standard and Average.
3. User configurable dimensions:
   1. Warehouse
4. Deterministic cost calculation.
   1. Cost recalculation does not change previous costs.
   2. Calculated cost is stored for each transaction.
   3. Transactions are ordered based on the date they are processed on the ERP and not its movement date.
   4. The price used on the cost calculation the Order price
      1. If the Invoice price is different a Cost Adjustment is created to adjust the cost.
5. New document Cost Adjustment.
   1. Changes on calculated cost (landed cost, invoiced order, cancelled transaction,...) are included using this document.
   2. Each transaction might have different cost adjustments associated.
   3. The Cost Adjustment has a date it is applied on, which can be different than the original calculation date.
   4. Algorithms shall provide a method to populate the cost adjustment lines with the related transactions and amounts.
   5. Lines are related to the transaction it is related to, the amount to adjust and the type of adjustment (cogs or inventory)
   6. Each line has to define which document types need to be accounted.
6. Cost configuration based on legal entity and dimensions.
7. Reports have to know the last day cost was calculated.

Functional requirements based on business processes

Costing engine based on Accounting engine

Id	Requirement	Importance	Status
1.1	Background process to calculate pending transactions.	Must have	Finished
1.2	Calculate cost based on warehouse and organization. NOTE: It won't be possible to select several warehouses. When a product cost is calculated by warehouse it will be stored its cost for each warehouse.	Must have	Finished
1.3	Ability to know the algorithm used to calculate each transaction.	Must have	Finished
1.4	Ability to know the last day the cost has been calculated.	Must have	Not started
1.5	Ability to know if a transaction's cost has been calculated.	Must have	Finished
1.6	Ability to define landed cost.	Should have	Not started

Costing algorithms

Id	Requirement	Importance	Status
2.1	API definition to implement by each algorithm module: Method to generate cost. Method to calculate cost for each transactiont type. Method to get stock valuation by warehouse. Method to initialize cost adjustment lines.	Must have	Started
2.2	Standard cost algorithm.	Must have	Finished
2.3	Average cost algorithm.	Must have	Finished
2.4	FIFO cost algorithm.	Should have	Not started
2.5	LIFO cost algorithm.	Should have	Not started
2.5	Specific Identification cost algorithm.	Nice to have	Not started
2.6	Cost initialization method by algorithm.	Must have	Started

Costing configuration

Id	Requirement	Importance	Status
3.1	New window to configure costing: Fields: Costing algorithm, Warehouse (check box). Start Date, End Date	Must have	Finished
3.2	New tab on product to see product specific configurations.	Must have	Finished
3.3	New process to initialize a costing rule	Must have	Finished

Cost Adjustments

Id	Requirement	Importance	Status
4.1	New Cost Adjustment window	Must have	Not started
4.2	New Cost Adjustment process	Must have	Not started

Other functional requirements

Id	Requirement	Importance	Status
5.1	Adapt accounting to use the new engine's API	Must have	Started
5.2	Adapt existing reports to use the new engine's API	Must have	Not started

Functional requirements descriptions

In this section are described all the functional requirements to fulfill this development.

The aim of the new engine is to calculate the cost of all the Material Transactions of Products configured to have its cost calculated. Each transaction will have its cost amount calculated and stored for reporting purposes. To do so the transactions are processed ordered by the date they were logged in the ERP. Notice that this date might be different than the Movement Date of the transaction. To process all the transactions there is a background process that searches all the pending transactions to calculate its cost.

To calculate the transaction cost it is retrieved the Costing Algorithm that applies to the product. If no Costing Rule is found an exception is thrown and the process stops. As the transactions are calculated in order when one fails the following transactions won't be calculated until the problem is fixed. the cost amount of the transaction is calculated based on the Transaction Type. There is a list of implemented transaction types and how is the cost calculated for each one in the Costing Algorithm document.

The Costing Algorithm and dimensions to be used for each product are configured as Costing Rules. Each rule has to be defined for a Legal Entity and it defines the Costing Algorithm and whether the cost has to be calculated by warehouse or not. The rule applies to all the products whose cost is set to be calculated. The Costing Rules have a starting and ending date. The Starting Date is set when the rule is validated. And the Close Date is set when the rule is replaced by another one.

All Costing Rules need to be validated or initialized. The initialization process checks that the instance is migrated in case it is needed and initializes the costs to be used by the new algorithm. The Starting Date is automatically set to the date and time when the rule is validated or to a date in the past (defaulted to January 1st, 1900) meaning that the rule applies to all the previous transactions. When the new rule overwrites an existing rule, or applies to products using the old costing engine, the Starting Date will be the date when the rule is validated. If the products have previous transactions and its cost has never been calculated the starting date will be the first date. When the rule is replacing a previous rule it is necessary to close the old rule and initialize the costs on the new algorithm. This process is managed using Physical Inventories. Two physical inventories are created for each organization and warehouse the rule applies to. The closing physical inventory empties the stock of products and have its cost calculated using the previous rule. The initializing inventory fills in again the stock using the cost amounts calculated on the closing inventory and its cost is stored using the new rule.

The validation process does several checks:

• For products with a previous rule all their transactions need to be calculated.
• For products without a previous rule (nor using old engine) all their transactions need to be NOT calculated.

When it is desired to upgrade an instance using the legacy engine to the new engine is is needed to execute the Migration Process. This process applies to all the Clients so it has to be run by the System Administrator. Once the instance is migrated it won't be possible to use the legacy engine anymore. The migration is needed when the old engine is used, this is, when there are entries in the Costing table with a cost type different to Standard. This process, once checked that the migration is possible, creates a costing rule for each legal entity found in the instance. The migration is done as a two step process. On the first one the rules and inventories are created leaving the initializing inventories not processed. The user then reviews those inventories to fix the quantities and costs and process them. The second step after checking that all inventories have been processed validates all the rules.

It is possible to modify the cost calculated for a transaction on a later date, for example for landed costs or invoicing. This is done using the Cost Adjustment document. On this document is set the amount to be adjusted, the date when the cost adjustment happens and the transaction(s) the adjustment applies to. When the adjustment is processed the corresponding costing algorithm determines which transactions needs to be adjusted. Using Cost Adjustments it is possible to see the evolution of the cost related to the transaction over the time. The main scenario to use adjustments are for Purchase Invoices. The cost of the Receipts is calculated based on the related Purchase Order. When the receipt is invoiced it has to be checked if a cost adjustment is needed.

Technical Requirements

• All code shall be written as java classes using DAL.

Non-Functional Requirements

Discussion Items

Open and comment discussion items on project's Open discussion forum