Understanding the Aging Application Engine Process
The Aging process is part of the Aging Preprocessor multiprocess job (ARAGE).
The Aging Preprocessor multiprocess job (ARAGE) includes:
The Aging Parallel Preprocessor Application Engine process (AR_AGEPP).
The Aging Parallel multiprocess job (AR_AGE).
The Aging Parallel multiprocess job calls AR_AGE1 through AR_AGE#, which run the Aging process (AR_AGING).
See Setting Up Parallel Processing for Aging.
The Aging process updates summary aging information that appears on various inquiry pages. Management and collection departments rely on aging to identify delinquent accounts and to assess possible cash flow issues.
The Aging process also updates the Due and High Due history IDs.
This section discusses:
The commit cycle.
In use customers.
When you run the Aging process, aging occurs in two phases:
The system builds images of all the records as they appear after you run the Aging process and commits after every step.
The system updates the database with the new records.
Phase two is wrapped into one commit; therefore, database integrity remains intact, regardless of how you proceed after a problem.
When you run the Aging process, it marks the customers as In Use by updating the process instance in the Customer Data (CUST_DATA) table with the process instance of the current job.
Note: If In Use customers are encountered (that is, if the process instance is less than or greater than zero) during the Aging process, then the aging run is not terminated. The In Use customers are simply not aged, while the rest of the customers in the requested business units are aged normally. After you determine the reason that the customer is an In Use customer and correct the problem, run the aging request again.