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

This module, abreviated as AWO, 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.

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:

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

Advanced Warehouse Operations consists of a set of functionalities that enable warehouses to optimize space utilization and operator transactions, while increasing inventory accuracy. Together with a proper planning and execution of replenishments this will have a positive effect on sales while reducing costs of inventory. It also gives tools to reduce Excess & Obsoletes.

Advanced Warehouse Operations is a flexible solution for simple or complex, manual or automated warehouses. 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.

Configuration

The main new concept and paradigm-shift that is introduced with Advanced Warehouse Operations (AWO) is 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 Internal Routings (IR), Storage Bin Group (SBG), the capacity constraints and warehouse algorithms;
  3. Display the tasks in sequence of their priority and in a simple and user friendly user-interface;
  4. Update the transaction as 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 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 - 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.

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 control.

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 requsted 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, e.g. a non-functional IRA.

The crucial difference from a warehousing perspective is that 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 IRA. For a non-functional IRA in contrast, the goods stay for a certain period in the non-functional IRA 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 IRA, typically only set true for 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 counts with numerous SBGs in order to organize the storage, minimize inventory losses and optimize space-utilization and inter-warehouse trafic.

Storage Bin (SB)

Definition: A Storage Bin is the smallest unit of space (volume) in a warehouse that the organization want to recognize. Not all SB 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.

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 primery 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.

Note that the Travel Sequence plays a role when the tasks are presented on the screen or on paper, not when the tasks are determined: The determination of the tasks is executed by the warehouse rules.

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 put-away process. 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 (introduced with the Inventory Status project)

Definition: The inventory status of the Bin defines the default IS that any inventory that is received in that specific bin will adopt. The IS are defined on client level and are valid for all organizations. They define what is and what is not possible with the inventory through these three settings:

  1. Available y/n - defines if the specific inventory is available for general business flows like sales 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.
  4. Supplier Consignment y/n - defines if the value of the inventory is taken into account in the general ledger. If "Yes", the value is not taken into account in the general ledger, but is added to the accounts payables when it is consumed.

Note: Customer Consignment is not a separate flag since this functionality is obtained by creating bins in a virtual customer location. The customer must be obliged to inform consumption of the material so that it can be included in the accounts receivable process.

Storage Bin Capacity (Alternative UoM project)

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 storage bin selected has capacity of 25 units for any product of the category "Quechua Shoes". Note that this is not a best-practics 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 are defined in the SBG and SBG-List.
Storage Bin Capacity - How to use it?

The bin-capacity is defined as an 'inclusion' of the specified capacity, expressed as a quantity in a certain UoM for a product or all products that belong to a certain product-category. 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 Non-functional IR-Area,
  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-2 - Mapping of the Warehouse Activities

Inventory Transaction Types (ITT)

Definition: The Inventory Transaction Type is the definition of the 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.

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

Autorization by ITTs (Roadmap acceleration project)

This functionality will:

  1. Show the menu-options on the Front-End in function of the granted authorizations.
  2. Show/Hide the buttons in the Back-End in function of the granted authorizations;
  3. Show, on the Front-End, the related documents -and as such allow to assign them or initiate transactions for them- in function of the granted authorization.
  4. In combination with the Dynamic Task assignment functionality, assign only those tasks where the operator is authorized to execute.

In the Advanced Warehousing Operations, the activity of picking can be done for different document types: for SO, for DO or for WE. The same is valid for Receipts and also for Physical inventory tasks there can be Initial-Counts and Re-Counts. Some organizations allow only specific personnel to recount. This is the reason why the authorization is linked with the Inventory Transaction Type.

The authorization settings will use the same technology as currently used in the WebPOS: Preferences.

So the proposal is to link access in both FE and BE to the Inventory Transaction Type and define the preference with User and ITT.

Base Task Types (BTT)

Definition: A Base Task type defines the fields of the task that are relevant for the mobile user interface. The Base Task Types are defined on client level and come with the installation.

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

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

Task Types (TT)

Definition: A Task Type is a grouping of tasks were originated from different IR but share the same purpose.

The Task Type defines:

  1. the priority-base, priority-increment and mnemonic and color of the tasks in the User Interface.
  2. the defaulted values to the Confirmed fields:
    1. Quantity
    2. Attribute
    3. From
    4. To
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 stock detail.
The list of current warehouse algoritms and, implicitely, an indication of potential warehouse algorithms.

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.

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.

Configuration - Activity-3 - 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 Internal Routings (IR). 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 IR can be configured to presented and to behave in specific ways:

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

Internal Routing (IR)

Definition: An Internal Routing is the route that the goods are to follow in the specific situation. The IR consist of one (1) IRA when there is just a receipt or issue and of two IRA when there is a from- and a to- IRA relevant.

An example of several IR 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 Internal Routing sequence determines if a print activity should be initiated. Further configuration is needed to inform the quantity of labels, the format and printer.

Deviation: Inspection IR (Roadmap acceleration project)

If flagged, 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 "INS-TR". If an IR is found, the task will be generated with the settings of the new IR.

Deviation: 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:

Configuration - Activity-4 - 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-5 - Assignments of IR and WA

Internal Routing Assignment (IR-A)

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

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 thus behavior), the assignments can be conditioned with the below set of parameters. To establish an order of prioritization, each parameter is given a weight which at the end of the pre-assignment determines the final IR.

Pre-assigment process: In the example below there are three different IR assigned to the ITT Receipt Purchase Order. In case that the business partner category from the purchase order matches with the condition, this assignment will be valued with 10 points. In the case that the product category of the purchase order matches with the condition, this assignment is value with 20 points, etceteras. At the end of the pre-assignment, the IR with the most points is assigned and used in the generation of tasks.

The Receipt Purchase Order inventory transaction type can find different IR. The image shows the use of the product category and business partner category in the conditions for the assignment.

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 WA-Assignment can have multiple WA per ITT, because an WA-Assignment does not guarantee a successful return. See the configuration for Receipt Purchase Order below:

  1. The first WA will try to return the bin where the product AND lot is already present. In case a new lot is received, it will return NULL and the second WA is invoked.
  2. The second WA will try to return the bin where the product is stored, regardless the lot. If there is no stock of that product in the determined IRA, it will return NULL and the third WA is invoked.
  3. This continues until a bin is found or ends in an error message.

The WA-A is sequencing the bins or inventory to be able to produce the optimum proposal within the limitation of the IRA as determined by the IR-A.

Unlike the IR-Assignment, The WA-Assignment can have multiple algorithms per ITT.

See these UI-mockups mockups for a sense of the user-experience.

Configuration (Optional) - Activity-6 - Intra-Warehouse Replenishments

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 id open for general public whereas the bulk storage area is only accesible for employees. Note: Inter-Warehouse Replenishments are not covered in Advanced Warehouse Operations but form part of the Distribution Order project and FrePPLe integration.

Min/Max per product per SBG

In the Replenisment window it will be possible to define per product and SBG, always inside a specified organization/warehouse, the minimum level and the maximum level, 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 SBG can physically hold. The quantity to pick = Maximum -/- Quantity OnHand in the specified SBG.

ITT for Replenishment

RPL-TR

Generation of Tasks

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

Configuration (Optional) - Activity-7 - 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 etup in the Print ervice, 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 Internal Routing (IR).

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 Internal 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 Internal Routing, set the flag Print-ID. That will show the Warehouse Printer field, and the Print ID Template field.

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

When we generate Tasks from the differents 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 the print-flag- can be printed with the Print-button on the Task-window in the backend.

When we generate Tasks from the differents 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 the print-flag- can be printed with the Print-button on the Task-window in the backend.

The internal process that generate 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 Internal Routing configured previously, or -if empty- apply the Bartender printer selction logic.

Add new Parameters: This print process can be extended, and the user can add extra parameters to this 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 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. And example of a new parameter returned here is:

The system will take all the classes that implements 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-8 - Generate WorkRequirements through WebServices

Advanced Wareouse Operations for Manufacturing (AWO-MFG) include the possibility to have a third-party software create the Work Requirements (WR) and -optionally- process it and generate the Work Effort (WE), Production Run (PR) and Material List (ML) by the use of WebServices.

The optional Processing of the WR (and subsecuent generation of the WE, PR and ML) is activated by passing a header parameter, called "Process", with true or false.

Find below the instructions and an example of the message-content:

  1. The WebService URL is : <hostAddress>/ws/org.openbravo.warehouse.advancedwarehouseoperations.manufacturing.addWorkRequirements
  2. The header parameter has to be added like the Authorization parameter.
  3. Bear in mind that all the referenced ID's like the Organization, Client, Processplan, etc, must exist on Openbravo.
The header parameter that will process the WR and generate WE, PE and ML.

Operation

Preferences

These preferences currently exist:

The preferences determine default behaviour.

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 aware of the detailed situation of all inventory, reservations and other tasks. During generation of tasks on a Storage_Detail, the system will check if that Storage_Detail is compromised with a detailed reservation or if another task already exists and is pending to be executed. If so, this Storage_Detail is ignored. This mecanism 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 tasks can be confirmed as if it 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.

Assign Tasks

Assign from the Back-end

In the task window you can edit the user field. With that, the task is assigned. 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 the product, EAN/UPC or attribute value and select the tasks. Alternatively browse the unassigned tasks and select those to work on.

Assigning existing 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.

Dynamic Task Assignment will hide the manual assignment window of the back-end, that allows to assign the operator to the resulting tasks. As 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- than 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 must be confirmed in a second screen.

Select the task to unassign and press 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 automatically generated, given a correct configuration, as a result of a logictical transaction. The content of the tasks, i.e. priority, task-type, from- and to- bin etceteras is derived from the configuration.

Determination rules of the From/To

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

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 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: Press 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 blanks 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: Press the menu Receipts menu will allow to scan, enter or search for open documents, as per 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 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). When a document is selected, the relevant picking process is executed and tasks are generated.

Initiating the picking for the selected Production run of the Work Effort will generate Picking Tasks for all components (P-) previously not picked.

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?

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

Picking for WE

The Pick-To bin is setup in the manufacturing cost center.

The Pick-To bin can be predefined in the Manufacturing Cost Center.

Other Picking transactions

Generate Tasks for Put-Away

The Put-Away functionality allows to generate a task for any storage detail, given a complete 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.

Required Configuration:

  1. Is there an IR assigned to the ITT “PUT-*"?
  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 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 Audit (Roadmap acceleration project)

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

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, will flag the task as ready to confirm. The confirm button will execute the actual confirmation.

From Back-end

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

Confirming a Task from the back-end and overriding the -possible- user-assignment.

Attributes

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

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.

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. 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 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 Tasks

In the case the task will not be executed, the user can delete the task in the backend task-window.

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

Reprint Product ID (label)

In the Back-end task window, any processed/confirmed task can reprint the Product ID.

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

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

This page has been accessed 1,635 times. This page was last modified on 28 September 2016, at 11:33. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.