Monday May 09, 2011

Enforcing Redundancy

A number of our local installations do not appear to be running batch process REDSAAMT, resulting in life becoming just that little bit harder for the associated CC&B instance. This batch process is tasked with marking financial transactions as redundant (based on the fact that corresponding debits and credits have a resulting $0.00 impact on the overall Service Agreement balance and the transaction arrears date on the transactions is older than x days, as specified on the Installation Options). Open Item accounting transactions are not reviewed by this process. When this job is not run, CC&B has to wade through a larger set of transactions to determine current balances, and as a result performance suffers.
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:

Bill Completion Logic


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.
About

Stuart Ramage

I am a Consulting Technical Manager for Oracle Corporation, and a member of the OU Black Belt Team, based in Hobart Tasmania.
I have worked in the Utility arena since 1999 on the Oracle UGBU product line, in a variety of roles including Conversion, Technical and Functional Architect.

Contact me on:

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today