Log in / create account
Openbravo.com
Partner Portal
Issues
Blogs
Forge
University
View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

Modules:Advanced Warehouse Operations

Languages: 

English | Translate this article...

Contents

Introduction

Advanced Warehouse Operations

Advanced Warehouse Operations is a flexible solution for simple or complex, manual or automated warehouses and is prepared to connect to automated/robotized operations. It consists of a set of functionalities that enable warehouses to optimize stock and utilization while making staff more efficient and effective and increasing inventory accuracy. Abreviated as AWO, this module provides the infrastructure necessary to define warehouse structures and rules, and execute the operations through the Openbravo mobile technology as well as through the Openbravo backend functionalities. These operations include receipts, movements, pickings, replenishments, counts and several advanced operations as detailed below.

Together with a proper planning and execution of replenishments, this will have a positive effect on working capital utilization though the following direct impacts:

  1. Improved sales by avoiding stock-outs and obsoletes;
  2. Improved internal efficiency by efficiency driven operations with dynamic Task Priority and Travel Sequences.
  3. Improved internal efficiency by intuitive UI and offline-resistent mobile operations;
  4. Reduced costs by optimization of space utilization by Popularity Codes and Dynamic Capacity calculations;
  5. Reduced costs by optimization of staff;
  6. Reduced costs by preventing obsolete- and excess inventory;
  7. Reduced costs by use of common hardware components.

The power of the solution lies is the simplicity of the user interface and operator handling on the mobile devices, combined with the configuration possibilities. The simplicity of the UI hides the configuration that is capable of handling all kinds of exceptions, priorities and incidents that may occur during the management of inventory. Therefore, this documentation starts with a thourough explanation of the configuration and possibilities.

This wiki is written in two major focus points, each with several chapters:

Group of Inventory- and Supply Chain Management functionalities

The AWO module has been created in order to enhance Openbravo with the ability to do advanced warehouse operations by configurable warehouse areas and dynamic bin- and inventory determination but all to a simple and effective User Interface.

It is an important part of a set of functionalities that all together bring first class inventory and supply chain capabilities. The complete set is:

Scanners and other hardware devices for AWO

The Front-End functionality of AWO works with the same scanners / hardware set as the WebPOS / Retail Front-End. There are however also specific devices for use in warehouse environments. For more information please check this link

Licences

Roadmap Acceleration projects

Roadmap Acceleration projects are functional enhancements to Advanced Warehouse Operations that are foreseen and designed, but not yet executed. As they are in the roadmap they will eventually be executed but maybe not in the sequence or moment that a particular implementation requires. In this scenario, the development can be accelerated, prioritized, by a sponsering from the customer. The projects that are in this chapter are:

Basic Configuration

This chapter covers all basic configuration for Advanced Warehouse Operations, it is important to execute these configurations in the indicated sequence. The next chapter will cover more advanced features that can optionally be implemented at will and in any sequence.


The main new concept and paradigm-shift that is introduced with Advanced Warehouse Operations (AWO) is the concept of TASK.

Definition: A task is a defined and concise instruction to move a given product and quantity from a specified location to another specified location.

Assigned tasks on a mobile device: Concise instructions, presented by priority and travel sequence.


In the execution sense, the concept of TASKS is at odds with the concept of logistical TRANSACTIONS: Transactions, f.i. a Purchase Order Receipt, is to be executed as a whole, often by a single operator. However, this transaction can consist of many -potentially hundreds- different movements:

Front-end menu for the operator

All the goods in the container must be moved from truck to receipts area, from receipts to storage or -if relevant- to the inspection area or even directly to the shipping area for cross-docking.

The paradigm shift that is introduced with the concept of Tasks is to:

  1. Have the logistical transactions separate the transaction lines into individual tasks according to a unified definition of task;
  2. Generate these tasks based on the configuration of the Routings (R), Storage Bin Group (SBG), the capacity constraints and warehouse algorithms;
  3. Display the tasks in sequence of their priority and travel sequence and in a simple and user friendly user-interface;
  4. Update the transaction as the result of the confirmation of a task.

Nevertheless, a task is always related to a transaction. Some transactions relate to multiple tasks (picklists, PO-receipts), others to a single (cycle counts). A single-line transaction can also result into multiple tasks: for instance when the quantity to move is higher than the capacity of the receiving bin. In this case multiple tasks are created, one for each receiving bin, to satisfy the complete quantity of the movement.




The following configuration activities will guide you through the necesary steps for the Advanced Warehouse Operations module to generate the tasks.

Activity-1 - Activate Advanced Warehouse Operations on Organization level

Activating the Advanced Warehouse Operations in the Organization/Information tab will present the AWO functionality and hide other functionality from the user.

Then, make sure that the dataset for Advanced Warehouse Operations is loaded. This dataset contains several defaults that make the configuration easier, but also contain the new document types that come with Advanced Warehouse Operations and without these it will not be possible to create tasks. To do this, go to Enterprise Module management and select and process AWO.

Importing the dataset of AWO before starting the configuration will facilitate the process and avoid errors.

Activity-2 - Mapping of the Warehouse Physical space

Definition: A warehouse is a logistical unit with the purpose of storage and manipulation of goods. As such it has an address and staff that operates within the warehouse. A logical warehouse can consist of multiple buildings that share the same address and staff.

The first activity to undertake is the mapping of the physical spaces in the warehouse. The following information is needed in this step:

The reason that this is the first implementation activity is that it typically takes a lot of time for the warehouse manager to get to a consolidated and well thought through mapping, and while the warehouse manager is working on this, the consultant can focus on other areas.

External Data Load

The data that the warehouse manager needs to deliver is described in this excel template: File:Dataload template AWO.xlsx.

As from version 18Q4, the EDL capabilities for Advanced Warehouse Operations will be based on the External Data Load architecture.

Internal Routing Area (IRA)

Definition: An Internal Routing Area is an area in the warehouse where a specific activity is performed. There are two types of IRA:

This naming becomes clear when considering the question "Where do I have my inventory?". Surely, most of it will be in storage but large amounts are not in storage areas and this inventory also needs to be controlled.

Mapping of the physical spaces and routes of a typical warehouse

The major difference between the storage area and the other areas is that in storage, inventory just sits and waits until someone needs it. Whereas in all other areas that 'someone or something already requested the inventory to be there: in other words it is awaiting a "function". And since these functions move the inventory in-and-out, these areas are not restricted by capacity.

A functional IRA is when a business-activity like production, inspection or packing is performed. A Non-functional IRA is an area for a static activity like storage.

The crucial difference from a warehousing perspective is that, typically, in a functional area, the goods move in-and-out in a short time-span. As result, the concept of storage bin capacity is not relevant for the functional RA. For a non-functional IRA in contrast, the goods stay for a certain period and thus the non-functional IRA counts with many -thousands- of individual storage spaces (bins) for with the capacity concept is relevant.

Further on IRA level, there is a flag that allows or denies the picking from that RA, typically only set true for a non-functional IRA with no public access.

In the image the following (typical) IRA are shown:

Other typical IRA are:

The internal routing areas Receipts, Shipping and Storage defined for warehouse Spain, region North. Note that only the IRA "Storage" is defined as non-functional.

Storage Bin Group (SBG)

Definition: A Storage Bin Group is a group of Storage Bins with the same characteristics.

The IRA "Storage - NonPublic" is defined with several SBG for different products. There can be unlimited SBG's in each IRA. Note that the functional IRA "Receipt" and "Shipping" each have just one SBG.

Examples of SBG's in a non-functional IRA are:

Within each IRA at least one SBG must be created. Since for functional IRA, the capacity is irrelevant and goods move-in/out, the functional IRA only need just one SBG. The non-functional IRA however typically consists of numerous SBGs in order to organize the storage, minimize inventory losses and optimize space-utilization and inter-warehouse trafic.

Picking Sequence: This field is used in some Picking algorithms and serves the purpose to guide picking from preferred SBG's.

Storage Bin (SB)

Definition: A Storage Bin is the smallest unit of space (volume) in a warehouse that the organization wants to recognize. Not all SBs necesarily are of the same volume, this depends on the importance and function that the specific SB has.

In the Advanced Warehouse Operations functionality, an SB belongs to an SBG. Where the SB defines the space, capacity, coordinates etc. the SBG defines its purpose.

The SB has the following attributes:

Within each SBG at least one SB must be created. Since capacity is irrelevant and goods move-in/out, the functional IRA only needs one SBG (although more can be created).

The Storage bin with their Travel Sequence, Popularity code and Inventory Status

Travel Sequence

Definition: The travel sequence partially determines the sequence in which tasks are shown on the handheld device. The use is to show the ideal route to follow the warehouse bins and to avoid going criss-cross through the warehouse.

The primary sequence of the presentation of the task is the priority (in descending order). But when a (large) pick-list or receipts-list is generated, all related tasks will have the same priority. Then it will be the travel sequence that determines the sequence in which the bins should be visited. The third attribute that is used for task-sequencing is the bin.SearchKey, for the case that both priority and travel sequence are identical.

Note that the Travel Sequence plays a role when the tasks are presented on the screen or on paper, it is not relvant for the generation of the tasks, although the ITT will determine if the travel sequence is taken from the from-bin or from the to-bin.

The Travel Sequence in the Task is taken from the To-Bin or from the From-Bin, depending on the configuration in the Inventory Transaction Type.

Bin.Popularity Code

Definition: The popularity code of the bin indicates the relative distance of the bin to the dock or office. You can see it as an ABC-code for warehousing purposes. The popularity code is used during the put-away process if the related algorithm is configured and determined for the specific movement. See also the popularity code of the product.

Recommended use: Popular bins are close to the dock and used for fast moving goods while little popular bins are used for slow-movers. Typically the products have 3 PopCodes, similar to the ABC classification: 10 (fast movers), 20 for regular products and 30 (slow movers). The bins have more Popularity Codes: starting from 10, 11, 12, 13, all the way to 39. With this configuration, the warehouse algorithm "Put-away by PopCode" will only consider bins with a Popularity Code equal or higher than the product: So that a product with Populatiry Code 20 will skip the bins with Popularity Code 10...19 and only consider bins with Popularity Code starting from 20. With this logic we prevent that slow-movers as stored in popular bins.

Inventory Status (IS)

See this link for the Inventory Status conceptual description.

Definition: The inventory status is an attribute of a Bin and defines the IS that any inventory in that specific bin will adopt. Process: Changing the Inventory Status of a specific Storage Detail, will do the following:

  1. Check if no tasks are pending for this Storage Detail;
  2. Check if the configuration is complete;
  3. Check if the virtual bin to create already exists, if so use it and skip the next step;
  4. Create a Virtual Bin as a copy of the original bin but with the newly assigned IS. Note that virtual bins do not have capacity and occupancy is set to 100%.
  5. Move the Storage Detail from the original bin to the Virtual bin.

The IS are defined at the client level and are valid for all organizations. They define which flows are possible and which are not possible to execute through these three settings:

  1. Available y/n - defines if the specific inventory is available for general business flows like reservations and picking.
  2. Netteable y/n - defines if the specific inventory is to be taken into account for planning / MRP purposes.
  3. OverIssue y/n - defines if the specific inventory is allowed to go negative. This can happen during the picking- and the issue-transaction type.
The various Inventory Status values that are supplied with the instalation of the software.

A change of Inventory Status of a specific Storage Detail is possible with the "Status" button in the Warehouse Operations window. This button will allow to select the new Inventory Status and create On-The-Fly a new virtual bin as a copy of the existing bin, but with the new Inventory Status. Once this Virtual Bin is created, the Storage Detail is moved to the new bin. Note that unlike the other buttons, this button only executes one row at the time.

Storage Bin Capacity

Definition: Storage bin capacity is the inclusion of quantities per UoM of any or specified products or product categories. Both product and product-category can be left blanks to indicate capacity for any product / product category in the specified quantity per UoM.

The concept of Bin Capacity implies the need of Occupancy calculation. See the paragraph Occupancy calculation for the details on this.

Through Storage Bin Capacity, the Advanced Warehouse Operations module can be configured for a chaotic/random storage system or for a fixed-bin storage system.

The storage bin selected has capacity of 25 units for any product of the category "Quechua Shoes". Note that this is not a best-practice use of capacity: The capacity is best expressed in a generic UoM like Pallet (PL) so that the bin is not restricted for a specific use. The usage of the bins is defined in the SBG and SBG-List.
Storage Bin Capacity - How to use it?

Implementation advice for chaotic/random storage system: In order to use a chaotic (or random) storage system where multiple products can be stored in any bin, the bin-capacity should best be expressed in a unit of measure that is common for all products of the specific organization. The use of PL 'pallet' is a good choice for many different types of products, but is less appropiate for organizations that deal in liquids or small products like medicine.

Below a typical implementation of a dynamic/chaotic bin with capacity of 1 pallet for any product. The products should have an alternative UoM conversion to pallet so that the system 1) allows this product in this bin 2) can calculate what quantity (in Base UOM) can be stored in this bin.

Product Product-Category Quantity Unit of Measure
* * 1 PL

Implementation advise for a fixed-bin storage system: In order to use a fixed-bin storage system where a bin can only receive a certain product (or product-category), the bin should be configured with capacity for that specific product/-catagory. The Put-Away algorithms will only include bins with available capacity for the product to store. Note that products inside a Reference do not occupy capacity: It is the associated product of the Reference-Type that occupies the capacity of the bin.


The bin-capacity is defined as an 'inclusion' of the specified capacity, expressed as a quantity in a certain UoM for a certain product (or all products) or for a certain product-category (or all product-categories). Multiple capacity definitions for a specific bin have the 'or' relation, not the 'and' relation. Hence,

The bin-occupation is expressed in and used as a percentage. To illustrate this, lets assume a bin which has the capacity defined with two lines: One for a capacity for 1 pallet of the product category Beverages-Cans and another for a capacity of 40 boxes of the product "Gift-Cups". The capacity of the bin would be defined as per below.

Product Product-Category Quantity Unit of Measure
* Beverages-Cans 1 PL
Gift-Cups * 40 BX

Now note that both lines express the maximum capacity of that bin for that product/category and Qty/UoM, in other words: If, at a certain moment, there are 40 boxes of "Gift-Cups" in the bin, the bin is full. Likewise, if there are 10 boxes, 25% of the total capacity is full and a new put-away will consider this bin for the remaining 75% if the product/product category matches the specified capacity.

If we observe bin AABBCCDD in the table below, we see currently stored (remember that storage is ALWAYS in Base UoM):

Bin Product QuantityOH in BUM BUM-AUM conversion Relative bin-occupation
AABBCCDD Coca-Cola ZERO Cans 4800 CAN 9600 CANs in a PL 50% (half a pallet)
AABBCCDD Gift-Cups 320 EA 40 Each in a BX 20% (8 BX)

The above inventory results in the consolidated bin-occupancy of 70%. This percentage is used during the evaluation of capacity in the search for bins in the put-away process. So going into the logic of the put-away process, specifically into the evaluation of bins for their capacity, let's assume that we are receiving 800 EA of "Gift-Cups" and that the IR and WarehouseRule is to evaluate bin AABBCCDD. Note that:

  1. Capacity is only relevant for storge in non-functional IRA,
  2. The IR-Assignment has found the destiny IR-Area,
  3. The WarehouseRule-Assignment has sequenced the bins for the below evaluation process,

Then:

  1. we see that bin AABBCCDD has allowed capacity for "Gift-Cups" (OK, next step),
  2. we see that bin AABBCCDD has 30% free capacity (OK, next step),
  3. we know that this 30% is 30% * 40 BX = 12 BX = 480 EA (OK, next step),
  4. we can create a Task for Expected Qty 480 EA, (OK, next step)
  5. total receipt quantity (800) -/- Quantity in Tasks (480) is greater than 0 -> OK -> Iterate and continue with next bin according to the sequencing of the Warehouse Algorithm.

Activity-3 - Mapping of the Warehouse Activities

Base Task Types (BTT)

Definition: A Base Task type defines the fields that are relevant for the configuration of the routings. The Base Task Types are defined at client level and come with the installation of AWO.

The Base Task Types are predefined in the system and available for SystemAdmin only.

Inventory Transaction Types (ITT)

Definition: The Inventory Transaction Type is the definition of the logistical activity with the justifying document type. It allows the Advanced Warehouse Operation module maximum flexibility in defining the warehouse operations.

The Inventory Transaction Types defines the originating document and the activity that is performed with that document. Further it defines the Delta-behavior, where the Travel Sequences is taken from and how the fields on the Front-End should behave.

The ITT are predefined in Openbravo and can only be modified with SysAdm access.

The flag 'Behave as Group' will show tasks together as a group. Within the other tasks, the priority of a GroupTask equals the maximum priority of its sub-tasks.

Flow ITT System Action Back-End Front-End Document
Menu Button Menu Task Icon
Receipts RCT-PO Generates the AWO Receipt tasks for the selected purchase order. This ITT creates the stock and only needs the IRA-To. Purchase Order AWO-Button-BE-GR.jpg Receive AWO-Button-FE-RCT-PO.jpg Reception List
RCT-DO This ITT generates the AWO tasks to receive the stock from the in-transit location. Distribution Order(r) AWO-Button-BE-GR.jpg Receive AWO-Button-FE-RCT-DO.jpg Reception list
RCT-RMA This ITT generates the AWO tasks to receive the stock from Return from Customer. Return from Customer AWO-Button-BE-GR.jpg Receive File:AWO-Button-FE-RCT-RMA.jpg Reception list
DEV-QI Deviation to Quality Inspection. If activated in the IR and the product requires inspection, the TaskGenerator deviates from the original ITT to the ITT DEV-QI and generates the task with this. No menu nor button, functionality is automatically invoked given the configuration. AWO-Button-FE-QI.jpg Goods Movement
DEV-XD Deviation to Cross Docking. If activated in the IR and there is open demand for the product for *today*, the TaskGenerator deviates from the original ITT to the ITT DEV-XD and generates the task with this. No menu nor button, functionality is automatically invoked given the configuration. AWO-Button-FE-XD.jpg Goods Movement
Inventory Management PUT-TR Generates the AWO tasks that searches for the destiny bin in a storage area, given the configurations for IR and WA. Warehouse Operations AWO-Button-BE-PA.jpg Putaway AWO-Button-FE-PA.jpg Goods Movement
MOV-TR Generates the AWO tasks that puts the stock to a manually given destiny bin, regardless the configuration for Warehouse Algorithms. Warehouse Operations AWO-Button-BE-MOV.jpg Use "Put away" on the Front-End and overwrite To-Bin Goods Movement
IST-TR Generates the AWO tasks that moves the stock to a given new Inventory Status and creates On-The-Fly the temporary virtual bin with this status. Typically a task that is Auto-Confirmed. Warehouse Operations AWO-Button-BE-STS.jpg Status N.A. (Auto-Confirm) Goods Movement
BXP-TR Generates the AWO tasks that adds the Reference to the Storage Detail. Being invoked from the Back-End, the BXP-TR typically is a task that is Manually-Confirmed. Warehouse Operations AWO-Button-BE-BXi.jpg Not on FE AWO-Button-FE-BXi.jpg Goods Movement
BXI-TR Generates the AWO tasks that adds the Reference to the Storage Detail. Being invoked from the Front-End, the BXI-TR typically is a task that is Auto-Confirmed. Not relevant on Back-End. Box N.A. (Auto-Confirm) Goods Movement
BXO-TR Generates the AWO tasks that removes the Reference from the Storage Detail. The BXO-TR typically is a task that is Manually-Confirmed. Warehouse Operations AWO-Button-BE-BXo.jpg Unbox AWO-Button-FE-BXo.jpg Goods Movement
RPL-TR Generates the AWO tasks by invoking the IR to Replenish a picking location from a Bulk location. Scheduled as Process Request N.A. N.A. N.A. Goods Movement
ORG-TR Generates the AWO tasks by invoking the IR to Re-organize stock that is in a sub-optimum bin. Scheduled as Process Request N.A. N.A. N.A. Goods Movement
PRT-TR Generates the AWO tasks by invoking the IR to print a label or group. It does not generate a Goods Movement. Tasks File:AWO-Button-BE-PRT.jpg Print N.A. (Auto-Confirm)
Physical Inventory CNT-PI Generates the AWO Count Pysical Inventory task for the selected Storage Detail. As this ITT is acting on a Storage Detail and not moving it, the IRA-From and -To are the same. Warehouse Operations AWO-Button-BE-CNT.jpg Not on FE AWO-Button-FE-CNT.jpg Physical Inventory Proposal
REC-PI Generates the AWO Re-count Pysical Inventory task for the selected Storage Detail. As this ITT is acting on a Storage Detail and not moving it, the IRA-From and -To are the same. Warehouse Operations AWO-Button-BE-REC.jpg Not on FE AWO-Button-FE-REC.jpg Physical Inventory Proposal
CYC-PI Generates the AWO Cycle-Count Pysical Inventory task for the selected Storage Detail. As this ITT is acting on a Storage Detail and not moving it, the IRA-From and -To are the same. Not relevant on Back-End. Count N.A. (Auto-Confirm) Physical Inventory Proposal
Production PIK-WE Status=Available. Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Production Run AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
PIK-WE Status=Reserved. Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Production Run AWO-Button-BE-RSV.jpg Not relevant on Front-End. Goods Movement
ISS-WE Issue ACTUAL components to the work order. Production Run AWO-Button-BE-GI.jpg Issue AWO-Button-FE-ISS-WE.jpg Issue List
RCT-WE Receive ACTUAL finished product. Production Run AWO-Button-BE-RCT+BFLUSH.jpg Receive (&Backflush) AWO-Button-FE-RCT-WE.jpg Reception List
Shipping PIK-SO Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Sales Order AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
PIK-DO Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Distribution Order(i) AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
PIK-RTS Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Return to Vendor AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
ISS-SO Generates the AWO tasks that takes the previously allocated/picked Storage Details for the given Sales order with the objective to issue the stock to the business partner. Sales Order AWO-Button-BE-GI.jpg Issue AWO-Button-FE-ISS-SO.jpg Issue List
ISS-DO Generates the AWO tasks that takes the previously allocated/picked Storage Details for the given Distribution order with the objective to issue the stock to the business partner. Distribution Order(i) AWO-Button-BE-GI.jpg Issue AWO-Button-FE-ISS-DO.jpg Issue List
ISS-RTS Generates the AWO tasks that takes the previously allocated/picked Storage Details for the given RTS with the objective to issue the stock to the business partner. Return to Vendor AWO-Button-BE-GI.jpg Issue File:AWO-Button-FE-ISS-RTS.jpg Issue List

Authorization by ITT

This functionality allows to restrict activities to the Front-End users at two separate authorization levels: Initiate and Confirm. The restrictions are configured in the following tab:

File:AWO-FE-Restrictions.jpg
In this tab you can define the actions that a front-end role/user is restricted from. For each Inventory Transaction Type it allows to restrict the activity to initiate the generation (and implicit assignment) of tasks, or to confirm tasks.
  1. Initiate Transactions: When a user wants to initiate a picking, receipt or any other ITT from the Front-End, the system checks if this ITT is not restricted for this user. Likewise, if the initiation takes place on the Back-End, the system checks if the assigned user is not restricted to confirm this ITT.
    1. If the user is restricted, an error is shown.
    2. Further, the menu-option is hidden when a user is restricted for all ITT's of that menu. E.g.: If a user is restricted for RCT-PO but not for RCT-DO, the Receive menu-option is shown. If a user is restricted for all RC-*, the Receive menu-option is hidden.
    3. As this process from the front-end also assigns the task to the user, a role/user that is allowed to initiate, is implicitely also allowed to confirm.
  2. Confirm Tasks: During the assignment-process, the system checks -both when assigned from the Back-End and from the Front-End- if the user is restricted for the related Inventory Transaction Type and, if afirmative, an error is shown. This flag can only be activated when there is no related task is assigned to the role/user.

By default nothing is restricted so all front-end users are allowed to initiate and confirm all inventory transaction types.

Task Types (TT)

Definition: A Task Type is a grouping of tasks that give the icon, priority settings and Base Task-Type to the tasks. Different IR can make use of the same TT to share the icon and priorities but handle movements in different areas or with different Front-End behavior.

The Task Type defines:

  1. the priority-base, priority-increment, both relevant for the Dynamic Priority calculation, and mnemonic and color of the tasks in the User Interface.

Note in the image how the Base Task Type is defined for the various Task Types. This corresponds to the type of goods transaction that the system will execute and is essential in the configuration. Once it is defined, it is not updateable to avoid contradictions in the configuration of the routings and routing-assignments.

The Task Types relate to warehouse activities and drive the behavior in the front-end.

Warehouse Algorithms (WA)

Definition: A Warehouse Algorithm defines the sequence of inventory (picking) or bins (put-away) that are to be considered when the system is creating a task.

Available Warehouse Algorithms

The available warehouse algorithms can be viewed using the magnifying glass in the window Warehouse Definition, tab Warehouse Algorithm Assignment. The initial set of Warehouse Algorithms will cover all common business situations. New algorithms can be developed and will be added to the existing set in future releases.

Use the magnifying glass to see all installed algorithms.

Types of Warehouse Algorithms

There are two types of algorithms:

  1. Algorithms that return a bin,
  2. Algorithms that return the requested quantity of a storage detail.
The list of current warehouse algoritms for Put-Away and, implicitely, an indication of potential warehouse algorithms. Note that with the integration of Alternative Unit of Measure there are algorithms designed to return a (multiple of) the Logistic (primary) unit of measure.

The algorithms that return a bin use as first parameter the sequence number of the StorageBinGroup.


The list of current warehouse algoritms for picking. Note that with the integration of Alternative Unit of Measure there are algorithms designed to return a (multiple of) the Logistic (primary) unit of measure.

The WA are predefined in Openbravo and can only be modified with SysAdm access.

Dynamic Priority

Part of the configuration of the warehouse activities is the setup of the background process that recalculates the priority of the tasks and, subsequently, indicates the proposed execution sequence to the operator on the mobile device.

With this mechanism, some tasks of certain task-type can raise faster in priority than others.

Example:

  1. Pickings tend to be more important than put-aways, so they get a higher Priority-Base.
  2. But you don't want the docking area to accumulate too much received material as this would obstruct the operators.
  3. So you give the Put-Away tasks a higher increment in the Task Type...
  4. ...and schedule the background priority process to run frequently, for instance every 60 minutes.
  5. With this, new Put-Aways will be lower in priority and give room for other tasks but over time their Priority will increase and avoid obstruction of the docking area.


The recurring process that recalculates the priority of the task and with that, determines the sequence of the tasks on the front-end as indication to the operator for their execution.

Priority for GroupTasks

Tasks that are defined to behave as group in the Inventory Transaction Type, are shown together below the so-called header-task. This header-task is virtual and is shown with the maximum priority of any of its sub-tasks.

Activity-4 - Mapping of the Warehouse Routes

The same mapping as above, note that the arrows represent routes.

Once the physical space in the warehouse has been defined in IRA, SBG and SB, it is time to connect the IRA into Routings (R). The arrows in the image of the warehouse are typical routes in any warehouse. These should be configured given the warehouse functions, layout and previously defined IRAs.

The R can be configured to presented and to behave in specific ways:

Note: By creating the R, only the route and its behaviour is defined. The conditions under which the R is invoked is done in the Routing-Assignment.

Routing (R)

Definition: A Routing defines the route that the goods are to follow and the behavior of the task. See Routing Assignment to understand the mechanics of the assignment of Routings. The R consist of one (1) IRA when there is just a receipt or issue and of two IRAs when there is a from- and a to- IRA relevant. The behavior is splitted in:

  1. Back-End behavior, which encapsulates logic for the generation of data for the task. The attributes that govern this are part of the Routing itself.
  2. Front-End behavior, which encapsulates logic for the presentation of data and other Front-End behavior. The attributes that govern this are part of the Front-End Configuration that is attached to the Routing.

Note on the wording of Internal Routing Area and Routing: The areas (IRA) physically are always inside a specific warehouse and for that reason are always internal routing areas. A Routing (R) can be link an Internal and with an External, for that reason it is called just Routing.

The R determines the behavior of the Back-End process / generation of the data for the task(s) and related data, by specifying the following:

  1. Manual- or Auto-Confirm,
  2. Print ID;
  3. Print Group;
  4. Deviate to ITT Quality Inspection;
  5. Deviate to ITT Cross-Docking;
  6. Subsequent ITT,

The R determines the behavior of the task once it is presented on the Front-End, see detailed configuration, by specifying the following:

  1. Show/Hide expected Qty
  2. Default the Expected value to the Confirmed Qty
  3. Default the Expected value to the Confirmed Bin-From
  4. Default the Expected value to the Confirmed Bin-To
  5. Hide / Show specific attributes of the Attribute List
  6. Require Double Confirm
  7. Require Approval on Delta
  8. Allow Attribute Override


An example of several IRs for different movements and with different parameter settings.

Confirm

The Confirm flag determines if the task will need manual confirmation of the execution or if the task is confirmed (& executed) automatically immediately after it's creation. Tasks that are confirmed automatically are visible in the Task View, with status Confirmed. If confirmed automatically the task will still execute actions like Print or Add/Remove Reference.

Print_ID

The Print_ID field in the Routing determines if a print activity should be initiated. Further configuration is needed to inform the quantity of labels, the format and printer.

Deviate to Quality Inspection

If flagged in the IR, the IR-Assignment logic will check if the product is flagged for inspection. If so, the logic will disregard the previously determined IR and will restart the IR-determination using the Inventory transaction type "DEV-QI". If an IR is found, the task will be generated with the settings of the new IR.

Deviation to Quality Inspection is activated. This is only relevant for ITT that execute a From-To, like Put-Away, Move and Pick.

Remove Reference

This functionality depends on the Referenced Inventory functionality, here you can see the configuration of it.

In the Routing, the flag Remove Reference will make the end-result is un-referenced, e.g. are unboxed / individual products. Subsequently, the characteristics of the products, like Qty, UOM and SBG-List, prevail above the characteristics of the reference/box. Therefore, the activity executed with Inventory Transaction Type, is governed by the characteristics of the individual products and ignores the characteristics of the reference.

Note that the PIK-SO, PIK-DO and PIK-WE transactions will implicitely remove the reference, if present, as well. Storage-Details inside reference-types that do not allow picking, are invisible for the picking algoritms.

Deviate to Cross Docking IR

This functionality is not yet executed. Cross Docking in AWO is the functionality that interupts the creation of the task if demand is detected for the relevant product and time window.

Under certain conditions, this R overrules the previously determined R with the purpose to send the product to the Cross Docking IRA (as per the R definition). The conditions are:

  1. It detects the open order for 40 and generates a task according to the configuration for Inventory Transaction type "DEV-XD";
  2. For the remaining quantity of 60 it generates one or multiple Put-Away tasks, depending on the configuration.

Print-as-Group

The existing Print-ID functionality prints the ID-card of a single storage detail. Like tasks are confirmed individually or as a group, we can also print a format containing a group of confirmed tasks. This is relevant in the following cases:

  1. Print Delivery note: When the group of tasks that relate to the ITT ISS-SO or ISS-DO, the group of storage details can be printed on a Delivery note.
  2. Print Receipt document: When the products from a Purchase Order are received, the group of RCT-PO tasks can be printed on the Receipt Document.

Subsequent Task generation

This functionality is not yet executed.

This functionality is similar to the deviation to Quality Inspection or to Cross Docking but with an important difference: Where the deviations to QI or to XD interrupt the Routing determination based on an inspection or cross docking requirement and generates a task based on a different ITT, the subsequent task functionality will automatically generate a new task on confirmation of the previous task and as such creates the possibility of a workflow.

For this a new column "Subsequent ITT" in the Routing is added that holds the Inventory transaction type that is invoked when the previous task is confirmed. This is particulary useful in the following environments:

Notes:

  1. The task generator will see no difference between a manual invoked ITT or an ITT invoked as result of a Subsequent Task configuration.
  2. Only ITT that can be executed with the existing information of the storage detail and from previous task(s) can be configured in the Routing:
    1. RCT-PO, RCT-DO and RCT-WO cannot be configured because they require an external event like the arrival of the truck or completing a Work Order.
    2. PIK-SO, PIK-DO and PIK-WO cannot be configured because these require an order. (Unless
    3. ISS-SO, ISS-DO and ISS-WO can be configured because the previous task hold the order details.
    4. *-PI can be configured as they only need the Storage Detail.
    5. Move cannot be configured as it needs a manually determined To Bin.
    6. Box cannot be configured as it needs a Reference Type or Reference Number.
    7. Unbox can be configured.
    8. Deviation-* cannot be configured as this ITT in itself is a result and not a beginning of a flow.
  3. Subsequent tasks are not assigned to any operator by design. This should be handled either manually or by the Operator Load Balancing functionality.

Activity-5 - Product/Warehouse characteristics

Product Parameters

The SBG-List is defined on Organization level of the product.

SBG-List

Definition: The Storage Bin Group List is the list of SBG in which the system is allowed to propose the put-away bin. The SBG are on Warehouse-level while the SBG-List is on product-level. This drives the organization to synchronize the names of the SBGs in the warehouses alike, facilitating a proper understanding of the product' storage necesities and reducing the configuration.

Product/Warehouse parameters

The SBG-List is defined on Organization level of the product.

Storage Bin

Storage Bin is the default, static bin in which a product will be stored. It is used in the WR that assigns this default storage bin.

Product.Popularity Code

Definition: The popularity code of the product is the logistical ABC-code of that product. It allows to distinguish between the popular and non-popular products or in other words fast-movers and slow-movers.

Usage: The popularity code is used during put-away process to propose the proper bin. The warehouse rule(s) that use this popularity code will sequence the allowed bins by the bin.popularity code starting the popularity code of the product. Typically three values 10, 20 and 30 are used.

Example: Finding a bin for a slow-mover with popularity code 30, the system will evaluate all bins (within the allowed SBG/SBG-List) with a bin.popularity code of 30 and higher, and as such avoiding put-away in a bin with a bin.popularity code between 10 and 29. In the case that the product is fast-mover with product.popularity code 10, the bins with bin.popularity code of 10 and higher are evaluated, to facilitate the proposal of a popular bin.

PrintID_Qty and PrintID_UoM

Through the two fields Print_IDQty and Print_ID UoM, the quantity of labels "ID" can be calculated. Further configuration is needed to define the format and the printer.

Usage: If you need three labels for each Box, specify here 3 BX. When a logistical transaction occurs and the IRS is configured to activate printing, then the quantity in BaseUM of the transaction is evaluated against these parameters to calculate the number of labels.

Example: Assume that we want 1 ID for each BX of the "Gift-Cups" (see example Bin-capacity above). When we then receive 800 Each of the "Gift-Cups" and printing is activated, the system will request 20 labels: 1 for each BX.

Activity-6 - Assignments of R and WA

Routing Assignment (R-A)

Definition: The assignment of an R to a set of conditions. The determination of the R must be succesfull in order to generate a task. If not, an error message will be shown and the configuration must be completed.

The purpose of the R-A is to determine the route and with that, the behavior at the Front-End.

There are two levels of conditions in the assignment of IR:

  1. The mandatory conditions determines if a task is to be created.
  2. The optional conditions determine for which IRA the is to be created.

Mandatory conditions

The Inventory Transaction Type and the From-IRA are both mandatory conditions:

Optional conditions

The optional conditions that determine the IR are exposed below both in writing and in image.

The IR is the first responsible for the creation of tasks as it delimites the search for bins or inventory to the IRA that is defined as the From- or To. In order to determine the proper IR (and also the Front-End behavior), the assignments can be prioritized with the below set of (optional) conditions. To establish an order of prioritization, each parameter is given a weight which at the end of the pre-assignment determines the final IR:

The weights are given in such way that two conditions of a lower priority sum less than one condition from a higher priority. Example, in relation with the image below:

The Receipt Purchase Order inventory transaction type can find different R. The image shows the use of various optional conditions to specify exceptions in the receipts flow.

Warehouse Algorithm Assignment (WA-A)

Definition: The assignment of a WA to a set of conditions. The determination of the WA starts after the determination of the IR. Both need to be successful in order to generate tasks.

The purpose of a WA is sequencing the bins (put-away) or inventory (picking) to be able to produce the optimum proposal within the limitation of the IRA as determined by the IR-A. The WAs are responsible for the determination of the Bins and Storage Details of the task, delimited by the previous determination of the IRA. The assignments can be sequenced with the column sequence and are selecteable with the set of optional conditions.

There are two levels of conditions in the assignment of WA:

  1. The mandatory conditions determines if a task is to be created.
  2. The optional conditions determine for which Bin or Storage Detail the task is to be created.

Mandatory conditions

The Inventory Transaction Type is the only mandatory condition. If there is no configuration for the ITT, the system will issue an error message.

Optional conditions

The optional conditions that determine the multiple WA's are exposed below both in writing and in image.

Unlike the IR-Assignment, the WA-Assignment can have multiple WA per set of conditions because a single WA-Assignment does not guarantee a successful return of the full requested quantity. See for example the configuration for Receipt Purchase Order in the image below:

  1. The first WA will try to merge to a bin where this product and attribute are already stored, but in multiples of the Primary Logistic Unit.
  2. The second WA will try to merge to a bin where this product and attribute are already stored, but in any quantity.
  3. The third WA will try to return the bin where this product (but not the attribute) is already stored, in a quantity that is a multiple of the Primary Logistic Unit.
  4. This continues until a bin is found. If at the end no bin is found, the system will generate a task without a destiny bin, urging the operator to find one.
Unlike the IR-Assignment, The WA-Assignment can have multiple algorithms per set of conditions using the Sequence column.

Activity-7 - Physical Inventory

There are three separate Inventory Transaction Types for this activity of counting and correcting inventory, and all three need to be correctly configured in the IR-Assignment with an IR that is linked to the Base Task Type "on" and with identical From-IRA and To-IRA.

But different to other Inventory transaction types, the *-PI ITTs do not need an algorithm, after all both the Storage detail and the bin are predetermined so there is nothing to search for.


The three ITT and their typical use are these:

All Physical Inventory tasks, regardless the ITT that was used, will show in the expected values the situation in the database and in the confirmed values the situation as verified in reality. Depending on the values in Expected and Confirmed, the following is executed:

Expected values Confirmed values Typical use Action
Empty Populated CYC-PI: When the operator encounters new unexpected stock Create Storage Detail with "Confirmed values"
Populated Empty CNT-PI, REC-PI, CYC-PI: When the system thinks there is stock but in reality there is not. Delete Storage Detail.
Populated Populated CNT-PI, REC-PI, CYC-PI: According to the system there is inventory, but not exactly the same quantity. Adjust the Storage Detail with Delta between Expected and Confirmed.

Activity-8 - Referenced Inventory

Referenced Inventory is the concept of identifying stock as part of a reference. This reference is a number that -physically speaking- refers to a box, rolltainer or any other type of container. Read here about the conceptual explanation of Referenced Inventory.

Definition of Products

The Reference type requires a product from where it inherits the Alternate UOM and the SBG-List which are used during the Put-Away process.

Definition of Reference-Type

The Reference-Type can be linked with a sequence, it must refer to a product (see image above) and can be protected against picking.

Specific note on Picking from a Reference/Box: A picking activity will always remove the reference, if any, regardless of the flag in the Routing.

Support Move and Put-Away of a Referenced Inventory

As from 18Q4 the following improvements related to Referenced Inventory are available:

  1. Move- and Put-Away of referenced inventory are presented and processed as a group, respecting the integrity of the Reference as a whole.
  2. Count/Recount/Cycle of Referenced Inventory without the need to unbox/rebox the product.
  3. Determine potential bin-locations based on the product in the associated referenced inventory type (instead of the referenced product itself) in Put-Away transactions.
  4. Determine the bin-occupancy percentage based on the product in the associated referenced inventory type (instead of the referenced product itself).

Move and Put-Away of Referenced Inventory

Moving an RI implies to move all the stock within the RI as a group. The existing AWO-concept "Behave as Group", implemented in some ITTs like RCT-PO and RCT-DO, allows to confirm a set of tasks as a group. It usually confirms all the tasks within the group at the same time, but it doesn’t really force the user to confirm them as a group. It means that the user can individually confirm a task declared as Behave as Group outside of the group, for instance by assigning tasks to multiple different operators. Besides, it also allows the user to confirm a subset of tasks in the group, or even to override confirmed fields, like quantity (to generate deltas), or locator to (so each task could perfectly confirmed in a different bin to).

This behavior is too open for the move/putaway of RI, where the operator physically moved a box, often unaware of the contents. As result:

  1. All the storage details linked to the referenced inventory must have a related task.
  2. All the tasks must be confirmed at the same time as a group. There is no possibility to individually confirm tasks.
  3. The confirmed fields must be exactly the same as the expected fields. For example, there is no possibility to create deltas.
  4. The confirmed bin-to must be exactly the same for all the tasks in the RI.

To force this behavior, the new concept "Behave as Group with Referenced Inventory" is introduced. The default is defined in the ITT and the operational value in the task. It controls whether the task can be confirmed individually or it must be confirmed as a undivideable-group. Example: MOV-TR is declared as Behave as Group with RI. This means that any task on a Referenced Storage Detail, will be marked as Behave as Group with RI. However, if we are moving a stock not related to a Reference, then the above flag will be unmarked.


In order to link the tasks together as a group, mandatory requirement to control the tasks that should be behaving as a group with RI, the document Warehouse Picking List is used. This document-type is populated for transactions that relate to the Referenced Inventory. Each indivudual Reference will have a separate Warehouse Picking List, where a new field is added that shows the associated Referenced Inventory.

In the operation, the tasks marked as "Behave as group with RI" will not be confirmed individually, but through the Warehouse Picking List document. This mechanism also forces that the Confirmed Bin-To for these tasks is the only field that can be modified and, at the same time, force the system to populate the Bin-To to all other tasks within the group. Or in other words, it’s not possible to confirm tasks inside a RI group with different confirmed bin-to, because otherwise the RI would be in two different bins at the same time (something controlled by the system).

On initiating a Put-Away or Move, the Warehouse Operations window will show a separate grid for not-referenced and for referenced inventory. As normal, the grids will continue to filter out any stock linked to a not confirmed task. In the case of the Reference grid, if any of the storage details within the RI has a not confirmed task, then the full Reference will be automatically filtered out.

Warehouse Operations: The 2 grids that show not-referenced and referenced inventory.

Count/Recount/Cycle of Referenced Inventory

Stock Adjustments from borth the BE and FE are possible also on Referenced Inventory and without the need to unbox/rebox the product.

The Count and Recount buttons in Warehouse Operations show also storage detail inside a referenced inventory. The user can select one or many storage details inside a RI, for which an individual task will be generated, regardless they belong to a RI. The Warehouse Operations window also allows the user to select at the same time stock with and without a Referenced Inventory.

Determine Potential Bin-To for Referenced Inventory

The Expected Bin-To calculation, as executed in the PA algorithms, will ignore the content of the Reference and instead use the associated product of the Reference-Type to determine the potential Bin-To. This associated product defines the SBG-List, and thus the valid range of Bin-To for this type of Reference. The sequence of steps is as follows:

  1. User generates a PutAway of a RI with several storage details.
  2. The first storage detail reaches the PA algorithms engine.
  3. The system detects it is inside the RI, so it takes into account the product defined in Referenced Inventory Type instead of the actual storage detail.
  4. The system determines the expected Bin-To (if any) and sets it.
  5. The next storage detail within the same Reference reaches the PA algorithms engine.
  6. The system detects that the Reference has already calculated a bin-to to for the previous task and automatically forces the same bin-to to the new task.

Determine Occupancy for Referenced Inventory

In the case of referenced inventory, the occupancy calculation will also ignore the product of the referenced storage detail, and instead calculate with the UOM-Conversion settings of the product that is associated with the Reference-Type.

The occupancy of any stock inside a reference will not be taken into account, but the occupancy of the reference itself.

Activity-9 - Assure access from Front-End

When logging-in from the Front-End, the system checks if the users' default organization and warehouse is defined in the warehouse definition window.

If the user has no default warehouse, it will automatically use the warehouse with the highest priority within the organization.

Further, the role of the user must have the Advanced Warehouse Operations feature.

Activity-10 - Setup Process Requests

These back ground processes should run to optimize Advanced Warehouse Operations:

Increment Task Priority

The objective of the Dynamic Priority feature, is that the priority of tasks in status Available is increased over time according to their priority-increment. The reason behind this is to prevent that tasks with a lesser priority will never be on the top of the list when new tasks with higher (base-) priority are generated. To enable this, the task-priorities must be recalculated every n-time, adding the value of the field "Priority Increment" of the task Type to the tasks.

The recurring process that recalculates the priority of the task and with that, determines the sequence of the tasks on the front-end as indication to the operator for their execution.

Recalculate Storage Bin Occupancy

The occupancy and occupancy_pending of a storage bin in a non-functional IRA are continuously updated when stock is entered or taken out of that bin or when tasks are generated for that bin. However, also adjustments to the capacity definition of a bin or adjustments to a UoM-conversion affect the Occupancy and Occupancy_pending of that bin. For that reason it is required to run the recalculation frequently; At least daily is recommended.

The Occupancy% and Occupancy_Pending% are recalculated continuously on these events:

  1. Occupancy%: When stock is added to / taken out from a bin. Typically on confirmation of a task.
  2. Occupancy_Pending%: When a Task is generated in status Available. If both From- and To- bins are defined in that task, both bins get updated.

There are however events that influence the Occupancy that are not covered automatically. For instance when a Alternative UOM conversion is changed or when bin capacity is changed. For this reason there is a background process that recalculates these fields.

The background process that recalculates the Occupancy and Occupancy_Pending of each bin in a non-functional IRA.

Verbosity for Occupancy calculation This process writes in the verbosity log each step of the calculation and warns when there are missing definitions:

Reprocess Error Import Entries

It happens, due to a variety of reasons, that the confirmation of tasks ends in an error. Even though the Front-End will show a succesful synchronization, and the backend confirmed succesful receipt, the backend was not capable to process it correctly. As result, the Goods transaction is not produced and the task-in-error is recorded in the Error window, see for details the paragraph on Offline Error-Monitoring in this Wiki.

Frequent execution of unprocessed tasks helps to keep the warehouse-reality reflected properly in the database.

Activity-11 - Retail Integration

In an environment with both Retail/POS and Advanced Warehouse Operations, it is highly recommended to indicate where the POS is allowed to consume the stock from. This is configured in the definition of the POS terminal, section Advanced Warehouse Operations, field "Internal Routing Area for Sales". Likewise, the field "Internal Routing Area for Returns" indicates where the returned stock can be placed.

Note: Both fields are optional but it is highly recommended to define them. Only if the fields are populated, the sales- or return-functionality of the POS will be restricted in the determination of the bin. If not, the POS will take or place stock from any available Bin, which might create conflicts with the AWO definition of the Warehouse.

Indicating to the POS where the stock can be reduced from and where returned stock can be placed.

Activity-12 - Run Warehouse Configuration Check

When the mandatory configuration steps are completed, it is advised to run the Warehouse Configuration Check report. This report runs a variety of checks and writes in the verbosity any incomplete configurations.

Run the Warehouse Configuration Check process for each AWO-Activated organization.
Analyze the verbosity output until no errors/warnings are reported.

Activity-13 - Activate Verbosity

The verbosity is a key functionality in helping to understand, fine-tune or correct the Advanced Warehouse configuration. It is highly recommended to activate the verbosity feature in the first weeks after Go-Live or after a change in the configuration.

As this is in essence an operational feature, it is described in detail in the paragraph on Verbosity.

The verbosity is activated per user and time frame and specifies the verbosity level.

The verbosity level can be set as follows:

Advanced Configuration

This chapter covers features that are not necesary for a correct functioning of Advanced Warehouse Operations. They refine or automate the operation and can be implemented at will and in no specific sequence. Before starting this chapter, the basic configurations should have been executed.

Warehouse Front-End Configuration

The Openbravo Advanced Warehouse Operations makes it possible to show, default or hide values/quantities and attributes of the task in the Front-End. When referring to attributes in this paragraph it is imperative that we understand the difference between header attributes and list-attributes:

Moreover, it is possible to show the same task with different Front-End behavior based on the role of the user. This answers to the following business cases:

  1. Blind Receipts: Some companies want to hide the expected quantity from the operators, but the manager should be able to see it.
  2. Multiple attributes: In situations where many attributes are relevant but required in all movements, for instance in a cold-chain where there are temperatures of different moments and movements.

The architecture is such that if nothing is configured, all will be shown. In other words, the configuration is to reduce certain details from the front-end display. The rules and configuration for the Front-End behavior are the following:

  1. If nothing is defined in the window Warehouse Front-End Configuration and the same tab under the Routing, the Front-End will always show everything.
  2. The header-attributes (Serial#, Lot# and Expiry date) are identifiers of the stock. They are only editable upon receipts (PO, WE), not during movements or counts.
In the window Warehouse Front-End configuration the profiles are defined.
The profiles can be attached to the IR and are valid for a specific role or for any role.

This architecture does not impact the generation of the task: Tasks will always be generated with the fields for the confirmed values empty. It is the Front-End that determines if and how the expected values will be shown. Tasks that are Auto-Confirmed will copy the relevant values for the 'confirmed' fields from the related 'expected' fields.


As from version 18Q3 the following additional Front-End configurations are available:

  1. Default FE-Configuration on Warehouse level. Applies to all tasks unless the Routing of the specific Task is configured with it's own FE-Configuration.
  2. Double-Confirmation. Will present the operator, after initial <Confirm>, the details of the task plus User-ID, and request a re-confirm before the back-end is invoked for processing.
  3. Authorization on Delta. Applies to positive and negative Quantity-Delta's and requests the password of the configured authorization level.
  4. Default the Confirmed and/or Show the Expected Bins. Will allow to default/show values with the purpose to demand an action from the operator.

Default FE-Configuation on Warehouse level:

Specify here the general applicable Front-End Display configuration for this warehouse.

Double Confirmation:

Specify here if the tasks-confirmation requires a double OK from the operator.

Authorization on Delta:

Specify here if a delta requires approval from a predefined officer.

Default the Confirmed and/or Show the Expected Bins:

Specify here if the From- or To- bin should be defaulted or shown.

Printing Integration

The AWO architecture is prepared to integrate with different Print Services, internal or external. The current status of the integrations is exposed below. Apart from the setup in the Print Service, there is also a setup to do in Openbravo. The setup in openbravo is limited to the following:

Internal Print Services

Roadmap acceleration project.

External Print Services

Integration with BarTender using Webservices

Configuration in Openbravo

The openbravo Advanced Warehouse Operations module will generate print requests when the printID is activated in the Routing (R).

First, we have to navigate to the Print ID Template window, where we will have the new Printing Service from the Bartender module installed before. Here we create the Templates according to the BarTender setup and link them to the URL of the BarTender server.

The BarTender printing setup in Openbravo Advanced Warehousing.

Once we have defined our webservices process with the URL of the web service, we have to define which Routings should print an ID (label) and which Printing template should be called. Optionally, a printer can be configured to override the printer-selection logic in the Print Service. To activate the printing in the Routing, set the flag Print-ID. That will show the Warehouse Printer field, and the Print ID Template field.

In the Routing we activate printing and select the template and (optionally) the warehouse printer.

When we generate Tasks from the different transaction types (Picking, Put-away, Receipt…), each task where the print-flag is set, will automatically issue a print-request on confirming the task. Furthermore, any task -regardless of the print-flag- can be printed with the Print-button on the Task-window in the backend.

The internal process that generates the JSON that will be sent to the Bartender Server, will have this default parameters:

Also it will send all attributes that are relevant for that inventory:

The printer parameter will take the Warehouse Printer field of the Routing configured previously, or -if empty- apply the Bartender printer selection logic.

Add new Parameters: This print process can be extended, and the user can add extra parameters to these default parameters which we discussed above.

To inject new parameters, all we have to do, is create a new Java class implementing the PrintingParameterHookInterface and adding the annotations:

Once it is implemented the class, there will be one method to override: @Override public Map<String, Object> getTaskParameters(OBAWOTask task) { }

This method will return the Map of the parameter names, and the parameter values. An example of a new parameter returned here is:

The system will take all the classes that implement this hook interface with the annotations that we have seen before, and will add the default parameters configured on the bartender print service plus the parameters returned from the new classes.

Example object that Openbravo AWO sends when PrintID is activated: {"productCode":"MTRC1", "productDescription":”New Product”, "productEan":"C11111", "productCategory":"My Product Category", "Supplier Type":null, "printer":"HP", "taskLocatorTo":"AAL01R00", "taskIr":"RCT to STG, ManConf", "Cage Code":null, "productBrand":"", "taskUser":"Openbravo", "taskDatetime":"2016-06-21 16:07:53.059", "taskQty":200, "IUID":"TestUid"}

Delta Management, Quantity Tolerances and Storage Detail Swap

There are different scenarios where it should be allowed to deviate from the exact quantity ordered. The business case known as Catch Weight / Variable weight is implicity addressed in these scenarios:

  1. In an area with public access, like a supermarket, where a client request 1 kg and is served with a little over or under. This scenario is treated with the Price Lookup Code (PLC) functionality, an international standard and already possible in Openbravo.
  2. In an area with no public access, like a warehouse:
    1. When the operator finds less product (in a good state) in the bin than according to the system is available. This situation is managed with Delta Management.
    2. When the operator can't take the full quantity in one go and needs to return to get the remaining quantity. Also this situation is managed with Delta Management.
    3. Products in sealed boxes with variable quantities, that are shipped to customers as-is, without opening the box. These products have in common that the variance in quantity represents a relative high value and the business does not want to consider these boxes with a typical or average quantity. This will be treated with Referenced Inventory.
    4. Products in bulk (a granel) like oranges, potatoes, etc. are stored in bulk (a granel) and Qty Confirmed will deviate from Qty Expected. This situation is solved with the functionlity of Quantity Tolerances.
    5. When the operator is instructed to get a specific lot- or serial-number and this lot/serial can't be taken easily while other lot/serials of the same product and bin are easy to get. For instance, the serial# is at the bottom of the pallet and getting it would include to unmount the pallet, get the serial# and mount it again. This situation is managed by the functionality called Storage Detail Swap.

Resuming, Advanced Warehouse Operations offers four different concepts that facilitate certain flexibility during operation. This flexibility allows, in a controlled way, that operators chose different bins, different stock or different quantity:

  1. Delta Management: Allows the operator to request a new task from the system. Note: It is the system that determines the bin or storage detail.
  2. Reference Inventory: Allows to identify boxes/cases that can hold different quantities of a specific product. Note: It is the system that determines the reference (box/case).
  3. Quantity Tolerances: Allows the operator to under- and over-confirm for bulk-products without invoking Delta Management. Note: It is the operator who determines the quantity.
  4. Storage Detail Swap: Allows the operator to chose a different attribute -e.g. Serial number-. Note: It is the operator who determines the attribute.

See this chapter for the Operational effects of these concepts.

Delta Management

Definition: Delta Management is the automatic generation of a new task when the initial task is confirmed with less than the expected quantity. These new tasks are called Delta-Tasks and are identified by the relation to the initial task as can be seen in the Task window.

The configuration needed to activate Delta Management comes default with the instalation of the AWO module. The functionality is set at the level of Inventory Transaction Types because not all ITT are relevant or subject to generate delta-tasks. Physical Inventory for instance (Count, Recount, Cycle-OTF) will not generate a delta-task because a difference in quantity is an expected outcome whereas in Put-Away or Picking it is not.

Note that the functionality of Quantity Tolerances kind of delays the Delta functionality by allowing certain level of differences.

Quantity Tolerances

The Quantity Tolerances functionality allows, for products that are marked as Variable Quantity, to over- and under- confirm without invoking the Delta Management functionality. These products typically also are measured (Base UOM) in so-called natural units

A typical tolerance for Picking of Sales Orders versus picking of Distribution Orders.

The Operational effect of Quantity Tolerances is nothing else that it 'delays' the Delta Management functionality by allowing a different Quantity Confirmed, while inside the specified tolerances. Important to mention is that this functionality only works while the device is online.

Storage Detail Swap

Storage Detail Swap, aka Attribute Override, allows the operator, when instructed to get a specific lot- or serial-number, to select another lot/serial# -of the same product- instead.

The Swap Levels are:

  1. No swapping allowed
  2. Uncompromised Stock: The system will only allow to take stock without any reservations, tasks and in an available Inventory Status.
  3. Previous + Non-Allocated Reservations: The system will only allow to take stock without any allocated reservations, tasks and in an available Inventory Status.
  4. Previous + Not-Assigned Tasks: The system will only allow to take stock without non-assigned tasks and in an available Inventory Status.
  5. Previous + Assigned Tasks: The system will only allow to take stock in an available Inventory Status.

The Swap Areas are:

  1. Same Bin: The new stock must be inside the same bin.
  2. Any Bin in the Same Internal Routing Area: The new stock must be inside the same IRA.
  3. Any Bin in the Same Warehouse: The new stock must be inside the same warehouse.
Storage Detail Swap is configured at warehouse level.

The task-type that is subject to this functionality is always a Picking task that was generated using a PK algorithm, which -by definition- is always linked to an allocated reservation, either generated by the AWO engine at task creation or previously existing if created manually.

When the user swaps the Storage Detail, the quantity of the linked stock reservation is always decreased by the quantity to be swapped. In other words: The quantity that is not being confirmed with the expected storage detail, is released.

Operator Load Balancing

Operator Load Balancing is the functionality that assigns tasks to Operators, given the Task Assignment configuration. It only affects unassigned tasks of status Available. It is the mechanism that optimizes the task-assignment and with that the operator-activity and material throughput in the warehouse.

The background process checks for the following data:

  1. The users of already assigned tasks are checked if they are still logged-in or not. If they are logged-out, the tasks will be unassigned by the process so that they can be re-assigned to users/operators that are logged-in.
  2. The "Limit of Tasks" that are loaded to the AWO-Front-End, as defined in the preferences.
  3. The default Warehouse of the users that are logged-in to the AWO-Front-End must be set. The tasks and task-assignment configuration of this default warehouse is subject to the assignment process.
The operator must have the default warehouse assigned.

Then the process will read the configuration of the tab "Task Assignment" in the Warehouse Definition window. There are two different types of assignment rules that can be configured:

  1. Apply Rule to Tasks: This type of rule will use the settings of the rule and apply them to filter the unassigned tasks. Then this subset is sequenced (priority(desc), Travel Seq(asc), bin(asc)) and assigned one-by-one to the user(s) of the selected rule.
  2. Apply Task to Rules: This type of rule will select the first unassigned task (in sequence of priority(desc), Travel Seq(asc) and bin(asc), then find the first rule (of the type "Task to Rule") that is applicable for the task and assign the user of the rule to that task.
How the different Rule-types can be used to obtain any type of sssignment.

Operator Load Balancing is particulary interesting when the users generate tasks without assigning, or even better, when the system generates tasks in the background, for instance for picking, replenishing, organizing or auditing. For these tasks, this functionality will assign the proper operator according to the configuration in the Warehouse Definition window.

Task-Assignment Configuration

The Task Assignment tab in the Warehouse Definition window allows to create the assignment configuration as per the concepts as explained in the image.

Task Assignment configuration.

Additional notes to the Task Assignment configuration:

  1. The sequence number must be unique.
  2. Most transactions have a -From and a -To value for the IRA and SBG. The flag in the Inventory Transaction Type, determines if the -From or -To value is referred to.
  3. The Popularity code of the bin, not of the product.
  4. Allow wildcards % for Travel Sequence and User.Position.
  5. Allow > and < for Popularity code
See Note2: This column Travel Sequence Bin is used to determine the Travel Sequence in the Task, and now also will be used to determine if the "From value", or "To value" of the columns IRA and SBG are relevant.

Task Assignment Process Request

The Operator Load Balancing process is a (frequently) scheduled process that will only change the field Task.User/Contact according to the Task Assignment configuration. The pocess executes the following:

The process is as follows:

  1. Select the first (by sequence number, asc) TA-rule. If the rule type = "Apply Rule to Tasks", then apply the filters of the rule to the selected tasks. This creates a subset of the tasks, still sequenced as before.
    1. Note: If there are no TA-rules then nothing is assigned. For starters, it is advisable to create the "Generic rule", see rule 99 in the example.
  2. Set Task.User/Contact to the User/Contact of the TA-rule (unless not logged-in!) until max tasks of that User/Contact.
  3. Iterate this until a) no more tasks to assign or b) all users/contacts have reached their max number of tasks.


The background process "Task Assignment" should be configured to run in the propiate frequency. It will read the configuration as described in the functional description and assign the tasks accordingly.

Run the Task Assignment process frequently to optimize operator activity.

Batched Wave picking

This functionality is not yet executed.

Configuration: In the window Warehouse definition, we create a new tab “Wave” (after Task Assignments) with the following columns:

Event (mandatory) Conditions (optional) TimeStamp (system) Explanation
Wave days Wave time ITT Order Delivery Address Customer Zip-code Carrier Channel
....F.. 12:00 PIK-SO SO123456 dd-mm-yyyy hh:mm:ss An order that came in via the online channel and the customer selected delivery Friday afternoon. As response, the system created this wave-definition.

Note1: If the customer selected ASAP, the wave is also created but with settings that will pick instantly (all wave days, time 00:00). Note2: This wave must be inactivated after the order is completely delivered.

MTWT..S 07:00 PIK-DO TechnoPark dd-mm-yyyy hh:mm:ss All DO’s for TechnoPark should be picked every working day (weekend=F+S) at 7 AM.
MTWTF.. 09:00 PIK-SO Caprabo 08*** dd-mm-yyyy hh:mm:ss All Sales orders for Caprabo within Delivery ZIP-code 08*** should be picked every working day at 9 AM.
MTWTF.. 16:00 PIK-SO DHL-24h dd-mm-yyyy hh:mm:ss At 16:00h of all days except Saturday and Sunday, we pick for the carrier DHL-24h.
MTWTFSS * PIK-SO eComm dd-mm-yyyy hh:mm:ss Any order that comes in via the eCommerce site and without specific delivery terms, will be picked in the next interval.

According to the AWO-concepts, each of these waves would result in a number of pick-tasks that are -as always- presented in sequence of priority and travel sequence. Since these tasks can belong to different orders, the picker(s) can work on different orders at the same time and that is a different approach than picking Order-by-Order.

Self-Replenishments

This functionality is not yet executed.

Definition: Intra-Warehouse Replenishments are planned internal movements, typically from a bulk storage area to a picking area, in order to prevent that the picking area will be depleted.

Often this picking area is open for general public, whereas the bulk storage area is only accesible for employees. With this functionality, stocking areas that are open for general public will trigger a replenisment request once the Quantity OnHand equals or fell below the defined minimum. Note: Inter-Warehouse Replenishments are not covered in Advanced Warehouse Operations but are part of the Distribution Orders project and FrePPLe integration.

To distinguish replenishment tasks from normal Put-Aways or Moves, we create a new ITT for Replenishment: RPL-TR

Min/Max per product per bin: In the window Warehouse definition, tab Replenishment, it will be possible to define per product and bin the minimum level and the maximum level of stock, for now expressed only in the Base UM of the product.

The setup for the Intra-Warehouse replenishment would look like this:

Product SBG Bin MinQty MaxQty UoM Comment
Quechua TieBreak size43 Tennis * 2 8 pair Generates a Replen-task when Qty drops below 2 in "Tennis". TaskQty is set to MaxQty (8) - CurrentQty in the SBG "Tennis"
Skateboard N-York * D13M10 2 5 each Generates a Replen-task when Qty drops below 2 in D13M10. TaskQty is set to MaxQty (5) - CurrentQty in the Bin D13M10

Self-Organizing

This functionality is not yet executed.

The Self-Organizing warehouse feature uses the SBG-Lists and Popularity codes that are configured in earlier chapters to determine the optimum bin and compares that to the actual bin. So, apart from scheduling the background process, there are no additional configuration steps.

Due to warehouse re-organizations, expanding or decreasing SBG's, changing popularity codes or simply manually deviated put-aways, the stock can be physically in a suboptimal bin. This functionality will detect that and generate and assign Put-Aways to relocate the stock by using a new ITT called “ORG-TR” that in the execution is the same as the PUT-TR.

Wrongly placed stock is detected and tasks are generated to optimize the warehouse.

From an operational perspective, it does not make sense to generate tasks for all suboptimal located stock since this could result in hundreds of tasks and overwhelm the operators. For that reason, this functionality counts with 2 essential parameters and a scheduled background process:

  1. Maximum number of tasks per run (Prerefence),
  2. Priority of Reorganizing tre stock and this requires the Analyzing step below:
  3. Schedule the background process that generates these tasks in alignment with the operational situation.

Analyzing step:

  1. Select all StorageDetails that are
    1. in a Non-Functional IRA and
    2. have no Task in status Available and
    3. have no Replenishment definition.
  2. For each occurrence, set Reorg-Priority parameter according to the below:
    1. Reorg-Priority 99: Stock that is outside the SBG-List of the product.
    2. Reorg-Priority 88: Stock that is inside the SBG-List but in the last SBG of that list
    3. Reorg-Priority 77: Stock that is inside the SBG-List but not in the first SBG of that list
    4. Reorg-Priority 66 and less: Stock that is in the first SBG of the SBG-List but not in the corresponding popularity code of that product. In this case, the bigger the difference between the actul bin's popularity code and the product' popularity code, the higher the Reorg-Prority should be. So we subtract (Bin.PopularityCode -/- Product.PopularityCode) and as per result we assign the Reorg-Priority, for instance:
      1. Difference => 20 (f.i. bin=>30, product=10): Reorg-Priority = 66
      2. Difference => 15 (f.i. bin=>27, product=10): Reorg-Priority = 65
      3. Difference => 10 (f.i. bin=>20, product=10): Reorg-Priority = 64
      4. Difference => 5 (f.i. bin=>16, product=10): Reorg-Priority = 63

After the analyzing step, the Self-Organizing process should create the number of tasks, as defined in the preference, by selecting the stock with the highest Reorg-Priority first.

Self-Auditing

This functionality is not yet executed.

The background process will read the rules and generate Physical Inventory Count tasks to continuously verify and improve the quality of the inventory-information and with that enhance the internal efficiency of all warehouse processes.

Predefined Rules may include:

Frequency Quantity-Delta Product-Category Business Partner
Incidental Receipt Purchase Order * *
Monthly * XYZ *
Monthly * * ABC

Operation

Role Access

The user/role should have access to the Advanced Warehouse mobile form.

Performance Considerations

Front-End

Device Performance Check

When logging in for the first time to the device, the application executes a performance test of the device and stores the result in the cache. When the cache is cleared it will execute the check the next time again.

Device Search Mode

Whether or not the devices searches with an *Exact* clause or with a *Contains* clause is determined in the following preferences:

Do you allow to search any occurrence with the *contains* clause or not?

Back-End

Extensive performance testing have been executed prior to the first version of Advanced warehouse Operations. The details can be found in this chapter.

Note that the Preference "Use-Contains" influences performance. See the preference setting below.

Preferences

These preferences currently exist:

These preferences allow to execute inventory movements outside AWO-control.
AWO-Back-End-Prefs-EmbeddedScanner.jpg
The preferences determine default behaviour.
By default this setting is enabled.
Switch-on when Alternate UoM is used.
Enable Stock Reservations.
Hide the Row(X), Stack(Y), Level(Z) of the bins.
Appearance and duration of the front-end messages.
When refreshing, already inputted but not confirmed data is lost.
Enables/Disables by default the external input device.
If set, the related sales order is invoice upon issuing the goods.

Offline Capabilities of the Front-End

The online indicator, for-information-only. Offline-mode will continue to confirm tasks.

Tasks are always generated in the back-end, because only the back-end is up-to-date with the detailed situation of all inventory, reservations and other tasks. During the generation of tasks on a Storage_Detail, the system will check if that Storage_Detail is compromised with a detailed reservation(s) or if other tasks already exist and are pending to be executed. If so, the compromised quantity of that Storage_Detail is ignored, treated as reserved, while the uncompromised quantity is available for task-creation. This mechanism protects the stock from other processes, so when a task is assigned and loaded to a front-end, this front-end can lose connectivity without risking an integrity breach of the inventory.

The front-end is designed to continue operations with the pre-loaded tasks while it is offline. The number of preloaded tasks is determined by a preference, initially set to 30 (see preferences above). The tasks can be confirmed as if the device is online. The front-end will poll continuously the network status and re-connect when possible. Once reconnected, any confirmed tasks will be transmitted to the back-end and any newly assigned task loaded to the front-end.

While the front-end is offline, it is not possible to assign/unassign tasks nor to initiate transactions in the back-end, like receipts or pickings, since these operations require information from the back-end.

The Front-End will only show tasks that have not ended in a Synchronization-error, see below paragraph on Offline Synchronizations.

Offline Error-Monitoring in the Back-End

The window below shows the task-confirmations that ended in error, either by synchronization or other causes. It also allows to re-process or delete the message. In the properly managed warehouse this window is monitored actively by the responsable officer and messages are processed or removed. It is also possible to schedule the Reprocess Syncronization Errors in the background.

The back-end window where the synchronization errors can be monitored and re-processed.

Dynamic Data Load

To import existing stock from a legacy system to Openbravo with the module Advanced Warehouse Operations installed, the preference "Allow Goods Transaction outside AWO for *" should be defined with a value "Y" before running the process. Once the import process has finished the preference should be disabled or removed.

These preferences allow to load data from an external system bypassing the AWO control.

Front-End Autentication

A user can login to the Front-End if the default warehouse of that user is created in the Warehouse Definition window.

Front-End Warehouse Restriction

The operations from the Front-End are restricted to the default warehouse to which the role of the operator is defined. This restriction applies to:

Front-End User Interface

Task presentation

Tasks are presented on the Front-End in the following way:

  1. Filtered on Task.Assigned = User and Task.Status = Available;
  2. Maximum number of tasks per Front-End as set in the Preference;
  3. Sequenced by:
    1. Task.Priority (descending);
    2. Task.Travel Sequence (ascending);
    3. To- or From Bin (ascending). The To- or From is determined by the Inventory Transaction Type.

Scanning

Advanced Warehouse Operations is designed to execute/confirm tasks by using a specific warehouse device with integrated scanner. These scanners can be equiped with a simple 1D scanning engine, a 2D scanning engine or even RFID scanning engine.

Several different concepts can be scanned: product barcodes (EAN13/UPC), lot/serial numbers, bin codes and numbers of documents like purchase order or sales order.

Scanning tasks

Currently AWO frontend allows to increase the confirmed quantity of a task by scanning the product UPC/EAN code. Also it is possile to fill some fields of the task (Locators or attribute values) by scanning the ID having selected the field in the right side of the screen.

The logic used by AWO Frontend to increase the qty is the following. 

 1. Check that code match with selected line
 2. If code match with selected line and quantity can be increased, then increase the line confirmed quantity
 3. If code match with selected line but it cannot be increased try to find another line with the same product to increase
 4. If the code does not match with the selected line then try to find in the list of task an item with that code which allows to increase the quantity (if there are several, first will be selected and increased)

If no UPC code matches found, then the system will try to set the value for current selected field of the selected line. 

 1. If locator ID is scanned and locator To is selected, then the value of locator To will be set with the locator associated with the scanned UPC/EAN code.
 2. If serialNo is selected, scanned value will be set as serial NO

Scanning the GTIN-14 code

This project is not yet executed.

The Alternate UOM functionality allows for the creating of multiple packaging levels of a SKU. Each of these packaging levels can have a unique barcode assigned to it, the so-called GTIN-14 code. When this code is scanned, the system not only identifies the product but also the quantity in Base-UOM and the packaging code.

Auto-Refresh and Reload

Static Data

Products and Bins, including Virtual bins from the inventory Status changes, are refreshed upon login only and by pressing F5 on the computer or mapped key on the device.

Dynamic Data

A refresh of the dynamic data can be requested by the Refresh button on the menu. Further, the AWO Front-End will automatically refresh and reload tasks every time the back-end is consulted. This happens -when online- after initiation of a transaction, confirmation of a task and after assign/unassign tasks. This refresh actualizes existing tasks with new priorities and loads newly assign tasks to the front-end. As a result, existing tasks might be seen in a different sequence than before due to the dynamic priority calculation of Advanced Warehouse Operations.

Indicators on Task-level

The task-icon is marked with an Green OK, Orange button or Red cross in function of the quantity confirmed and Inventory Transaction Type.

The tasks can be indicated with a green checkmark, orange ball or red cross. The meaning of this is the following:

On Attribute-level

Mainly at the point of Goods Receipts moment, the attributes are marked if they require a value. See example below.

The attributes are marked in colors that indicate if they are mandatory (and empty) or optional.

Warehouse Operations window

The window Warehouse operations shows all Storage Details and is designed to facilitate a wide range of common activities on these Storage Details that can be executed by tasks. The following buttons are available:

Further, there are tabs that show the related records for

The window Warehouse Operations with the buttons for the procedures and tabs of related information.
The task in status "Available" allows to show the additional button Confirm.

Multi-select limitation

Distinct to the standard grid in Openbravo, the window for Warehouse operations allows to select multiple records and execute the button for all those selected. This is particulary useful to initiate Counts for all stock of a specific product, or for all stock in a specific bin or Storage bin Group. Only those Storage Details that do not have a task will be processed.

Those Storage Details that already have a Task assigned will be skipped from the initiated process and produce an exception message in the header.

It is possible that the filter returns more than 100 rows and then the standard limitation (grid pagination) will show only the first 100 and the execution of the button would in that case only execute these 100 rows. There are three ways to bypass this and depending on the business environment and frequency of the execution of this procedure, one or the other should be applied:

  1. The limitation of 100 rows in the grid is configurable at system-level and valid for all clients on this system. There is however a performance effect that should be verified for each environment, taking into account the number of records and the performance of the server.
  2. Scrolling down will load all the records and once loaded will execute the button on all selected rows.
  3. Refining the selection criteria in order to reduce the number of selected records to less than the limitation.
The limitation of 100 rows in the grid can be configured differently, or the user can scroll down to force that all records are loaded before execution.

Multi-select without limitation

This project is not yet executed.

Planned for future development is the possibility to execute all of the lines that are selected through the use of filters in the Warehouse Operations window, regardless if this filter results in 50 or 5000 (example) lines.

This is particulary relevant in high volume environments and during a wall-to-wall physical inventory count.

Alternative Unit-of-Measure in the tasks and Decimals

Products that have an Alternative UoM specified and set as "Primary" for the logistics flow will have their tasks generated with the columns Alternative UoM and Convertion Rate populated IF the quantity in the task is a full multiple of the Conversion Rate. The Front-End reads this information and will present the task in the Alternate UoM with the abbreviation from the column "Symbol" in the table for Unit of Measure, but will process always in Base Unit-of-Measure.

If the UoM, base or alternative, is defined with decimals in the column "Standard Precision" of the Unit of Measure definition, these decimals will be shown on the front-end and used when processing. If the quantity that was manually requested in f.i. the Put-Away has more decimals than the Standard Precision of the relevant UOM allows, the quantity will be rounded-down to the number of allowed decimals. Example:

  1. I manually request a put-away for 9.1234 kg of a certain product.
  2. The UOM 'kg' is defined with 3 decimals in the column Standard Precision
  3. The task(s) will be created for a total of 9.123 kg, ignoring the fourth decimal and, subsequently, leaving 0.0004 kg in the original bin after the confirmation of the task.


Decimals and Logistical units

It is important to understand that the front-end quantity field and the "+" and "-" buttons work on the integers only, while the system shows the value with number of decimals as defined in the column Standard precision of the UoM definition.

So without taking into account the quantity per logistical unit, we would see a single task of 3,6 bx if we would put-away 18 'each' of a product that is defined as 5 'each' in a box (and if the unit 'box' would be defined with 1 decimal). And the quantity can only be increased or decreased by full integers on the front-end. But physically (and in most cases), these 18 'each' actually are 3 boxes plus 3 'each'. And the operator will (in most cases) handle them in two distinct movements.

The task is created with the Alternate UoM with and conversion rate and presented with that on the Front-End.
The Put-Away menu of the front-End allows to see & select either in BUM or in AUM.


To reflect the two physical movements in the reality, it is better to generate two tasks: One for 3 boxes and another one for 3 'each'. They might be going to the same To-Bin, that is a different issue and is determined by the algorithms. For these situations there are algorithms that return only (multiple of) full logistical units, these have "FLU" in their name. A proper configuration would show first an algorithm for Full Logistical Units, followed by the same algorithm but for any quantity.

An example configuration for businesses that have Alternate UOM set as Primary in the logistics flow.

Assign Tasks

Assign from the Back-end

In the task window you can edit the user field. Upon saving, the task is assigned to the chosen user. When the user reloads the front-end (automatically after confirming a task), the newly assigned task will appear in sequence of the priority (highest first) and travel sequence (lowest first).

Assigning in the grid unassigned tasks in the Back-End.
Assigning multiple tasks at the same time.
If the Override User-Assignment flag is checked, it is possible to reassign (multiple) assigned tasks.

Assign from the Front-end

Click on the Assign option in the menu and type or scan the product, EAN/UPC or attribute value and select the tasks. Alternatively browse the unassigned tasks and select those to work on. Available tasks that are not yet assigned will be shown in sequence of priority descending, travel sequence ascending, Bin SearchKey ascending.

Assigning available but unassigned tasks in the Front-End.

Unassign Tasks

Unassign from the Back-end

This is similar -reversed- to the assign activity from the Back-End: Instead of filling the user field, it is emptied.

Unassigning existing but assigned tasks in the Back-End: empty the user field.

Unassign from the Front-end

Select the task and then the Unassign button. Depending on the preference, the unassignment might have to be confirmed in a second screen.

Select the task to unassign and click the menu-option. If the preference to confirm the unassignment is set, a second screen will ask confirmation.

Lookup Inventory

Searching for inventory by product, EAN or attribute values.

Generate Tasks

Tasks are generated as a result of the initiation of a logistical transaction, provided that the configuration was completed. The content of the tasks, i.e. priority, task-type, from- and to- bin etcetera, is derived from the configuration.

Expected and Confirmed values

The task has fields for the expected quantity and bins and for the confirmed quantity and bin. The expected values are always calculated and put in the task, but it depends on the front-end configuration if these expected values are visible on the front-end. The confirmed values are never put in the task when it is generated. The front-end, depending again on the front-end configuration can show them and will send the confirmed values to the back-end for processing.

Alternate Unit of Measure

All quantity fields are in the database in Base Unit of Measure. The task has fields for Alternative UoM and Conversion rate. These fields are filled if both conditions are met:

  1. If the product of the task has a primary logistical unit of measure defined;
  2. If the quantity of the task is a (multiple of) the conversion rate of the Alternate UoM.

Task Status

Tasks can have three different Status values:

  1. Reserved: A Task is generated in this status in order to claim the Storage Detail ahead of time. The task is not visible to the Front-End.
  2. Available: The task is visible to the Front-End and can be confirmed.
  3. Confirmed: The task was confirmed, either manually or automatically.

Determination rules of the From/To

When determining the 'From' and 'To' values of the task, the following process is followed:

  1. The system checks if the organization is activated for Advanced Warehouse Operations.
  2. The system takes the warehouse from the header (not from the lines!) of the document.
  3. The IR is determined with the warehouse and the Inventory Transaction Type and other -optional- relevant conditions from the IR-Assignment tab of the Warehouse definition window.
  4. The Warehouse Algorithms for the 'From' and 'To' are determined with the Inventory Transaction Type and other -optional- relevant conditions from the Warehouse Algorithm-Assignment tab of the Warehouse Definition window.
    1. In some situations the 'From' and/or 'To' are predefined. When this is the case, the predefined From/To will overrule the determination logic in the configuration. This is the case when:
      1. The sales or distribution order has predefined reservations (allocated) that point to a specific attribute/bin.
      2. The put-away is initiated for a specific storage_detail / attribute.
      3. The picking is for a specific Production Run and this Production Run has an IssueBin defined. In this case the IssueBin is set as the ToBin.
    2. It can happen that the predefined value is not according to the configuration: For instance when the reservation of the order indicates a bin outside the From-IRA from the IR that was determined by the TaskGenerator; Or the IssueBin in the ProductionRun is not inside the To-IRA of the determined IR. This will provoke a warning message in the verbosity but will not impede the creation of the task.

Document Generation

The generation of Tasks takes place in the Back-End and will create different Openbravo Documents. These are:

Reception List

Receiving generates a Reception List.

Picking List

Picking generates a Picking List.

Issue List

Issueing generates an Issue List.

Physical Inventory Proposal

Any type of Physical Inventory (Count, Recount, Cycle Count) will generate a Physical Inventory Proposal.

Generate Tasks for Receipts

The Receipts functionality has the scope as per the document types hereunder. The receipts menu-option in the Front-End will accept (scan, enter) any value and search the database for a document number of the entered value, regardless of the document type, and prompt the user with the found document(s). When a document is selected, the relevant receipt process is executed and tasks are generated.

Required Configuration:

  1. Is there an IR assigned to the ITT “RCT-PO"/"RCT-DO"/"RCT-WE"?
  2. Is there a WA assigned to the same ITT?
  3. If destination is a non-functional IRA:
    1. Does the product have a SBG-List?
    2. Does this SBG-List contain SBGs for the warehouse?
    3. Are there bins defined in these SBGs?

From the Back-End: Click the button "Receive" on any purchase order or Distribution Order in status BOOKED with pending quantity to receive. A pop-up window will request the user-id to whom the tasks should be assigned. This field can be left blank with the result that the tasks are generated but not (pre-)assigned.

Initiating a Purchase Order receipt from the Back-End and assigning the tasks.

From the Front-End: Click the Receive option will allow to scan, enter or search for open documents, as per the above scope. Selecting a document will initiate the task generation and assign the task to the Front-End user that initiated the transaction.

Initiating a Purchase Order receipt from the Front-End which automatically assigns the tasks. Scan, enter or search for any Purchase Order number or Order Reference in a document with status BOOKED.

Receipts with Reference

A receipt with reference (see Referenced Inventory) is only possible in the case of a Distribution Order, where the goods were sent with a Reference and from within the Openbravo instance. In this case, the quantity of the individual lines can not be changed as they are supposed to be in a reference/box.

Generate Tasks for Put-Away

The Put-Away functionality allows to generate a task for any storage detail, provided a completed configuration. Any attributes will travel with the task and movement. A single line or multiple lines can be selected from either the front-end or the back-end.

The window Put-Away Stock":

Pre-refactor Put-Away.


From the Front-End: Open the menu Put-Away and select the product and quantity. Confirm to generate the task.

Note that the Front-End allows to switch and express the quantity in either BUM and AUM.


Required Configuration:

  1. Is there an IR assigned to the ITT “PUT-TR"?
  2. Is there a WA assigned to the same ITT?
  3. Does the product have a SBG-List?
  4. Does this SBG-List contain SBGs for the warehouse?
  5. Are there bins defined in these SBGs?

Generate Tasks for Move Stock

The main difference between the Move and Put-Away functionality is the fact that a Put-Away searches for the destiny bin given the product- and algorithm configuration, whereas the Move functionality requests the back-end user to manually input the destiny bin. The configuration of the IR is required given that this determines the Task Type, priorities and Front-End behavior.

As such, the Move allows to generate a task for any storage detail, given a complete configuration. Any attributes will travel with the task and movement.

The Move button is part of the Warehouse Operations button":

The Move button will ask for the (optional) operator and the destiny bin.

Required Configuration:

  1. Is there an IR assigned to the ITT “MOV-TR"?

Generate Tasks for Physical Inventory

From the Back-End the user can generate Count and Recount tasks from the Warehouse Operations window. This is easily done by filtering and selecting the group of Storage Details for which to generate a task and click the proper button. The Count button will initiate the Inventory transaction type CNT-PI. On the other hand, the Recount button invokes the TaskGenerator with the REC-PI inventory transaction type.

Initiating a Count or Recount from the Warehouse Operations window.

Both Count and recount tasks are then assignned to the Front-End operator where they can be confirmed.

From the Front-End the user can select the menu Count and scan (or manually enter) the bin. Once the bin is selected the system asks to enter the product and checks if that bin/product exists in the system. If it exists, the expected values are populated, or, if not, the expected values are empty. If it exists and there is a reservation on this Storage detail, the system will issue a warning and no task is generated.

Initiating a Count from the Front-End will initiate the CYC-PI Inventory Transaction Type.
Browsing the Product will show existing Storage Details on the selected bin and warn if there are Tasks in Progress. Operator should abandon and work on the existing task first.
Once the bin is selected, the operator can adjust existing inventory or can create new inventory.
Update the quantity and/or the list-attributes and confirm. The header-attributes (serial#, lot#, expiry date) are not updateable.

Generate Tasks for Batched Wave Picking

In order to generate tasks for Batched Wave picking, two steps must be completed:

  1. Setup the configuration for Batched Wave Picking to define which orders should be selected when.
  2. Setup the process request that generates these tasks.

Generate Tasks for Self-Replenishment

Note: Replenishment tasks in the context of Advanced Warehouse Operations refer to the activity to replenish picking or public storage areas from the main- or bulk-storage area, all within the walls of the warehouse. Replenishment from external sources (suppliers, distribution centers) is managed by the Advanced Planning functionality.

In order to generate tasks for Self-Replenishment, two steps must be completed:

  1. Setup the configuration for Self-Replenishment to define which minimum quantity of which products should be in which bin.
  2. Setup the process request that generates these tasks.

Generate Tasks for Self-Organizing Warehouse

The Self-Organizing Warehouse functionality will generate Put-Away (ORG-TR) tasks for products that are not stored in their ideal bin.

In order to generate these tasks, two steps must be completed:

  1. Setup the configuration for Self-Organizing to define which minimum quantity of which products should be in which bin.
  2. Setup the process request that generates these tasks.

Generate Tasks for Self-Auditing warehouse

The Self-Auditing Warehouse functionality will generate Physical Inventory Count tasks for products that match with the configured rules.

In order to generate these tasks, two steps must be completed:

  1. Setup the configuration for Self-Auditing to define which minimum quantity of which products should be in which bin.
  2. Setup the process request that generates these tasks.

Generate Tasks for Picking

The Picking functionality has the scope as per the document types hereunder. The picking menu-option in the Front-End will accept (scan, enter) any value and search the database for a document number of the entered value, regardless the document type, and prompt the user with the found document(s). In case of the Work Effort, see (Advanced Warehouse Operations for Manufacturing.), also the Production Reference field can be searched for. When a document is selected, the relevant picking process is executed and tasks are generated.

Required Configuration:

  1. Is there an IR assigned to the ITT “PIK-SO"/"PIK-DO"/"PIK-WE"?
  2. Is there a WA assigned to the same ITT?

Allocated Reservations: The generation of Picking tasks for document-type "Sales Order" will also create an allocated reservation for (each required quantity of) each identified Storage Detail. This reservation stays with the picked Storage Detail even if this Storage Detail is moved and is only removed (released) when the Goods Shipment is executed.

See chapter Assignments of IR and WA for the dynamics on the assignments of IR and WA.

From the Back-End / Single Order

The ITT "PIK-SO" is invoked with TaskStatus "Available" when the button Picking Tasks is activated. As roadmap acceleration project, the same ITT "PIK-SO" can be invoked with TaskStatus "Reserved" when the button Reservation Tasks is activated.

From the Sales order screen the picking transactions can be generated.

From the Back-End / Multiple Orders

The window "Sales Order Lines Picking" can be used if multiple lines from multiple orders should be picked. The user can select one or many lines, from different sales orders, and the system will generate the picking tasks and group them in Picing lists according to the selected option. For each line the user can select the desired qty to pick (less or equal than the current pending quantity).

Initiating the picking for multiple lines of multiple orders.

It's possible to define a grouping criteria. By default the system will generate a unique Picking List per organization with all the tasks inside. However the user can select a different grouping criteria. In AWO we include by default these options, but external modules can easily add new ones.

The grouping preference.
The picking tasks can be grouped according to these grouping options.

In the Force Warehouse selector the user can optionally select the warehouse from which the picking tasks will be created. The warehouse at sales order header will be overwritten by this one for the selected sales order lines. If null (default behavior), AWO will use the warehouse defined at the sales order header.

From the Front-End

Initiating the picking for the selected products will generate Picking Tasks for all components (P-) previously not picked.

Delivery Modes

In the Sales Order Line Picking window, the user can add delivery mode, date and time. See for all details this wiki.

Other Picking transactions

Generate Tasks for Issues

The 'Issue' transaction is for the SO (and DOi) what the Receipt transaction is for the PO (and DOr): Where the Receipt-* transactions create Storage Details, the Issue-* tranactions will 'issue' (e.g. 'hand out', 'emit', 'remove', 'give away') Storage Details as a result of the Goods Shipment (sales, distribution) or Goods Consumption (work effort) transaction. There are three possible modus operandi:

  1. If there has been a previous picking activity for a Sales Order, then there are allocated reservations (manually created upfront or automatically by the picking transaction itself) and the issue transaction will take the reserved storage details and generate the tasks.
  2. If there has been a previous picking activity for a Distribution Order (i) or Work Effort, and the issue transaction will take the reserved storage details and generate the tasks.
  3. If there is no previous picking activity but there are (manually created) allocated reservations, then the TaskGenerator will accept these reservations and and create the tasks.
  4. If there is no previous picking activity and no allocated reservations, then the TaskGenerator will find the Storage details given the configuration for the ISS-SO transaction type and create the tasks.

Concerning the last two modus operandi -without previous picking-, these allow to issue the goods directly from a non-functional IRA, for instance "Storage", without passing through the packaging or shipping IRA.

In all cases, the task generator will compare the bin from the reservation with the allowed bins/IRA from the configuration and only generate the task if the reserved bin is part of the allowed bins. This is an additional measure to control that stock is to be issued from the IRA that are configured for this.

Further, depending on the configuration of the task, they will be automatically confirmed (typical configuration) or manually by an operator.

Required Configuration:

  1. Is there an IR assigned to the ITT “ISS-SO"/"ISS-DO"?
  2. Is there a WA assigned to the same ITT?

See chapter Assignments of IR and WA for the dynamics on the assignments of IR and WA

From the Back-End. The ITT "ISS-SO" is invoked with TaskStatus "Available" when the button Generate Goods Shipment is activated.

Generation the Goods Shipment from the Sales Order window.

From the front-End:

Initiating the Issue of the Sales Order (DO) will generate Issue Tasks for all Storage Details (picked, available.

The Issue menu-option in the Front-End will accept (scan, enter) any value and search the database for a document number of the entered value, regardless the document type, and prompt the user with the found document(s).


Other Issueing transactions

Generate Tasks for Inventory Status change

The 'Inventory Status Change' transaction allows the operator to quickly change the inventory status of a Storage Detail and with that allow or disallow the reservations/picking flow and/or allow or disallow the planning flow.

Required Configuration:

  1. Is there an IR assigned to the ITT “IST-TR"?

See chapter Inventory Status for the details on this.

From the Back-End. The ITT "IST-TR" is invoked when the button Status is activated.

Changing the Inventory Status in the Warehouse Operations window.

From the front-End:

Changing the Inventory Status on the Front End.

note that this Inventory transaction Type is typically configured as Auto-Confirm.

Monitor Picking/Issueing progress in the Back-End

The Sales Order window in the back-end shows “Pending Lines” or “Pending Quantity” to pick/issue. Here we have to bear in mind that in the Sales Order window has the possibility to issue direct, bypassing the picking activity and thus we can’t simply look at confirmed picking tasks: there might not be any.

Comparison with the similar flags in the Production Run

There are similar but not equal flags that show the progress of picking in the Production Run. We believe that the function in the Sales Order is the better of the both ways to show the progress of an order, regardless if it is a Sales or Work order. However, the Production Run does not have the possibility to issue directly, it is included in the backflush, and for that we show the progress differently.

So, for a sales order of 10 units, if the IssueList is generated directly (auto-confirmed or not), the flag will be updated to 0. If only 6 are confirmed, then the system would automatically generate the 'delta task' for the remaining 4 and, subsequently, the flag stays at 0. But if I delete the task for 4, the flag is updated and will show a qty of 4 pending, or “to be picked/issued”.

Confirm Tasks

From Front-end

Confirming a task from the Front-End requires the mandatory attributes (if any) to have a correct value. The attruibutes can be scanned in the right-pane of the front-end while the left-pane will indicate which values are still) missing.

Confirming a Task with empty mandatory attributs will fail and show and error message.

Tasks that have all required values filled-in, are flagged as 'Ready to Confirm'. The confirm button will execute the confirmation.

A task with no attributes or all values correct and defaulted, will flag the task as ready to confirm. Both the confirm button and the task-icon will execute the actual confirmation.

From Back-end

Tasks can also be confirmed from the Back-end by selecting the task and clicking the Confirm button. If the task is assigned, the back-end user has to indicate it manually to override this assignment.

Confirming a Task from the back-end and overriding the -possible- user-assignment.
Confirming a Task in Form-mode allows to specify Delta-response and Auto-fill the confirmed values.

Attributes

The Advanced Warehouse Operations module guarantees full traceability since all tasks include the attribute-set of the storage detail. For products that are defined with an attribute set, all mandatory attributes must have a value before the storage detail can be created in a Goods receipts movement.

An example of an attribute-set defined in the backend, with header attributes, mandatory attributes and field-types 'date' and 'list'.

Attributes can be entered in the Front-End in any task that is of Base Task Type "Goods Receipts". The system will read the attribute-set that is connected to the product and, if any, prompt the attributes on the right-pane. On the left-pane the attributes are shown and colored in red if they are mandatory and still empty.

The left- and right pane indicate that attributes are required in the Goods receipt process.

Changes to an existing Attribute-Set

Changes to an existing attribute set are possible through the Front-End configuration functionality that allows to specify which attributes are shown and/or defaulted. These changes are efectuated in the attribute-set and afect all storage details that share this attribute-set. A change to this functionality, that allows to create new instances of attribute-sets and therefore reflect changes only for the separated part of the stock after f.i. a partial picking or movement, will be incorporated in the 18Q1 version of Advanced Warehouse Operations.

Resulting Inventory Transactions

Depending on the Base Task Type, the resulting inventory transaction is one of these:

Differences between Expected and Confirmed

The task has fields for expected and confirmed quantity and locator. Differences are detected and can be acted upon, either directly by the task generator or in a BI cube to analyze deviations.

Confirmed Quantity is less than Expected Quantity

If the confirmed quantity is less than the expected quantity, the AWO Task Generator will detect this and automatically generate a new task with the remaining quantity if the ITT allows this, see details in the paragraph on Delta Management. This allows the operator to put-away a partial quantity in Bin A and continue the put-away of the remaining quantity.

Confirmed Quantity is bigger than Expected Quantity

This is only possible for Goods Receipts and Physical Inventory (Count, Recount, Cycle-OTF) and is not limited by a warning or error message.

Confirmed Locator is different than Expected Locator

The expected locator is always a proposal. The operator can input / scan a different locator and the movement will be executed with the confirmed movement.

Confirm Issue Sales Order Auto-Invoice

Setting the related preference, the system will -upon issuing the goods- automatically create & process the sales invoice based on the related order's invoice terms.

Delta Management, Quantity Tolerances and Storage Detail Swap

Advanced Warehouse Operations offers four different concepts that facilitate certain flexibility during operation. This flexibility allows, in a controlled way, that operators chose different bins, different stock or different quantity:

  1. Delta Management: Allows the operator to request a new task from the system. Note: It is the system that determines the bin or storage detail.
  2. Reference Inventory: Allows to identify boxes/cases that can hold different quantities of a specific product. Note: It is the system that determines the reference (box/case).
  3. Quantity Tolerances: Allows the operator to under- and over-confirm for bulk-products without invoking Delta Management. Note: It is the operator who determines the quantity.
  4. Storage Detail Swap: Allows the operator to chose a different attribute -e.g. Serial number-. Note: It is the operator who determines the attribute.

See this chapter for the configuration of these concepts.

Delta Management

If a Task is confirmed with less quantity than the expected quantity (and no tolerances are defined), and the ITT has Delta Management enabled, a pop-up is shown and prompts the user to select Same, Different, Skip Delta or Cancel. Depending on the task type, this can refer to either of these:

In either case, the response of the user is stored in the task as Delta-Response and determines the next action for the Task Generator.

Unless the operator selects Skip Delta or Cancel, a Delta-Task will be generated for either the same or for a different bin or storage detail.
Delta Task identification in the window for Tasks.

Same or Different: If the initial task found the bin/storage detail with the given configuration, the same bin/storage detail will be found by the Delta-Task if nothing would prevent that. So, when the operator selects different on the Front-End, the system executes the following in order to by-pass the initial bin/storage detail:

Quantity Tolerances

The Operational effect of Quantity Tolerances is nothing else that it 'delays' the Delta Management functionality by allowing a different Quantity Confirmed, while inside the specified tolerances. Important to mention is that this functionality only works while the device is online.

Storage Detail Swap

On th AWO-Front-End an additional icon is visible for those Inventory Transaction Type that are subject to Swapping. On clicking this icon, a list of possible Storage details are shown, according to the Swap Level and Swap Area configuration.

The top-right icon is shown when Storage Detail Swap is allowed. Clicking it will show the Storage Details that match the configuration of Swap Level and Swap Area.
Also when confirming from the back-end the Storage Detail can be swapped.
The swap allowed to confirm different Storage Details.

Cancel / Delete Tasks

In the case the task will not be executed, the user can delete the task in the backend task-window. This is restricted to tasks without an assigned user to avoid -as much as possible- the confirmation of deleted tasks.

Canceling the task from the back-end if no user is assign to it.

Delete Tasks and Reservations when closing SO and DO

As from 19Q1 and driven by the preferences below, related open tasks will be deleted automatically when closing a DO or SO and storage details are no longer reserved.

Closing the DO or SO will delete open tasks and storage details are no longer reserved.

Reprint Product ID (label)

In the Back-end task window, a confirmed task that relates to an IR with the Print ID=True, can reprint the Product ID.

Select the processed/confirmed task and press the button reprint.

Verbosity

Verbosity is the functionality of gathering functional messages during the complex process of creating tasks. These messages allow to follow the steps of the process and as such help to understand why certain IR or why certain bins or storage details are selected. This is particulary important when the warehouse is (re-) configured.

Verbosity literally means “To use more words than needed” and applied to the RequirementsAnalysis, Algorithms and TaskGenerator means that every single step during the generation of a task (not only the final result!) is recorded in a Verbosity output file for analysis. With this output, the configuration can be understood and correction or fine-tuning can be applied.

The verbosity functionality produces an enormous volume of output and therefore can be activated in the window Warehouse Verbosity Configuration per user, per time frame while specifiying the verbosity level.

The verbosity is activated per user and time frame and specifies the verbosity level.

The window "Warehouse Verbosity Log" shows when and who invoked the TaskGenerater for which Inventory Transaction type.

The times that the TaskGenerator was invoked and Verbosity was active.

Inside the header, all actions, decisions and determinations that the TaskGenerator took from the moment it was invoked to the moment it finished is shown in the log.

Once activated, the verbosity functionality produces the detailed steps during Task Generation.
The Beautify Log button improves the presentation of the verbosity log.

Reporting and Business Intelligence

Warehouse Task Report

The Task Report shows the details and values of the selected tasks.

Multiple selections to report the tasks of interest.
An example of the Task report layout, in this case to HTML.

Business Intelligence Cubes

This project is not yet executed.

Specific KPI's for Advanced Warehouse Operations

AWO: Number of deltas per week. This answers the following questions:
  • Which operators and which tasks generate more deltas?
  • Are there many DeltaBin’s to Overflow? Then I might need to increase the SBG.
Show DeltaQty / DeltaBin, Per user, Per ITT.
AWO: Tasks per operator per week. This answers the following questions
  • I have to fire 1 person of 3, who is the most productive of the 3?
  • Compare to Norm: Is Operator-X doing better in Put-Away but worse in Picking?
Show by ITT (including CHG-TR for the status)
AWO: Occupancy by SBG. This answers the following questions
  • Which areas of my whse have more space available and which are fully loaded? (only in non-functional IRA)
Show avg occupancy of SBG, descending. Double-click to drill down to bins.
AWO: Popularity analysis. This answers the following questions
  • Is the populatiry code of the product according to the frequency of its movements?
  • Number of movements per product / month
Show product popularity and (avg) bin-popularity.

Generic KPI's for Inventory Mangement

ITR: Inventory Turnover Ratio.
ITR helps us to measure the number of times we sell or turn our average inventory kept in the warehouse. In other words, it measures the number of opportunities to earn profit that we experience each year from our working capital invested in the inventory. It is calculated by dividing Cost of Goods (COGs) sold by the average inventory investment: ITR: COGs / [(Opening Stock+Closing Stock)/2]
Benchmark:There is no specific benchmark for ITR. However, organizations who are product leaders in the market are likely to satisfy with ITR of 3-4 while operational excellence oriented organizations, such as low-cost airlines or wholesalers aim at achieving 8-9 ITR. On the other hand, distributors that handle a wide range of brands and strive to meet customer needs aim at keeping ITR around 5-7. Deciding the number of ITR is heavily related to the gross margin generated by related SKUs or brands. Thus, managers should also refer to the following KPI.
TEI: Turn-Earn Index.
TEI helps us to combine the gross margin and turnover. A logic behind TEI is to keep high ITR for SKUs or brands generating low margins and to satisfy with medium- or low-level ITR for SKUs or brands generating high margins. TEI: (ITR) x (Gross Profit %) x 100
Benchmark: Achieving TEI between 150 and 180 is the best practice in terms of balancing gross margin and inventory. For instance, having 160 TEI for a brand can be interpreted as having 20% margin and turning inventory 8 times or having 40% margin with turning inventory 4 times per year.
GMROI: Gross Margin Return on Investment.
GMROI represents the amount of gross profit earned for every AED (or $, £, €, ₺) of the average investment made in inventory. It is calculated by dividing gross profit by the average inventory investment. Tracking GMROI on a monthly basis provides a significant clue in terms of having a clear understanding of which SKU or brand produce more gross profit in the inventory. GMROI: [Gross Profit] / [(Opening Stock+Closing Stock) / 2] X 100
Benchmark: Achieving GMROI between 200 and 225 is the best practice by means of generating gross profit from the inventory hold for the related SKUs or brands.
DOS: Days of Supply.
DOS is the most common KPI used by managers in measuring the efficiency in supply chain. It is calculated by dividing the average inventory on hand (as value) by the average monthly demand (as value) and then multiplying it by thirty, when measuring on a monthly basis. DOS: Avg Inventory / Monthly Demand x 30
Benchmark: There is no specific target for DOS, but measuring it by considering the following months’ sales forecasts (as value) will help us to have a clear understanding of at which level we need to keep our stock to be able to improve inventory management on a monthly basis. Nevertheless, DOS does not help us to understand how well our inventory will match the demand. To cover this, we need the following KPI.
IV: Inventory Velocity.
IV is the percentage of inventory we are projecting to be consumed within the next period. It helps the managers to understand how well the inventory on hand matched the demand. It is calculated by dividing sales forecast of the following period by the opening stock. Tracking IV on a monthly basis will provide significant clues in terms of aligning inventory level to the optimal level for matching supply-demand, and preventing excessive stock in the warehouse. IV: Next Month's Sales Forecast / Opening Stock
Benchmark: For continuous SKUs, keeping IV between 60-70% will provide a good match of demand while 75-80% of IV can be more beneficial for fast-moving SKUs. Whilst having IV less than 60% indicates excessive stock, IV over 80% is risky in terms of being out of stock as it calls for Kanban-Pull system. Practically, not all SKUs or brands can be treated equally via aforementioned KPIs. Applying Pareto Principle will help easily categorize SKUs (e.g. fast-, continuous-, intermittent- and slow-moving SKUs). Categorization can be based on monthly sales volume, margin percentage or the number of exists from the warehouse. Making use of Pareto Principle upon these three perspectives and then taking the average weights will be a good asset in terms of placing each SKU to the correct category.

Examples for Combinations with Advanced Warehouse Operations

Food Truck or Van Sales

AWO-PLUS-VanSales.jpg

Sales from a van with combining Openbravo WebPOS and Advanced Warehouse Operations.


When combining the WebPOS with the Replenishment logic of the Advanced Warehouse Operations we get the possibility for sales from a van, regardless if that is a food truck or any other merchandise.


How: The van/truck will be defined as a bin in a separate Internal Routing Area with minimum/maximum levels of all products that should be in that truck. While operational, the WebPOS will be configured to consume only from this specific IRA while doing the sales. Being connected continuously, the sales and remaining level of stock can be monitored from the central point. When the truck arrives back at the central stocking point, Advanced Warehouse Operations will be able to replenish with exactly those products needed in order for the truck to continue to the next route.

Retrieved from "http://wiki.openbravo.com/wiki/Modules:Advanced_Warehouse_Operations"

This page has been accessed 25,870 times. This page was last modified on 10 January 2019, at 11:03. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.