Purging in EDI
Purging data is a key part of system maintenance. Purging keeps the system healthy and responsive by removing data that is no longer needed for day-to-day operations. Over time, accumulation slows down queries, list views, and even the purge operations themselves. The more records in the table, the longer everything takes. Systems run better, cost less, and carry less risk when you regularly clean out data you no longer need.
To determine how long you should keep records and how often to schedule a purge action, you must check with your compliance or legal team to understand any rules for EDI data retention. You also need to consider your daily or monthly data volume. If your organization generates a lot of records, you may need to purge more frequently to keep the system efficient and manageable.
Purge actions are available for Translation Logs, EDI Work, EDI Data Exchange, and EDI Transaction History.
The general priority order for data retention periods is, from shortest to longest: EDI Work, Translation Logs, EDI Data Exchange, and finally EDI Transaction History.
The default queue for the EDI purge actions in Async Administrator is named Default EDI Purge Queue.
Purge parameter
Older Than Days is a required parameter in all purge functions. A display only Older Than Date field shows the calculated cut off date. Records with a date older than the entered number of days are deleted. Records newer than the number are kept.
Additional business class specific parameters for record selection may be available in a Purge action.
Purging EDI Transaction History
Purging EDI Work
When your workflow confirms that translation errors are addressed, you may use a short retention period. Ensure that no regulatory or operational reasons justify retaining processed records. You can purge EDI Work data after a few days or weeks.
Aside from the number of days from the current date, users can specify reference ID, status, or direction
.Purging EDI Data Exchange
Review your historical trends regarding retransmission, troubleshooting, and partner requests. Keep in mind that EDI Transaction History and Archive store all processed raw data. If the need to access raw data rarely exceeds a particular period, set a retention policy. The retention policy must balance operational efficiency and storage management. Use your archival systems for long-term data access, and purge EDI Exchange data accordingly to optimize your environment.
Aside from the number of days from the current date, users can specify status, direction, or both to purge records.
Purging Translation Logs
Review your typical response times and the practical uses of translation logs. If logs are rarely accessed beyond a few weeks, a shorter retention period may reduce storage requirements without affecting support effectiveness. Otherwise, retaining the 180-day default can provide additional assurance for handling less frequent or delayed investigations.
Post Upgrade Automatic Purging Translation Logs
Translation logs older than 180 days are automatically purged as part of release post-upgrade actions. You can change the older than days number or disable the automatic purge behavior through Configuration Parameters.