Projects:Referenced Inventory/Functional Specification

Functional Requirements

Objectives and Definition

Many companies move and store goods grouped in a RollTainer, Case or Box. The generic term for these is container and includes any kind of object that can contain goods however for user-friendliness we will use the term box.

These movements can be inside a warehouse or between warehouses, and even between warehouses of cooperating business partners. The boxes may be reusable or may be disposable and have different sizes and purposes and are suitable for different types of goods. This is the use-case of Shared References as explained below. At the same time it is relevant to identify goods that are measured in a Natural Unit like mass or length, when we want to talk about a specific example of this product. This is the use-case of Unique References as explained below.

In both use-cases, identifying a product or a group of products by a single scan, and functionality that allows to create/clear the box or add/remove goods to/from that box, facilitates enormously the handling of products while avoiding the typical errors from human intervention.

Definition: Referenced Inventory is the functionality that identifies one or multiple storage details (Stock records) by using a "Reference Number". The Reference Number can have two distinct uses as illustrated below:

Reference Types

Shared References	Unique References
Shared References: Multiple Storage Details can have a Reference number that is shared with other Storage Details. Containers / boxes that are used in the Shared Reference variant, come in different formats and have different purposes and life-cycles. Scanning the Reference will identify the list of Storage Details. In this case the scanned 'object' can be a roll-cage, box or pallet with a variety of products and quantities for further distribution.	Unique References: A Storage Detail can (optionally) have a reference number, and this reference number is not re-used in other storage details. Unique Reference numbers can be used as method for Catch Weight, when product has a Base Unit of Measure in weight but specific storage details can have different weight. Scanning the Reference will point to only one Storage Detail and uniquely identify it. Unique References are used to identify a specific good and distingish it from another good that looks the same but might have different weight, lot, expiry date etcetera.
Compare Shared References to SSCC: Part of the functionality of the Reference Number is also known as the SSCC Serial Shipping Container Code. While the SSCC is mainly focussed on logistical identification and handling in distribution between business partners (For instance, the SSCC# is present in EDI / ASN), the functionality of the Reference Number not only includes these inter-warehouse logistics but also covers the intra-warehouse logistics that facilitates logistical identification and handling between bins within a warehouse.	Compare Unique References to Price lookup Code: In Openbravo Advanced Warehousing, the functionality of Unique References / Catch Weight is implicitely included in the way how Attributes are handled. All attribute values are scanneable from the front-end and attributes can be defined to represent the Unique Reference. Moreover, the most common way in Retail to deal with this functionality is through Price Lookup Code (PLU) which is also supported in the Openbravo Commerce Suite.
	Compare Unique References to Serial Number: The Reference number is functionally different fom a Serial Number in the sense that a reference number only exists during the life-time inside the warehouse or between warehouses in the distrubution process: It has no value once it has been shipped to a customer or other third party. A specific Storage Detail in a distribution chain can very well have different Reference Numbers when it was in different warehouses. In contrast, a serial number or lot/batch number identifies the stock during its complete life-time, regardless if it just was manufactured, already distributed and awaiting a customer or sold and perhaps requested a repair or service. Reference numbers and serial/lot number can co-exist as they serve different purposes.

Scope

Advanced Warehouse Operations

• The functionality will be available in Openbravo Advanced Warehousing module only.

Limited to Shared References

• As result of the comparison above, the scope of the Referenced Inventory Functionality is limited to Shared References.
• A Shared Reference can be understood as a virtual container or box.

Occupancy of bins

• From the physical perspective (from the outside) a shared reference is a (closed) box. As a result, the items inside can no longer be managed individually. Subsequently, the products inside the box will not occupy any space in the bin (referenced inventory does not count for the occupancy calculation) but the reference/box itself will occupy space according to the unit of measure conversion of the Product that is linked to the Reference Type.

Boxing and Unboxing

• There will be functionality for boxing/unboxing of Storage details.

Move and Put-Away

• There will be functionality to move and put-away boxes.

Clear Reference

• There will be functionality that clears a reference -if present- on confirmation of a task.

Functionality

Predeterminations

1. There will be only one transaction that can add or clear a reference number to/from a Storage Detail. This will be implemented with a new column Reference in the AttributeSet.
2. It will not be mandatory to assign a AttributeSet to a product: Stock from products that have no AttributeSet assigned, will still have an attribute set instance that will be used by the Reference if-and-when that stock is boxed.
3. A specific Reference Number can only be present in one bin, not in multiple bins at the same time.

Story Boards

The different flows are being explained, including error messages, in the sequences below. For a concentrated view, the story-boards below can serve.

Flow	Step-1	Step-2	Step-3	Step-4	Step-5	Step-6	Step-7
Boxing (front-end) -> Choose/Create Box (BXI-TR)	From the Front-End, press the button "Box" and move on.	Then the default popup to chose or create a new Box is shown.	The system will recognize the RefID if it exists and fill Ref-Type and Bin.	...or a new box is created and the system generates the RefID...	...in which case the RefType and Bin must be declared.	...or a new box is created with a given RefID.	When all is entered, pressing OK will create the RefID/Box.
Boxing (front-end) -> Adding products (BXI-TR)	After having created the RefID / box (see above) the box and type is shown.	Products can be added by scanning them into the box.	Here a second product is scanned and now in the box.	And products can also be added by selecting them from the list.
Boxing (back-end) (BXP-TR)	From the Back-End one or multiple -not referenced- Storage Details can be selected before pressing the Box button.	The selection is shown on the 'select&execute' screen and the quantities can be changed.	Choose the Reference Type here and move on.	Three boxing tasks to be executed: One with known RefID, one with known RefType and one where the box RefType and RefID are unknown.	Here the content of a box is shown. Nothing can be editted.
Unboxing (back-end) (BXO-TR)	From the Back-End one or multiple -referenced- Storage Details can be selected before pressing the UnBox button.	The selection is shown on the 'select&execute' screen and the quantities can be changed.	The UnBox tasks are show on the front-end of the selected operator.
(delayed) Move or Put-away a Box (back-end) (PUT-BX, MOV-BX)	From the Back-End one or multiple -referenced- Storage Details can be selected before pressing the Move or Put-Away button.	The selection is shown per box! on the 'select&execute' screen and the quantities canNOT be changed.	The Move/Put-Away tasks are shown on the front-end of the selected operator.	The Content of the box can be made visible/hidden with the buttons View/Hide.
(delayed) Put-away a Box (front-end) (PUT-BX, MOV-BX)	From the Front-End, press the button "Put-Away".	The selector shows the boxes that are available...	...and allows to select one or multiple. Subsequently the tasks are generated and assigned to the operator.
Pick from Box	Picking from a Box will show the Reference ID. Regardless if the Routing is configured with "Remove Reference"=true, the Reference will be removed.

New Entity: Reference Types

There are different types and sizes of boxes and containers so when creating a new Reference (container/box), the type must be chosen and the Reference must refer to the Reference Type.

The Reference Type has the following charateristics:

• Search Code.
• Description. A short description of the reference type.
• Modus: Unique / Shared. For now the functionality is limited to Shared References, but since it has effect on the Picking Algorithms, the flag must be created.
• Product. For Put-Away and capacity calculations, the Reference will inherit the:
  • SBG-List,
  • Alternate unit of measure.
• Sequence. A numbering sequence for this Reference Type according to standard Openbravo numbering logic.

New Window: Reference Inventory Type

• New window Reference Inventory Type where the user can create/delete/inactivate Reference Types.

New window Referenced Inventory

• To show all references (read-Only), with the reference type, when they were created and with a tab with the Storage Details when they were added / removed. It should not be possible to delete a reference because of traceability. Instead, used and not-permanent references will be inactivated.

New Inventory Transaction Type: "BXI-TR" Box-In transaction

This functionality will allow to create a new box from the Front-End and add one/multiple product(s) to it, as well as adding product to an already existing box.

• New ITT "BXI-TR" (Box-In transaction), Behave-as-group=true. This ITT is initiated exclusively from the Front-End menu "Box" and executes the new transaction that adds the Reference number to each of the selected Storage Details. It is advised to configure this ITT as Confirm=Auto to avoid that the operator is presented with a task after having 'confirmed' the boxing.
  • A similar ITT "BXP-TR" (Box-planned transaction) will be developed (Confirm=Manual) that will be initiated exclusively from the Warehouse Operations window and create tasks that can be assigned to an operator. The separation between BXI-TR and BXP-TR is required since the configuration does not allow the same ITT to be executed sometimes with Auto-Confirm, sometimes with Manual Confirm. Note that this is similar to the separation of the CYC-PI vs CNT-PI.
• New menu "Box" in the Front-End with 2 distinct flows. The user enters/scans a Reference ID and the system checks if it exists (only in online mode!).
  • If the ReferenceID exists:
    • the system shows the free Storage Details in the same bin and with same inventory status.
    • the users selects which Storage Details need to be boxed.
    • the system generates (and Auto-Confirms) the tasks that creates the Reference.
  • If the ReferenceID is blank or does not exist:
    • If Blank, the user selects a Reference Type and the system generates a new RefID according to the preferences of the Reference Type.
    • the users selects which Storage Details need to be boxed.
    • the system generates (and Auto-Confirms) the tasks that creates the Reference.
• Note that this transaction requires the device to be online in order to check if the scanned/entered RefID exists.

New Inventory Transaction Type: "BXP-TR" Box-In Planned transaction

This functionality will allow to create a new box from the Back-End by selecting one or multiple Storage details, and optionally assign the tasks to an operator.

• New ITT "BXP-TR" (Box-In Planned transaction), Behave-as-group=true. This ITT is initiated exclusively from the Back-End window Warehouse Operations with the button "Box" and generates tasks that adds the Reference number to each of the selected Storage Details. It is advised to configure this ITT as Confirm=Manual.
  • A similar ITT "BXI-TR" (Box-In transaction) is described in this wiki that executes from the Front-End. The separation between BXI-TR and BXP-TR is required since the configuration does not allow the same ITT to be executed sometimes with Auto-Confirm, sometimes with Manual Confirm. Note that this is similar to the separation of the CYC-PI vs CNT-PI.
• New button "Box" in Warehouse Operations window with 2 distinct flows. The user selects one or multiple free Storage Details and hits the button.
  • A popup for Reference ID, Reference Type and operator appears.
  • The user enters a Reference ID and the system checks if it exists (online only!, also in back-end).
  • If the ReferenceID exists:
    • the system generates the tasks and assigns them to the selected operator, if any.
  • If the ReferenceID is blank or does not exist:
    • If blank, the user has to (mandatory) select a Reference Type and the system generates a new RefID according to the preferences of the Reference Type.
    • the system generates the tasks and assigns them to the selected operator, if any.
• Note that this transaction requires the laptop/computer to be online in order to check if the scanned/entered RefID exists.

Creation of Reference Number

• Reference number must be unique within the instance. The method to generate the Reference number is by using a sequence or by scanning/typing it manually.

Change to Task entity: Column Expected Reference and ConfirmedReferenceTask

• Tasks that are created by the BXP-TR will have the value in the column ExpectedReference populated. If generated with BXI-TR the ExpectedReference is blank. As with bins, the user may deviate and confirm a different reference.

New Inventory Transaction Type: "BXO-TR" Box-Out transaction

This functionality will allow to unbox a single or multiple Storge Detail that have a Reference ID.

• New ITT "BXO-TR" (Box-Out transaction), Behave-as-Group=false. This ITT executes the new transaction that removes the Reference number to each of the selected Storage Details.
• New button "Unbox" in Warehouse Operations window.
  • The system creates tasks for the Storage Details that must be unboxed.
  • Upon Confirmation, the Reference ID will be removed but other data elements like Bin or Status will remain the same.

Change Inventory Transaction Type: "PUT-TR" Multiple Goods movements by Reference/Box

The existing PUT-TR will be used to move boxes with all its content. When the system detects that the selected Storage Detail is referenced, it will check if all related Storage Details are selected and will issue an error if not. If all related Storage details are selected, the tasks will be generated with the "Behave-as-Group" flag set to true, so that the Front-End treats the tasks as a single box.

Changes to the window Warehouse Operations

It is important that the Warehouse Operations window remains the center of stock visibility and manipulation, also for referenced inventory.

• Disable the button BOX for referenced Storage Details.
• Enable the buttons MOVE, STATUS and UNBOX for referenced Storage Details.
  • Note: It is allowed to unbox a single Storage Detail from a box.
• Enable the button PUT-AWAY if the Reference is defined with a Unit of Measure and Storage Bin Group List.
• Disable the buttons UNBOX for non-referenced Storage Details. Enable the rest of the buttons.
• The reference number must be visible in the Warehouse Operations window IN A SEPARATE COLUMN (not as part of the attribute-string) for each of the referenced storage details. It should be possible to sort/filter on it so that the user can select and see the content of a box.

Changes to warehouse put-away algorithms

• The logic for all Put-Away algorithms must be adapted to store referenced storage details as a whole and not the content. The reference type has the field Product from which it inherits the Storage Bin Group List and Alternate UOM. With this, the algorithm can detect if it deals with a reference/box or with individual storage details before listing the possible destination bins.

Changes to Occupancy calculation

• Referenced inventory does not exist for the occupancy calculation because it is not the content of the reference/box that 'occupies' but it is the reference itself, regardless if it is empty or with goods.

Effect on other Inventory Transaction Types

• The PIK-SO, PIK-DO and PIK-WE (Picking Sales order, Distribution order, Work Effort) will only consider the Storage details inside a Reference if the Reference Type allows picking.
• ISS-SO, ISS-DO, ISS-WE (Issue Sales Order, Distribution order, Work Effort)of referenced (Modus=Shared) should be executed as a group (as-is).
• RCT-PO (Receipt Purchase Order) is not relevant since the Storage Details not yet exist.
• RCT-DO (Receipt Distribution Order) of referenced (Modus=Shared) should be executed as a group (as-is).
• CNT-PI, RCT-PI and CYC-PI (Count, Recount and Cycle-Count Physical Inventory transactions) are not allowed for referenced (Modus=Shared) storage details.
• IST-TR (Inventory Status Change) is not allowed for Referenced inventory where Modus=Shared.

Change to Routing definition and Task Confirmation Process

• A new flag 'Remove Reference' must be added to the routing definition. When a task is confirmed and the routing has this flag=true, then the process will blank out the reference value of the Storage Detail. Use-case: picking of goods that are inside a box is possible and picking a product out of its box is an implicit unboxing activity. Hence, the routings that are used for picking should have this flag set.

MTR/VMA 7/feb/2018: The below "AddRef" is under discussion / to be reviewed. Note: We think that the "Add Ref" functionality will be surpassed by the AWO-roadmap project "Subsequent ITT" that can execute a movement activity with a boxing activity (or any other ITT) in serial-mode, whereas the "Add Ref" implies the parallel execution of two movements. We foresee complications in the UI and real-life operation and for now have decided to park the "Add Ref" functionality until further notice.

• A new flag 'Add Reference' must be added to the routing definition. When a task is presented and the routing has this flag=true, then the user is prompted with the Reference ID field where a value must be entered/scanned. If this value does not exist, then the field Reference Type is mandatory and the sytem will generate a new reference according to the preferences of the Reference Type.

New Processes on AWO Front-End

• New menu Box
• New menu Unbox
• Menu Status is not possible for referenced storage details.

Other changes

• The reference is visible in the transaction history as part of the attribute and marked between square brackets [reference].
• Add Reference number to Task report and Stock report.
• Add the Reference number to the webservice of the print-ID request.
• Reservations: The reservation stays with the Storage Detail after boxing.
• Packing functionality: Printing of the delivery note should show the content grouped by reference/box.
• Lookup (FE): First check if the scanned value is a Reference. If true, then show all Storage Details of that Reference.

Technical Documentation

See this wiki for the technical documentation of Referenced Inventory.