WMS Rules Engine Examples

Oracle Warehouse Management Rules Engine Examples An Oracle Topical Essay October 2002; updated October 2004

Oracle Warehouse Management Rules Engine Examples

RULES ENGINE EXAMPLES

This document is a tool to assist implementation of Oracle Warehouse Management, by documenting the seeded rules and strategies and additional rules and strategies that might be helpful for both simple and complex operational requirements. All types of rules are documented, including picking, putaway, cost group, label type, and task type assignment rules. In addition, picking and putaway strategies are documented. The most difficult part of setting up the Rules Engine is not defining the rules in the application, but rather, defining the business logic that needs to be modeled. The rules and strategies contained here can help an implementation team ask the right questions in beginning to define the requirements for the Rules Engine. This document assumes familiarity with the Rules Engine and does not go into the specifics of how to translate the rules and strategies documented here to the system. Please refer to the Oracle Warehouse Management Guide for assistance understanding the basic user interface. Please refer to the Rules Engine chapter of the Oracle Warehouse Management Implementation Guide for detailed explanations of how the Rules Engine functions, including performance and implementation considerations, customization details, and debugging and trouble shooting assistance. Seeded Rules & Strategies

No two warehouses are alike. However, some warehouses have very simple needs that can be modeled by generic rules and strategies that do not refer to any entities defined specifically for that warehouse. For instance, a FIFO/FEFO rule that ensures stock rotation is used by many warehouses, and requires no references to warehouse-specific data. Whenever possible, simple generic requirements have been provided for with seeded rules and strategies. Common picking and putaway rules and strategies have been seeded in the application. To use the seeded strategies, no changes need be made, but rather, all that need be done is define the strategy search order and make the strategy assignments. As these common picking strategies are often applicable for the entire organization, the strategy search order may only require the Source Organization for the picking search order, and the Destination Organization for the putaway search order. Of course, the putaway search order must also include the transaction type object and an assignment of a putaway strategy without any restrictions in the rules to the staging transfer transaction type to indicate that sales order staging transfers are always valid. This assignment must be made for both Internal and Sales Order Pick if both internal sales orders and external sales orders are used. Details

1

on this requirement can be found in the Rules Engine chapter of the Oracle Warehouse Management Implementation Guide. To use the seeded rules, no changes need be made to the rules, but they must be assigned to userdefined strategies, and in turn, these strategies assigned to objects defined in the strategy search order. Seeded rules can also be copied, and the copies modified, to provide even greater flexibility. Additional Examples

Many of the more complex rules that can be used require multiple warehouse-specific restrictions, or additional flexfield or data setup. These will be documented in this guide, with detailed explanations of what the rule does, why each object was used, how the rule could behave differently with slightly different parameters, and what additional setup, if any, is required to make the scenario work. Almost none of these rules and strategies will be able to be used as-is in any given warehouse. However, they will describe some complex scenarios that the Rules Engine can be used to model, many of which at first glance might not appear possible to do without customization. Therefore, these additional examples should prove very helpful to complex implementations where customization is being considered. Performance

All of these rules have been tested functionally, but only some of them have been tested for performance considerations. Therefore, some of the complex rules may provide the correct results and may be fast in a demo environment, but may be unusable in a production environment. Nonetheless, the examples in this document should be helpful in understanding how various complex requirements can be modeled and the different questions that need to be answered when building rules. Whenever performance problems crop up, review the performance section of the Rules Engine chapter in the WMS Implementation Guide. Format

Rather than providing screenshots of the rules and strategies, the rules and strategies will be defined in tabular format. Rules

Rules will be specified in the following format, where LOG is either AND or OR, and OP is the connecting operator such as =, = Actual Transaction Capacity by Units, Volume and Weight S Subinventory/Locator Item on-hand quantity Descending in txn UOM

Transaction Primary Quantity

7

Seeded Putaway Strategies

These strategies can be used as-is within a strategy assignment. No modifications are necessary to make these strategies behave as documented. As the seeded putaway strategies refer to seeded putaway rules, the strategies also determine available locator capacity by the minimum of units, volume, and weight. All seeded strategies allow partial success within the rules. Empty locator

This strategy references a single seeded putaway rule, Empty Locator. The rule puts material away to a locator that is completely empty. All empty locators are considered equally valid, so an empty locator is chosen at random. Strategy Empty Locator Description Any empty locator Rule Empty Locator: Always R Subinventory/Locator Item on-hand quantity =

Constant Number

0

This strategy will perform poorly in large warehouses. A strategy that uses a slightly different rule that performs much more quickly can be defined using the Empty Flag parameter on the locator. However, because the rule requires a periodic concurrent program to run to maintain the Empty Flag parameter, it will be discussed as an additional putaway rule. Minimize fragmentation

This strategy references a single seeded putaway rule, Minimize fragmentation. This rule minimizes fragmentation in the warehouse of a given item by putting that item away to locators where the most of that item is already on-hand. Strategy Minimize fragmentation Description Store like items together Rule Minimize fragmentation: Always S Subinventory/Locator Item on-hand quantity

Descending

Same material status code

This strategy references one seeded putaway rule that puts lot controlled material to a locator or subinventory with the same material status the lot. Strategy Same material status code Description Select sub or loc with same material status as lot Rule Like material status code for lots: Always R Item Lot Status Enabled R AN ( Destination Locator Status Identifier D R OR Destination Status Identifier Subinventory

= =

Constant Character Lot

Y Status Identifier

=

Lot

Status Identifier

)

8

Additional Putaway Rules

More complex putaway rules are documented here. Also, variations of the seeded rules that may not be immediately obvious are also documented. Some of these rules may also require additional setup beyond simply defining the item, such as locator flexfields or lot contexts. The examples documented here should be used as guidelines in defining new rules, and can be particularly helpful in modeling complex requirements. Because these rules are not seeded, specifics that may differ from warehouse to warehouse can be indicated in the rule restrictions. For instance, a subinventory name or item category may be used to make the rule more concrete and easier to understand. Please be sure to use data specific to the warehouse when defining rules. Category based putaway

Specific subinventories or locators may be dedicated to storing particular categories of items. Putaway rules can be built based on the category code that an item is assigned to. For instance, items assigned to the category code MISC may be stored in the BULK subinventory. The following rule models this scenario. Rule Store items with category MISC is subinventory BULK Description Putaway items with category SEGMENT1 of MISC to subinventory BULK R Category Segment1 = Constant Character R AN Destination Subinventory Name = Constant Character D Subinventory

MISC BULK

This rule is basing the putaway location on the category code name only, with the assumption that that category code is not used in multiple category sets. Alternatively, strategies can be assigned to particular category / category set combinations if category is included in the strategy search order. Using the strategy search order, rather than rule restrictions, is suggested if a category belongs to more than one category set. This will also minimize the number of rules in a strategy and thus will help improve performance. Closest empty locator

This rule ensures that the closest empty locator to where the material is already stored is used to store an additional putaway of the material. This rule helps store items in close proximity to other locations where that item is stored, without refilling locations that may be almost empty so that a more accurate FIFO picking can be ensured. Either Cartesian coordinates or locator picking order can define proximity, though Cartesian coordinates will ignore walls and other physical barriers when finding the closest locator. Picking order, however, will sort the locators based on locator picking order only, excluding subinventory picking order. Therefore, if the item is to be stored in multiple subinventories, and proximity by picking order needs to be used, the picking order should be defined so that locator picking order is unique for all locators in an organization, not just for all locators in a subinventory. For instance, suppose there are two subinventories in your warehouse, PICK1 and PICK2. PICK1 comes before PICK2 in the subinventory picking order. Each subinventory has three locators that are sequenced as indicated in the table below. Then the following subinventory and locator picking order should be defined on the subinventory and locator definitions: Subinventory

Sub

Locator

Locator

9

Picking Order

Picking Order 1.1

PICK1

PICK2

1

2

1

1.2

2

1.3

3

2.1

4

2.2

5

2.3

6

Note that in this definition, PICK1 1.3 is considered equally far away from locator 2.1 in subinventory PICK1, and from locator 1.2 in subinventory PICK2. If locators in different subinventories should not be treated as equidistant, then the picking order can be manipulated by leaving gaps. The size of the gap, in comparison to the range of a picking order within a subinventory, will control at which point the Rules Engine will consider locators in other subinventories prior to considering distant locators in the same subinventory. For instance, the locator picking order defined below will ensure that all locators within PICK1 be filled with an item before moving to subinventory PICK2, and vice versa, for a particular item.

Subinventory

PICK1

PICK2

Sub Picking Order

1

2

Locator

Locator Picking Order

1.1

1

1.2

2

1.3

3

2.1

101

2.2

102

2.3

103

The restriction enforces that the locator is empty. Rule Closest empty locator by picking order Description Putaway to closest empty locator by picking order R Subinventory/Locator On-hand Quantity = S Destination Locator Proximity To Locator With Item By Picking Order

Constant Number Ascending

0

Additional restrictions that ensure that the entire load can be put away to that single locator by weight, volume, units, and even dimensions, may also be helpful and can be added. Dedicated item storage

Some warehouses may have dedicated item storage for select items due to user training or historical reasons, or perhaps to capture some type of logic that the Rules Engine cannot easily model. These dedicated locators are defined using the standard Item Subinventory form available from the organization item definition. The Rules Engine will always honor these relationships if the Restrict Subinventories or Restrict Locators flags are checked on the Inventory tab. However, this may be overly restrictive in that user directed moves are not allowed and the staging lanes must be explicitly defined for each item that needs to be shipped. If these flags are left unchecked, then material movement is allowed anywhere in the warehouse, but a rule that suggests putaway to these specific locators can be built. Rule Dedicated item storage

10

Description Putaway to locator defined on item subinventory relationships R Destination Locator Locator Identifier = Item Locator

Locator Identifier

This rule can be combined with additional restrictions or sort criteria to minimize fragmentation, require empty locators, or restrict to a specific subinventory, for instance. Dynamic slotting putaway

Dynamic slotting selects the best locator for an item based on its current or forecasted usage. Fast moving items are placed in more quickly accessed locators, such as the lower racks near the staging lanes, and slower moving items are placed in less easily accessed locators. Several in-between classifications can also be used so that a warehouse or section of a warehouse can be segmented into many different types of locators. With a combination of putaway strategies based on this rule, and picking strategies based on a similar rule, items can be dynamically re-slotted as their classifications change. The dynamic slotting rule takes advantage of ABC compiles and ABC assignment groups to determine the classification of the item, and a descriptive flexfield to determine the classification of the locator. ABC compiles can be made based on forecasted demand, MRP demand, historical usage, current on-hand, or several other criterion. An ABC assignment group is defined by associating a group name with ABC classes. Note that the classes need not necessarily be named A, B, and C; they could be named FAST, MED, SLOW, or H, M, L, or A, B, C, D, and X, for instance. Numeric values, such as 1, 2, and 3, can also be used, and can provide some additional flexibility as described below. Items are then assigned to the classes in the groups based on the ranking the items received in the compile, as controlled by user-indicated breakpoints. Exceptions to the ranking established by the compile can also be made. A locator descriptive flexfield should be given corresponding values, so that, for instance, an A item will be put in an A locator, and a B item will be put in a B locator. For instance, if A items / locators are for high demand items, then perhaps the first two racks of each row would be A locators. Or the bins that are at the end of each aisle, closest to the pickers traveling path, would be A locators, and the locators in the center of each locator would be assigned a value of C, for slow moving items. An experienced warehouse manager should perform this assignment because it requires intimate knowledge of the warehouse layout, problem spots, and sweet spots. Several different options need to be discussed to get a rule that most accurately matches the warehouse requirements. The rule developed below will assume that a locator can hold only one item, but different lots and revisions can be commingled in that locator. As long as an item’s classification has not changed, additional receipts of that item will be putaway to the same locator to minimize fragmentation, capacity permitting. If the locator is full, nearby locators will be selected. However, the item’s classification may change as demand patterns change. These changes would be reflected by periodically updating the item assignments by re-building the ABC compile. This rule will put items away based on the current classification only. Picking rules will be used to clean up items stored incorrectly based on the new classifications. For instance, an item may have been classified as an A item last month, and thus is stored in several A locators. Due to seasonal demand, the item may now be a B item, and so any newly received material will be directed to B locators. The material still residing in the A locators can be allocated for manually created mass moves, or sales order transfers, but will not automatically be moved when the item assignments are updated. Refer to the dynamic slotting picking rule to better understand how this incorrectly stored material can be best allocated.

11

If there are no more locators available with the matching classification for the item, the closest matching locator based on classification will be used. This can more easily be done if numeric classifications, such as 1 to 5, have been used. For instance, if there are no more 1 locators available for items classified as a 1 item, the system will next search for available 2 locators, and so forth. An item will be kept close to other occurrences of it in the warehouse by putting away based on proximity to other locators with the same item. The ABC Assignment Group identifier must be known to build this rule. In the example below, the identifier used is 23. The identifier can be found in MTL_ABC_ASSIGNMENT_GROUPS_V. The second and third restrictions together enforce that the locator is either empty, or contains no other items. The parameter Only Item in Locator is null when the locator is empty or when the locator has mixed contents, but stores the item identifier when there is exactly one item in that locator. This flag is updated on every receipt, but is not updated on issue transactions automatically. Therefore, to keep the parameter up to date in an efficient fashion, the concurrent program Update Locator Capacity should be run periodically. Note that because of the way the parameter is updated, this may occasionally cause the rule to exclude locators do not contain other items, but will not allow the rule to include locators that would violate the rule restriction. The frequency in which the Update Locator Capacity concurrent program should run depends on how often locators get emptied of items and the accuracy required in choosing the best locators, weighed against the system resources that are available. These two restrictions could be replaced by a single restriction using the parameter Number of Other Items in Location, produce the same results, and not require that the concurrent program be scheduled periodically. However, the two restrictions below will make the rule perform several orders of magnitude faster on a large instance because they refer to database columns, while Number of Other Items in Location requires an expensive API call. Rule Putaway items to locators that with same dynamic slotting classification Description Minimize fragmentation, no item commingling, store items in locators with same ABC classification from group id 23 R Destination Locator ATTRIBUTE1 = Expression Select abc_class_name from mtl_abc_classes mac, mtl_abc_assignments maa where maa.abc_class_id = mac.abc_class_id and maa.inventory_item_i d= base.inventory_item_ id and maa.assignment_grou p_id = 23 R AN ( Destination Locator Only Item in Locator = Item Item ID D R OR Subinventory/Locator On-hand quantity = Constant Number 0 ) S Subinventory/Locator Item on-hand quantity Descending S Destination Locator Proximity To Locator Ascending With Item By Picking Order

Of course, sort criteria and restrictions can be modified or added to in order to achieve the exact rule needed for the warehouse, but the bulk of the logic is contained in the first restriction. The rule above will put away only to locators with the identical ABC classification. If there are no locators available with the required classification, however, additional rules in a strategy are necessary to putaway to other locators with similar (but not identical) classifications. The following rule will put

12

away to locators within a range of 1 of the required classification. That is, if the item is classified as 2, this rule will putaway to locators with a classification of 1 or 3. Note that this type of rule requires that the ABC classifications be consecutive integers; alphanumeric classifications cannot be used. Additional rules, expanding the search criteria even further, or perhaps putting away to a different overstock area in the warehouse, can be added to the strategy. Rule Putaway items to locators with dynamic slotting classification within 1 of required classification Description Minimize fragmentation, no item commingling, store items in locators with ABC classification from group id 23 within 1 R Destination Locator ATTRIBUTE1 = Expression Select D (abc_class_name-1) from mtl_abc_classes mac, mtl_abc_assignments maa where maa.abc_class_id = mac.abc_class_id and maa.inventory_item_i d= base.inventory_item_ id and maa.assignment_grou p_id = 23 R AN ( Destination Locator Only Item in Locator = Item Item ID D R OR Subinventory/Locator On-hand quantity = Constant Number 0 ) S Subinventory/Locator Item on-hand quantity Descending Ascending S Destination Locator Proximity To Locator With Item By Picking Order

Again, this rule would likely be used with some variation of the Dynamic Slotting Picking rule to ensure that when items are reclassified, the material stored in old classifications is allocated first to empty out those locators, or perhaps only picked for requisition move orders, but not for sales order staging. Note that any locator with a null value for the descriptive flexfield attribute will not be selected for putaway. If locators with null values are to be selected by a version of this rule, then a restriction that uses the operator IS NULL must be added. Ensure item dimensions defined

Oftentimes, an items’ dimensions will not be defined at the same time the item is defined, either because they are not known with any degree of certainty, or the physical data is not available to the person performing the initial item definition. However, prior to storage in the warehouse, these dimensions may need to be captured. A putaway rule can direct material without dimensions to a specially defined sizing area. A material handler will measure all material in this area, populating the

13

dimensions in the item definition. Dimensioned material can then be putaway from this sizing area to a properly sized locator. This rule will suggest putaway of material without a length, width, and height to the subinventory SIZING. Rule Ensure item dimensions entered prior to put away to storage Description Putaway to SIZING if length, width, or height is not populated R Destination Subinventory Name = Constant Character Subinventory R AN ( Item Length IS D NUL L R OR Item Width IS NUL L R OR Item Height IS NUL L

SIZING

)

Additional restrictions can be added to ensure that the dimension unit-of-measure, weight, weight unit-of-measure, volume, and volume unit-of-measure are all populated as well. Ensure locator dimensions large enough

Putaway of some items, such as pipes, require locators of specific sizes, beyond verification of the item weight and volume in comparison to that of the locator. The Rules Engine does not explicitly check the dimensions of the item in comparison with those of the locator when allocating space for a putaway. However, these sizing restrictions can be modeled the Rules Engine if necessary. This rule verifies that the dimensions of the item can fit within the dimensions of the locator. Rule Locator dimensions must be large enough for item, no rotation, assuming same UOM Description Restrict putaway to locators large enough by width, height, and length R Destination Locator Width >= Item R AN Destination Locator Length >= Item D R AN Destination Locator Height >= Item D

Width Length Height

Of course, sort criteria can be added, choosing the smallest locator by width, length, height, or total volume that is still large enough for the entire load to achieve a best-fit putaway. Note that no unit-of-measure conversion is performed, so the dimensions of the locator must be in the same unit-of-measure as that of the item. Also, this does not consider rotating the item. Suppose that the item can be rotated horizontally, so that the width and length are interchangeable. Perhaps the item is a large ATM that is sitting on a pallet that can be entered from the front or the side. However, the item cannot be rotated vertically. Then the following set of restrictions will ensure the dimensions of the locator are large enough, while still allowing this rotation: Rule Locator dimensions must be large enough for item, rotating horizontally, assuming same UOM Description Restrict putaway to locators large enough by width, height, and length, while allowing width and length to be switched R ( Destination Locator Width >= Item Width R AN Destination Locator Length >= Item Length ) D R OR ( Destination Locator Width >= Item Length R AN Destination Locator Length >= Item Width ) D R AN Destination Locator Height >= Item Height D

Of course, the rule can also be defined to allow vertical rotation only, or both vertical and horizontal rotation, by adding additional clauses. Furthermore, perhaps only the width of the item in comparison

14

to the locator is important; the rule can be simplified by removing the restrictions that are not necessary or relevant. If it cannot be assured that the dimensions of the locator and the dimensions of the item are not in the same unit-of-measure, explicit conversions can be made. The following rule does not attempt to rotate the item, but checks all three linear dimensions. The last restriction is necessary so that the rule will compile. Please refer to the Rules Engine chapter of the WMS Implementation Guide for more details on this requirement. Rule Locator dimensions must be large enough for item, no rotation Description Restrict putaway to locators large enough by width, height, and length R Destination Locator Width >= Expression

R AN D

Destination Locator

Length

>=

Expression

R AN D

Destination Locator

Height

>=

Expression

R AN D

Item

Item Identifier

=

Item

inv_convert.inv_um_ convert(null, null, unit_width, msi.dimension_uom_ code, base.dimension_uom _code, null, null) inv_convert.inv_um_ convert(null, null, unit_length, msi.dimension_uom_ code, base.dimension_uom _code, null, null) inv_convert.inv_um_ convert(null, null, unit_height, msi.dimension_uom_ code, base.dimension_uom _code, null, null) Item Identifier

These types of rule would most typically be used when either only a single dimension is important, such as length for piping, or when only a single unit of an item can fit in a locator at a time and the best fitting locator should be selected, such as an ATM. The Rules Engine tracks locator capacity by total volume, total weight, and total units (or any combination thereof). The Rules Engine does not cube out the space, however. Therefore, these types of rules may not work well for selecting the best locator when multiple different sized items are to be stored in the same locator. Freight carrier based staging lane selection

Sales order picking tasks can be directed to different staging lanes based on the freight carrier / shipment method on the order line, or based on any number of other order attributes such as customer name or shipment priority code. The staging subinventory must be provided in the Shipping Parameters form. However, the staging lane (or rather, locator within that staging subinventory) need not be specified in that form or during pick release. If the staging lane is left blank in the Shipping Parameters form and in the Pick Release rule, and if trip/dock door appointments are not being used to automatically select the correct staging lane, then the Rules Engine can select any staging lane within the staging subinventory. Suppose two parcel carriers are used by the warehouse: DHL and UPS, three staging lanes, named STAGE.DHL, STAGE.UPS, and STAGE.OTHER have been set up, and the second segment of the locator key flexfield is called Rack. Then the following rule can be used to ensure that sales order lines get staged in the lane corresponding to the line shipping method code. Lines with different shipment methods, or without shipment methods, will get staged in STAGE.OTHER. 15

Rule Stage material in lanes DHL, UPS, and OTHER based on sales order line shipping method Description Sales orders lines with shipping method DHL and UPS go into lanes with Rack named same; others to OTHER lane R Destination Locator Rack = Sales Order Line Shipping Method Code R OR ( Destination Locator Rack = Constant Character OTHER R AN Sales Order Line Shipping Method Constant Character DHL D Code R AN Sales Order Line Shipping Method Constant Character UPS ) D Code

The exact same logic can be defined using one fewer restrictions taking advantage of the database operator IN / NOT IN, as follows: Rule Stage material in lanes DHL, UPS, and OTHER based on sales order line shipping method Description Sales orders lines with shipping method DHL and UPS go into lanes with Rack named same; others to OTHER lane R Destination Locator Rack = Sales Order Line Shipping Method Code R OR ( Destination Locator Rack = Constant Character OTHER R AN Sales Order Line Shipping Method NOT Expression ‘DHL’,’UPS’ ) D Code IN

Note that the first restriction requires that the value for Rack in each staging lane correspond exactly to the Shipping Method Code indicated on the sales order line, and that the Rack segment on the locator key flexfield be defined as a varchar. Because different groups may be responsible for defining and maintaining this data, and because relationships with carriers may change over time, more generic staging lanes can be set up, as in the following example. Suppose that instead of the three lanes defined above, there are three lanes named STAGE.1 – STAGE.3 that are used for DHL, UPS, and other shipping methods, respectively. Then the following rule will ensure that sales order lines get staged in the lane corresponding to the line shipping method code. Rule Stage material in lanes 1, 2, and 3 based on sales order line shipping method Description Sales orders lines with shipping method DHL to lane 1, UPS to lane 2, other to lane 3 R ( Destination Locator Rack = Constant Number 1 R AN Sales Order Line Shipping Method = Constant Character DHL D Code R OR ( Destination Locator Rack = Constant Number 2 R AN Sales Order Line Shipping Method = Constant Character UPS D Code R OR ( Destination Locator Rack = Constant Number 3 R AN Sales Order Line Shipping Method Constant Character DHL D Code R AN Sales Order Line Shipping Method Constant Character UPS D Code

) )

)

These rules need not specify the subinventory name, because the staging subinventory name will always be stamped on the move order by the pick release process prior to the Rules Engine selecting a staging lane. This means that the subinventory that is indicated on the pick release rule, or on the Shipping Parameters form if left blank during pick release, must be the subinventory with these staging lanes; otherwise, sales order lines will backorder because the Rules Engine will be unable to find a putaway location acceptable to both the pick release process and the rule logic. Similarly, the locator must not be indicated on the pick release process, either as part of the pick release rule or on the Shipping Parameters form. These rules used the shipping method code on the sales order line. The shipping method code might be indicated on the sales order header instead, or perhaps on both. Variations of the rule can be defined that honor one or the other, or perhaps check for a shipping method code at the line level first, and only then check at the header level only if none is provided on the line. For instance, in the following rule, the shipping method on the header is used only if the shipping method on the line is null. This rule would be combined with other rules for UPS and the miscellaneous staging lane in a multi-rule strategy.

16

Rule Stage material in lane 1 if shipping method code is DHL on sales order line or header, using more specific value Description Stage material in lane 1 if shipping method code is DHL on the sales order line, or if not on line, on header R Destination Locator Rack = Constant Number 1 R AN ( Sales Order Line Shipping Method = Constant Character DHL D Code R OR ( Sales Order Line Shipping Method IS Code NUL L R AN Sales Order Header Shipping Method = Constant Character DHL ) D Code )

These rules could also be broken up into multiple rules within a strategy without any change in behavior because the different clauses in the rule are mutually exclusive; an order line has only one shipping method. If one scenario occurs much more frequently than the other, then the Rules Engine will perform faster if the more common scenario is listed first as a separate rule. Even if the scenarios occur with roughly the same frequency, or the frequency of the different scenarios is not known, the rule should still be broken up into multiple rules in a strategy to reduce the complexity of the query required by the database. For instance, the rule above should be rewritten as a three-rule strategy as follows: Strategy Name Stage material in lanes 1, 2, and 3 based on sales order line shipping method Strategy Description Sales orders lines with shipping method DHL to lane 1, UPS to lane 2, other to lane 3 Rule Name Stage material in lane 1 for DHL (Always) R Destination Locator Rack = Constant Number 1 R AN Sales Order Line Shipping Method = Constant Character DHL D Code Rule Name Stage material in lane 2 for UPS (Always) R Destination Locator Rack = Constant Number 2 R AN Sales Order Line Shipping Method = Constant Character UPS D Code Rule Name Stage material in lane 3 if shipping method code is neither DHL nor UPS (Always) R Destination Locator Rack = Constant Number 3 R AN Sales Order Line Shipping Method Constant Character DHL D Code R AN Sales Order Line Shipping Method Constant Character UPS D Code

Other common scenarios that can be modeled with these types of rule might be based on the shipping priority code, order type, or any of the flexfields, defined on the sales order header or sales order line. Of course, the above putaway rules, as well as any other putaway rule based on the sales order header or sales order line will only produce suggestions when the putaway is for a sales order, but not during putaway during receiving or replenishment putaway. Job completion locator

With tight integration between Oracle Work in Process and Oracle Warehouse Management, completions can be performed directly into LPNs and the Rules Engine can be used to determine where to put the newly completed material away to. Oftentimes, a completion subinventory and locator is defined on the routing, and the putaway should be directed to this locator first. The following rule will direct putaway of LPNs from a job to the completion subinventory and locator defined on that job. Note that although this information is taken from the job, it is defaulted on the job from the routing when the job is first defined. Therefore, if the operator has altered the completion subinventory or locator for some jobs for a particular reason, this latest up-to-date data will be used for the putaway. Rule Put completed assemblies to completion sub / loc defined on job Description LPNs created via LPN-based completions are directed to the completion sub / loc on the job, defaulted from routing R WIP Job Completion Locator = Destination Locator Locator Identifier Identifier

17

This rule would then typically be assigned to a strategy. The strategy could then be assigned to the transaction type of WIP Assembly Completion, assuming that transaction type is an object in the putaway strategy search order. By using this object in the strategy search order, different putaway strategies could be used for putaway from purchase order receipt, putaway from manufacturing completion, and putaway for sales order staging transfer. If a capacity is defined for the locator, or the locator is otherwise not available because it is assigned to a material status that places it on hold, then the system will not be able to suggest a putaway location and thus the operator will be unable to put away the LPN, which is still in WIP, to inventory. To circumvent this problem, the strategy may have a second rule that directs the material to a special subinventory. In addition, the Rules Engine provides flexibility beyond simply putting completed LPNs to the defined completion locator. For instance, if each completion is pallet and requires its own locator, a rule can be built that can direct completions to empty locators, but only within the subinventory defined on the routing / job as the completion subinventory. Again, this would typically be used in a strategy that includes additional rules to determine where to put the LPN if no locators in the expected subinventory are available. Rule Put completed assemblies to completion sub / loc defined on job Description LPNs created via LPN-based completions are directed to the completion sub / loc on the job, defaulted from routing R WIP Job Completion = Destination Subinventory Name Subinventory Subinventory R AN Subinventory/Locator On-hand Quantity = Constant Number 0 D

The second restriction enforces that the locator is empty. License plate number based putaway

Different pallets may be required to be directed to different areas based on some logic not easily modeled by the Rules Engine, but which the receiver can accurately capture. Several series of pregenerated LPNs can be created and labels can be pre-printed. The putaway logic can be based on attributes of these LPNs, such as LPN prefix, LPN suffix, or LPN volume or weight. For instance, suppose that some pallets are sealed with shrink-wrap, while other pallets are strapped and enclosed in a large corrugated cardboard box. Because the wrap is easier to break, the warehouse may wish to direct the shrink wrapped pallet to a case area or a forward picking area to be broken down, while the strapped and boxed pallet should be directed to a bulk storage area where it might be able to be sold without performing any repackaging. The system has no way to recognize that these different pallets are packed differently because they may contain the same quantity, be from the same supplier, and be identical in all other aspects. Therefore, two rolls of LPN labels can be pre-generated via the desktop concurrent request. One roll will have the suffix B on the license plate number, indicating bulk storage, while the other roll will have the suffix C to indicate case storage. The receiver, knowing that the label used will control where the material is directed, will label the pallets with pre-generated label from one of the two rolls based on the packing configuration. The following rule will put LPNs with the suffix B to a subinventory named BULK. A similar rule can be defined for C and CASE. Rule LPNs with suffix B putaway to BULK Description LPNs with name like %B are putaway to subinventory BULK R License Plate License Plate Number LIK Constant Character

%B

18

R AN D

Destination Subinventory

E Subinventory Name =

Constant Character

BULK

These restrictions would probably be combined with additional restrictions or sort criteria that minimize fragmentation, or perform other optimizations. Similarly, putaway logic can be based on a combination of the prefix and suffix. Note, however, that because this uses the database operator LIKE, there is no way to recognize that the suffix B is different from, say, the suffix EB; both suffixes would match %B. Therefore, make sure that any suffixes or prefixes you use are distinct. Limited quantities of hazardous items stored inside

Some organizations may have policies that prevent storage of large quantities of hazardous materials within the warehouse. For instance, due to safety requirements, no more than 1000 gallons of chlorine can be stored in various subinventories throughout the warehouse. Any receipts that will drive on-hand over that limit must be stored outside the warehouse in an overstock subinventory. This requirement is surprisingly complex, so the rule to model the requirement as stated will be built in stages. The following rule comes close to modeling the stated requirement. Rule Store any excess of 1000 of item in subinventory OVERSTOCK Description If more than 1000 (primary UOM) units of item are in organization, store additional quantity in sub OVERSTOCK R Destination Quantity On-Hand >= Constant Number 1000 Organization R AN Destination Subinventory Name = Constant Character OVERSTOCK D Subinventory

Whenever the organization has more than 1000 on-hand, any additional material will be directed to the OVERSTOCK subinventory. Note that the quantity on-hand that is used in the calculation is the current quantity, prior to the suggestion. Therefore, if there are 900 gallons currently on-hand, a putaway of 200 gallons will be not be directed to OVERSTOCK by this rule. After those additional 200 have been received, the on-hand quantity will be 1100, and any subsequent putaways will be directed to OVERSTOCK. Furthermore, as this rule is based on the total on-hand quantity in the warehouse, it includes the quantity stored outside in OVERSTOCK. Therefore, even if the subinventories inside the warehouse are emptied, material will continue to be sent to OVERSTOCK so long as the total on-hand in the warehouse is greater than 1000. Suppose that, instead of being stored in multiple subinventories within the warehouse, the item can only be stored in one subinventory, HAZMAT, inside the warehouse, and one subinventory, OVERSTOCK, outside the warehouse. Then the following putaway strategy will direct to HAZMAT until a putaway places HAZMAT above 1000 gallons, regardless of the quantity already stored in OVERSTOCK. Strategy Direct all additional receipts to OVERSTOCK once HAZMAT has quantity on-hand greater than 1000 Description As soon as HAZMAT has over 1000 units, direct additional material to OVERSTOCK Rule Direct material to HAZMAT as long as current HAZMAT on-hand is less than 1000: Always R Destination Quantity On-Hand < Constant Number 1000 Subinventory R AN Destination Subinventory Name = Constant Character HAZMAT D Subinventory Rule Direct material to OVERSTOCK: Always R Destination Subinventory Name = Constant Character OVERSTOCK Subinventory

A strategy is required here because there is a strict preference to placing new material to HAZMAT before OVERSTOCK, so long as HAZMAT has less than 1000 units presently on-hand.

19

A variation of the above rule using a SQL expression can prevent the quantity in the HAZMAT locator from ever exceeding 1000 gallons, including the suggested quantity. That is, in the example above, 200 gallons were be directed to HAZMAT when the current on-hand quantity is 900. The following strategy would direct all 200 to OVERSTOCK because the total on-hand after the suggestion would exceed the limit of 1000. Strategy Direct all additional receipts to OVERSTOCK if they would force HAZMAT over 1000 units Description All receipts that will put HAZMAT above 1000 units directed to OVERSTOCK Rule Direct material to HAZMAT as long as this putaway will not force HAZMAT above 1000 units: Always R Destination Quantity On-Hand = Actual Transaction Txn Primary Qty Capacity by Volume and Weight

Finally, a single restriction rule can be used that bases capacity on weight, volume, and units, as follows: Rule Locator must have enough capacity by weight, volume, and units for entire load Description Restrict putaway to locators with sufficient capacity by weight, volume, and units for entire putaway R Subinventory/locator Minimum Available >= Actual Transaction Txn Primary Qty Capacity by Units, Volume and Weight

As before, these restrictions can be expressed as a sort criteria instead, or as a combination of restriction and sort criteria to achieve a best fit. They may also be combined with other restrictions to ensure that different lots or items are not commingled, or that putaways are directed only to particular subinventories. The actual transaction object contains information relevant to the transaction at hand. Two attributes return the quantity of the transaction: transaction primary quantity, and transaction quantity. The primary quantity attribute gives the transaction quantity in the default (or primary) unit-of-measure defined for the item on the item master. The quantity attribute gives the transaction quantity in the unit-of-measure entered at the transaction time. The minimum available capacity attributes, however, return the available capacity in terms of the primary unit-of-measure of the item.

24

Rejected material to MRB subinventory

Inspection is an optional process during receiving, and is controlled by the receipt routing. WMS requires that material that fails inspection be split into a different LPN then the material that passes inspection. Rejected material can then be putaway to different places in the warehouse for further action. Rejected material should be directed to a special MRB (material review board) subinventory. Rule Rejected material to MRB subinventory Description Direct material that fails receiving inspection to the MRB subinventory R Actual Transaction Inspection Status = Constant Number R AN Destination Subinventory Name = Constant Character D Subinventory

3 MRB

Of course, the rest of the putaway rules should be built so that material that is not rejected is not putaway to the MRB subinventory. Three values are used for the Inspection Status as follows: Status

Meaning

1

Awaiting inspection

2

Accepted

3

Rejected

The rule can be based on either a value of 2 or 3; a value of 1 is not applicable in that the system will not allow putaway of an LPN that is still awaiting inspection until that inspection has been completed. If the item does not require inspection, then the inspection status will be left null. Also, note that this inspection status is applicable only to the standard inspection process performed via the inspection routing receipt. If Mobile Quality is used for inspection to collect a quality plan, then different objects or customer expressions are necessary. Stacking pallets within single locator

A particular locator may be able to fit several pallets or loads of an item, but can be stacked on top of other pallets of the item only if those other pallets provide a level surface. That is, only if the pallets in the locator have not yet been used, or perhaps if the pallets have been used but the top layer of the pallet provides a flat surface. For instance, a pallet of sand bags may be stacked so that there are 7 bags per layer on each pallet, and 6 layers in a pallet for a total of 42 bags. Additional pallets can be stacked on top of any pallet, so long as the top layer of the pallet is a complete layer. That is, as long as there is a multiple of 7 bags in the locator, another pallet can be placed there as well. Or perhaps new pallets can only be stacked on top of other full pallets, so that a locator with this item can be used only if there are a multiple of 42 bags in the locator. The following rule places a pallet of an item into a locator only when that locator contains an even multiple of the item. The quantity to use as the multiple is defined as a flexfield on the item definition. This rule ensures that the entire load, based on volume, weight, and unit capacity, can be put away to this single locator to maximize the operator efficiency. It also ensures that the locator contains no other items other than that which is being put away. The sort criteria also means that the load will be put away to empty locators, if necessary.

25

The second and third restrictions together enforce that the locator is either empty, or contains no other items. The parameter Only Item in Locator is null when the locator is empty or when the locator has mixed contents, but stores the item identifier when there is exactly one item in that locator. This flag is updated on every receipt, but is not updated on issue transactions automatically. Therefore, to keep the parameter up to date in an efficient fashion, the concurrent program Update Locator Capacity should be run periodically. Note that because of the way the parameter is updated, this may occasionally cause the rule to exclude locators that do not contain other items, but will not allow the rule to include locators that would violate the rule restriction. The frequency in which the Update Locator Capacity concurrent program should run depends on how often locators get emptied of items and the accuracy required in choosing the best locators, weighed against the system resources that are available. These two restrictions could be replaced by a single restriction using the parameter Number of Other Items in Location to produce the same results, and not require that the concurrent program be scheduled periodically. However, the two restrictions below will perform several orders of magnitude faster on a large instance because they refer to database columns, while Number of Other Items in Location requires an expensive API call. Rule Must be able to stack pallet on top of existing material in the warehouse Description Restrict putaway to locators with an even multiple of the item based on an item attribute R Subinventory/locator Minimum Available >= Actual Transaction Txn Primary Qty Capacity by Units, Volume and Weight R AN ( Destination Locator Only Item in Locator = Item Item ID D R OR Subinventory/Locator Quantity on-hand = Constant Number 0 R AN Subinventory/locator Item on-hand quantity = Expression inv_convert.inv_um_ D convert( mptdtv.inventory_ite m_id, null, floor ( WMS_Parameter_PV T.GetItemOnHand ( base.ORGANIZATI ON_ID, mptdtv.INVENTOR Y_ITEM_ID, base.SUBINVENTO RY_CODE, base.LOCATOR_ID, msi.PRIMARY_UO M_CODE, msi.PRIMARY_UO M_CODE ) / msi.attribute1 ) * msi.attribute1, msi.PRIMARY_UO M_CODE, mptdtv.transaction_u om, null, null) S Subinventory/locator Item on-hand quantity Descending

)

This rule would typically be used as part of strategy with additional rules that direct the material to other locators or empty locators if a locator that can be stacked cannot be found. Stacking single item across multiple racks

Warehouse locations are often defined by a three segment row / rack / bin designation. In some subinventories, it may be important to stack an item in a single row and bin, but across multiple racks, so that overstock can be easily found in a vertical “stripe”. For instance, the first time an item is

26

received into a subinventory, it should be placed in the lowest empty rack. The next time it is received (assuming the first pallet is still on-hand), it should be placed in a rack directly above the first pallet. Similarly, the third receipt should be directed to the third rack in the some row and bin. This can be accomplished by using the locator Cartesian coordinates to represent locator proximity. The x, y, and z coordinates must be defined so that all locators within a single row and bin, but across multiple racks, should be considered by the system to be in exactly the same physical location. For instance, suppose this putaway logic is to be used within a single subinventory, PICK. There are three racks, two aisles, and two bins, for a total of twelve locators, as follows: Locator

X

Y

Z

1.1.1

1

0

1

1.2.1

1

0

1

1.3.1

1

0

1

2.1.1

2

0

1

2.2.1

2

0

1

2.3.1

2

0

1

1.1.2

1

0

2

1.2.2

1

0

2

1.3.2

1

0

2

2.1.2

2

0

2

2.2.2

2

0

2

2.3.2

2

0

2

Note that the x-coordinate is equal to the row, the z-coordinate is equal to the bin, but the y-coordinate is always zero. Therefore, all three locators in the first row / bin are a distance of zero between each other, as calculated by the Rules Engine when Cartesian coordinates are used. The rule needs restrictions to ensure that only subinventory PICK gets picked up, and only empty locators are selected. A sort criteria ensures that the racks are filled in ascending order. The restriction that proximity by Cartesian coordinates equals 0 ensures that material is stored in a single rack. However, if the material is not yet stored in the warehouse, the parameter Proximity To Locator With Item By Coordinates cannot calculate a value (it will return a value of 999,999,999). Additionally, if the item is stored elsewhere in the warehouse, the system will calculate the distance to that other location, and that value may be neither 0 nor 999,999,999. Therefore, the rule must also check if the on-hand quantity of the item in the subinventory is 0, and if so, start at the first rack. Rule Stacking single item across multiple racks in subinventory PICK Description Putaway item to single row / bin combination but multiple racks R ( Destination Locator Proximity To Locator = Constant Number With Item By Coordinates R OR ( Destination Quantity On-Hand = Constant Number Subinventory R AN Destination Locator Rack = Constant Number D R AN Subinventory/Locator On-hand quantity = Constant Number D R AN Destination Subinventory Name = Constant Character D Subinventory S Destination Locator Rack Ascending

0 0 1

) )

0 PICK

Note that this rule takes advantage of nested parentheses. Parentheses can be nested several levels deep in a rule definition to model complex logic.

27

Note that if an item is not already on-hand in the subinventory, then the first rack will be used to store the item. Therefore, if all the racks at the first level are full, then this rule will not put any additional material in that subinventory. However, if the upper racks, but not the first rack, have material in them, then a new item can be placed in that first rack. Therefore, material should be consumed from highest rack down to lowest rack in order to ensure that only one item at a time can be placed in a vertical stripe. Also, this rule will only allow an item to be placed in a single vertical; once all three racks in a single row / bin have that item in it, all other locators will fail the restrictions. Therefore, this rule would typically be part of a multi-rule strategy that designates where additional material should be stocked. Subsequent rules might be less restrictive on proximity in that subinventory, including proximity as a sort criteria rather than a restriction. Variations of this rule can segment subinventories further, so that, for instance, only the upper racks are used for this type of overstock storage and different items are stored in the lowest racks. Modifying the way the Cartesian coordinates have been set up can also create other types of striping. Supplier based putaway

Material from some suppliers may need to be putaway separately, or at least temporarily directed to a different subinventory than other suppliers’ material due to quality, inspection requirements, or other business processes. Putaway rules based on suppliers can be built to model this requirement. Note that this type of requirement can only be modeled during the initial putaway from receiving; as Oracle does not store the supplier with the on-hand material after it is received into inventory, subsequent material movements cannot be based on the supplier. This rule puts material received from supplier Acme Industries to a quality control area, QC STAGE, where it will wait for additional action. Rule Material from supplier Acme Industries to QC STAGE Description Putaway material received from supplier Acme Industries to subinventory QC STAGE R Supplier Vendor Name = Constant Character Acme Industries R AN Destination Subinventory Name = Constant Character QC STAGE D Subinventory

Putaway logic can be based on different attributes of the supplier, as well as attributes of the supplier site. For instance, perhaps all material received from a particular country must be putaway separately, or perhaps suppliers in another country use a different pallet type and their material must be repalletized in a special packaging area prior to putaway to final storage. Transaction unit-of-measure putaway

An item may be received in different units-of-measure. The receiver may perform the receipt transaction indicating eaches, cases, or pallets depending on how the material has been packed (assuming that conversions to the item’s primary unit-of-measure for all the units-of-measure have been defined already). The transaction unit-of-measure can determine where the material is put away from the initial receipt transaction. Note that once the material is in inventory, the on-hand quantity is always stored in the primary unitof-measure of the item, so transaction unit-of-measure based putaway will only work for putaway from receiving.

28

Suppose a CS unit-of-measure has been set up and defined for an item. CS receipts are to be directed to the CASE subinventory. Other rules in the strategy may be defined to direct material received in Ea to the EACH subinventory, or material received in PAL to the BULK subinventory. This rule models the scenario for CS and CASE: Rule Direct CS receipts to CASE subinventory for putaway from receipt Description Direct material to CASE based on transaction UOM of CS R UOM Transaction UOM = Constant Character Code R AN Destination Subinventory Name = Constant Character D Subinventory

CS CASE

Volume of container item

The available volume on the locator is kept current on every transaction with the volume of the items that reside in that locator, not the volume of the container item. For instance, if a pallet of 20 items, each sized 1 ft3 were put away to a locator, the available volume in that locator would decrease by 20 ft3. However, the pallet’s volume is not considered in the available capacity of the locator. So if the footprint of the pallet consumed, say, 30 ft3, there would be a discrepancy between the volume truly available, and the volume the system believes is available. If the container items have non-trivial sizes, this can be addressed in one of several ways, all via custom rule restrictions. Alternate approaches that address this limitation via a custom quantity function are also possible. But first, several assumptioms must be defined. The volume that will be considered as the volume of consumed by the material could be the volume of the items (as is currently the case), the volume of the container items, or a maximum of the volume of the container item and the contents. The latter, though the most complicated, may also be the most accurate for two reasons: if a container item is not assigned to an LPN, then there is no volume to fall back on other than the volume of the contents, and the volume of the container item may be defined as a container on which you stack items (i.e.: a wooden pallet) or a container into which you pack items (i.e.: a drum). Also, in the first approach below, the volume that will be considered is the liquid volume, in that the space will not be “cubed out”. For instance, a 3x3x3 locator can hold 3 2x2x2 items by liquid volume (33/23>3), yet only one of those 23 items can fit in there if it is, in fact, a solid item. The following rule with a custom restriction puts away an LPN to a locator if the volume capacity of the locator is sufficient for the container item being put away, taking into consideration only the volumes of the container items already in the locator. Rule Direct Consider LPN container item volume when putting away Description Only put away into locator where available volume considering current container items & this container item is sufficient R License Plate License Plate Number = Expression select wlpn.license_plate_n umber from mtl_system_items msilpn, mtl_item_locations millpn where msilpn.inventory_ite m_id = wlpn.inventory_item_ id and msilpn.organization_i d= wlpn.organization_id and

29

decode(mptdtv.type_ code,1,NVL(mptdtv.t o_locator_id,base.loc ator_id),2,base.locato r_id) = millpn.inventory_loca tion_id and mil.max_cubic_area > nvl(msilpn.unit_volu me,0) + (select nvl(sum(nvl(msiall.u nit_volume,0)),0) from mtl_system_items msiall, wms_license_plate_n umbers wlpnall where wlpnall.lpn_id in (select distinct wlpnall.lpn_id from mtl_onhand_quantitie s_detail moqdall, wms_license_plate_n umbers wlpnall where moqdall.locator_id = decode(mptdtv.type_ code,1,NVL(mptdtv.t o_locator_id,base.loc ator_id),2,base.locato r_id) and moqdall.lpn_id = wlpnall.lpn_id) and wlpnall.inventory_ite m_id = msiall.inventory_item _id and wlpnall.organization_ id = msiall.organization_i d)

Note that this restriction is incomplete, in that it does not yet handle the following common scenarios, though it should provide a framework for a complete restriction: •

Does not handle UOM conversions, in that the locator capacity or container item volume may be stored in different UOMs

•

Does not handle if the LPN container item is null, or the container item volume is null or 0, other than treating it as a 0 volume

•

Does not handle pending putaways that are already suggested, or loaded tasks for which a container item may have been removed but not yet dropped to the destination locator

All these limitations can be addressed by a more complete custom rule restriction. Alternatively, a much simpler custom rule restriction can be used if the restriction is instead based on just the number of LPNs in the locator under consideration, which would be reasonable if the locators (for which the rule applies) are all roughly similar in size, and the container items are similarly roughly equivalent in size. If, instead, there are several different LPN container item sizes, with different combinations of each possible in any given locator among a group of similarly sized locators, a custom user-defined table can be pre-defined to enumerate all possible combinations of container items that can fit in that

30

locator, and a custom rule restriction – or even a custom PL/SQL function called by such a rule restriction – can be defined to compare the LPN and locator under consideration with the current contents of the locator.

31

Seeded Picking Rules

These rules can be used as-is within a user-defined strategy. No modifications are necessary to make these rules behave as documented. 30-day range FEFO min pick task

This rule attempts to deplete locators that are almost empty, but only selecting lots with less than 30 days of life left before expiration. Because the allocation mode honors the pick unit-of-measure, the full units-of-measure of a given lot will be allocated first. The restriction on the Shelf Life Control Code ensures that this rule will only allocate items that are expiration date controlled. Note that this rule restriction ensures that only lots with at most 30 days of life remaining are allocated; implicit is the restriction that only lots that have not yet expired should be allocated. The Rules Engine will never allocate an expired lot, even if other restrictions point to only that lot. Rule 30-day range FEFO min pick task Description Lots with less than 30 days life order to deplete locators, use pick UOM Allocation Mode: No LPN Allocation, Prioritize Pick UOM R Lot Expiration Date