The Real-time Availability Monitor time-triggered transaction monitors the inventory availability of inventory items. It can be configured to raise the REALTIME_AVAILABILITY_CHANGE event when the inventory level for a given item changes between the thresholds defined in the Applications Manager in the Global Inventory Visibility module.
It can be run in three modes:
If a bundle item is configured to have its components ship independently, the Real-time Availability Monitor 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. For more information about future inventory availability, see the Configuring Sterling Global Inventory Visibility.
Demand of type OPEN_ORDER is used in getting the inventory availability picture. If sourcing is maintained, the Real-time Availability Monitor 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, are unable to be processed by this time-triggered transaction.
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 will proceed. Setting these default inventory monitor rules also ensures that inventory activity will be recorded when the system is running in activity-based mode.
When monitoring the total availability across nodes, the Real-time Availability Monitor monitors all nodes in the default distribution group of the inventory organization.
When monitoring the availability at individual nodes, the Real-time Availability Monitor monitors all nodes in a specified distribution group. For more information about configuring distribution groups and node-level inventory monitoring, see the Configuring Sterling Global Inventory Visibility.
If configured, the Real-time Availability Monitor also considers the onhand and future inventory availability safety factor during monitoring. For more information about the inventory availability safety factors and the findInventory() API, see the Configuring Sterling Global Inventory Visibility and the Sterling Selling and Fulfillment Foundation: Javadocs.
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, and 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 FutureAvailableDate set to the date on which the maximum future supply is available.
When the Real-time Availability Monitor is run in activity based mode, changing one of the thresholds of an inventory item does not cause the agent to monitor it unless there is a change in activity. 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. In order to ensure that in such a scenario I is not left unmonitored, call the createInventoryActivity API when changing a monitoring rule for an item.
If enabled, the Real-Time Availability Monitor 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 the Real-time Availability Monitor 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 there is a net availability change, an activity record is inserted into the YFS_INVENTORY_ACTIVITY table. For example, when releasing a scheduled order, demand is decremented for SCHEDULED and incremented for ALLOCATED. This results in 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 enabled, the Real-Time Availability Monitor computes and publishes a matrix of maximum ship dates for available quantities, which includes the following information:
The matrix is published to the REALTIME_AVAILABILITY_CHANGE event and stored in XML format in the AVAILABILITY_INFO field of the YFS_INVENTORY_ALERTS table. The monitorItemAvailability() API can be used to update the matrix. For more information about the monitorItemAvailability() API, refer to the Sterling Selling and Fulfillment Foundation: Javadocs.
For information about using the Real-Time Availability Monitor to calculate and publish a matrix of maximum ship dates for available quantities, refer to the chapter on Configuring Inventory Rules in the Configuring Sterling Global Inventory Visibility.
Computing the Maximum Ship Date
The maximum ship date is equal to the maximum expected ship date across all the nodes being considered. For information about calculating the expected ship date, refer to the Product overview. Additionally, the following options can be configured as part of the maximum ship date:
Maximum Ship Date Time - If you specify a time for the maximum ship date, the Real-Time Availability Monitor calculates the maximum ship date, as described earlier, and then applies the following logic:
Number of Days To Offset the Maximum Ship Date - You can specify a number of days to offset the maximum ship date. The Real-Time Availability Monitor calculates the maximum ship date, including the maximum ship date time, and then increments the maximum ship date by the number of days specified by the offset number. For example, if the Real-Time Availability Monitor has calculated a maximum ship date to be 11 a.m. on July 19 and Number of Days to Offset the Maximum Ship Date is set to 1, the maximum ship date is recalculated to be 11 a.m. on July 20.
Calculating the Effective Until Date
The Real-Time Availability Monitor calculates the effective until date by subtracting the node's minimum notification time from the maximum ship date and then adjusting for the preceding notification time on the node's notification schedule. The effective until date is only valid while supplies are available at the node.
For example, if an available quantity has a maximum ship date of 4 p.m. on July 19 and the shipping node has the following notification schedule, the effective until date is calculated to be 3 p.m. on July 18:
In this example, the effective until date is calculated by first subtracting the 24-hour minimum notification time from the 4 p.m., July 19 maximum ship date and then adjusting for the 3 p.m. notification time. If an order is not placed before 3 p.m. on July 18, the July 19 maximum ship date is no longer available because the node must be notified at least 24 hours before shipping the items, by 4 p.m. on July 19. Also, if a different order reduces available quantities at the node before the order is placed at 3 p.m. on July 19, the maximum ship date cannot be met and the effective until date becomes invalid.
Additionally, offset days are not considered when calculating the effective until date. Thus, if the maximum ship date in the earlier example is updated to 4 p.m. July 20 by setting Number of Days to Offset Maximum Ship Date to 1, the effective until date is updated to 3 p.m., July 19.
Example 1: Computing Maximum Ship Dates for Available Quantities
Node 1 has the following supply picture:
Node 2 has the following supply picture:
The following table shows the availability matrix for Node 1 and Node 2, where the following conditions are true:
ETA | Quantity | Maximum Ship Date | Effective Until Date |
---|---|---|---|
Node 1 | |||
7/19/2010 | 80 | 4 p.m., July 20 | 3 p.m., July 19 |
7/22/2010 | 10 | 4 p.m. July 22 | 3 p.m., July 21 |
Node 2 | |||
7/19/2010 | 100 | 4 p.m., July 21 | 2 p.m., July 19 |
7/22/2010 | 20 | 4 p.m., July 22 | 2 p.m., July 20 |
In this example, July 19 is the ETA for a quantity of 80 items at Node 1 and 100 items at Node 2. The matrix shows a 4 p.m., July 20 maximum ship date for the 80 available items from Node 1 and a 4 p.m., July 21 maximum ship date for the 100 available items from Node 2. For Node 1, the maximum ship date is calculated by adding the 24-hour minimum notification time to the 3 p.m. notification time on July 19, and then adjusting for the 4 p.m. maximum ship date time. The effective until date is calculated by subtracting the 24-hour minimum notification time from the maximum ship date and then adjusting for the 3 p.m. notification time. For Node 2, the maximum ship date and effective until date are calculated similarly, with the exception that Node 2 has a 48-hour minimum notification time and a 2 p.m. notification time.
Additionally, the example shows July 22 as the ETA for a quantity of 10 items at Node 1 and 20 items at Node 2. The maximum ship date is 4 p.m., July 22 for the 10 items at Node 1 and 4 p.m., July 22 for the 20 items at Node 2. If the difference between the current date and the ETA is greater than the node's minimum notification time, the ETA date is used for the maximum ship date. In this example, the difference between the current date, July 19, and the ETA date, July 22, is greater than the minimum notification times at both nodes. Thus, the maximum ship date is set to the maximum ship date time on the ETA date at the nodes, which is 4 p.m., July 22 at Node 1 and 4 p.m., July 22 at Node 2.
Example 2: Computing the Maximum Ship Date at Nodes With Non-Working Days
The following table displays the availability matrix for Node 1 and Node 2 when the supply picture and conditions from Example 1 are applied. However, in this scenario, July 19 and July 20 are nonworking days.
ETA | Quantity | Maximum Ship Date | Effective Until Date |
---|---|---|---|
Node 1 | |||
7/19/2010 | 80 | 4 p.m., July 22 | 3 p.m., July 21 |
Node 2 | |||
7/19/2010 | 100 | 4 p.m., July 23 | 2 p.m., July 21 |
In the example, Node 1 has an available quantity of 80 on July 19 and a minimum notification time of 24 hours. Because July 19 and July 20 are nonworking days at Node 1, the 80 items are not considered available until July 21. In this case, the maximum ship date is calculated by adding the 24-hour minimum notification time to July 21 and adjusted for the 4 p.m. maximum ship date time. For Node 2, the maximum ship date is calculated similarly, with the exception of a 48-hour minimum notification time.
Example 3: Offsetting the Maximum Ship Date
The following table displays the availability matrix for Node 1 and Node 2 when the supply picture and conditions from Example 2 are applied. However, in this scenario, Number of Days To Offset the Maximum Ship Date is set to 1.
ETA | Quantity | Maximum Ship Date | Effective Until Date |
---|---|---|---|
Node 1 | |||
7/19/2010 | 80 | 4 p.m., July 23 | 3 p.m., July 22 |
Node 2 | |||
7/19/2010 | 100 | 4 p.m., July 24 | 2 p.m., July 22 |
In the example, the maximum ship dates for Nodes 1 and 2 are calculated similarly to Example 2. However, the maximum ship dates are incremented by 1 because Number of Days to Offset the Maximum Ship Date is set to 1. In this example, the effective until date is set to 3 p.m., July 22 for Node 1 and 2 p.m., July 22 for Node 2 because the offset days are not considered when calculating the effective until date.
The following are the attributes for this time-triggered transaction:
Attribute | Value |
---|---|
Base Transaction ID | REALTIME_ATP_MONITOR |
Base Document Type | General |
Base Process Type | General |
Abstract Transaction | No |
APIs Called | FindInventory |
The following are the criteria parameters for this monitor:
Parameter | Description |
---|---|
Action | Required. Triggers the transaction. If left blank, it defaults to Get, the only valid value. |
Number of Records To Buffer | Optional. Number of records to retrieve and process at one time. If left blank or specified as 0 (zero), it defaults to 5000. |
InventoryOrganizationCode | Inventory organization code to use when MonitorOption is
passed as 3. The inventory organization has to be
an enterprise. If this is not passed, the monitor runs for all inventory organizations. |
MonitorOption | 1 - Activity Based (Monitor based on distinct
inventory items in YFS_INVENTORY_ACTIVITY table). 2 – Quick Sync (Re-raise event to publish information from the YFS_INVENTORY_ALERTS table). 3 – Full Sync (Monitor based on all inventory items maintained by the inventory organization provided. If no InventoryOrganizationCode is provided, all inventory item is monitored). If not provided, default value is 1. |
ItemStatuses | List of valid statuses of items to be processed. Statuses must be separated by a , for example 3000,2000. This is only used when MonitorOption is passed as 2 or 3. If provided, only items with the matching statuses is monitored. |
FromAlertTimestamp | This is only used when MonitorOption is passed
as 2. If provided, the agent raises the REALTIME_AVAILABILITY_CHANGE
event to republish inventory availability information which was published
between the time that the agent started and FromAlertTimestamp. If not provided, all inventory availability information published before the time that the agent started is republished. |
AllowedOverriddenCriteria | If set to Y, the overridden value for the agent criteria parameters
can be provided at the command line while triggering the agent in
the following format:
For more information about passing these attributes, see the Installing topic. |
FromLastNumberOfHours | This is only used when MonitorOption is passed as 2 to calculate
the FromAlertTimestamp parameter, if necessary. If the FromAlertTimestamp parameter is not provided, it is calculated as current timestamp minus FromLastNumberOfHours. |
CollectPendingJobs | If this parameter is set to N, the agent does not collect information on the pending jobs for this monitor. This pending job information is used for monitoring the monitor in the System Management Console. |
RaiseEventsOnAllAvailability |
When set to Y, REALTIME_AVAILABILITY_CHANGE event is raised on all availability changes regardless of whether availability exceeds or falls below specified thresholds. This is only used when MonitorOption is passed as 1. Valid values: Y or N. Default value: N. |
ColonyID | Required in a multi schema deployment where a table may exist in multiple schemas. Runs the agent for the colony. |
NumInvActivitiesProcessed
None.
The following events are raised by this time-triggered transaction:
Transaction/Event | Key Data | Data Published* | Template Support? |
---|---|---|---|
REALTIME_ |
None |
YFS_REALTIME_ATP_MONITOR. |
Yes |
* These files are located in the
following directory:
|
Although described as 'real time', availability changes may not be triggered immediately as inventory changes occur if the agent has a backlog of messages to process. Furthermore, this monitor exists as a time-triggered transaction, and thus monitors availability of inventory items only when the monitor is triggered based on the configured runtime properties.