Projects:InventoryTransactionType/Functional Specification
Contents |
My Project - Functional Specifications
This is a draft document, a preliminary set of thoughts to outline the functionality and facilitate the discussion.
Overview
Inventory is created and changed in an increasing number of functionalities. Also, certain inventory transactions -such as a sales order- can be created from different modules: from the POS, from the ERP and in the future potentially through EDI. The inventory transaction history serves to track and trace all movements AND CHANGES related to inventory. The increasing number of functionalities that will be able to do that require additional columns in the inventory transaction history in order to retail full understanding of what happened, when, how and by whom.
Purpose
The purpose of this project is to enhance the control on inventory management. This is not a "visible" functionality, but one that will add robustness in the forsight of new functionalities related to Omni-channel strategy and requirements.
Scope
Statement: "All activities in Openbravo that affect the inventory, either in QUANTITY or in COST, are subject to generate an inventory transaction history record". "Activities that intent to result in an inventory change, such as the creation of a sales order, pending to be delivered, should be considered as well, possibly activated by choice on client- or organization level.
Explicitely out-of-scope is the transaction type related to financial transactions.
The scope of the project is to...
- ...implement additional or re-use existing columns to the inventory transaction history table;
- Transaction Type. A Transaction Type consists of two elements: Activity and Reason.
- Activity: Receipts (RCT), Issues (ISS), Change (CHG), Count (CNT), ...?
- Reason: Sales Order (SO), Purchase order (PO), Work Order (WO), Inventory transfer (ITR), Cycle Count (CYC), Physical Inventory (PI), Cancel&Replace (C&R), Unplanned adjustment (UAJ), etceteras.
- Business Process that initiated the inventory transaction
- User, Role.
- Transaction Type. A Transaction Type consists of two elements: Activity and Reason.
- ...adapt all related software to ensure a proper population of these columns;
- ...adapt the related reports to take into account these columns;
- ...adapt specific functionalities (Cancel&Replace) in accordance with the meaning of these columns.
References
Design Considerations
Assumptions
Inventory Transaction Type include rational combinations of the concepts as mentioned in the scope: Activity and Reason. With rational combinations we exclude for instance CNT-PO because it does not make sense. CNT-PI or CNT-CYC however are rational transaction types.
The complete list of Transaction Types will be defined in the design phase and based on existing and foreseen functionalities.
The concept of Inventory Status will not be part of the inventory transaction type (like it is in SAP) in order to avoid the exponentially increase of the number of transaction types. As such, it will be possible to execute a purchsase order receipt (RCT-PO) to any (predefined) inventory status.
Dependencies
Constraints
Glossary
Functional Requirements
User roles & profiles
Business process definition
User stories
Functional requirements based on business processes
Open Discussion Items
Most inventory transactions require a possibility to execute a full or partial 'undo' in order to quickly correct a human 'typo' error.
- For instance a purchase order receipt: Eventhough the delivery note had a receipt of 3, physically only 2 arrived. The warehouse operator executed the transaction based on the delivery note and not on the actually received quantity. After having confirmed only 2, it has to be corrected in the PO and in inventory.
In SAP this is done with a different transaction type: a 'reversal' variant of the normal transaction. In QAD this is done with the same transaction type, but allowing a negative quantity to be processed; So that a negative RCT-PO is really reducing inventory. The QAD method has the advantage that the same transaction, with the same user/role, can be used.