About Sourcing
Overview
Sourcing rules control how an order is fulfilled. The ROM user interface enables clients to set up and adjust the order sourcing logic by defining specific rules that control the fulfillment process.
To facilitate order brokering, ROM uses two types of sourcing rules:
Core Rules, which identify all nodes that could fulfill an order.
Seller Rules, which identify the optimal fulfillment for the order.
The rules depend on the overall fulfillment network setup, geographies served, and supported fulfillment types combined with their optimization choices.
Considerations for Core Rules
To determine the Core Rules should be set up for a seller, consider the following factors:
- What fulfillment types are supported?
- Ship-to Store fulfillment?
- Ship-from Store fulfillment?
- In-Store Pickup?
- DC only fulfillment?
- Dropship fulfillment?
- What Ship-to destinations are supported?
- Domestic US only?
- International shipping?
- APO/ FBO/ DPO addresses?
- Are there order types that require different order brokering, such as Marketplace or Retail Connection orders?
- Do you sell Hazmat items that need to be fulfilled by a DC versus a retail store?
- Do you offer Giftwrap? If so, are your retail stores set up with the materials and training to do it?
- Is ROM determining the sourcing location?
- If Ship-from Store is enabled, should there be a limit on the number of orders released to each store location per shift?
- If Ship-from Store is enabled and there are store locations in Alaska, Hawaii or Puerto Rico, do you want to always try to source from the store within that location first for order with Ship-to addresses in those locations?
- If Dropship is enabled, do you always want to source to the primary vendor first?
- If you support preorders, do you always want to source them to DCs?
- Do you have SKUs that are only stocked in a DC and not in your store network?
- Do you want all orders with overnight ship methods to be shipped from the DCs?
Define and Set Up Core Rules
Core rules are composed of selection criteria, including fulfillment types and attributes, and sourcing rules, which form a core rule set. You can have one or multiple active rule sets.
You can schedule core rules to be active for set amount of time. For example:
During Black Friday weekend, change the priority to source from DCs and lower foot traffic stores, and optimize by date as opposed to minimal shipments.
Selection Criteria
A rule can have one distinct criteria set, for example:
For all STH orders, source in this order: DCs first, followed by Retail Stores within the lower 48 states.
You can also combine criteria; for example:
For all STH orders that have overnight shipping, only consider DCs.
Each order line identifies the best-fit core rule based on the selection criteria.
The following table describes the selection criteria and when to use them.
Criteria | Description | When To Use? |
|---|---|---|
Fulfillment Type: Ship-to Home (STH) | Ship the order to the shoppers (home) address. The order can be shipped from a DC, a retail store, or a drop shipper. | Set this up as a default for all clients. If you want to have different shipping rules for these states/ territories/ countries where more expensive to ship to, consider setting up separate Ship-to Home rules for:
Within each of these areas, you would define a Ship-to Region Group that contains the individual state/countries. |
Fulfillment Type: Ship-to Store (STS) | Ship the order to a store address to complete an in-store pickup. The order can be shipped from a DC, a retail store, or a drop shipper. | Use this criterion when STS is supported and it should have a different sourcing priority than the STH core rule. Additionally, if you set up separate STH core rules for Alaska, Hawaii, and Puerto Rico, then set up separate STS core rules. Generally, the top sourcing priority for an STS order is the Customer Pickup Location (because it's the cheapest place). |
Fulfillment Type: In-Store Pickup | Fulfill the order from a specific node (store)from which the shopper retrieves the order. | Because the order routes to a shopper-specified store, this criterion is not necessary. |
Item Id | When an item ID is entered, any order line with this specific item ID is routed according to the core rule setup. | Use this criterion when to route a SKU to a specific fulfillment node (such as a DC). |
Type | At the item level | |
Dropship | At the item level | Use this criterion when an item is eligible for dropship. Some clients choose to have the fulfillment node sourcing priority to try to fulfill from retail stores/DC first, and then to dropship vendor. Other clients choose to only consider the dropship vendor. |
Preorder | At the item level | Use this criterion when the item is eligible for preorder. Generally, preorders have only the DC listed as the fulfillment node sourcing priority. |
Item Sourcing Classifications | You can identify up to three generic attributes. You can specify them in the Item Master feed or on the Item screen in the ROM UI. | Based on specific client-defined sourcing needs. Example: If the client sources based on an attribute in the item master, a sourcing rule can use those specific attributes. |
Associate Delivery | At the item line level | Use this criterion when the order is a same-day delivery order and the Store Associate delivers the order. |
Shipping Method | At the item line level | Use this criterion when an order should be routed based specifically on the shipping method on the order line item. |
Bulk Order | At the order level | Use this criterion when a bulk order needs to be routed to a fulfillment location that handles bulk orders. |
Order Source | At the order level | Use this criterion when the order has a specified source code (such as a Marketplace order) and the fulfillment needs are different from the standard STH rule, or there are fulfillment geography restrictions. |
Within a defined shipping region | When included, the rule is only used to source order lines to ship-to addresses that fall within the regions included in the group. | Use this criterion when shipping is supported to areas such as Alaska, Hawaii, Puerto Rico; and you want to ensure that they are fulfilled from a specific location (such as a DC) first and retail store node types second. Examples:
Note: Shipping Regions are set up (by zip code range, by state etc). Then 1 to many Shipping Regions are added to a Ship Region Group. A Ship Region Group can be added here to a Core Rule. There can be only one Ship Region Group per Core Rule. |
The following table shows an example of a Ship Region File set up using postal codes.
Ship Region Name | Postal Code Low | Postal Code High |
|---|---|---|
Ship Region 1 | 00050 | 00060 |
Ship Region 2 | 00080 | 00090 |
Ship Region 3 | 00100 | 00200 |
Ship Region 4 | 00300 | 00400 |
The following tables shows an example of a Ship Region Group file.
Ship Region Group Name | Ship Regions Included |
|---|---|
Node Preference Order Grouping 1 | Ship Region 1, Ship Region 3 |
Node Preference Order Grouping 2 | Ship Region 2, Ship Region 4 |
The following table shows an example core rule setup.
Core Rule Name | Node Priorities | Shipping to Region Group (only one allowed per rule) |
|---|---|---|
Node Preference 1 | 330 346 427 468 | Node Preference Order Grouping 1 |
Node Preference 2 | 468 346 427 330 | Node Preference Order Grouping 2 |
Sourcing Rules
The core rule sourcing rules include:
Override Definitions, including the Fulfillment Network Override and Fulfillment Geography Restriction toggles
Fulfillment Nodes for Sourcing Priority (Mandatory)
Inventory Burn Rule (Mandatory)
Override Definitions
The following table defines the available override settings and when to use them.
Overrides | Description | When To Use? |
|---|---|---|
Network Override | When enabled, only fulfillment nodes types identified within the override network are used to source the item. An Item Sourcing Override attribute is provided by retailers in the Item Master feed/ Item Screen (Sourcing Override). If a Sourcing Override attribute is provided for the item, then the item will be sourced according to that definition. If a fulfillment location is not identified within the override network, the item is cancelled. | This would be used to limit the potential fulfillment nodes to either DC only or Retail Stores only. If DC only is indicated, then only DC nodes will be considered. If Retail Stores only is indicated than only retail stores will be considered. |
Geography Restriction | Fulfillment locations that locations that fall within the 'Ship From' Regions cannot ship to the locations within the 'Ship To' regions. The ship to address of the item in the request is used to determine which fulfillment nodes cannot ship to the destination address. Those nodes are then excluded from sourcing the item. | This is optional and should only be configured to enforce geography restrictions. Example: If international shipping is supported, restrictions may be set up that nodes that fall within the US48 Node Group that contains all store fulfillment nodes within the lower 48 states are not allowed to ship to nodes that fall within the China, Japan, India or Canada node groups Used when SFS is used in multiple countries and wish to prevent cross border shipments from stores. |
Fulfillment Nodes for Sourcing Priority
Mandatory Configuration
The sourcing process determines the potential fulfillment nodes for the order line item. This determination is based on the defined priority order of the fulfillment nodes.
- You can configure one to many fulfillment node types. For each type, you must define a priority ordered; the system does not define it.
- The lower the number, the higher the priority.
- You can set up multiple types with equal priority. In this case, ROM considers those types with the same priority. For example, if Node123 has the same priority as a Zone Group, ROM selects both Node 123 and all of the nodes within that Zone Group.
The following table describes the node types you can use and tells you when to use them.
Types | Description | When To Use |
|---|---|---|
By Node | Select an individual node. | Use this node type to route an order line (defined by item, item attribute, and so on.) to a specific node for fulfillment. For example, route aAll hazmat items to a DC. |
By Node Group | Select a node group. A node group comprises one to many individual nodes; for example, all retail stores within the country of Italy. This node group could be called Italy Retail Stores. | Use this node type when an order line should be considered by multiple nodes that have been logically grouped into a Node Group. ROM considers the nodes in the group to have equal priority.. Example: Assume you have a Core Rule of STH - Puerto Rico, where the Ship-to Region Group includes all ship-to addresses within Puerto Rico. The top priority might be a Node Group that contains all retail stores within Puerto Rico. The second priority might be a Node Group that contains both DCs in the eastern half of the US. The third priority might be a Node Group that contains all retail stores within the US48 states. Suggested potential node groups: · US48: includes all nodes within lower 48 states. · Hawaii: Includes all nodes within state of Hawaii. · Alaska: Includes all nodes within state of Alaska. · Puerto Rico: Includes all nodes within territory of Puerto Rico. · High traffic stores: Includes all nodes that have high foot traffic (where you might want to restrict sourcing of SFS orders). · Low traffic stores: Includes all nodes that have low foot traffic (where you might want to increase sourcing of SFS orders). |
By Zone Group | Select a zone group. ROM uses the UPS Shipping Zone Groups, which use data from UPS itself. The zip code range (from and to) determines what zone the order line falls into.
Note: Zone Calculations calculate how far the destination is from fulfillment nodes. This data is used to calculate shipping costs. | Use this node type when an order line should be considered by all nodes that are within pre-defined distances from the ship-to address. This type excludes the weight of packages. Typically, these would be set in ascending order Zone 2, Zone 3, Zone 4, and so on. |
By Distance Group | Select a predefined distance group. The distance groups allow user-entered mile/kilometer range. For example: you can set up a distance group of: · Distance Group 1: 1 - 500 miles · Distance Group 2: 501+ miles Note: Non US locations would use Distance Group vs Zone Group | Use this node type when an order line should be considered by all nodes that are within pre-defined distances from the ship-to address. |
By Drop Ship Vendor | Defaults to the Primary Vendor. | Use this node type when supporting dropship items. |
By Pickup Node | Defaults to the customer pickup location. | Generally, the top sourcing priority for an STS order is to source the order from the customer pickup location (because it's the cheapest place). |
Inventory Burn Rule
Mandatory Configuration
Burn Rule | Description |
|---|---|
Highest ATP | Use the node that has the highest available to promise inventory. |
Highest Computed Supply | Based on supply factor for node/item, then calculated as (ATP * (supply Factor + 1). |
Profitability | Based on retailer-provided value for node/ item. |
Define and Set Up Seller Rules
Seller Rules are applied after the Core Rule selection. ROM moves to optimize the order itself and takes all order lines into consideration to determine the optimal fulfillment for the order, not order line level. Only one set of seller rules is configured.
Seller Rules have four aspects:
Fulfillment Optimization
Fulfillment Constraints
Sourcing Restrictions
Node Prioritization
Fulfillment Optimization
The following table describes the fulfillment optimization methods.
Optimization Method | Description |
|---|---|
Min Shipment | If listed as a higher priority, ROM looks to see if inventory is available (at the same node) within a the configured optimization date range. If inventory for all order lines within the order are available within the date range, the order lines will be held until all order lines can be fulfilled. Example: Optimized Date Range = 3 days. Order has 2 line items. Line Item A is available today. Line Item B will be available 2 days from today. In this case, the order will be held to result in the minimal number of shipments. If ROM identifies multiple shipping options that result in the same number of shipments, then the Date rule is applied. When selected, there are often less splits. ROM will select the store that can fulfill it without splitting Note: This option would be used when cost savings is prioritized Note: If inventory is outside of date range, ROM looks to identify what we can fulfill fastest |
Date | If listed as a higher priority, ROM ships as items becomes available and we don't look for future inventory. When selected, there are often more splits (and ROM will send to a node that can fulfill the item first) Chooses location(s) with earliest availability date |
Landed Cost | If selected, when more than one location is identified as the potential fulfillment node to source order lines, ROM will use the cost to determine which fulfillment node is closer. This is done using zoning costs only and does not include labor costs. When this is selected, it overrides the other optimizations and finds the location which is proximity based. When selected, store nodes will more often win as they are more distributed than DCs. Note: ROM utilizes the UPS zoning tables. When landed cost is selected, there is no need to set up Fulfillment Sourcing Priorities by Zone Group. Landed cost computation - relying on data that UPS provides us. If they use FedEx, they will use UPS. Download if from there. Once we know location has which inventory, at that time simple logic item (qty), weight of item, here is the price from X location to Y location. Computer ship cost. Ship cost is used to (eachitemnode), compute net cost for entire order. |
Optimized Date Range | The number of days that ROM will hold an order to reduce the number of shipments. This is used in the Min Shipment calculation above. |
Fulfillment Constraints
Fulfillment constraints work within the Fulfillment Optimization settings. They are very powerful settings. Be sure that you understand them fully before selecting them.
Best Practice: Default settings is to have none of these options selected which will have an end result of ROM fulfilling as much as possible in as little shipments as possible.
Constraint | Description |
|---|---|
Order Ship Complete | ROM ensures that an order is shipped entirely or not at all. ROM will allow the order to be fulfilled via multiple nodes). ROM will automatically cancel the order if unable to fulfill the entire order. |
Order Ship from Single Node | ROM will ship an order from a single node but will allow multiple shipments (that can span dates). ROM does not require that the entire order be fulfilled completely. |
Line Ship Complete | ROM ensures that an order line is shipped entirely or not at all. ROM will allow the order line to be fulfilled via multiple nodes. ROM will automatically cancel the order line if unable to fulfil the line completely. |
Line Ship from Single Node | ROM will ship all order line items from a single node but will allow multiple shipments (that can span dates). ROM does not require that the entire order line be fulfilled completely. |
Note: If all settings are selected, ROM enforces the following two settings: Order Ship Complete + Order Ship from Single Node
The following examples show how Order Ship Complete works.
- Easton declines both lines.
- If both lines are available at Rialto, both lines release to Rialto.
- If one or both lines are unavailable at Rialto, both lines are canceled.
- Easton declines one line and ships the other.
- If the line is available at Rialto, it is released to Rialto.
- If the line is not available at Rialto, it is canceled.
ROM enforces the ship order complete constraint during every sourcing attempt. However, once the order is released (if ROM believes the fulfillment node(s) to have the inventory), then the fulfillment location is in control of the fulfillment.
In the warehouse, the warehouse management system (WMS) could potentially have a control in place to make sure to enforce ship order complete.
The ship order complete flag attempts to ensure the order is shipped complete, but cannot guarantee it if the inventory is not actually available.
Sourcing Restrictions
The parameters are applied whenever a sourcing process is executed.
The following table shows best practice for sourcing restrictions.
Restriction | Description |
|---|---|
Max Splits | The maximum number of shipments that a sales order can be split into. ROM's max allowed is 4 The final action (cancel or route to order exception queue) is the configured max splits + 1 |
Max Resourcing Attempts (Standard | Expedited) | The maximum number of times that ROM will try to source an order line in the event that inventory is not found (and a pick decline action takes place). ROM's max allowed is 5 The final action (cancel or route to order exception queue) is the max resourcing attempts + 1 |
Exclude Drop Ship Client Paid | When selected, Drop Ship nodes (client paid) are not included in the Max Split calculations. When enabled, orders sourced from Drop Ship nodes are not cancelled when they exceed the Max Splits rule |
Exclude Drop Ship | When selected, Drop Ship nodes (client paid & Radial paid) are not included in the Max Split calculations. When enabled, orders sourced from Drop Ship nodes are not cancelled when they exceed the Max Splits rule |
Node Prioritization (Optional)
The following table shows best practice for node prioritization.
Prioritization Method | Description |
|---|---|
Use Fulfillment Node Preference | Retailers provide a Sourcing Preference attribute within the Item Master Feed. If this option is selected, ROM will use this value as a final tie breaker after optimization and constraints are applied. (i.e. use DCs only or use Stores only) |
Use Node Preference | Retailers provide a Node Preference attribute within the Facility Feed (for retail stores only). If this option is selected, ROM will use this value as a final tie breaker after the inventory burn rule is executed. If a preference is not provided for a store, it's considered the least preferred store. Also under fulfillment nodes in the ROM UI. |
Use Node Item Preference | Retailers provide a Node Item Preference attribute within the Facility Item Feed. If this option is selected, ROM will use this value as a final tie breaker after the inventory burn rule is executed ROM chooses the store with the lowest preference |
Business Logic
When an order is scheduled, the sourcing logic executes based on the configured core rules. The system uses the following process for each order line:
- ROM identifies the core rule set that has the most granular match based on the configured criteria.
- After selecting the core rule set, ROM identifies all nodes from the highest priority Fulfillment Nodes for Sourcing setting for that core rule.
- If the Fulfillment Geography Restriction is enabled and the ship-to address falls into configured rule, ROM excludes those node(s).
- If the Network Override Rule is enabled, ROM excludes those node(s).
- If multiple Fulfillment Nodes For Sourcing have the same priority rating, they are treated equally.
- ROM identifies the inventory available for each of the remaining nodes. Note: On-hand and future inventory are taken into consideration for the availability calculation.
- If none of the selected nodes has full availability to fulfill the item, ROM identifies all nodes from the next highest priority Fulfillment Nodes for Sourcing setting. It excludes those based on geography restrictions and network override settings.
- ROM continues to work through the sourcing order in sequential order.
Note: ROM considers the following node settings when determining availability:
- Node Status: Active
- Node: Enabled for Availability
- Max Items Scheduled to Node: When the max number of items has been met for the store with more inventory, then ROM either goes to the next store, or schedules the order to the store to be released at the next day/shift. (If the Max Item setting is not configured, then ROM goes by highest ATP.)
- Held Status: When inventory is in a HELD status, the inventory is returned as 0.
- Configured Overdue Supply
- Configured Overdue Demand
- Configured Forward Days to Consider Supply
- Configured Backward Days to Consider Supply
- Receipt Processing Time
- Advance Notification Time
- Reserved Demand
- When more than one location has the order line item availability, ROM applies the Inventory Burn Rule to prioritize the location.
- After potential nodes, with availability, are identified and the data is aggregated, ROM then moves over to execute against the Seller Rules to identify the optimal fulfillment.
- Seller Rules are applied after the Core Rule selection. ROM moves to optimize the order itself and takes all order lines into consideration to determine the optimal fulfillment for the order, not order line level. Only one set of seller rules is configured.
- ROM determines the fulfillment optimization type prioritized first:
- Minimum Shipments: If selected, ROM determines the inventory availability with in the configured optimized date range
- Date: If selected, ROM determines the earliest inventory availability date
- ROM filters out any options that exceeds the max splits or max sourcing attempts
- If there are multiple solutions with the same priority, then ROM determines:
- If Node Prioritization is set, ROM identifies the node choice based on the configured preferences:
- Fulfillment Network Preference (DC or Store)
- Node Preference (retail store ranking)
- Node Item Preference
- If Landed Cost is enabled, ROM identifies the node choice of closest proximity.
- If Node Prioritization is set, ROM identifies the node choice based on the configured preferences:
- Sourcing selection is made and fulfillment order(s) are appropriately routed.
Note: If the fulfillment type is ISPU, the item is routed to the shopper-identified node.
