Real-time Availability Monitor (RTAM) and inventory availability monitoring

E-commerce businesses often need real-time inventory availability indicators so that they can provide their customers with snapshots of the inventory picture without constantly making calls to Sterling Order Management System Software. Indicators can be helpful on web sites where orders are placed and the inventory is being viewed and modified often. Examples of inventory availability indicators are In Stock, Low, Limited, and Backorder/Pre-order, and Out of Stock.

Sterling Order Management System Software provides inventory monitoring functionality through the Real-time Availability Monitor (RTAM). RTAM is a time-triggered transaction that monitors inventory availability of inventory items and publishes availability by raising the REALTIME_AVAILABILITY_CHANGE_LIST event.

RTAM runs in three modes:
Activity-based mode

In this mode, Sterling Order Management System Software tracks inventory changes in real time. If the inventory level of an item changes, such as falling below a specified threshold, Sterling Order Management System Software raises the REALTIME_AVAILABILITY_CHANGE_LIST event, which publishes the updated inventory level to external systems, such as a web site.

Note: When RTAM runs in activity-based mode, the inventory availability monitor does not completely operate in real time. Inventory changes are published to a database table, which is processed by the monitor. Thus, think of activity-based mode as near real time.
Quick sync mode
When RTAM runs in this mode, Sterling Order Management System Software sends the most recent inventory availability information recorded by the monitor to external systems. For example, if an item's inventory level changes from In-Stock to Low and then back to In-Stock, Sterling Order Management System Software publishes only the 'In-Stock' level for that item at synchronization time.

Additionally, since inventory availability information includes on-hand and future availability, this mode can be used to send availability messages to the planning and promotion systems.

Full sync mode

Typically, an enterprise runs RTAM in full sync mode as a scheduled job, generally at night. Inventory availability information is sent for all items, regardless of whether or not availability changes occur for the items.

The Full Sync mode is expected to be used the first time the inventory availability monitor runs, if inventory information has not been loaded into Sterling Order Management System Software through the Sterling Order Management System Software APIs or services.

When you use RTAM, consider the following information:
  • When the onhand quantity is greater than the configured low threshold, the REALTIME_ONHAND alert type is raised, and the alert level is based on the onhand quantity.

    When the onhand quantity falls below the configured low threshold, the REALTIME_FUTURE_MAX alert type is raised. The alert level is based on the total future supply (FutureAvailableQuantity) with FirstFutureAvailableDate set to the date on which the first future supply is available and the FutureAvailableDate is set to the date on which the maximum future supply is available.

  • If a bundle item is configured to have its components ship independently, RTAM publishes inventory information for each component of the bundle item but not for the bundle item.
  • In all cases, the percentage of future inventory availability is used for considering inventory availability at retrieval time.
  • If configured, RTAM considers the onhand and future inventory availability safety factor during monitoring. For information about the findInventory() API, see the Javadoc.
  • If item information is not available on the system, such as when inventory between databases is not in sync, default inventory monitor rules can be configured so that monitoring proceeds. Setting these default inventory monitor rules also ensures that inventory activity is recorded when the system is running in activity-based mode.
  • When RTAM computes availability, RTAM uses the default scheduling rule of the inventory organization. For example, if Ignore Landed Cost is set in the scheduling rule, RTAM excludes landed costs from its calculations.

Publishing availability by delivery method

RTAM can be configured to publish availability by delivery method. When RTAM considers delivery methods, the following functionalities affect RTAM's calculations:
Safety factor
Safety factors are defined for delivery methods and can affect RTAM's availability calculations. RTAM uses the following logic to calculate availability:
Supply - demand - safety factor for delivery method =
For example, a consuming application, such as an online shopping website, displays availability information to in-store customers who search for items on mobile devices. In this example, RTAM calculates and publishes availability for the SHP and PICK delivery methods for item 1 at Store 1. Store 1 has a supply of 10 and demand of 3, the SHP safety factor is 1, and the PICK safety factor is 3. In this scenario, RTAM publishes availability for item 1 as 6 for the SHP delivery method and 4 for the PICK delivery method.

If safety factor is not defined for the delivery method for which availability is being calculated, the safety factor that is defined for the item, supply type, node type, item classification attributes, or item node definition is used.

Capacity is defined for delivery methods and can affect RTAM's availablity calculations. For example, if all capacity for SHP is depleted for the next 20 days but there's capacity for PICK and RTAM is configured to look within 10 days, RTAM reports 0 availability for SHP but actual inventory for PICK.

To configure delivery methods for RTAM, use the manageInventoryMonitorRule API. For details, see the Javadoc.

Publishing availability for procured inventory

When a node's inventory falls below a specified level, RTAM can compute the availability of inventory from associated procurement nodes and publish this information as procured inventory. Additionally, if a procurement node's availability crosses a threshold, alerts are raised for the related ship nodes.

When you run RTAM in Full Sync Mode and a node's availability is calculated to be below the specified threshold for considering procurements, procurement sourcing rules, based on fulfillment types, are read for the node. RTAM monitors all nodes applicable for procurement across all the sourcing rules for the item. If node level monitoring is enabled for the ship nodes that require procurements, node level alerts are also created for the procurement nodes.

Procured quantities do not affect future available thresholds or alert levels.

To configure RTAM to publish procured quantities, specify a threshold at which RTAM starts considering procurements. Possible threshold values are 1, 2, and 3. For example, if you set the procurement level threshold at 2 and the level 2 alert at 10 items, RTAM starts considering procurements when the node's available quantity falls below 10 items.

To configure RTAM to consider procurements, use the mangeInventoryMonitorRule API. For details, see the Javadoc.

Example 1: Publishing availability for procured inventory

Example 1 shows the available and procured quantities that RTAM publishes when RTAM is configured to consider procurements.

Assume the following conditions:
  • RTAM runs in Full Sync mode on 2015-11-1.
  • Node 1 (SN1) can procure inventory from PN1 and PN2.
  • Onhand inventory for SN1, PN1, and PN2 is at 10, 40, and 20 items, respectively.
  • Thresholds are set at 0 items for low, one item for medium, and five items for high.
  • RTAM is configured to start considering procurements after inventory falls below the high threshold.

Table 1 shows information that RTAM publishes when inventory is adjusted to four items at SN1. The example shows that SN1 has an onhand quantity of four and that 60 items can be procured in 7 hours.

Table 1. RTAM publishes availability for SN1
Alert Level Alert Quantity Onhand Available Quantity Future Available Quantity First Future Available Date Procured Quantity Procurement Lead Time
1 5 4 0 2500-01-01 60 7 hours

Publishing inventory changes in real time

In Activity-based mode, RTAM publishes inventory changes for an item in real time. Specify one of the following modes for raising the REALTIME_AVAILABILITY_CHANGE_LIST event:
  • All inventory changes. To select this mode, set RaiseEventsOnAvailabilityChanges to "Y".
  • All inventory changes below a specified inventory threshold and inventory changes between thresholds. To specify a threshold, set AlwaysRaiseBeyondLevel to 1, 2, or 3, where these values correspond to the high, medium, and low boundaries configured in the ATP monitor rule. For example, if you want to publish Onhand quantities as "only 5 left", "only 4 left", etc., for all supply-and-demand changes after inventory falls to the "Limited" level, set AlwaysRaiseBeyondLevel to "3".
  • Inventory changes between thresholds.
    Note: Changing one of the thresholds of an inventory item does not cause the agent to monitor the item unless a change in activity occurs. For example, if item I with available quantity 700 is being monitored with a low threshold of 600, and the low threshold is then changed to 1000, no event is published unless there is change in I's activity. To ensure that in such a scenario I is not left unmonitored, call the createInventoryActivity API when the monitoring rule is changed for an item.

To configure a mode for raising the REALTIME_AVAILABILITY_CHANGE_LIST event, use the mangeInventoryMonitorRule API. For details, see the Javadoc.

Calculate velocity and determine when an activity is processed

If enabled, RTAM determines when an activity (YFS_INVENTORY_ACTIVITY) must be processed. Based on the calculated velocity of the item, the date and time of when the threshold changes can be determined. When RTAM time-triggered transaction runs, it processes only those activities that expire in the next <X> minutes based on the configuration. By default, this time interval is set to 0.

After the monitorItemAvailability API call completes, and if net availability changes, an activity record is read from the YFS_INVENTORY_ACTIVITY table. For example, when a scheduled order is released, demand is decremented for SCHEDULED and incremented for ALLOCATED. The result is a net 0 change to the node. In this case, there is no need to create an activity record for which RTAM results in the same availability picture. In the case of shipment confirmation, demand (ALLOCATED) and supply (ONHAND) are both reduced but treated as a net change of 0.

If net demand is not 0, during activity record creation a new column, NEXT_PROCESSING_TS, is populated. The next processing time is based on the alert level and the current on hand quantity. And if the value of RaiseEventsOnAvailabilityChanges flag is set to Y, all activities are processed and sorted by NEXT_PROCESSING_TS. If AlwaysRaiseBeyondLevel is configured for a velocity item, RTAM processes below threshold activities sooner than above threshold activities.

Note: If an activity with the same item-node combination exists in the YFS_INVENTORY_ACTIVITY table, an activity is not created even if the net change is not 0.

Monitor nodes and Distribution Groups

You can configure RTAM to monitor and publish availability for a distribution group, which is a group of nodes, distribution groups, or individual nodes.

When the total availability across nodes is monitored, RTAM monitors all nodes in the default distribution group of the inventory organization.

When monitoring the availability at individual nodes, RTAM monitors all nodes in a specified distribution group.

OPEN_ORDERs and Distribution Group Priority Levels

Demand of type OPEN_ORDER is used in getting the inventory availability picture. If sourcing is maintained, RTAM can either monitor the total availability across nodes or the availability at individual nodes. Inventory items without an Availability Monitor rule, or with a rule that is disabled, is unable to be processed by RTAM.


Distribution group priority levels define the sequence in which demand for OPEN_ORDERs is placed against distribution groups. When you configure distribution group priority levels, demand for OPEN_ORDERs is placed against the distribution group with the highest priority until the distribution group's available stock runs out. Demand is then placed against the distribution group with the next highest priority level. Only distribution groups with a priority are considered for OPEN_ORDER demands.

For example, you might assign warehouses to distribution group 1 and stores to distribution group 2, and then give distribution group 1 a higher priority than distribution group 2. In this example, open orders are sourced by the warehouses in distribution group 1 until stock runs out in the warehouses and then the orders are sourced by the stores in distribution group 2.

To configure priority levels for distribution groups, create a Priority attribute for the DIST_GRP_LVL_MONITOR common code.

OPEN_ORDERS, Model Items, and Distribution Group Priority Level

When OPEN_ORDERs demand containing a model item is distributed to prioritized distribution groups, RTAM bases its calculations on the total quantity across the child models.

For example, Table 2 shows the model item "Cup" and the child items, "Red Cup", "Blue Cup", and "Green Cup" for distribution group 1 and distribution group 2.
Table 2. Quantities for model item "Cup" and child items
Distribution Group Red Cup Blue Cup Green Cup Cup
DG1 2 2 3 (2+2+3) = 7
DG2 5 5 2 (5+5+2) = 12

In this example, for an OPEN_ORDER of three red cups, one blue cup, and five green cups, RTAM first sums the total (3+1+5=9) and then performs the distribution between DG1 and DG2. In this case, since DG1 has higher priority, its OnHand and Future Quantities are consumed first before DG2 is considered.

Table 3 shows the resulting OnHand Quantities for DG1 and DG2:
Table 3. RTAM calculates quantities for the open order
Distribution Group Priority Level Distribution Group OnHand Quantity
1 DG1 (7-7) = 0
2 DG2 (12 -2) = 10
If RTAM considered child items when availability is calculated for open orders, the inventory picture is different.