View source | View content page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Show collection (0 pages)
Collections help


Projects:InventoryTransactionType/Functional Specification


My Project - Functional Specifications

This is a draft document, a preliminary set of thoughts to outline the functionality and facilitate the discussion.


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.


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.


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...


Design Considerations


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.




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.

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.

Closed Discussion Items

Retrieved from ""

This page has been accessed 620 times. This page was last modified on 5 February 2015, at 11:06. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.