Enhanced return monitor
The enhanced return monitor allows you to monitor the following situations:
- Milestone x has not been reached y hours before a given date type.
- Milestone x has not been reached within y hours of a given date type.
- Milestone x has not been reached within y hours of milestone z.
- Milestone x has been reached y hours before a given date type.
- Milestone x has been reached within y hours of a given date type.
- Milestone x has been reached within y hours after milestone z.
- The order has been in status x for y hours.
- Date type x is y hours before date type z.
- Date type x is y hours after date type z.
The enhanced return monitor can be configured to monitor the following system date types:
- Actual Order Date - Read from the ORDER_DATE column of the YFS_ORDER_HEADER table
- Requested Ship Date - If there is an order release, read from the REQ_SHIP_DATE column of the YFS_ORDER_RELEASE table. Otherwise, read from the REQ_SHIP_DATE of the YFS_ORDER_LINE table.
- Expected Ship Date - Read from the EXPECTED_SHIPMENT_DATE column of the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as Requested Ship Date.
- Actual Ship Date - If the date is before 01/01/2500, read from he EXPECTED_SHIPMENT_DATE column of the YFS_ORDER_LINE_SCHEDULE table. If the date is on or after 01/01/2500, this date type is returned as null.
- Requested Delivery Date - If there is a release, read from the REQ_DELIVERY_DATE column of the YFS_ORDER_RELEASE table. Otherwise, read from the REQ_DELIVERY_DATE of the YFS_ORDER_LINE table.
- Expected Delivery Date - Read from the EXPECTED_DELIVERY_DATE column of the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as Requested Delivery Date.
- Actual Delivery Date - If the date is before 01/01/2500, read from he EXPECTED_DELIVERY_DATE column of the YFS_ORDER_LINE_SCHEDULE table. If the date is on or after 01/01/2500, this date type is returned as null.
For Order Fulfillment, Planned Order Execution, Reverse Logistics, and Purchase Order Execution pipelines, the system defined dates such as Shipment and Delivery are stored without a time component. Therefore when you configure a rule using these dates, all time computations are carried out assuming they are always 12:00:00 AM.
For more information about milestones, date types, and monitoring rules, refer to the see the Configuring Sterling Supply Collaboration topic, the Configuring Distributed Order Management topic, and the Configuring Sterling Reverse Logistics topic.
If you run the Enhanced Return Monitor, you must configure and run the Close Order time-triggered transaction in all applicable pipelines. For more information about the Close Order time-triggered transaction, see Close order.
The same relog interval is used for all document types.
Attributes
The following are the attributes for this time-triggered transaction:
| Attribute | Value |
|---|---|
| Base Transaction ID | ORDER_MONITOR_EX.0003 |
| Base Document Type | Return Order |
| Base Process Type | Reverse Logistics |
| Abstract Transaction | No |
| APIs Called | None |
Criteria parameters
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. |
| Collect Pending Jobs | 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. |
| 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. |
| Enterprise Code | Optional. Enterprise for which the Order Monitor needs to be run. If not passed, then all enterprises are monitored. |
| Lead Time | Optional. Value to be specified in minutes. Used by monitor agents to retrieve the jobs for processing. The agents verify the lead time against NextAlertTs in monitor entities to derive the jobs. |
| Colony Id | Required in a sharded deployment where a table may exist in multiple schemas. Runs the agent for the colony. |
Statistics tracked
The following statistics are tracked for this monitor:
| Statistic Name | Description |
|---|---|
| NumOrdersProcessed | Number of orders processed. |
| NumAlertsRaised | Number of alerts raised. |
Pending job count
For this transaction the pending job count is the number of open orders with the value of NEXT_ALERT_TS less than or equal to (<=) the current date.
Events raised
No events are raised. Individual actions associated with the monitoring rule are run.
The data published is RETURN_MONITOR_EX.xml.
Monitor rule's condition template
If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is used to obtain both the order details and the evaluating monitor rule details. See the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.
If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the MonitorConsolidation->Order element of the default monitor template, the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_MONITOR_EX.xml file, is used.
If the default monitor template is used, the MonitorConsolidation-> Order-> OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not passed into the condition.