Real-time availability monitor

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.

Note: When the Promising server is being used, this transaction is not called on the Order server.

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.

Calculating velocity and determining when an activity must be processed

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.

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

Computing and publishing the maximum ship dates for available quantities

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:

Table 1. Example: availability matrix of maximum ship dates for available quantities
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.

Table 2. Example: availability matrix for nodes with non-working 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.

Table 3. Example: availability matrix when offsetting the maximum ship date
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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 4. Real-time availability monitor attributes
Attribute Value
Base Transaction ID REALTIME_ATP_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called FindInventory

Criteria parameters

The following are the criteria parameters for this monitor:

Table 5. Real-time availability monitor criteria parameters
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:
<AgentCriteriaAttribute> <OverriddenValue>

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
Changes

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.
Note: Distribution Rule Id is used for internal purposes and should be left blank.

Statistics tracked

NumInvActivitiesProcessed

Pending job count

None.

Events raised

The following events are raised by this time-triggered transaction:

Table 6. Events raised by the realtime availability monitor transaction
Transaction/Event Key Data Data Published* Template Support?

REALTIME_
AVAILABILITY_
CHANGE

None

YFS_REALTIME_ATP_MONITOR.
REALTIME_AVAILABILITY
_CHANGE.html

Yes
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

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.