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

PDF Books
Show collection (0 pages)
Collections help

Search

Projects:InventoryStatus/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

Purpose

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

Scope

This project has impact on all existing functionalities that create and update inventory records. More specific:

Examples of inventory status values, without the intention to be complete:


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.

Retrieved from "http://wiki.openbravo.com/wiki/Projects:InventoryStatus/Functional_Specification"

This page has been accessed 1,306 times. This page was last modified on 3 November 2016, at 14:22. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.