Order purge

Order purge reduces the load on frequently accessed tables. It works on a task queue. It picks up the orders from YFS_TASK_Q table that are available for the transaction PURGE.

If the purge criteria are not met, the AVAILABLE_DATE is calculated based on the modify time stamp of the order in the YFS_ORDER_HEADER and the YFS_TASK_Q tables, whichever is the maximum, and retention days are added to the new AVAILABLE_DATE.

This transaction depends on all lines of an order that is in a status pickable by the Purge transaction.

The following statuses are available for configuration to be picked up by Order Purge:

• Draft Created (1000) and all extended Draft Created Statuses.
• Created (1100) and all extended Created statuses. These statuses are available only for document types Sales Order, Purchase Order, and Transfer Order.
• Released (3200) and all extended Released statuses.
• Shipped (3700) and all extended Shipped statuses.
• Completed (3700) and all extended Completed statuses. These statuses are available only for the document type Master Order.
• Received (3900) and all extended Received statuses.
• Cancelled (9000) and all extended Cancelled statuses.
• Shorted (9020) and all extended Shorted statuses.

You can use purge codes pseudo-logic to analyze purges. If the following conditions are met, an order is picked up for purge:

• All open child orders (derived, chained, return, exchange, procurement, or refund fulfillment) for the order must already be purged.
• No pending transfer-out charges to another order that exceeds the transfer-ins.
• No pending adjustment invoices.

An order is purged immediately if it meets the above three criteria and is cancelled with payment collection complete.

For the purge agent to pick up a cancelled order, the payment status of the order must be one of the following values:

• Paid
• Not Applicable

If an order does not meet any of the purge criteria, continue checking for the following criteria:

• No order release status record that does not meet the retention days.
• It is in the correct status for purge. For example,
  • All service requests for the order must be in Shipped or extended Shipped status.
  • The payment status for the order must be Paid or Not Applicable.
  • It must not have any unpurged negotiations.
• For all order lines other than service request lines:
  • If the Seller inventory update is required, the Status Inventory Type has the “Update Seller Supply” option that is turned on, and the Seller Supply Type is “Onhand”, or blank. (The Seller Supply Type can also be a custom seller supply type with the “Onhand Supply” check box enabled.)
  • If the Seller Demand Type is blank.
  • If the Buyer inventory update is required and the Buyer Supply Type is “Onhand”, or blank.
• The last modification of the order must fall before the lead time (in days) set up.
• Any enterprise that uses the Console must schedule purge transactions.
• The order must not have an undelivered service line.
• In an exchange order for processing a return order, the exchange order must be purged from history before the return order is purged.

With no change to status inventory type, a Shipped (3700) status or its extended status is purged if the Buyer is not passed.

An order in Shipped status or extended Shipped status in the default pipeline is not purged if the Buyer passed on the tracking inventory. Therefore, the purging of the order that is related to the pending supply for the Buyer tracking inventory is prevented.

To purge such orders, the status inventory type for the Shipped or extended Shipped status must be configured such that the Buyer Supply Type is ONHAND for the status inventory type.

If the Inventory Published flag for the organization is set to Y, the Buyer Supply Type should be ONHAND in order to purge the shipped order. If the Inventory Published flag for the organization is set to N, the shipped order will be purged regardless of the Buyer Supply Type specified.

When the purge agent is run, the draft order without lines is purged to the order history table. When the purge history agent is run, the draft orders without lines get deleted permanently.

The Order Purge agent is capable to delete the order audit records instead of writing them to history tables, on purge of an order. If you do not have a continuous use of order audits after orders are purged to history, you can consider this feature, and it helps to make order history data lighter. You need to set the yfs.purge.order.orderaudit.delete property to true to enable this feature. By default, the property is set to false and order audit data is purged and moved to order audit history tables..

The Sterling Order Management System also provides a user exit named YFSBeforeOrderAuditPurgeUE in relation with this feature. The user exit can publish the order audit records being deleted from Sterling Order Management System on purge of an order. You can implement the user exit if you want to store order audit records externally to Sterling Order Management System to refer in the future.