Projects:InventoryStatus/Functional Specification

Contents 1 My Project - Functional Specifications 1.1 Overview 1.1.1 Purpose 1.1.2 Scope 1.1.3 References 1.2 Design Considerations 1.2.1 Assumptions 1.2.2 Dependencies 1.2.3 Constraints 1.3 Functional Requirements 1.3.1 User roles & profiles 1.3.2 Business process definition 1.3.3 User stories 1.3.4 Functional requirements based on business processes

My Project - Functional Specifications

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

Overview

Purpose

The purpose of this project is to enhance the inventory management of Openbravo ERP by adding the dimension of Inventory Status.

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

Scope

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 reservations and picking.
  • 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 Inventory Status value to each location or bin record.
• Add the possibility to manually update the Inventory Status of a Storage Detail by moving it to a virtual, AdHoc created, bin with that status.
• A new process 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).

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.

Note: the inventory status in no sense has effect on the inventory value.

References

Design Considerations

The table Inventory Status would be this:

Status	Description	Available	Netteable	Over-Issue
AVAIL	Available inventory	Yes	Yes	No
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

Assumptions

Dependencies

Constraints

Functional Requirements

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)

User stories

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.

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.

Category: Projects ERP