This chapter covers the following topics:
This chapter contains a detailed discussion of the complete Task Management process, which consists of task creation, splitting, merging, assignment, dispatching, and execution. It provides the basic fundamentals of tasks as well as highlights decisions that may impact the implementation. It also discusses key setup areas, and helps to troubleshoot some basic problems that may be encountered during implementation or warehouse operation.
Task management is used in many processes in Oracle Warehouse Management. It is used for material transfers required for sales order picking, replenishment, picking for manufacturing, and requisition move orders. It is also used for cycle count tasks.
The following table outlines which of the task management features are applicable for each of these different types of tasks, and how the features differ for different task types.
| Task Type | Sales Order | Internal Order | Replen. | Move Order Issue | Move Order Transfer | WIP Picking | Cycle Count | Putaway |
|---|---|---|---|---|---|---|---|---|
| Task Create Process | Pick Release Cycle Count Workflow |
Pick Release Cycle Count Workflow |
Move Order Pick Slip Report N Step putaway workflow |
Move Order Pick Slip Report | Move Order Pick Slip Report | Comp. Pick Release | Cycle Count Schdl. Cycle Count Workflow |
LPN Scan or Pregen.Putaway |
| System Task Type | Pick | Pick | Replen. | Move Order Issue | Move Order Transfer | Pick | Cycle Count | Putaway |
| Allocate | Yes | Yes | Yes | Yes | Yes | Yes | NA | NA |
| Pick Method | Yes | Yes | No | No | No | Yes | NA | NA |
| Paper Assist Pick | Yes | Yes | Yes | Yes | Yes | Yes | No | NA |
| Task Type Assn. | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Task Split | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Task Dispatch | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Putaway Drop All |
| Task Load | Yes | Yes | Yes | No | Yes | Yes | NA | Yes |
| Task Drop | Yes | Yes | Yes | Yes | Yes | Yes | NA | Yes |
| Label Printing | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Op. Plan | Yes | Yes | No | No | No | No | No | Yes |
| Task Plan | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Whse. control board | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
Each of the different business flows has different processes to create tasks. For instance, sales order tasks are created by using the Pick Release program to select specific sales orders to include in release. It is only after these respective processes run that tasks are visible to Oracle Warehouse Management as Unreleased or pending work.
All these processes require you to set up data. For instance, prior to running Component Pick Release to create tasks for manufacturing components, you must define the job or schedule. Prior to creating Move Order Issue tasks, you must create and approve the Requisition Move Order.
The pick release process releases internal and external sales orders to the warehouse floor. The Pick Release window has many options to control which lines to select for pick release and how to restrict the material the system considers available for pick release, as well as several other options.
Selection criteria for the release lines to include are as follows:
Order number
Order type
Order status
Customer address
Ship to address
Dates of scheduled shipment
Customer request dates.
You can also select lines based on delivery or trip, if these have been created in advance, or via ship method or order priority.
Pick release establishes the sales order allocation sequence in case of short supply, optionally specifies the staging lanes, and controls if deliveries are automatically created as part of the pick release process using the Delivery Grouping Rules defined on the Shipping Parameters window. Other options control if pick release is restricted to lines for which prior reservations were made, and can be further restricted to consider only material from a particular subinventory or locator.
A pick release option controls if the move orders are automatically allocated, or if allocation happens later by a manually triggered process. Set this option to automatically allocate the move order, except when you want to troubleshoot with the Rules Engine Simulator.
Another pick release option controls whether the allocated move orders are automatically transacted, which bypasses much of the rest of the task management process. In an Oracle Warehouse Management enabled organization, automatic confirmation is typically disabled except in certain situations. A serialized item cannot be transacted by auto pick confirmation if serial allocation is disabled. In the absence of customizations , if auto-pick confirmation is enabled, then the only mobile shipping method available for use is the Quick Ship method. Another pick release option controls if the system should create a task with an unreleased or pending status You can also set task priority at pick release. If necessary you can use the warehouse control board to change the task status, and priority.
In addition, the cycle count workflow can create sales order tasks by automatically re-allocating new material when a sales order task is underpicked
The system creates replenishment tasks (and allocations) when the Move Order Pick Slip report runs. You must also run the Min-max planning report prior to running the Move Order Pick Slip report.
The Min-max Planning Report creates the move orders based on selection criteria, such as item category, and planner and buyer, and also controls which sources of demand and supply are included. This creates the move orders, but the Move Order Pick Slip report actually allocates these move orders and creates the tasks to perform. Alternatively, you can choose Allocate in the Transact Move Order window to manually allocate the move orders the Min-max Planning Report creates.
In addition, the n-step putaway workflow can create replenishment tasks when an LPN is dropped to an intermediate staging location that differs from the initial putaway suggestion provided by the system. The replenishment task directs the operator to move the material from this intermediate location to its final destination.
The system creates Move Order Issue & Transfer Requisition move order tasks (and allocations) when the Move Order Pick Slip report is run for approved move orders. Similar to replenishment, a two step process is used to create the move order, and then allocate the move order. Alternatively, you can choose Allocate in the Transact Move Order window to manually allocate the move orders the Min-max Planning Report creates.
The system creates tasks to pick components required for manufacturing jobs when Component Pick Release is run. Component pick release allocates and creates the tasks. Different user-interfaces are used based on manufacturing mode: discrete jobs, repetitive jobs, lot-based jobs, and flow schedules each have separate component pick release processes with different selection criteria. See: Manufacturing Picking.
Tasks for cycle counting are automatically created when the counts are scheduled. This is triggered via the Cycle Count Scheduler, accessible from the cycle counts window. You must create the cycle count header prior to scheduling cycle counts.
In addition, the cycle count workflow can create cycle count tasks by automatically generating a task to count the material that the operator was unable to find when executing a picking task. In creating this cycle count task, the system also automatically places a reservation on the missing quantity so that it is not allocated for other tasks until the discrepancy is resolved
Each of the different business flows for which tasks are created has a System Task Type. The system defines System Task Types, and groups them by similar sets of features. The System Task Type is automatically assigned to every task when it is created and cannot be edited. Tasks within the same System Task Type can be further classified by User Task Types, which are assigned at a later point by the Rules Engine.
All material movement tasks require a source and a destination for the material. Only cycle count tasks do not require material movement, and are not allocated. All other tasks use the Rules Engine to allocate material and, if necessary, a destination locator.
Allocation is performed during pick release, if auto-allocate is enabled. If the move order is not automatically allocated during pick release, you can use the Allocate button on the Transact Move Order window to allocate it at later point.
The Rules Engine allocates material based on defined picking rules. If the sales order was reserved, the reservation is viewed as an additional constraint on the rule. If you entered a subinventory or locator in the Pick Release window, these also act as additional rule constraints. The system applies these constraints together to find available material to allocated for the sales order. If no material is found, the system backorders the delivery.
The Rules Engine is also used to select the staging lane if none was specified on the pick release window or selected by previously defined dock door appointments. Otherwise, the Rules Engine is used to validate the staging lane.
The Move Order Pick Slip report performs allocation. The Min-max Planning reports specifies the destination subinventory but may not specify the source subinventory. The system uses the Rules Engine picking rules to select the source subinventory, if not already specified, and the source locator. The Rules Engine putaway rules are used to select which locator of the destination subinventory the replenishment should be directed to.
You can specify different levels of detail on the move order during creation. For instance, a subinventory transfer move order requires only the destination subinventory be specified, but you can optionally indicate the destination locator, source subinventory and locator, or lot or serial details. The Rules Engine fills in any missing details when allocating, with the details already specified acting as additional constraints on the rules.
Move order issues do not have an inventory destination. The rules engine can specify the subinventory or locator, or optionally you can specify the subinventory or locator. Move order transfers require both a source and a destination.
Manufacturing picking tasks are allocated at the same time the task is created. Unlike the other types of tasks, you cannot separate the move order creation and the allocation into two separate processes.
The move order is allocated using the Rules Engine to determine the source of the material. The destination of the material is controlled by attributes on the material requirement. If the supply type is push, (and the supply subinventory is null) then the destination of the move order is a job or schedule, and thus no destination subinventory or locator is determined by the system. If the supply type is pull, the destination of the move order is the supply subinventory / locator defined on the bill. The Rules Engine is used to validate the supply subinventory and locator.
If a supply subinventory is specified, the destination of the move order is the supply subinventory, even if the supply type is push. The supply subinventory must be non-LPN controlled and non-reservable.
Various picking methodologies are available to control the way tasks are dispatched. These methodologies are supported for sales order and manufacturing picking tasks. Two ways are available to use pick methodologies. You can set up Pick Slip Grouping Rules that preassign pick methodologies, or you can choose the pick methodologies from the mobile Task Menu.
Immediately after allocation, the system groups all lines that are released together according to a pick slip grouping rule. The system assigns the same pick slip number to all lines with the same criteria that are defined in the pick slip grouping rule, and assigns different pick slip numbers to lines that do no have the same criteria. The system dispatches all lines with the same pick slip number in a group, and assigns a single operator assigned to the group.
Some commonly used pick methodologies for sales orders are as follows:
Wave picking: The system does not group lines by any criteria. The system dispatches an operator one task at a time. The operator must complete the task before the system dispatches the next task.
Order picking: The system groups all lines for a particular sales order, job, or schedule together, so an operator receives all the tasks required to pick a single sales order, job, or schedule. An operator must complete all the tasks in the group before the system dispatches any other tasks to the operator.
Zone picking: The system groups all lines for a particular sales order, job, or schedule, and within a particular subinventory together so an operator receives all the tasks required to pick a sales order, job or schedule from a single subinventory. Because one group per source document per subinventory exists, potentially multiple groupings for the sales order, job or schedule could exist. An operator must complete all the tasks in the group before the system dispatches any other tasks.
Bulk picking: The system groups all lines that allocate the same item from the same locator into a single larger task, so an operator can pick for multiple sales order or manufacturing requirements in a single operation. Note that these items must then be de-consolidated after the picking process.
A manager can also create pick methodologies based on any number of grouping criteria. Pick slip grouping rule may include criteria that is not applicable to the task for which it is used. For instance, a grouping rule with the job, department, and operation criteria checked may be used during sales order pick release. In this case, the system ignores criteria that is not applicable.
Tasks for the same item and revision from the same subinventory and locator are merged together if the item is bulk picked. Bulk picking can be specified either by the pick slip grouping rule / pick methodology on pick release, or the Bulk Picked item attribute on the item definition. In addition there is a concurrent program that allows you to merge picking tasks after task creation. WMS Bulk Task Generation, Oracle Warehouse Management User's Guide.
The task merging process, as an extension of the pick slip grouping rules, is supported for manufacturing and sales order tasks. Items that are lot or serial controlled are not eligible to be merged.
The system suggests containers into which the items on the tasks are picked. This allows the picker to pick into the final shipping carton, and is also commonly used for conveyor-based picking where a picker picks a sales order into a tote that is scanned to trigger the next task. Cartonization is grouped by delivery, so lines that are shipped together are grouped together by the system Only sales order and manufacturing picking tasks are cartonized.
The system creates putaway tasks in the following two ways. If you turn on pregeneration of putaway the task is created after the receipt transaction is complete. If you do not turn on pregeneration of putaway the task is created after you scan the LPN. The system does not dispatch putaway tasks to you. When you scan the LPN, you receive the putaway task on the device you are signed in to. If you load multiple LPNs for putaway, you can use the Drop All option within the Directed Task Menu. If you select Drop All the system directs you in the optimal dropping order through the warehouse and enables you to putaway all the loaded LPNs.
In some scenarios paper-assisted picking, where the system produces a paper report, and the operator has the ability to decide which task to perform next, may be useful. Paper assisted picking could be helpful when the operator knows more efficient paths to go from locator to locator that cannot easily be modeled in the system, or if some pick methodology not easily mapped to the methodologies above is required.
Paper-assisted picking is available for all of the material movement tasks, which excludes only cycle counting tasks. You must enter a task number that is provided on the move order report. These reports can be automatically printed as part of the task creation process.
As soon as the tasks are created, the system assigns a task type you define to the task. This task type controls which skill sets are required to perform the task. Equipment may also be required to perform the task, which is captured by the task type. Only operators with the valid skill sets and equipment are dispatched specific tasks.
For all tasks except cycle count tasks, the task type is assigned by the Rules Engine based on any number of criteria you define. You can also define a default task type for each of the System Task Types if more specific rules-based logic is not necessary, or to serve as a fallback task type if the Rules Engine is unable to select a task type.
Cycle count tasks use the first task type you defined in the task types window. Currently, cycle count tasks do not use the Rules Engine to select the task type.
Task type assignment does not assign a task to an operator, but rather assigns a task to a skill set and optionally, equipment item, that is required to perform the task. One or more operators can be qualified to perform this type of task, and the task is not actually assigned to the operator until the operator asks the system to dispatch the next unit of work. Only at this point, or via a manual task assignment from the Warehouse Control Board, is a task associated to a particular operator.
You can also use application program interfaces (APIs) for task planning. You can use APIs to update and delete inbound, outbound, move order and cycle count tasks. You can update the task status, task type, priority, operation plan, and LPN cartonization information. You can also use APIs to split outbound tasks and cancel pending crossdocking tasks.
If you try to update a pending task to queued, you must enter the employee ID of the user to which the task should be queued as an API input parameter. You must verify that the employee ID is valid because the API does not perform any validation checks.
The task is split, if necessary, based on the capacity of the equipment required to perform the task. Tasks split in this way receive the same pick slip number, and are grouped together and dispatched to the operator. All material movement tasks are potentially split based on equipment capacity.
All tasks are dispatched when the operator logs into the system and requests a task. The operator receives the highest priority task sequenced by subinventory and locator picking order, based on where the operator is currently located. You can assign task priorities manually via the Warehouse Control Board.
All of the system task types can be interleaved. For example an operator could perform a sales order pick, followed by a move order issue task, followed by a pick for a manufacturing job, and then back to a sales order pick. Essentially, interleaving can be controlled by the task types. If qualified, the operator is dispatched the next task regardless of the task type. However, in cases where the system assigns a groups of tasks to an operator, such as via cluster picking or pick slip grouping rules, the system directs the operator to complete that group of tasks before it assigns additional tasks of potentially different system task types.
Sales orders have an additional feature to control how to interleave sales order tasks across the pick release waves. You can interleave Sales order picking tasks across pick release waves so the highest priority task in any wave is dispatched first. You can also segregate tasks by waves, so an operator is not dispatched any task from a later wave if the operator is qualified to perform any task on an earlier wave, regardless of task priority or subinventory / locator picking sequence. This behavior is controlled by a profile option WMS: Sequence Picks Across Waves.
An operator can load or drop a task. Loading a task indicates the material was loaded to equipment or a person. An operator can load additional tasks or drop the loaded tasks when ready.
Cycle count tasks are not material movements, and thus cannot be loaded. Move order issue tasks issue material directly to a destination account in a single operation, and thus loading these tasks is not supported. All other tasks can be optionally loaded.
Task drop confirms the material is moved to the final destination, which may be a staging lane, job or schedule, supply subinventory, account, or normal subinventory or locator. The material transaction is completed only after the task is dropped. All material movement tasks support task dropping.
Pick methodologies refer to the different ways that you fulfill a group of orders. For example, you might select to pick an order by itself, or to pick multiple orders at the same time. The type of picking methodology you use depends on the kinds of operations you run in the warehouse. For example if you have a high volume warehouse that is concerned with picking speed, you may not choose to use bulk picking.
Oracle Warehouse Management supports the following pick methodologies:
Order picking: The system assigns picks for one order, job, or schedule at a time to a user. When a user accepts a task for the first line of a job, schedule, or sales order, the system assigns the user all other picking tasks associated with that job, schedule, or order to the user as well, regardless of the task type or subinventory.
Wave picking: The system dispatches one task at a time to the user.
Zone picking: The system assigns picks for a given sales order, job or schedule in a given subinventory to a user. If a user accepts a task for the first line of a sales order, job, or schedule, the system assigns the user all other lines on that sales order, job, or schedule that are sourced from the same subinventory.
Bulk picking: The system groups tasks to pick the same items that are sourced from the same locator so you only see one task that might represent picks for several order lines. Deconsolidation of order lines occurs at pick drop. Oracle Warehouse Management automatically splits bulk tasks based on equipment constraints during pick release. You can choose to bulk pick items at pick release via the pick slip grouping rules, or choose to use the concurrent program to bulk pick across pick waves after pick release. You can also bulk pick within a delivery or across deliveries. The following bulk pick exceptions apply:
The system does not allow bulk picking for cartonized items
The bulk picked item must be the same revision
Note: You cannot merge tasks with allocated LPNs with any other tasks. If you want to use bulk picking, you must use an allocation mode that does not allocate specific LPNs.
Paper-based picking: Users pick according to a paper pick slip that is printed at pick release. This enables a user to dispatch tasks to themselves when working in a paper-assisted environment.
Pick and Pass/Label picking: The system generates LPNs during cartonization and prints the labels prior to picking. In order to pick, the user scans the LPN and the system dispatches the picking task associated with that LPN. The user can then pass the LPN to the next user or continue picking all material for the LPN. The system does not prompt the user to drop the LPN in the staging lane until the user picks all of the lines.
Cluster picking: The system dispatches a specified number of clusters to a single user. A cluster is all the tasks related to a sales order delivery, or a manufacturing job or schedule. Clusters are comprised of a group of tasks associated to a delivery or cartonization group for a sales order, manufacturing job, or schedule.
User-defined pick grouping: See:Defining Pick Slip Grouping Rules, Oracle Inventory User's Guide.
In Oracle Warehouse Management, you set up pick slip grouping rules to specify different ways where a warehouse might choose to fulfill a groups of orders. For example, warehouse operators might choose to pick an order across multiple subinventories, or they might decide to pick by bulk. Pick slip grouping rules enable warehouse managers to specify the type of picking methodology used to pick orders.
The entire picking and putaway processes are integrated with label printing. Several business flows are integrated into the picking and putaway processes and are triggered automatically by specific transactions. The business flows are as follows:
Pick Load: The label request is created when an operator selects Load or Drop in the Pick Load page for sales order tasks.
Pick Drop: The label request is created when an operator completes the drop transaction for sales order tasks.
WIP Pick Load: The label request is created when an operator selects Load or Drop in the Pick Load page for all manufacturing picking tasks.
WIP Pick Drop: The label request is created when an operator completes the drop transaction is for manufacturing picking tasks.
Cartonization: The label request is created during pick release for tasks that are cartonized.
Pick Release: The label request is created during pick release to support Pick UOMs per case or pallet if cartonization is not enabled.
Cycle count: The label request is created when a cycle count entry is posted.
Replenishment Load: The label request is created when an operator selects Load or Drop in the Pick Load page for all replenishment tasks.
Replenishment Drop: The label request is created when an operator completes the drop transaction for replenishment picking tasks
Putaway Drop: The label request is created after the operator completes the drop transaction for putaway.
Operation plans control the routing and behavior of individual tasks through the warehouse. Operation plans are automatically assigned to tasks when initially created, using the Rules Engine.
The system assigns one of eight predefined operation plans during pick release to sales order or internal order tasks. You can use the operation plan selection rules via the rules engine, or accept the default from the Warehouse Parameters window to assign the operation plans. The plan controls if and how to default LPNs when the operator drops sales order tasks in the destination locator thereby aiding in delivery consolidation.
You can set up inbound operation plans using the Operation Plan Setup Window. See: Advanced Task Framework Concepts.
When the system creates tasks, they can be dispatched immediately, or at a later time. You can hold back tasks to manually prioritize, assign, and group tasks as required, and then release smaller groups of tasks to be performed by certain individuals or groups of operators. In this way, and using some of the summary features of the Warehouse Control Board, you can exert tighter control over the work performed in the warehouse.
The Warehouse Control Board provides visibility to the following information to all tasks performed in the warehouse.
Task Details
Dispatch information,
Load information
Completion information
Operator who performed the task
Task exceptions
You can use the Control Board to create and save actions to perform on tasks such as manage task priorities, control task assignments, and cancel crossdocking tasks. You can also optionally override the qualifications of an operator to which you assign the task.
Finally, the Control Board also provides summary statistics that allow you to monitor labor productivity and equipment utilization within the distribution center. Additional summary statistics can be reported on groups of tasks, so the total weight or volume required for the tasks, or the total expected time required to complete those tasks can be estimated.
Task management setup includes the following tasks:
For the system to capture the skill set of each user, and then use this information to dispatch tasks to qualified users, each user defined in the system must be associated with an employee defined in Oracle Human Resources.
Note: Only one person can be logged onto the mobile user interface, with one user name at a time. Therefore, users that will be using the system concurrently cannot share a user name.
Oracle Warehouse Management enables you to define the types of employees who work in the warehouse. The BOM resources entity is used to capture the skill sets of employees required to perform a specific task. For each task that requires a unique set of skills, define a new resource. However, if the same set of skills can be used to perform a variety of tasks, you do not need to define individual resource types. In this case, a single resource type will suffice. See: Defining a Resource, Oracle Bills of Material User's Guide
Equipment, such as forklifts, pallet jacks, and so on are used to perform tasks in a warehouse. In WMS, you set up equipment as a serialized item and a BOM resource, see, Defining Items, Oracle Inventory User's Guide and Defining a Resource, Oracle Bills of Material User's Guide. Users sign on to the serial number of the equipment and are then dispatched tasks appropriate to that equipment.
To set up equipment for use with WMS, you must do the following:
Define the equipment as an item
Define the item as an equipment type
Specify the equipment as serial controlled (predefined)
Enter the equipment's capacity (optional)
Generate serial numbers for the individual pieces of equipment
After you set up equipment items, you must set up the equipment types as resources. You use the BOM resources window to setup equipment resources see: Defining a Resource, Oracle Bills of Material User's Guide. Equipment resources represent types of equipment. For example, you might have several items that all perform the same function and can be used interchangeably. In this case, you could create one resource and then associate each similar piece of equipment under that resource.
Each task generated by the system for dispatch to a user must have a task type. Task types are user-definable through the BOM Standard Operations window see: Creating a Standard Operation, Oracle Bills of Material User's Guide. For each task that requires a unique combination of human and equipment type resources, a new task type should be created. You must enter a task type in the task type field.
Note: Available system task types are Pick, Putaway, Cycle Count, Replenish, MOXfer (Move Order Transfer), MOIssue (Move Order Issue), Inspection, and Staging Move.
Note: WMS requires that, at a minimum, you set up at least one pick and one replenishment task type. In addition, one cycle count task type can be defined if cycle counts should be dispatched as tasks. Do not define more than one cycle count task type for the organization.
You must also assign operation resources to the task type, enter one human resource per task type and at most, one equipment resource. Every task requires exactly on human resource, but the equipment resource is optional. See: Defining a Resource, Oracle Bills of Material User's Guide
A department represents a grouping of similar resources within a warehouse. For example, all of the employees and equipment that perform picking tasks might be grouped together in the Picking department.
To use the task management system, you must set up at least one department. To use a human and equipment resource to perform the same task, each must be defined to the same department. Therefore, you should not implement separate departments for equipment and human resources. For information on defining departments See: Defining a Department, Oracle Bills of Material User's Guide
The User Task Type Attributes window enables you to specify a task type, pick load page type, and if you should honor the pick UOM you specified on the Subinventory window. If you choose to honor the pick UOM, then you can print shipping contents labels by case or pallet for the pick release business flow if you do not enable cartonization. To set up task type attributes see Setting Up User Task Type Attributes, Oracle Warehouse Management User's Guide.
Related Topics
Overview of Task Planning, Oracle Warehouse Management User's Guide
Defining Resources, Oracle Bills of Material User's Guide
Physical Attribute Group, Oracle Inventory User's Guide
Defining Resources, Oracle Bills of Material User's Guide
Creating a Standard Operation, Oracle Bills of Material User's Guide
In order to use the task management features, you must define several different entities. Some of these steps are optional, while others are required for some of the system task types. However, you must define at least one task type must for each of the system task types (Pick, Replenishment, MO Issue, MO Transfer, Cycle Count) in order to automatically have those tasks dispatched. Some of these steps, such as defining employees and defining users, are performed as part of the common installation steps.
The following table lists the steps for setting up task types:
| Step | Required |
|---|---|
| Define Employees | Yes |
| Associate Employees to Users | Yes |
| Define Equipment Items | No |
| Define Equipment Instances | No |
| Define Resources | Yes |
| Define Department | Yes |
| Define Task Type | Yes |
| Define Task Type Rules | No |
| Define Default Task Types | No |
Though defining task type rules and defining default task types are optional, you must perform at least one of the steps.
Prior to defining entities, you must identify the task types to be used in the warehouse. Use the following questions to help define task types:
Beyond the five system-defined task types that differentiate the tasks by the type of document that originated the task, what criteria are used to differentiate who is qualified or what equipment is required to perform a task? This helps determine what task types should be defined.
Do operators typically work with one or two pieces of material handling equipment all day, such as a dedicated fork truck driver? If so, then equipment resources should be defined. Or do they typically switch equipment frequently, grabbing whatever equipment they need to do the task? If so, then it may not even be necessary to define equipment resources because operators are already deciding which equipment to get based on the task attributes.
Are there different classes of material handling equipment in the warehouse, such as a pallet jack, fork truck, or cart? Are these classes broken down even further, perhaps by weight capacity, or by material handling properties? Can only some equipment be used for refrigerated or hazardous items? Is some equipment required to reach certain areas, such as high racks, in the warehouse? This helps determine what equipment items should be defined and how they should be associated to task types.
Are different operators trained to operate different pieces of equipment, or move different classes of items, or are all operators qualified to move all material? This helps determine what manual resources should be defined and how they should be associated to task types.
Though task types are set up to model skill sets and equipment required to perform tasks, they can also be used to selectively restrict tasks to operators. Operators can elect to perform tasks in the refrigerated cooler in the morning, and tasks in the freezer in the afternoon, as directed by you the manager, and controlled by the equipment the operator signs on to.
In addition to defining task types, you must define Transaction Reasons if exceptions to tasks, such as picking less than the allocated quantity or picking from a different locator than suggested, are allowed. See: Overview of Transaction Reasons for implementation details on defining Transaction Reasons and the associated workflows.
In setting up skill sets, you assign a particular employee to resources, which effectively means the employee has the skill sets to perform specific tasks. You must define this employee to set up resources.
Employee information is maintained by Oracle Human Resources. If Oracle Human Resources is installed, an employee can be defined and maintained from the Enter and Maintain People window in HRMS Manager responsibility. If Oracle Human Resources is not installed, you can access the same window via the Warehouse Manager responsibility. See Entering a New Person, Managing Your Workforce Using Oracle HRMS (US).
When signing on to the mobile devices, an operator indicates a user name and password. The user name is associated to a specific employee, and in turn, to the skill sets the operator has, by means of this step.
After creating a mobile user and providing it with the appropriate responsibilities, associate the employee defined in the previous step to this user.
There can be more than one employee with the same employee name and number, but belong to different Operating Units. Verify the employee selected belongs to the correct Operating Unit for the responsibilities.
Equipment items are a specific type of equipment required to perform a task type. They are used to restrict the tasks dispatched to a particular operator based on the equipment with which the operator has logged on. Equipment capacity is also used to split tasks, if the weight or volume of the task exceeds the weight capacity or volume capacity of the equipment that is required to perform it. Typically, equipment items are the model numbers of the equipment used in the warehouse. Examples of equipment items include Komatsu K4300 forklift 2-ton fork, Yale Y4000 2-ton lift, or Caterpillar C3600 high-reach fork truck.
Equipment items are optional resources on a task type. This step is only required if the operator should be required to sign on to particular equipment to get specific tasks.
Equipment items are defined from the Master Items window, as equipment items are simply serialized inventory items with several additional attributes. Ensure the Vehicle check box is enabled, and that the item is defined as serial at receipt, or serial predefined. You must assign the item to the organization in which it is used. Additional optional attributes include the equipment capacity, specified by entering a maximum load weight and internal volume. Ensure the units-of-measure that are specified for these two attributes are in the same unit-of-measure class that is used to specify the weight and volume of the items.
The specific pieces of equipment in each warehouse are modeled as serialized instances of equipment items. For instance, there may be 15 2-ton forklifts in a particular warehouse. Because these forklifts have the same make and model and are therefore interchangeable on the warehouse floor, they have been defined using just one equipment item. Serial numbers must then be generated for the 15 different instances. It is these serial numbers, associated with a particular equipment item, which the operator is logging on to. This step is only required if equipment items have been defined.
Serial numbers can be generated either via the desktop concurrent request to generate serial numbers, or via miscellaneous receipts of the equipment items. Equipment items can be on-hand, but that the task management processes do not require that it be on-hand, nor do they perform or require any material movements of the equipment item.
Resources are used to model the equipment and employee skill sets. Two different types of resources are used to model task types: manual and machine, or rather, operator and equipment. Resources group the employees or equipment items into sets where every instance on that set is considered equivalent.
To define manual resources create a resource name and indicate the type as Manual. You can assign the employees defined earlier to that resource. All the employees assigned to a resource are considered interchangeable, so any one of the employees on a resource can perform a particular task. Different manual resources might be a 2-ton forklift operator, forward picker, hazmat handler, or cycle counter.
To define equipment resources create a resource name and indicate the type as Machine. You can assign the equipment items defined earlier to that resource. Equipment items assigned to a resource are considered interchangeable, so any serial instance tied to an equipment item on a resource can perform a particular task. Different machine resources might be a 2-ton forklift, small cart, or hazmat forklift.
Departments break resources into logical groups. One department may be defined for hazardous material handling, while a second department may be defined for miscellaneous material. Or one department may be defined for picking, and another for replenishment. You can assign resources to one or many departments, and departments include both manual and machine resources.
User-defined tasks types set the skill sets and optionally, equipment, required to perform a task. Each task type you define is associated with exactly one manual resource and either one or zero machine resources. The task dispatching engine dispatches tasks to operators qualified to perform that particular task. You must associate the task type with a department and with a system-defined task type. You must define at least one user task type for each system task type in order to use task dispatching for that system task type.
Task type assignment rules determine the user-defined task types to assign to each task. You use the Rules Definition window to create Task type assignment rules. However, unlike picking and put away rules, task type assignment rules do not have strategies, or strategy assignments.
Each task type assignment rule has both restrictions and a return value. The return value is the user-defined task type that should be returned when the restrictions are met. The restrictions indicate the requirements that must be met, such as the quantity of the task or the source location of the task The rules also are given a weight, which determine the sequence in which the rules are evaluated; higher weighted rules are evaluated first. The task type on the rule with the highest weight for which all the restrictions are met is stamped on the task.
You do not have to define Task Type Assignment Rules if default task types are defined at the organization level. You can use rules and organization defaults to ensure a task type is always assigned.
If no task type is assigned after evaluating all the task type assignment rules, or if no task type rules exist, the system checks for the default task types assigned to each system task type on the Organization Parameters window. You do not have to define default task types if task type rules exist. Both rules and organization defaults can be used to ensure that a task type is always assigned.
Transaction Reason Actions provide you with an alternate customizable flow to handle exceptions. For example, you may try to pick from a location that differs from the system suggested locations because you are unable to reach the suggested locator. The system prompts you for a reason. You can associate this reason with a workflow process, which automatically executes.
Transaction Reasons enable you to record and monitor exceptions to tasks. You must enter exceptions when you perform something unexpected during a task. You can optionally associate a Transaction Reason with a workflow process or Transaction Reason Action, which supports customized alternative process flows to automatically handle these exceptions.
The following is an example of a Transaction Reason Action:
Transaction Scenario: You are asked to pick a quantity of three of a particular item from a locator, but when you go to the locator, there is only one item in the locator.
Reason for the Exception: Inadequate quantity in suggested locator.
Action: Execute a Workflow to request a cycle count on the locator.
You setup transaction reasons in the Oracle Inventory Transaction Reasons window. See Defining Transaction Reasons, Oracle Inventory User's Guide. You can view reasons with an attached corrective action workflow. The workflow initiates upon completion of the task or transaction.
The Cycle Count workflow process is seeded with the application. The workflow performs the following steps:
Cycle Count Reservations: The cycle count workflow creates a cycle count reservation for the discrepant quantity when you initiate the workflow from the pick load page. The discrepant quantity is the difference between suggested task quantity and the actual quantity picked from the location. The reservation prevents the discrepant quantity to be re-allocated to other tasks until you perform a cycle count, and the inventory on-hand balance is correct. The reservation includes the item, subinventory, locator, and as applicable, revision and lot number.
Generate Cycle Count Entries and Cycle Count Tasks: The workflow schedules a cycle count for the discrepant item and locator, and a concurrent request for generating cycle count entries and cycle count tasks is submitted.
Alternate Task Generation: The workflow generates an alternate task for the remaining quantity you can not pick due to a pick exception. The system creates an alternate task provided sufficient on-hand quantity exists and can be allocated elsewhere. If sufficient quantity does not exist at an alternate location, the system backorders the remaining quantity.
The application also comes with a second seeded workflow to enable n-Step Putaway. Suppose you have a task to put away or replenish material from location A to location D. You are responsible for picking material from location A, but location D is at the other end of the warehouse and rather than travel the distance, you can drop the material destined for D at an intermediate staging location, called B, and another operator completes the movement from B to D.
In this case, you override the suggested drop location of D by indicating a drop location of B instead. When the system requests an exception reason, you indicate a reason associated with the workflow process of n-Step Putaway. The system automatically generates a task (of type replenishment) to move the material from B to D and automatically dispatches the task to a qualified operator. However, that operator may be able to move the material to location D, or may only be able to transfer the material from location B to location C, which generates another movement task.
In addition to the two seeded workflows, you can build your own custom workflows to automatically process any notifications or other exception handling you deem necessary.
Oracle Warehouse Management contains the workflow: MTL Transaction Reasons Workflow. This workflow contains over sixty input and output parameters you can use to create a custom workflow process using the Oracle Workflow Builder. Alternatively, you can select either of the two seeded workflow processes attached to this workflow name, Cycle Count, or WMS N Step Putaway.
To create a reason that automatically triggers a cycle count process when an operator selects the reason from a picking task, create a new record in the Transaction Reasons window. Enter a name such as “Missing Quantity”, keep in mind that the display is a mobile handheld device and so the name should be as succinct as possible. The system also displays the description field. This is an optional field during setup.
The workflow type must be set to MTL Transaction Reasons Workflow, and the workflow process to Cycle Count. Other processes you associate with this workflow name are also be available here. Be sure to indicate a Reason Type of Picking. Only picking, putaway, and replenishment tasks support automatically initiating workflows on exceptions. The Reason Type is used to restrict which reasons you see in each type of transaction or task. Other transactions, such as a material status update, can use and record transaction reasons, but do not initiate any associated workflow.
Use the following procedure to test the Transaction Reasons workflow:
Create and release a sales order for a quantity of three of an item.
Use the mobile device to sign on and navigate to the Pick Load Page.
In the pick load page there is a task to pick three items. When you reach the field confirm quantity, enter the quantity as one.
Select the Drop button instead of the Pick More button, to indicate that you wish to pick only one instead of the original requested quantity of three.
The audit page opens. Select the reason associated with the workflow process Cycle Count and select Done to continue.
Complete the task, including confirming the suggested drop location and select Done. Verify that the task is completed for the reduced quantity via the Warehouse Control board or the View Material Transactions window.
Verify the cycle count for the requested location. Navigate to the cycle manual requests window and enter the default cycle count header name associated with the organization where the quantity discrepancy exists. You should see a request for a cycle count in the Schedule Requests field.
Verify the workflow notification was sent.
Navigate to the Warehouse Control Board window and verify the creation of the cycle count task and alternate picking task if additional quantity was on-hand and available.
The following section provides details about how the system dispatches tasks operators and the different processes available to manage the tasks in the warehouse.
In order to receive tasks, an operator must sign on to the mobile device, select the Whse Mgmt responsibility, and navigate to the Tasks menu. After entering the current organization, an operator can optionally enter the equipment serial currently in use, or the subinventory from which tasks should be restricted.
If the operator does not enter any value for the equipment, the system assumes the operator has the necessary equipment to perform the next task. The operator can also enter a value of NONE, which restricts the system to dispatch only tasks that do not require any equipment. For any other value entered, the system dispatches tasks that require a resource equipment type the operator indicates. Although the operator scans or enters the specific equipment item serial number, the serial number is tied to an equipment item, which is in turn linked to a resource, and a task type.
If the operator enters a subinventory, only tasks originating in that subinventory are dispatched to the operator.
There are several ways you can perform tasks in the warehouse. Tasks are divided into two categories, directed tasks and manual tasks. The following section describes all the options available in the tasks menu.
The directed tasks option enables you to perform system directed tasks. You can use the warehouse control board to assign a task priority, or optionally set a default task priority at pick release, see Navigating the Warehouse Control Board, Oracle Warehouse Management User's Guide and Releasing Sales Orders for Picking, Oracle Shipping Execution User's Guide. Directed tasks are grouped under the following categories.
Interleaved Tasks: Enables you to perform any kind of task.
Outbound: Enables you to perform sales order and internal order tasks.
Manufacturing: Enables you to perform work order tasks.
Warehousing: Enables you to perform replenishment, cycle counting, slotting (move order transfer), and move order issues.
Directed Move: Allows you to move LPNs.
You can reconfigure the menu structure to group directed tasks to suit your needs.
The Accept Any Task option calls the task dispatching engine to retrieve the next optimal task among all the pending tasks that the operator is qualified for. If any tasks are already dispatched or queued to the operator, the next task based on subinventory / locator picking order is then presented to the operator.
If no tasks are currently dispatched or queued to the operator, the following process gets the next task or group of tasks. Tasks are first filtered out based on the manual resources required for the task, the equipment the operator has signed on to, and the subinventory the operator signed in to. The tasks that pass these restrictions are then sequenced based first on the task priority, where higher priority numbers take precedence. The tasks of the highest priority are then sequenced based on subinventory and locator picking order, and the task closest to the operator's last known position based on ascending subinventory / locator picking sequence is dispatched to the operator and presented on the mobile device. Sales order tasks can also be optionally interleaved across pick release batches, or dispatched batch by batch, depending on the setting of the profile option WMS: Sequence Picks Across Waves.
All tasks with the same pick slip number are also assigned to the same operator at this time. When performing tasks with the same pick slip number, the operator is automatically brought to the next task in that group as soon as the previous task is dropped. When the operator completes the tasks in the group, the mobile device displays a message, and returns the operator to the task menu.
From the Accept Any Task option, the operator can completely perform the task, and elect to drop the material directly to the destination for material movement tasks, or if applicable, load the task.
Express Pick is similar to Express Load, except both the pick load and the pick drop are performed in a single operation. The complete task is transacted in a single operation.
Tasks dispatched via Accept Any Task require the operator to confirm several details about the task, including the revision, item, source subinventory and locator, and quantity, as well as the lot and / or serial details, as applicable. If the material is packed and comes from an LPN that can be entirely consumed by the task, the confirmation process is simplified. The operator only has to scan the LPN.
The Express Load page is a configuration which requires minimum confirmation of fields. It bypasses all of the confirmation fields, allowing a task load to be confirmed with a single keystroke after confirming the pick to LPN..
Express Load uses the same task dispatching algorithm as Accept Any Task to select the next task to load for an operator.
Cluster picking allows a pre-specified number of “clusters” to be dispatched to an operator, to handle scenarios where the operator may be traveling through the picking area with a cart and be able to pick for several sales orders or jobs at once by consolidating the material into a tote specific to the source document.
Clusters are defined by the tasks within a single delivery for sales order picking, or all the tasks related to a single job or schedule for manufacturing. As soon as the operator accepts a task via the cluster picking option, all other tasks for that cluster as well as the tasks from a pre-specified number of additional clusters are assigned to the operator immediately. The system directs the operator to use new LPNs / totes when picking the first task for a new cluster, but to reuse the already existing / loaded totes when picking additional tasks for that cluster. Clusters for manufacturing and sales orders can be interleaved, based on operator qualifications and task type setup.
The Pick by Label option is applicable to cartonized tasks only. It is primarily used in conveyor-based picking, where a tote passes down a conveyor belt and different operators load material to the tote. Rather than dispatching tasks based on priority, or by a Pick ID, tasks are dispatched by scanning the license plate. By way of cartonization, the tasks have already been associated to that particular LPN. The LPNs are initially placed on the conveyor based on the labels printed during cartonization at pick release.
When the operator scans an LPN, all eligible tasks that should be picked into the LPN are dispatched one after the other based on the picking sequence. The operator performs these picks one after the other into that LPN. Once all picks are complete the operator has the choice of dropping the LPN, or passing it on to the next operator in the queue.
The discrete picking option uses the preassigned pick methodology defined by the pick slip grouping rules. All eligible tasks with the same pick slip ID are dispatched the same operator one after the other.
The order picking option dispatches all eligible tasks from the same sales order or internal order to the same operator.
The wave picking option does not group tasks prior to dispatch to the operator. The system dispatches to the operator the most optimal eligible task one after the other based on subinventory / locator picking sequence and task priority.
The bulk picking option does not group tasks prior to dispatch to the operator. The system dispatches individual bulk picking tasks one after the other based on subinventory / locator picking sequence and task priority
The replenishment picking option does not group tasks prior to dispatch to the operator. The system dispatches individual replenishment tasks one after the other based on subinventory / locator picking sequence and task priority
The counting option does not group tasks prior to dispatch to the operator. The system dispatches individual cycle counting tasks one after the other based on subinventory / locator picking sequence and task priority
The slotting option does not group tasks prior to dispatch to the operator. The system dispatches individual move order transfer tasks one after the other based on subinventory / locator picking sequence and task priority
The move order issue option does not group tasks prior to dispatch to the operator. The system dispatches individual move order issue tasks one after the other based on subinventory / locator picking sequence and task priority
The move any LPN option is applicable to inbound tasks only. It allows putaway of both loaded LPNs and LPNs that are not currently loaded for putaway. It also allows you to transfer contents from the loaded LPN into another LPN, nest the loaded LPN into another LPN, or drop the loaded LPN as is.
This option allows the operator to drop any loaded LPN. The loaded LPN could be either a pick or putaway transaction. If the operator invokes the list of values the system displays only those LPNs the operator loaded. However, the operator can scan LPNs that were loaded by a different operator, and perform drops.
The Drop All LPNs option is applicable to inbound tasks only. It allows putaway of all loaded LPNs that are currently loaded for putaway. It also allows you to transfer contents from the loaded LPN into another LPN, nest the loaded LPN into another LPN, or drop the loaded LPN as is. The system allows the operator to putaway only those LPNs they loaded. One operator cannot drop LPNs loaded by another operator. The system routes the operator through the warehouse in the most optimal dropping sequence.
The staging move is applicable to outbound tasks only. When a task is picked and dropped into a consolidation locator or packing station, an operator can scan these LPNs and the system directs the operator to the appropriate staging lane.
The Manual Pick option is primarily used in paper-assisted picking environments where the operator dispatches tasks manually, rather than relying on the task dispatching engine to select the next task to dispatch. The Pick ID triggers the Manual Pick option, available from the Pick List printed by sales order pick release, and also available on the Move Order Pick List report for other move orders.
Once a task has been dispatched to an operator manually via Manual Pick, the other task features behave exactly as if the task were dispatched via Acc Next Task, with the exception of pick slip grouping rules. Specifically, the Manual Pick option does not honor the pick slip grouping rules, so that an operator can perform tasks from multiple different groups if desired. However, because the pick slip report breaks pages with each new pick slip number, this can be avoided by process controls, if desired.
The Pick ID is simply the TRANSACTION_TEMP_ID, from MTL_MATERIAL_TRANSACTIONS_TEMP, and so in the absence of these reports during testing or demo situations, can be accessed either directly from the tables, or from the Transaction Number column on the Warehouse Control Board. in the case of bulk picked tasks, the individual child tasks that are merged to window the parent task are not eligible to be picked via Manual Pick.
The manual tasks option allows you to perform manual tasks. The following is a list of manually performed tasks
Manual Load
Manual Drop
Manual Unload
Inspect
Paper Based Pick
LPN Mass Move
LPN Mass Consolidate
The manual load option is used to load LPNs for putaway. It allows putaway load of LPNs that are not currently loaded for putaway. It also allows you to transfer contents from the LPN into another LPN, nest the LPN into another LPN, or load the LPN as is.
The manual drop option is used to drop loaded LPNs. This option is not available for outbound tasks. It allows the operator to drop LPNs into any locator of their choice. The system does not direct the operator to any specific locator. It also allows the operator to transfer contents from the LPN into another LPN, nest the LPN into another LPN, or load the LPN as is.
The manual unload option can only be used on tasks that were picked for outbound transactions. The operator can scan a loaded LPN and perform an unload transaction, reversing the task load and placing the task back in the queue of pending tasks available for operators. Unload returns the material to the source locator in the same state (packed or loose) in which it was loaded. Finally, information about the task can be viewed. Although the Manual Unload page displays only those LPNs the operator loaded, the operator can access other LPNs via this page if the LPN is scanned directly.
The inspect option can be used to inspect LPNs received via inbound, and are not currently putaway.
The LPN mass move option is only applicable to outbound transactions. When LPNs are picked and dropped into a consolidation locator, the operator can perform a mass move of these LPNs to a packing locator or a staging lane. The operator scans the source locator and the destination locator to perform the move.
LPN Mass Consolidate enables you to consolidate all staged LPNs for the same delivery residing in the same locator. You can specify the destination LPN and if the destination LPN is new, you must specify the sub and locator also. This locator can be of any one of the three types: staging, consolidation, or packing. For consolidated LPNs that have LPNs across deliveries, the destination locator must be a staging locator.
In some scenarios paper based picking, where the system produces a paper report, and the operator has the ability to decide which task to perform next, may be useful. Paper based picking could be helpful when the operator knows more efficient paths to go from locator to locator that cannot easily be modeled in the system, or if some pick methodology not easily mapped to the methodologies above is required.
Paper based picking is available for all of the material movement tasks, which excludes only cycle counting tasks. You must enter a task number that is provided on the move order report. These reports can be automatically printed as part of the task creation process.
Oftentimes, a locator may be unavailable or specific material may not be found as expected. Different types of task exceptions are supported, each of which can trigger a corrective workflow.
You define transaction reasons during the setup process. Transaction reasons link an exception type, such as a Picking exception or a Putaway exception, with a text description and an optional user-defined workflow that can perform a corrective action. For pick load transactions reasons, you can enter a reason context and attach an associated workflow. Defining Transaction Reasons, Oracle Inventory User's Guide.
Common types of corrective actions may be placing locators or subinventories on hold if they are damaged, cycle counting an item in a locator if it is short picked, or reallocating an order line if insufficient material was found.
In the Pick Load page, an operator can pick packed material, as well as loose material. Packed material is picked by entering an LPN in the LPN / Loc field; to pick loose material, the LPN field is left blank.
When the operator scans the from LPN, the system calls a LPN matching routine. This compares the selected LPN against the requirements of the task in question. The system calls the routine even if a particular LPN has been allocated, in case additional material was packed into the LPN after the allocation occurred.
The matching routine verifies the selected LPN has the allocated item. If the item is revision controlled, the LPN must include the specific revision on the task. If the item is lot controlled, the LPN must include at least one of the allocated lots. If the item is serial controlled and serial allocation is enabled, the LPN must include at least one of the allocated serials. The material that matches the allocation must also be available. Note that this matching routine allows LPNs from different locators to be entered, even though they are not in the list of values for the LPN. But it performs the additional availability check, for which LPNs displayed in the LPN list may then be invalidated.
The matching routine then checks to see if the LPN can be completely consumed by the task:
If item lot controlled, all lots in the LPN have been completely allocated
If item serial controlled, all serials have either been completely allocated, or specific serials have not been allocated
No other items or revisions in the selected LPN
If the LPN can be entirely consumed by the task, the operator does not need to confirm any of the other task details such as subinventory, locator, item, revision, lot, or serial. However, if the LPN can be only partially consumed, then the operator must confirm all the additional details based on pickload page configuration.
If, after selecting the LPN, regardless of whether it was entirely consumed, the task still has remaining quantity to pick, the operator can either continue to pick more loose or packed material from the same or different locator, or can indicate that there is no more material to pick that thus the task is short picked.
The LPN Fields properties can be configured to behave independently for fully consumable LPNs versus partially consumable LPNs and/or loose material. Three scenarios are supported for fully consumable LPNs and one scenario is supported for partially consumable LPNs and/or loose material. These configurations pertain to behavior at the time of retrieving material from a locator and loading it into an LPN. The tables below depict these scenarios and provides allied setup information.
| Details | Setup |
|---|---|
| Background: Locator E1.1.1 contains LPN10. LPN10 is fully consumable. Requirement: Get LPN10 As-Is. |
All valid setups for Transfer LPN or Into LPN can achieve this. Basically either Transfer LPN or Into LPN is set up as one of these three properties:
|
| Background: Locator E1.1.1 contains LPN10 .LPN10 is fully consumable .Requirement: Transfer All contents of LPN10 to LPN20. |
Transfer LPN:
OR
Into LPN: hide fields |
| Background: Locator E1.1.1 contains LPN10.LPN10 is fully consumable. Requirement:Get LPN10 As-Is and Nest into LPN777. |
Transfer LPN: Hide fields Into LPN:·
OR
|
| Details | Setup |
|---|---|
| Background: Locator E1.1.1 contains LPN10 and/or Loose material. LPN10 is partially consumable. Requirement: Move partial contents of LPN10 to LPN20 and/or move Loose material to LPN20. |
Either Transfer LPN or Into LPN is set up as one of these two properties:
|
All material movement tasks must be picked to an LPN. This LPN could be the final LPN that is shipped to the customer, an intermediate LPN that is consolidated into a larger shipping container or pallet, or an intermediate tote that is only used to identify the material while the operator is moving it.
If cartonization, is enabled, the system automatically generates the Pick To LPN, as well as the container item that the task should be picked to. This suggestion is displayed in the Pick Load page. If the operator is picking an entire LPN, then the Pick To LPN defaults as the From LPN, meaning that the entire LPN is loaded as is. However, if the task is not cartonized and the operator picks a partial LPN or loose material, the operator enters or generates the Pick To LPN.
For sales order picking tasks, the only restrictions the system enforces are that different deliveries are not commingled in the same Pick To LPN, and that the Pick To LPN is in the correct context when it is used. The valid contexts are Packing Context, and Defined but not Used. This means the following can be used for the Pick To LPN:
LPN which is currently loaded to the operators equipment for the same delivery
LPN which has been pre-generated and not yet used
LPN generated inline using the hot-key
The LPN Fields properties in the pick load page setup can be configured to behave independently for fully consumable LPNs versus partially consumable LPNs and/or loose material. Three scenarios are supported for fully consumable LPNs and one scenario is supported for partially consumable LPNs and/or loose material. These configurations pertain to behavior at the time of retrieving material from a locator and loading it into an LPN. The table below diagrammatically depicts these scenarios and provides allied setup information.
Sales order picking tasks allow the operator to consolidate individual picking tasks for larger deliveries as part of the Pick Drop process. If deliveries were automatically created as part of the pick release process, or if they were created manually prior to pick release, the Pick Drop page uses the deliveries to group LPNs that should be dropped together. If any operator has already dropped an LPN for the delivery, that LPN will be defaulted as the Drop LPN.
By leaving the Drop LPN as suggested, the Pick To LPN is automatically nested inside the Drop LPN. The operator can also clear the Drop LPN, so that the Pick To LPN is dropped as is, or a new Drop LPN can be generated. Like the restriction on the Pick To LPN, the only restrictions on the Drop LPN are that it does not result in delivery commingling, and that it is in a valid context of Picked or Defined but not Used.
If the LPNs are not consolidated into larger shipping containers, the Drop To LPN can be used to help identify other LPNs in the staging lane near which the current LPN should be dropped, thereby keeping deliveries near each other. This helps streamline the outbound shipping process because a shipper need not search the entire staging lane for missing LPNs.
LPN contexts indicate the current LPN state. For instance, an LPN may be in inventory, or it may be in-transit between two organizations. Other contexts include Resides in WIP and Resides in Receiving. Resides in receiving is used for LPNs that have been created and packed, but not yet put away to inventory. Several contexts are used for LPNs as they proceed through the picking process. Specifically, the contexts Packing Context and Picked come up only in reference to tasks.
The Picked context is used to identify LPNs that have been staged for sales orders. These LPNs can only be issued as part of a shipping transaction. They can also be split into smaller LPNs, or merged so long as only LPNs on the same delivery are combined.
The material movement is not processed until the task is dropped; no transaction is recorded for tasks which have only been loaded, though details about the task such as the time at which it was loaded and the operator who loaded the task are recorded.
When a new LPN is generated for a task that is subsequently loaded, the LPN is not packed and does not yet reside in a particular subinventory and locator. These LPNs are given the context Packing Context. This also applies to Pick To LPNs that previously had the context Defined but not Used. When a task is dropped, the LPN is given one of several contexts as follows:
If the task is dropped for a sales order staging transfer, the LPN is given the Picked context.
If the task is dropped for any other task to an LPN controlled subinventory, the LPN is given the context Resides in Inventory.
If the task is dropped to a non-LPN controlled subinventory, or the task drop issues the material to WIP, the LPN is given the context Defined but not Used so that it can be reused as a tote.
If the task is issued on a Move Order Issue, the LPN is given the context of Issued Out of Stores.
The Warehouse Control Board is a desktop-based management tool that enables you to view the tasks pending progress, currently in progress, or already completed, for a particular operator, task type, job, sales order, date, task status, or any number of additional criteria. Task exceptions are recorded and displayed in the Control Board.
You receive a message that indicates no tasks are available.
This could happen for one of many reasons. There could be no tasks pending, or the task could be pending but no task type assigned, or the task type could be assigned, but the operator is ineligible to perform the task. The following helps determine which those three scenarios is the root cause of the problem, and how to resolve the problem.
First, query the Warehouse Control Board for tasks created by the particular document (job, sales order, move order, etc.) for which tasks were expected. Clear the date fields, and select all statuses. If no tasks are found for that particular document, then the task creation process failed. For material transfer tasks, the most common cause is that the Rules Engine was unable to allocate any material. Please refer to the Rules Engine chapter of this guide for steps on how to debug this problem. Other possibilities are that no replenishments were required, the Restock option on the Min-max Planning Report was set to No, Cycle Counts have already been scheduled for the period, or the release criteria set during pick release were too restrictive and did not pick up the desired lines.
If tasks have been created, check the task status. The task status should be Unreleased or Pending for any task that has not yet been begun or assigned to a particular operator. If the task status is Unreleased, either task planning was enabled when the tasks were initially created, or a user manually changed the task status to Unreleased. Unreleased tasks are not eligible to be dispatched.
If the task status is Completed, check the name of the employee that the system believes completed the task; perhaps someone else is also testing concurrently. If the task status is Completed for a sales order task, verify that Auto Pick Confirm was disabled during the pick release batch. Verify that the item is reservable, as non-reservable items are automatically pick confirmed during sales order pick release regardless of the setting of the Auto Pick Confirm flag.
If the task status is Queued, that means the task has been manually assigned to a particular operator via the Control Board. Either log on as that operator to complete the task, change the assignment to another operator via the Control Board, or set the task status back to Pending, which automatically clears out the operator assignment and make the task available for any operator. However, tasks in status of Queued should still be available via Acc Next Task to the correct operator.
If the task status is Dispatched, that means the task has been assigned to a particular operator by the system based on either pick slip grouping rules or cluster picking. Tasks in status of Dispatched should still be available via Acc Next Task to the correct operator.
If the task is in status Loaded, an operator has loaded the task to his equipment, but has not yet completed the task. The task should be available to be completed from the Current Tasks option of the user who loaded the task. Or any other operator can complete the task by manually entering or scanning the LPN in their Current Tasks page.
If the task is in status Pending, the task should be available to any qualified operator based on the task type that is assigned to the task. Verify the Task Type for the task; if the task type is null, then the Rules Engine was unable to assign a task type and there were no default task types defined in the Organization Parameters window. Verify that the task type assignment rules are enabled. Also, if patches have been recently applied to the instance and task type rules worked prior to the patches, run the concurrent request Generate All Rules. Define default task types ensure that a task type is always assigned to tasks. To continue with this task, manually assign the task to a particular operator in the Warehouse Control board.
If the task is in status Pending and has a task type, but is still unavailable via Acc Next Task, then likely the employee associated with the mobile user is not qualified to perform the task. Check the Resources required for the Task Type; there should be exactly one manual resource, and either zero or one machine resources assigned. Verify the employee name that is associated to the user, and then verify that employee is on the list of valid employees to perform the manual resource. Also, when signing on to the mobile device, leave the Equipment and From Sub fields blank, so that these do not act to further restrict the tasks available to the operator.
If the task status is Active, the task page is currently open in an operators session and thus the system things an operator is currently working on that task. The operator that has that task open will also be displayed in the Warehouse Control board.
Some sales order picking tasks are never dispatched
So long as some operator is qualified to perform the task, the qualified operator should always be dispatched tasks before being given the “No Tasks Available” message, as long as that operator did not sign on to a specific subinventory or sign on with specific equipment. However, in an active warehouse, there may always be pending picking tasks as pick release is performed daily for new batches and yet it may seem that some of the picking tasks for waves released in previous days do not get dispatched.
Tasks are dispatched in sequence of priority and subinventory / locator picking sequence, and restricted by the operators skill set. Assuming that an operator is qualified to perform all tasks, priorities are never manually assigned, and the operator does not sign on to a particular piece of equipment or a particular subinventory, tasks are sequenced solely on subinventory / locator picking sequence.
If an operator is in one end of the warehouse, based on that picking sequence, additional picking waves are released before the operator completes the previous wave. It is possible the operator may never get to the opposite end of the warehouse because additional were created for locations within the operator's current area. While this ensures an efficient picking path, this also means tasks may be left pending indefinitely as new batches are released. Instead, you may wish that an operator cannot work on any tasks released in a later pick release wave as long as there are tasks still pending in a previous wave for which the operator is qualified.
This is controlled by a profile option, WMS: Sequence Picks Across Waves. This profile option determines whether sales order picking tasks should be sequenced only on priority and subinventory / locator picking order regardless of pick wave, or whether they should be sequenced by wave number, priority, and then subinventory / locator picking order.
So long as some operator is qualified to perform the task, the qualified operator should always be dispatched tasks before being given the “No Tasks Available” message, as long as that operator did not sign on to a specific subinventory or sign on with specific equipment. However, in an active warehouse, there may always be pending picking tasks as pick release is performed daily for new batches and yet it may seem that some of the picking tasks for waves released in previous days do not get dispatched.
Tasks are dispatched in sequence of priority and subinventory / locator picking sequence, and restricted by the operators skill set. Assuming that an operator is qualified to perform all tasks, priorities are never manually assigned, and the operator does not sign on to a particular piece of equipment or a particular subinventory, tasks are sequenced solely on subinventory / locator picking sequence.
If an operator is in one end of the warehouse, based on that picking sequence, additional picking waves are released before the operator completes the previous wave. It is possible the operator may never get to the opposite end of the warehouse because additional were created for locations within the operator's current area. While this ensures an efficient picking path, this also means tasks may be left pending indefinitely as new batches are released. Instead, you may wish that an operator cannot work on any tasks released in a later pick release wave as long as there are tasks still pending in a previous wave for which the operator is qualified.
This is controlled by a profile option, WMS: Sequence Picks Across Waves. This profile option determines whether sales order picking tasks should be sequenced only on priority and subinventory / locator picking order regardless of pick wave, or whether they should be sequenced by wave number, priority, and then subinventory / locator picking order.
This profile option only affects how sales order picking tasks are interleaved with other sales order picking tasks; if an operator is qualified to perform, say, replenishment or WIP picking tasks, these may be continually dispatched before other sales order tasks if they are continually being created. Therefore, if this continues to be a problem for sales order picking tasks, the operator qualifications or task types should be modified so that sales order picking tasks are not interleaved with other task types.
User dispatched a task not qualified to perform
There are two possible causes that a task for which an operator is not qualified to perform has nonetheless been dispatched to the operator.
The task may have been manually assigned to a particular operator via the Warehouse Control Board. Manual assignments take precedence over the user task type assigned to the task. However when manually assigning specific operators to tasks, you have the option to indicate the assignment should only be made if the user is qualified to perform the task type, or the assignment should be made regardless of qualifications or skill sets.
User task type populated incorrectly
The most common cause for an incorrect task type is that the task type assignment rules are incorrectly defined. Task type rules are evaluated in sequence of descending weight; the task type on the highest weighted rule for which all the rule restrictions apply (and which has a return value associated with the same System Task Type required for the task) are assigned to the task.
Verify that the rules are weighted correctly, and that different task type assignment rules do not have the same weight. Also verify that the rules that should be selected are enabled, and run the Generate All Rules concurrent request if patches have been recently applied to the system. Double-check the rule restrictions to ensure that they are encoding the correct rule logic. Finally, verify that the task type that is expected has the correct System Task Type; for instance, a Replenishment task type will never be assigned to a Picking task, regardless of the rule setup.
Tasks not consolidated for bulk picking
When tasks for the same item created by sales order pick release or manufacturing component pick release are not grouped together, as expected for bulk picking, there are several attributes to verify.
First if the item is bulk picked, verify that the bulk pick flag is enabled on the organization item, as depending on the implementation, this flag may be controlled at the organization level rather than the master level. Or, if the batch was released with a bulk picking pick methodology, verify that Bulk Picking is, in fact, indicated as the pick methodology on the rule.
Verify that all other attributes of the task are identical. Specifically, only tasks of the same item and revision, from the same subinventory and locator, and assigned the same task type, can be consolidated for bulk picking.
If the task type assigned to the task requires an equipment item with constrained capacity, verify that the consolidated tasks would not exceed the equipment capacity. Tasks are not consolidated if their combined weight or volume would exceed the equipment capacity.
Tasks for which particular license plates have been allocated are not merged with any other task.
Tasks not split as expected
When a task exceeds the equipment capacity by weight or volume, it will be automatically split. If it is split unexpectedly, there are several attributes to verify.
Verify the equipment capacity and item attributes are defined at the organization item, as depending on the implementation, this flag may be controlled at the organization level rather than the master level. Also, verify that the units-of-measure for both the equipment item weight and volume, and the picked item weight and volume, have been defined, and that they are in the same unit-of-measure class.
The system splits tasks based on the smallest capacity equipment item of the required machine resource. For instance, if a resource “Small forklift” is required for a particular task type, and three equipment items are assigned to the machine resource defined on the task type have weight capacities of 2000 pounds, 2200 pounds, and 2500 pounds, the original task is split into smaller tasks of 2000 pounds per task.
Exiting from a task makes task unavailable to others
When you enter a task, the task status is updated from Pending to Active. This prevents other operators from accessing the same task. When you exit from a task using the key assigned to the Menu function (defaulted to F2 with the default key mappings), the task is set back to a Pending status, and available for any operator.
However, in certain situations, the system is unable to rollback the task. Currently, if the mobile device loses the connection but you elect to start a new session, rather than continuing the old session, when you log in to the system, the task remains Active.
From LPN list does not include an expected LPN
The From LPN list of values in the Pick Load page displays any LPN that contains some of the allocated material in the allocated locator. That is, any LPN that includes at least one of the allocated item, revision, and lot, and if serial allocation is enabled, serial, and resides in the locator selected by the Rules Engine, will be in the LPN list of values. Verify the allocation details of the task and the contents of the license plate.
You can pick LPNs that reside in different locators than allocated may, as long as they also match the allocation details. However, these other LPNs are not displayed in the From LPN list.
Invalid LPN message when a particular From LPN is picked
After selecting a particular LPN, several additional validations are made as follows.
The system checks LPN to verify at least some of its contents are allocated, including verifying the revision, lots, and if serial allocation is enabled, serial numbers contained.
Material statuses of the contents are verified to ensure that at least some of the contents may be picked.
Availability of the contents are verified to ensure that the contents are available and not allocated or reserved to another requirement.
Invalid LPN message when a particular Pick To LPN is specified
The Pick To LPN must meet several restrictions. It must either be loaded by the operator for the same delivery, or have a context of Defined but not Used. You can generate a new LPN via a hot-key, or the desktop concurrent request. If you do not generate a new LPN the From LPN defaults as a valid Pick To LPN if the LPN entered as the From LPN was entirely consumed by the task. No other LPNs can be used as the Pick To LPN.
Invalid LPN message when a particular Drop LPN is specified
You can specify the Drop LPN for sales order picking tasks. LPNs cannot commingle deliveries at any level of nesting. Only LPNs picked for the same delivery, new LPNs generated via a hot-key or LPNs that reside in the context Defined but not Used, can be used as a Drop LPN.
Task type assignment rule cannot be compiled see:System Rules Engine
What do the different task statuses mean and how are they dispatched?
The seven task statuses, are:
Unreleased:The system created the task, but it is not yet eligible for dispatch. Tasks are generally created in this status because you want to exert additional control over exactly when tasks are released. You can update tasks in this status to Pending to make them eligible for dispatching, or directly to Queued. The system creates tasks in this status when you check Plan Tasks on the Pick Release window.
Pending:The task was created and can be sent to any available operator. The system dispatches pending tasks based on priority, and sequences tasks based on subinventory picking order and locator picking order in relation to the operator's last-known position. The system then filters tasks by task type, current operator equipment, and subinventory.
Queued:You manually assigned a task to a particular operator in the Warehouse Control Board. The system assigns queued and dispatched tasks to operations based on task priority. The system then sequences the tasks based on subinventory picking order and locator picking order in relation to the operator's last-known position.
Dispatched:The system assigns the task to an operator as part of a group of tasks because of pick slip grouping rules or cluster picking. The system dispatches the tasks based on priority, and sequences the tasks subinventory picking order and locator picking order in relation to the operator's last-known position. You cannot update dispatched tasks on the Warehouse Control board. When an operator cancels an active task in the same cluster, the rest of the tasks revert to status pending.
Active: This is the task on which the user is working. The task is rendered to the user's mobile device, but the user has not selected either the <Load> no <Load & Drop> button. As soon as the operator either loads or drops the task, the status changes.
Loaded:A particular operator has loaded the task, but the system has not posted a material transaction. To complete the task, the operator must drop the task.
Completed:An operator has transacted the task, and the material transaction has posted.
The task the user is currently working on is in the statuses Dispatched and Queued only. The system groups tasks by pick slip number, clusters order number, and cartonization ID depending on which pick method or menu entry the operator uses.
Is task interleaving supported?
Task interleaving is when tasks of different types are dispatched to an operator to minimize deadheading and take advantage of the current operator location. For instance, if, after loading a picking task, a cycle count needs to be performed in an adjacent locator, the operator should perform the cycle count first before leaving the area.
Oracle Warehouse Management has full support for task interleaving. Tasks are dispatched to an operator based on skills and equipment required for the task, operator capabilities, and grouping rules. Beyond these restrictions, tasks of any type are dispatched to operators based on priority and subinventory and locator picking order. Cycle count, picking, replenishment, and requisition move order tasks can be interleaved.
How is wave planning supported?
Wave planning refers to the process by which sets of outbound sales order tasks are grouped, released, and executed. For example, if an organization performs primarily parcel shipments, there may be one daily UPS departure in the afternoon, and one daily FedEx departure in the morning. Sales orders that must be shipped via UPS may be released several times throughout the day, while FedEx orders may be released just once, early in the morning.
You can schedule the pick release process, which creates tasks for the outbound shipments, with certain parameters. You can set several release rules the system automatically performs every day at predefined times.
Are tasks assigned to specific operators?
When tasks are created, they are not assigned to specific operators. Rather, a task type is assigned to operators, which represents the skill set the task requires. The task type has an associated set of operators and optionally, a set of equipment, any instance of which are equally qualified to perform the task. The system dispatches tasks when the operator indicates they are ready for the next task.
At the point of accepting a task, it is possible for several tasks to be assigned to a single operator, based on the current pick slip grouping rules. All tasks with the same pick slip number are dispatched together as a group. In addition, it is always possible to assign a task directly to an operator via the Warehouse Control Board.
Can tasks be automatically pick confirmed?
Auto pick confirm, an option that can be specified on the pick release batch or controlled for the organization on the shipping parameters window, automatically confirms the move order as allocated without any manual intervention. Auto pick confirmation is supported in a Oracle Warehouse Management organization.
However, only loose material is picked, and moved to the staging lane loose, unassociated with any license plates. Both cartonization suggestions and LPN allocations are not honored if the task is automatically pick confirmed. Only loose material is selected even if LPN allocation has been used. If auto pick confirmation is enabled, the subinventories from which material is allocated should not be LPN controlled. Otherwise, when attempting to confirm the move order, the system may drive loose on-hand quantities negative or the transaction may error, depending on the organization parameter for negative balances.
You can complete the ship confirmation process on the desktop Shipping Transactions window or on the mobile Quick Ship page. Note that neither LPN Ship nor Dock Ship will be available for auto pick confirmed lines, because both of these shipping processes are driven by the LPN.
The Oracle Warehouse Management Control board does not include auto pick confirmed move orders. Also, note that as is also the case for inventory organizations, serialized items can only be automatically pick confirmed if serial allocation is enabled; otherwise the system does not know which serials to transact.
Can nested license plates be picked?
Oracle Warehouse Management supports nesting license plates to any number of levels. However, only innermost license plates, that contain only loose items and not other license plates, can be picked. This means an item is stored in cases and pallets, where a case is modeled as an LPN and a pallet is a nested LPN that contains many case LPNs. You can confirm a task for that item by scanning one or several case LPNs, which would automatically unpack the case from the pallet before moving it to the staging lane. But a larger task could not be confirmed by scanning the pallet LPN label, as that license plate is not the innermost level.
What attributes must tasks share in order for them to be merged?
Tasks can be merged for bulk picking if the item is marked as bulk picked, or pick release is performed with a bulk picking pick slip grouping rule. However, several other criteria of the items must also be shared. The tasks must be for the same item and revision, and be allocated from the same subinventory and locator. Also, specific LPNs may not be allocated for the particular task. Tasks with LPN level allocations are not merged. However, tasks for different lots or serials may potentially be merged.
I can populate a reason code in tasks and transactions, as well as during material status updates. Will all of these initiate the workflow?
Only task exceptions initiate the corrective action workflow. Transactions and material status updates do not initiate a workflow process.
What changes can I make in a dispatched task?
You can change the subinventory and locator, and reduce the picked quantity. You cannot change the lot or, if enabled, the serial number.
Does Oracle Warehouse Management populate the workflow attribute serial numbers for picking and putaway exception handling
The attribute serial number is no populated.
The following table shows the Oracle Warehouse Management task type value for each of the system defined task types:
| System Task Type | Warehouse Management Task Type Value |
|---|---|
| Pick | 1 |
| Putaway | 2 |
| Cycle Count | 3 |
| Replenish | 4 |
| Move Order Transfer | 5 |
| Move Order Issue | 6 |
The seeded workflow processes, Cycle Count and WMS N Step Putaway, should always show up in the Workflow Process field in the Transaction Reasons window after the Workflow Name MTL Transaction Reasons Workflow has been selected. However, if a custom workflow process you have developed does not show up in this field, there are several things you can check.
You may not have saved the workflow process properly in the wf_runnable_processes_v table. The LOV query for the workflow process is:
SELECT DISPLAY_NAME, PROCESS_NAME, ITEM_TYPE
FROM WF_ RUNNABLE_PROCESSES_V wf, MTL_TRANSACTION_REASONS mtr
WHERE wf.ITEM_TYPE = MTR.WORKFLOW_NAME
Also if needed, the LOV query to obtain the workflow name:
SELECT DISPLAY_NAME, DESCRIPTION, NAME
FROM WF_ITEM_TYPES_VL
If the workflow is visible in this window and you are able to assign it to a transaction reason, but the process did not execute, be sure you associated the reason with both a workflow name and workflow process, and that the user entered the correct reason. The system needs both the workflow name and process to execute the workflow.
When using the seeded Cycle Count workflow process, if the system sends a notification but does not request a cycle count, it is possible you did not define the default cycle count header on the organization parameter window.
Oracle Warehouse Management supports customization of new workflow processes. Only new workflow processes created under the workflow MTL Transaction Reasons Workflow are supported. You can use the Oracle Workflow Builder to view the attributes and descriptions.
Workflow processes execute when the system prompts you for a Reason on the mobile device during task execution only. The Reason field appears in the following scenarios:
Pick Load Page: when confirmed quantity is different from suggested quantity.
Pick Load Page: when confirmed location is different from suggested location.
Pick Drop Page: when confirmed location is different from suggested location.
Putaway Drop Page: when confirmed quantity is different from suggested quantity.
Note: Although the Update Status Page requests that the user enter a reason, it does not execute a workflow.
The executed MTL Transaction Reasons Workflow workflow processes always have the following attributes:
Reason Id
Calling Program Name
Source Organization Id
Reason Name
The following paragraphs contain the default attributes for the associated Reasons.
Other than those attributes described below, the remainder of the attributes in the workflow may or may not populate depending on the transaction. For example, the destination organization attribute populates only if a putaway is done for an inter-organization transfer.
The following are applicable for both picking and replenishment tasks:
When the confirmed quantity differs from the suggested quantity. The attribute Transaction Quantity populates with the quantity actually picked.
When the confirmed location differs from the suggested location. The attributes Destination Subinventory and Destination Locator populate with the new Subinventory and Locator respectively.
The following is applicable for both picking and replenishment tasks:
When the confirmed location differs from the suggested location. The attributes Destination Subinventory and Destination Locator populate with the new Subinventory and Locator respectively.
The following are applicable for putaway tasks.
When the confirmed quantity differs from the suggested quantity. The attribute Transaction Quantity populates with the actual putaway quantity.
When the confirmed location differs from the suggested location. The attributes Destination Subinventory Destination Locator populate with the new Subinventory and Locator respectively.
This script identifies the applicable task type assignment rules called for a particular task. The following query displays all enabled task type rules for the selected organization or made common to all organizations. You must enter the numeric value for the system task type and the three-character organization code.
select wrb.rule_weight as weight,
wrt.name as name,
wrt.description as description,
operation_code as user_task_type,
ml.meaning as system_task_type
from wms_rules_tl wrt, wms_rules_b wrb, mtl_parameters mp,
bom_standard_operations bso, mfg_lookups ml
where wrt.language = 'US'
and wrt.rule_id = wrb.rule_id
and wrb.type_code = 3
and wrb.organization_id in (mp.organization_id,-1)
and mp.organization_code = &org_code
and wrb.enabled_flag = 'Y'
and bso.standard_operation_id = wrb.type_hdr_id
and bso.wms_task_type = &wms_task_type
and bso.wms_task_type = ml.lookup_code
and ml.lookup_type like 'WMS_TASK_TYPES'
order by wrb.rule_weight