Modules:Advanced Warehouse Operations
Languages: |
English | Translate this article... |
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:
- Improved sales by avoiding stock-outs and obsoletes;
- Improved internal efficiency by efficiency driven operations with dynamic Task Priority and Travel Sequences.
- Improved internal efficiency by intuitive UI and offline-resistent mobile operations;
- Reduced costs by optimization of space utilization by Popularity Codes and Dynamic Capacity calculations;
- Reduced costs by optimization of staff;
- Reduced costs by preventing obsolete- and excess inventory;
- 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:
- Explanation and examples about the AWO Configuration, starting here
- Explanation and examples about the AWO Operation, starting here
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:
- Enhancements in the Supply Chain concerning PLANNING & EXECUTION of INCOMING INVENTORY:
- (17Q3) Distribution Orders. Integration aspects (configuration & operation) with Advanced Warehouse Operations are covered in this Wiki.
- Advanced Forecasting and Planning with FrePPLe ('Pull'-model)
- FairShare ('Push'-Model)
- Enhancements in the Supply Chain concerning MANAGEMENT of IN-HOUSE INVENTORY:
- (17Q1) Unit of Measure Conversions. Integration aspects (configuration & operation) with Advanced Warehouse Operations are covered in this Wiki.
- (17Q3) Inventory Status. Integration aspects (configuration & operation) with Advanced Warehouse Operations are covered in this Wiki.
- (18Q2) Referenced Inventory. Integration aspects (configuration & operation) with Advanced Warehouse Operations are covered in this Wiki.
- (17Q4) Advanced Warehouse Operations, including mobile inventory procedures (this wiki)
- Advanced Warehouse Operations for Manufacturing
- Enhancements in the Supply Chain concerning PLANNING & EXECUTION of OUTGOING INVENTORY:
- (17Q3) Distribution Orders. Integration aspects (configuration & operation) with Advanced Warehouse Operations are covered in this Wiki.
- Vehicle and Transport management
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. For more information please check this link
Licences
- License: Commercial
- Category: Module
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:
- Authorization per ITT (Initiate and/or Confirm)
- Batched Wave picking
- Self-Replenishing warehouse
- Self-Organizing warehouse
- Self-Auditing warehouse
- Tasks for Issue- and Receipt Work Effort (ISS-WE and RCT-WE)
- Tasks for Return Material Authorization and Return To Supplier (RCT-RMA and PIK-RTS, ISS-RTS)
- Scan GTIN-14 (packaging level) in the Front-End
- [Done for 18Q1] Referenced Inventory with AWO
- Operator Load Balancing
- Push-model planning and FairShare
- Cross Docking
- Put-Away "Merge with Order" and "First valid Empty Bin
- Warehouse Operations window: Execute button on Filter
- Print-as-Group flag in Routing
- Subsequent Task Generation
- Business Intelligence cubes for Advanced Warehouse Operations
- Print button on Front-End
- Kitting: Introduce the concept of BOM-Type for different construction processes:
- BOM-Type MTO: The construction requires a (machined) process or assembly. As in current Process Plan. The system consumes components (P-) and produces FG (P+).
- BOM-Type KIT: The construction does not require a process or assembly but a gathering/boxing of components and is executed in the warehouse resulting in BOX-TR task-types in AWO-Referenced Inventory.
- BOM-Type ATO: Configurable BOM with optional and mandatory components, presented and constructed during order-entry, resulting in a unique composition of the ordered product, requiring process/assembly.
- [WIP for 18Q3] Double Confirmation on Front-End: Show task-details and ask the operator to verify after pressing <CONFIRM> but before committing to the Back-End. Driven by a flag in Routing (behavior).
- [WIP for 18Q3] Approval on Delta on Front-End: O a Quantity-Delta, show task-details and ask the manager to approve (password) the over/under quantity. Driven by a flag in Routing (behavior).
- Download Warehouse Configuration Check to XLS format. This check can produce large volumes of data and a download would facilitate to organize the missing configuration components.
- [Considered for 18Q4] Attribute Override on Front-End. The AWO-proposed attribute is not always easiest to pick. Still it is proposed for all good business reasons -as defined in the algorithm assignment- and important to keep as expected value. The Delta-functionality allows some flexibility to the operator but not always enough. This functionality is to allow the operator to pick from existing attributes (lot/serial/exp.date) within the same IRA by overriding the proposed attribute. The proposal is a complex of functionality:
- Add another flag in the Routing (concentrate behavior aspects) “Allow Attribute Override”. When allowed, the Attribute fields on the FE are clickeable and open a window where all StorDet of the same product + same IRA-From and available Inv.Sts are shown. Sequence: First show the stor.det from the same bin.
- If the selected Stor.Det already has a task (Task.Sts=Avail and Not-Assigned ) than the system should switch the assigned Storage Detail between the tasks.
- Why "Not assigned" -> this avoids problems with offline.
- Why not sts Reserved -> This ATTR might be reserved on purpose in production.
- If the selected Stor.Det already has a task (Task.Sts=Reserved OR Assigned -> Error.
- If the selected Stor.Det QtyAvail < QtyExp = Delta task.
- [DONE for 18Q2] Move-Transaction Assignment on From-IRA AND To-IRA. The assignment of the current MOV-TR only allows 1 Routing (so 1 To-IRA) per from-IRA as per design of the Routing-Assignments. This limites the use of this transaction and in some sense contradictory to the purpose where a human determines to To-Bin, regsrdless system configuration. The proposal is to allow Routing-assignments for MOV-TR based on uniqueness of both From-IRA and To-IRA. This will allow multiple routes as well as restriction to undesired routes.
Configuration
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.
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:
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:
- Have the logistical transactions separate the transaction lines into individual tasks according to a unified definition of task;
- Generate these tasks based on the configuration of the Routings (R), Storage Bin Group (SBG), the capacity constraints and warehouse algorithms;
- Display the tasks in sequence of their priority and travel sequence and in a simple and user friendly user-interface;
- 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.
Configuration - Activity-1 - Activate Advanced Warehouse Operations on Organization level
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.
Configuration - 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:
- Routing Areas
- Storage Bin Groups
- Bins and Bin capacity
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.
Dataload Template
The data that the warehouse manager needs to deliver is described in this excel template: File:Dataload template AWO.xlsx
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:
- Functional RA
- Non-functional RA
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.
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:
- Receipts
- Storage
- Storage with public access
- Production
- Shipping
Other typical IRA are:
- Packing
- Inspection
- Scrap
Storage Bin Group (SBG)
Definition: A Storage Bin Group is a group of Storage Bins with the same characteristics.
Examples of SBG's in a non-functional IRA are:
- Bins in cold/freezing area,
- Bins for fresh or contagious goods,
- Bins for (small) spare parts,
- Bins for bulk-storage and bins for picking areas,
- Bins for high valued goods in secured storage,
- Bins for bonded warehouse areas (ex-customs areas),
- Etceteras.
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.
- Use case: From a specific product, I have new stock and refurbished stock and the refurbished stock is stored in a different SBG. I prefer to do the picking for assembly from the refurbished stock while shipments to customers from the new stock, but only if I have this available. So picking for PIK-SO would be assigned the algorithms "Pick by SBG-Picking Sequence (asc) while PIK-WE would be assigned "Pick by SBG-Picking Sequence (desc).
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:
- Search Key / Coordinates - describes the street/column/level of the bin and it is adviseble to give this a understandable structure, for instance:
- ABBCCDEE, where:
- A = Building;
- BB = Street within the building;
- CC = Column;
- D = Position;
- EE = Vertical level
- Example 3AD17M10 means: Building 3, Street AD, Column 17 (impar: so at the left), Middle position and Vertical level 20.
- Popularity Code - describes the vicinity of the bin related to the functional IRA, typically those for shipping and receiving;
- Travel Sequence - describes the optimum sequence in which the operator is to visit the bins;
- Inventory Status - describes the status that any inventory will adopt when placed in this bin.
- IsVirtual - A virtual bin is created as a copy of the from-bin by a Change of the Inventory Status of a Storage Detail. A virtual bin does not have capacity, occupancy is set to 100% to avoid consideration in the Put-Away process.
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).
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.
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:
- Check if no tasks are pending for this Storage Detail;
- Check if the configuration is complete;
- Check if the virtual bin to create already exists, if so use it and skip the next step;
- 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%.
- 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:
- Available y/n - defines if the specific inventory is available for general business flows like reservations and picking.
- Netteable y/n - defines if the specific inventory is to be taken into account for planning / MRP purposes.
- OverIssue y/n - defines if the specific inventory is allowed to go negative. This can happen during the picking- and the issue-transaction type.
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.
- Bin Capacity is the basic concept that allows for the Chaotic Bin System.
- Bin Capacity is only relevant for Non-Functional Internal Routing Areas (like storage), since Functional IRA have unlimited capcity by definition.
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.

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.
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,
- a bin without defined capacity has no capacity whatsoever and will not be considered for a put-away in bins that belong to a non-functional IRA.
- a bin with 2 capacity definitions, each for a pallet of a different product/category does not have a capacity of 2 pallets, but can absorb any of the defined products/categories to a maximum of 1 pallet.
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):
- 4800 CANs of "Coca-Cola ZERO cans" (translates to a relative 50% bin-ocupation) and
- 320 EAch of "Gift-Cups" (translates to a relative 20% bin-ocupation).
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:
- Capacity is only relevant for storge in non-functional IRA,
- The IR-Assignment has found the destiny IR-Area,
- The WarehouseRule-Assignment has sequenced the bins for the below evaluation process,
Then:
- we see that bin AABBCCDD has allowed capacity for "Gift-Cups" (OK, next step),
- we see that bin AABBCCDD has 30% free capacity (OK, next step),
- we know that this 30% is 30% * 40 BX = 12 BX = 480 EA (OK, next step),
- we can create a Task for Expected Qty 480 EA, (OK, next step)
- 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.
Configuration - 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.
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 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 | ![]() | Receive | ![]() | Reception List | |
RCT-DO | This ITT generates the AWO tasks to receive the stock from the in-transit location. | Distribution Order(r) | ![]() | Receive | ![]() | Reception list | ||
RCT-RMA | This ITT generates the AWO tasks to receive the stock from Return from Customer. | Return from Customer | ![]() | 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. | ![]() | Goods Movement | ||||
DEV-XD | Roadmap Acceleration project. 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. | ![]() | 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 | ![]() | Putaway | ![]() | 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 | ![]() | 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 | ![]() | 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 | ![]() | Not on FE | ![]() | 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 | ![]() | Unbox | ![]() | Goods Movement | ||
RPL-TR | Roadmap Acceleration project. 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 | Roadmap Acceleration project. 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 | Roadmap Acceleration project. 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 | 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 | ![]() | Not on FE | ![]() | 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 | ![]() | Not on FE | ![]() | 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 | ![]() | Pick | ![]() | 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 | ![]() | Not relevant on Front-End. | Goods Movement | |||
ISS-WE | Roadmap Acceleration project to Issue ACTUAL components | Production Run | ![]() | Issue | ![]() | Issue List | ||
RCT-WE | Roadmap Acceleration project to Receive ACTUAL finished product | Production Run | ![]() | Receive (&Backflush) | ![]() | Reception List | ||
Shipping | PIK-SO | Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. | Sales Order | ![]() | Pick | ![]() | Goods Movement | |
PIK-DO | Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. | Distribution Order(i) | ![]() | Pick | ![]() | Goods Movement | ||
PIK-RTS | Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. | Return to Vendor | ![]() | Pick | ![]() | 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 | ![]() | Issue | ![]() | 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) | ![]() | Issue | ![]() | 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 | ![]() | Issue | File:AWO-Button-FE-ISS-RTS.jpg | Issue List |
Authorization by ITTs (Front-End Restrictions)
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:
- 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.
- If the user is restricted, an error is shown.
- 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.
- 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.
- 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:
- 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.
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.
Types of Warehouse Algorithms
There are two types of algorithms:
- Algorithms that return a bin,
- Algorithms that return the requested quantity of a storage detail.
The algorithms that return a bin use as first parameter the sequence number of the StorageBinGroup.
The WA are predefined in Openbravo and can only be modified with SysAdm access.
PA "Merge by Order" (Roadmap acceleration project)
This algorithm is relevant when picking to specific packging areas/bins when the order must be completely grouped before packed.
PA "First valid Empty Bin" (Roadmap acceleration project)
This algorithm is also relevant for the grouping as it prevents a new order to be merged in a bin that already contains products from different orders.
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.
- The Base-Priority as previously defined in the Task Types is the initial priority of a task.
- The Priority Increment is the value that this process adds to the tasks every time that this process runs.
- The tasks with highest value of Priority are presented first on the Front-End. In the case of equal priority, the tasks are sequenced by Travel Sequence and Bin. In other words, sequence of Tasks on front-End: Priority (descending), travel Sequence (ascending), Bin (ascending).
With this mechanism, some tasks of certain task-type can raise faster in priority than others.
Example:
- Pickings tend to be more important than put-aways, so they get a higher Priority-Base.
- But you don't want the docking area to accumulate too much received material as this would obstruct the operators.
- So you give the Put-Away tasks a higher increment in the Task Type...
- ...and schedule the background priority process to run frequently, for instance every 60 minutes.
- 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.
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.
Configuration - Activity-4 - Mapping of the Warehouse 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:
- The R can be confirmed manually or automatically. In the latter case no task will be visible.
- The R can trigger the printing of a label (product identification, ID).
- The R can be presented with a specific color, mnemonic and priority by assigning the proper Task Type (TT) to it.
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:
- 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.
- 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.
- External Routing: When the two IRA belong to different warehouses (within the same legal entity) they connect thse warehouse with a goods movement as result of the confirmation of the task.
- Internal Routing: A Routing is internal when both Internal Routing Areas belong to the same warehouse or when there is just one IRA like in PO-Receipts or SO-Issues.
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:
- Manual- or Auto-Confirm,
- Print ID;
- Print Group (RM Acceleration)
- Deviate to ITT Quality Inspection;
- Deviate to ITT Cross-Docking (RM Acceleration).
- Subsequent ITT (RM Acceleration)
The R determines the behavior of the task once it is presented on the Front-End, see detailed configuration, by specifying the following:
- Show/Hide expected Qty
- Default the Expected value to the Confirmed Qty
- Default the Expected value to the Confirmed Bin-From
- Default the Expected value to the Confirmed Bin-To
- Hide / Show specific attributes of the Attribute List
- Require Double Confirm (RM Acceleration)
- Require Approval on Delta (RM Acceleration)
- Allow Attribute Override (RM Acceleration)
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.
- the field Deviate to Quality Inspection is set in the IR; This is only allowed for ITT that are related to BTT of type "From-To".
- the product is marked for Inspection.
- Full Quantity: Note that unlike the Deviate to Cross Docking, Deviate to Quality Inspection will generate a task for the full quantity.
Remove Reference
This functionality depends on the Referenced Inventory functionality (18Q2).
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 (Roadmap acceleration project)
Under certain conditions, this IR overrules the previously determined IR with the purpose to send the product to the Cross Docking IRA (as per the IR definition). The conditions are:
- the field Deviate to Cross Docking is flagged in the IR. This is only allowed for ITT that are related to BTT of type "From-To".
- the field Deviate to Quality Inspection is not flagged in the IR (Inspection prevails above Cross Docking),
- there is open -unpicked- demand for the received product for *today*.
- Partial Quantity: Note that unlike the Deviate to Quality Inspection, the Deviate to Cross Docking can generate tasks for a partial quantity, leaving a remaining quantity for the non-deviated IR. Example: There is 100 Each to Put-Away and an open order for 40 while Cross Docking is activated. The Put-Away is initiated and detects the open quantity:
- It detects the open order for 40 and generates a task according to the configuration for Inventory Transaction type "DEV-XD";
- For the remaining quantity of 60 it generates one or multiple Put-Away tasks, depending on the configuration.
Print-as-Group (Roadmap acceleration project)
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:
- 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.
- 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 (Roadmap acceleration project)
This functionality is similar to the deviation to Quality Inspection or to Cross Docking. Where the deviations interrupt the Routing determination based on 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 relvnt in the following environments:
- Goods were deviated to Inspection and after inspection they should be moved to storage. By defining PUT-TR in the column "Subsequent ITT" of the routing, a Put-Away task is generated once the goods arrived in Inspection.
- Staging: Goods are required in production but flow through staging area. The initial task will move the goods to this staging area and the subsequent task will move the goods to the final bin location.
Configuration - Activity-5 - Product/Warehouse characteristics
Product Parameters
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
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 (Alternative UoM project)
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.
Configuration - 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:
- The mandatory conditions determines if a task is to be created.
- 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:
- ITT: If there is no configuration for the ITT, the system will issue an error message.
- From-IRA: If there is an ITT configured, but the Storage Detail is not found in the From-IRA, the system will issue the same error message. Note that this is not relevant for PO- and WE-Receipts that do not have From-IRA.
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:
- Weighted with 16 points: Product,
- Weighted with 8 points: Product Category. Note that Product and Product Category are mutually exclusive.
- Weighted with 4 points: Business Partner,
- Weighted with 2 points: Business Partner Category. Note that Business Partner and Business Partner Category are mutually exclusive.
- Weighted with 1 point: Storage Bin Group.
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 R-A for Product "Natural Black Current" from any supplier in the category "Retail" sums to 16+2 = 18 points. In the case the goods will be moved to Receipts, probably for visual check of quantity and damages.
- The R-A for Product "Natural Black Current" without further optional condition sums to 16 points. So any receipts of this product from a supplier in a different category will be directed to the Inspection area, probably for a bit more than just the visual inspection of quantity and damages.
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:
- The mandatory conditions determines if a task is to be created.
- 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:
- 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.
- The second WA will try to merge to a bin where this product and attribute are already stored, but in any quantity.
- 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.
- 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.
Configuration - 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.
- Note that all *-PI tasks will be presented in the Base UM on the front-End. The reason is that these tasks cannot be consolidated in Logistical UM because of the possible decimals and rounding conflicts. Example:
- In a specific bin we have 17 ea in inventory: 5 boxes of 3 plus 2 ea.
- Showing the task in Logistical UM would show 6 bx (because Box is defined without decimals; but even with decimals there would be a rounding issues) and that would lead to an incorrect inventory adjustment.
- We can also not split the task into one of 5 bx and another one for 2 ea because each of these will confirm the adjustment independently: The first would confirm the quantity to 15 ea (wrong, because we have 17 ea) and the second would confirm the quantity to 2 ea (worse, because we still have 17 ea!).
The three ITT and their typical use are these:
- CNT-PI: Count Physical Inventory. This ITT is initiated exclusively from the Back-End, window Warehouse Operations. It is typically used for organized counts.
- REC-PI: Recount Physical Inventory. This ITT is identical to the previous CNT-PI, with the only difference that the task-type is REC-PI, indicating -for audit reasons- that a previous count could have been wrong. Being a separate ITT, it also allows to configure and authorize it separately (depending on "Authorization by ITT" which is a Roadmap acceleration project).
- CYC-PI: Cycle-count Physical Inventory. This ITT is initiated exclusively from the Front-End and is typically used for immediately executed counts / corrections.
- The Routing should be configurated as Auto-Confirmed, because the confirmed value is received from the front-end already. If it is Manual Confirmed, the task would appear on the Front-End but again with the original quantity since the value was not updated.
- The Openbravo interpretation of the concept of cycle-count and selection method is according to the On-The-Fly philosophy. It is advisable that the cycle-count activity is executed by an (experienced and authorized) operator. Note that other methods are implicitly supported by the ability to filter stock by area or product in the Warehouse Operations window.
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. |
Configuration - 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
Definition of Reference-Type
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.
Configuration - 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.
Configuration - Activity-10 - Setup Background processes
There are currently these back ground processes in Advanced Warehouse Operations:
Mandatory: 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.
Mandatory: 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.
- Occupancy is a percentage that uses the bin capacity definitions and product UoM-conversions of the actual stock in that bin.
- Occupancy_pending is a percentage that is calculated in the same way as the occupancy field, but using the tasks with status Avail instead of actual stock.
- If the stock is pending to leave the bin, the result of the calculation is negative.
- If the stock is pending to be received, the result is positive.
- Bins in Functional IRA are set to occupancy = 100%, occupancy_pending = 0%
The Occupancy% and Occupancy_Pending% are recalculated continuously on these events:
- Occupancy%: When stock is added to / taken out from a bin. Typically on confirmation of a task.
- 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.
Verbosity for Occupancy calculation This process writes in the verbosity log each step of the calculation and warns when there are missing definitions:
- INFO - 24-02-2017 07:14:55 - Started calculation of occupancy for storage bin 'AAL01L00'.
- INFO - 24-02-2017 07:14:55 - Started calculation of real occupancy for storage bin 'AAL01L00'.
- INFO - 24-02-2017 07:14:55 - Bin-Capacity record defined for product Marlon Coat -S- [NULL, NULL, 1, Pallet].
- INFO - 24-02-2017 07:14:55 - Conversion found in alternative unit Pallet - Unit [25].
- INFO - 24-02-2017 07:14:55 - 1 Unit of product Marlon Coat -S- found in bin, occupying 4.00. Accumulative occupancy is 4.00.
- INFO - 24-02-2017 07:14:55 - Bin-Capacity record defined for product Gracelynn Clutch [NULL, NULL, 1, Pallet].
- INFO - 24-02-2017 07:14:55 - Conversion found in alternative unit Pallet - Unit [500].
- INFO - 24-02-2017 07:14:55 - 4 Unit of product Gracelynn Clutch found in bin, occupying 0.80. Accumulative occupancy is 4.80.
- INFO - 24-02-2017 07:14:55 - Bin-Capacity record defined for product Puma Red (pair) [NULL, NULL, 1, Pallet].
- INFO - 24-02-2017 07:14:55 - No conversion found for Pallet - Unit neither in Uom conversion nor in Alternative Uom.
- INFO - 24-02-2017 07:14:55 - WARNING: Product 'Puma Red (pair)' is not defined for the capacity of bin ‘AAL01L00’ or not conversion was found. The product is ignored for occupancy calculation.
- INFO - 24-02-2017 07:14:55 - Bin-Capacity record defined for product Nike AirJordan (pair) -S- [NULL, NULL, 1, Pallet].
- INFO - 24-02-2017 07:14:55 - No conversion found for Pallet - Unit neither in Uom conversion nor in Alternative Uom.
- INFO - 24-02-2017 07:14:55 - WARNING: Product 'Nike AirJordan (pair) -S-' is not defined for the capacity of bin ‘AAL01L00’ or not conversion was found. The product is ignored for occupancy calculation.
- INFO - 24-02-2017 07:14:55 - Bin-Capacity record defined for product Granger Bag -L- [NULL, NULL, 1, Pallet].
- INFO - 24-02-2017 07:14:55 - Conversion found in alternative unit Pallet - Unit [200].
- INFO - 24-02-2017 07:14:55 - 25 Unit of product Granger Bag -L- found in bin, occupying 12.50. Accumulative occupancy is 17.30.
- INFO - 24-02-2017 07:14:55 - Finished calculation of real occupancy for storage bin 'AAL01L00'.
- INFO - 24-02-2017 07:14:55 - Started calculation of pending occupancy for storage bin 'AAL01L00'.
- INFO - 24-02-2017 07:14:55 - Finished calculation of pending occupancy for storage bin 'AAL01L00'.
- INFO - 24-02-2017 07:14:55 - Finished calculation of occupancy for storage bin ‘AAL01L00’, resulting in 17% and 0% pending.
Mandatory: 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.
Optional: Batched Wave picking process
This is a Roadmap Acceleration project and, once done, should be implemented as Process Request. See the functional description here.
Optional: Self-Replenishment process
This is a Roadmap Acceleration project and, once done, should be implemented as Process Request. See the functional description here.
Optional: Self-Organizing process
This is a Roadmap Acceleration project and, once done, should be implemented as Process Request. See the functional description here.
Optional: Self-Auditing process
This is a Roadmap Acceleration project and, once done, should be implemented as Process Request. See the functional description here.
Optional: Operator Load Balancing process
This is a Roadmap Acceleration project and, once done, should be implemented as Process Request. See the functional description here.
Configuration - Activity-11 - 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.
Configuration - Activity-12 - 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:
- Header-Attributes are part of the header of the Attribute-set: These are Lot, Serial and Expiry date and define the stock: Once they have a value, this value cannot change over time.
- Note the Lot can be used as Batch since -stricktly speaking- a Lot is a subset of a Batch.
- List-Attributes are attributes that can be added to the Attribute-set and these attributes describe the stock: The value can be given or changed without creating a new storage detail.
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:
- Blind Receipts: Some companies want to hide the expected quantity from the operators, but the manager should be able to see it.
- 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:
- 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.
- 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.
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.
Configuration (Optional) - Activity-13 - Batched Wave picking (Roadmap acceleration project)
- Definition Batch picking: A scheduled background process that triggers the picking activity for a predefined selection of Sales/Distribution/Work orders. Batch-picking is the process that group a (fixed) number of orders are picked at the same time to avoid multiple visits to the same bin. This is typically done to align picking activities with distribution schedules.
- Definition Wave picking: The execution of picking tasks by area in order to concentrate the workforce to the activity in that specific area. Wave picking is the process that pickings are executed by area and in programmed intervals (waves). This is typically done in environments with a hydraulic racking system or in environments that include cold-chain that idealy should be picked last. In Openbravo Advanced Warehouse this is done by configuring the Operator load Balancing process by Travel Sequence.
- Definition Batched Wave picking: The combination of both, resulting in the automatic generation of tasks according to a distribution schedule with the possibility to focus the workforce on specific areas or goods. Batched wave-picking combines both: Allow to create definitions of order-groupings (the batches) and use dynamic task-assignment to assign tasks of specific travel sequence (or other parameters like pop-code) before assigning other tasks.
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.
Configuration (Optional) - Activity-14 - Self-Replenishments (Roadmap acceleration project)
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.
- Minimum: If the actual Quantity OnHand in the SBG is equal to or below the specified minimum, a Replenishment task can be initiated.
- Maximum: The quantity to be picked and moved should not be greater than the bin capacity. The quantity to pick will be calculated as Maximum minus Quantity OnHand in the specified bin.
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 |
Configuration (Optional) - Activity-15 - Self-Organizing Warehouse (Roadmap acceleration project)
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 activating 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.
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:
- Maximum number of tasks per run (Prerefence),
- Priority of Reorganizing tre stock and this requires the Analyzing step below:
- Schedule the background process that generates these tasks in alignment with the operational situation.
Analyzing step:
- Select all StorageDetails that are
- in a Non-Functional IRA and
- have no Task in status Available and
- have no Replenishment definition.
- For each occurrence, set Reorg-Priority parameter according to the below:
- Reorg-Priority 99: Stock that is outside the SBG-List of the product.
- Reorg-Priority 88: Stock that is inside the SBG-List but in the last SBG of that list
- Reorg-Priority 77: Stock that is inside the SBG-List but not in the first SBG of that list
- 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:
- Difference => 20 (f.i. bin=>30, product=10): Reorg-Priority = 66
- Difference => 15 (f.i. bin=>27, product=10): Reorg-Priority = 65
- Difference => 10 (f.i. bin=>20, product=10): Reorg-Priority = 64
- 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.
Configuration (Optional) - Activity-16 - Self-Auditing Warehouse (Roadmap acceleration project)
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 |
Configuration (Optional) - Activity-17 - 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:
- Determine in the IR if a label (ID) should be requested,
- Determine in the IR which model/template should be used,
- Determine in the IR (optional) to which printer the output should go,
- Determine in the Product/Warehouse the quantity of ID per UoM (alternate UoM project).
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.
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.
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:
- productCode,
- productDescription,
- productCategory,
- productBrand,
- productEan,
- taskIr,
- taskDatetime,
- taskUser,
- taskQty,
- taskLocatorTo,
- printer
Also it will send all attributes that are relevant for that inventory:
- Attribute name (String),
- AttributeInstance value (String))
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:
- @ApplicationScoped
- @Qualifier(PrintingBroker.PRINTING_PARAMETERS_QUALIFIER)
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:
- final Map<String, Object> parameters = new HashMap<String, Object>();
- final Product prod = task.getProduct();
- parameters.put(“productCode”, prod.getSearchKey()); return parameters;
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"}
Configuration (Optional) - Activity-18 - 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 level can be set as follows:
- None: The verbosity is activated but no messages will be logged.
- Error: Only messages of the level 'Error' will be logged.
- Warning: Only messages of the level 'Error' and 'Warning' will be logged.
- Info: All functional messages (Info, Warning and Error) will be logged but no technical/stack information.
- Debug: All functional messages plus technical/stack information is logged.
Configuration (Optional) - Activity-19 - Retail Integration
In an environment with both Retail/POS and Advanced Warehouse Operations, it is important 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. Only if the fields are populated, the sales- or return-functionality of the POS will be restricted in the determination of the bin.
Operation
Performance Considerations
Front-End
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.
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.
Preferences
These preferences currently exist:
- Initial Data Load: Check the paragraph Initial Data Load for the preference when loading the stock from a legacy system to Openbravo.
- Front-End: Confirm when Unassign will ask the user "Are you sure" before unassigning the task.
- Front-End: Limit of Tasks loaded to the Mobile Application will set the maximum number of tasks that will be loaded to the mobile device. Unlike timed server-updates, Advanced Warehouse Operations will continuously update the server when online. For the scarse moments that the user is offline, we consider 30 tasks a good quantity to continue confirming preloaded tasks until the mobile device is online and synchronized again. In essence it is a work-force optimization (no other users can execute tasks that are loaded to assigned to another user) and performance measurement.
C:\Users\maarten\Google Drive\OB New functionalities\Inventory Management Projects\AWO-Back-End-Prefs-UseContains.jpg
- Back-End: Use Contains can be switched off to gain performance in searchesin big databases.
- Back-End: Enable Reservations should be set as it is used for Sales Order pickings.
- Back-End: The Hide XYZ of bins preference could be set to avoid the XYZ in the bin definition, as it is ignored in AWO.
- Front-End: Appearance and duration of messages can be set with the following preferences.
- Front-End: Message on Front-End Refresh can be set with the following preferences.
- Front-End: Use External Input is defaulted with this preference.
Offline Capabilities of the Front-End
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.
Initial 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.
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:
- Lookup or Put-Away of Storage Details in bins that belong to the determined warehouse.
- View, operate and assign tasks for transactions inside, to (receipts) or from (issues) the determined warehouse.
- Initiate receipt of Purchase Order that is defined to the determined warehouse.
- Initiate picking for Sales Order or Work Effort that is defined to the determined warehouse. Note: The warehouse of the WE is determined through the IssueBin of the Production Run.
Front-End User Interface
Task presentation
Tasks are presented on the Front-End in the following way:
- Filtered on Task.Assigned = User and Task.Status = Available;
- Maximum number of tasks per Front-End as set in the Preference;
- Sequenced by:
- Task.Priority (descending);
- Task.Travel Sequence (ascending);
- 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 the GTIN-14 code (Roadmap acceleration project)
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 tasks can be indicated with a green checkmark, orange ball or red cross. The meaning of this is the following:
- The Green CheckMark indicates:
- The Confirmed values are equal to the Expected values;
- No mandatory data is missing;
- The Task is ready to be confirmed.
- The Orange Ball indicates:
- The Confirmed values are not equal to the Expected values;
- No mandatory data is missing;
- The Task is ready to be confirmed.
- The Red Cross indicates:
- Some mandatory data is missing;
- The Task is not ready to be confirmed.
On Attribute-level
Mainly at the point of Goods Receipts moment, the attributes are marked if they require a value. See example below.
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:
- Confirm (when on a Task in status Available)
- Count
- Recount
- Put-Away
- Status
- Move
- Box
- Unbox
Further, there are tabs that show the related records for
- Tasks
- Transactions (history)
- Reservations
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.
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:
- 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.
- Scrolling down will load all the records and once loaded will execute the button on all selected rows.
- Refining the selection criteria in order to reduce the number of selected records to less than the limitation.
Multi-select without limitation (Roadmap acceleration project)
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:
- I manually request a put-away for 9.1234 kg of a certain product.
- The UOM 'kg' is defined with 3 decimals in the column Standard Precision
- The task(s) will be created for a total of 9.123 kg, ignoring the fourth decimal.
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.
- The column "Standard precision" in the Unit of Measure window determines the number of decimals that are relevant for logistical transactions.
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.
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.
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).
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.
Operator Load Balancing (Roadmap acceleration project)
The Operator Load Balancing functionality is a background/batch process that continuously looks at unassigned tasks, current assignments and autorization levels and assigns the tasks in sequence of their priority to the operator that is most likely to execute fastest, based on his queue of unconfirmed tasks.
The Operator Load Balancing does not affect tasks that are initiated from the Front-End, since these tasks implicitely are assigned to the user who initiated the transaction.
Operator Load Balancing is particulary interested when the system generates tasks in the background, for instance for picking, replenishing or auditing. For these tasks, this functionality will assign the proper operator according to the following intelligence that is to be configured in the Warehouse Definition window:
Input for the Operator Load Balancing process:
- Autorization levels as per the preferences by Inventory Transaction Type;
- Unassigned tasks in sequence of priority;
- Maximum number of tasks per operator, as preference of the Front-End.
Primary rules:
- Select tasks status available AND Assigned=null
- Assign tasks in sequence of
- Secondary rules.Sequence number,
- Task.priority,
- ITT not specified in Secondary rules (so that it is not mandatory to specify secondary rules..
Only assign tasks to operators that are authorized to execute this ITT. Do not exceed the number of assigned tasks per operator as defined in the preference.
Secondary rules:
- There will be a new tab in the Warehouse Definition window (after tab WA-Assignments) called “Task Assignments”. This will have the columns as per below and allows to configure which tasks should be assigned first. If nothing is defined, then the task-priority is leading:
- Mandatory: Sequence number
- Mandatory: ITT
- Optional: IRA
- Optional: SBG
- Optional: Travel Sequence (allow to use wildcards like Travel Sequence AA* means all TS that starts with AA
- Optional: Popularity Code (bin) From and To - will select tasks within the From-To range (from or to: see ITT definition).
- Optional: Product category
- Optional: Operator (note: the assignment process should still check if the operator is authorized!)
Assignment process:
- Should be scheduled as a process request.
- Must read ‘secondary rules’
- Should write verbosity INFO: All successful assignments. ERROR: When a secondary rule cannot be executed f.i. Operator is not authorized.
Default dataset should include these secondary rules:
Sequence | ITT |
---|---|
10 | REC-PI |
11 | CNT-PI |
12 | CYC-PI |
20 | PIK-SO |
21 | PIK-DOi |
22 | PIK-WE |
30 | ISS-SO |
31 | ISS-DOi |
32 | ISS-WE |
40 | DEV-XD |
41 | DEV-QI |
50 | RCT-PO |
51 | RCT-DOr |
52 | RCT-WE |
60 | PUT-TR |
61 | MOV-TR |
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.
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.
Lookup Inventory
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:
- If the product of the task has a primary logistical unit of measure defined;
- 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:
- 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.
- Available: The task is visible to the Front-End and can be confirmed.
- 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:
- The system checks if the organization is activated for Advanced Warehouse Operations.
- The system takes the warehouse from the header (not from the lines!) of the document.
- 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.
- 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.
- 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:
- The sales or distribution order has predefined reservations (allocated) that point to a specific attribute/bin.
- The put-away is initiated for a specific storage_detail / attribute.
- 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.
- 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.
- 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:
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. This can be seen in the Task window. Delta Management is activated 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.
Behavior in the Front-End
If a Task is confirmed with less quantity than the expected quantity, 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:
- Bin: In the case the Task is searching for a Bin: Same refers to the same bin and Different will propose a different bin according to the configuration of the warehouse algorithms for this ITT.
- Storage Detail: In the case the Task is searching for a Storage Detail: Same refers to the same storage Detail and Different will propose a different storage detail according to the configuration of the warehouse algorithms for this ITT.
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.
Behavior on the Back-End
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:
- In the case the Task is searching for a Bin: The current bin is temporarily blacklisted so that the Task Generator skips this Bin while it generates a new proposal. Note: No change to the Occupancy is done.
- In the case the Task is searching for a Storage Detail: The Storage-Detail + remaining quantity is temporarily blacklisted so that the Task Generator skips this Storage Detail while it generates a new proposal. Note: No Phuysical Inventory or status Change task is generated to provoke this behavior.
Document Generation
The generation of Tasks takes place in the Back-End and will create different Openbravo Documents. These are:
Reception List
Picking List
Issue List
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.
- Receipts for PO
- Receipts for DO
- Receipts for WE (Roadmap acceleration project)
Required Configuration:
- Is there an IR assigned to the ITT “RCT-PO"/"RCT-DO"/"RCT-WE"?
- Is there a WA assigned to the same ITT?
- If destination is a non-functional IRA:
- Does the product have a SBG-List?
- Does this SBG-List contain SBGs for the warehouse?
- 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.
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.
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":
Required Configuration:
- Is there an IR assigned to the ITT “PUT-TR"?
- Is there a WA assigned to the same ITT?
- Does the product have a SBG-List?
- Does this SBG-List contain SBGs for the warehouse?
- 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":
Required Configuration:
- 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.
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.
Generate Tasks for Batched Wave Picking (Roadmap acceleration project)
In order to generate tasks for Batched Wave picking, two steps must be completed:
- Setup the configuration for Batched Wave Picking to define which orders should be selected when.
- Setup the background process that generates these tasks.
Generate Tasks for Self-Replenishment (Roadmap acceleration project)
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 Batched Wave picking, two steps must be completed:
- Setup the configuration for Self-Replenishment to define which minimum quantity of which products should be in which bin.
- Setup the background process that generates these tasks.
Generate Tasks for Self-Organizing Warehouse (Roadmap acceleration project)
The Self-Organizing Warehouse functionality will generate Put-Away (ORG-TR) tasks in a scheduled background process for products that are not stored in their ideal bin.
Generate Tasks for Self-Auditing warehouse (Roadmap acceleration project)
The Self-Auditing Warehouse functionality will generate Physical Inventory Count tasks in a scheduled background process for products that match with the configured rules.
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:
- Is there an IR assigned to the ITT “PIK-SO"/"PIK-DO"/"PIK-WE"?
- 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. 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 front-End:
Other Picking transactions
- Picking for WE, see Advanced Warehouse Operations for Manufacturing.
- Picking for DO (Roadmap acceleration project)
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:
- 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.
- 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.
- 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.
- 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:
- Is there an IR assigned to the ITT “ISS-SO"/"ISS-DO"?
- 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.
From the front-End:
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
- Issueing for DO (Roadmap acceleration project)
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:
- 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.
From 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.
Tasks that have all required values filled-in, are flagged as 'Ready to Confirm'. The confirm button will execute the 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.
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.
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.
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:
- Goods Movement
- Goods Receipt
- Goods Issue (shipment, consumption)
- Inventory Adjustment
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.
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.
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.
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 window "Warehouse Verbosity Log" shows when and who invoked the TaskGenerater for which Inventory Transaction type.
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.
Reporting and Business Intelligence
Warehouse Task Report
The Task Report shows the details and values of the selected tasks.
Business Intelligence Cubes (Roadmap acceleration project)
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
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.