Smart Sourcing

To improve performance, smart sourcing can be used to dynamically determine the nodes to consider for sourcing product items.

Smart sourcing helps in performance and configuration of scheduling and fulfillment of orders from a store. For example, consider a scenario where you have to source product items for 3,000 stores based on regions and distribution groups. In case of normal sourcing, the distance for all 3,000 stores has to be calculated to the address before they are filtered out to be considered for sourcing. Therefore, there might be certain level of performance implications. Reducing the nodes manually can cause situations wherein same two items are fulfilled from two different locations, but they could ideally be fulfilled from a single node. Smart sourcing helps in reducing the nodes to be processed for sourcing, but still provides the best possible option. In order to take full advantage of the Smart Sourcing feature, both Realtime Availability Monitor (RTAM) and node-level RTAM for all nodes that are considered for smart sourcing must be running. Smart Sourcing uses the requested delivery method to look up node-level RTAM data. If Smart Sourcing cannot find the requested delivery method, the shipping delivery method is used. It is assumed that RTAM is monitoring at least shipping.

By default, the Smart Sourcing Allowed flag is enabled in the sourcing rule to dynamically determine the nodes to be considered for sourcing. When sourcing, the order lines are grouped into lines that require smart sourcing to be applied, lines to be used for common node consideration, and lines not applicable. A line is required for smart sourcing when it meets all of the following criteria:
  • Smart sourcing is enabled.
  • The current sourcing rule allows for smart sourcing.
  • Sourcing added more than the configurable number of nodes.
For example, assume that smart sourcing is enabled for 10 nodes; Item1 is sourced from a distribution group that has five nodes and Item2 sourced from a distribution group with 15 nodes. Based on data that is provided in YFS_INVENTORY_ALERTS, sourcing first determines the 10 best nodes to read inventory for Item2. So, when determining the best options, Item1 is considered for five nodes and Item2 is considered for 10 nodes. If for some reason (either through constraints, inventory picture, and so on) it cannot find all quantity for Item2, smart sourcing will be expanded for Item2 to use only nodes that have inventory. Item1 is not expanded (2nd sourcing rule detail is not considered; procurements are not expanded, and so on).

The goal of the smart sourcing is to avoid reading and processing inventory for nodes that do not contain inventory. If the item is determined to be available at many nodes, determination of the nodes is based on the optimization type. When multiple lines and addresses are concerned, sourcing dynamically chooses nodes based on different criteria. If multiple lines are being promised, nodes found across all items are considered for lines with availability.

Smart sourcing uses data that is provided in the YFS_INVENTORY_ALERTS table to identify the nodes that must be considered for smart sourcing. Depending on the sourcing rule detail configuration, the query that is fired against this table differs. It is suggested to analyze this query and apply an index to the table with the columns that are queried to ensure that the ideal plan is chosen. In addition to an index on this table, ensure that the CLOB column, AVAILABILITY_INFO, is in its own tablespace. In Release 9.5, AVAILABILITY_INFO is replaced by the INV_INVENTORY_ALERT_DETAIL table.