My Project - Functional Specifications
This is a draft document, a preliminary set of thoughts to outline the functionality and facilitate the discussion.
The purpose of this project is to enhance the inventory management of Openbravo ERP by adding the dimensions of Inventory Status and Vendor-Consignment.
- The inventory status refers to the condition of a specific inventory (such as AVAILABLE, RETURN, DEFECT, TRANSIT) that is stored in a specific organization, warehouse and bin and for a product with a specific lot/serial and quantity. The inventory status can allow or disallow certain business processes.
- Vendor-consignment inventory is owned by the vendor while physically on-hand in the organization. The ownership transfers to the organization at the moment of sale or any other reduction of inventory such as (re-)count or scrap. The inventory is not valued and will only generate the accounts payable when reduced from inventory, except when returned to the vendor.
This project has impact on all existing functionalities that create and update inventory records. More specific:
- Ability to create/modify/delete Inventory Status with the following attributes:
- Available: Inventory that is available for any transaction.
- Netteable: Inventory that is available for planning of future supply (MRP).
- OverIssue: Inventory that is allowed to go negative. This is especially seen in manufacturing environments.
- Add a Default Inventory Status value to each location or bin record.
- Add an Inventory Status value to each inventory record.
- Add a Vendor-Consignment flag to each inventory record.
- Add a PO-Type "Consignment"
- Add the possibility to manually update the Inventory Status and Vendor-Consignment values.
- A new Change Agent that
- identifies affected reservations when a change of the inventory status reduces/increases the quantity available. Once identified, the relevant users could receive an alert about the consequence of the change in availability.
- identifies changes to Vendor-Consigned inventory and generates the related accounts payable.
Examples of inventory status values, without the intention to be complete:
- Available (YYN -> Available, Netteable, Not OverIssue, Owned/Not-Owned) can be set for all inventory that is free to be picked, for sales, production or any other purpose.
- In Transit (NYN) is not free to be sold or shipped but is expected within a limited time and for that we will take it into account for planning.
- Quarantine or Blocked (NNN) is not available nor netteable since we expect a larger duration of this status, whereas…
- ...Inspect (NYN) is also not available but is expected to be freed in a limited time.
- the inventory status in no sense has effect on the inventory value.
- the vendor-consigned inventory is not valued, eventhough the product is costed.
The table Inventory Status would be this:
|TRANSIT||Inventory left supplier but not yet received||No||Yes||No|
|INSPECT||Inventory under inspection by QA-dept.||No||Yes||No|
|QUARANTINE||Inventory rejected by QA, awaiting scrap or RTV||No||No||No|
|WIP||Inventory in process, negative allowed for backflush||Yes||Yes||Yes|
The Inventory status can be added to the inventory table as a
User roles & profiles
Business process definition
All functions that create/update/delete inventory should go through a central broker. This central broker will make sure to present only the relevant inventory to the requesting function: Reservations will only see inventory where the attribute Available is true while MRP will see all inventory where the attribute Netteable is true.
Unless overwritten, inventory will adopt the status of the location where it is created/received.
Note that moving inventory or changing the status might result in less or more quantity available and for that reason can have effect on reservations / ATP (Avail To Promise)
Story 1: Available & Not-Netteable
1. Goods are received, through a purchase order or distribution order, in the RECEIPT location before they are put-away into the storage areas or shopfloor. Here they are counted and checked on damages.
2. The RECEIPT location is setup with default inventory status (IS) “In Transit”. It is not available but will be in a matter of hours, maximum 1 day, and for that it is netteable.
3. While the stock has a not-available status, the quantity available-to-promise does not change.
4. In the RECEIPT location, this stock is not available for sales but is property of the company. The goods implicitely adopt the default-IS “In Transit” (NYN) of the RECEIPT location.
Story 2: Move to Available
1. When the stock is moved to the shopfloor, it will adopt the IS “Available” as was setup for this location.
2. The quantity available to promise (ATP) now is increased with the quantity moved to the shopfloor.
3. This ATP is the same on each medium, X-channel included.
Story 3: Move from Available to Quarantine
1. Due to a water problem, all the inventory in a certain section of the shopfloor is not selleable anymore. The shopfloor manager sets the IS of all related inventory (by location) to Quarantine and secures the area.
2. The ATP for the affected inventory is reduced with the quantity that was available in the affected section.
3. Effect 1 -> Move from Avail to Not-Avail: If the new qty available is less that the existing qty required, a message is sent to the shopfloor manager to indicate which sales are affected by the reduced inventory so that (s)he can prioritize sales. This message also includes an indication when new stock is expected with the status of that: For instance “Next planned/confirmed delivery DD-MM-YYYY under PO123456.”.
4. Effect 2 -> Move from Nett to Non-Nett: Since Quarantine is Not-Netteable, MRP will see that less quantity is netteable and, in the case that forecast, safety stock or planning parameters justify, a new planned supply is created.
Story 4: Move from Non-Netteable to Netteable
1. The water-problem was not so bad and some products are good for sales. The shopfloor manager switches the related inventory to IS “Available”.
2. As result, the quantity netteable has increased.
3. A selective MRP is initiated for the affected inventory to prevent outbound orders.
Story 5: Behavior in a sales order.
1. On creation of a sales order line, only the “Available” inventory is shown.
2. On reservation of a sales order line, only the “Available” inventory is shown.
Story 6: Negative inventory
1. A different product, a component for repairs, is on status Avail (YYN). The workorder needs 5 each of this component and physically there are 5. In the database only 4 appears.
2. On completing the workorder (backflush) the system will fail: The IS “Avail” does not allow to go negative since OverIssue = No.
3. We change the status of the inventory to “Backflush” (YYY).
4. The workorder can be completed correctly but leaves a -1 quantity of the component.
Story 7: Vendor-Consignment inventory
1. As result of the product/vendor definition, a purchase order line is flagged as vendor-consignment. Upon receipt, the inventory records are flagged 'Vendor-Consigned'.
2. As result of this flag, this inventory receipt does not execute the process for accounts payables.
3. This flag can be changed manually in the inventory management function or it can be changed as result of a sale or other flows that reduce inventory on-hand like an inventory (re-)count or scrap procedure. In any of these cases, the Vendor-Consignment flag must be switched-off prior to the sale, count or scrap transaction.
4. Upon change of this flag (on->off / off->on), the change agent detects this and (un-)processes the related accounts payable.
Functional requirements based on business processes
Deleting / De-activating an Inventory Status. An inventory status can not be deleted when there is inventory with that status.
Modifying an Inventory Status. An inventory status can not be modified when there is inventory with that status.
Open Discussion Items
Level in OB
There are not so many different functional inventory status. Without the intention to be complete we can think of these: AVAILABLE, TRANSIT, RETURN, SCRAP, RESERVED, BACKFLUSH, BLOCKED, QUALITY, SERVICE and surely more. But not hundreds, that would not serve any purpose. The inventory status-name, e.g. "AVAILABLE" most likely would be implemented as "DISPONIBLE" in a spanish environment; Their functional meaning however is in the above case identical.
So here is the doubt: Since OB allows to create several organizations / legal entities of different languages in the same client, on which level should the inventory status reside? Initially I was tempted to have it on the level of the client: Just like UoM conversions, the inventory status is universal for the client. But how then to satisfy the workers in the other cultures/languages?