1 Order Orchestration Routing Engine Overview
Overview: Order Orchestration provides a gateway to inventory availability across all sales channels. When used with a call center, store point-of-service, ecommerce, or other customer-facing application, Order Orchestration enables you to offer your customers multiple purchasing options, such as store pickup. You can use Order Orchestration’s Routing Engine module to automatically select the best location to fulfill customer orders across the enterprise, and to track customer orders from creation through fulfillment. In addition, with Order Orchestration’s statistical data, you can optimize inventory disbursement to ensure appropriate stock levels in each salable location.
About Supplier Direct Fulfillment: See the Supplier Direct Fulfillment Overview.
About Store Connect: See the Store Connect Overview.
In this topic:
-
Importing Items/Products, Inventory, Barcodes, Images, and Locations into the Database
The Routing Engine
Overview: Use Order Orchestration’s Routing Engine module to:
-
determine whether products are available across the enterprise
-
select the best location to source an order or line, either automatically based on criteria that you set for the enterprise, or by providing a list of possible locations
-
help the customer select a location where s/he can pick up an order
-
create orders across the enterprise
-
notify locations about assigned orders
-
track order or line status
In this topic:
-
Using Product Availability Search for a Pickup or Delivery Order
- Reviewing or Updating Order Orchestration Orders
Types of Orders
The types of orders that the Routing Engine supports are described briefly below.
-
Important:
When you create a new organization in Order Broker 20.0 or higher, ship for pickup orders are automatically enabled, and in this case retail pickup and ship-to-store orders are not supported. When you update to Order Broker 21.0 or higher, ship for pickup orders are automatically enabled in all existing orders, and in this case retail pickup and ship-to-store orders are converted to ship-for-pickup orders.For more information: See About Ship-for-Pickup Orders for background.
Delivery Order
The Routing Engine can select a location to ship an order to the customer, or staff can designate a location. You would typically use this option to ship an order even though the desired products are backordered in the originating location.
Example 1: The customer wants to buy a product from a retail location, but the product is out of stock. The location submits the order to the Routing Engine, specifying that the order be shipped directly to the customer from a nearby distribution center.
Example 2: The customer orders a product on the web storefront. Since the product is currently backordered in the warehouse, the order management system submits the order to Order Orchestration for fulfillment. The Routing Engine automatically selects a location to fulfill the order, and the selected location ships the product directly to the customer.
Pickup Order
A location submits a pickup order to the Routing Engine when the customer has already selected a location where s/he would like to pick the order up and where the inventory is available. You would typically use this option to enable the customer to pick up the order at a nearby store that already has the inventory on-hand rather than wait for shipment.
Example: The customer contacts the call center to see if a product can ship from the warehouse. Since the product is currently backordered in the warehouse, the CSR helps the customer select a nearby store where the product is currently in stock, so the customer can pick it up there.
Ship For Pickup Order
A ship-for-pickup order is one that the customer picks up at a designated location, and that can have a separate placing, sourcing, and pickup location, although any two of these locations can be the same.
Example 1 (three different locations): The customer places an order on the web site (location A) and wants to pick the order up at location B. The Routing Engine “shops” the order and selects location C as the sourcing location. Location C ships the inventory to location B, where the customer can pick it up.
Example 2 (placed location and pickup location are the same): The customer places an order at location A and also wants to pick the order up at location A. The Routing Engine “shops” the order and selects location B as the sourcing location. Location B ships the inventory to location A, where the customer can pick it up.
Example 3 (sourced location and pickup location are the same): The customer places an order by phone (location A) and wants to pick the order up at location B. When the order is submitted to the Routing Engine, the requested item is available at location B, so it is selected as the sourcing location. Once the order is ready at location B, the customer picks it up.
This order flow resembles the pickup order.
Example 4 (placed location and sourced location are the same): The customer places an order by phone (location A) and wants to pick the order up at location B. The distribution center has the inventory available, and ships it to location B. Once the order is ready at location B, the customer picks it up.
The pickup location for a ship-for-pickup order must be specified in advance, and cannot be changed. The sourcing location can also be specified in advance, or the Routing Engine can select the sourcing location. If the selected sourcing location cannot source the order, then the order can be “reshopped” so that another sourcing location is assigned.
Summary of Order Types
The different types of orders are summarized below.
Important:
When you create a new organization in Order Broker 20.0 or higher, ship for pickup orders are automatically enabled, and in this case retail pickup and ship-to-store orders are not supported. When you update to Order Broker 21.0 or higher, ship for pickup orders are automatically enabled in all existing orders, and in this case retail pickup and ship-to-store orders are converted to ship-for-pickup orders.For more information: See About Ship-for-Pickup Orders for background.
| Purpose | Delivery | Pickup | Ship for Pickup |
|---|---|---|---|
|
used to: |
ship an order to the customer when the inventory is backordered in the originating location |
enable the customer to pick up the order at a nearby store that already has the inventory on-hand rather than wait for shipment |
enable the customer to pick up the order at a nearby store, and source the inventory from the placing location, the pickup location, or a different location |
|
originating location is where the order is: |
placed |
placed |
placed, and possibly where it’s sourced or picked up |
|
fulfilling location is where the order is: |
shipped from |
picked up |
N/A; sourcing location and pickup location can be different |
|
fulfilling location selected how? |
Routing Engine, or designated by the originating location; can be restricted through zone fulfillment |
customer |
sourced: Routing Engine, or designated by placing location pickup: designated by the customer |
|
order shipped to: |
customer |
N/A |
pickup location, if different from sourcing location |
Selecting the Location for a Pickup Order (LocateItems)
Purpose: The submit order message for a pickup order needs to specify the fulfilling location and system. You can use the locate items message to request a listing of locations that should be able to fulfill an order for one or more products in a specified area.
Which locations have a product available for pickup? A pickup order means that the customer will pick up the product(s) in a location where the inventory is available, and it does not need to be transferred from a different location. If the request message indicates that the fulfillment type is a pickup:
-
The response message lists each location where the product is stocked, is flagged as Pickup Available, and has a quantity available that meets or exceeds the quantity specified in the request message; also, the response provides information such as the available quantity and the date and quantity of the next expected purchase order. If the customer requests more than one item, the response message lists locations where all requested items are available for pickup.
-
Once the customer specifies the location where s/he would like to pick up the product(s), you can then send the SubmitOrder request message, providing the customer information, requested products, and selected location.
Note:
Optionally, the request message can specify a requested location if the customer has a preferred store and wants to check on availability in that store only.For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Example:
A customer wants to pick up an item at a nearby store. The LocateItems request indicates:
-
the item (AB100 in a quantity of 5)
-
the postal code where the customer is located (01581)
-
the distance (in miles or kilometers) that the customer is willing to travel (15 miles)
The LocateItems response lists:
-
store location 23: 10.72 miles from the customer
-
store location 57: 13.51 miles from the customer
The response also includes the available quantity in each location, information on any open purchase orders, and the store’s address.
Cannot split: Pickup orders cannot be split across multiple fulfilling locations. To split a pickup order, the originating system needs to submit the request for each location as a separate order.
Exclude Locations with Zero Available? If the Exclude Locations with Zero Availability setting at the Preferences screen is selected, any possible product locations whose current available to promise quantities are 0 or less are excluded from consideration before the application of any potential probability rules.
Gift wrap? If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible for the pickup order.
Locate Items Sort Order, Pickup Request
If Use Weighted Brokering Rules is selected at the Preferences screen, the locations are listed in proximity sequence.
If Use Weighted Brokering Rules is not selected (Standard Brokering), the locations returned in the response are sorted based on the same Order Orchestration criteria that apply to delivery orders unless you use the Order Orchestration Preference Overrides screens to set up preference overrides. Otherwise, the organization-level settings apply to all systems and order types, and the number of eligible locations exceeds the Maximum No. Responses, it is possible that the store location closest to the customer might not be included in the search results, even if it has the requested item(s) available.
Example: On Hand Count is the first criterion under the Order Orchestration Settings at the Preferences screen, and the Maximum No. Responses is set to 5.
The available quantity of the requested item in each eligible location is:
-
100 in location A, 20 miles away
-
90 in location B, 25 miles away
-
80 in location C, 19 miles away
-
70 in location D, 15 miles away
-
60 in location E, 10 miles away
-
50 in location F, 5 miles away
Because location F is the sixth location, it is not included in the search results, even though it is the closest to the customer’s address.
However, if you use the Order Orchestration Preference Overrides screen to set up an override for the system to sort first on proximity when the order type is Pickup, then location F is returned first in the search results.
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Selecting a Location for a Delivery Order
Overview: You can have the Routing Engine select the fulfilling location for a delivery order.
Splitting orders or lines? The Allow Split Order preference controls whether it is possible to split a delivery order across multiple fulfilling locations, If this preference is selected, the Routing Engine splits orders if needed to fulfill the order, and the submit order message can specify multiple fulfilling locations for an order. If the Allow Split Line preference is also selected, the Routing Engine splits the quantity of a single order line across multiple fulfilling locations if necessary.
Weighted or standard brokering? The Use Weighted Brokering Rules setting at the Preferences screen controls how the Routing Engine “shops” for fulfilling locations:
-
Standard brokering: If Use Weighted Brokering Rules is not selected, the Routing Engine selects fulfilling locations based on the Standard Brokering criteria, including proximity, on-hand count, location priority, last order assigned, and sales velocity rank.
-
Weighted brokering: If Use Weighted Brokering Rules is selected, the Routing Engine filters the list of eligible fulfilling locations for an order and submits the list, along with information on the order line(s) and configuration data, such as weighted brokering settings, to the Science Engine module for brokering. The Science Engine evaluates the data and either assigns the fulfilling location(s) or returns a reason code indicating why the order or line(s) could not be fulfilled.
-
Weighted brokering is used to select fulfilling locations for the Submit Order message, Product Availability message, and “reshopping” an order or line; however, it is not used for the Locate Items message. Locations in the Locate Items response are listed in order of proximity, and do not reflect any Science Engine calculations.
You can use weighted brokering to select fulfilling locations that are more profitable. For example, you can give preference to locations that have a lower labor cost or to product locations where the in-store margin (selling price - cost) is lower than the margin for an online sale.
The use of each method to select fulfilling locations is described below.
Locate Items Request for Delivery Order
Note:
Selecting a sourcing location for a ship-for-pickup order is very similar. See About Ship-for-Pickup Orders for key differences.Which locations have the product(s) available for shipment or transfer? A delivery order means that the product(s) should be shipped to the customer’s home.
Note:
The locations where a product is available for pickup might differ from the locations where a product is available for shipment, based on the settings of the Pickup Available, and Delivery Available flags. For example, you might flag your retail store locations as Pickup Available and your warehouse as Delivery Available.Grouping shipments? The Group Shipment Locations setting at the Preferences screen controls how the LocateItems response works for delivery requests:
-
If the Group Shipment Locations preference unselected, the response message lists locations where the available quantity should be able to fulfill the order. The logic is described below.
-
If the Group Shipment Locations preference is selected, the Routing Engine uses the same logic described below for when the preference is unselected; however, the response does not include details on each location that can fulfill the order. Instead, the response just includes the virtual (non-existent) location, indicating that the order can be fulfilled through the Routing Engine.
The chart below illustrates the logic used to select locations to include in the response message if the Group Shipment Locations preference is unselected, the Allow Split Order preference is selected, the request message does not specify a requested location, and splitting is not prohibited based on carrier. If the request is subject to zone fulfillment, then the eligible locations considered are restricted to the primary or alternate locations specified for the zone.
Note:
The response includes the virtual location even when the only locations that meet the criteria are backordered, if they are flagged as Backorder Available.Basic evaluation: To be included in the LocateItems response message without splitting a potential order or line, a location must:
-
have a quantity available that is not less than the requested quantity after applying any active probability rules, or be flagged as Backorder Available. If the request specifies more than one product the response message includes locations only if they stock both (or all) products in the request message.
-
be flagged as Delivery Available
-
be within the proximity specified in the LocateItems request message based on the postal code indicated (Note: The SubmitOrder message does not specify a proximity radius)
-
Not be excluded:
-
because it is within the same system as the requesting location, if the Disallow shopping within same system flag is selected at the System screen.
-
based on the Maximum No. Responses specified for the organization.
-
because the total number of delivery or ship-for-pickup orders assigned for fulfillment or sourcing for the current date meets or exceeds the Maximum Daily Orders limit specified at the Preferences screen. This evaluation takes place only if the Use Maximum Order Limits preference is selected; see Using Maximum Daily Order Assignment for more information.
-
based on any probability rules for which the location(s) or items are eligible. These rules apply before determining which locations to include in the response, and the availability information (available quantity, next purchase order date, and next purchase order quantity) to provide. For example, if a probability rule for a location indicates to reduce the available quantity by 10, Order Orchestration subtracts 10 from the availability quantity that is indicated in the response message.
-
Exclude Locations with Zero Available? If the Exclude Locations with Zero Availability setting at the Preferences screen is selected, any possible product locations whose current available to promise quantities are 0 or less are excluded from consideration before the application of any potential probability rules.
Gift wrap? If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible.
Zone fulfillment? If you use zones for fulfillment and the shipping address is within a zone, only locations specified for the zone are eligible for selection through the Routing Engine. See Using Zones for Fulfillment for more information.
Specific location requested? If the request message specifies a requested location such as the customer’s favorite store, then the response message includes only the requested location in the response, regardless of the Order Orchestration rules set up at the Preferences screen or whether the location is otherwise eligible (for example, through zone fulfillment, or whether it is within the same system if the Disallow shopping within same system flag is selected for the system). See the requested location for more information.
Do Not Split Order For Carrier?If the specified ship via matches the Do Not Split Order For Carrier specified at the Preferences screen and the fulfillment type is delivery, then the Routing Engine does not consider whether the request could be fulfilled by splitting the order across multiple locations.
If weighted brokering is enabled: Because weighted brokering is not evaluated when processing the Locate Items message, the Locate Items response simply lists eligible locations in order of proximity, and does not reflect any Science Engine calculations.
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Location Selection
If Use Weighted Brokering Rules is selected at the Preferences screen, the locations are listed in proximity sequence. The Weighted Brokering rules do not apply to LocateItems request processing, and the Science Engine is not used for a Locate Items search.
If Use Weighted Brokering Rules is not selected at the Preferences screen (Standard Brokering). the Routing Engine uses the method described below to select locations for delivery orders.
Overrides: When selecting locations, the Routing Engine uses the Order Orchestration criteria in the order specified at the Preferences screen unless you have used the Edit Order Orchestration Preference Override screen to set an override sort preference for the system, order type, and Express carrier setting:
-
Proximity
-
Location Priority
-
On Hand Count
-
Last Order Assigned
-
Sales Velocity Rank
These criteria are ranked at the Preferences screen or the Edit Order Orchestration Preference Override screen to indicate which criterion to apply first. For example, if the Proximity criterion has a setting of 1, the closest locations are listed first, followed by locations that are farther from the requesting location. See Selecting a Location for a Delivery Order.
Note:
The Last Order Assigned and Sales Velocity Rank criteria are optional.If zone fulfillment applies, then the criteria above apply to the primary or alternate locations specified for the zone. See Using Zones for Fulfillment for a discussion.
If the Disallow shopping within same system flag is selected at the System screen for the requesting location’s system, then the criteria above apply only to locations in other systems.
How many locations listed? If the Group Shipment Locations preference is unselected, the Routing Engine checks the Maximum No. Responses setting to determine how many possible locations to include in the LocateItems response. If not all eligible locations are included, the response eliminates locations based on the Order Orchestration selection criteria specified at the Preferences screen or the Edit Order Orchestration Preference Override screen. For example, if the first criterion is proximity, and the Maximum No. Responses is set to 5, the 5 closest qualifying locations are included.
If the request specifies a requested location, then only the requested location is included in the response, and it is included regardless of whether the location is within the related zone when zone fulfillment applies.
Splitting orders? When it receives a request, the Routing Engine always checks first to see if there is a location that could fulfill the entire order. Otherwise, if there is not a single location that can fulfill the order and the Allow Split Order preference is:
-
selected, the Routing Engine next checks whether assigning a single line to multiple locations can make it possible to fulfill the order. In this case, the response lists the locations that have the item available.
-
unselected, the Routing Engine does not attempt to split any order lines.
Splitting lines? If the Allow Split Order preference is selected, but assigning the individual lines to different locations does not make it possible to fulfill the order completely, the Routing Engine next checks the Allow Split Line setting at the Preferences screen to determine whether it can attempt to fulfill the order by splitting the quantity for a single item across multiple locations. If the Allow Split Line preference is:
-
selected, the Routing Engine next checks whether the order can be fulfilled by assigning the individual lines to different locations. If the order would be split, the Routing Engine evaluates each order line individually based on your Preferences settings. In this case, the sequence in which the locations are listed in the response indicates their eligibility based on your preferences.
-
unselected and the order could not be fulfilled without splitting, the Routing Engine indicates that the order cannot be fulfilled.
Splitting lines with backorder available? The LocateItems response message lists locations that could partially fulfill an order line regardless of whether any of these locations are flagged as Backorder Available. However, when you send the SubmitOrder message, the Routing Engine splits the line across locations using your specified criteria until it comes to the location flagged as Backorder Available; when it comes to this location, the Routing Engine assigns the remaining quantity of the item. See LocateItems Sequence and Splitting Examples (Standard Brokering) for an example.
Partially fulfill? If splitting the order or the lines does not make it possible to completely fulfill the order, the LocateItems response indicates the locations that could fulfill individual lines on the order. Lines that could not be completely fulfilled, even after splitting the line across locations, are indicated in the response with the message Product not available within search criteria.
Do Not Split Order For Carrier? If the specified ship via matches the Do Not Split Order For Carrier specified at the Preferences screen and the fulfillment type is delivery, then the Routing Engine does not consider whether the request could be fulfilled by splitting the order across multiple locations.
Note:
When determining whether a location can fulfill an order, the Routing Engine first checks for locations that have the required quantity on-hand; however, if there are no locations with the quantity on-hand, the Routing Engine considers locations flagged as Backorder Available.
LocateItems Sequence and Splitting Examples (Standard Brokering)
Note:
Selecting sourcing locations for a ship-for-pickup order is very similar. See About Ship-for-Pickup Orders for key differences.Location sequence in response: When the Routing Engine receives a request message for a delivery order and you are not using the Group Shipment Locations option, the sequence of the locations listed in the response message indicates the order in which the Routing Engine would select a location for fulfillment of the order.
Example: If your preferences indicate to select a location first based on proximity, the first location listed in the response is the location closest to the customer’s address based on postal code. If two or more locations are the exact same distance from the customer’s address, the Routing Engine checks the next criterion, such as available quantity.
Zone fulfillment? If you use zones for fulfillment and the shipping address is within a zone, only locations specified for the zone are eligible to be included in the response when the fulfillment type is DELIVERY. See Using Zones for Fulfillment for more information.
Specific location requested? If the request message specifies a requested location such as the customer’s favorite store, then the response message includes only the requested location in the response, regardless of the Order Orchestration rules set up at the Preferences screen or whether the location is otherwise eligible through zone fulfillment or if the location has exceeded the maximum number of orders and you are Using Maximum Daily Order Assignment. See the requested location for more information.
Maximum order limits? When the Use Maximum Order Limits preference is selected for the organization, the LocateItems response message for a delivery request excludes locations if the number of orders assigned for the current date meets or exceeds the Maximum Daily Orders limit specified at the Preferences screen. See Using Maximum Daily Order Assignment for more information.
Gift wrap? If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible.
Criteria based on location: The Order Orchestration search criteria of proximity, last order assignment, or priority number are based on the location itself, so the sequence of locations in the response message is not affected by the products requested.
Example: Highest priority Order Orchestration setting is Proximity (set at either the Preferences screen or through the Order Orchestration Preference Overrides screen)
Product AB100 and product BC200 available in:
-
location 10: 10.21 miles from the customer’s location based on postal code
-
location 20: 7.88 miles from the customer’s location based on postal code
Result: The response lists location 20 before location 10.
Note:
If a product is available in a location that has the Use Proximity Locator preference unselected, then the distance calculated from the customer’s location is always 0. If you use the Proximity Order Orchestration criterion, you might apply this preference to your distribution center in order to have it always be the “preferred” location for delivery requests.Location sequence based on available quantity if multiple products requested: If your Order Orchestration search criteria at the Preferences screen or the Edit Order Orchestration Preference Override screen are based primarily on on-hand count, this location sort logic is based on the combined available quantity for all requested products in each location where the products are available.
Example: Highest priority Order Orchestration setting is On Hand Count (set at either the Preferences screen or through the Order Orchestration Preference Overrides screen)
Example:
-
Product CD100:
-
400 available in location 11
-
50 available in location 22
-
-
Product DE200:
-
10 available in location 11
-
75 available in location 22
-
Result: If the message requests:
-
just CD100: location 11 is listed first (available quantity of 400 is greater than 50)
-
just DE200: location 22 is listed first (available quantity of 75 is greater than 10)
-
both CD100 and DE200: location 11 is listed first (combined available quantity of 410 (400 + 10) greater than combined available quantity of 125 (50 + 75))
Note:
If your response includes locations with a negative quantity (included because the Backorder Available flag is selected), then it is possible that the first location listed might not have all requested products in stock, even when you are searching based on on-hand count. For example, location 33 has an average available quantity of 25 (20 of product EF300 and -5 of product FG400), while location 44 has an average available quantity of 6 (7 of EF300 and 5 of FG400). In this situation, location 33 is listed first in the response message.For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Location sequence based on sales velocity rank if multiple products requested: If your Order Orchestration search criteria at the Preferences screen or the Edit Order Orchestration Preference Override screen are based primarily on sales velocity rank, this location sort logic is based on the combined sales velocity for all requested products in each location where the products are available.
Example: Highest priority Order Orchestration setting is sales velocity rank (low to high, set at either the Preferences screen or through the Order Orchestration Preference Overrides screen)
-
Product CD100:
-
sales velocity is 40 in location 11
-
sales velocity is 5 in location 22
-
-
Product DE200:
-
sales velocity is 10 in location 11
-
sales velocity is 30 in location 22
-
Result: If the message requests:
-
just CD100: location 11 is listed first (sales velocity of 40 is greater than 5)
-
just DE200: location 22 is listed first (sales velocity of 30 is greater than 10)
-
both CD100 and DE200: location 11 is listed first (combined sales velocity of 45 (40 + 5) greater than combined sales velocity of 40 (10 + 30))
Note:
If a product location has a sales velocity setting of 0 (for example, because the system has not yet reported a sales velocity), this setting counts as the lowest possible sales velocity.Sequence if splitting: If the Allow Split Order preference is selected and the Routing Engine would not be able to fulfill an order for all requested items without splitting it across multiple locations, the response lists the possible locations in a different sequence for each requested item.
Example: Highest priority Order Orchestration setting is On Hand Count (set at either the Preferences screen or through the Order Orchestration Preference Overrides screen), splitting order
-
Product GH100
-
10 available in location 55
-
20 available in location 66
-
-
Product HI200
-
15 available in location 66
-
43 available in location 77
-
-
Product IJ300:
-
17 available in location 88
-
23 available in location 99
-
Result: If the message requests all 3 items, the response lists the locations for each based on the available quantity of each item in each eligible location:
-
GH100: location 66 (20 available) before location 55 (10 available)
-
HI200: location 77 (43 available) before location 66 (15 available)
-
IJ300: location 99 (23 available) before location 88 (17 available)
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Splitting order if not all items available: If the Allow Split Order preference is selected, then the response indicates which items could be fulfilled, and which items are not available in the quantity requested.
Example: Splitting order, not all items available in requested quantities
-
Product KL100, requested quantity 1:
-
10 available in location 12
-
20 available in location 23
-
-
Product MN200, requested quantity 5:
-
15 available in location 34
-
4 available in location 45
-
-
Product OP300, requested quantity 7: 2 available in location 56
Result: If the message requests all 3 items, the response indicates:
-
KL100: lists location 12 and location 23
-
MN200: lists location 34; location 45 not listed since available quantity of 4 is less than requested quantity of 5
-
OP300: indicates Product not available within search criteria
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Maximum number of responses: The response does not include more locations than the Maximum No. Responses specified at the Preferences screen, even if the Allow Split Line preference is selected and the order line would need to be split over more locations than permitted under the Maximum No. Responses.
Example: Splitting items, locations required to fulfill requested quantity exceeds Maximum No. Responses
-
Product QR100, requested quantity 10:
-
2 available in location 67
-
2 available in location 78
-
2 available in location 89
-
3 available in location 90
-
3 available in location 91
-
-
Maximum No. Responses = 3
Result: The response lists location 90 (3 available), location 91 (3 available), and location 67 (2 available). Although the response lists a total quantity available of 8, the additional locations not listed in the response have sufficient inventory to fulfill the entire quantity if the order line is split.
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Grouping shipments and splitting orders: If the Group Shipment Locations and Allow Split Order preferences are selected, the response indicates which of the requested items are available in the quantities indicated; however, if the Allow Split Order preference is unselected, then if any requested item is not available in the requested quantity, then the entire order is considered to be not available.
Example: Grouping shipments, one requested item not available
-
Product KL100, requested quantity 1:
-
10 available in location 12
-
20 available in location 23
-
-
Product MN200, requested quantity 5:
-
15 available in location 34
-
4 available in location 45
-
-
Product OP300, requested quantity 7: 2 available in location 56
Result:
If the message requests all 3 items and Allow Split Order is selected, the response indicates:
-
KL100 and MN200: indicates available in the virtual location
-
OP300: indicates Product not available within search criteria
If the message requests all 3 items and Allow Split Order is unselected, the response indicates Product not available within search criteria for all 3 items
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Splitting an order line if a location is flagged as Backorder available: If the Allow Split Order and Allow Split Line preferences are both selected, then the Routing Engine splits a single line across multiple locations. However, if one of the locations it would select is flagged as Backorder Available, then that location serves as a catch-all to fulfill the remaining quantity of the order line.
Example: Splitting an order line across multiple locations with one location flagged as Backorder available
-
Product KL100, requested quantity 15:
-
3 available in location 12
7 available in location 23
2 available in location 37
1 available in location 49
2 available in location 82
-
Result:
-
If the Maximum No. Responses is not set less than 5 and the first Order Orchestration criterion is On Hand Count, the response lists the locations in the following order:
-
7 available in location 23
-
3 available in location 12
-
2 available in location 37
-
2 available in location 82
-
1 available in location 49
-
-
However, if location 37 were flagged as Backorder Available, when you submitted an order line for a quantity of 15, the Routing Engine splits the line across locations as follows:
-
7 assigned to location 23
-
3 assigned to location 12
-
5 assigned to location 37
-
Submit Order Request for Delivery Order (Standard Brokering)
The following process applies when Use Weighted Brokering Rules is not selected.
Note:
The process for selecting a sourcing location for a ship-for-pickup order is very similar. See Enable Ship-For-Pickup? for key differences.Location designated? The originating location can specify the location(s) to fulfill a delivery order and indicate the selected location(s) in the submit order message. For example, you might use the locate items request and response to initially generate a list of possible locations, and then select a location from this list to designate in the submit order request. When the fulfilling location is designated in the submit order request, the Routing Engine confirms that each location is eligible to fulfill the order, based on:
-
Location eligible? The Delivery Available flag at the Preferences screen must be selected.
-
Backorder eligible? If the location does not have the requested quantity of each item on the order available after checking on inventory if it’s in an online system, and applying any probability rules (less any reserved quantity or fulfilled quantity; see Calculating the Available to Promise Quantity), the Backorder Available flag at the Preferences screen must be selected.
If a designated location is not eligible based on the above criteria, the Routing Engine returns an error to the submit order request message. However, if the location is otherwise eligible, the Routing Engine assigns the order to the specified location even if the location is:
-
not within the related zone when you use zone fulfillment, or
-
excluded based on probability rules, or
-
within the same system as the requesting system, even if the Disallow shopping within same system flag is selected for the system.
Gift wrap? If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible.
Note:
Regardless of the setting of the Allow Split Order and Allow Split Line preferences, the Routing Engine does not split an order or line when the fulfilling location is specified in the request message.If location not designated: The Routing Engine uses the same logic to select a fulfilling location for a delivery order when it receives a locate items request as when it receives a submit order request without a fulfilling location specified. The Routing Engine checks each location stocking the requested item(s):
-
Excludes the location that generated the order.
-
If the shipping address falls within a fulfillment zone, restricts the results to the primary locations specified for the zone. See Using Zones for Fulfillment for a discussion.
-
If the Disallow shopping within same system flag is selected for the system of the requesting location, excludes all other locations for that system.
-
Applies any proximity rules to determine whether a location is an acceptable distance from the customer’s shipping address.
-
If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible.
-
Considers locations only if the Delivery Available flag at the Preferences screen is selected.
-
Excludes a location if the total number of delivery orders assigned for the current date meets or exceeds the Maximum Daily Orders limit specified at the Preferences screen. This evaluation takes place only if the Use Maximum Order Limits preference is selected; see Using Maximum Daily Order Assignment for more information.
-
Determines the Available to Promise quantity: see Calculating the Available to Promise Quantity.
-
Applies any probability rules to determine whether to include the location and to calculate the available quantity to use for evaluation purposes. For example, you might have a probability rule to exclude a location if the available quantity is less than 2, or a rule to include the quantity expected to be received on an upcoming purchase order in the available quantity.
Note:
If the Exclude Locations with Zero Availability setting at the Preferences screen is selected, any possible product locations whose current available to promise quantities are 0 or less are excluded from consideration before the application of any potential probability rules. -
After performing the above calculations, considers each location as eligible only if it has at least the requested quantity available for each requested item (less any reserved quantity and fulfilled quantity; see Calculating the Available to Promise Quantity), or if it is flagged as Backorder Available.
-
If there is more than one eligible location at this point, applies the Order Orchestration selection criteria specified at the Preferences screen or the Edit Order Orchestration Preference Override screen to select the locations eligible to fulfill the order. You assign each of the five criteria with a rank to indicate which criterion to use first. The selection criteria are:
-
Proximity: Set this criterion to Closest to select the eligible location closest to the customer’s address. You might choose this setting to save on shipping costs.
-
Location Priority: Set this criterion to Low to High to select the eligible location whose location priority is the lowest number. The location priority is a number you assign to a location, location type, or organization to control the Routing Engine search logic.
-
On-hand count: Set this criterion to High to Low to select the eligible location where the Available to Promise quantity of the product is highest. You might use this setting to avoid depleting the inventory in any one location.
-
Last order assigned: Set this criterion to Variable to select the eligible location whose last order assignment date and time was the earliest. You might choose this setting to create an even distribution of orders among eligible locations. This criterion is optional.
-
Sales velocity rank: Set this criterion to Low to High to select the eligible location where the product’s Sales Velocity is lowest. This criterion is optional.
-
Criterion ranking: The Routing Engine uses the criterion with the highest rank to select the fulfilling location. If there is a “tie” (for example, if two locations have the same Available to Promise quantity or the same location priority), the Routing Engine uses the next criterion based on assigned rank.
-
Example: The On-hand Count preference is ranked at 1 with an Order of Descending (highest to lowest), so the Routing Engine selects the location with the highest Available to Promise quantity. If there are two locations with the same available quantity, the Routing Engine checks the selection criterion ranked at 2: this is Location Priority, and it has an Order of Ascending (lowest to highest). As a result, the Routing Engine selects the location whose Location Priority is 1 over a location whose Location Priority is 5.
Using alternate locations for a fulfillment zone: If the shipping address falls within a fulfillment zone and the order cannot be assigned using the primary locations specified for the zone, the Routing Engine next uses the steps above to attempt to assign the order using the alternate locations for the zone. If the order can using the alternate locations for the zone and you split orders, the Routing Engine then uses the steps above to attempt to assign the order across both the primary and alternate locations for the zone. See Using Zones for Fulfillment for a discussion.
Acknowledge order before brokering? If the Acknowledge Order Before Brokering preference is selected, the Order Orchestration does not select a fulfilling location before sending the submit order response message; instead, it confirms that the order information, such as address, products, and originating location, is valid, assigns the order to a temporary IN PROCESS location, and then sends the response message as to an order acknowledgment. The Order Orchestration then proceeds with location selection. The originating system can send a status inquiry request afterward to determine the assigned location(s). See Acknowledge Order Before Brokering for a discussion.
Order rejected? When a location rejects an order or line, the Routing Engine goes through the same selection criteria again; however, it excludes any location that has already rejected the order or line. Also, when you split orders, if the entire order is rejected, the Routing Engine does not attempt to assign all lines to the same fulfilling location; instead, it searches for locations for each line individually.
Note:
Even if the original submit order request message specified a fulfilling location, the Routing Engine uses its standard selection logic when the assigned location rejects the order or line.If the Routing Engine cannot find a location for fulfillment: If at any point the Routing Engine receives a submit order message and cannot find an eligible location to ship the order or line, or if an order or line is rejected by an assigned location and the number of Search Retries specified at the Preferences screen is exceeded, the Routing Engine assigns the order or line to the Default Unfulfillable Location specified at the Preferences screen. By assigning an order or line to the Default Unfulfillable Location, the Routing Engine is flagging the order or line as unfulfillable. When the requesting system receives a status inquiry response message indicating that an order or line is assigned to this location, this indicates to the system that it either needs to fulfill the order or line using its internal processes or cancel the order or line.
Example: Splitting an order at initial submission with subsequent rejection
-
Product KL100, requested quantity 2:
-
1 available in location 12
-
1 available in location 23
-
Result:
-
Order created, with 1 unit assigned to location 12 and 1 unit assigned to location 23.
Note:
If only 1 unit were available when the submit order message was received, the Routing Engine would have assigned the entire order to the default unfulfillable location.Example: When a split order line rejected:
-
The Routing Engine puts the second order line in unfulfillable status; however, the order is still open if location 12 can fulfill the first order line.
For more information: See Calculating the Available to Promise Quantity and Using Probability Rules for information on factors that affect the available quantity.
Submit Order Request for Delivery Order (Weighted Brokering)
The following process applies when Use Weighted Brokering Rules is selected.
Note:
Selecting a sourcing location for a ship-for-pickup order is very similar. See About Ship-for-Pickup Orders for key differences.Location designated? The originating location can specify the location(s) to fulfill a delivery order and indicate the selected location(s) in the submit order message. For example, you might use the locate items request and response to initially generate a list of possible locations, and then select a location from this list to designate in the submit order request. When the fulfilling location is designated in the submit order request, the Routing Engine confirms that each location is eligible to fulfill the order, based on:
-
Location eligible?The Delivery Available flag at the Preferences screen must be selected.
-
Backorder eligible? If the location does not have the requested quantity of each item on the order available after checking on inventory if it’s in an online system, and applying any probability rules (less any reserved quantity; see Calculating the Available to Promise Quantity), the Backorder Available flag at the Preferences screen must be selected.
If a designated location is not eligible based on the above criteria, the Routing Engine returns an error to the submit order request message. However, if the location is otherwise eligible, the Routing Engine assigns the order to the specified location even if the location is:
-
not within the related zone when you use zone fulfillment, or
-
excluded based on probability rules, or
-
within the same system as the requesting system, even if the Disallow shopping within same system flag is selected for the system.
Gift wrap? If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible.
Note:
Regardless of the setting of the Allow Split Order and Allow Split Line preferences, the Routing Engine does not split an order or line when the fulfilling location is specified in the request message.If location not designated: When Use Weighted Brokering Rules is selected, the Routing Engine submits a listing of eligible locations to the Science Engine, along with additional data to enable the Science Engine to select the fulfilling location(s) for the order. However, before submitting the information to the Science Engine, the Routing Engine filters the list of eligible locations to those that stock the requested item(s), and:
-
Excludes the location that generated the order.
-
If the shipping address falls within a fulfillment zone, restrict the list to the primary locations and secondary locations specified for the zone. See Using Zones for Fulfillment for a discussion.
-
If the Disallow shopping within same system flag is selected for the system of the requesting location, excludes all other locations for that system.
-
Applies any proximity rules to determine whether a location is an acceptable distance from the customer’s shipping address.
-
Considers locations only if the Delivery Available flag at the Preferences screen is selected.
-
Excludes a location if the total number of delivery orders assigned for the current date meets or exceeds the Maximum Daily Orders limit specified at the Preferences screen. This evaluation takes place only if the Use Maximum Order Limits preference is selected; see Using Maximum Daily Order Assignment for more information.
-
Determines the Available to Promise quantity: see Calculating the Available to Promise Quantity.
-
Applies any probability rules to determine whether to include the location and to calculate the available quantity to use for evaluation purposes. For example, you might have a probability rule to exclude a location if the available quantity is less than 2, or a rule to subtract 10% from the reported available quantity for certain locations.
Note:
If the Exclude Locations with Zero Availability setting at the Preferences screen is selected, any possible product locations whose current available to promise quantities are 0 or less are excluded from consideration before the application of any potential probability rules. -
After performing the above calculations, considers each location as eligible only if it has at least the requested quantity available for each requested item (less any reserved quantity; see Calculating the Available to Promise Quantity), if the order might be split across the eligible locations that collectively have the requested quantity, or if the location is flagged as Backorder Available.
Do Not Split Order For Carrier? If the specified ship via matches the Do Not Split Order For Carrier specified at the Preferences screen and the fulfillment type is delivery, then the Routing Engine does not consider whether the request could be fulfilled by splitting the order across multiple locations.
Submission to Science Engine: The Routing Engine then submits the list of eligible locations to the Science Engine. The information sent to the Science Engine includes:
-
Order line information: order type, request ID, line number, product code, selling price
-
Configuration information: Weighted Brokering criteria (the percentage weights assigned for Labor Cost, Gross Margin, Proximity, On Hand Quantity, and Sales Velocity, as well as the Priority for evaluating sales velocity), Allow Split Order setting, Allow Split Line setting, and Maximum Order Splits setting
-
Information on each eligible product location: Product code, System code, Location code, Available to Promise quantity after subtracting any reserved quantity and applying any probability rules, distance, zone group level (primary or secondary), Backorder Available setting, On Clearance setting, Selling Price, Cost, Sales Velocity, and the location’s Labor Cost
Criteria for fulfilling location assignment: The Science Engine uses similar criteria for fulfilling location assignment to standard brokering criteria, except in each of the following scenarios, if more than one location could fully or partially fulfill the order, select a location based on weighted brokering rules:
- Single location? If a single location could fulfill the entire order with its on-hand quantity, use that location, selecting a primary location if the order is subject to fulfillment zone processing; otherwise,
- Fulfill by splitting order? If Use Split Order is selected, and the entire order could be fulfilled across more than one location by splitting the order, but not the line quantities, with the locations’ on-hand quantities and without exceeding the Maximum Order Splits, use these locations. If the order is subject to fulfillment zone processing, split the order only across primary locations; otherwise,
-
Fulfill by splitting order and lines? If Use Split Order and Use Split Line are selected, and the entire order could be fulfilled across more than one location by splitting the order and line quantities with the locations’ on-hand quantities and without exceeding the Maximum Order Splits, use these locations. If the order is subject to fulfillment zone processing, split the order and lines only across primary locations; otherwise,
-
Fulfill by splitting order in primary or alternate locations in zone? If the order is subject to fulfillment zone processing, Use Split Order is selected, and the entire order could be fulfilled across more than one Primary or alternate location by splitting the order, but not the line quantities, with the locations’ on-hand quantities and without exceeding the Maximum Order Splits, use these locations; otherwise,
-
Fulfill by alternate locations in zone? If the order is subject to fulfillment zone processing and could not be fulfilled by assignment to primary locations, but a single alternate location could fulfill the entire order with its on-hand quantity, use that location; otherwise,
-
Fulfill by splitting order and lines in primary or alternate locations in zone? If the order is subject to fulfillment zone processing, Use Split Order and Use Split Line are selected, and the entire order could be fulfilled across more than one Primary or alternate location by splitting the order and line quantities with the locations’ on-hand quantities and without exceeding the Maximum Order Splits, use these locations; otherwise,
-
Fulfill by assignment to backorder location(s)? If any eligible locations are flagged as Backorder Available, select one of these locations with the highest on-hand quantity. The order and lines can also be split as in the above scenarios, as long as the Maximum Order Splits is not exceeded.
See Science Engine Examples for information on how the Science Engine evaluates potential locations based on the weighted brokering criteria passed, and see Primary and Alternate Search Hierarchy: Weighted Brokering for details on fulfillment zone processing.
Response from Science Engine: The Science Engine returns one of the following responses:
-
Fulfillable: The complete quantity of the order is fulfillable, based on the available to promise quantity without relying on backorder fulfillment.
The Science Engine returns the location(s) to the Routing Engine.
-
Fulfillable through backorder: The order line(s) are fulfillable only by assigning one or more units or lines to a backorder location because the full quantities are not available.
The Science Engine returns the location(s) to the Routing Engine, but also provides a reason code identifying how it selected the location(s). The following reason codes are stored in the UNFULFILLABLE_REASON_CODE in the XOM_STATUS_HISTORY table; however, no Transaction Note is displayed at the Order screen:
-
4000: An order or line had to be assigned to a backorder location that was currently without sufficient inventory, because the entire order could not be assigned to locations with sufficient inventory without exceeding the Maximum Order Splits. For example, an order includes a line for 1 unit of item A, and another line for 2 units of item B. Location 100 can fulfill the line for item A. Locations 200 and 300 each have 1 unit item B. The Maximum Order Splits is set to 2. If location 200 supports backorders, the line with 2 units of item B is assigned there.
-
5000: An order or line had to be assigned to a backorder location that was currently without sufficient inventory, because there were no locations that had the inventory on-hand; however, this was not the result of the Maximum Order Splits setting being exceeded.
-
8000: An order or line could have been assigned to locations with inventory if split order or line were allowed; but since the order or line could not be split, it was assigned to a backorder location that was currently without sufficient inventory.
-
-
Unfulfillable: The order line(s) are not fulfillable even by assigning one or more units or lines to a backorder location, either because backorder locations are not available or because of a limit to splitting the order or lines.
The Science Engine returns a reason code identifying why the order could not be fulfilled. The following reason codes are stored in the UNFULFILLABLE_REASON_CODE in the XOM_STATUS_HISTORY table:
-
Exceed Maximum Number of Splits: The Science Engine returned a code indicating that the entire order could not be fulfilled without exceeding the Maximum Order Splits, so the entire order is unfulfillable. This response can occur for a single-line order that could have been fulfilled by splitting the line, but split line is not enabled. A reason code of 1000 is stored as the UNFULFILLABLE_REASON_CODE in the XOM_STATUS_HISTORY table.
-
Not Enough Inventory and No Backorder Location: The Science Engine returned a code indicating that the entire order, or a line on the order, could not be fulfilled because there was not sufficient inventory on-hand, and there was not an eligible location that supported backorders. A reason code of 2000 is stored as the UNFULFILLABLE_REASON_CODE in the XOM_STATUS_HISTORY table if the entire order was unfulfillable, and a reason code of 3000 is stored for an individual line that was unfulfillable while other line(s) could be fulfilled.
-
Not Fulfilled due to Split Not Allowed: The Science Engine returned a code indicating that the entire order could not be fulfilled without splitting one or more order lines, and Allow Split Line was not selected. The same message is displayed if the order could not be fulfilled without splitting the order, and Allow Split Order was not selected. A reason code of 7000 is stored as the UNFULFILLABLE_REASON_CODE in the XOM_STATUS_HISTORY table if the entire order was unfulfillable, and a reason code of 6000 is stored for an individual line that was unfulfillable while other line(s) could be fulfilled.
-
Acknowledge order before brokering? If the Acknowledge Order Before Brokering preference is selected, the Routing Engine confirms that the order information, such as address, products, and originating location, is valid, assigns the order to a temporary IN PROCESS location, and then sends the response message as an order acknowledgment regardless of whether it has already received the response from the Science Engine. The originating system can send a status inquiry request afterward to determine the assigned location(s). See Acknowledge Order Before Brokering for a discussion.
Order rejected? When a location rejects an order or line, the Routing Engine again submits the order or line to the Science Engine; however, it excludes any location that has already rejected the order or line from the list of eligible locations.
Note:
Even if the original submit order request message specified a fulfilling location, the Routing Engine uses its standard location eligibility logic for submission to the Science Engine when the assigned location rejects the order or line.If the Science Engine cannot find a location for fulfillment: If at any point the Routing Engine receives a submit order message and Science Engine cannot find an eligible location to ship the order or line, or if an order or line is rejected by an assigned location and the number of Search Retries specified at the Preferences screen is exceeded, the Routing Engine assigns the order or line to the Default Unfulfillable Location specified at the Preferences screen. By assigning an order or line to the Default Unfulfillable Location, the Routing Engine is flagging the order or line as unfulfillable. When the requesting system receives a status inquiry response message indicating that an order or line is assigned to this location, this indicates to the system that it either needs to fulfill the order or line using its internal processes or cancel the order or line.
When the requesting system receives a status inquiry response message indicating that an order or line is assigned to this location, this indicates to the system that it either needs to fulfill the order or line using its internal processes or cancel the order or line.
Science Engine Examples
The Science Engine uses the information passed from the Routing Engine, including the weighted brokering criteria, to select locations if there is more than one eligible location or an order or line needs to be split for fulfillment.
Each of the weighted brokering criteria that have percentage weights greater than 0 are considered.
| Example Description | Example |
|---|---|
|
Example 1: Select by margin (select the location where the difference between the in-store Selling Price and the Cost is lowest, since it is more profitable to source the online order there) |
In this example:
Result: The Science Engine selects location A, because it has the higher score. An in-store purchase in location A results in a lower margin than location B, so it is more profitable to assign the online order to location A. The Margin displayed for the Product Location differs from the margin calculation performed by the Science Engine. The Science Engine’s calculation includes the order line unit price, while the Margin displayed for a Product Location is simply the in-store Selling Price minus the Cost. |
|
Example 2: Select by net profit (select the location where the overall profit is lowest after factoring in the order unit price, in-store Selling Price, Cost, and Labor Cost) |
In this example:
Result: The Science Engine selects location B. After factoring in the higher Labor Cost for location A and the lower Labor Cost for location B, the Science Engine determines that location B is more profitable. Note: When you set the Weighted Percentages to include both Gross Margin and Labor Cost by applying percentages greater than 0, the Science Engine uses Labor Cost only as part of the net profit calculation by subtracting it from the margin weight as described above. However, if the Weighted Percentages include just Labor Cost and have the Gross Margin percentage set to 0, then the Science Engine uses Labor Cost by itself, based on its percentage weight. |
|
Example 3: Select the best location based on weighted percentages that include both profitability and other criteria. Unlike the other examples, this scenario includes criteria that are not the same units: in this case, currency (such as dollars) and quantity. |
In this example:
Result: The Science Engine selects location B. Its lower Labor Cost outweighs the higher Available to Promise quantity of location A. |
Using Attribute Rules for Delivery Orders
You can set up custom attributes to filter the locations eligible to source orders, or where orders can be picked up.
Custom attributes are used only if Use Attribute Rules is selected at the Preferences screen.
These rules apply when filtering locations for LocateItems, ProductAvailability, and SubmitOrder requests. They also apply when “reshopping” orders as a result of a StatusUpdate request or when the order is rejected through the user interface. If there have been any changes to the attribute assignments to locations or the product since the order line was created, the current attribute assignments apply.
Note:
This setting also controls whether to filter locations when gift wrap is required.Examples:
| Attribute Usage | How to Implement |
|---|---|
|
Engraving required: Product A always requires engraving, so only locations that support engraving can fulfill orders for this product. |
Setup:
Web service responses: The LocateItems response, ProductAvailability response, and SubmitOrder response automatically filter locations to those that support engraving based on the attribute assignment and the fulfillment type. |
|
Engraving optional: Product B is eligible for engraving, but can also be ordered without it. The individual request for the product indicates whether engraving is required. |
Setup:
Web service requests: The LocateItems request, ProductAvailability request, SubmitOrder request should include the custom attribute only when engraving is required. Web service responses: The responses messages filter eligible locations based on whether they support engraving for the specified Location Use. |
|
Supported brand: Your organization includes store locations associated with multiple brands, but only locations that are associated with Brand ABC can fulfill orders for the brand. Location 100 is associated with brand ABC. |
Setup:
|
Attribute setup options: You can use the following options when setting up attribute definitions:
-
Attribute Type: Attributes can filter eligible locations based on:
-
Location and Product: The location must be consistent with an attribute defined for the product. The attribute might be a universal requirement, such as the engraving required example above, or specified on a case-by-case basis, such as the optional engraving example.
-
Location: The location must be consistent with an attribute defined for the originating location. The requirement might apply to the pickup location for a pickup order, or to the sourcing location for a delivery order.
-
-
Product Type: Although you can create attributes with an Attribute Type of Product, these attributes are informational only and not used to route orders.
-
Data Type: Possible attribute data types are:
-
Boolean: The attribute is used to route orders if the Boolean is assigned to the product or originating location, such as the engraving examples above. An assigned Boolean is interpreted as True. Negative Boolean attributes are not supported.
-
List: Defines a list of valid values, such as the brand example above. When the attribute is used to route orders, there must be a match with one of the list values.
-
Text: Similar to the List data type, except it is not validated against a defined list of values.
-
Number: Similar to the List data type, except it is not validated against a defined list of values, and must be numeric.
-
-
Allow Multiple:
-
Locations: Controls whether the attribute can be assigned more than once to a single location with different values and the same Location Use (Originating, Sourcing, or Pickup). For example, a location can support multiple brands. Even if the attribute is set to not allow multiples, a different attribute value can be assigned to the location for each different location use; for example, a location can support engraving when it is a sourcing location, but not when it is a pickup location. Regardless of the Allow Multiple setting, only a single value can be assigned to a location when the Location Use is Originating.
-
Products: Controls whether the attribute can be assigned more than once with different values to the same product.
The Allow Multiple setting does not apply to Boolean attributes, and cannot be selected.
Filter based on multiple attributes? It is possible for multiple location, or product and location attributes to filter eligible locations. For example, one attribute can filter locations that do not support engraving, while another attribute can filter locations based on brand. All attributes apply, regardless of whether:
-
They have been assigned to the product or any potential sourcing or pickup locations;
-
They are passed in the LocateItems, ProductAvailability, or SubmitOrder request message;
-
They were initially applied to the order line at the time that it was created, and it is now being “reshopped.”
A location is excluded if it does not qualify based on all location or product and location attributes. For example, the Brand attribute is applied to location 1 with a Location Use of Originating and a value of ABC, and a LocateItems request from location 1 passes the Brand attribute with a value of brand DEF with a Pickup fulfillment type. Only locations that are assigned both ABC and DEF with a Location Use of Pickup can be eligible as pickup locations.
Assigning attributes to locations or products: Use the New Location Attribute and New Product Attribute screens to assign attributes.
-
Turn-by-Turn Distance Evaluation for Delivery Orders
Overview: If you use the Oracle Maps Cloud Service API for proximity location, you can use turn-by-turn distance evaluation, rather than straight-line distance evaluation, for delivery orders that use a specified carrier.
Useful when? You might use this option to choose fulfilling locations based on the actual driving distance from the fulfilling location to the customer’s address. This way, you can avoid routes with a longer driving distance if, for example, an additional few miles are required to cross a bridge to get from a store location to the customer’s address, even though the store location and the customer’s address are directly across a river from one another, or if a U-turn is required to drive to the customer’s address.
Process overview: Order Orchestration uses the integration with Oracle Maps Cloud Service to determine the turn-by-turn distance of potential fulfilling locations as follows:
-
Submits the customer location to Oracle Maps Cloud Service determine its longitude and latitude.
-
Pre-qualifies potential locations based on straight-line distance:
-
Calculates the straight-line distance from each potential fulfilling location, based on the latitude and longitude of each.
-
Eliminates any location whose straight-line distance exceeds the maximum distance, either defined in the web service request or from the Maximum Turn-by-Turn Distance defined at the Preferences screen, as described below, or that does not have a latitude and longitude defined.
-
-
Submits a turn-by-turn request to Oracle Maps Cloud Service, providing the latitude and longitude of the customer’s location as the starting location, and the latitude and longitude of each potential fulfilling location within the specified maximum distance from the customer’s location.
-
When Oracle Maps Cloud Service returns the actual turn-by-turn distances, Order Orchestration omits any locations whose turn-by-turn distance exceeds the defined maximum distance from consideration. For example, the maximum distance is defined as 15 miles. The distance for location A was 14.78 miles based on the initial pre-pass calculation, but is 15.5 miles based on the turn-by-turn calculation. As a result, location A is not included in the list of eligible locations.
When does turn-by-turn distance evaluation take place? This calculation takes place when:
-
You use Order Maps Cloud Service, and have completed the Geocode setup at the Tenant-Admin screen, including entering a valid Turn-by-Turn Distance URL.
-
The carrier specified for the request or order matches the Carrier for Turn-by-Turn Distance Evaluation specified at the Preferences screen.
-
Order Orchestration needs to find a fulfilling location for a delivery order in response to:
-
Locate items: When:
-
The fulfillment_type in the locate items request is DELIVERY, and
-
The <ship_via> is the Carrier for Turn-by-Turn Distance Evaluation.
The Maximum Turn-by-Turn Distance and unit of measure are used.
If the request message specifies a requested_location, only that location is returned in the response message, with a distance of 0.0.
-
-
Product availability: When:
-
A type of is DELIVERY is specified in the product availability search request and,
-
The ship_via is the Carrier for Turn-by-Turn Distance Evaluation.
The range_distance and range_unit, if any, specified in the request are used; otherwise, the Maximum Turn-by-Turn Distance and unit of measure are used.
-
-
Submit Order request: When:
-
The transaction_type_id is DELIVERY in the submit order message, and
-
The ship_via is the Carrier for Turn-by-Turn Distance Evaluation.
The submit order request does not specify a distance or unit of measure, and the Maximum Turn-by-Turn Distance and unit of measure are always used.
Status Update rejecting the order or line: When:
-
The order type for the order specified in the status update request message rejecting the order or line is DELIVERY, and
-
The ship via is the Carrier for Turn-by-Turn Distance Evaluation.
The status update request does not specify a distance or unit of measure, and the Maximum Turn-by-Turn Distance and unit of measure are always used when the order or order line is rejected.
-
-
Rejecting an order or line in order inquiry: When:
-
You change the status to rejected at the Order screen or the Edit Order Item window, if the order type is DELIVERY, and
-
The ship via is the Carrier for Turn-by-Turn Distance Evaluation.
There is no option to specify a distance or unit of measure in order inquiry, and the Maximum Turn-by-Turn Distance and unit of measure are always used in this case.
-
Troubleshooting:
-
As with straight-line distance evaluation, the Shop Order When Proximity Unknown preference controls how to handle submit order requests when the proximity cannot be determined. See that preference for more information.
-
The Trace Shopping Log screen indicates when a location is eliminated from consideration based on distance, including turn-by-turn distance, with a Reason of Proximity Distance. The distance used as a criterion is indicated.
-
Turn-by-turn distance evaluation is enabled for a maximum of 50 locations within the requested distance. If there are more than 50 locations, the search will fail.
Note:
-
When you configure Carrier for Turn-by-Turn Distance Evaluation at the Preferences screen, Order Orchestration does not confirm that the Turn-by-Turn Distance URL is configured at the Tenant-Admin screen.
-
Similarly, Order Orchestration does not check whether there are any organizations configured for turn-by-turn distance at the Preferences screen if you do not set the Turn-by-Turn Distance URL setting at the Tenant-Admin screen.
For more information: See Using the Oracle Maps Cloud Service API for background and additional setup information.
Same-Day Delivery
The routing engine supports identifying and tracking same-day delivery orders using the following messages:
-
Requests and responses for existing orders: A delivery_service_level of “SAME_DAY” is returned for an existing order when the order type is DELIVERY and the submit order request message creating the order included a ship via code matching the Carrier for Turn-by-Turn Distance Evaluation preference setting for the organization.
-
Fulfillments Response
-
Order Inquiry Status Response
-
Order Status List Response
-
Order Search Response
-
-
Product Availability Response: Included in the response when a fulfillment type of DELIVERY and ship via code that matches the Carrier for Turn-by-Turn Distance Evaluation preference setting for the organization are specified in the request.
The delivery_service_level attribute is available only when a version of 23.2 is specified in the request.
Delivery ID: The delivery_id is a unique identifier generated by the originating application that requests to book a courier for a same-day delivery order, and will be passed in a fulfilled status update request message. This attribute is available in the following version 23.2 messages:
-
Status Update request
-
Order Inquiry Status response
-
Order Status List response
-
Order Search response
Troubleshooting Fulfillment or Sourcing Location Selection
Because there are various factors that can affect how the Routing Engine eliminates potential locations from selection as fulfilling locations (order “shopping”), you can use the Trace Shopping Log screen as needed to research shopping logic and resolve questions. This screen provides a listing of the potential product locations for an order, and indicates the reason, if any, why each location is eliminated, including:
-
Not supporting the order type
-
Not having sufficient inventory
-
Probability rule
-
Maximum order limit
-
Zone fulfillment
-
Proximity distance
-
Shopping within system not allowed
-
Not supporting gift wrap
-
Attribute incompatibility
Note:
Oracle recommends that you turn on shopping logic tracing to research questions related to how the routing engine is selected locations, but to otherwise keep tracing turned off in order to enhance system performance.For more information: See the Trace Shopping Log for a discussion and more details.
Acknowledge Order Before Brokering
If the Acknowledge Order Before Brokering flag is selected at the Preferences screen, Order Orchestration generates the submit order response before selecting a fulfilling location for a delivery order. This option enables Order Orchestration to respond more quickly to submit order requests, especially if you process large, multi-line orders.
If this flag is selected, when a system submits a delivery order that does not specify a fulfilling location:
-
Order Orchestration validates just basic order information, such as address, products, and originating system and location, before acknowledging the order in the submit order response message.
-
The order lines are initially assigned to the IN PROCESS location, a virtual location used temporarily until Order Orchestration completes the fulfilling location selection process, including all shopping logic such as fulfillment zone evaluation, interactive inventory inquiry, and probability rules.
-
Order Orchestration creates the IN PROCESS location if it does not already exist. This location is:
-
assigned to the same system and location type as the default shipping (unfulfillable) location
-
created with the Pickup Available, Delivery Available, Backorder Available, Ship For Pickup Sourcing Available, Ship For Pickup Receiving/Pickup Available flags at the Preferences screen all set to No
-
assigned the name Brokered Order Temporary Location
-
-
The submit order response message always specifies the IN PROCESS location for a delivery order unless the request message specified a fulfilling location.
-
The order is created with a hidden in_process flag that is set to Y until Order Orchestration completes location assignment for the order. As long as this flag is set to Y, no lines on the order are eligible to be included in the fulfillment response message.
-
The originating system needs to submit a status inquiry request after initial order creation to determine the selected fulfilling location.
-
If the originating system cancels an order or line while it is still assigned to the IN PROCESS location, Order Orchestration does not assign the order to an actual fulfilling location.
-
Order Orchestration does not delay processing or assign a rejected order or line to the IN PROCESS location; instead, it “reshops” the order or line immediately.
-
If an order or line is still assigned to the IN PROCESS location when Order Orchestration receives a status update to cancel it, or of the line is in any status other than new_order, Order Orchestration does not attempt to find a fulfilling location for the order or line.
Cleanup process: A cleanup job runs automatically every hour to check for any orders or lines that were created more than an hour earlier and that are still assigned to the IN PROCESS location, and completes processing for these orders or lines.
Use the Reschedule All option at the View Active Schedules screen to resolve any scheduling
issues for the cleanup job. Note that the Reschedule All option
does not restart jobs that are in Paused status (
). Jobs stay in Paused status
only briefly before Order Orchestration restarts them automatically.
Note:
This cleanup job also attempts to send failed requests to RICS when you use Order Fulfillment through RICS Integration.The Acknowledge Order Before Brokering flag is selected by default. If this flag is not selected, Order Orchestration completes the fulfilling location selection process as it receives and creates each order, and specify selected fulfilling locations in the submit order response message.
Using Product Availability Search for a Pickup or Delivery Order
The Product Availability search message is similar to the LocateItems search, except that the Product Availability search:
-
can include more than one transaction type (pickup or delivery) in a single request, and each type can include its own search range distance
-
does not include product location details for delivery searches; instead, it indicates:
-
if the entire requested quantity can be satisfied; otherwise,
-
if a partial quantity of the requested items can be satisfied, the maximum Available to Promise quantity of each item
-
-
for a pickup request, always returns each item location that could partially fulfill the requested quantities of all requested items
Weighted brokering: If Use Weighted Brokering Rules is selected, product availability searches use the same process as the one described under Selecting the Location for a Pickup Order (LocateItems) and Selecting a Location for a Delivery Order:
-
Pickup: The Product Availability response includes the list of eligible pickup locations that have the item(s) available, sorted in order of proximity
-
Delivery: The Routing Engine sends the list of eligible locations, along with related data, to the Science Engine, which returns the responses described under Selecting a Location for a Delivery Order; the Routing Engine uses this information to populate the Product Availability response
Determining eligible locations and available quantities:
-
If Use Weighted Brokering Rules is not selected: Most of the existing Order Orchestration preferences and settings (such as proximity, Fulfillment criteria, probability rules, zone fulfillment, and the Backorder Available setting) apply to product availability searches essentially as they do to LocateItems requests.
-
If Use Weighted Brokering Rules is selected: See Selecting a Location for a Delivery Order for details on how the Routing Engine filters the list of eligible location and the information sent to the Science Engine
About the maximum available quantity: The Product Availability response message indicates a maximum_available quantity for items on delivery searches only if the full requested quantity(ies) of all items are not available in eligible locations. See below for examples on how the maximum_available quantity is used.
Product Availability Search: Pickup
When the Product Availability request specifies a PICKUP search type:
-
If there is at least one eligible location that could fulfill the specified quantities of all requested items, or are flagged as Backorder Available, the response_description is Success, and the response includes details on the product location(s).
-
if there are no eligible locations that could fulfill partial quantities or are flagged as Backorder Available, the response_description is Product not available within search criteria, and the response does not include any product locations.
-
If there is at least one eligible location that could fulfill partial quantities of all requested items, or that stock the item and are flagged as Backorder Available, the response_description is Product not available within search criteria, and the response includes details on the product location(s).
Example: The search request specifies item A with a quantity of 5, and item B with a quantity of 10. The response_description is Product not available within search criteria, and the response includes details on a location that has:
-
5 of item A (full quantity) and 9 of item B (partial quantity)
-
1 of item A (partial quantity) and 1 of item B (partial quantity)
-
5 of item A (full quantity) and none of item B, but is flagged as Backorder Available
Note:
The Maximum No. Responses setting at the Preferences screen does not limit the number of locations returned when the product availability type is PICKUP, and the sort order is not based on the Order Orchestration criteria specified at the Preferences screen or through the Order Orchestration Preference Overrides screen.
-
Product Availability Search: Delivery/Single Item
Note:
Determining whether a ship-for-pickup order can be sourced is very similar. See About Ship-for-Pickup Orders for key differences.When the Product Availability request specifies a DELIVERY search type for a single item, the Product Availability response message includes a response_description of SUCCESS, and does not indicate a maximum_quantity, if:
-
there is at least one eligible location that could fulfill the specified quantity of the requested item, or
-
the requested quantity could be fulfilled by splitting the line across multiple eligible locations, and the Use Split Line preference is set to Yes, or
-
there is at least one eligible location that is flagged as Backorder Available
Otherwise, the response message indicates Product not available within search criteria, and specifies the maximum_available quantity of the item. The maximum_available quantity is:
-
the total available quantity across all eligible locations if the Use Split Line preference is set to Yes; otherwise,
-
the highest available quantity for any eligible location.
If there are no eligible locations with a quantity available, the maximum_available is 0.
If Use Weighted Brokering Rules is selected, the Routing Engine uses the Science Engine to obtain this information; otherwise, the Routing Engine obtains the information.
Examples: If item AB100, quantity 10 requested:
| Scenario | Result |
|---|---|
|
Eligible locations include:
|
response_description: Success maximum_available: not indicated |
|
Eligible locations include:
|
response_description = Product not available within search criteria If Use Split Line =
|
|
Eligible locations include:
|
response_description: Success maximum_available: not indicated |
|
No eligible locations have any available quantity or are flagged as Backorder Available |
response_description = Product not available within search criteria maximum_available: 0 |
Product Availability Search: Delivery/Multiple Items and Split Order = No
Note:
Determining whether a ship-for-pickup order can be sourced is very similar. See About Ship-for-Pickup Orders for key differences.When the Product Availability request specifies a DELIVERY search type for multiple items and the Use Split Order preference is set to No, the Product Availability response message includes a response_description of SUCCESS, if:
-
there is at least one eligible location that could fulfill the specified quantities of all the requested items, or
-
there is at least one eligible location that stocks all the requested items and is flagged as Backorder Available
Otherwise, the response message indicates Product not available within search criteria.
Maximum_available never returned: Regardless of whether the response message indicates Success or Product not available within search criteria, when the Product Availability request specifies a DELIVERY search type for multiple items and the Use Split Order preference is set to No, the Product Availability response message never includes the maximum_available for the items.
Examples: If item AB100 and item CD200, quantity 10 each requested:
| Scenario | Result |
|---|---|
|
Eligible locations include location A:
|
response_description: Success |
|
Eligible locations include:
|
response_description = Product not available within search criteria |
|
Eligible locations include location A, flagged as Backorder Available:
|
response_description: Success |
Product Availability Search: Delivery/Multiple Items and Split Order = Yes
Note:
Determining whether a ship-for-pickup order can be sourced is very similar. See About Ship-for-Pickup Orders for key differences.When the Product Availability request specifies a DELIVERY search type for multiple items and the Use Split Order preference is set to Yes, the Product Availability response message includes a response_description of SUCCESS, and does not indicate a maximum_quantity for any items, if:
-
there is at least one eligible location that could fulfill the specified quantities of the requested items, or
-
the requested quantities of the items could be fulfilled by splitting the order across multiple eligible locations, or by splitting any of the lines across multiple eligible locations if the Use Split Line preference is set to Yes, or
-
any of the items that could not have their requested quantities fulfilled by eligible locations as described above are stocked in eligible locations that are flagged as Backorder Available
Otherwise, the response message indicates Product not available within search criteria, and specifies the maximum_available quantity of the item.
What does the maximum_available represent? When the full quantities are not available for all requested items and the Use Split Order preference is set to Yes, the maximum_available quantity is determined as follows:
-
If a full or partial quantity of one or more items is available across all eligible locations:
-
if the Use Split Line preference is set to Yes, the maximum_available is the total available quantity for the item across all eligible locations
-
otherwise, if the Use Split Line preference is set to No, the maximum_available quantity is the highest available quantity in any single eligible location
-
-
if a partial quantity of one or more items is available across all eligible locations, and one or more items are not available:
-
if the unavailable item(s) are stocked in any eligible locations flagged as Backorder Available, the maximum_available quantity for the unavailable item(s) is the requested quantity; otherwise,
-
the maximum_available quantity for unavailable items is 0.
-
Examples: If item AB100 and item CD200, quantity 10 each requested:
| Scenario | Result |
|---|---|
|
Eligible locations include location A:
|
response_description: Success no maximum_available indicated Location A can fulfill the requested quantities. |
|
Eligible locations include:
|
response_description: Success no maximum_available indicated Order can be split across location A and location B. |
|
Eligible locations include location:
|
response_description: Success no maximum_available indicated Although no eligible locations have sufficient inventory to fulfill the requested quantity of CD200, location B stocks CD200 and is flagged as Backorder Available. |
|
The Use Split Line preference = Yes, and eligible locations include:
|
response_description: Success no maximum_available indicated The second line can split across multiple locations if the Use Split Line = Yes. |
|
The Use Split Line preference = No, and eligible locations include:
|
response_description: Product not available within search criteria maximum_available:
|
|
The Use Split Line preference = Yes, and eligible locations include:
|
response_description: Product not available within search criteria maximum_available:
|
|
Eligible locations include:
|
response_description: Product not available within search criteria maximum_available:
|
About Ship-for-Pickup Orders
Important:
When you create a new organization in Order Broker 20.0 or higher, ship for pickup orders are automatically enabled, and in this case retail pickup and ship-to-store orders are not supported. When you update to Order Broker 21.0 or higher, ship for pickup orders are automatically enabled in all existing orders, and in this case retail pickup and ship-to-store orders are converted to ship-for-pickup orders.
What is a ship for pickup order? A ship for pickup order is one that the customer picks up at a specified location, and that can be sourced by either the placing location, the pickup location, or a third location. For example:
-
order placed in location A, inventory sourced from location B, and customer picks up in location C
-
order placed in location D, inventory sourced from location E, and customer picks up in location D
-
order placed in location F, inventory sourced from location F, and customer picks up in location G
-
order placed in location H, inventory sourced from location J, and customer picks up in location J
See Ship For Pickup Order for illustrations of possible order flows.
Typical ship for pickup order flow:
-
Pickup location selected: The customer selects a location for order pickup.
-
Inventory available? The placing location confirms that the inventory can be sourced.
Note:
The ProductAvailability message can be used both to search for pickup locations and to confirm that the merchandise is available for sourcing, given the fulfillment rules set up for the organization, including proximity, location zones, split order/line options, and probability rules. The LocateItems request can also search for sourcing locations, but does not support searching for pickup locations for ship-for-pickup orders. -
Order created: The order is created, and the pickup location specified. Optionally, the SubmitOrder request can also specify the sourcing location, or the Routing Engine can select it.
-
Sourcing location notified? If the sourcing location is different from the placing location, the sourcing location receives notification of the order through the Fulfillments response message.
Sourcing location ships to pickup location? If the sourcing location is different from the pickup location:
-
The sourcing location updates the status to Intransit when the order ships.
-
The pickup location receives notification of the order through the Intransit response message. This message is similar to the fulfillments response message, but includes only ship-for-pickup orders that are in transit to the selected pickup location.
-
The pickup location receives the order.
-
-
Order fulfilled: When the customer picks up the order, the pickup location updates the status to Fulfilled.
Can the pickup location reject the order? If the pickup location rejects the order, this indicates that there was a problem with the transfer from the sourcing location, such as a damaged or missing shipment. As a result, the Routing Engine “reshops” the order.
Note:
Important: Before converting an existing organization to support ship-for-pickup orders, confirm that all integrating systems can also support ship-for-pickup orders.Using LocateItems to Find a Sourcing Location for Ship-For-Pickup
When a LocateItems request specifies a fulfillment type of SHIPFORPICKUP, it also needs to specify the location where the customer wants to pick up the order. In this situation, the LocateItems request serves to confirm that the inventory is available for sourcing. Both the requesting location and the pickup location can be included in the search results if they have the requested inventory available and are otherwise eligible, since they can also serve as the sourcing location for a ship-for-pickup order.
Example: The LocateItems request requests availability for an item, with the ship-for-pickup location A. The response includes locations A, B, and C, indicating that location A can be both the sourcing location and the pickup location.
Potential sourcing locations must be flagged as Ship For Pickup Sourcing Available, based on the setting at the Preferences screen.
When calculating proximity, the Routing Engine uses the ship-for-pickup location specified in the LocateItems request message and the Sourcing Distance specified at the Preferences screen. The distance passed in the LocateItems request is not used.
Gift wrap? If the gift_wrap tag in the request is set to Y and the Use Attribute Rules flag is selected at the Preferences screen, only locations that are flagged to support gift wrap are eligible as pickup locations for the pickup order. The sourcing location for a ship-for-pickup order does not need to support gift wrap.
Custom product or location attributes? See Using Attribute Rules for Ship-for-Pickup Orders for a discussion on how you can use custom attributes to filter eligible locations.
Aside from these differences, using LocateItems to find a sourcing location is the same as the process described under Selecting a Location for a Delivery Order.
The LocateItems request does not support searching for pickup locations for a ship-for-pickup order. The ProductAvailability request should be used instead to generate a list of locations eligible for pickup or ship-for-pickup orders, as well as indicating whether the merchandise is available for sourcing.
Using Product Availability Search for a Ship-for-Pickup Order
When the ProductAvailability request specifies a fulfillment type of SHIPFORPICKUP, the response indicates:
-
whether the requested inventory is available for sourcing, and
-
the eligible pickup locations, excluding potential pickup locations if there is no existing system product for the system
In many respects, the product availability search for a ship-for-pickup order is similar to searching for delivery orders. The key differences are described below.
Selecting a Sourcing Location for a Ship-for-Pickup Order
The ProductAvailability search uses the following rules when searching for sourcing locations:
-
Potential sourcing locations are identified based on the Ship For Pickup Sourcing Available setting at the Preferences screen.
-
The Sourcing Distance specified at the Preferences screen always applies when searching for a sourcing location. The range_distance from the product availability request applies only when selecting the list of eligible pickup locations. When calculating proximity for the sourcing location, the Routing Engine uses the address specified in the ProductAvailability request message.
-
Both the requesting (placing) location and the pickup location are evaluated as potential sourcing locations.
-
If the requested item(s) are not available for sourcing in the full requested or partial quantity(ies), no pickup locations are returned in the response.
-
Selecting a Pickup Location for a Ship-For-Pickup Order
The submit order message for a ship-for-pickup order needs to specify the pickup location and system. You can use the product availability message to request a listing of locations that should be able for pickup of a ship-for-pickup order near the customer’s location. A system product must exist in the potential pickup location’s system.
| Sourcing Scenario | Example |
|---|---|
|
Is the requested item available for sourcing? In order for the product availability response to include any eligible pickup locations, it is necessary for at least a partial quantity of the requested item be available at an eligible sourcing location. If there is more than one item specified in the request, then at least one of the items must be at least partially available. Which locations are eligible to be pickup locations for a ship-for-pickup order? A ship-for-pickup order means that the customer will pick up the product(s) in a location where the inventory might already be available, or it might need to be transferred from a different location. If the product availability request message indicates that the fulfillment type is a ship-for-pickup:
|
Example: A customer wants to pick up an item at a nearby store. The ProductAvailability request indicates:
Provided the full requested quantity of AB100 is available at any sourcing locations, the ProductAvailability response returns a description of Success, indicating that the item can be sourced, and lists:
If only 4 units of the product are available, the response indicates Product not available within search criteria, and lists the maximum_available quantity of 4. |
If the placed (originating) location is specified as the sourcing location: The SubmitOrder message can indicate a sourcing location that is the same as the placed (originating) location. In this situation:
-
The Routing Engine does not search for a sourcing location.
-
The Routing Engine does not confirm that the inventory is available at the placed/sourcing location.
-
The Reserved Quantity is not increased.
-
The order count is not increased for calculation of Maximum Daily Orders.
-
The order is not included in the fulfillments response message to the placed/sourcing location.
If the sourcing location is not specified in the request, it is possible for the Routing Engine to select the placed location to source the order. In this situation, the Routing Engine treats the order the same way as any other ship-for-pickup order; for example, the Reserved Quantity is increased, the order count is increased, and the order is included in the fulfillments response message.
Aside from these differences, using the ProductAvailability request to find availability and pickup locations for a ship-for-pickup order is the same as the process described under Using Product Availability Search for a Pickup or Delivery Order.
Using Attribute Rules for Ship-for-Pickup Orders
You can set up custom attributes to filter the locations eligible to source orders, or where orders can be picked up.
Custom attributes are used only if Use Attribute Rules is selected at the Preferences screen.
These rules apply when filtering locations for LocateItems, ProductAvailability, and SubmitOrder requests. They also apply when “reshopping” orders as a result of a StatusUpdate request or when the order is rejected through the user interface. If there have been any changes to the attribute assignments to locations or the product since the order line was created, the current attribute assignments apply.
Note:
This setting also controls whether to filter pickup locations when gift wrap is required.Examples:
| Attribute Usage | How to Implement |
|---|---|
|
Product A always requires engraving, so only locations that support engraving can fulfill orders for this product. |
Setup:
|
|
Product B is eligible for engraving, but can also be ordered without it. The individual request for the product indicates whether engraving is required. |
Setup:
|
|
Location 100 is associated with brand ABC. Your organization includes store locations associated with multiple brands, but only locations that are associated with Brand ABC can serve as pickup locations orders for the brand. The sourcing location does not need to be associated with the originating brand. |
Setup:
Web service responses: The LocateItems response, ProductAvailability response, SubmitOrder response filter eligible locations to Location 200 and Location 300, because they are both assigned a Value of ABC with a Location Use of Pickup. Note: The same results would occur if, instead of assigning the brand attribute with a Value of ABC and a Location Use of Originating to location 100, the brand attribute was passed in the request message with a value of ABC. |
Attribute setup options: You can use the following options when setting up attribute definitions:
-
Attribute Type: Attributes can filter eligible locations based on:
-
Location and Product: The location must be consistent with an attribute defined for the product. The attribute might be a universal requirement, such as the engraving required example above, or specified on a case-by-case basis, such as the optional engraving example.
-
Location: The location must be consistent with an attribute defined for the originating location. The requirement applies to the pickup location for a pickup and to the sourcing location for a delivery order. For a ship-for-pickup order, the requirement can apply to the sourcing location, the pickup location, or both, based on the Ship For Pickup Match Type set for the attribute definition.
-
Product Type: Although you can create attributes with an Attribute Type of Product, these attributes are informational only and not used to route orders.
-
Data Type: Possible attribute data types are:
-
Boolean: The attribute is used to route orders if the Boolean is assigned to the product or originating location, such as the engraving examples above. An assigned Boolean is interpreted as True. Negative Boolean attributes are not supported.
-
List: Defines a list of valid values, such as the brand example above. When the attribute is used to route orders, there must be a match with one of the list values.
-
Text: Similar to the List data type, except it is not validated against a defined list of values.
-
Number: Similar to the List data type, except it is not validated against a defined list of values, and must be numeric.
-
-
Allow Multiple:
-
Locations: Controls whether the attribute can be assigned more than once to a single location with different values and the same Location Use (Originating, Sourcing, or Pickup). For example, a location can support multiple brands. Even if the attribute is set to not allow multiples, a different attribute value can be assigned to the location for each different location use; for example, a location can support engraving when it is a sourcing location, but not when it is a pickup location. Regardless of the Allow Multiple setting, only a single value can be assigned to a location when the Location Use is Originating.
-
Products: Controls whether the attribute can be assigned more than once with different values to the same product.
The Allow Multiple setting does not apply to Boolean attributes, and cannot be selected.
-
-
Ship For Pickup Match Type: Controls whether the attribute needs to match the sourcing location, the pickup location, or both the sourcing and the pickup location for a ship-for-pickup order. Does not apply to delivery or pickup orders.
-
Filter based on multiple attributes? It is possible for multiple location, or product and location attributes to filter eligible locations. For example, one attribute can filter locations that do not support engraving, while another attribute can filter locations based on brand. All attributes apply, regardless of whether:
-
They have been assigned to the product or any potential sourcing or pickup locations;
-
They are passed in the LocateItems, ProductAvailability, or SubmitOrder request message;
-
They were initially applied to the order line at the time that it was created, and it is now being “reshopped.”
A location is excluded if it does not qualify based on all location or product and location attributes. For example, the Brand attribute is applied to location 1 with a Location Use of Originating and a value of ABC, and a LocateItems request from location 1 with a Pickup fulfillment type passes the Brand attribute with a value of brand DEF. Only locations that are assigned both ABC and DEF with a Location Use of Pickup can be eligible as pickup locations.
Considerations for Upgrade to 21.0
If ship-for-pickup orders were not previously enabled in your organization prior to the 21.0 update:
-
Integrating systems must support ship-for-pickup: Do not upgrade to 21.0 if any integrating systems do not support a third location besides the originating (placed) location and the pickup location.
-
Existing orders permanently converted: When ship-for-pickup orders are enabled, all delivery and ship-for-pickup orders are converted to ship-for-pickup orders, and cannot be changed back.
-
Reset fulfillment options: After ship-for-pickup orders are enabled, you need to use the Preferences screen to set the options at the Fulfillment tab, including the Sourcing Distance. You can also use the Order Orchestration Preference Overrides screens to set up overrides.
-
Reschedule reports: After converting an existing organization to support ship-for-pickup orders, you should recreate any currently scheduled Order Status or Unfulfillable reports.
-
Ship-to-store orders and Store Connect use:
If you previously processed ship-to-store orders and use Store Connect, these orders will be converted to ship-for-pickup orders, which cannot be fulfilled through the Store Connect user interface.
Additional Differences When Ship-For-Pickup is Enabled
Additional web service and screen differences to note when ship-for-pickup orders are enabled in an organization are described below.
Routing Engine Setup for Ship-For-Pickup
When ship-for-pickup orders are enabled, the Fulfillment tab of the organization’s Preferences screen includes:
-
Sourcing Distance: Indicates the maximum distance a potential routing location can be, based on:
-
the ship-for-pickup location, if specified (LocateItems request, SubmitOrder request, or “reshop”), or
-
the address specified in the Product Availability request
-
-
Ship For Pickup Sourcing Available: Controls whether a location is eligible to source a ship-for-pickup order
-
Ship For Pickup Receiving/Pickup Available: Controls whether a location is eligible to be a pickup location for a ship-for-pickup order
These last two options replace the Retail Pickup Available and Ship To Store Available options when ship-for-pickup orders are enabled or after the 21.0 update. These differences also apply to the Order Orchestration Preference Overrides screens.
Aside from these differences, Routing Engine logic works the same way when selecting a sourcing location for a ship-for-pickup order as it works when selecting a fulfilling location for a delivery order. All the brokering settings, such as split order, zone fulfillment, acknowledging orders before brokering, and probability apply the same way for ship-for-pickup processing as they would for any other type of order.
SubmitOrders
When the SubmitOrder message specifies a fulfillment type of SHIPFORPICKUP, it also needs to specify the pickup location for the order. It can also include the sourcing location. If no sourcing location is specified in the message, the Routing Engine “shops” the order as described above and selects the sourcing location.
Fulfillments
The fulfillments response message includes orders only when the request is from the sourcing location. The pickup location receives notification of incoming orders from the Intransit response.
Intransit
This web service request resembles fulfillments request processing, but serves only to notify pickup locations about ship-for-pickup order that are in transit.
Other Web Service Differences
Fulfillments response, status inquiry response, status list response, order search response: These response messages indicate the pickup locations for ship-for-pickup orders.
Screen Differences
Certain screens display different options based on whether ship-for-pickup orders are supported:
-
Preferences screen: Options available at the Fulfillment tab vary, as described above.
-
Order Orchestration Preference Overrides: Different order types are available to configure based on whether ship-for-pickup is supported.
-
Run Reports, Schedule Report: The sourced location is available for selection when generating the Order Status report, and the report includes the sourced location.
-
Order Inquiry: When ship-for-pickup orders are enabled for an organization, the Order Inquiry screen has the Locations column broken out into three columns to indicate the Placed Location, Sourced Location, and Pickup Location. The search criteria also vary from those displayed for an organization that does not support ship-for-pickup orders. Similar differences apply to the Order screen and the Edit Order Item and Display Order Item windows.
Troubleshooting Fulfillment or Sourcing Location Selection
Because there are various factors that can affect how the Routing Engine eliminates potential locations from selection as fulfilling locations (order “shopping”), you can use the Trace Shopping Log screen as needed tor research shopping logic and resolve questions. This screen provides a listing of the potential product locations for an order, and indicates the reason, if any, why each location is eliminated, including:
-
Not supporting the order type
-
Not having sufficient inventory
-
Probability rule
-
Maximum order limit
-
Zone fulfillment
-
Proximity distance
-
Shopping within system not allowed
-
Not supporting gift wrap
-
Attribute incompatibility
Note:
Oracle recommends that you turn on shopping logic tracing to research questions related to how the routing engine is selected locations, but to otherwise keep tracing turned off in order to enhance system performance.For more information: See the Trace Shopping Log screen for a discussion and more details.
Routing Engine Message Summary
Overview: The request and response messages that support the Routing Engine are briefly summarized below. See the Web Services Guide on My Oracle Support (2953017.1) for links to detailed information on each message, including layouts, sample messages, and message contents.
LocateItems: These messages are part of the typical flow for creating pickup orders. Their use is optional for creating other types of orders, because the Routing Engine uses the same steps to select a location for a delivery order or the sourcing location for a ship-for-pickup order as it uses to create the response to the LocateItems request.
-
Request: Look for locations that should be able to fulfill a pickup or other type of order, or source a ship-for-pickup order, for one or more items. Includes information on the customer’s location or ship-for-pickup location for proximity purposes.
-
Response: Lists the location(s) that should be able to fulfill or source the product(s) specified in the request message. Based on your Order Orchestration settings at the Preferences screen, the response for a delivery or ship-for-pickup request can list information on individual locations, or just indicate that the product(s) can be shipped.
Product Availability (multiple fulfillment types): Request availability information for one or more items and one or more fulfillment types (delivery, pickup, or ship-for-pickup):
-
Request: Look for locations that should be able to fulfill a pickup order or where the customer could pickup up a ship-for-pickup order, or confirm whether a delivery, or ship-for-pickup order could be fulfilled or sourced. Includes information on the customer’s location for proximity purposes.
-
Response: Lists the location(s) that should be able to fulfill the product(s) specified in the request message for a pickup order, or whether a delivery, or ship-for-pickup order could be fulfilled or sourced.
SubmitOrder: Requests creation of the order and might also request assignment of a fulfilling or sourcing location, depending on the order type. See Types of Orders for more information.
-
Request: Includes information such as:
-
the requesting location and system
-
the requesting system’s order number
-
requested item(s), quantities, prices, and tax charges
-
name and address of the sold-to customer
-
for a pickup order, the location where the customer will pick up the order
-
for a delivery or ship-for-pickup order, shipping address information
-
order total and subtotal amounts
-
optionally, special instructions
-
optionally, tender amounts and other information (Note: The message should not include the actual credit card account number.)
-
-
Response: Once it has created the order, the Routing Engine sends a simple response message acknowledging the order, confirming the fulfilling or sourcing location and system, and indicating the request ID it has assigned to uniquely identify the order.
Fulfillments (polling for new orders): Each location that might need to fulfill or source any orders needs to poll the Routing Engine periodically for any newly assigned orders or lines. Alternatively, a system can submit a fulfillment request to poll for orders assigned to all its related locations.
-
Request: A location or system identifies itself in order to request a listing of newly-assigned orders.
-
Response: Lists details on the order, such as customer name and address, order type (pickup, delivery, or ship-for-pickup), requested items and quantities, and special order messages. If the Require Status Update flag for the location’s system is unselected, then the Routing Engine sends each order just once to the fulfilling or sourcing location and does not require confirmation. See Require Status Update for Assigned Orders? below for a discussion.
Intransit (polling for ship-for-pickup orders in transit to pickup location): Each location that might receive any ship-for-pickup orders for customer pickup needs to poll the Routing Engine periodically for any in transit orders or lines. Alternatively, a system can submit an intransit request to poll for orders in transit to all its related locations.
-
Request: A location or system identifies itself in order to request a listing of in transit ship-for-pickup orders.
-
Response: Lists details on the order, such as customer name and address, requested items and quantities, and special order messages. If the Require Status Update flag for the location’s system is unselected, then the Routing Engine sends each order just once to the pickup location and does not require confirmation. See Require Status Update for Assigned Orders? below for a discussion.
StatusUpdate: Change the status of an existing order or line. Any location can send a status update to the Routing Engine, including the originating location and the fulfilling, sourcing, and pickup location; however, certain status updates are restricted to the fulfilling, sourcing, or pickup location.
-
Request: Identifies the requesting system and location, the order or line, and the new status to assign. Status updates apply at the order level if the Allow Split Order preference is unselected; otherwise, they apply at the line level. Also, status updates must specify the quantity to update if the Allow Partial Updates preference is selected.
-
Response: Indicates whether the status update was successful.
Important:
If the Allow Partial Updates preference is selected, before a system sends a status update, it should first send a status request message so that the status update correctly identifies the current Order Orchestration line number.StatusRequest (order status inquiry): At any point in the order or fulfillment process, any location can send an order status inquiry request to the Routing Engine.
-
Request: Provides the order ID and request ID that uniquely identify the order.
-
Response: Indicates the current order and line statuses and the name and address of the sold-to customer.
OrderSearch (search for orders for a customer): At any point in the fulfillment process, any location can send an order search request to the Routing Engine.
-
Request: Includes search criteria such as information on the sold-to customer or shipping address, including name, phone number, or email address. Can also specify a date, to request a list of orders created on or after that date.
-
Response: Includes details on all orders that meet the search criteria.
Order Update (update the Under Review flag for an order): At any point in the fulfillment process, a system can update the setting of the Under Review flag, indicating whether the order is eligible for fulfillment:
-
Request: Indicate the order to update and the setting of the Under Review flag.
-
Response: Indicate whether the update was successful.
Order Status List (request the current status of a list of orders): At any point in the fulfillment process, a system can request the current status of a list of up to 2000 orders:
-
Request: Request the current status of a list of orders by specifying the request IDs, and can optionally specify to include orders based on the status of the order lines.
-
Response: Provides the status and other summary information about the requested orders.
Availability Update (change the current available quantity for a product location): At any point, the system can update the available quantity for one or more product locations:
-
Request: Specifies whether to increase, decrease, or reset the available quantity for one or more product locations. If the product location does not already exist, it is created.
-
Response: Indicates whether each product location was updated successfully.
For more information: See the Web Services Guide on My Oracle Support (2953017.1).
Require Status Update for Assigned Orders?
Overview: The Require Status Update flag for a system controls the updates that take place for fulfillments response processing and intransit response processing.
Note:
A status update is not required to set the status to polled when you use Order Fulfillment through RICS Integration, regardless of the setting of the Require Status Update flag.Fulfillments Response Message
Fulfilling or sourcing locations: You can specify whether the Routing Engine requires confirmation that an assigned fulfilling location, or sourcing location for a ship-for-pickup order, has been notified of an order or line included in the fulfillment response message. The Require Status Update flag setting for a system controls whether the confirmation is required.
If the Require Status Update flag is:
-
Selected = the Routing Engine continues to include an order in the fulfillment response message to an assigned fulfilling or sourcing location or system, until the location or system sends a status update indicating that the order or order line is polled (all order types) or accepted (pickup, delivery, or ship-for-pickup orders). When the Routing Engine receives this status update, it flags the order or line as polled.
Possible risk: With this setting, there is a potential risk that an order could be created twice in the integrating system if, for example, that system does not complete creating the new orders in the fulfillments response message and sending the status update messages for them before it sends a new fulfillments request message to Order Orchestration.
-
Unselected = the Routing Engine includes each order or line just once in the fulfillment response message to an assigned fulfilling or sourcing location. If the order or line status was new_order, it changes the status to polled.
Possible risk: With this setting, there is a potential risk that an order might not be created in the integrating system if, for example, the integrating system does not receive the fulfillments response, or fails to create all orders in the response.
Polling count: Each time the Routing Engine includes an order in the fulfillment response message, it increases the order line’s Poll Count. Once an order’s Poll Count exceeds the Polling Retries specified for the system, the order is eligible to be included in the Polling Status Email, notifying the system administrator of unacknowledged orders for the location.
Note:
Until the order or lines are flagged as polled, the Routing Engine continues to include the order in the fulfillment response message even after it was included in the Order Orchestration Polling Status Email.Splitting orders?
If the Allow Split Order preference is selected, each order line on a delivery order can be assigned to a different fulfilling location, or each order line on a ship-for-pickup order can be assigned to a different sourcing location, or be assigned at a different time. As a result, the Routing Engine evaluates the Poll Count of each order line separately, and does not send the Order Orchestration Polling Status Email unless an individual line exceeds the Polling Retries setting.
Example: The Polling Retries for a system is set to 5. If line 1 has a current Poll Count of 4 and line 2 has a Poll Count of 3, the Routing Engine does not include the order in the Order Orchestration Polling Status Email. However, if one of the lines has a current Poll Count of 6, the Routing Engine includes the order in the Order Orchestration Polling Status Email.
If the Allow Split Order preference is unselected, all order lines are assigned to the same fulfilling location, or sourcing location in the case of ship-for-pickup orders. In this case, the Poll Count of each order line is the same.
Example: The Polling Retries for a system is set to 5. If each line has a Poll Count of 4, the Routing Engine does not include the order in the Order Orchestration Polling Status Email. However, if each line has a Poll Count of 6, the Routing Engine includes the order in the Order Orchestration Polling Status Email.
Flagging an order or order line as polled vs. polled order status: Sending the status update flags the order or line as polled and prevents it from being included in future fulfillment response messages; however, this status update does not necessarily change the status to polled. For example, setting the status to accepted also serves to flag the order or line as polled and prevent it from being included in future fulfillment response messages.
Consistent setup in integrated system: It is important that the integrated system is set up consistently with the Require Status Update and related settings in Order Orchestration; otherwise, the integrated system might not send status update messages for newly assigned orders or lines, and the Routing Engine might continue to include the same orders or lines in the fulfillment response message, resulting in duplicate orders in the integrated system. For example, if the Require Status Update flag is selected for the Order Administration System system in Order Orchestration, then the Re-Polling for Orders Brokered to OROMS (L04) system control value in Order Administration should also be selected.
Clearing the poll count: The Routing Engine resets the Poll Count to 0 if a fulfilling location rejects an order or order line, or if its status changes to canceled, unfulfillable, or fulfilled.
Polling Status Email
The Routing Engine sends this email to the System Ops Email address specified for the system at the Orders tab on the System screen. The email lists each order with an order line whose Poll Count has exceeded the system’s Polling Retries setting.
No email is generated for orders that exceed the Polling Retries setting based on the intransit response message.
The language used for the email is based on the Language specified for the organization, and the formatting of dates, times, and numbers is also based on the organization-level settings. See the Organizations screen for more information.
Different poll counts? If there are multiple order lines assigned to the fulfilling location, the order might be listed more than once when multiple lines exceed the Polling Retries setting based on different Poll Count totals.
Example:
-
Same poll count: Order 123 includes line 1 and line 2. each with a Poll Count of 5. The email lists the order once with a Times Polled of 5.
-
Different poll counts: Order 456 includes line 1 with a Poll Count of 5, and line 2 with a Poll Count of 6. The email lists the order twice, once with a Times Polled of 5, and once with a Times Polled of 6.
How often? The Routing Engine uses the number of minutes indicated for the Email Notifications job to determine how often to generate the email.
****ATTENTION****
The following orders have been sent multiple times and not confirmed as received.
System Code: cws(Store)
Date/Time : 10/21/2016 1:53:22 PM
| Location | Request ID | Order # | Times Polled |
|---|---|---|---|
|
317 Sample Loc 317 Sample Loc 317 Sample Loc 317 Sample Loc 317 Sample Loc |
68866 68907 68913 68918 68918 |
7854 7857 7859 7861 7861 |
11 10 10 9 8 |
Please do not respond to this message.
--Order Orchestration
Intransit Response Message
Pickup locations: In addition to controlling the updates that take place for fulfilling and sourcing locations as a result of the fulfillments response message, the Require Status Update flag also controls the updates that take place for pickup locations as a result of the intransit response message. This message is used only for ship-for-pickup order types.
If the Require Status Update flag is:
-
Selected = the Routing Engine continues to include a ship-for-pickup order in the intransit response message to a pickup location or system, until the location or system sends a status update indicating that the order or order line is intransit polled.
-
Unselected = the Routing Engine includes each ship-for-pickup order or line just once in the intransit response message to a pickup location, and then changes the status to intransit polled.
Polling count: The polling count for the order line is initially set to 0 when it is in transit. Each time the Routing Engine includes an order or line in the intransit response message, it increases the order line’s Poll Count.
Note:
Unlike the rules for the fulfillment response, the rules for the intransit response do not include generating the Order Orchestration Polling Status Email when an in transit order exceeds the Polling Retries specified for the system.Calculating the Available to Promise Quantity
Overview: Each integrated system has its own rules for calculating an item’s available quantity based on the on-hand quantity, open orders, pending transfers, and other related data. In Order Orchestration, you have the option of configuring a system to subtract order lines in certain statuses from the reported available quantity in order to make the availability calculation more accurate. When an order line is in one of these statuses, that quantity in that fulfilling location is considered reserved for the order, and not available to fulfill any other orders.
Example: The available quantity reported by a system for a product location is 37; however, the location is assigned to fulfill an order for 4 units, and the order is in new_order status, indicating that the location has not yet polled for new orders and been notified of this order assignment. As a result, the effective available quantity is actually 33 (37-4). You can configure the system to consider order lines in new_order status as reserved, and subtract the total quantity of order lines in this status from the reported available quantity to determine the effective available quantity for a fulfilling location.
Fulfilled quantity: You can also track the Fulfilled Quantity in order to subtract it from the available quantity.
Ship-for-pickup orders: When the order type is ship-for-pickup, the Fulfilled Quantity is updated for the sourcing location when the order is fulfilled at the pickup location.
The Available to Promise quantity for a product location is equal to the available quantity minus the reserved and fulfilled quantity.
Reserved Quantity Calculation
When does Order Orchestration subtract the reserved quantity? When Order Orchestration responds to a LocateItems request or a product availability request, assigns a location for an order line, evaluates probability rules, or evaluates whether a location specified for an order can fulfill the order, it subtracts the reserved quantity from the available quantity last reported for the location. For example, if the available quantity in a product location is 10, but there are 9 units of this product on other order lines assigned to that fulfilling location in a reserved status, then Order Orchestration determines that the available quantity to return in the LocateItems response message, or qualify for a new order, is 1.
Examples: The following table presents examples on how you might subtract the reserved quantities for two different systems:
| System Rules | Sample Setup | Sample Result |
|---|---|---|
| System subtracts reserved order lines: System 123 (Order Administration) calculates available quantity as On hand - Protected - Reserved - Reserve Transfer - Backordered = Quantity available and reports the result to Order Orchestration; however, if an order is currently in new_order status in Order Orchestration, this indicates that system 123 has not yet polled for the order or been notified of its assignment. |
You select the Include Reserved flag for system 123, and select the New_Order status. |
System 123 reports a quantity available of 50 for item AB100 in location 10; however, there are currently 2 units of item AB100 assigned for fulfillment to location 10 on an order in new_order status. Order Orchestration subtracts the 2 units in new_order status and calculates a quantity available of 48. |
|
System does not subtract any order lines: System 789 reports on-hand quantity to Order Orchestration as the available quantity. |
You select the Include Reserved flag for system 789, and select the New_Order, Accepted, Picked, and Polled statuses. |
System 789 reports a quantity available of 30 for item AB100 in location 35; however, there are currently order lines for the item assigned to this location for fulfillment in the following statuses:
Order Orchestration subtracts a total of 10 units in the above statuses and calculates a quantity available of 20. |
When you select reserved statuses: When you configure this option for a system at the System screen, Order Orchestration automatically calculates the reserved quantity for each product location for the system by evaluating each item on order in all product locations. The number of affected product locations and order lines determines how long this calculation takes to complete.
Activities that update the reserved quantity: Any activity related to updating order or order line status can also update the reserved quantity for a product location if the system’s Include Reserved flag is selected. These activities include:
-
creating a new order through the SubmitOrder request message
-
updating an existing order status through the StatusUpdate request message or through the Order screen
-
receiving a fulfillments request message if the system is not configured to require a status update after polling; see Require Status Update for Assigned Orders?
-
fulfilling an order through Store Connect
Reviewing the available and reserved quantity for a product location: You can review the reported available quantity minus the reserve quantity at the Edit Product Location screen.
Fulfilled Quantity Calculation
Subtracting the fulfilled quantity: If tracking fulfilled quantity is selected for a system, the fulfilled quantity is also subtracted from the available quantity when calculating the Available to Promise quantity. Order Orchestration updates the fulfilled quantity for a product location when:
-
a location ships a delivery order: the fulfilled quantity increases by the shipped quantity
-
a customer picks up a pickup order: the fulfilled quantity increases by the picked up quantity
-
a customer picks up a ship-for-pickup order: the fulfilled quantity increases by the picked up quantity at the sourcing location
-
the fulfilled inventory export runs: if the Track Fulfilled Quantity field for the system is set to Reset at Inventory Export, the fulfilled quantity is set to 0, and the available quantity is reduced by the fulfilled quantity, calculated based on the xom_status_history records of the delivery or pickup orders that were included in the export
-
the product import runs: if the Track Fulfilled Quantity field for the system is set to Reset at Product Import, the fulfilled quantity is set to 0, but the available quantity is not updated
Examples of fulfilled quantity updates: If the Track Fulfilled Quantity field for the system is set to Reset at Inventory Export:
-
There are 10 units of an item in a location:
-
Available quantity = 10
-
Reserved quantity = 0
-
Fulfilled quantity = 0
-
Available to promise = 10
-
-
An order for 3 units is assigned and is polled. If the reserved statuses include polled orders:
-
Available quantity = 10
-
Reserved quantity = 0
-
Fulfilled quantity = 3
-
Available to promise = 7
-
-
The order is shipped:
-
Available quantity = 10
-
Reserved quantity = 3
-
Fulfilled quantity = 0
-
Available to promise = 7
-
-
The Fulfilled Inventory Export runs:
-
Available quantity = 7
-
Reserved quantity = 0
-
Fulfilled quantity = 0
-
Available to promise = 7
-
See the Track Fulfilled Quantity field at the System screen for more examples.
Reviewing quantities for a product location: You can review the Available Quantity, Reserved Quantity, Fulfilled Quantity, and the Quantity to Promise at the Edit Product Location screen and the Browse Product Locations window.
Resetting the fulfilled quantity: You can configure a system to reset the fulfilled quantity either when the fulfilled inventory export runs, or when the product import runs. See the System screen for more information.
Things to Note about Reserved and Fulfilled Quantity Calculation
-
Special items such as drop ships: If a system uses special available quantities to indicate a drop ship item, you can set up a probability rule to apply the special available quantity even if there is a reserved quantity. For example, Order Administration reports a quantity available of 9999 for a drop ship item, which is not stored in inventory in the warehouse but can still be reserved on new orders. You might set up a probability rule such as:
If Category Equal To [=] DROP
Then Available Quantity Equal [=] 9999
Applying a probability rule such as this can enable you to continue using business logic based on the available quantity of 9999 to identify special items such as drop ships.
-
What if the available quantity is negative? When you update a system to include a new status in the reserve quantity total, the effective available quantity that results for a location might be negative. For example, a location has 10 units available, with 11 units on orders that are in new_order status. If you update the system to include new_order items in the reserved quantity total, the resulting effective available quantity is -1; however, Order Orchestration does not update the currently assigned orders automatically. Instead, the location needs to reject the orders if it cannot fulfill them all.
-
Reserved statuses should exclude fulfilled: Do not include fulfilled order lines in the reserved statuses selected for the Store Connect system to avoid incorrect calculation of the Available to Promise quantity.
For more information: See the Fulfilled Inventory Export for background on exporting inventory updates to a system and ways to update the fulfilled quantity.
Reviewing or Updating Order Orchestration Orders
You can use the Order Inquiry and Order screens in Order Orchestration to review information about orders assigned to Order Orchestration for fulfillment. You can also update the orders’ status, or the fulfilling or sourcing location, if you have authority. The information displayed at these screens includes:
-
order number and request ID
-
sold-to and ship-to customers
-
originating and fulfilling locations; or placing, sourcing, and pickup locations for ship-for-pickup orders
-
details on ordered items, including quantity, pricing, and tax
-
current status
-
status and fulfilling or sourcing location history
-
special handling instructions
-
ship via and tracking number
-
order totals and balance due, if any
Updating order or order line status: A user with authority to Order Maintenance can update the status of an order (if the organization does not split orders) or the status of an order line (if the organization does split orders). If the Allow Partial Updates preference is selected, then the quantity is always required when you update status.
Updating the fulfilling or sourcing location for an order or line: A user with authority to Order Maintenance can update the assigned fulfilling or sourcing location for an order (if the organization does not split orders) or for an order line (if the organization does split orders). Reassignment is available only for delivery and ship-for-pickup orders. You cannot change the quantity when you change the fulfilling or sourcing location; the change always applies to the entire current quantity for the line.
For more information: See the Order screen for information on maintaining an order or order line.
Examples of Order Orchestration Process Flows
The examples presented below include integrations with Order Administration System, a POS system such as Oracle Retail Xstore Suite, and a web storefront. For example, you can connect one or more Order Administration system companies, one or more Xstore locations, and your web storefront, allowing the customer to locate merchandise anywhere in this group of locations.
Note:
The sample flow below:-
is illustrative of integration with Order Administration System and Xstore. Integrations between Order Orchestration and other systems will use a somewhat different flow.
-
does not reflect all current Order Orchestration options, such as the ability to split orders or lines, track reserved quantities, use zone fulfillment, or update partial line quantities.
Example: Searching for Items
Sample message flow: A typical scenario for locating products might be:
- A customer on the web storefront wants to check the availability of a particular product for pickup. The web storefront sends an inquiry, such as the locate items request, to Order Orchestration.
-
Order Orchestration’s database indicates that the product is stocked in the warehouse for your Order Administration company and in several Xstore locations.
-
Order Orchestration sends an inventory inquiry request to Order Administration System and to Xstore to check the current inventory for the requested product in the locations where it is stocked.
Note:
If any system is flagged as “off-line,” Order Orchestration does not attempt to check inventory on demand; instead, it uses the inventory information currently in the Order Orchestration database. -
The inventory inquiry response provides the product’s current available quantity in each location. Order Administration also provides information about any open purchase orders.
Note:
Order Orchestration updates the availability information for the product in its own database when it receives the information from each on-line system, creating new product locations if there was not previously a record of an item in one of the system’s locations. -
Order Orchestration retrieves the availability information for any off-line locations from its own database.
Note:
Even if a system is flagged as on-line, if Order Orchestration cannot connect to the system’s database, it retrieves the availability information from its own database. -
Order Orchestration sends the availability information back to the web storefront using the related response message. The customer then might have the option of creating a store pickup request at one of the locations where the product is available.
Example: Creating a Delivery Order in Xstore and Fulfilling it in Order Administration
Overview: The following screens illustrate the process of creating a delivery order in Xstore and sending it to Order Administration System Cloud Service for fulfillment.
Select order type: In Xstore, select Customer Delivery in order to have Order Administration System ship the order directly to the customer.
Enter additional information and locate items: After entering the customer’s name and address and selecting the ship via, use the Locate Item option to find a location where the merchandise is available for shipment. Behind the scenes:
-
Xstore sends a LocateItems request to the Routing Engine
-
The Routing Engine queries the Order Administration database for possible fulfilling locations, or checks its own database for the most up-to-date information
-
The Routing Engine applies proximity, probability, and your Order Orchestration preferences to the list of possible locations in order to determine which locations to return to Xstore, the availability information to include, and the order in which to sort the locations, for example:
-
always list distribution centers first
-
include certain locations even if the requested merchandise is backordered
-
include no more than 5 locations in the results
-
-
The Routing Engine uses the LocateItems response to return the results to Xstore
Note:
Depending on your business requirements and the type of order, you can also opt to have the Routing Engine select the fulfilling location.Complete order entry in Xstore: After selection of a ship via (which must map to an Order Administration ship via code) and completion of tender entry, Xstore sends the submit order request to the Routing Engine.
Order created in Order Orchestration: The Routing Engine creates the order in new_order status. The distribution center periodically sends a fulfillment request message to Order Orchestration to poll for newly-assigned orders.
Order created in Order Administration: When Order Administration receives the fulfillment response message, it uses the information to create an Order Orchestration record and the new order for processing, including:
-
customer name and address information
-
Xstore order number is the alternate order number
-
Pricing, tax, and other order totals from Xstore
-
Order Orchestration request ID saved in an order message
Fulfillment: Before printing a pick slip for the order Order Administration sends a status inquiry request to the Routing Engine to confirm that the order has not been canceled. As Order Administration puts the order through its normal process of pick slip printing, shipment, and billing, it sends order status updates to the Routing Engine with each change in status. When it ships the order, the information sent to the Routing Engine includes the ship via and tracking number, if available, so this information is available to Xstore when it sends its periodic status inquiry requests.
-
Data Hierarchy
Order Orchestration serves as a central repository of availability information for products from each of the integrated systems. Within an organization, one system serves as the default system for item/product information, and the products from other systems are associated with that default system’s product. Selecting the default system is an important step in the implementation process for Order Orchestration. For example, if you use Order Orchestration with Order Administration, then Order Administration System would typically serve as the default system, or system of record. You would create items and SKU’s in Order Administration and export them to Order Orchestration, along with location-specific data and availability information.
In order to understand how Order Orchestration handles availability information, it is important to review how it stores information on the products and systems that it integrates with.
Organization, System, and Location
The highest organizational level in Order Orchestration is the organization. The organization consists of any number of systems that will have the ability to communicate with Order Orchestration in performing searches for available inventory and, potentially, using the Routing Engine.
The organization includes various systems. A system, such as a company in Order Administration or an Xstore database, is integrated with Order Orchestration for the purposes of providing inventory availability information, requesting inventory availability information, or using the Routing Engine.
Systems can be on-line or off-line. Order Orchestration sends messages to on-line systems to get real-time inventory and waits for the responses. For off-line systems, Order Orchestration relies on the inventory information stored in Order Orchestration’s own database, which is typically scheduled to be updated daily or on some other periodic basis. Order Orchestration does not send a real-time request to off-line systems.
Each time Order Orchestration receives an inventory response from an on-line system, it stores the latest availability information for the product in its database. In this way, Order Orchestration can provide recent availability information even in the case of temporary communication problems.
A system can contain one or more locations, such as a warehouse in Order Administration or a store location in Xstore. Each location would contain inventory whose availability information should be made visible across the organization.
Each location is assigned to a location type, indicating whether it is a store, warehouse, or vendor. Location types are defined within each organization; for example, Pinnacle Company organization might include location types of Pinnacle stores and Pinnacle warehouses, while the Zenith Company organization includes Zenith stores and Zenith warehouses.
Your organization includes only the systems and locations that you have chosen to include in your Order Orchestration organization. For example, you can omit specific store locations or non-allocatable warehouses from your locations, or training or test companies from your systems.
Product, System Product and Product Location
Order Orchestration provides availability information for the specific products that you have added to Order Orchestration’s database.
A product, such as a pen, might be identified by a different code, ID or barcode across the systems in your organization; however, Order Orchestration’s database cross-references this same product across the various systems. Each instance of the same product in the various systems represents a system product.
For example, you sell a pen as AB100 in Order Administration company 1. You sell the same pen as 345789123 in Xstore. For the master product AB100, you have two system products in Order Orchestration: AB100 for Order Administration System, and 345890123 for Xstore. It is also possible to use the same code for a product across more than one system; for example, you might also sell the pen as AB100 in Order Administration company 2.
Note:
If you import products from Merchandising Cloud Services applications (RMFCS), then the product code and all system product codes are the same.If you are using Order Administration System, then the master product is defined as the item/SKU in your default Order Administration company, or system, and other system products are related to this primary product. If you are using Order Administration and Xstore, then the master product is probably defined in Xstore.
Order Orchestration stores availability information for each system product in the product location where it is stocked. For example, you stock AB100 in warehouses 2 and 3 in Order Administration, and in store location 1 and 2 in Xstore. The information included in the Order Orchestration database for each product location is:
-
available quantity
-
next purchase order date (date of the next expected purchase order, if any)
-
next purchase order quantity (the quantity expected on the next purchase order)
-
date and time when the availability information was last updated for the product location
Product barcodes: You can assign UPC barcodes to products in your organization for use in Store Connect. Barcodes are assigned to the product itself rather than a system product, and must be unique in your organization. See Importing Items/Products, Inventory, Barcodes, and Locations into the Database for background on importing barcodes along with products, system products, locations, and product locations.
As with the Organization, System, and Location hierarchy, you control which products and product locations to include in Order . For example, you can omit new products, or products that you sell only on your web storefront and not in your retail stores by using the OROB Eligible flag in Order Administration.
Integrated Data Hierarchy
The following chart illustrates the complete hierarchy in Order , including relationships among Organization, System, and Location and Product, System Product and Product Location.
Proximity Locator Searching
Overview: In addition to locating merchandise in warehouses and stores, Order Orchestration can restrict its search to a specific geographical area. For example, if the customer wants to find a certain product in stores within 25 miles of his home, Order Orchestration restricts the search results to stores within that distance from the customer’s address. Proximity logic is available for searches, such as locate items requests and for the Routing Engine.
Supported when? Proximity locator searching is supported only when the Use Proximity Locator option is selected at the Preferences screen. If the Geocode Address is blank at the Tenant-Admin screen, then proximity locator searching is based on the proximity location table; otherwise, if a Geocode Address is specified, proximity locator searching is based on the Oracle Maps Cloud Service.
Method of distance evaluation: In most cases, distance evaluatoin is based on straight-line (Euclidean) search. The straight-line search is based on:
-
The actual street address, if provided and if Oracle Maps Cloud Service, if in use; otherwise,
-
The center of the zip or postal code.
However, you can calculate turn-by-turn distance for delivery orders using a specified carrier if you use Oracle Maps Cloud Service. See Turn-by-Turn Distance Evaluation for Delivery Orders for a discussion.
Using the Proximity Location Table
How is proximity calculated? When you use the proximity location table, proximity locator searches are based on the longitude and latitude at the center of each zip or postal code based on the density of population within the zip or postal code.
The distances indicated in the search results are not exact driving distances; instead, they are based on the population centers of the zip or postal codes. For example, if the customer’s address is in zip code 01701 and the specified product is available at a store location in zip code 01760, the indicated distance indicates the difference in longitude and latitude from the population center of 01701 to 01760; it does not indicate the actual driving distance from the customer’s home.
If the customer’s address is in the same zip or postal code as the location, then the distance indicated in the search results is 0.0, regardless of the actual distance between the two addresses in the zip or postal code.
Calculating proximity as described above applies only within the US and Canada.
Rounding: There are situations in which Order Orchestration might include locations whose distances from the customer’s location are greater than the specified radius, if the number can be rounded down to the radius. For example, if the specified radius is 25 miles, and a store is 25.21 miles from the customer’s location, Order Orchestration includes this location in the search results. Including these locations can be helpful, since the proximity search is not an exact driving distance from the customer’s location to the store. However, the location is not included if the distance would round up to the next number rather than down to the radius. For example, if the distance calculated is 25.91 miles, Order Orchestration does not include it in the search results.
What if the request does not specify a postal or zip code? The proximity search relies on the postal or zip code for greatest precision; however, it is still possible to process a proximity search without this piece of information.
For example, a customer is looking for the location closest to 101 Main Street in Springfield, but does not know the zip code for this address. There are 17 zip codes in Springfield, but there is no way for Order Orchestration to determine the correct zip code for 101 Main Street. In this situation, Order Orchestration uses the first zip code in the proximity location table for Springfield as a basis for calculating the distance from the customer’s location.
What if the postal or zip code is incorrect? If the postal or zip code does not exist in the proximity location table, or if the postal or zip code is in the table but associated with a different city, Order Orchestration includes locations in the search results, but indicates a distance of 0.
What if the postal or zip code is formatted differently? If a United States zip code includes more than 5 positions (for example, 12345-6789), Order Orchestration uses just the first 5 positions of the zip code in order to find more matches in the proximity location table (for example, 12345).
Determining the latitude and longitude for a location: Order Orchestration determines the latitude and longitude for a location when you create a new location or update a location’s address, either through the import process, the location update request message, or through the New Location or Edit Location screen.
Note:
When you use the proximity locator option, a Canadian postal code should always include the space: for example, L5R 4H1 rather than L5R4H1.Uploading Zip and Postal Code Information to the Proximity Database
Proximity location table: If you do not use the Oracle Maps Cloud Service to look up latitude and longitude, you need to populate the proximity location table before you can begin using proximity searches in Order Orchestration. This table provides the latitude and longitude for each postal or zip codes in the US and Canada.
You can use the Proximity Uploads screen in Order Orchestration to upload a comma-separated value (.CSV) file to the proximity location table.
Order Orchestration uses the information in the proximity location table only if the Geocode Address field at the Tenant-Admin screen is blank.
Using the Oracle Maps Cloud Service API
Overview: Order Orchestration sends geocode requests to the Oracle Maps Cloud Service to determine latitude and longitude for customer and location addresses only if a URL is specified in the Geocode Address field at the Tenant-Admin screen. In this case, it does not use the proximity location table to calculate distance, regardless of whether the table contains any information.
How is proximity calculated? The exact latitude and longitude of the location or the customer’s address, including the street address, is determined. Any time a street address is specified, it must be valid; otherwise, proximity calculation will be inaccurate or unpredictable.
Turn-by-turn distance? If you use the Oracle Maps Cloud Service API, you have the option to use Turn-by-Turn Distance Evaluation for Delivery Orders, which calculates the actual driving distance. Otherwise, the distances indicated in the search results are not exact driving distances.
What if the request does not specify a postal code or zip code? In this case, the distances returned in the search results may not be correct.
The proximity calculation works as described above only within the US and Canada. Proximity calculations may be less exact for other countries.
When are requests sent?
-
Location addresses: Order Orchestration sends a geocode request when you create a new location or change the address of the existing location, either at the screen, through an import process, or through a web service response. The geocode request includes the first street address line, city, state or province, postal or zip code, and country code. The geocode response indicates the exact longitude and latitude for the street address.
Note:
When you use the proximity locator option, each location’s address must include a valid street address, and a Canadian postal code should always include the space: for example, L5R 4H1 rather than L5R4H1. -
Customer addresses: Order Orchestration sends a geocode address when it receives a request for a product search, such as a delivery order in the Submit Order request, a Locate Items search, or a Product Availability search. The geocode request includes the street address (optional), city, state or province, postal or zip code, and country code. The geocode response indicates the exact latitude and longitude for the street address.
-
Pickup locations for ship-for-pickup orders: In the case of a ship-for-pickup order, Order Orchestration treats the pickup location address in the same way as a customer address for a delivery or pickup order, sending the pickup location’s address in the geocode request, and using the pickup location’s address as the central point when calculating proximity.
-
Turn-by-turn requests: Sent only for delivery requests using the specified Carrier for Turn-by-Turn Distance Evaluation when turn-by-turn calculation is enabled. Order Orchestration sends a turn-by-turn request, listing the latitude and longitude of each location that has passed the initial pre-qualification based on the specified maximum distance, using the customer’s address as the central point in order to calculate the turn-by-turn distance. See Turn-by-Turn Distance Evaluation for Delivery Orders for more information.
What if Order Orchestration does not get a geocode or turn-by-turn response? If there is no response within the Connection Timeout interval specified at the Tenant-Admin screen, then an error is returned in the response message to the system requesting the search. For example, the response to a locate items request indicates Customer Address not found. This error might also occur if, for example, the Geocode Address is incorrect.
Setting Proximity Preferences
What happens when proximity search is selected? If a location is set to use proximity searching based on the preference hierarchy described above under Proximity Locator Searching, Order Orchestration calculates the location’s distance from the customer before determining whether to include the location in the search results or select a location to fulfill an order or line. If the location is outside the customer’s search area, Order Orchestration does not include the location in the search results, even if the product is available in that location. You might use this setting for stores where the customer can pick up the product.
Ship-for-pickup: In the case of ship-for-pickup orders, proximity searching includes:
-
sourcing location: Proximity radius is based on the Sourcing Distance specified at the Preferences screen.
pickup location: Proximity radius is based on the range distance specified in the ProductAvailability request message. Searching for pickup locations is not supported in the LocateItems or SubmitOrder messages.
-
What happens when proximity search is not selected? If a location is set to not use proximity searching, Order Orchestration does not calculate its distance to use as a criterion for search results. If the location has the requested item(s) and it is included in the search results, the results indicate a distance of 0 from the customer’s location. You might use this preference for warehouses from which you can ship the product. If your preferences indicate to search first based on proximity, such warehouses, if otherwise eligible to be included in the search results, will always be at the top.
Note:
Even if a location such as a warehouse is not subject to proximity locator searching, it should still be created in Oracle Retail Order Orchestration with a valid address.Shop Order When Proximity Unknown? If the Shop Order When Proximity Unknown flag is selected at the Preferences screen, the Routing Engine does not return an error if the customer’s shipping address for an order cannot be determined. In this case, the Routing Engine:
-
Uses the ship-to address, if possible; otherwise,
-
Uses the address of the originating location, if possible; otherwise,
-
Uses a distance of 0 as the proximity.
This preference applies only to the Submit Order request.
If a requested location specified: The customer ship-to address is not validated when a LocateItems request specifies a requested_location, or the SubmitOrder request specifies a requested fulfilling or sourcing location. In this situation, the distance returned in a LocateItems response is 0.
Turn-by-turn distance evaluation: Turn-by-turn distance evaluation, rather than straight-line distance evaluation, is available for delivery orders using a specified carrier if you are using Oracle Maps Cloud Service. See Turn-by-Turn Distance Evaluation for Delivery Orders for background and setup information.
Determining Whether to Use a Preference in Searches
Overview: Use the Preferences screen to indicate whether to use proximity or probability in locate items searches, under what conditions to use offline inventory, and for settings and search criteria related to the Routing Engine. You can set preferences at the location, location type, or organization level. Order Orchestration always starts checking at the lowest level first, and works its way up the hierarchy if a setting is blank.
For example, using proximity in searches is a Yes or No setting. At each level, you can set this preference to:
-
Yes: use the preference in searches.
-
No: do not use the preference in searches.
-
Blank: go to the next level in the hierarchy to determine whether to use the preference. For example, if this setting is blank for a location, Order Orchestration checks the setting at the location type level.
This hierarchy allows you to set the preference at the highest applicable level. For example, if you never want to use proximity logic in your U.S. warehouses, you can set this preference at the location type level. However, if you always want to use probability rules, you set this preference at the organization level.
Organization level only: There are some preferences that you cannot set at any level below the organization, such as the Use Offline Newer Than time period, which indicates when it is not necessary for Order Orchestration to send an inventory inquiry request to an online system.
Using Probability Rules
Overview: Inventory levels at different locations frequently fluctuate because of sales, returns, shrinkage, purchase order receipts, and other activities. As a result, the most recent inventory count in Order Orchestration might not accurately reflect the actual quantity available in the store or warehouse when the customer wants the product. To avoid disappointing the customer with information that might be outdated or incorrect, you can apply probability rules, based on your best predictions about inventory activity, against the inventory information provided by Order Orchestration in locate items searches or for the Routing Engine.
Example: Store 10 is not part of an online system; Order Orchestration receives inventory updates from the store each night but not throughout the day. You can apply a probability rule that always reduces the available quantity of products in store 10 by the average sell-through rate. The average sell-through rate for product AB100 in store 10 is 15 units a day. When a customer inquires on availability for product AB100, if the current off-line available quantity for the product is 20, Order Orchestration presents the available quantity as 5.
What is a rule? A rule lets you specify whether to transform the availability information for a product location in the response to a locate items request message, or when the Routing Engine selects a fulfilling location. For example, rules can indicate to exclude product locations in locate items or order assignment, or to apply a calculation against one of the inventory fields in the search results (such as reducing the available quantity by 15 in the sample above). The inventory fields that a rule can update are the available quantity, the next expected purchase order date, or the next expected purchase order quantity.
Note:
The rule does not actually update the inventory information for the product location; it only controls the information displayed in the search results or used by the Routing Engine when it assigns a fulfilling location. For example, if a rule results in reducing the available quantity to 5, this quantity is displayed in the search results for a locate items request; but the available quantity specified for the product location remains the same.Simple rules: Rules can be as simple or complex as you need them to be. A simple rule might be: always exclude location 20 from locate items searches. See the Sample Rules for instructions on how to create each of the sample rules. You might use this rule, for example, before you open a new store location for business if you are currently stocking it with inventory, but the inventory is not yet for sale to the public. Another simple rule might be: always decrease the available quantity by the shrink rate.
More complex rules (rules with tests): A more complex rule applies one or more tests before determining whether to exclude a location or update one of the inventory fields. For example, a rule with one test might be: if the available quantity is less than the sell-through quantity, then present the available quantity as 0.
Another example of a more complex rule might allow you to add a cushion for late purchase orders. A rule might be: if the available quantity is less than 10 and the next expected PO date is before today (i.e., the purchase order is late), reduce the available quantity by 20%. Another rule might apply to a group of products for which shipment is typically late. A rule might be: if system product is AB200 or system product is AB300, add 5 days to the next PO date. Similarly, you might set up a rule based on other product attributes, such as: if department is 1538, reduce the available quantity by 15%.
Assigning rules: You can assign rules to one or more locations, location types, or organizations. For example, if you would like a rule to apply only to a particular store location, you can assign it to that location only. If you would always like to reduce the available quantity by the sell-through quantity for all U.S. stores, you would apply that rule to that location type. When you assign rules, you have the option of specifying a beginning and/or ending date, and of specifying whether the rule applies only to off-line or on-line inventory levels (see inventory level type).
Rules use a hierarchy, similar to Proximity Locator Searching, in determining which rule applies to which product location. For example, if you assign a rule at the location level, it might override a rule assignment at the location type or organization level.
Within a single level, you use sequence numbers to identify the priority to rules. For example, if you have 2 rules assigned to a location type, the rule with the lower sequence number is evaluated first.
Because each rule can update only a single field, it is possible for a product location to be subject to multiple rules. Once a particular field has been subject to a rule, Order Orchestration stops evaluating rules for the product location in that search. However, a rule set up to exclude a product location overrides any rules that apply to individual fields.
When does probability rule evaluation take place? During a search for product locations, Order Orchestration:
-
identifies the product locations that might be eligible for consideration based on proximity
-
applies any probability rules
-
determines which product locations are still eligible after applying the probability rules
-
for a locate items search or order assignment, sorts the product locations based on the hierarchy specified at the Preferences screen or the Edit Order Orchestration Preference Override screen
-
for a locate items search, eliminates any product locations that are not within the Maximum No. Responses specified at the Preferences screen, and returns the results
Rules do not apply when a locate item request or submit order request specifies a fulfilling or sourcing location.
Exclude Locations with Zero Available? If the Exclude Locations with Zero Availability setting at the Preferences screen is selected, any possible product locations whose current available to promise quantity are 0 or less are excluded from consideration before the application of any potential probability rules.
Flexibility of rule creation: Order Orchestration provides you with extreme flexibility in setting up rules; however, it is important that you make sure your rules are not so complex that the results are unpredictable. Oracle recommends that you test each rule that you apply to make sure that it works as you intend it to.
Rounding: Available quantity and next PO quantity are always presented as whole numbers in the locate items or Routing Engine search results, so that Order Orchestration rounds the result of any calculation up or down to the nearest whole number. For example, a result of 18.4 is rounded down to 18; 18.5 or higher is rounded up to 19.
For more information: See Probability Rule Wizard for instructions on setting up rules, rule examples, and suggestions for testing rules.
Note:
In order to use probability rules for an organization, you must select the probability rules preference. You can set this preference only at the organization level at the Preferences screen.Using Zones for Fulfillment
Purpose: Zone fulfillment provides a means to have the Routing Engine limit order assignment to particular store or warehouse locations based on the geographical area of the order’s shipping address.
Example: You prefer to use the distribution center in Hartford, Connecticut to ship orders to customers in the New England states, even if a location in California has a greater quantity available.
Why use zone fulfillment? You might use zone fulfillment to save on freight charges and expedite shipping in certain areas. Zone fulfillment logic can also increase the speed of location assignment, since it uses a limited number of eligible locations.
Fulfillment of delivery orders and sourcing for ship-for-pickup only: Zone fulfillment applies only to delivery and ship-for-pickup orders, and these types of locate items or product availability searches. It does not apply to store pickup orders.
Applies to both standard brokering and weighted brokering: Regardless of whether your organization uses standard brokering rules, or uses weighted brokering rules and assignment through the Science Engine, you can use zone fulfillment to route orders.
How does zone fulfillment work? When you use zone fulfillment, the Routing Engine determines whether a shipping address falls within a fulfillment zone. It then restricts the list of possible fulfilling locations to the one(s) specified for the zone. This evaluation takes place when the Routing Engine receives a submit order message, a product availability search request, a locate items request, or when an existing order is rejected by the assigned fulfilling location,
If the order cannot be fulfilled or sourced by the locations included in the zone, it is assigned to the default unfulfillable location. Similarly, in the case of a locate items or product availability search, the response message indicates that the requested item(s) is/are not available.
Primary and alternate locations: When you set up a zone for fulfillment you can specify:
-
primary locations: One or more locations where you prefer to place orders within the zone. At least one primary location is required.
alternate locations: Optionally, one or more locations that are eligible for order assignment if the order cannot be fulfilled within the list of primary locations. You might set up alternate locations to help eliminate the possibility of losing a sale.
-
Selecting geographical areas for shipping addresses: You can set up zones to include shipping addresses based on:
- Zip code prefix range: For example, all orders shipping in zip codes that start with 021 through 025 should ship from any of the Boston retail locations. This option is available for United States addresses only.
-
State or province: For example, all orders shipping to New York, New Jersey, Pennsylvania, and Delaware ship from the east coast distribution center or the outlet store. This option is available for United States and Canadian addresses only.
-
Country: For example, all orders shipping to France, Germany, and Austria ship from the Austrian distribution center. This option is available for countries other than the United States and Canada only if the Use Proximity Locator preference is unselected for your organization. Contact your Oracle representative about how to use proximity calculation for countries other than the U.S. and Canada.
When attempting to assign an order, the Routing Engine starts zone selection with the most specific criterion (zip code prefix) and works through to the most general (country). If the shipping address on the order does not match any zones, then the Routing Engine uses the standard assignment logic as set up at the Preferences screen or the Edit Order Preference Override screen.
Example: You have set up the following active zones:
-
Portland, Maine Area: includes zip code prefixes 040 through 043
-
Northern New England: includes Maine, New Hampshire, and Massachusetts
-
United States
-
If a locate items request or the order’s shipping address is in:
-
Portland, Maine, zip code 04101: use the Portland, Maine Area zone
-
Anson, Maine, zip code 04911: use the Northern New England zone
-
Providence, Rhode Island, zip code 02903: use the United States zone
-
Toronto, Canada: do not restrict order assignment by zone
-
Order Orchestration selection criteria still apply: When a shipping address falls within a fulfillment zone, the Routing Engine uses existing rules when selecting and ordering locations, except that the eligible locations are restricted to those specified for the zone. For example, if you set the Order Orchestration preferences to select first based on On Hand Count, the primary location with the highest on-hand count is selected. Also, the Routing Engine executes this process first within the primary locations before checking any alternate locations, as described above.
If you group shipment locations: Zone fulfillment logic still applies to locate items processing if you use the grouping shipment locations option.
Requested location? The Routing Engine does not use zone fulfillment logic if:
-
the locate items request specifies a requested location
-
the submit order message specifies a location for fulfillment
In both of these cases, the Routing Engine restricts location selection or assignment to the specified location, regardless of whether the shipping address falls within a zone that includes the location.
How to start using zones: The Routing Engine uses zones for fulfillment when:
-
the Use Zone Fulfillment flag at the Preferences screen is selected, and
-
the zone is flagged as Active
For more information: See the Fulfillment Zone Wizard.
Standard or weighted brokering? The primary and alternate search hierarchy within zones varies depending upon whether Use Weighted Brokering Rules is selected. See:
Primary and Alternate Search Hierarchy: Standard Brokering
The following process applies if Use Weighted Brokering Rules is not selected.
If splitting: If you use splitting orders, the Routing Engine attempts to:
- Assign the entire order to a single location within the primary locations specified for the zone; otherwise, if this is not possible;
-
Split the order within the primary locations specified for the zone; otherwise, if this is not possible;
-
Assign the entire order to a single location within the alternate locations specified for the zone; otherwise, if this is not possible;
-
Split the order within the alternate locations specified for the zone; if this is not possible;
-
Split the order across the primary and alternate locations; if this is not possible;
-
Assign the order to the default unfulfillable location.
If not splitting: If you do not split orders, the Routing Engine attempts to:
- Assign the entire order to a single primary location specified for the zone; otherwise,
-
Assign the entire order to a single alternate location specified for the zone; otherwise;
-
Assign the order to the default unfulfillable location.
Primary and Alternate Search Hierarchy: Weighted Brokering
Weighted Brokering and the Science Engine: When you use weighted brokering, the Routing Engine passes information to the Science Engine indicating whether each eligible product location is in a primary or alternate location. The Science Engine then uses the same rules on order assignment and splitting as the Routing Engine uses for standard brokering. See Submit Order Request for Delivery Order (Weighted Brokering) for a discussion.
The following process applies when Use Weighted Brokering Rules is selected.
If splitting order is supported:
- Assign the entire order within the primary locations specified for the zone; if this is not possible,
-
Assign the entire order by splitting it across the primary and alternate locations; if this is not possible;
-
Assign the entire order within the alternate locations specified for the zone; if this is not possible;
-
Assign the order to the default unfulfillable location.
If not splitting:
- Assign the entire order to a single primary location specified for the zone; otherwise,
-
Assign the entire order to a single alternate location specified for the zone; otherwise;
-
Assign the order to the default unfulfillable location.
Using Maximum Daily Order Assignment
Purpose: You can specify the maximum number of delivery or ship-for-pickup orders to assign to a location on a daily basis.
Example: Location 10 cannot be assigned more than 10 orders a day, while location 20 cannot be assigned more than 15 orders a day.
Delivery and ship-for-pickup orders only: The maximum daily order restriction applies to delivery or ship-for-pickup orders only. There is no daily limit to the number of store pickup orders that can be assigned to a location.
When a location is over the daily maximum: If a location has met or exceeded the maximum number of orders for the day, the Routing Engine:
-
does not include the location in the locate items search results for a delivery or ship-for-pickup order unless it is the requested location; see Selecting a Location for a Delivery Order
-
does not assign a delivery or ship-for-pickup order, or a line on a delivery or ship-for-pickup order, when a submit order message does not specify a fulfilling location
-
does not assign a delivery or ship-for-pickup order, or a line on a delivery or ship-for-pickup order, when the current assigned fulfilling or sourcing location rejects the order (“reshop”)
These restrictions apply regardless of whether the location has the inventory on-hand, or is flagged as Backorder Available.
Tracking daily order count: The Routing Engine uses a counter for the location to track the number of delivery and ship-for-pickup orders assigned for the day. This counter is not displayed on any screen.
-
Counter increased when? The daily order count increases when a delivery or ship-for-pickup order is initially assigned, or when an order is reassigned through reshopping. The counter for a location increases by one regardless of:
the number of lines on the order being assigned to the location
-
the quantities currently on the order lines
-
whether the order is split across multiple locations
-
whether the Routing Engine assigns the order, or the location was specified in the submit order message, or selected in order maintenance when you are assigning the order to a different location
Note:
The counter is not increased for store pickup orders, or for selection as a pickup location for a ship-for-pickup order. -
-
Counter not decreased: The daily order count does not decrease if an order is rejected or canceled.
-
Counter is at the location level: Even if you specify a Maximum Number of Orders for a location type, the Routing Engine tracks order assignment for each location separately and does not combine the order totals across the location type.
-
Reset daily: The Routing Engine checks the daily order count date for the location each time an order is assigned, and starts the counter over at one if the last daily order count date is not the current date. Like the order counter, the daily order count date is not displayed on any screen.
Overriding the order limit: Even if a location is not eligible for automatic delivery or ship-for-pickup order assignment based on the daily order count, you can still:
-
Request current inventory in the location by requesting the location specifically in the locate items search request (using the requested_location, or “favorite store” element)
-
Assign a delivery or ship-for-pickup order by specifying the location in the submit order request message
-
Select the location through order maintenance, if you have the required authority
When you assign a location that has already met or exceeded the daily order limit, the Routing Engine continues to increase the daily order counter for the location.
Note:
No maximum applies to the Default Unfulfillable Location where the Routing Engine assigns unfulfillable orders.Setup through preferences: To use the maximum daily order assignment option:
-
Select Use Maximum Order Limits at the Preferences screen.
-
Specify the Maximum Daily Orders for the organization, and optionally at the location type level or the location level. A setting of 0 indicates that there is no limit to the number of orders that can be assigned to a location, while a setting of Not Defined indicates to check at the next level of either the location type or the organization.
When evaluating whether a maximum applies, the Routing Engine checks the Maximum Daily Orders setting for:
- the location; otherwise,
-
If the Maximum Daily Orders is Not Defined for the location, check the location type; otherwise,
-
if the Maximum Daily Orders is Not Defined for the location type or the location, use the organization setting.
Updating Order Status at the Line or Unit Level
Overview: The Allow Partial Updates preference for an organization controls whether you update order line status at the order line level or at the unit level. This option is available only if the organization has the Allow Split Order preference selected.
Example: An order line has a quantity of 5 units. The location has only 3 units of the item available. If the Allow Partial Updates preference is:
-
selected, the assigned location can send a status update rejecting 2 units
-
unselected, the location must accept or reject the entire order line
Quantity always required: When this is preference selected, the location sending a status update always needs to specify the quantity to update as well as the line number. Similarly, the quantity is a required field when you use the Edit Order Item window to update an order line.
Creating a new order line: If the Allow Partial Updates preference is selected, when the Routing Engine receives a status update whose quantity is lower than the total line quantity, it creates a new order line for the specified status, and decreases the quantity for the existing order line.
Example: Order line 1 has a quantity of 7 units and is currently in picked status. The assigned location sends a status update indicating that 3 units are fulfilled. The Routing Engine:
-
creates line 2 for a quantity of 3 and a status of fulfilled
-
updates line 1 to a quantity 4, and leaves the status as picked
Note:
The Routing Engine creates a new line with the next available line number. For example, if there were already 3 lines on the order, the Routing Engine creates line 4 for the 3 fulfilled units.Split line not required: Although the Routing Engine effectively splits an existing line when it receives a partial quantity update, it is not necessary to have the Allow Split Line preference selected. The Allow Split Line preference controls whether to split a line at initial order assignment, not whether to split a line due to later changes in status.
Rejecting individual units and the Search Retries setting: The Routing Engine uses the Search Retries setting to determine the total number of times it can attempt to reassign delivery and ship-for-pickup orders when they are rejected by their fulfilling or sourcing locations. This limit applies to the entire order, regardless of whether the organization supports split orders, split lines, or partial status updates.
Example: The Search Retries preference is set to 2. If the organization supports:
-
Split order but not split line or partial status update, the order is assigned to the Default Unfulfillable Location after the order is rejected 2 times.
-
Split order and split line but not partial status update, the order line is assigned to the Default Unfulfillable Location after the total number of line rejections received and “reshop” attempts is 2, regardless of whether the rejections were for the same line or different lines.
-
Split order and partial status update, the order line is assigned to the Default Unfulfillable Location after the total number of unit quantity rejections received and “reshop” attempts is 2, regardless of whether the rejections were for the same line or different lines, or whether the rejections were for the full line quantity or a partial line quantity.
Rejecting individual units and reshopping to different fulfilling or sourcing locations: When the Routing Engine receives a status update rejecting a quantity of a delivery or ship-for-pickup order line, it uses its standard logic (including probability rules and zones) to assign each rejected quantity. If a location rejects a partial quantity of a line in 2 separate status updates, the Routing Engine assigns each partial quantity to a different fulfilling location.
Example:
-
Location A rejects all 3 units of an order line in a single status update, and the Routing Engine assigns all 3 units to location B.
-
Location A rejects 1 out of 3 units on an order line, and the Routing Engine assigns the unit to location B. If location A then rejects the remaining 2 units of the order line, the Routing Engine assigns the 2 units to location C.
Current Order Orchestration line number required for status update: When the Allow Partial Update preference is selected but the Use Requesting System Line Number in Status Update flag is not selected, or the status update does not come from the originating location, the line_no specified in a status update request message needs to match the current line number in Order Orchestration, and the specified quantity cannot exceed the current quantity on the order line. In order to be sure of sending the current line number, the requesting system should first send a status inquiry request before sending the status update request.
Example: Location A sends its line #11 for 3 units to Order Orchestration as a delivery order. In order to send a status update request to cancel the line, the location must first send a status inquiry request. The status inquiry response indicates that the current line numbers in Order Orchestration are:
-
line 1 in accepted status, with a quantity of 1
-
line 2 in picked status, with a quantity of 2
-
The location then sends a status update request for the current quantities of lines 1 and 2, indicating to cancel both lines.
Note:
Sending the status inquiry first also enables the requesting system to confirm that the order line has not been canceled or fulfilled.Screen differences to note: When any line on an order splits, either through initial order assignment or a partial quantity status update, then the Detail tab on the Order screen groups the split lines under the requesting system line number. If none of the lines are split, then the Detail tab provides maintenance or display access only through the original requesting system line number; otherwise, you need to select the current line number in Order Orchestration to maintain or display. See Reviewing or Updating Order Orchestration Orders and the Order screen for more information.
Before turning on partial quantity updates: Before you enable this option, it is important to confirm that updating a partial quantity of a line is supported by all systems integrating with Order Orchestration.
Auto-Cancel Unclaimed Orders
Purpose: You can configure Order Orchestration to automatically cancel pickup or ship-for-pickup order lines if the customer does not pick them up after a specified number of days.
Note:
The auto-cancel option is available only if Allow Split Order is selected at the Preferences screen.Assignment of Pickup By Date
When you configure auto-cancel, Order Orchestration assigns a Pickup By Date to a line when the line is first eligible for pickup. The Pickup By Date is based on:
-
The auto-cancel settings at the Preferences screen, indicating the number of days to wait after the line is eligible for pickup before the line can be automatically canceled. The Preferences screen also includes the cancel reason code to use when automatically cancelling unclaimed orders.
-
The Days Open settings for the pickup location, so that any days when the location is not open are excluded from the Pickup By Date calculation.
For example, the Auto Cancel Days of Unclaimed Pickup Orders at the Preferences screen is set to 2 days. The pickup location is flagged as open all days except for Sunday. If the line is eligible for pickup on Saturday the 5th, the line is assigned a Pickup By Date of Tuesday the 8th, since Sunday is not included. However, if the pickup location is open on Sunday, the line is assigned a Pickup By Date of Monday the 7th.
Order Orchestration makes the Pickup By Date assignment when the line status changes to:
-
Picked, if the order type is pickup, or if the order type is ship-for-pickup and the sourcing location is the same as the pickup location; otherwise,
-
Received, if the order type is ship-for-pickup, and the sourcing location is different from the pickup location. In this situation, the line is not eligible for pickup until the sourcing location has transferred the inventory to the pickup location, and the pickup location has received it.
Note:
The Pickup By Date is assigned even if the order is currently under review.
When the Pickup By Date is assigned, an order history message is written, for example: Pickup By Date: 12/31/2017.
Auto-Cancellation Updates
When the Auto Cancel Unclaimed Pickup Orders job runs, it:
-
Evaluates each organization that has Allow Split Order selected.
-
If Auto Cancel Days of Unclaimed Pickup Orders specifies a number of days, selects each pickup order line in picked status and with a Pickup By Date that is in the past.
-
If Auto Cancel Days of Unclaimed Ship For Pickup Orders specifies a number of days, select each ship-for-pickup order line that is either in picked status with the sourcing location is the same as the pickup location, or in received status with the sourcing location different from the sourcing location, and with a Pickup By Date that is in the past.
-
For each selected order line:
-
Changes the status to canceled.
-
Clears the Pickup By Date.
-
Creates a history record, displayed at the History tab of the Order screen, indicating that the order line was canceled with the Auto Cancel Reason. The User ID indicated is SYSTEM and the Source is WS.
-
Sets the AUTO_CANCELLED flag in the XOM_ITEM table to 1.
-
Sample Auto-Cancellation Flows
Auto-cancel calculation: An order line is eligible for cancellation by the auto-cancel job after the assigned Pickup By Date has passed, excluding any dates that are not flagged as Days Open for the pickup location.
-
Open all days:
-
The Auto Cancel Days of Unclaimed Pickup Orders is set to 3.
-
The pickup location has all days selected as Days Open.
-
The order line is picked on Saturday, the 16th, and the Pickup By Date is set to the 19th, 3 days later.
-
When the auto-cancel job runs on the 20th, the order line is canceled.
-
-
Location closed on Sunday:
-
The Auto Cancel Days of Unclaimed Pickup Orders is set to 3.
-
The pickup location has all days selected as Days Open except for Sunday.
-
The order line is picked on Saturday, the 16th, and the Pickup By Date is set to the 20th, 3 days later, omitting Sunday from the calculation
-
When the auto-cancel job runs on the 21st, the order line is canceled.
-
The job uses the Auto Cancel Reason specified at the Preferences screen.
-
Changing an Order Line’s Pickup By Date
You can change an order line’s Pickup By Date:
-
Order Status Update request message: This message enables you to change the Under Review setting as well as the Pickup By Date.
-
Store Connect: The Change Pick Up Date window enables the store associate to change the Pickup By Date.
-
Order Inquiry: The Edit Order Item window enables you to change the Pickup By Date assigned to an order line.
When the Pickup By Date is changed, an order history message is written, for example: Pickup By Date: 12/31/2017.
Status changes clear the Pickup By Date: Once the Pickup By Date is set for a line, a change of status clears the Pickup By Date. This occurs regardless of whether the line’s status changes to fulfilled because it was picked up, or because it was canceled or rejected. When the Pickup By Date is cleared, an order history message is written: Pickup By Date Removed.
Report
The Auto Cancel Report provides a listing of orders that include any lines that were automatically canceled within a specified date range, and includes customer contact information. See that report for more information.
Required Setup for Auto-Cancellation
To enable auto-cancellation of unclaimed pickup or ship-for-pickup orders:
-
Auto-cancel reason code: Use the Reason Codes screen in Modern View to create the Auto Cancel Reason.
-
Preferences screen: At the Fulfillment tab, set:
-
Auto Cancel Days of Unclaimed Pickup Orders to enable auto-cancellation of pickup orders.
-
Auto Cancel Days of Unclaimed Ship For Pickup Orders to enable auto-cancellation of unclaimed ship-for-pickup orders.
-
Auto Cancel Reason for the auto-cancel job to use when canceling the orders.
Note:
These fields are available only if Allow Split Order is selected.
-
-
Locations: Optionally, use the Days Open fields for a location to unselect any days of the week that should not be included when calculating the Pickup By Date for orders assigned to the location for pickup. Ways to create or update locations include:
-
Importing Locations through File Storage API process: When you create a new location through the location import, all days of the week listed under Days Open are selected by default. When you update an existing location through the import, the Days Open settings are not changed.
-
New Location or Edit Location screens: The Days Open settings are available at these screens.
-
Location Bulk Updates wizard: You can use this option to set the Days Open for a group of individual locations.
-
location update request message: See the Web Services Guide on My Oracle Support (2953017.1) for background on using this request message.
-
-
Auto-cancel job: Use the Schedule Jobs screen to specify the time of day when the auto-cancel job should run, and to enable the job.
Things to Note about Auto-Cancellation
Reviewing the Pickup By Date for a line:
-
When the Pickup By Date is automatically assigned to the order line, a transaction history record is created. The Pickup By Date assignment is displayed under Transaction Notes at the History tab of the Order screen.
-
Web service message responses: The Pickup By Date for an order line, if assigned, is included in the responses to the Order Search response, Status List response, and Status Inquiry response messages.
-
Store Connect screens: The Pickup By Date is displayed on various order detail screens in Store Connect.
The Pickup By Date is assigned even if the order is currently flagged as Under Review.
Partial updates: If the Allow Partial Update preference is selected, it is possible for a different Pickup By Date to be assigned to individual units on an order line, or for one unit to have a Pickup By Date while the other does not. For example, a pickup order line with two units is assigned to a pickup location. If one unit is picked on Tuesday and the other is picked on Wednesday, the line splits, and each resulting line has a different Pickup By Date.
Existing orders without Pickup By Dates: Any orders that were already eligible for pickup before you configure your organization for auto-cancellation will not be automatically assigned a Pickup By Date. Optionally, you can assign a Pickup By Date to an existing order through the Edit Order Item window in Order Orchestration, the Change Pick Up Date window in Store Connect, or through the Order Status Update request web service message.
For more information: See:
-
Reason Codes screen in Modern View to create the Auto Cancel Reason.
-
Preferences screen to set the Auto Cancel Days of Unclaimed Pickup Orders and Auto Cancel Reason, as well as the Auto Cancel Days of Unclaimed Ship For Pickup Orders.
-
New Location screen or the Importing Locations through File Storage API process to create locations, including the Days Open.
-
Edit Location screen or Location Bulk Updates wizard to update the Days Open for locations.
-
Schedule Jobs screen to schedule the auto-cancel job.
-
Edit Order Item window or the Order Update request chapter in the Web Services Guide on My Oracle Support (2953017.1) to change an order line’s Pickup By Date.
-
Browse Order Item window or Edit Order Item window to review an order line’s Pickup By Date.
-
LocationUpdate request chapter in the Web Services Guide on My Oracle Support (2953017.1) for information on updating the Days Open.
-
OrderSearch response chapter, Order Inquiry StatusRequestResponse chapter, or Order Status List response chapter in the Web Services Guide on My Oracle Support (2953017.1) for an integrated system to obtain an order line’s Pickup By Date.
Order Fulfillment through RICS Integration
Overview: Use communication through Oracle Retail Integration Cloud Service (RICS) to manage order fulfillment through the following Oracle Retail applications:
-
Inventory reservation and warehouse order communication: Order fulfillment is through Oracle Retail Merchandising Foundation Cloud Service (RMFCS).
-
Store order communication: Order fulfillment is through Oracle Retail Store Inventory Management (SIM) or Enterprise Inventory Cloud Service (EICS) and its UX layer Store Operations Cloud Service (SOCS).
Note:
The order fulfillment process described below is available for delivery orders only.Order creation: The order creation process includes the following steps:
-
Submit order: An integrated system, such as Order Administration or Order Administration Cloud Service, submits the order to Order Orchestration.
-
Order routing: Order Orchestration selects one or more fulfilling locations for the delivery order, as described in the Order Orchestration Routing Engine Overview.
-
Communication through RICS: If the system associated with a fulfilling location is configured for RICS integration, Order Orchestration posts the order or order line to RICS.
-
Successful post? If Order Orchestration receives a message indicating that the order posting was a success, the order status changes to posted. Order Orchestration assigns this status only to orders fulfilled through the RICS integration.
-
RICS broadcasts the order request to SIM or EICS and RMFCS: If the assigned fulfilling location is a:
-
Warehouse: RMFCS creates the order. RICS sends a status update of accepted to Order Orchestration. SIM and EICS ignore the request if the fulfilling location is a warehouse.
-
Store location: SIM or EICS creates the order.
Regardless of whether the assigned fulfilling location is a warehouse or a store location, RMFCS reserves inventory for the order.
-
Which orders are eligible for posting to RICS?
-
Assigned to system configured for RICS? Only orders that are assigned to fulfilling locations in a system configured for RICS are eligible for posting.
-
Delivery orders only: Other order types are not submitted.
-
Under review? You need to select the Hold Under Review Orders setting for the system to indicate not to submit orders whose Under Review flag is selected, but instead to wait until the flag is cleared.
Additional events that trigger posting an order to RICS: In addition to posting at order creation, Order Orchestration also submits eligible orders to RICS when:
-
Rejection: The currently assigned fulfillment location rejects the order, or you change the status to rejected through the Order screen or the Edit Order Item window, depending on whether you use split orders.
This type of rejection can also occur if a store associate cannot find inventory for the order, and cancels the order in SIM; or if warehouse staff cannot find inventory, and they cancel the order in RMFCS.
In either case, Order Orchestration “reshops” the order to a new fulfilling location.
-
Location change: You change the assigned fulfilling location through the Order screen or the Edit Order Item window, depending on whether you use split orders.
Releasing reservation: Release reservation processing takes place if the Send Release Reservation Inventory Message flag is selected at the System screen. When an order or line assigned through RICS is canceled or rejected, Order Orchestration generates a message to RICS indicating that the reserved inventory for the order can be released. This information enables RMFCS to use the inventory for other orders, and notifies RMFCS, EICS, or SIM to update the status of the order. The status update can occur either through a web service request, or at the Order screen or the Edit Order Item window.
The release reservation message is also generated when you assign a new fulfilling location through the Order screen or the Edit Order Item window.
Order Orchestration generates the release reservation message immediately. If Order Orchestration then reshops a rejected order to another enterprise location, it posts the new order information through RICS for fulfillment.
Note:
Order Orchestration does not send the release reservation message if the order is under review and the system is configured not to send orders that are under review, because in this situation the order was not yet posted through RICS.Updating order status: RICS sends status update messages when the status of an order or line changes. These messages map to the Order Status Update Request message. When the order or line ships, the information updated can include a carton number and tracking information, as well as the shipping date from the fulfilling location.
If RICS sends a status update message and the order is already in that status, Order Orchestration does not return an error to RICS; however, the error is noted in the RICS Log tab of the Order screen, for example: Error updating status for request id = XXXXX line number = X - got an exception. Request already at provided status.
Under review change notifications: Order Orchestration submits an under review message to RICS to notify the fulfilling system when an open order that was previously submitted is now under review, or when a submitted order that was previously under review is no longer under review.
For example, this situation can occur when:
-
Order Orchestration submits an order through RICS for fulfillment.
-
A number of days later, the authorization expires; and when the originating system, such as Order Administration, submits a new authorization request, it is declined.
-
The originating system sends an order update request to Order Orchestration to set the Under Review flag to Y.
Order Orchestration then submits the under review request to RICS, indicating not to fulfill the order at this time.
Similarly, Order Orchestration submits the under review update message to RICS when an open order that was previously under review is no longer under review, and can be fulfilled.
The under review updates are sent only when:
-
The order is a Delivery order, and
-
The order status is currently Posted, Polled, Accepted, or Picked, and
-
The setting of the Under Review flag changes.
Hold Under Review? The Hold Under Review Orders flag should normally be selected at the System screen. When this flag is selected, an order is not initially sent to RICS when created if it is currently under review; instead, when the Under Review flag is cleared for the order, it is posted automatically as a new order to RICS, and the under review message is not generated. However, if the setting of the Under Review flag changes after the order is posted, the under review message is generated, indicating to hold the order.
If order or release posting fails: Posting orders or release reservation requests through RICS can fail because:
-
Communication with RICS did not succeed. For example, this might occur if RICS was temporarily unavailable, the URL specified at the System screen was incorrect, or the request timed out.
In this case, a background job triggers submission of all of these messages on an hourly basis. The messages are posted in first-in first-out order (oldest first). The RICS Log tab of the Order screen displays these messages with a Retry Status of Failed.
-
There an unrecoverable error in the information to be submitted. For example, the location code specified in the request is alphabetical rather than numeric.
In this case, Order Orchestration does not reattempt to submit these messages, because they would not succeed. The RICS log records are eligible to be purged through the daily cleanup job based on the RICS Log History retention days, described below. Order Orchestration changes the status of the order or lines to unfulfillable.
RICS log: The RICS Log tab of the Order screen provides further detail about activity and the messages sent and received. From this tab, you can also open the RICS Log Message window to review request or response messages.
Reviewing order activity and messages: The Transaction Notes at the History tab of the Order screen describe updates for orders fulfilled through the RICS integration. For example, when:
-
Order Orchestration submits the order to RICS: History message is Posted to RICS.
-
Order Orchestration notifies RICS to release the reservation for the order because it has been canceled or rejected: RICS Release Reservation Message Sent.
-
Order Orchestration notifies RICS that the Under Review flag for an open, submitted order has been selected: Under Review: Yes; RICS Under Review Message Sent. The note indicate a setting of No if the Under Review flag has been cleared.
-
There is an unrecoverable error in the information to be submitted, such as alphabetical characters in a numeric field: Unable to create RICS message.
Required configuration: To fulfill orders using RICS, complete the following configuration in Order Orchestration.
-
External Service configuration: Use the External Services screen to create each Orders service, so that they will be available for selection at the RICS Integration tab at the System screen
-
System configuration: Create SIM or EICS and RMFCS as systems in Order Orchestration.
-
Use the RICS Integration tab at the System screen to configure these systems. The information you can specify at this tab includes:
-
Flagging the system as Online for RICS communication. If this flag is not selected, no communication takes place with RICS.
-
Connection and authentication information for communicating with RICS.
Note:
The User ID specified through the External Services needs to have the Operator or Admin role in RIB in order to support sending stop and start requests at the beginning and end of the Inventory Quantity Export, indicating to pause individual inventory updates while the export runs. See Available-to-Sell Individual Inventory Updates through Oracle Retail Integration Cloud Service (RICS) for more information.
-
-
Settings that control order flow, including selecting the Hold Under Review Orders flag to prevent submitting orders that are currently held for review.
The Use Requesting System Line Number in Status Update flag at the Orders tab of the System screen should be unselected.
-
Web service authorization: Create web service users for the Oracle Retail Integration Cloud Service that will be required for authentication of inbound messages to Order Orchestration. See Web Service Authorization for more information.
-
Preference settings: Note the following settings at the Preferences screen:
-
Delivery orders only: The locations associated with the SIM and RMFCS systems should be configured in Order Orchestration to support delivery orders only. You cannot use the RICS integration to fulfill any other order types.
-
Cannot use split line or partial status update: The Allow Split Line and Allow Partial Updates preferences should not be selected for your organization. However, you can select Allow Split Order.
-
Split order: If Allow Split Order is selected at the Preferences screen, the Create Fulfillment Order message to RICS has the partial delivery indicator (<partial_delivery_ind>) tag set to Y; otherwise, it is set to N.
Other preference settings, such as Acknowledge Order Before Brokering, do not affect the ability to fulfill orders through RICS.
-
-
Store and warehouse locations: See Importing Data from Merchandising Cloud Services (RMFCS) through the Omnichannel Cloud Data Service (OCDS or Merchandising Omni Services) for information. Note that location codes must be numeric for integration through RICS.
-
RICS Log History retention days: This field at the Tenant-Admin screen specifies the number of days to retain RICS_LOG records before the daily cleanup job automatically deletes them. Can be from 0 to 30 days. Only successful records and records with unrecoverable errors are eligible for deletion.
-
Setup in Order Administration: If you use Order Administration System, note the following required setup.
-
Orders originating in Order Administration System should use an originating location that matches the E-Commerce Virtual Warehouse in RMFCS. The originating location passed from Order Administration is determined by the Originating Location to Pass to OROB (M32) system control value.
-
Order Administration should have the Use OROB for Fulfillment Assignment (M31) system control value selected.
-
See the Order Administration online help, including Brokered Backorders and Enterprise Order Integration, for background on additional setup in Order Administration.
-
For more information: Contact your Oracle representative for more information on configuration required beyond settings in Order Orchestration and Order Administration.
Troubleshooting and things to note:
-
If any order type besides a delivery order is assigned to a location in a system that uses RICS for order fulfillment, it will not be submitted to RICS. Instead, it will remain in new order status.
-
The processing described above takes place only for systems that are configured to use RICS based on the settings at the RICS Integration tab at the System screen.
-
RICS order fulfillment does not support fulfilling an order that includes the same item on multiple order lines, such as a ship-alone item.
-
Hold under review?If the order is fulfilled through RICS order fulfillment and the Hold Under Review Orders flag for the system is selected, the order is not posted for fulfillment until you clear the Under Review flag. This flag should be selected.
-
Require status update? The Require Status Update flag does not control whether the order status is automatically set to polled, since the fulfillment request message is not used.
-
Retry status displayed for unrecoverable errors: When the fulfillment request message to RICS has an unrecoverable error, the Retry Status listed at the RICS Integration tab at the System screen is Success. This status indicates that the RICS log record is eligible to be purged, because Order Orchestration will not attempt to post the message again.
-
It is not necessary to configure the hourly job that resubmits failed requests to RICS. This job runs automatically. It is the same job that checks for any orders that are still assigned to the In Process location if you use Acknowledge Order Before Brokering.
-
In process orders excluded: Orders that are currently assigned to the IN PROCESS location are not submitted until they are assigned to a location associated with a system flagged for RICS order processing. See Acknowledge Order Before Brokering for a discussion on in process orders.
For more information: See:
-
External Services screen for information on creating the Orders external services
-
RICS Integration tab at the System screen for additional configuration.
-
Web Service Authorization for information on setting up authentication for the Oracle Retail Integration Cloud Service.
-
RICS Log tab at the Order screen.
-
RICS Log Message window.
-
RICS Message Mapping in the Web Services Guide on My Oracle Support (2953017.1) for message and mapping details.
Importing Items/Products, Inventory, Barcodes, Images, and Locations into the Database
Part of the initial setup required for Order Orchestration is to populate the database with information such as locations, products, system products, and product locations. Also, you normally update this information periodically with any new or changed products and periodic inventory updates, and have the option of adding new information at any time.
Merchandising Cloud Services applications (RMFCS) imports: Importing products and barcodes from Merchandising Cloud Services applications (RMFCS) uses a different process than the one described under Import Process Overview (Other than RMFCS File Upload through OCDS or Merchandising Omni Services) See Importing Data from Merchandising Cloud Services (RMFCS) through the Omnichannel Cloud Data Service (OCDS) or Merchandising Omni Services.
Load products from default system first: Begin by importing products from your default system, creating records in the product, system_product, and product_location tables for this system. Afterward, load products from any system that is not flagged as the default in order to create the system_product and product_location records for that system. The default system is the one flagged as the Default at the Systems screen. See the description of the Data Hierarchy for a discussion of the default system.
You cannot load a product from a non-default system before first creating the product for the default system.
Note:
Oracle recommends that you do not use UPC codes as system product codes, because UPCs are not permanently assigned to a single product.Job batch size: The Job Batch Size defines the number of records for Order Orchestration to include in each batch of product, product location, and incremental inventory import records. The default setting is 1000 records.
Case-sensitive? Oracle recommends that when you use a file import, that you use uppercase for all import file names, regardless of whether the code identifying the importing system is all uppercase. For example, even if the system code is Xstore, the import file name could be PRODUCT_XSTORE.TXT.
Importing Data from Merchandising Cloud Services (RMFCS) through the Omnichannel Cloud Data Service (OCDS) or Merchandising Omni Services
You can import the following information through the Omnichannel Cloud Data Service (OCDS) or Merchandising Omni Services:
-
Warehouse locations: The import includes only virtual warehouse locations, with the address derived from the physical warehouse associated with the virtual warehouse. The data imported does not include additional information, such as location attributes or preference settings.
-
Store locations. The import includes store locations and addresses. The data imported does not include additional information, such as location attributes or preference settings.
-
Products and system products. The system product code should be the same as the product code for all integrating systems. The import should take place first for the default system, in order to create the product records first before attempting to create system product records for additional systems.
-
Item image URLs: Optionally, you can import item image URLs in order to display item images in Store Connect.
-
Inventory (product locations) for warehouse and store locations. The available quantity is imported, but not purchase order information.
-
Product barcodes: Optionally, you can import product barcodes so that they can be used to scan items in Store Connect.
About OCDS or Merchandising Omni Services: You can use OCDS or Merchandising Omni Services to import data that originates in Oracle Retail Merchandising Foundation Cloud Services.
Note:
When Order Administration integrates with Order Orchestration for customer order fulfillment, if either product integrates with OCDS or Merchandising Omni Services, the other product also needs to be integrated with OCDS or Merchandising Omni Services.Order Orchestration submits a web service request for each type of import, and uses the data in the response to update each target table.
Note:
When RMFCS is the system of record for products, the product code is the same as the system product code in all systems in your organization, including the default system. For example, if the product code is 12345, then 12345 is also the system product code for all systems.Configuration: To import this data from OCDS or Merchandising Omni Services, first use the Add or Edit External Services window from the External Services screen to specify:
-
The URL to use when requesting data for each type of import.
-
The Active flag to indicate whether each import type is currently active. For example, you might perform an initial warehouse and store inventory load and then deactivate these imports.
-
Authentication information for the web service requests, as well as the wait time.
Then, use the OCDS Integration tab at the System screen to specify the default location types to use when creating warehouse and store locations.
Submitting the import: If any of the URLs defined at the Add or Edit External Services window from the External Services screen are flagged as active, data imports take place from OCDS or Merchandising Omni Services rather than from any other source. Importing data through the file storage API does not take place.
For more information: See OCDS or Merchandising Omni Services Imports.
File Storage API for Imports and Exports
About the File Storage API: The File Storage API is a RESTful web service that supports importing and exporting data: uploads, downloads, deletions, and inquiries. If the File Storage API is enabled, it handles all imports and exports through files, including:
-
Imports scheduled through the Schedule Jobs screen:
-
products, system products, and item image URLs for display in Store Connect
-
product locations
-
locations
-
product barcodes
-
-
Incremental inventory updates, scheduled through the Schedule Jobs screen
-
Exports scheduled through the Schedule Jobs screen:
-
Inventory quantity
-
Fulfilled inventory
-
Sales order data extract
-
Note:
Importing Data from Merchandising Cloud Services (RMFCS) through the Omnichannel Cloud Data Service (OCDS) or Merchandising Omni Services does not use the file storage API.The file storage API is enabled by default for new installations of release 18.0 or higher.
Other import and export options: Other import and export options are handled through web service messages, including:
-
Imports:
-
Product Update Request Message or Product Update Request JSON Message: creates or updates products, system products, and product locations
-
Availability Update Request XML Message: Updates the available quantity for product locations, or creates product locations if they do not already exist.
-
Location Update Request JSON Message: Create or update locations
-
CreateDSVendor Request Message: Create or update vendors
-
-
Exports:
-
System Discovery Request and Response XML Messages: Export a list of systems
-
Location Discovery Request and Response XML Messages: Export a list of locations for a system
-
Location Detail Request and Response JSON Messages: Request detailed information on all locations for a system
-
See the Web Services Guide on My Oracle Support (2953017.1) for information on the above web service request messages.
Use of the FILE_STORAGE table: The FILE_STORAGE table stores data on import files and export files, as well as errors that occur during import processing. The web service requests files from, deletes files in, and puts files in this table.
Web service requests: Requests supported by the File Storage API and their purposes are:
-
getFile: Download an export file or error file that has been generated by Order Orchestration.
-
deleteFile: Delete a file record, such as an export file that has already been retrieved.
-
putFile: Upload an import file to Order Orchestration. The file format can be text (.TXT file extension) or compressed (.ZIP file extension). If the file is compressed, Order Orchestration extracts the information when processing the import. No other file extensions are supported. Note: If you are uploading a zip file, then it must contain a TXT file of the same name as the ZIP file, and be in the base level of the file, with no subfolders.
The File Storage API returns an error if there is already an existing file in the table with the same name, regardless of whether the suffix is different. For example, the API returns an error if you attempt to upload a file named PRODUCT_SYS.ZIP if there is currently a FILE_STORAGE record named PRODUCT_SYS.TXT.
-
getFiles: Request a list of file records in the FILE_STORAGE table.
Every request needs to specify a container. The types of containers are:
-
OROB-IMPORTS: Import file records that can be processed through the File Storage API. For example, use the putFile request to create an OROB-IMPORTS record so that Order Orchestration can import the data.
-
OROB-EXPORTS: Export file records that have been generated through the File Storage API. For example, use the getFile request to download an export file, or use the deleteFile record to delete an export that has been downloaded.
-
OROB-ERRORS: Error file records that resulted from an import process through the File Storage API. For example, use the getFiles request to retrieve a list of error files that have been created.
All request messages also need to use a valid Storage web service user ID with a valid password. See Web Service Authorization for background.
File cleanup:
-
Import file records: Order Orchestration deletes these file records when they are processed, although errors are retained in the OROB-ERRORS container of the file storage table.
-
Export file records: It is the responsibility of the integrating system to delete these records. They can be deleted through the deleteFile request message.
-
Error files records: These records are purged automatically through the daily cleanup job based on the number of days specified in the File Storage setting under Retention Settings at the Tenant-Admin screen.
Reviewing or deleting file storage records: Use the File Storage History screen to review and, optionally, delete file storage records.
Enabling the File Storage API: The File Storage API is enabled if the STORAGE_ID in the TENANT_CONFIG table in the Admin database is set to database. This entry is set by default for a new installation of Order Broker 18.0 or later. To enable File Storage after upgrading from an earlier release of Order Orchestration, contact your Oracle representative.
Summary of File Storage API responses: The response codes that might be returned to file storage requests include:
-
200 = The getFile or getFiles request was successful.
-
204 = The putFile or deleteFile request was successful.
-
401 = The request failed because the web service user and password were not correct.
-
403 = The file you attempted to upload from RMFCS exceeded 1 GB.
-
404 = The request failed for other reasons.
For more information: See the Order Orchestration File Storage API technical reference paper on My Oracle Support for more information on implementing this API.
Import Process Overview (Other than RMFCS File Upload through OCDS or Merchandising Omni Services)
For information on imports from RMFCS, see Importing Data from Merchandising Cloud Services (RMFCS) through the Omnichannel Cloud Data Service (OCDS) or Merchandising Omni Services
Import processing steps: Processing steps are parallel for all types of information:
-
The process clears outdated records from the import tables (location_import, product_import, product_barcode_import, and product_import_log) based on the Days to Keep Errors specified for the system at the Schedule Jobs screen. If a record is flagged with an error code, it remains in the import table until the Days to Keep Errors has passed and you next run an import for that system; otherwise, the process adds or updates the record or field in the target table (location, product, system_product, or product_barcode), and the record is cleared the next time you run an import for the system, regardless of whether the Days to Keep Errors has passed.
Note:
The product location import does not use an import table; instead, it updates the product_location table directly.Note:
The product location import file name can include an optional suffix to indicate information such as the location code or a date/time stamp. Use of a file name suffix enables the inventory system to stage multiple product location import files throughout the day, and have the files processed in order when Order Orchestration runs a scheduled import. See Importing Product Locations through File Storage API for more information. -
The process checks the FILE_STORAGE table for a record, created from a compressed (ZIP) file and extracted when the FILE_STORAGE record is created.
The process uses files or records named LOCATION_SYS.TXT, PRODUCT_SYS.TXT, PRODUCT_LOCATION_SYS.TXT, and PRODUCT_BARCODE_SYS.TXT files, where SYS is the system code running the import. The product location import file name can include an optional suffix to indicate information such as the location code or a date/time stamp. Use of a file name suffix enables the inventory system to stage multiple product location import files throughout the day, and have the files processed in order when Order Orchestration runs a scheduled import.
-
For each pipe-delimited file record, the process confirms that the data is formatted correctly and can be loaded into the related import table. For example, it checks whether a record includes an incorrect number of columns, has alphabetical characters in a numeric field, includes an improperly formatted date, or includes a field that exceeds the maximum length in the database. If there are any basic formatting errors in the uploaded data, it makes a copy of the file containing just the records in error in an OROB-ERRORS record in the FILE_STORAGE table with a message indicating the nature of the error.
-
The process deletes the record from the FILE_STORAGE table.
-
The process creates records in the import tables (location_import, product_import, or product_barcode_import) with any records that passed the basic edit. This step does not take place for product location records.
-
The process checks the location, product, and product barcode in the respective import tables for specific data errors, such as confirming that a product or system is correct, and flags the import file records with any errors.
-
For the product location import, the records in the FILE_STORAGE record or the PRODUCT_LOCATION_SYS.TXT file are checked for errors. Any entries in the record or import file that pass the edits update the PRODUCT_LOCATION table.
-
Any records in the import table that pass the edits update the target tables. Any empty fields in the import table do not update the target table; however, in the case of location updates, the location address is treated as a unit, so if any address data is passed for a location, the entire address is replaced with the data from the import table, including clearing any fields that are empty in the import table.
-
The process writes a log record for each import process. Import history information is available for review at the Product Imports History screen. History is retained for the number of days specified in the Job History retention setting at the Tenant-Admin screen.
-
Details on each product, location, or barcode record in error are available on a related error report (the Location Import Errors Report, Product Barcode Import Errors Report, or Product Import Errors Report). Also, the process updates the information on the last process date, time, and user for the system.
-
Based on the Location Product Import setting at the Event Logging screen, the process generates an email notification indicating success (if all records were successfully imported) or failure (if any record could not be imported).
Reset fulfilled quantity during product import? If the system’s Track Fulfilled Quantity field is set to Reset During Product Import, each product location is reset before the import process finishes. The Last Status is not updated at the Schedule Jobs screen until this last step is complete.
Note:
Oracle recommends that you do not use UPC codes as system product codes, because UPCs are not permanently assigned to a single product.Running the process: You can set up a periodic processing schedule at the Schedule Jobs screen. You can also run the process on demand at that screen.
Updating or creating product locations through inventory inquiry: When Order Orchestration requests updated inventory information from an online system as a result of a LocateItems request, Product Availability request, or SubmitOrder message, or when “reshopping” a rejected order, it updates the availability information for existing product locations, or creates new product locations if they do not already exist. However, it does not send an inventory inquiry to a system unless a product location for the item and system already exists.
Note:
Order Orchestration updates the product location records only if the Update Offline Inventory flag at the Preferences screen is selected.Using the product update or availability update request messages:
-
Product update request message: Enables you to create or update products, system products, and product locations; however, does not update product location attributes, and does not update item image URLs.
-
Availability update request message: Enables you to increase, decrease, or reset the available quantity for a product location.
These options can be useful for ad hoc updates. See the Web Services Guide on My Oracle Support (2953017.1) for more information.
Processing incremental inventory updates: Optionally, you can run an update program to import updated inventory levels from an integrated system, and then calculate the probable quantity available in each of the system’s product locations after factoring in any reserved quantity and current probability rules. A system can then retrieve the updated inventory information, including calculating the probable quantity, and use this information (for example, display this quantity on the ecommerce site). See the Incremental Inventory Import for more information.
For more information: See:
-
System, Schedule Jobs, and Product Imports History: configuring the import process and reviewing completed imports.
-
Importing Locations through File Storage API, Importing Products and System Products through File Storage API, Importing Product Locations through File Storage API, and Importing UPC Barcodes through File Storage API: import details, file layouts, and data mapping.
-
Product Barcode Import Errors Report, Product Import Errors Report, Location Import Errors Report: reviewing errors.
-
Web Services Guide on My Oracle Support (2953017.1) information on the interactive RESTful inventory update.
Additional Types of Import Processes (Other than RMFCS File Upload and OCDS or Merchandising Omni Services)
The additional types of import processes you can use to create and update locations, products and system products, product locations, and product barcodes in Order Orchestration are described briefly below.
RMFCS: For information on imports from RMFCS, see Importing Data from Merchandising Cloud Services (RMFCS) through the Omnichannel Cloud Data Service (OCDS) or Merchandising Omni Services,
Available-to-Sell Individual Inventory Updates through Oracle Retail Integration Cloud Service (RICS)
Order Orchestration processes individual inventory updates whenever they are received from through Oracle Retail Integration Cloud Service (RICS). This information originates in Oracle Retail Merchandising Foundation Cloud Service (RMFCS) or Enterprise Inventory Cloud Service (EICS). Processing this update requires Oracle Retail Integration Cloud Service authentication; see Web Service Authorization for more information.
Information received: The information in the individual inventory update maps to the availability update request:
-
If the product location already exists, only the Available Quantity is updated with the available to sell quantity passed. The current available quantity is overwritten with the available to sell quantity passed; no calculation takes place. This update functions the same way as a method of SET passed in the availability update request message.
-
If the product location does not already exist, it is created, using the system item, location, and location type passed.
If any of the information passed does not map correctly into the existing data in Order Orchestration, Order Orchestration returns an error to the RICS. Examples of incorrect data include:
-
The user name and password for web service authentication are not valid.
-
The item, location, or system do not exist.
See the Availability Update Request XML Message and Availability Update Response XML Message in the Web Services Guide on MOS (2953017.1) for more details.
Import Files
For import through the File Storage API for Imports and Exports, pipe-delimited files containing location, product, product location, and product barcode information are placed in the FILE_STORAGE table through a RESTful web service. You use the Schedule Jobs screen to set up an import schedule to process the data and create or update the related records in the database.
Periodic import from files does not require the system to be flagged as Online. The Online setting at the System screen indicates that Order Orchestration obtains current inventory information from the system when the Routing Engine evaluates which locations might be able to fulfill an order. Order Orchestration updates the product location records with this information only if the Update Offline Inventory flag at the Preferences screen is selected.
Additional import processes are described below.
Interactive Updates
Interactive inventory update through RESTful service call: If the system is flagged as Online and a URL is specified, Order Orchestration also uses a RESTful service call to request current inventory information for a specific product when it requires the information for a LocateItems request, a SubmitOrder request, or a Product Availability request, or when it needs to “reshop” a rejected order. In this case, the Remote System Service returns the information in a RESTful service response rather than in flat files.
Order Orchestration updates the product location records only if the Update Offline Inventory flag at the Preferences screen is selected.
Obtaining interactive updates from SIM or EICS: Order Orchestration can request interactive inventory updates from Oracle Retail Store Inventory Management (SIM) or Enterprise Inventory Cloud Service (EICS). If a system is flagged as Online and a Connection Type of SIM is specified, Order Orchestration sends a request message to obtain interactive inventory updates for a specific product when it requires the information for a LocateItems request or a SubmitOrder request, a Product Availability request, or when it needs to “reshop” a rejected order.
SIM returns the current Total Stock On Hand from the store location that matches the product location in Order Orchestration, and the Available Quantity for the product location is updated with this quantity. If the Item Status in SIM or EICS is Deleted, Discontinued, or Inactive, the Available Quantity for the product location is set to 0.
Differences between Order Orchestration and SIM or EICS:
-
Even if the Item Status in SIM or EICS is Deleted, Discontinued, or Inactive, the Available Quantity for the product location is set to 0. However, the product location may still be eligible for order assignment if the Backorder Available flag for the location is selected.
-
The response from SIM or EICS does not update the Next PO Date or Next PO Quantity for a product location.
-
SIM and EICS support a decimal position for the available quantity. If the available quantity passed from SIM includes a decimal, Order Orchestration truncates the number. For example, if SIM passes an available quantity of 12.75, the available quantity in Order Orchestration is set to 12.
Incremental Inventory Import
Optionally, you can configure a system to periodically run an import of updates to product location records. This process enables you to schedule incremental product location updates from the integrated system. See the Incremental Inventory Import option at the Schedule Jobs screen for details.
Reporting Options
Overview: Order Orchestration provides several operations reports. You can run reports on demand as well as schedule reports on a daily or weekly basis.
Operations reports: The reports provided with Order Orchestration are:
-
Auto Cancellation Report: A list of orders that include lines that have been automatically canceled. See Auto-Cancel Unclaimed Orders for a discussion.
- Unfulfillable Report: A list of orders that were completely
or partially unfulfillable. The information on the report includes
the customer’s name, email address, and phone numbers, as well as
the type of order and whether the order is fully or partially unfulfillable.
Order Status Report: A list of orders which you can generate by status, type, originating or fulfilling location, region, or ship via.
-
Zone List Report: Identifies the locations assigned to each active or inactive fulfillment zone as either a primary or alternate fulfilling location, and lists locations that are not assigned to any zones.
-
Import Errors Reports: A list of locations that failed when importing locations, products, system products, product locations, or product barcodes.
Report formats: You can generate reports in PDF format; in XLS format (so that you can open the report in a Microsoft Excel®); or in both formats. You can view or download the reports from a window in Order Orchestration and can send them by email to one or more recipients.
The Data Formats defined for the organization control the language, numeric, and date formats on reports. See Localization Settings for more information.
Scheduling reports: You can create one or multiple schedules for a report, specifying which day(s) of the week and which time(s) of the day when Order Orchestration should generate the report automatically. Each schedule can specify different selection criteria, such as different order statuses, locations, or date ranges. Also, you can specify an email distribution list for each schedule of a report.
Anonymizing Data
Purpose: Order Orchestration offers two options for anonymizing private data: a web service that can anonymize various types of data on demand, and a scheduled job that anonymizes closed sales orders and purchase orders based on the time period since the orders were created.
Private data web service: This web service includes two types of requests and responses:
-
GetPrivateData: The GetPrivateData request can request private data for customers, orders, vendors, and users.
-
ForgetPrivateData: The ForgetPrivateData request can inquire on whether private data for customers, orders, vendors, and users is eligible to be anonymized, or can request that the data be anonymized.
When the data is anonymized, it is converted to asterisks. Once the data is anonymized, it cannot be recovered.
Purging customer data from completed orders: The Completed Order Private Data Purge job enables you to anonymize customer data on completed orders based on the number of days since the orders were created (retention days).
The types of personal data that can be anonymized are:
-
customer names, addresses, email addresses, and phone numbers (sold-to and ship-to) and sales orders and purchase orders
-
vendor names, addresses, email addresses, and phone numbers
-
Order Orchestration user names and email addresses
-
Vendor user names and email addresses
-
Store Connect associate names and email addresses
-
brand contact names and email addresses
Orders and purchase orders are eligible to be anonymized only if they are no longer open, and a vendor is eligible to be anonymized only if there are no open purchase orders for the vendor. When a vendor is anonymized, it is flagged as inactive; however, Order Orchestration users, vendor users, and store associates are not automatically deactivated when they are anonymized.
For more information: See the Web Services Guide on My Oracle Support (2953017.1) for information on the web service requests that support inquiring on private data, inquiring on whether it is eligible to anonymize it, or requesting to anonymize it.
Time Zones
Overview: The time zones used for Order Orchestration include the following:
-
system time zone: Set to UTC (Coordinated Universal Time). This time zone is used for dates and times in the database and web service responses.
-
retailer’s time: The Time Zone specified at the Tenant (retailer information) screen. This time zone is displayed on most Order Orchestration, Store Connect, and Vendor Portal screens and in generated email notifications. It is used for scheduling imports, exports, and report generation, and to calculate the number of orders for Maximum Daily Orders.
-
user’s time: The time zone on the user’s personal computer or specified in the user’s browser. In most cases, the times displayed on screens and indicated in emails are in the retailer’s time rather than the user’s time.
Example: system time zone = UTC retailer’s time zone = UTC - 5:00 (for example, U.S. Eastern Time) user’s time zone = UTC - 8:00 (for example, U.S. Pacific Time)
| Event | Time Used or Displayed |
|---|---|
|
order created |
SubmitOrder response, database update, log entries: 2:00 (system time) Displayed on screens in Order Orchestration and Store Connect, such as order history: 7:00 (retailer’s time) Note: When using a screen to search by date, such as searching based on order date, the retailer’s time is used. For example, if an order was created at 01:00 (01:00 a.m.) June 29 system time, and 20:00 (10:00 p.m.) June 28 retailer’s time, searching based on an order date of June 28 displays the order, while a creation date of June 29 does not. |
|
imports scheduled and executed |
Schedule Jobs screen: 13:00 (1:00 p.m.) (retailer’s time) Database entry: 18:00 (6:00 p.m.) (system time) Confirmation email: 13:00 (1:00 p.m.) (retailer’s time) |
|
setting up probability locations |
The From Date and To Date at the Probability Location screen: no time is displayed, but date is calculated based on retailer’s time. |
Changing the time zone: Whenever the Time Zone is changed at the Tenant screen, it is necessary to update all schedules, including imports, exports, report generation, polling, and notifications.
Exceptions: Screens that use the user’s time rather than the retailer’s time:
-
Vendor Portal:
-
landing page: dates for calculation of updates and graphs
-
Purchase Order Shipping: default shipment date
-
Invoice: default invoice date
-
Also, the user’s time applies when prompting on a calendar entry.
Localization Settings
The following table indicates the source of localization settings for Order Orchestration screens, reports, and emails. The currency, if indicated, is always from the order.
See the Supplier Direct Fulfillment Overview for information on localization settings used for the Vendor Portal, and see Store Connect Overview for information on localization settings used for Store Connect.
| Language | Data Formats | |
|---|---|---|
| reports |
organization; see the Organizations screen |
organization |
| emails |
organization |
organization |
| screens |
locale appended to URL (for example, ?locale=fr, where fr indicates French). Supported locales are:
|
user profile, as defined when creating the user from IDCS or OCI IAM; however, if the locale specified for the user is not valid in Order Orchestration, a locale of en_US is assigned. |