Simplify purge process in accordance with purge policy of OMOC

The current purge process is very cumbersome and doesnt allow a client to meet the expectations of the purge policy defined by OMS.

Current process to purge order/shipment/returns data has these dependencies and checks

1. The purge functionality primarily works based on the last modified date (MODIFYTS), not the creation date (CREATETS), of the main entity record (e.g., YFS_ORDER_HEADER or YFS_SHIPMENT).

2. Child documents or related documents must be purged or completed first before the parent document can be purged

3. Order Purge Dependencies
   i. The Order Purge agent has several conditions that must be met before an order can be purged to history:
   ii. Shipments must be closed: The associated shipments for the order lines must be in a 'Closed' status (SHIPMENT_CLOSED_FLAG = 'Y') and eligible for the Shipment Purge agent.
   iii. No active order release statuses: There should be no outstanding YFS_ORDER_RELEASE_STATUS records that do not meet the retention days.
   Payment status must be final: The order's payment status must be "Paid," "Cancelled," or "Not Applicable," with no open charges or unpurged negotiations.
   iv. Exchange order dependency: If the order is an exchange order created as part of a return, it must be purged to history before the corresponding return order can be purged.

4. Shipment Purge Dependencies
   i. The Shipment Purge agent purges shipment records and their child tables (e.g., YFS_SHIPMENT_LINE, YFS_SHIPMENT_CONTAINER).
   ii. Shipments must be closed: The primary criterion is that the shipment must have its SHIPMENT_CLOSED_FLAG set to 'Y'. This is typically handled by the Close Shipment transaction.
   iii. Related orders should be purged (recommended): Although the shipment purge itself doesn't strictly block on the order being purged from live tables, best practice suggests running Order Purge with a slightly shorter retention period (e.g., 89 days) than the Shipment Purge (e.g., 90 days) to ensure the parent order is handled first. The purge logic works best when it can confirm that the related order is no longer in active use.

5. Return Order and Return Shipment Purge Dependencies
   i Return orders are a specific document type within the order family, and they follow similar logic to sales orders, with specific nuances:
   ii Return Shipments must be processed: Return shipments linked to the return order must be in a final, closed state.
   iii Exchange order dependency (as noted above): A return order that generated an exchange order cannot be purged until the associated exchange sales order has been purged to history.
   iv Payment processing flag: The ProcessPaymentOnReturnOrder flag affects the purge criteria. If set to 'N' (payment processing is done on the original sales order), the return order might be eligible for earlier purge as it has no open charges itself.

6. Receipt Purge Dependencies
   i. The Receipt Purge agent handles the archiving of receipt information (YFS_RECEIPT_HEADER, YFS_RECEIPT_LINE, etc.). This process is related to purchase orders and transfer orders where goods are received.
   ii. Receipts must be closed/processed: The receipts must be in a final state, indicating the receiving process is complete.

7. Order History Purge, etc. Last Modified Date (MODIFYTS) of the record in the history table itself.

8. Many orders have payment or other issues which are dealt offline and doesnt get to an endstate

As you can see there are so many dependencies and the criterias and interdependencies in this purge and if any one of this is NOT met then, the AVAILABLE_DATE in the YFS_TASK_Q table is recalculated by adding the retention days to the maximum of the order's modify timestamp and the task queue's AVAILABLE_DATE, ensuring it is picked up for re-evaluation later.

For an order with exchange or returns the purge has to take 4-5 steps(of dependent purges) before the order gets eligible to purge.

Can we simplify this process by just having the option to have one purge criteria for order CREATETS and purges all relevant Shipment, returns, exchange orders associated with it. Exchange order can be treated seperately. Customers will run 2 Purges one for Orders in Live table and one for orders in history table similar to the 2 criterias present. But no additional checks or dependencies be checked and the orders are moved in the state they are in.