Oracle Warehouse Management Rules Engine

This chapter covers the following topics:

• System Rules Engine
• Rules Engine Methodology
• Top Down Approach
• Implementation
• Implementation Considerations
• Customization
• Maintenance
• Common Problems
• Runtime Execution Trace
• Debug Message from the Rules Engine
• Frequently Asked Questions

System Rules Engine

Warehouse Management provides a full-suite of tools that enable a warehouse to effectively dispatch tasks and manage inventory. Currently, many decisions within a warehouse are left for the operator to perform, demanding a high degree of operator training, but yielding suboptimal results and occasionally serious mistakes. Material handling rules, customer requirements, and storage constraints place complex demands on the warehouse. The rules engine provides a flexible repository for the many different types of rules and restrictions to effectively manage a warehouse. This chapter illustrates how the rules engine can automate this decision making process and includes detailed implementation notes, examples, common problems, and supporting test scripts.

The rules engine enables directed picking and put away, assigns newly received material to a cost group, ensures customer compliant labeling, assigns tasks to a resource with the appropriate training and equipment, and selects the correct operation plan for a task. You can also use the cartonization criteria to assign the four options of the cartonization algorithm at the organization or subinventory level. Rules can be based on nearly any attribute in the database, including user-defined flexfields. Strategies, or a collection of rules, can be organization specific, customer specific, item specific, or specific to one of many additional business objects.

Directed Picking and Putaway

The rules engine provides intelligent suggestions for put away locations of new material, based on virtually any business process. Some common processes the rules are capable of modeling include: minimizing item fragmentation, requiring no lot commingling in a locator, directing hazardous materials to a corresponding hazardous storage location, or placing seasonal items in a subinventory dependent on time of year. Other put away possibilities include: basing the location on inspection results, purchase order type, or item category. The rules engine also suggest material put away to intelligent locations suggested by the rules engine, for any items anywhere within the warehouse.

When the system releases a pick wave to the warehouse floor, the rules engine determines the allocation suggestions. You can create picking rules to model business practices such as: to ensure stock rotation, meet customer requirements such as stock condition or quality, lot expiration date, or country of origin. You can allocate material by a simple FIFO or FEFO (first expired, first out) rule at the organization level, picking rules that pick to deplete a location to free up additional warehouse space, or rules to pick by cost group ownership. You can also model customer requirements so a single lot fills an entire order, or warehouse preferences so an item is picked from a single locator.

Task Type Assignment

Task type assignment captures the skill sets and equipment required for a warehouse task so work is assigned to appropriate users. Operators can sign onto a mobile RF device, optionally specifying the equipment available to them. Tasks are assigned to operators based on the operators skill set, equipment requirements and capacity, or the subinventory in which the task occurs. For example, you can assign hazardous tasks to personnel with the appropriate HAZMAT training, and limit put aways to the top racks to operators who signed on with a high-reach forklift.

Related Topics

Explaining Task Type, Label Format, and Operation Plan Selection Rules, Oracle Inventory User's Guide

Cost Group Assignment

Cost groups capture the material valuation accounts necessary for tracking inventory value. For instance, you can set up different accounts for refurbished, consigned, and company-owned inventory. You can also keep different cost groups for different sales channels. When you receive new material into the warehouse the owning cost group must be determined.

Material handlers should not make Cost group decisions. The rules engine automates this decision making, removes complexity from the floor and still provides material valuation accounts tracking. Cost group assignment can be made by inspection results, with a failed item assigned to a Hold for MRB cost group. Cost groups can also be assigned by supplier site, item category, or by item. The system uses default cost group of the items storage subinventory when it cannot find a rule for the transaction.

Related Topics

Cost Groups Overview, Oracle Warehouse Management User's Guide

Label Format Assignment

Compliant labeling is becoming increasingly important, but also increasingly difficult as different customers or carriers may require a different label format. The rules engine can select the appropriate label format based on customer, carrier, item category, or transportation method. These formats are associated with the required information, barcode symbologies, and appropriate layout for each item or container. Additionally, odd sized items may require different label types, or some order types may require weather-resistant labels. The rules engine can print different labels for different freight carriers or shipment types. The rules engine can also select label formats for use inside the warehouse. When you receive lot controlled items, the rules engine can print the appropriate lot stickers automatically.

Related Topics

Explaining Task Type, Label Format, and Operation Plan Selection Rules, Oracle Inventory User's Guide

Setting Up Label Format Assignment Rules, Oracle Warehouse Management User's Guide

Operation Plan Assignment

Operation plans determine the routing, packing, and consolidation operations that a task must go through. Some outbound processes may require LPN-based consolidation, whereby the system suggests which LPN to consolidate a delivery into when dropping an LPN in a staging lane, while other deliveries do not use this LPN consolidation. The operation plan selected during task creation controls these options as well as several additional features. The Rule Engine selects the operation plan based on the source subinventory, destination staging lane, customer class, or item type, or any number of different criteria.

Crossdock Criteria

Crossdock criteria determines the eligible supply and demand sources for crossdocking. You use crossdock criteria for both planned and opportunistic crossdocking. Crossdock criteria represent the business rules on which the system makes crossdocking decisions. After you create crossdock criteria, you use the Rules Workbench to assign the criteria. For more information on Crossdocking see Overview of Crossdocking and Crossdock Criteria.

Rules Engine Methodology

The rules engine is a very powerful and complex tool, but approaching it from the top down can ensure an efficient, streamlined system of rules. You can share rules among strategies and organizations. Several well-defined rules can take the place of dozens of more restrictive rules. Improper planning can lead to unnecessarily restrictive and complex rules that make the system more difficult to setup, debug, and maintain.

Definitions

Rule is a generic term for the way the intelligence is encoded in the rules engine; however, for the rules engine, they have a much more concrete meaning.

Rule

A rule is one or more restrictions that must be fulfilled to satisfy a business or customer requirement. Picking and put away rules also have an optional sort criteria to place an ordering on the list of put away or picking allocations that meet the restrictions. Picking and put away rules also have a quantity function, which specifies the function used to determine the material available for picking, or the space available for put away.

Example: Put away into any empty locator. Use the minimum of the destination locators volume and weight capacity to determine the amount of space available. Order the locators in ascending row, rack, and bin.

Picking rules also have optional consistency restrictions, to model requirements such as a pick must be for a single grade code, a single lot, or from a single subinventory. Picking rules also have an allocation mode, which controls whether allocations should be based on a pick unit-of-measure, and whether allocations should be made to the LPN detail level, or just to the locator level.

The following rules are used to develop a complete put away example.

1. Put away into any empty locator.

2. Put away into a locator, but do not commingle different lots of the same item.

3. Put away into any locator.

4. Put away into a refrigerated location.

5. Put away into any locator with a rack number greater than 3.

6. Put away into any locator with a rack number less than or equal to 3.

Cost group, task type, operation plan and label assignment rules have a return value instead of a quantity function. If all the restrictions are met, then the return value provides the name of the task type, label format, operation plan or cost group.

Example: If an item has a HAZMAT code, then return the task type hazardous.

Strategy

A strategy is an ordered sequence of rules that are used to fulfill complex business demands. The system traverses the rules of a strategy in sequence until the put away or picking task is fully allocated, or until a cost group that meets the restrictions is found. Strategies are not used for task type, operation plan and label format assignments.

Some distinct strategies are as follows:

1. Default put away strategy: First try to put away into an empty locator. If that fails, try to put it in any locator, but do not commingle different lots of the same item. Finally, if that still fails, put into any locator.

2. Never commingle strategy: First try to put away into an empty locator. If that fails, try to put it in any locator, but do not commingle different lots of the same item.

3. Refrigerated strategy: Put away into a refrigerated location.

4. On season strategy: First try to put away into any locator with a rack number less than or equal to 3. If that fails, put it in any locator.

5. Off season strategy: First try to put away into any locator with a rack number greater than to 3. If that fails, put it in any locator.

Business Object

Business Object: A business object is any entity with attributes and parameters used by a business and tracked by Oracle, such as an organization, an item, or an item category. The rules engine comes seeded with the most common business objects.

Some of the most common business objects used within rules are as follows:

• Item

• Item Category

• Organization

• Subinventory

• Customer

Strategy Assignment

A strategy assignment is a strategy you associate to an instance of a particular business object. You specify an instance by naming both the type of business object (e.g.: item category), and the name of the instance (e.g.: winter seasonal).

Some distinct strategy assignments are as follows:

1. For the organization WH1, whenever there is a put away task, use the default put away strategy.

2. For items in the item category perishable, use the refrigerated strategy.

3. For the item PR11568, whenever there is a put away task, use the never commingle strategy.

4. For items in the category summer seasonal, use on season strategy if it is March to September, and use off season strategy is it is October to February.

5. For items in the category winter seasonal, use off season strategy if it is March to September, and use on season strategy if it is October to February.

Execution for Rules with Strategies

You assign strategies, or sequences of rules, to one or several business objects in the Rules Workbench. When a pick, putaway, or cost group assignment strategy is required, the rules engine evaluates all the strategy assignments in the Rules Workbench, returning the first strategy where the attributes of the strategy assignment match the attributes of the transaction for which the strategy is required. The system filters strategy assignments so the rules engine considers only enabled assignments that are currently effective.

Although you must set up the rules engine from the bottom up, starting with the rules, the best way to understand the rules engine is to approach it from the top down. You should use the most general restrictions at each level. Setup is slightly different for cost group assignments, picking, and put away rules than from the other three types of rules.

The three steps are defining strategies for each business object, deciding which rules belong in the strategies, and defining the rules.

Task Type, Label Format and Operation Plan Selection Rules

Task type rules, label format rules, and Operation Plan rules are not assigned to strategies, but are automatically linked directly to the organization. The rule weight determines the search order. You set the rule weight for each rule, and higher weights take precedence. The higher the number the higher the weight.

For example, an organization has these types of tasks:

• HAZMAT task - required whenever item has a HAZMAT code

• high reach - required whenever item is in a locator with rack number > 4

• default task - for all other tasks

Assuming that the HAZMAT task takes priority (i.e.: if a task is both a HAZMAT task and a high reach task, then HAZMAT task should be returned), three rules are required:

1. High weight rule: If item has a HAZMAT code, return HAZMAT task

2. Mid weight rule: If item is in a rack > 4, return high reach task.

3. Low weight rule: Return default task.

Top Down Approach

In the top down approach, you must first determine the different strategies required for the different business objects. Perhaps three different customers have the same restrictions on lot quality, and all other customers do not have any preference on lot quality. This means you may need two different strategies for the two different groups of customers. If one of the customers requires lots of a certain quality for most items, but of a different quality or with different attributes for a different item, you may need two different strategies for that one customer.

List out all the common strategies that are required - for picking sales orders, picking manufacturing requirements, picking replenishment tasks, and so forth. You may find that the strategies you use when allocating material for different documents are all very similar, or they may all be different. Look for the common attributes in the strategies to see where you can reuse the same strategy, and where you may require different strategies. Conduct a similar analysis for putaway and cost group setup. The output from this step is two elements for each of the rule types: what strategies are needed, and to which business objects those strategies are assigned.

Note: You should generally avoid combining mutually exclusive conditions in a single strategy because you may often be able to separate them into two smaller strategies to get exactly the same functional behavior from the rules engine, but with better performance.

Grouping Similar Instances

Another way to simplify rules is to group instances using defining attributes. For instance, instead of creating different rules for each item at the item hierarchy level, you can create a rule for a category of items.

ExampleYou can assign the refrigerated strategy to each of the dozens or hundreds of individual items within the item category of perishable, but the rules and strategies are much easier to maintain if you group these items by item category and assign a strategy at the item category level.

Effective Dates

You can assign effective dates to Strategies and strategy assignments so you can create time dependent strategies.

The following are some of the allowed effective date types, and examples of each:

1. Always, when the strategy is not time dependent

2. Full date, to specify a particular starting and ending date

   - June 1, 2001 through July 15, 2002

3. Date, to specify starting and ending dates applicable to every year

   - June 1 through July 15

4. Month, for seasonal strategies

   - June through July

5. Day, from Monday through Thursday

6. Shift, for shift dependent strategies

Implementation

You must perform four steps to set up the rules engine for picking tasks, put away tasks, and cost group assignment rules. The steps are:

1. Create rules

2. Create crossdock criteria

3. Create strategies out of rules,

4. Assign rules, values, or strategies to business objects.

Note: Label format, operation plan, and task type assignment rules require only setting up rules.

Rules

Use the Rules window to setup rules. You build strategies out of one or more rules, and you can reuse rules for multiple strategies. Rules are slightly different for picking and put away tasks than they are for cost group, task type, operation plan, and label formatting assignments. For instance, picking and put away rules require a quantity function and use an optional sort criteria, while the assignment rules require a return value.

Restrictions

All rules have restrictions. Picking and put away rules apply these restrictions or constraints on the set of all possible locations to pare down the full list of locators from which material can be picked or put away. The assignment type rules evaluate the restrictions and return the value defined in the rule if all the restrictions are met.

For putaway rules, the restrictions answer the question "Of all possible locators in which this material could be put away to, what criteria must those locators have?” For picking rules, you can think of this as of all the locators in which this material is stored, and of all the different revisions, lots, and serials that are on-hand and available, what attributes must that material have in order to be allocated? For task type, label format, and cost group assignment rules, you can think of restrictions as the list of all the requirements that have to be met in order to select that specific task type, label format, or cost group.

You usually define restrictions by comparing two different attributes. For instance, a putaway restriction that puts material away to the subinventory named BULK equates the destination subinventory with the text “BULK”. The following are some of the different ways you can use elements to build restrictions:

Basic Operators

The most common operators used in rule restrictions are equality (=) and greater than / less than (<, <=, >, and >=). Other basic operators verify if the attribute is null or not null; these two operators require only one attribute.

Value Sets

You can define value sets to use in rule restrictions to meet complex customer requirements. For instance, a customer of a semiconductor warehouse may require microchips to be manufactured in one of an approved set of countries. The customer may change this list of countries over time and may give pending requirements to the warehouse, such as “on this coming July 15, we will begin accepting product from Thailand”, or “at the end of this year, we will no longer accept product from Taiwan”. Instead of creating multiple rules to define these changing requirements and setting up effectivity dates for these rules within a strategy, you can define a value set with values that have pending effectivity dates. In order to use a value set, use the IN operator and specify the name of the value set in the rule restriction.

Expressions

Occasionally, the Rules engine must model logic that does not correspond exactly to the seeded objects and attributes, or perhaps mathematical functions or custom user-defined tables must be referenced in the rule. By using a user-defined expression, a rule based on any data that can be accessed can be built. In order to use an expression, one of the basic operators defined above must be used, and the object on the right hand side should be set to Expression.

Sort Criteria

Picking and putaway rules have sort criteria. For putaway rules, the sort criteria determine which locators with available capacity to use. For picking rules, the sort criteria determines which specific on-hand quantity of an item to select for allocation among all the locators in which the material is stored and all the lots, serials, and revisions that are on-hand and available.

Consistency Requirements

Picking rules have consistency requirements. These are used to indicate that some characteristics must be identical across all allocations for that material request.

Allocation Mode

Picking rules have an allocation mode. The allocation mode controls several different ways in which the system can allocate material. Selecting the correct allocation mode allows a warehouse to take best advantage of the way in which material is packed and stored. The four allocation modes are as follows:

• No LPN Allocation

• No LPN Allocation Prioritize Pick Unit of Measure

• Allocation LPN and Loose

• Allocate Entire LPN Only

For instance, if items are typically stored in standard pack quantities, which are not modeled as LPNs, then the No LPN Allocation or Prioritize Pick UOM allocation mode should be used. Or if LPNs are used for storage, but the quantity stored within an LPN varies and multiple lots can often be found in the same LPN, then Allocate Entire LPN Only might be a good fit for the warehouse requirements.

No LPN Allocation

In this allocation mode, the rules engine considers loose and packed material equally. The allocation is not made to the LPN level, so the rules ignore the LPN. If the allocation is made to a locator where packed material exists, select specific LPNs unaided by the rules engine, though other attributes of the allocation such as particular lot or revision numbers must still be honored. If you defined a pick unit-of-measure and assigned it to the locator or subinventory, it is prioritized after the sort criteria that are defined on the rule.

No LPN allocation Prioritize Pick Unit of Measure

Packed and loose material is considered equally and the rules engine does not make allocations at the LPN level; however, the Rule Engine does prioritize the pick unit of measure above the sort criteria. The rules engine attempts to minimize the number of picks required for a task, subject to the rule restrictions. Units of measure and conversions are defined in Oracle Inventory, and optionally assigned to the subinventory and locator.

You can think of a pick unit of measure as the process by which a store clerk makes change for a cash transaction. Suppose the clerk has to return $0.99 to the customer. The clerk likes to make the customers happy by giving them the shiny coins first (sort criteria). The pick units of measure are the different coins: quarter, dime, nickel, and penny.

If the first allocation mode is used, where sort criteria is prioritized before pick unit of measure, then the customer might end up getting 99 brightest pennies in the cash drawer. If there are quarters, nickels, and dimes that are just as clean and shiny as the pennies, then sort criteria cannot differentiate between which coin to select first, and the pick unit of measure takes precedence.

If you use the No LPN Allocation, Prioritize Pick UOM allocation, then the system honors the pick unit of measure above sort criteria. The customer receives the three shiniest quarters, then the two best dimes, and finally, the four brightest pennies, for a total of $0.99. If there are fewer than three quarters available, the operator then tries to find more dimes, or if necessary, more nickels, and finally, if necessary, more pennies.

The only difference between this example and how the rules engine actually allocates material using this allocation mode is when the clerk would be unable to make exact change. If there were only four quarters and five dimes in the clerk's cash drawer, it would be impossible to get exactly $0.99. The rules engine would allocate three quarters and two dimes as before. But when it fails to find any pennies for the last $0.04, it would roll back up to larger coins, on the assumption that while the warehouse does not want to break up those larger units of measure, it can if necessary to avoid a customer backorder.

If you use either the No LPN Allocation, or the No LPN Allocation, Prioritize Pick UOM, the system uses both the sort criteria and the pick unit of measure; the only difference is which takes precedence. If the item is lot or revision controlled, the system does not group the different lots or revisions together when it tries to allocate full units of measure. Therefore, this allocation mode works best for material without lot or revision control that is stored in a standard pack size.

Allocate LPN and Loose

This allocation mode considers packed and loose material equally; however, the rules engine selects a particular license plate if it allocates from a locator where packed material resides. Instead of allowing operator to select one of the LPNs that contain the required item, the rules engine chooses a particular LPN. You can define restrictions or sort criteria that restrict or prioritize packed material or loose material. The system displays the allocated LPN to the operator when the task is performed, and the allocated portion of the LPN is not available for other transactions. This allocation mode can allocate partial LPNs, so the operator can select LPNs with mixed items. When this allocation mode allocates packed material, the allocation is made to the innermost LPN.

Allocate Entire LPN Only

The system considers only LPNs that can be completely consumed by the current allocated move order line. The system does not consider LPNs that contain multiple items, material partially allocated or reserved to other move order lines, or an LPNs that have a quantity greater than the required quantity. In addition, if only part of the material in the LPN meets the rule restrictions, then the system does not allocate the LPN because the move order line cannot completely consume it. As in the Allocate LPN and Loose mode above, this allocation mode allocates only the innermost LPN.

Exercise caution when you use this allocation mode as the only rule in a strategy, or in conjunction with consistency requirements. When it is the only rule (or last rule) in a strategy, the system does not allocate the move order if the allocation cannot completely consume the LPN. Unless the warehouse requires that only complete LPNs be picked and sales orders be backordered in the absence of complete LPNs, a rule that allocates packed or loose material should follow a rule with this allocation mode. This allows the system to allocate move orders with partial LPNs, or loose material, even if the system cannot allocate complete LPNs.

Suppose on hand and available are three LPNs with quantities of two, three, and four, and the rules engine attempts to allocate a sales order for quantity of five. If the rules engine comes across the LPN with four first, due to sort criteria or other reasons, the system allocates that complete LPN; however, it is then unable to allocate the remaining quantity of one. This allocation mode does not perform a best fit algorithm.

Using consistency requirements with Allocate Entire LPN Only allocation mode compounds the possibility to backorder, because if a consistency requirement is included the rules engine, the rules engine does not make any allocations if the entire allocation cannot be met. For instance, using the same example above, if the rules engine allocates the LPN with four first, the remaining quantity of one cannot be allocated, and the entire quantity of five is backordered.

The frequency of these issues is reduced if LPNs with standard sizes are used, or if rules that use this allocation mode, and particularly rules with this allocation mode that have consistency requirements, come in a strategy where subsequent rules loosen some of the allocation requirements.

You also need to consider the impact of reservations on this allocation mode. The rules engine applies reservations and rule restrictions together to make an allocation, and only if the requirements in both are met is an allocation made. The rules engine processes allocations one-by-one, before it attempts to gather additional unreserved material to allocate. When the rules engine attempts to allocate one reservation via a rule with this allocation mode, only LPNs that can be fully allocated by a single reservation are allocated. For example, if one LPN has a single item with multiple lots, and LPN-level reservations exist for all the lots in the LPN to a single sales order line; the LPN is not allocated with this allocation mode. When honoring the first reservation, the rules engine does not know additional unprocessed reservations will allow the remainder of the LPN to be allocated. This problem arises when multiple detailed reservations to a single LPN for a single source line are created in advance of allocation.

Allocate Entire LPN Only can be incredibly powerful when LPNs contain mixed lots, particularly when those lots have different attributes that are excluded or preferred by certain customers. It is also useful for manually reserving specific LPNs to sales orders when that LPN contains only a single lot or item without any controls, or when other attributes of an LPN are relevant during allocation and the warehouse wishes to best leverage the way the material is currently packed.

Quantity Function

Picking and putaway rules include a quantity function, although for picking rules, there is only one available quantity function that automatically defaults in the window and is not editable. The quantity function determines how the rules engine calculates availability of the item or of locators. For picking, material availability is calculated by the Available to Transact (ATT) quantity, which considers other allocations and reservations. For putaway, locator availability can be calculated in one of many ways that consider the locator capacity with respect to units, volume, or weight, or that use a custom, user defined, function to determine locator capacity.

Return Value

Task type, label format, operation plan and cost group assignment rules have a return value. This is the single value returned by the rule that specifies the format of the label, the specific cost group to assign, or the user-defined task type to assign if all the restrictions in the body of the rule are met.

Weight

Task type rules, operation plan selected rules, and label format rules are not assigned to strategies and do not have strategy search orders. The rules engine traverses all rules that are available under the organization, ordered by descending weight, when attempting to assign a task type to a task or selecting the correct label format.

Related Topics

Defining Units of Measure, Oracle Inventory User's Guide

Defining Unit of Measure Conversions, Oracle Inventory User's Guide

Strategies

Strategies are a sequence of rules with which the rules engine tries to allocate material or space to fulfill a request. You construct strategies in the Strategies window from one or more rules. You can reuse rules for multiple strategies. In the case of the cost group assignment rules, the rules engine returns a value as soon as the rules engine comes to a rule where all the restrictions pass. For pick and put away tasks, the rules engine stops traversing additional rules as soon as the entire task is allocated. Therefore, unless the strategy fails if specific criteria are not met (and the task is unallocated or unassigned), a general default rule should always be the last rule in the strategy.

You can assign rules after you choose the type of strategy to create and enter a name and description. The sequence number specifies the order in which the rules are executed. The rules available to be assigned to the strategy are the rules that are the same type as the strategy, and are further limited by the current organization.

You can allow partial success for pick and put away rules. If the rules engine cannot fully allocate a pick or put away task within a rule, partial success allows a task to be allocated across several rules.

• Suppose the warehouse preferred put away tasks to go first into subinventory A, then into subinventory B - but only if the task can be entirely allocated to that subinventory. Only if no space is available in those two subinventories should the task be allocated to any subinventory (including A or B) where space is available. Then there are three rules to the strategy:

• Put away to subinventory A, do not allow partial success

• Put away to subinventory B, do not allow partial success

• Put away to any available locator, allow partial success

You can also set up rules to be valid only during specific periods of time, as is necessary for seasonal rules or for rules begin some time in the future. Always is also an option for the effective date. A complete listing of the effective dates can be found in Appendix B.

The User Defined check box in the Strategies window is similar to the one in the Rules window in that it differentiates rules that have been seeded with the application from those that you define. You cannot modify seeded strategies. You cannot change an enabled strategy. You also cannot disable rules in an enabled strategy. You must disable all strategies that use a particular rule before disabling a rule; this prevents potential data corruption problems.

Rules Assignment

You use the Rules Workbench window to assign strategies to one or several business objects. As with rules within a strategy, the sequence number that you assign to strategy assignments indicates the order in which the rules engine evaluates strategy assignments. The rules engine stops searching for a strategy as soon as it finds an applicable strategy in the Rules Workbench. A strategy is applicable if the assignment is enabled and currently effective (based on the date effectivity of the strategy assignment), and all the assigned business objects match the values of the transaction to perform.

You can also assign a rule directly in the rules workbench instead of assigning a strategy. This means the rules engine searches for an applicable rule in the rules workbench instead of a strategy. If the rule type is either opportunistic crossdock or planned crossdock, you can specify only a rule as the return type.

In addition, you can assign a cost group rule value directly in the Rules Workbench. This enables you to avoid creating dummy rules and strategies that slow down system performance.

For instance, in the Rules Workbench, a picking strategy may be assigned to a particular customer and item category, so that the strategy executes for material allocation of items in that item category when an operator picks for a sales order to ship to that customer. There may be a generic organization policy for picking material for outbound sales orders, so you can assign the strategy to the sales order picking transaction type. However you must assign the generic strategy a sequence number higher than the customer-specific strategy assignment.

In the Rules Workbench window, the sequence numbers must be unique within the rule type and organization. Strategy assignments are specific to the current organization to which you have logged in to, so the organization assignment is always made for all new strategy assignments.

Only the objects to which strategy assignments are necessary should be displayed in the Rules Workbench. Use the folders feature to hide the columns for the other objects of the window, and make the folder the default folder.

Note: You can hide only folders that do not have assignments in any organization.

Related Topics

Describing the Rules Workbench, Oracle Warehouse Management User's Guide

Implementation Considerations

Because the rules engine can model complex business logic, you must consider several areas when you set up rules so the rules engine works properly.

Staging Lane Put away Rule

For any move order that has an inventory source and destination to be allocated, there must be applicable picking and applicable put away rules. For the rules engine to allocate pick wave move orders, a put away rule must exist must that has the staging lane as an acceptable put away location.

A put away rule with no restrictions assigned to only the organization is not appropriate, because it allows put away from a purchase order receipt of refrigerated material into a staging lane when instead, it should be placed in a refrigerated locator. Instead, this default put away rule should be specific for sales order staging transfers. The easiest way to set this up is to assign a strategy with a single rule (without restrictions or sort criteria) to the transaction types of Internal Order Pick and Sales Order Pick in the Rules Workbench. In order to support transfers to supply subinventories of pull items pick released for manufacturing requirements, assign this strategy to the Backflush Subinventory transfer transaction type as well.

Staging lanes for sales orders are determined by: any trip planning / dock appointments, the default staging subinventory and locator on the Pick Release window, or the default staging subinventory and locator on the Shipping Parameters window. If the staging lane is selected by one of these three methods prior to getting to the rules engine, then the rules engine validates the staging lane capacity is sufficient and that the material status of the staging lane does not disallow this transaction.

Note: It is recommended you leave the capacity fields null to define staging lane capacity as infinite. Otherwise pick release may backorder sales order line because staging lane capacity is unavailable.

It is possible to leave the locator field blank on the Shipping Parameters window, and in the absence of dock appointments or other defaults on the Pick Release window, the rules engine selects the staging lane among all the staging lanes that are in the staging subinventory. In this case, staging lane selection rules can be built based on the customer, ship method, freight carrier, or any number of other attributes related to the sales order. In these scenarios, it may make sense to model staging lane capacity as well.

Some move orders do not have both an inventory source and an inventory destination. Examples include purchase order receipt put aways (source is receiving), putaway from manufacturing completion (source is WIP), and requisition move order issues (destination is an account). The Rules engine allocates and validates only the inventory portion of the move order.

Manual Reservations

Any reservations of material that you make manually must meet the restrictions the rules create. Manual reservations do not override the rules engine, but are combined with the rules engine to further restrict potential picking and put away locators.

Example A: A reservation for a sales order is manually placed on material in source subinventory of Case Pick; however, the applicable strategy for this pick has only one rule: pick from subinventory Each Pick. Therefore, because there are no rules that agree with the reserved subinventory, the pick fails and no pick wave move order lines are allocated. The delivery line is backordered.

Example B: A reservation for a sales order is manually placed on material in source subinventory of Bulk Pick, and source locator of A.1.2 (Row, Rack, Bin). There is enough material in subinventories Each Pick, Case Pick, and Bulk Pick. The applicable strategy for this pick has two rules. The first rule restricts picks to the Each Pick subinventory. The rule fails because this does not agree with the reserved subinventory. The second rule has no restrictions. Therefore, all three subinventories pass the rule restrictions; however, the rules engine suggests only Bulk Pick A.1.2 because it is the only locator that satisfies the rules and agrees with the reserved subinventory and locator.

Example C:: A reservation for a sales order is manually placed on lot A10, which has a lot expiration date six days in the future. The applicable picking strategy has only one rule which requires that all expiration-date controlled items have at least thirty days of life remaining to be picked for a sales order. Therefore, because there are no rules that agree with the reserved lot, the pick will fail and no pick wave move order lines will be allocated. The delivery line will be backordered.

Reservations can be made to the LPN detail level either manually by a reservation you create in the Reservations window, or systematically by an LPN-based completion of a work order tied to a sales order. Typically, this scenario applies in an ATO / CTO shop where LPN-based completions are used, or if a particular LPN must be reserved to a customer because of labeling or other packaging requirements.

Whenever a reservation is made to the LPN detail level, the rules engine allocates to the same level of detail, regardless of the allocation mode on the rule that made the actual allocation; however, the system still other rule restrictions are still honored.

Related Topics

Allocating and Transacting Move Orders, Oracle Inventory User's Guide

Defining Shipping Parameters, Oracle Shipping Execution User's Guide

Performance

The performance of the rules engine is critical for large warehouses with complex requirements. You can set up the business scenarios the rules engine models in several different ways, with varying impacts on performance. A slight change in the way a rule is defined can effect how the rule performs. There are several general guidelines when defining rules to help improve the rules engine performance. It is important to stress-test the rules with the expected transaction volume prior to go-live.

Strategy Depth

The rules engine can select the correct strategy to execute almost instantly, while evaluating rules within a strategy takes considerably longer. That means more strategy assignments, where each strategy has fewer rules, are generally preferable to fewer strategy assignments with deeper strategies. This type of change may be the most difficult to implement, but if done correctly can achieve exactly the same business logic in a much more efficient fashion.

The most common way you can make strategies shallower is when they contain several different mutually exclusive rules, and the attributes that differentiate the rules are available as business objects in the Rules Workbench. For instance, you can define business logic to putaway purchase orders to different subinventories based on the supplier in two ways. A single strategy like the following, with three rules, can be assigned to the purchase order receipt transaction type

Rule Name Putaway to Subinventory INSP for ACME

Alternatively, you can assign three different single-rule strategies as follows. This strategy is assigned to the purchase order receipt transaction type, and the vendor Acme:

Rule Name Putaway to Subinventory INSP

The second strategy assigns the purchase order receipt transaction type and the vendor business world.

Putaway to Subinventory HOLD for Business World

The final default strategy, used for all other vendors is assigned only to the purchase order receipt transaction type. This strategy assignment has the highest sequence number of the three strategy assignments.

Putaway to Subinventory Bulk

The rules engine can quickly find an applicable strategy. It can almost instantly select the correct rule for an inbound receipt putaway with the latter setup. In the first setup, where a single three-rule strategy was used, the rules engine must evaluate the first two rules for all receipts where the vendor is neither Acme nor Business World before finding the correct rule to use. Also, the rules are simpler and more generic in the second example. They need only refer to the destination subinventory and not to the vendor. This allows rules to be re-used more frequently, simplifies setup and maintenance, and makes it easier to understand the existing setup from the Rules Workbench. While this process may not always result in single-rule strategies, it nonetheless can usually greatly shorten many strategies and make the rules engine execute more quickly.

Minimize Use of OR

Avoid using the connector OR in rule definitions because they are more difficult for the database to evaluate then AND. If you use OR to indicate multiple values are valid, then you can use the operator IN with a single restriction rather than multiple restrictions. If OR is used to group several mutually exclusive scenarios together and these strategies cannot be divided into separate smaller strategies, the rules engine performs better if these mutually exclusive scenarios are broken apart into separate rules in a single strategy. This runs counter to minimizing strategy depth; however, in combination with correct rule sequencing, this performs significantly better than a single complex rule.

Rule Sequencing

In some picking, putaway, and cost group strategies, and for many of the rules defined for label format, operation plans and task type selection, the logic defined by the rules is mutually exclusive and cannot be broken up into separate strategies in the Rules Workbench because the business objects that would make that possible are not available. For instance, two task type assignment rules might be set up to assign one task type if the pick is from the lower racks, and a separate task type if the pick is from the higher racks. Because it is not possible for any task to meet the restrictions in one of these two rules, the two rules are mutually exclusive.

One of the mutually exclusive scenarios may occur more often than the other. The rules engine continues to evaluate rules until it has found an assignment rule for which the restrictions are met, or until it completes the entire allocation. If you rearrange the rules and place the more frequently used rules before the less frequently used rules, or if you change the rule weights, the rules engine does not have to evaluate as many rules overall, and you improve system performance without changing the business logic.

For instance, continuing the shipment priority code example above, suppose that priority code LOW was the most frequently used priority code, representing about 55% of sales orders, while about 30% of orders had priority code MED, and the remaining 15% were priority HIGH. Then the strategy would be more efficiently written as follows, with the rule returning the more frequently used scenario placed first in the strategy. For an average 100 sales order lines, the previous strategy that did not consider sequencing, would have evaluated a total of 240 rules, while the strategy below would end up evaluating 160 rules - a performance gain of over 30%.

Note: This rule sequencing improves the average performance of a large pick release batch, even though the individual performance of a particular allocation may not improve or may even get worse by changing the rule sequencing. Stress testing under loads that approximate a production environment will provide the best guidance on the exact rule sequencing. And of course, not all strategies can be re-sequenced in this way.

Sort Criteria

You can define sort criteria for picking and put away rules. Sort criteria significantly slow down the performance of rules because the database must gather all the rows that meet the restrictions before beginning to sort. If you do not define sort criteria, the database returns the first rows that meet the restrictions without scanning the entire table. Sometimes sort criteria is critical to correctly modeling the required logic, while at other times, the sort criteria may add only marginal value, or perhaps it does not help with warehouse efficiency at all. You must weight the benefit sort criteria can add to rules against the performance impact it has on the rules engine.

Sometimes you can use multiple rules in a strategy to achieve the same logic that sort criteria provide. For instance, suppose you assign lot attribute, Grade, values A, B, or C, and a sort criteria indicates a preference of A, then B, and finally if necessary, Grade C. Instead, you use three rules in sequence to model the same scenario. The first rule indicates Grade A is valid; the second rule indicates Grade B is valid, and the third rule indicates Grade C is valid. Often, these three rules without sort criteria execute faster than the first rule with the sort criteria, if the rules engine is able to find sufficient material with the first rule. Because this leads to a deeper strategy, use data comparable to a production instance to evaluate the performance of both scenarios to provide realistic statistics on which setup would be faster.

Restrict Locators

You can add additional rule restrictions that can decrease the number of locators the rules engine query returns. This improves the performance for all picking and putaway rules, but is more helpful for picking and putaway rules that include sort criteria. For instance, if you can logically segregate items into several different categories and each category is directed to a different subinventory for putaway, the rules engine only needs to sort a fraction of the locators in the warehouse. Often, an operator performing the receipt knows the subinventory in the warehouse in which the item should be stored, but just does not know the specific locator. In this case, the operator could perform a direct receipt into a temporary staging locator. Different inbound staging locators be set up for each of the different areas in the warehouse to which material should be directed.

You could determine the subinventory based on the item category, so seasonal and non-seasonal items are directed to different subinventories to greatly reduce the number of locators the rules engine needs to evaluate. Rules could then restrict the list of valid locators based on the staging locator in which the material is located.

These types of restrictions enhance the speed of the rules engine, in some cases enabling use of sort criteria that would otherwise be too performance intensive to include in the rules.

Rule Expressions

Most of the seeded objects and attributes correspond directly to tables and columns. For instance, for a picking task, the input to the rules engine is a move order line. From the move order line, the system can join directly to the table MTL_SYSTEM_ITEMS, which contains attributes about the items. The attribute Width on the object Item in the rules engine corresponds to the column UNIT_WIDTH in this table.

You can include an expression you defined in a rule, where you can enter additional unseeded attributes, use mathematical expressions, or join to additional tables in ways to model some specific business logic. In developing the rules engine, the joins to all the required tables were made as direct as possible, slower views such as key flexfield views were avoided, and indices were added when necessary to ensure that the database could efficiently get the required data. When you define custom expressions, inefficient SQL can severely hinder the performance of the rules engine. For instance, expressions that require full table scans must be avoided for all but the smallest lookup tables. Joins should be made on identifiers when available, rather than on item or customer names.

If a rule with a user-defined expression is performing poorly, have a DBA familiar with the Oracle data model and database performance review the expression.

Inefficient Attributes

While most of the seeded attributes correspond directly to columns in the database, some of the attributes are PL/SQL functions that perform complex calculations. The attribute Number of Other Items, counts the number of unique values of INVENTORY_ITEM_ID in the table MTL_ONHAND_QUANTITIES_DETAIL, restricted by the current organization and locator the rules engine is examining. This data cannot be obtained directly unless the database is denormalized. Using this attribute leads to slower rules.

To see if the parameter or attribute you are using directly accesses a column on a table, or instead is a potentially slower function, open the parameter list-of-values in the rules engine window. To the right of the parameter name and description is a table alias, table name, and column name. If the value in the column name field is "Expression", rather than the name of a column, then that parameter uses a PL/SQL function. If rules are performing slowly, evaluate if any of the attributes are PL/SQL functions, and if they are required to model the business logic or if you could use different attributes.

Note: A PL/SQL function in sort criteria causes more performance problems than a PL/SQL function in rule restrictions.

Update Locator Capacity

Several frequently used attributes were denormalized so you can access the data available to the Rules engine directly from a table. You do not require a PL/SQL call or additional join to determine the data. The following four attributes are now part of the locator definition:

• Empty

• Only Item in Locator

• Item Resides in Locator

• Mixed Items

The system automatically updates these attributes upon material receipt. For instance, if a locator is empty, then the Empty attribute is set to Yes, an upon a material receipt, the system updates it to No; however, with the exception of the Empty attribute, the attributes are not automatically updated on material issues. If the system updated the attributes automatically, then it could cause a slow down in transaction processing. The system automatically updates the Empty attribute on every transaction because determining whether a locator is newly empty after issues or transfers is a quick calculation and does not cause a significant slow down in transaction processing.

You schedule the Update Locator Capacity concurrent request to update the other three attributes, Only Item in Locator, Item Resides and Mixed Items. The frequency with which you schedule this report depends on the transaction volume of the warehouse, the system resources available, and how significantly a less-than-optimal locator selected by the Rules Engine affects warehouse efficiency. Because of the way the system updates these attributes, a rule that uses the Mixed Items attribute to find locators with only the same item returns a subset of the valid locators. It does not return locators that contain multiple items. It may also exclude other locators that no longer contain multiple items, but contained multiple items when the system last ran the concurrent request.

In addition to updating the attributes, the Update Locator Capacity concurrent request updates the locator capacity and the Empty attribute. While locator capacity and the Empty attribute are automatically updated on every transaction (including receipts, transfers, and issues), data, such as assigning a container item to an LPN that already resides in a specific locator, or changing physical attributes of the items on the desktop Item Master window, is not automatically reflected by locator capacity.

Lot and Serial Attributes

Rules based on lot or serial attributes apply items which have those attributes defined. They fail to generate allocation suggestions for items that are not lot controlled or serial controlled, or which use a different context mapping for the flexfields.

ExampleThe general warehouse policy is that no item with less than thirty days before the lot expiration date will be shipped; however, the warehouse also carries other items that are not expiration date controlled. This can be handled by using two different rules within a single strategy. A shelf life code of 1 means there is no expiration data control, while values of 2 and 4 indicate expiration date control. Therefore the following two-rule strategy implements the organization policy efficiently.

Rules Strategy

Performance Impact of Serial Attributes

The rules engine can allocate individual serial numbers. The standard approach for serial items is for the rules engine to direct the operator to locations where sufficient material can be found, based on any applicable rules, but not to allocate specific serial numbers. When the operator performs the picks, the operator specifies which serials were picked. This is sufficient when all serials of an item are identical, all serial attributes for a given item are identical within a single locator, or there are no material statuses assigned to serials that disallow picking. The system can allocate individual serial numbers if necessary. You can use this if business practices require allocation by serial attribute, or when statuses that disallow picking are assigned to serials. This causes a significant performance reduction in the rules engine whenever serial controlled items are allocated. Do not use serial allocation unless particular business practices require it. To turn on serial allocation, check the Allocate Serial Numbers check box on the Organizations Setup window.

Note: It is possible to base rules on serial attributes even when serial allocation is disabled. The rules engine would honor the rule restrictions, allocating only from locators that have serials with the correct attributes, but would not specify the specific serials on the allocation. It would then be left to the operator to pick the correct serials from the allocated revision, lot, and locator; the system would not validate the serials selected by the operator. Therefore, if selecting specific serials based on attributes is important and serial selection should not be left to the operator, serial allocation should be enabled for the organization.

Customization

The rules engine contains dozens seeded of business objects, and comes with hundreds of attributes from which you can build rules; however, it is possible that in very complex scenarios, the basic rules engine does not suffice. You can customize the rules engine with non-invasive changes in four different ways.

If the seeded objects and attributes from which rules are defined cannot completely model the business scenario, you can write custom expressions that grab onto additional attributes and tables. If you cannot model a business scenario even with these custom expressions, you can custom define the entire rule. If the objects available for assigning strategies to the Rules Workbench do not provide enough flexibility, then you can define our own custom strategy assignments. Put away rules use a capacity calculation you can base on volume, weight, dimensions, and units of the item in comparison to the physical capacity of the locators. In situations where more complex capacity algorithms are necessary, you can customize the capacity calculation. Detailed explanations on each of these areas, including how to implement them, are included below.

Custom Expressions

Often, a rule may seem to fit within the framework of the standard restrictions, but the required object or attribute is not available, or perhaps requires some mathematical or character manipulation to retrieve the right logic, or the data is stored in a custom table.

User-defined expressions can support all these possibilities, and are a completely non-invasive way to build a rule. A rule with a user-defined expression is handled exactly the same as other rules. You can define it on the desktop Rules window, and recompile it via the Generate All Rules concurrent program.

Defining Expressions

When the rules engine executes a rule, the user defined restrictions are appended to the where clause in the rule body. The rules engine translates the restrictions on the window to A OP B, where A is the attribute is the first attribute, and B is the second attribute. For instance, the restrictionDestination Subinventory / Subinventory Name = Constant Character / BULK in a put away rule would be appended asomsei.SECONDARY_INVENTORY_NAME = 'BULK' . The column,SECONDARY_INVENTORY_NAME, is the name of the column on the tableMTL_SECONDARY_INVENTORIES . The alias,omsei , is hard-coded in the seed data so whenever the rules engine needs to join to this table, the same identifier is used.

An expression replaces the second object with the SQL entered on the rule, exactly as you enter it. Therefore, you can manually code the exact same logic if, instead of entering the restriction Destination Subinventory / Subinventory Name = Constant Character / BULK, Destination Subinventory / Subinventory Name = Expression / 'BULK'. The rule body would be identical.

The expression can be much more complex than an alphanumeric constant. Suppose you assign a particular lot controlled item to an attribute context, mapping two columns N_ATTRIBUTE1 andN_ATTRIBUTE2 to two attributes that indicate the flammability of this particular lot. Different locators throughout the warehouse have different safety ratings, and the system stores the safety as a number on a locator flexfield columnATTRIBUTE1 . Because of how the safety rating relates to the two lot attributes, a locator can store any lot so long as the product of the two attributes is smaller than the safety rating; otherwise, a hazardous situation results.

While there is no rule attribute to get at the product of N_ATTRIBUTE1 and N_ATTRIBUTE2, this restriction can be easily modeled via a rule restriction with a user-defined expression. The restriction is as follows: Destination Locator / ATTRIBUTE1 < Expression / mln.N_ATTRIBUTE1 * mln.N_ATTRIBUTE2. Of course, this expression only works if both attributes are always populated for the item; if they are optional attributes, the function NVL should be used to control what should happen if they are null.

Table Aliases

Table aliases are hard-coded in the seeded data. The easiest way to get the table alias is directly from the rules setup window. The Parameter LOV shows, in addition to the parameter name and description, the table alias, the table name, and the column name.

In most scenarios, the table alias and table name are the same for all parameters of a given object, because an object typically corresponds to a table, and parameters columns within that table. There are occasional exceptions to the rule, it makes sense to group a parameter with others from a different table. Also, you can easily see here which parameters are expressions or call PL/SQL functions, rather than directly access a column of a table, as the text "Expression" will be displayed in the column name.

If a join to an additional table or a reference a table that is already included in the objects but for which a different join is required, be sure that a new table alias is used and that table aliases reserved by the Rules Engine is not inadvertently used. To see a list of all table aliases that the rules engine may already be using, execute the following SQL query:

select name, description, table_alias 
from wms_db_objects wdo, wms_objects wo 
where wdo.db_object_id = wo.object_id 

For performance reasons, tables are added to the rule body only when they are required by the rule restrictions. The rules engine analyzes the seeded rule attributes to determine which tables to add to the base query when compiling the rule; it does not analyze any user-defined expressions. In the example above, if the only restriction in the rule is the one line Destination Locator / ATTRIBUTE1 < Expression / mln.N_ATTRIBUTE1 * mln.N_ATTRIBUTE2, then the table MTL_LOT_NUMBERS will not be added to the base, and thus the alias mln is not defined in the rule body. This rule does not compile.

In order to compile this rule, you must add an additional restriction to force the rules engine to define the alias mln. You can add a dummy restriction to the rule which is always true, joined to the real restriction by AND. The simplest dummy restriction is equating any attribute of the required object to itself, such as Lot / Lot Number = Lot / Lot Number.

Joins to Additional Tables

You can refer to the table alias to access tables part of the base query, and embed a select statement in an expression to access tables that are not part of the base query. When you join to additional tables, several considerations must be made. Make sure you completely define the join conditions, and if you use an operator such as =, <, <=, >, >=, or LIKE, that the expression returns exactly one row. If you use the operator IN, the expression can return none, one, or many rows.

Finally, be sure to assess the performance impact of any user-defined expressions. Selecting additional columns from tables that are already in the base query or performing simple mathematical operations on those columns has little performance impact. Joining to new tables not referenced in the base query could potentially degrade performance, depending on table size and table indices. Finally, embedded PL/SQL functions, such as unit-of-measure conversions, can be used, but should be avoided unless the performance degradation is tolerable, and the scenarios in which they are used are limited.

Options for Arbitrary SQL

The previous examples define a subinventory name, and multiplying two lot attributes illustrate how to use custom expressions when you need to compare a standard attribute to a user-defined attribute. Though it is more complicated, you can also compare two user-defined attributes.

To compare user defined attributes you must first create a dummy attribute as the first expression in the rule. For example, you can define a restriction Item / Item Number = Expression / SQL , where , the <SQL> return the item number if the required restriction is true and returns null if the restriction is false. The <SQL> may appear as follows:

select msi.segment1 
from custom_table ct 
where mln.attribute1*mln.attribute2 > ct.attribute1 
and ct.inventory_item_id = msi.inventory_item_id 
and ct.organization_id = msi.organization_id 

This SQL assumes that you used the item and lot objects somewhere else in the rule restrictions so you can use aliases without defining them. The custom table (custom_table) has the same primary key as the Oracle Inventory item table, inventory item identifier, and organization identifier. If the restriction mln.attribute1*mln.attribute2 > ct.attribute1 is true, then the SQL statement returns msi.segment1 (the item name), and the rule restriction evaluates Item / Item Number = Expression / msi.segment1 which is true for a single segment item.

If however, mln.attribute1*mln.attribute > 2 ct.attribute1 is false, then the rules returns nothing, and the rule restriction Item / Item Number = Expression / null is false. The Rules Engine continues to the next line, or if there are no other lines, to allocate the next rule.

You can also use parentheses in custom expressions to compare two user-defined attributes. For example, the custom restriction Destination Subinventory / Subinventory Name = Expression 'Bulk' is encoded as omsei.SECONDARY_INVENTORY_NAME = (’BULK’). These parentheses mean that the expression "'BULK' AND mln.attribute1*mln.attribute2 > (select ct.attribute1 from custom_table ct where ct.inventory_item_id = msi.inventory_item_id and ct.organization_id = msi.organization_id)" is not parsed correctly because it will be encoded into SQL as: omsei.SECONDARY_INVENTORY_NAME = ('BULK' AND mln.attribute1*mln.attribute2 > (select ct.attribute1 from custom_table ct @ where ct.inventory_item_id = msi.inventory_item_id and ct.organization_id = @ msi.organization_id)). This is not a valid WHERE clause because of the parentheses.

Instead, if you use the expression ("'BULK') AND (mln.attribute1*mln.attribute2 > (select ct.attribute1 from custom_table ct where ct.inventory_item_id = msi.inventory_item_id and ct.organization_id = msi.organization_id)", this is encoded as omsei.SECONDARY_INVENTORY_NAME = ('BULK') AND (mln.attribute1*mln.attribute2 > (select ct.attribute1 from custom_table ct where ct.inventory_item_id = msi.inventory_item_id and ct.organization_id = msi.organization_id)). The latter is a valid statement, and completely encapsulates the desired logic. To further simplify this, rather than using subinventory name, you can use the date so the restriction becomes Date / Current Date = Expression / "sysdate) AND (<REST>", where <REST> is and arbitrary SQL restriction that the system must evaluate as either TRUE or FALSE.

Custom Rule Definition

The rule is the lowest level unit for the Oracle Warehouse Management rules engine. Each enabled rule has a corresponding PL/SQL package, named WMS_RULE_####, where #### is the rule ID. For a picking or put away rule, this package contains the SQL query and corresponding logic to return a list of valid locations. The rule package for a cost group assignment, task type assignment, or label printing rule also contains a main SQL statement, but in these rules, the query is used to determine if these rules are valid for this transaction.

Because each rule has a different package, it is easy to customize the code for individual rules to meet your specific business needs. You can create and enable a rule through the user interface and retrieve the rule rule_id (see the tablesWMS_RULES_B and WMS_RULES_TL ). When you enable the rule, a PL/SQL the system creates the package on the database. You can then change the rules package to carry out whatever additional processing is necessary. The rule package can make calls to custom APIs, or carry out extra validations.

This can be a fairly powerful and non-invasive way to customize the Oracle Warehouse Management rules engine, but there are two caveats to this customization approach. If you regenerate a rules PL/SQL package, the system overwrites the customizations. Regeneration of a rule package happens in one of three ways: First, the rule can be disabled and then re-enabled through the window, or you can select Regenerate Rule Package from the Tools menu on the Rules window, or you can launch the Generate All Rule Packages concurrent program.

Second, the procedures in the rules package are expected to accept and return certain values. Customizations can change the logic of the procedures in the PL/SQL package, but changing the parameters or return values of the procedures causes errors in the rules engine.

All of the rule packages share some things in common. All have three procedures: open_curs, fetch_one_rowandclose_curs. Open_curs is called once at the beginning of the rule execution, and close_curs is called once at the end of each rule execution. For picking and put away rules, fetch_one_row can be called multiple times; for all others, fetch_one_row is only called once per rule. The package specifications for the different rule type codes are different.

Picking and Put away Rules

Picking and put away rule packages basically function the same, and they have the same package specifications.

CREATE OR REPLACE PACKAGE WMS_RULE_#### AS
        PROCEDURE open_curs ( 
                p_organization_id            IN NUMBER,
                p_inventory_item_id          IN NUMBER,
                p_transaction_type_id        IN NUMBER,
                p_revision                   IN VARCHAR2,
                p_lot_number                 IN VARCHAR2,
                p_subinventory_code          IN VARCHAR2,
                p_locator_id                 IN NUMBER,
                p_cost_group_id              IN NUMBER,
                p_pp_transaction_temp_id     IN NUMBER,
                p_serial_controlled          IN NUMBER,
                p_detail_serial              IN NUMBER,
                p_detail_any_serial          IN NUMBER,
                p_from_serial_number         IN VARCHAR2,
                p_to_serial_number           IN VARCHAR2,
                p_unit_number                IN VARCHAR2,
                x_result                     OUT NUMBER);
        PROCEDURE fetch_one_row  ( 
                x_revision            OUT VARCHAR2,
                x_lot_number          OUT VARCHAR2,
                x_lot_expiration_date OUT DATE,
                x_subinventory_code   OUT VARCHAR2,
                x_locator_id          OUT NUMBER,
                x_cost_group_id       OUT NUMBER,
                x_uom_code            OUT VARCHAR2,
                x_serial_number       OUT VARCHAR2,
                x_possible_quantity   OUT NUMBER,
                x_consist_string      OUT VARCHAR2,
                x_order_by_string     OUT VARCHAR2,
                x_return_status       OUT NUMBER);
        PROCEDURE close_curs; 
END WMS_RULE_####;

Without customization, these three procedures manage interaction with a SQL cursor. This SQL cursor returns eligible locations to pick from or put away to. Open_curs and close_curs are called once per rule to open and close the SQL cursor. Fetch_one_row is called continuously until either all of the transaction quantity is allocated or no more rows are returned from the SQL cursor.

Without customization, open_curs is called once per rule to open the SQL cursor. This procedure also populates all the variables used by the sql statement. When customizing, open_curs is a good place to take care of any setup processing, as it is called at the beginning of the rule engine processing. Here are the parameters for open_curs:

Parameters for open_curs

Parameter	Parameter Type	Description
p_organization_id	Number	The current organization (primary key for MTL_PARAMETERS)
p_inventory_item_id	Number	The item to be allocated (primary key for MTL_SYSTEM_ITEMS)
p_transaction_type_id	Number	Identifies the transaction type (primary key for MTL_TRANSACTION_TYPES)
p_revision	Varchar2 (Length 3)	Identifies revision to be allocated, as specified on move order line or pre-existing reservation. If no specific revision has to be picked, this value is -99.
p_lot_number	Varchar2 (Length 30)	Identifies lot number to be allocated, as listed on move order line or pre-existing reservation. If no specific lot number has to be picked, this value is -9999.
p_subinventory_code	Varchar2 (Length 10)	Identifies subinventory to pick from or put away to (depending on type code of rule), as listed on move order line or pre-existing reservation. If no specific subinventory has to be used, this value is -9999.
p_locator_id	Number	Identifies locator to pick from or put away to (depending on type code of rule), as listed on move order line or pre-existing reservation. If no locator has to be used, this value is -9999.
p_cost_group_id	Number	Identifies cost group to be allocated, if listed on move order line. If no specific cost group has to be allocated, this value is -9999.
p_pp_transaction_temp_id	Number	Identifies a unique record in WMS_TRANSACTIONS_TEMP and WMS_TRX_DETAILS_TMP_V (view based on above table). This record is used by the SQL cursor.
p_serial_controlled	Number	1 if item is serial controlled item, 0 otherwise.
p_detail_serial	Number	1 if allocation engine should generate suggestions for serial numbers; 0 if allocation engine should suggest locations, but not specific serial numbers
p_detail_any_serial	Number	1 if allocation engine should suggest any serial eligible serial numbers; if any other value, allocation engine should suggest only serial numbers between p_from_serial_number and p_to_serial_number. Corresponds to MTL_PARAMETERS.ALLOCATE_SERIAL_FLAG
p_from_serial_number	Varchar2 (Length 30)	If p_detail_any_serial is not 1, and p_detail_serial is 1, then all suggested serial numbers should be between p_from_serial_number and p_to_serial_number
p_to_serial_number	Varchar2 (Length 30)	If p_detail_any_serial is not 1, and p_detail_serial is 1, then all suggested serial numbers should be between p_from_serial_number and p_to_serial_number
p_unit_number	Varchar2 (Length 30)	Identifies unit number of serial numbers to pick from, as specified on the move order line. If no specific unit number has to be picked, then this value is -9999
x_result	Number	This output variable must be returned by open_curs. The value is 1 if success, 0 otherwise. If x_result = 0, the rules engine will exit with error

When customizing, it is important to return 1 for x_result if there is no error.

The rules engine calls fetch_one_row continuously until either all of the transaction quantity is allocated or there are no more rows to return from the SQL cursor. In the existing code, this procedure fetches a record from the SQL cursor and returns it to the calling procedure. This location record is then used to allocate. The following table contains the parameters for the function.

fetch_one_row Parameters

Parameter	Parameter Type	Description
x_revision	Varchar2 (Length 3)	The revision to pick or put away. If item is revision controlled, this value must not be NULL.
x_lot_number	Varchar2 (Length 30)	The lot number to pick or put away. If item is lot controlled, this value must not be NULL.
x_subinventory_code	Varchar2 (Length 10)	The subinventory code to pick from or put away to. This value must not be NULL.
x_locator_id	Number	The locator to pick from or put away to. This value must not be NULL.
x_cost_group_id	Number	The cost group to pick from or put away. This value must not be NULL.
x_uom_code	Number	The Pick UOM of the locator (as defined on the table MTL_ITEM_LOCATIONS). If the Pick UOM Code of the locator is NULL, this value should be equal to the Pick UOM Code of the subinventory (from MTL_SECONDARY_INVENTORIES). Alternately, if you do not want to use the Pick UOM functionality built into the Rules engine, then this value can always be equal to the Primary UOM of the item.
x_serial_number	Number	If p_serial_controlled = 1, p_detail_serial = 1, and p_type_code = 2, then this value should contain the serial number to pick. If p_type_code = 1, then this value is not used.
x_possible_quantity	Number	For picking rules, this is the total available quantity for these return parameters (revision, lot, sub, locator, cost group). If x_serial_number is not NULL, return 1. For put away rules, this should be the available capacity in the locator.
x_consist_string	Varchar2 (Length 1000)	This string is used when a rule has consistency restrictions defined. Records returned from the fetch_one_row with the same x_consist_string can be issued together. Return NULL to disable the consistency functionality built into the rules engine.
x_order_by_string	Varchar2 (Length 1000)	This string is used by the Pick UOM functionality. The value normally returned in this parameter is a concatenation of all the sort criteria values for this record. For example, if sort criteria is Lot number, and this record has a lot number of A, then x_order_by_string = A. If the sort criteria is lot number and lot expiration date, then x_order_by_string might look like A01-01-2001, a concatenation of the lot and the expiration date. Setting this parameter to NULL will affect the performance of the Pick UOM functionality built into the rules engine, causing sort criteria to be ignored.
x_return_status	Number	1 if record is successfully found and returned, and 0 if no more rows to fetch. If x_return_status = 0, all other return values are ignored.

• Returning a record from fetch_one_row does not insure that this record is used to allocate. The rules engine checks availability of the material on picking rules and capacity of the locator on put away. The engine makes other checks and orders records received from fetch_one_row based on order_by_string and consist_string.

  The last procedure in the rule package is close_curs. Without customization, this is used to close the SQL cursor after the rules engine is finished with the rule. There are no input or output parameters. When customizing, this is a good procedure to carry out any cleanup or post rule processing that must occur.

Cost Group Rules

Create Or Replace Package WMS_RULE_#### AS
 procedure open_curs (
                p_line_id     IN NUMBER, 
                x_result     OUT NUMBER); 
        procedure fetch_one_row  ( 
                x_return_status       OUT NUMBER);
        procedure close_curs;
 END WMS_RULE_####;

Open_curs and close_curs function the same way as those procedure do in the packages for picking and put away rules; however, the arguments for open_curs are different:

open_curs Argument Parameters

Parameter Name	Parameter Type	Description
p_line_id	Number	Primary Key for an entry in WMS_COST_GROUPS_INPUT_V. This record represents either a move order line or a transaction temp record.
x_result	Number	This output variable must be returned by open_curs. The value is 1 if success, 0 otherwise. If x_result = 0, the rules engine will exit with error

Unlike the picking and put away rules, fetch_one_row only returns a status. If x_return_status = 0, then the cost group for this rule will not be used. If x_return_status >= 1, then the cost group rules engine will assign to the transaction the cost group associated with this rule.

Task Type Rules

CREATE OR REPLACE PACKAGE WMS_RULE_#### AS
        procedure open_curs ( 
                p_pp_transaction_temp_id     IN NUMBER,
                x_result                     OUT NUMBER);
        PROCEDURE fetch_one_row  ( 
                x_return_status       OUT NUMBER);
        PROCEDURE close_curs; 
 END WMS_RULE_####;

The procedures in the task type rules package behave exactly like the cost group rules. If x_return_status >= 1, then the task type associated with that rule is used. The parameterp_pp_transaction_temp_id corresponds to a single entry in the MTL_MATERIAL_TRANSACTIONS_TEMP table.

Label Printing Rules

CREATE OR REPLACE PACKAGE WMS_RULE_#### AS
         procedure open_curs (
                p_label_request_id           IN NUMBER,
                x_result                     OUT NUMBER);
        PROCEDURE fetch_one_row  (      
                x_return_status       OUT NUMBER);
        PROCEDURE close_curs; 
END WMS_RULE_####;

The procedures in the label rule package behave like the procedures for cost group and task type assignment rules. The only difference is the parameter p_label_request_id. This value is the primary key for the table WMS_LABEL_REQUESTS, corresponding to the column label_request_id.

Operation Plan Rules

CREATE OR REPLACE PACKAGE WMS_RULE_XXXXX AS 
        procedure Get_OP (  
         p_pp_transaction_temp_id     IN NUMBER, 
         x_return_status              OUT NUMBER);
 end WMS_RULE_XXXXX;  

The procedures in the operation plan rule package behave like the procedure task type assignment rules. The parameter p_pp_transaction_temp_id is the transaction_temp_id of the task in mtl_material_transactions_temp. If x_return_status >= 1, then the operation plan associated with that rule is used.

Custom Selection Process

Oracle Warehouse Management enables you to develop your own selection process, using both seeded objects and user-defined objects. The package WMS_RE_CUSTOM_PUB contains a procedure, SearchForStrategy, that you can customize. When looking for a strategy, rule or value to use during allocation or cost group assignment, the rules engine calls this procedure, which returns a strategy, rule, or value identifier. Without customization, this procedure returns NULL for return_type_id, and uses the normal process using the Rules Workbench to select the appropriate strategy, rule, or value. You can customize SearchForStrategy to use customer-specific algorithms to find an allocation strategy , rule or value . When SearchForStrategy returns a non-NULL return ID, that ID is used as the pick, put away, or cost group engine , and the assignments in the Rules Workbench are ignored.

You can find the following procedure specification for WMS_RE_CUSTOM_PUB at $WMS_TOP/patch/115/sql/WMSPPPUS.pls

procedure SearchForStrategy (
            p_init_msg_list             in                      varchar2         := fnd_api.g_false
           ,x_return_status             out     NOCOPY  varchar2
           ,x_msg_count                 out      NOCOPY  number
           ,x_msg_data                   out    NOCOPY  varchar2
           ,p_transaction_temp_id  in                           number   := fnd_api.g_miss_num
           ,p_type_code                 in                      number   := fnd_api.g_miss_num
           ,x_return_type               out  NOCOPY             varchar2 -- 'V' for Value , 'R' for Rule , 'S' for strategy
           ,x_return_type_id            out  NOCOPY              number
           );

Parameter Name	Parameter Type	Description
p_init_msg_list	Varchar2 (Length 1)	This parameter indicates whether message stack should be initialized. When customizing you can ignore this parameter.
x_return_status	Varchar2 (Length 1)	S = Success; E = Error; U = Unexpected error. Returning S means that the custom procedure found a strategy. Returning E means that the custom procedure did not find a strategy, and the rules engine should find a strategy using the normal algorithm. Returning U causes the rules engine to error out. The procedure should return one of these three values.
x_msg_count	Number	This value represents the number of error messages in x_msg_data (see subsequently). If there no errors occur, then return 0.
x_msg_data	Varchar 2 (Length 240)	This string holds the names of the error messages that are encountered in the procedure. If there no errors occurs, then return NULL.
p_transaction_temp_id	Number	This number is the line ID for the move order on which the rules engine is running. It corresponds to the line_id column on MTL_TXN_REQUEST_LINES table. This value is always passed.
p_type_code	Number	The type code of the strategy that should be found. Every strategy has a type code: Pick (2), Put Away (1), or Cost Group (5).
x_return_type	Varchar2(1)	The return type values are: S: Strategy R: Rule V: Value
x_return_type_id	Number	This return type identifier is a strategy_id, rule_id, or value identifier based on the value of the return_type (S, R, or V)

Even after you customize the procedure, the Rules Engine can still use the Rules Workbench if SearchForStrategy returns a NULL value for x_return_type and x_return_type_id. This is useful if you want to use only a custom algorithm. When the criteria are met, the procedure returns a return_type_id. When you want the engine to find a strategy, rule or value using the rules workbench, the procedure returns NULL for x_return_type and x_return_type_id.

Custom Capacity Calculation

When determining locations eligible for put away, the rules engine examines the capacity of the location. Current capacity for each location is stored on the MTL_ITEM_LOCATIONS table. The rules engine looks at these numbers to determine how much is available to put away. There are three ways that capacity is measured - by weight, by volume, and by units.

Depending on the quantity function on a put away rule, the rules engine uses available capacity by weight, volume, units, or some combination thereof, on the locator definition to determine the locator's capacity for the given item. An additional quantity function is Available Capacity by Customer-Specific Algorithm. This function should return the capacity for the given item in that items primary UOM. The rules engine takes the minimum of that quantity, and the available capacity where units, weight, and volume also considered, to be the available locator capacity for this transaction

You can also use capacity information in the restrictions and sort criteria of a put away rule. The Subinventory/Locator, contains four parameters which call customized functions.

Object Subinventory/Locator Customization Parameters

Parameter Name	Function Name	Description
Available Capacity by Customer-Specific Algorithm	WMS_RE_CUSTOM_PUB.GetAvailableLocationCapacity	The unoccupied capacity in a locator that is not already reserved for other put away allocations
Occupied Capacity by Customer-Specific Algorithm	WMS_RE_CUSTOM_PUB.GetOccupiedLocationCapacity	The capacity taken up by material currently in the locator
Remaining Available Capacity by Customer-Specific Algorithm	WMS_RE_CUSTOM_PUB.GetRemainingLocationCapacity	The available capacity of the locator after the current transaction
Total Capacity by Customer-Specific Algorithm	WMS_RE_CUSTOM_PUB.GetTotalLocationCapacity	The overall capacity for the locator, regardless of what is currently occupied or available

Without customization, these functions return 0.

Custom Quantity Function Example

The following example shows an example of a custom quantity function for a putaway rule; however, these details should be used only as a guide. You should test any custom functions on your own system to ensure that the results meet your expectations.

The warehouse operation is split across two subinventories, called PICKFACE and RESERVE. The RESERVE subinventory is a bulk storage area. Stock is received in pallets and generally stored in RESERVE. Min-Max replenishment is used to move stock from RESERVE to PICKFACE as required

RESERVE is LPN controlled, but PICKFACE is not LPN controlled. Putaway is always to empty locators.

For maximum efficiency, during putaway the logic should first check the on-hand for that item in PICKFACE. If this is below the min-max minimum level then putaway should be directed to PICKFACE to take it up to the min-max maximum level, with any remainder being put away to RESERVE. Other considerations, such as perform this special putaway directly to PICKFACE only if the stock in RESERVE is not older than the stock in PICKFACE, may also be included.

You can define restrictions that direct you to PICKFACE if the subinventory quantity is below minimum, but there would be no way to indicate to the system that the putaway should be split so that PICKFACE does not exceed maximum. To place a limit on the capacity of the floating locator below the weight or volume capacity implied by the physical attributes, a custom quantity function is required.

Desired Output

Consider an item with the following setup:

• Min-Max minimum = 15

• Min-Max maximum = 30

• PICKFACE locator capacity = 10

• Current on hand = 12

• LPN contents = 50

The desired output from the rules engine is as follows:

Subinventory	Locator	Quantity	Cumulative Pending & On-Hand Subinventory
PICKFACE	1	10	22
PICKFACE	2	10	32
RESERVE	1	30	30

Note: This brings the cumulative on-hand balance in PICKFACE to 32 rather than the maximum 30. This is acceptable because only empty locators are used. Replenishing the locators to full quantity rather than a partial quantity postpones the next required replenishment and does not take up extra space.

Reasons for Custom Quantity

The difficulty in meeting this requirement with the standard quantity functions, or even with custom rule restrictions, lies in the way putaway rules are executed. The operation is as follows:

• The system evaluates the rule restrictions to generate a list of all allowable locators.

• Rule sort order is applied to the sort list.

• The rule quantity function is evaluated for the first locator. The system will put away the LPN, or a part of the LPN if the locator capacity is less than the LPN quantity.

• The system evaluates the quantity function for the next locator in the list, and repeats the previous steps until the LPN is completely put away, or no capacity exists.

Maintenance

If a strategy search fails or if all the rules within a strategy fail, the rules engine cannot assign or allocate the task, or assign a label or cost group. If you do not set up the rules, strategies, or correctly, the rules engine returns an illogical or suboptimal result. To track the causes of these problems, Oracle Warehouse Management provides the following diagnostics features:

• Rule and Strategy of Transaction

• Rule Where Used

• Simulation

Rule and Strategy of Transaction

Determine which rule strategy the rules engine used. The rules engine stamps the rule and strategy that generated each pick and put away suggestion on the transaction. You can view this from the desktop View Material Transactions window after the transaction completes.

Rule Where Used

To determine which strategies use a particular rule, the Rule Where Used window provides a view of all strategies that use that rule, within that organization. If a rule is common to all organizations, you must perform this check must in each organization that uses the rule.

Simulation

The best way to debug the rules engine setup is to use the rules engine Simulator. The simulator takes an unallocated move order as input, and can display the allocation details that would be created with any enabled pick or put away rule or strategy. It can also simulate the entire strategy selection process to help debug the strategy assignments. Details about the allocation indicate why specific material or locators were not selected.

Related Topics

Explaining the Oracle Warehouse Management Rules Engine Simulator, Oracle Warehouse Management User's Guide

Common Problems

Common problems and their causes and solutions, including debugging scripts (if applicable) are discussed below.

1. No orders lines selected in pick release

   This happens when no unreleased or backordered order lines meet the selection criteria specified in the pick release rule or Release Sales Order window. Selection criteria could include the order number, delivery number, trip number, customer, order type, scheduled ship date, requested date, or order line status. Available order lines are limited to booked orders that are unreleased or backordered, so if no lines meet the specified criteria, no lines are released. You can check the pick release request log to confirm no lines are release. Search for text like:

   No lines selected for organization V1

   The system generates a request when pick release is run in concurrent mode, and the request number is given when Concurrent is selected. See: Overview of Pick Release., Oracle Shipping Execution User's Guide

2. Orders selected but lines backordered

   Lines are backordered when no material is available that meet the picking rule restrictions, or when there is not enough capacity available in the selected staging lane. Model staging lanes as locators with infinite capacity (by leaving the capacity fields blank on the locator definition window) so that the latter problem does not occur. The former problem, however, indicates the rule restrictions are incorrect or too restrictive, or if they are correct, that there is no available material in the warehouse that meet those restrictions. Either problem will be indicated in the pick release request log with the text like:

   Pick Release process could not allocate 12 of item JCNOSTK for order 5000726 as there was insufficient quantity available.

   The first step in debugging this situation is to check the available quantity of the item using either the mobile item inquiry window or the desktop material workbench window. Picking allocates from available quantity, rather than on-hand quantity, because available quantity excludes material that has already been reserved.

   If there is a material reservation of this item to the sales order, then the reservation quantity does not appear as available, but the rules engine still validates that the reserved material meets the picking restrictions. You can find Reservations in the Desktop Reservations window. A reservation could have been made manually or by Order Management during Auto-Scheduling. See Availability and Reservations, Oracle Order Management User's GuideAvailability and Reservations . If the reservation specifies a revision, lot number, subinventory, or locator, verify the reservation meets the rule restrictions.

   If there is available material, determine which picking strategy should have been selected. This can be done by checking the strategy assignments in the Rules Workbench, and then searching for (currently effective) strategy assignments that match the order line, or by pick releasing the sales order with Auto-Allocate disabled and using the rules engine Simulator to better understand why the sales order is not getting allocated.

   Use the rules engine Simulator to determine exactly why a sales order is backordered. The most common cause is incorrect put away rules setup that does not validate the staging lane that is defaulted by the pick release process The common causes are capacity limitations on staging lanes, incorrect effective dates on the rules or strategies, or mistakenly disabling the Partial Success Flag on the strategy definition. Other considerations to check for are the material status on the material, or the source and destination locators. All of these validations are displayed by the rules engine Simulator.

   Check the selected strategy rule by rule to determine if the desired behavior is properly coded in the rule restrictions and consistency requirements (the sort criteria only impacts the order in which material is chosen, assuming that multiple material units are available). If consistency requirements are specified, verify that there is enough material available with those particular attributes. For instance, if consistent lot is specified, check if there is enough available in a single lot. If not, then that rule returns no allocations and the rules engine will go to the next rule in the strategy. Verify that the rule restrictions are correct and that if lot or serial attributes are specified, the correct attribute columns are referenced. The lot and serial attribute columns can be found in the descriptive flexfield definition window.

   Other possible causes could be incorrect effective dates or incorrect selection of the partial success flag on the strategy definition. Verify that if any effective dates other than Always are used, that they encode the proper system behavior. Effective dates can be used in two places: rules may be effective only during certain periods on a strategy definition, and strategies may be effective only during certain period on a strategy assignment. Finally, unless a specific scenario exists where material must be allocated using entirely one rule, the partial success allowed flag on the strategy window should be enabled. Otherwise, even if partial allocations can be made using multiple rules within a strategy, no material will get allocated unless the allocation can be made entirely from a single rule.

   Material may not get allocated if no strategy can be found and there is no default picking and put away rule defined on the Organization Parameters window.

3. Allocations Not What Expected

   The picking and putaway strategy and rule that were selected by the system are stamped on the temp transaction prior to performing the transaction, and on the transaction history after the transaction has been completed. Therefore, the selected rule or strategies can be seen by a SQL query on mtl_material_transactions_temp prior to transaction, or via the View Material Transactions window on the desktop after the transaction has taken place.

4. Lines Allocated But Task Type Not Assigned

   After the material allocation is made for a picking or replenishment task, task type assignment is performed. If the allocation was made but no task type was assigned, then no enabled task type rule was applicable. Note that a default task type rule can be specified at the organization level. This scenario can be detected with the following script, which returns all the task lines in the table mtl_material_transactions_temp of a given move order or batch number:

   --Replace &batch with the pick release batch number within single quotes
   select bom.operation_code as task_type, item.concatenated_segments as item, 
       transaction_quantity as qty, transaction_uom as UOM,     temp.subinventory_code as subinventory, loc.concatenated_segments as locator
    from  bom_standard_operations bom, mtl_material_transactions_temp temp, 
       mtl_txn_request_lines mol, mtl_item_locations_kfv loc, 
       mtl_txn_request_headers head, mtl_system_items_kfv item 
   where temp.move_order_line_id = mol.line_id and item.inventory_item_id = temp.inventory_item_id 
                   and item.organization_id = temp.organization_id 
                   and mol.header_id = head.header_id
                   and head.request_number = &batch
                   and bom.standard_operation_id = temp.standard_operation_id 
                   and loc.inventory_location_id = temp.locator_id  

   Check for null entries in the task type field. To debug this scenario, determine which rules should apply to the line, and verify that the rules are enabled. A list of all enabled task type rules of a given organization, in the sequence they are applied, can be seen with the following script:

   --Replace &org_code with the 3 character within single quotation marks
   select rule_weight, name, description, type_hdr_name 
   from wms_rules_v rule, mtl_parameters mtl 
   where type_code = 3 
                   and rule.organization_id = mtl.organization_id 
                   and organization_code = &org_code 
                   and enabled_flag = 'Y' 
                   order by rule_weight 
                   

5. Task Type Assigned But Task Not Available to User

   The most common cause of this problem is problems with the task type setup, such as the resource or employee definition. See System Task Management for additional information.

6. Rule Cannot be Compiled

   The system performs several syntax checks are on a rule when you enable it. The system checks parentheses to make sure they match and are closed properly. Also, if the rule includes a user-defined expression, the system verifies that the expression is correctly defined. For custom expressions, verify that the correct table aliases are used, and that the tables identified by the aliases would be included in the rule. Recall that a dummy restriction may need to be added for some user-defined expressions.

   If the rule still does not compile, there may be a problem with the seeded objects. If the rule has multiple restriction (or sort criteria) lines, make a copy of the rule and remove the restriction or sort criteria lines one by one; attempt to compile the rule at each removal. (Ensure that the parentheses match at all times by removing all parentheses, even though this does not correctly model the rule logic.) If, after removal of a particular line, the rule can then be compiled, that attribute is the offending component. Contact Oracle Support and provide them with that particular restriction line, and with the entire rule.

7. Rule Not Available for use in Strategy

   Only enabled rules can be used in strategies; verify that the rule is enabled. If both the Rules window and the strategy window are open at the same time, the enabled rule must be saved before the rule will be available for strategies. Rules are organization specific, unless they are shared across all organizations by checking the Common To All Orgs check box. Also, rules can only be used in strategies of the same type. For instance, a put away rule cannot be used in a picking strategy.

8. Strategy Not Available for use in Strategy Assignment

   Only enabled strategies can be used in strategy assignments; verify that the strategy is enabled. If both the strategy and the strategy assignments window are open at the same time, the enabled strategy must be saved before the strategy will be available for strategy assignments. Strategies are organization specific, unless they are shared across all organizations by checking the Common To All Orgs check box. Also, strategies can only be used in a strategy assignment of the same type. For instance, if the selected strategy type on the strategy assignments window is picking, then only picking strategies appear in the list of values.

9. Cannot Disable rule

   A rule can only be disabled if it is not used in any enabled strategies; all strategies in which that rule occurs, even if the strategy is in a different organization, must first be disabled. The rule where used window indicates in which strategies a particular rule is used.

10. Cannot Disable Strategy

    A strategy can only be disabled if it is not used in any enabled strategy assignments in the Rules Workbench. All strategy assignments in which that strategy is used, even if in a different organization, must be disabled or deleted before that strategy can be disabled.

11. Unable to Allocate Error

    This error occurs on the mobile device from a user-triggered LPN put away. This indicates one of the following:

    • None of the locators chosen by the rules in the selected put away strategy have available capacity

    • The restrictions on the rules do not return any locators even before capacity considerations

    • No put away strategy was found and no organization default put away rule was defined on the Organization Parameters window.

    This may also indicate that the current locator of the LPN is a valid locator returned by the rules engine. A user-triggered LPN put away creates a move order in the background, and a move order cannot have the source and destination locators be the same.

    Finally, this may indicate that the current location of the LPN is not a valid picking location for that item. Both picking and put away rules are used for every move order, so if current LPN locator does not meet the restrictions in any of the rules of the applicable picking strategy, then the system cannot allocate the move order. The best way to ensure that the source of a move order validates is to assign a pick strategy with a single rule with no restrictions to the transaction type Move Order Transfer. This is used for both requisition move orders and put aways initiated on the mobile device, so verify this is the logic desired. Perhaps some material should not be allocated for these move orders and thus should be excluded by rule restrictions (or material status) this material could still be moved by a user initiated subinventory transfer.

12. Allocation violates consistency restrictions on rule

    When multiple manual reservations are created on a single sales order, the consistency rules may not work as expected. The system treats each reservation as a different input record for the rules engine, meaning that allocations occur separately for each reservation. Since allocation for each reservation occurs independently of allocation for the other reservations, the system does not check consistency restrictions across reservations.

    Example: Customer JBC orders quantity 20 of item K100. JBC specifies that they want 10 from lot A and 10 from lot B. The user creates 2 reservations on the sales order - one for quantity 10 on Lot A and one for quantity 10 on Lot B.

    The first rule encountered when the rules engine is run says Pick from a consistent subinventory. The rules engine could allocate 10 of Lot A from subinventory EACH and 10 of Lot B from subinventory STORES.

13. The rules engine suggest a putaway locator but commingle occurs error on dropping

    Cost group commingling is supported in a single locator as long as there is some differentiable characteristic of the material other than only its cost group, such as its innermost LPN if packed, lot, serial, revision, or item number. Therefore, because rules engine based material movement generally occurs with LPNs, there is only one circumstance when a cost group commingling error could occur from a directed putaway.

    If the destination subinventory is non-LPN controlled then the system attempts to unpack the LPN when the material is dropped. This implicit unpack transaction may remove the only characteristic (innermost LPN) that differentiated the material in transit from the material already in the locator. In this situation, the drop will fail and the user must select a different locator to put the material away to.

14. Material not allocated in FIFO fashion even though the FIFO rule is used.

    The way the system records the date that is used for FIFO depends on the setting of the profile option INV: FIFO for Original Receipt Date system chooses the oldest receipt date of lines with same item/sub/loc/lot/CG.

    If the profile option is disabled, then the system records the receipt date as the earliest date at which that item / revision / lot / cost group was first received in that locator. Material movements that create new on-hand records reset the receipt date to the date at which the transaction occurred, so a subinventory transfer of material into a new locator sets the receipt date of that item in that new locator to be the transfer date.

    If the profile option is enabled, then the system records the receipt date as the current date for transactions that create material, and as the receipt date on the on-hand record for material transfers. In this case, a subinventory transfer retains the original receipt date. To use true FIFO (to the extent that the system can distinguish the inventory), the profile option should be enabled, or set to Yes.

    When the sort criteria Stock On-hand Receipt Date is used, the rules engine is looking atORIG_DATE_RECEIVED , or if this is null, DATE_RECEIVED, in the on-hand record in MTL_ONHAND_QUANTITIES. DATE_RECEIVED is always the date at which that material was first received into the locator, while ORIG_DATE_RECEIVED is controlled by the profile option as described above.

    Because material is consumed from MTL_ONHAND_QUANTITIES on a FIFO basis with regards to DATE_RECEIVED, there may be a mismatch between the consumption of the material via transactions and the allocation of the material by the rules engine. This potential mismatch only occurs when there are no other criteria beyond item, revision, lot, subinventory, locator, and cost group to uniquely track material, so there would be no way to indicate to the operator which material to select. With multiple MTL_ONHAND_QUANTITIES records, the system selects the oldest date from records with same item/rev/sub/loc/lot/CG.

15. After applying a patch, sales orders are backordered and/or put away fails.

    When a rule is enabled, in the background, a PL/SQL package is generated with the rule restrictions and sort criteria. This is done so that pick release can run efficiently. The package includes SQL that references the tables and columns in the data model that are required for the rule. When patches are applied to the instance that change the data model, such as seed data changes or schema changes, these rule packages become invalid and must be recompiled. The rules engine will error and not allocate the move order if it attempts to apply a rule with an invalid package.

    Run the concurrent request to regenerate all rules, available from Other ->Requests -> Requests -> Run -> Generate All Rules in the Warehouse Manager responsibility. The PL/SQL package for all rules that are enabled will be regenerated by this request. Alternatively, there is an option in the Tools menu of the Rules form to regenerate the PL/SQLpackage for each rule individually.

Runtime Execution Trace

When you enable Runtime Logging from the logging preferences, the rules engine records a trace of all the strategies and rules that were evaluated, as well as which material or locators failed validation prior to coming to the final suggestion. Even when a move order is backordered, and no allocations are made, this data is recorded. You can view the data can be viewed in the Runtime Execution Trace window available from the desktop Warehouse Manager responsibility. The user-interface of this window and the type of information available is almost identical to that available in the rules engine Simulator. See Explaining the Oracle Warehouse Management Rules Engine Simulator, Oracle Warehouse Management User's Guide.

Debug Message from the Rules Engine

The Oracle Warehouse Management rules engine records debug messages in the pick release log. These debug messages help identify which strategies and rules were execute, reasons why various pre-suggestions were bypassed, and other information useful in identifying problems. Writing this log files slows performance of pick release. This log should be enabled when it is necessary to debug an issue. Please include this log whenever reporting an issue to Oracle Support.

This log is enabled or disabled using profile options. Please note that logging must also be turned on in order to use the Rules Engine Trace Mode.

Frequently Asked Questions

1. When are picking/put away rules used?

   The picking and put away rules engine is used for every move order within Oracle Warehouse Management-enabled organizations. This includes manual move orders, replenishment move orders, and sales order staging move orders. This also includes move orders which are created in the background via the mobile LPN put away page.

2. When are cost group rules used?

   All material in the warehouse has a cost group. Therefore, the cost group rules are used whenever new material, or material that does not already have a cost group, is received into inventory. This occurs on miscellaneous receipts, purchase order receipts, RMA receipts, WIP completions, and WIP component returns, for instance.

3. When are task type rules used?

   All tasks that are dispatched must have task types, and therefore use the task type rules. This includes replenishment, picking, and requisition move order tasks.

4. When are operation plan rules used?

   Operation plan rules are used to assign an operation plan to sales order picking tasks. They are not used for other types of tasks.

5. When are label format rules used?

   Label format rules are used for every label print request here the label format is not already specified by the user. This includes manual, user-triggered print requests, as well any labels that are triggered by transactions. To setup label formats and printers see: Defining Label Formats, Oracle Warehouse Management User's Guide

6. How is the appropriate staging lane selected?

   The put away locator for a sales order staging transfer is always a staging lane. The staging lane is selected by any dock door appointments, or by the default staging lane indicated on the pick release window or on the Shipping Parameters window. At a minimum, the Shipping Parameters window must have a staging subinventory defined. If no locator is defaulted, however, the rules engine can be used to select the best staging lane from the defaulted staging subinventory based on any number of criteria, such as freight carrier, ship method, or customer specific lane.

   The rules engine is always used to validate the staging lane, regardless of how the lane was initially suggested. The rules engine verifies that the lane is valid based on any rule restrictions in the applicable strategy, and also checks staging lane material status and capacity.

7. Can the rules engine Over allocate?

   The rules engine cannot over allocate material in Oracle Warehouse Management. The rules engine allocates the quantity indicated on the order line, or less if some quantity needs to be backordered.

8. What does the Allocate Serial Numbers check box on the Inventory Organizations window do?

   When this check box is checked, the rules engine suggests which serial numbers the operator should pick. When the check box is not checked, the rules engine just suggests the revision, lot number, subinventory, locator, and quantity for the material to be picked, and the operator enters the serial numbers during pick confirm. If serial allocation is turned off, the rules engine does not direct operators to serials with a material status that disallows picking or to serials that do not match any serial attribute (or other serial specific fields) specified in the rule restrictions. Enabling suggestions of serial numbers could result in poor performance, so the check box should be set only in certain business scenarios.

9. What if the contents of an LPN require put away to different locations?

   It could be that the contents of an LPN must be put away to different locators. For instance, an LPN might contain two different items that need to go into different locators. Or an LPN may contain different lots of the same item, where the lots have different material statuses and the put away rule directs material to a locator of like material status. The system directs the operator to put away each content item, revision, and lot in the license plate separately.

10. How do consistency requirement, pick UOM, and sort criteria interact?

    Consistency requirements are always maintained regardless of sort criteria or pick unit-of-measure. If the allocation mode No LPN Allocation, Prioritize Pick UOM is used, then the pick unit-of-measure of the locator is considered more important than sort criteria when choosing which material to pick. Sort criteria are still used to determine which material to pick, but only among locators that have the same pick unit-of-measure. If the allocation mode No LPN Allocation is used, then the sort criteria take priority over the pick unit-of-measure of the locator. Pick unit-of-measure is still used, but only to choose among material for which the sort criteria does not differentiate.

11. What rules and strategies come seeded?

    The application has several common picking and put away rules and strategies seeded and ready for use. The strategy search order and strategy assignments still must be defined. Note that seeded rules and strategies cannot be disabled or modified, but can be copied and the copies can be modified. These picking and putaway rules and strategies are seeded in the application and do not depend on any organization or installation specific data. The list of seeded rules and strategies can be found in Appendix B.

12. What if only one range parameter is specified in an effective date?

    The effective dates, assigned to rules within a strategy and strategies within a strategy assignment, have two optional fields for all date type except date type of Always. If both fields are entered, then the effective date is the range indicated, including the two endpoints. If only one parameter is entered, then the date range is treated as effective only up to, or effective beginning at that date, and ending at the end of the sequence for cyclical date types.

    Example: Date type of Full Date, date range of 1/1/2000 - 12/31/2000 means the effective date is every day in the year 2000. If only 1/1/2000 is indicated in the From field, then the effective date begins on the indicated date, and continues indefinitely. Similarly, if only 12/31/2000 is indicated in the To field, then the effective date ends on the indicated date, and is applicable for all dates prior to that date.

    Example: Date type of Day, date of Tuesday indicated on the From field but the To field left blank, assuming the week is defined as beginning on Monday, means that the effective date is from Tuesday to the end of the date type cycle, Sunday.

    If both date parameters are left blank, then the date type acts as if Always were indicated.

13. How do the Oracle Inventory allocation rules relate to rules engine based allocation?

    Oracle Inventory allocation rules are not used when Oracle Warehouse Management is enabled for an organization. Oracle Inventory allocation rules can be modeled with the Oracle Warehouse Management rules engine if the warehouse needs to maintain these allocation rules.

14. What are the differences in transactions when LPNs are allocated?

    When an allocation has been made to the LPN detail level, some features of tasks behave differently.

    • Transactions that invalidate the allocation, such as moving an allocated LPN to a different located are prevented.

    • Cartonization is skipped when an entire LPN is allocated, but is still performed if only pat of an LPN is allocated, assuming that cartonization is setup and enabled for the subinventory.

    • Tasks that allocate LPNs are not merged for bulk picking though they mat still be split on equipment capacity.

    • Allocations for different LPNs are always split into different tasks so that there is either zero or one allocated LPN per task.

    • Allocations are visible on the desktop Transact Move Order window but they cannot be updated if an LPN has been allocated.

15. How does the rules engine know when an LPN is full?

    The rules engine does not have a concept of when an LPN is full or not; however, when using the allocation mode Allocate Entire LPNs Only, the rules engine considers only LPNs which can be entirely consumed by the allocation. So a pallet that is only half full based on the capacity of the pallet could be allocated in this mode, so long as the entire half pallet can be consumed. Note that it is possible, with user-defined expressions, to also encode that the LPN must be “full” in order to allocate it.