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

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

Search

Modules:Advanced Warehouse Operations

Languages: 

English | Translate this article...

Contents

Pending to document

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 space utilization and operator transactions, while increasing inventory accuracy. Abreviated as AWO, this module provides the infrastructure necessary to define warehouse structures and rules, and execute the operations through the Openbravo mobile technology as well as through the Openbravo backend functionalities. These operations include receipts, movements, pickings, replenishments, counts and several advanced operations as detailed below.

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

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

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

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

Group of Inventory- and Supply Chain Management functionalities

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

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

Scanners and other hardware devices for AWO

The Front-End functionality of AWO works with the same scanners / hardware set as the WebPOS / Retail Front-End. For more information please check this link

Licences

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.

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


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

Front-end menu for the operator

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

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

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

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




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

Configuration - Activity-1 - Activate Advanced Warehouse Operations on Organization level

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

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

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

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:

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:

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

Mapping of the physical spaces and routes of a typical warehouse

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

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

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

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

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

Other typical IRA are:

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

Storage Bin Group (SBG)

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

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

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

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

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

Storage Bin (SB)

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

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

The SB has the following attributes:

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

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

Travel Sequence

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

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

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

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

Bin.Popularity Code

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

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

Inventory Status (IS)

See this link for the Inventory Status conceptual description.

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

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

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

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

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

Storage Bin Capacity

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

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

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

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

Implementation advice for chaotic/random storage system: In order to use a chaotic (or random) storage system where multiple products can be stored in any bin, the bin-capacity should best be expressed in a unit of measure that is common for all products of the specific organization. The use of PL 'pallet' is an 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,

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

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

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

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

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

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

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

Then:

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

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.

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

Inventory Transaction Types (ITT)

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

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

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

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

Flow ITT System Action Back-End Front-End Document
Menu Button Menu Task Icon
Receipts RCT-PO Generates the AWO Receipt tasks for the selected purchase order. This ITT creates the stock and only needs the IRA-To. Purchase Order AWO-Button-BE-GR.jpg Receive AWO-Button-FE-RCT-PO.jpg Reception List
RCT-DO This ITT generates the AWO tasks to receive the stock from the in-transit location. Distribution Order(r) AWO-Button-BE-GR.jpg Receive AWO-Button-FE-RCT-DO.jpg Reception list
DEV-QI Deviation to Quality Inspection. If activated in the IR and the product requires inspection, the TaskGenerator deviates from the original ITT to the ITT DEV-QI and generates the task with this. No menu nor button, functionality is automatically invoked given the configuration. AWO-Button-FE-QI.jpg Goods Movement
DEV-XD 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. AWO-Button-FE-XD.jpg Goods Movement
Inventory Management PUT-TR Generates the AWO tasks that searches for the destiny bin in a storage area, given the configurations for IR and WA. Warehouse Operations AWO-Button-BE-PA.jpg Putaway AWO-Button-FE-PA.jpg Goods Movement
MOV-TR Generates the AWO tasks that puts the stock to a manually given destiny bin, regardless the configuration for Warehouse Algorithms. Warehouse Operations AWO-Button-BE-MOV.jpg Use "Put away" on the Front-End and overwrite To-Bin Goods Movement
IST-TR Generates the AWO tasks that moves the stock to a given new Inventory Status and creates On-The-Fly the temporary virtual bin with this status. Typically a task that is Auto-Confirmed. Warehouse Operations AWO-Button-BE-STS.jpg Status N.A. (Auto-Confirm) Goods Movement
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 Print N.A. (Auto-Confirm)
Physical Inventory CNT-PI Generates the AWO Count Pysical Inventory task for the selected Storage Detail. As this ITT is acting on a Storage Detail and not moving it, the IRA-From and -To are the same. Warehouse Operations AWO-Button-BE-CNT.jpg Not on FE AWO-Button-FE-CNT.jpg Physical Inventory Proposal
REC-PI Generates the AWO Re-count Pysical Inventory task for the selected Storage Detail. As this ITT is acting on a Storage Detail and not moving it, the IRA-From and -To are the same. Warehouse Operations AWO-Button-BE-REC.jpg Not on FE AWO-Button-FE-REC.jpg Physical Inventory Proposal
CYC-PI Generates the AWO Cycle-Count Pysical Inventory task for the selected Storage Detail. As this ITT is acting on a Storage Detail and not moving it, the IRA-From and -To are the same. Not relevant on Back-End. Count N.A. (Auto-Confirm) Physical Inventory Proposal
Production PIK-WE Status=Available. Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Production Run AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
PIK-WE Status=Reserved. Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Production Run AWO-Button-BE-RSV.jpg Not relevant on Front-End. Goods Movement
ISS-WE Roadmap Acceleration project to Issue ACTUAL components Production Run AWO-Button-BE-GI.jpg Issue AWO-Button-FE-ISS-WE.jpg Issue List
RCT-WE Roadmap Acceleration project to Receive ACTUAL finished product Production Run AWO-Button-BE-RCT+BFLUSH.jpg Receive (&Backflush) AWO-Button-FE-RCT-WE.jpg Reception List
Sales PIK-SO Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Sales Order AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
PIK-DO Generates the AWO tasks that searches for the Storage Details given the configurations for IR and WA. Distribution Order(i) AWO-Button-BE-PK.jpg Pick AWO-Button-FE-PK.jpg Goods Movement
ISS-SO Generates the AWO tasks that takes the previously allocated/picked Storage Details for the given Sales order with the objective to issue the stock to the business partner. Sales Order AWO-Button-BE-GI.jpg Issue AWO-Button-FE-ISS-SO.jpg Issue List
ISS-DO Generates the AWO tasks that takes the previously allocated/picked Storage Details for the given Distribution order with the objective to issue the stock to the business partner. Distribution Order(i) AWO-Button-BE-GI.jpg Issue AWO-Button-FE-ISS-DO.jpg Issue List

Authorization by ITTs (Roadmap acceleration project)

This functionality will allow to grant access to the Front-End at two separate authorization levels:

  1. Initiate Transactions and implicitely auto-assign and execute the resulting Tasks.
  2. Execute pre-assigned Tasks.

The initial functionality request was to show/remove the front-end menu options by using preferences. So if user X has “Picking”=Y, then show picking. This is how it works in the WebPOS, but for AWO this will not work, because in the AWO case there is a main difference: Picking can be for SO, for DO or for WE, same for Receipts. So the proposal is to define the access in FE to the User and Inventory Transaction Type and define them as preferences like in WebPOS. For each ITT there should be 2 authorization-levels:

  1. Authorization to initiate. If no for (f.i.) RCT-PO, the user will
    1. ...still see “Receipts” in the menu (for DO or WE)
    2. ...not see Purchase Orders when searching.
    3. ...still be possible to Assign a RCT-PO to himself (this depends on the flag “Authorization to Execute”, below).
  2. Authorization to execute. If no for (f.i.) RCT-PO...
    1. also Authorization to Initiate must be no; If Yes, “Authorization to initiate” can be Yes or No.
    2. ...the user will not see RCT-PO tasks in the Assign menu

Note: Differences in the Authorization level between Front-End and Back-End should be managed separately.


Task Types (TT)

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

The Task Type defines:

  1. the priority-base, priority-increment and mnemonic and color of the tasks in the User Interface.

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

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

Warehouse Algorithms (WA)

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

There are two types of algorithms:

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

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


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

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

Dynamic Priority

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

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

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

Priority for GroupTasks

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

Configuration - Activity-4 - Mapping of the Warehouse Routes

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

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

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

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

Routing (R)

Definition: A Routing is the route that the goods are to follow in the specific situation. 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 R also determines the behavior of the Back-End process by specifying the following, see below:

  1. Confirmation-type,
  2. Print ID;
  3. Print Group (RM Acceleration)
  4. Deviate to Quality Inspection;
  5. Deviate to Cross-Docking (RM Acceleration).
  6. Forward (RM Acceleration)

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

  1. Show expected Qty
  2. Default Confirmed Qty
  3. Default Bin-From
  4. Default Bin-To
  5. Hide / Show specific attributes of the Attribute List


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

Confirm

The Confirm flag determines if the task will need manual confirmation of the execution or if the task is confirmed (& executed) automatically immediately after it's creation. Tasks that are confirmed automatically are visible in the Task View, with processed flag=yes.

Print_ID

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

Deviate to Quality Inspection

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

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

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:

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

Configuration - Activity-5 - Product/Warehouse characteristics

Product Parameters

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

SBG-List

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

Product/Warehouse parameters

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

Storage Bin

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

Product.Popularity Code

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

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

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

PrintID_Qty and PrintID_UoM (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 IR and WA

Routing Assignment (R-A)

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

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

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

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

Mandatory conditions

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

Optional conditions

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

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

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

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

Warehouse Algorithm Assignment (WA-A)

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

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

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

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

Mandatory conditions

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

Optional conditions

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

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

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

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.


The three ITT and their typical use are these:

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

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

Configuration - Activity-8 - Intra-Warehouse 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 Order project and FrePPLe integration.

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.

ITT for Replenishment

RPL-TR

Generation of Tasks

Manually in the Warehouse Operations window. Automatically with the Task Generator

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:

1. Dynamic priority / Recalculate task priority

The priority of tasks in status Available should be recalculated, adding the value of the field "Priority Increment" of the task Type to the tasks.

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

2. Occupancy and Pending occupancy recalculation

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

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

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

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

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

Verbosity for Occupancy calculation

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

3. Reprocess Syncronization Errors

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

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

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.

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

Configuration (Optional) - Activity-12 - Warehouse Front-End Configuration

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

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

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

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

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

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

Configuration (Optional) - Activity-13 - Printing Integration

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

Internal Print Services

Roadmap acceleration project.

External Print Services

Integration with BarTender using Webservices

Configuration in Openbravo

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

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

The BarTender printing setup in Openbravo Advanced Warehousing.

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

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

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

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

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

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

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

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

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

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

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

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

Configuration (Optional) - Activity-14 - Activate Verbosity

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

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

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

Operation

Performance

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.

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.

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

Front-End Autentication

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


Front-End Warehouse Restriction

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

Preferences

These preferences currently exist:

The preferences determine default behaviour.
Enable Stock Reservations.
Hide the Row(X), Stack(Y), Level(Z) of the bins.
Appearance and duration of the front-end messages.
When refreshing, already inputted but not confirmed data is lost.

Offline Capabilities of the Front-End

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

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

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

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

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

Offline Error-Monitoring in the Back-End

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

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

Front-End User Interface

Auto-Refresh and Reload

Static Data

Products and Bins, including Virtual bins from the inventory Status changes, are refreshed upon login and every nn minutes as set by the preference.

@GAL: Preference

Dynamic Data

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

Indicators on Task-level

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

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

On Attribute-level

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

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

Warehouse Operations window

The new window Warehouse operations will show all Storage Details and is designed to facilitate a wide range of common activities on those Storage Details that can be executed by tasks. The following buttons will be eventually available:

Further, there will be tabs that show the related records for

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

Multi-select and Execution

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

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

Multi-select and limitation

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

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


The limitation of 100 rows in the grid can be configured differently, or the user can scroll down to force that all records are loaded before execution.

Alternative Unit-of-Measure in the tasks and Decimals

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

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

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

Decimals and Logistical units

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

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

The task is created with the Alternate UoM with and conversion rate and presented with that on the Front-End.

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

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

Assign Tasks

Assign from the Back-end

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

Assigning existing but unassigned tasks in the Back-End.

Assign from the Front-end

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

Assigning available but unassigned tasks in the Front-End.

Dynamic Task Assignment (Roadmap acceleration project)

The Dynamic Task Assignment 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.

Dynamic Task Assignment will hide the manual assignment window of the back-end, that allows to assign the operator to the resulting tasks. As a result the task is created unassigned and will be selected by the batch process.

The Dynamic Task Assignment does not affect tasks that are initiated from the Front-End, these will be assigned to the user who initiated the transaction.

Input for the Dynamic Task Assignment:

Unassign Tasks

Unassign from the Back-end

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

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

Unassign from the Front-end

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

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

Lookup Inventory

Searching for inventory by product, EAN or attribute values.

Generate Tasks

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

Expected and Confirmed values

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

Alternate Unit of Measure

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

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

Task Status

Tasks can have three different Status values:

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

Determination rules of the From/To

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

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

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.

Delta Task identification in the window for Tasks.


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:

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

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

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:

Document Generation

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

Reception List

Receiving generates a Reception List.

Picking List

Picking generates a Picking List.

Issue List

Issueing generates an Issue List.

Physical Inventory Proposal

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

Generate Tasks for Receipts

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

Required Configuration:

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

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

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

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

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

Generate Tasks for Put-Away

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

The window Put-Away Stock":

Pre-refactor Put-Away.

Required Configuration:

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

Generate Tasks for Move Stock

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

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

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

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

Required Configuration:

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

Generate Tasks for Physical Inventory

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

Initiating a Count or Recount from the Warehouse Operations window.

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

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

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

Generate Tasks for 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 storage areas open for public, or in (production) areas where specific material is continuously consumed, there should be always enough material to serve the customer or internal process. In these situations the product is also stored in a bulk-storage area.

This functionality will allow to set minumum/maximum quantity per product per SBG/Bin. The recurring batch process will generate intra-warehouse Replenishment tasks for all products that are below their minimum level to avoid that the customer can't buy or internal process halts due to unavailable inventory.

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


Generate Tasks for Self-Organizing Warehouse (Roadmap acceleration project)

The Self-Organizing Warehouse functionality will generate Put-Away tasks in a recurring batch process for products that are stored in a different area than expected.

According to the products' SBG-List, the product has assigned one or several SBG's where it may be stored. Due to internal re-organizations, expanding or decreasing SBG's, changing popularity codes or simply manually deviated put-aways, the stock can be physically in a not-ideal area. This functionality will detect that and generate and assign Put-Aways according to the configuration of the warehouse.

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

Generate Tasks for Self-Auditing warehouse (Roadmap acceleration project)

The Self-Auditing Warehouse functionality will generate Physical Inventory tasks in a recurring batch process for products that match with the predefined rules.

The batch process will read the rules and generate Physical Inventory tasks to continuously 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

Generate Tasks for Picking

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

Required Configuration:

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

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

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

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

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

From the front-End:

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

Other Picking transactions

Generate Tasks for Issues

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

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

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

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

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

Required Configuration:

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

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

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

Generation the Goods Shipment from the Sales Order window.

From the front-End:

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

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


Other Issueing transactions

Generate Tasks for Inventory Status change

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

Required Configuration:

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

See chapter Inventory Status for the details on this.

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

Changing the Inventory Status in the Warehouse Operations window.

From the front-End:

Changing the Inventory Status on the Front End.

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

Monitor Picking/Issueing progress in the Back-End

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

Comparison with the similar flags in the Production Run

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

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

Confirm Tasks

From Front-end

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

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

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

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

From Back-end

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

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

Attributes

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

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

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

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

Changes to an existing Attribute-Set

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

Resulting Inventory Transactions

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

Differences between Expected and Confirmed

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

Confirmed Quantity is less than Expected Quantity

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

Confirmed Quantity is bigger than Expected Quantity

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

Confirmed Locator is different than Expected Locator

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

Cancel / Delete Tasks

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

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

Reprint Product ID (label)

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

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

Verbosity

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

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

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

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

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

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

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

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

Reporting and Business Intelligence

Task Report

Business Intelligence Cubes

Examples for Combinations with Advanced Warehouse Operations

Food Truck or Van Sales

AWO-PLUS-VanSales.jpg

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


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


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

Back-end Performance Tests

Introduction

These tests below have been executed as part of the first version of Advanced Warehouse Operations 17Q4.

The goal of this testing has been to ensure the proper behavior of the application while having an acceptable performance in environments with high volumes of data.

In order to do so, a mix of dummy data and properly created transactional data has been generated to populate the instance.

The results of this test should be used as an approximation to a real environment. However, since the bulk of the data is composed of dummy data, the real performance of the application can slightly differ from the obtained results.

Scenario

The scenario created for the performance testings starts with several Warehouses properly configured to work with Advanced Warehouse Operations.

In this case, a total of eight Warehouses have been created. This number is rather small, but since all the Advanced Warehouse Operations are focused in the same Warehouse, increasing the number of Warehouses had no effect on the performance, therefore it was not needed to create any more.

However, there are some other tables that can have a big impact in Advanced Warehouse Operations if not managed properly. For those tables, this are the number of records that have been created:

Storage Bins

The goal was to have one Warehouse with more than 10 million of Storage Bins and another one, used in most of the performance testing, with more than 100.000 Storage Bins.

The Warehouses with the largest amount of Storage Bins are

Warehouse No. of Records
Massive Data Warehouse 11.100.012
US West Coast 112.307
US East Coast 11.254

Storage Bin Capacity

The goal was to have one Warehouse with more than 10 million of Storage Bin Capacities and another one, used in most of the performance testing, with more than 100.000 Storage Bin Capacities.

In order to do so, a Storage Bin with 10 capacity records has been cloned to achive this figures

The Warehouses with the largest amount of Storage Bins are

Warehouse No. of Records
Massive Data Warehouse 10.000.010
US West Coast 104.088
US East Coast 18.801

Storage Details

The goal was to have one Warehouse with more than 10 million of Storage Details and another one, used in most of the performance testing, with more than 100.000 Storage Details.

The Warehouses with the largest amount of Storage Details are

Warehouse No. of Records
Massive Data Warehouse 10.000.002
US West Coast 111.148
US East Coast 20.193

Tasks

The goal was to have a total of more than 50 million of Tasks, in the same Warehouse that is used for most of the performance testing

The Warehouses with the largest amount of Tasks are

Warehouse No. of Records
US West Coast 50.014.565
US East Coast 21.362

Products and Storage Bin Group List

The goal was to have a total of more than 1 million of Products, with their own Storage Bin Group List with 10 lines each, for a total of more than 10 million Storage Bin Group List Lines

Table No. of Records
Product 1.021.171
Storage Bin Group List 1.017.464
Storage Bin Group List Lines 10.029.831

Results

In order to test the performance with the previous scenario, the already existing automated tests have been launched several times to simulate a real life scenario in which all the Warehouse Operations are executed mixed between them.

The central piece of code that manages the Warehouse Operations is the Central Broker, it is called for both Tasks generation and Tasks confirmation.

From the last 174 calls to the Central Broker this were the results

In an scenario with a Purchase Order with 1.000 lines that needs to create the Put-Away:

Chart of the ime taken in the execution of two runs of the automated tests:

AWO Performance Chart.png


Time taken in the execution of a run of the automated tests in the Console (some tests failed due to wrong data, that was expected):

AWO Performance1.png


Time taken in the execution of a run of the automated tests in the Profiler:

AWO Performance2.png


Slower queries in the execution of a run of the automated tests:

AWO Performance3.png


Considerations over the results

Conclusion

The time taken to generate the Tasks is defined by the configuration (number of records that the process needs to loop) rather than by bottlenecks in the process.

This means that if the Warehouse is configured properly, the performance of the application will be acceptable. If the performance is not what it was expected, the Warehouse Configuration should be reviewed first.

Limit scenarios

Some scenarios can reach the performance limits of Advanced Warehouse Operations.

Put-Away

If the Put-Away Warehouse Algorithm needs to loop over tens of thousands of Storage Bins to find one the performance will be compromised.

This can only happen if the Warehouse itself has tens of thousands of Storage Bins and the Algorithm loops through them all without being able to place the Stock.

This points to a possible Configuration problem

Both scenarios for a Order with one line

Picking

If the Picking Algorithm needs to loop through thousands of records without finding any Stock, the performance will suffer.

This can only happen if the same Product is placed over thousands of Storage Bins, with very a small quantity in each one of them, and an Order is placed requiring a huge quantity of this Product.

This case points to a possible problem in the Warehouse Configuration.

Recalculate Occupancy

It works with acceptable times (under 5 minutes) for Warehouses with tens of thousands of Storage Bins.

However, it has big performance issues with Warehouses of millions of Storage Bins.

Warehouse Configuration Check

This process is meant to be used while configuring a new Warehouse, not with one that is already being used.

Also, it works with acceptable times (under 10 minutes) for Warehouses with tens of thousands of Storage Bins.

However, it has big performance issues with Warehouses with millions of Storage Bins.

Additional Information

List of significant tables with more than 1.000 records


Table No. of Records
obawo_task 50.035.948
obawo_verbosity_log 50.027.547
m_locator 11.226.681
m_storage_detail 10.134.629
obawo_locator_capacity 10.122.900
m_attributesetinstance 10.106.695
obawo_locator_group_line 10.029.831
m_product_acct 1.021.215
m_product 1.021.171
obawo_locator_group_list 1.017.464
m_transaction 61.295
m_inoutline 43.385
m_productprice 42.310
ad_pinstance 33.176
m_inout 29.947
c_orderlinetax 24.548
c_orderline 24.539
obawo_batchoftasks 24.143
fact_acct 23.330
obawo_locator_group 17.243
m_stock_proposed 15.552
fin_payment_schedule 12.864
fin_payment_scheduledetail 12.076
c_ordertax 11.372
c_order 11.364
obawo_warehouse_rule_assi 9.582
m_product_aum 9.047
obawo_receptionlist 8.977
m_movementline 8.259
m_movement 8.259
c_invoicelinetax 6.123
c_invoiceline 6.121
m_transaction_cost 5.676
m_product_org 3.691
obawo_invprop_line 1.990
obawo_inventorylist 1.988
obawo_inventory_prop 1.988
obawo_internal_routing_assi 1.928
m_attributeset 1.917
m_attribute 1.911
m_costing 1.836
m_inventoryline 1.667
fin_payment_detail 1.518
c_invoice 1.517
fin_payment 1.384
m_inventory 1.313
obawo_pickinglist 1.220
m_reservation_stock 1.205

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

This page has been accessed 7,509 times. This page was last modified on 22 September 2017, at 00:45. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.