By Sturamage-Oracle on May 09, 2011
It is important to note that this job limits itself to reviewing 5,000 transactions for any one Service Agreement, and when this limit is reached the job simply generates a To Do and rolls all work performed back.. So, the big question is, how do you ‘catch up’ if you have not been running this job regularly, and have now reached the point where these 5,000-transaction-limit To Do entries are being generated?
The answer is the “Batch Business Date” parameter. Almost every batch process in the CC&B product makes use of the batch business date as a controlling factor, and processes records limited to this date (In CC&B 2.2 the exceptions to this rule are some of the Interval Reading Upload and Derivation, and Balance Control batch processes). Using this method, it is possible to run the batch process a number of times passing in differing batch dates each time (i.e. Run the job 3 times passing in dates of 2009/01/01, 2010/01/01 and 2011/01/01 to break the work being performed up into 3 ‘bite-sized’ chunks, thereby circumventing the 5,000 record limit in this particular process). It should be noted that this process simply updates the “redundant” flag on the transactions and does not perform any sort of transaction removal (i.e. Archiving), as a result this process will not assist with database size reduction.
This brings me to another point.. What populates the Arrears Date on a Transaction?
In normal usage, CC&B will generate a Financial Transaction record for every Bill Segment, Payment Segment, Adjustment (or Reversal of each) once the transaction is Frozen (or Cancelled in the case of the Reversal). These financial transaction records link back to the associated ‘detail’ records via the SIBLING_ID field on the table, but the associated BILL_ID and Arrears Date fields are normally left blank at this point.
This process of populating these components is then performed by Bill Completion (assuming the transaction is not a credit adjustment or a payment, since these are traditionally aged from the date that the transaction is frozen, rather than the date that the customer is made aware of the transaction), although it tends to do a bit more than just updating the arrears date.
The process performed at bill completion looks a little like this:
As a result, once a bill has been completed, all of the associated transactions on the SAs linked to the Account are ‘swept’ onto the bill and stamped with an arrears date that aligns with the bill completion date. This also ensures that all transactions linked to the bill inherit the same due date.