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.
- 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 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
) withFirstFutureAvailableDate
set to the date on which the first future supply is available and theFutureAvailableDate
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
- 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 = availability
- Capacity
- 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.
- 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.
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
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.
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.
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.
Distribution Group Priority Level | Distribution Group | OnHand Quantity |
---|---|---|
1 | DG1 | (7-7) = 0 |
2 | DG2 | (12 -2) = 10 |