Implementation Guide for Oracle Billing Insight > Payment Processing > About Recurring Payment Processing >

Example of Scheduling the Amount Due Before the Due Date

This topic shows an example of how a recurring payment processes for amount due before the due date. You might use this feature differently, depending on your business model.

Example of How to Schedule the Amount Due Before the Due Date

The following steps describe an example of how to schedule the amount due before the due date:

1. On date 04/09/2012, a customer with account number acct1111 creates a recurring payment. The amount is amount due, the pay date is one day before due date, the start date is 04/10/2012, and the end date is 06/10/2012.

   Column Name in the recurring_payments Table	Value
   payer_account_number	acct1111
   bill_scheduled	Y
   status	active
   last_process_time	04/10/2012. The value is the same as the start date.
   last_pay_date	01/01/1970. It has not been paid yet.
   next_pay_date	01/01/3000. This future date ensures there is no due date available yet.
   bill_id	Null
   max_num_payments	2147483647. This large number means the recurring payment will only be deactivated when the pay date is after the end date.

2. The pmtRecurringPayment job runs on 04/10/2012 23:59:00PM. The job searches the recurring_payments table to find all recurring payments whose bill_scheduled is Y and status is Active. It finds the example recurring payment and then asks Command Center to return all bills whose account number is acct1111 and whose UPDATE_DATE is between 04/10/2012 (last_process_time) and 04/10/2012 23:59:00PM (job run time). Two bills, bill2 and bill3, are returned. pmtRecurringPayment then finds the bill with latest due date bill3. bill2 is ignored because only the latest bill is paid.
3. After finding the latest bill from Command Center, pmtRecurringPayment checks whether the BILL_CYCLE_END_DATE of this bill is after the BILL_CYCLE_END_DATE of the bill used in the last payment (last bill information can be retrieved from payment_bill_summaries using the bill_id). If not, then this is an old bill and must not be paid. In this case, because there is no last payment, bill3 is paid.
4. Oracle Billing Insight inserts bill3 into the payment_bill_summaries table and the recurring_payment table is recalculated as shown in the following table.

   Column Name	Value
   payer_account_number	acct1111
   bill_scheduled	N, means this bill has not been paid or scheduled
   status	active, because next_pay_date is within the effective period
   last_process_time	04/10/2012 23:59:00PM, changes to job run time
   last_pay_date	01/01/1970, unchanged
   next_pay_date	05/14/2012, one day before the due date, 05/15/2012
   bill_id	bill3

5. If the pmtRecurringPayment job runs between 04/11/2012 and 05/10/2012, then nothing happens to this recurring payment because synchronization and scheduling do not happen. The table remains unchanged.
6. On 05/11/2012 11:59:00PM, three days before next_pay_date, pmtRecurringPayment runs again. The recurring payment mentioned previously will not be synchronized, because its bill_scheduled is N. However, it will be scheduled. pmtRecurringPayment finds all recurring payments whose bill_scheduled is N, status is Active and next_pay_date is equal to or before 05/14/2012 (05/11/2012 + 3 days). The previously mentioned recurring payment is picked up and a payment is inserted into the EDX_PMT_TRANSACTION table. The amount of the payment is $100.00, and the pay date is 05/14/2012. After this, the recurring payment table is changed to:

   Column Name	Value
   payer_account_number	acct1111
   bill_scheduled	Y, means this bill has been paid
   status	Active because next_pay_date is within the effective period
   last_process_time	04/10/2012 23:59:00PM, unchanged because there was no synchronization
   last_pay_date	05/14/2012, change to check's pay date
   next_pay_date	05/14/2012, unchanged
   bill_id	bill3
   payment_id	Points to the new payment_id inserted into the EDX_PMT_TRANSACTION table.

   The customer can now view the payment from Future Payments in the example interface. He or she can update or cancel the scheduled payment if desired.

7. On 05/12/2012 23:59:00PM, pmtRecurringPayment runs again and finds bills whose UPDATE_DATE is between 04/10/2012 11:59:00PM and 05/12/2012 23:59:00PM. No bills exist, and the Last Process Time is updated to 05/12/2012 23:59:00PM. Everything else remains the same.
8. On 05/13/2012, the ETL runs again and inserts a new bill, bill4. The bill detail information is obtained from the EDX_ACCOUNT_LATEST_STATEMENT table from OLTP..

   ACCOUNT_ NUMBER	STATEMENT_NUMBER	UPDATE_DATE	TOTAL_ AMOUNT_DUE	STATEMENT_ DUE_DATE
   acct1111	bill1	03/10/2012	100.01	04/15/2012
   acct1111	bill2	04/10/2012	50.00	04/25/2012
   acct1111	bill3	04/10/2012	100.00	05/15/2012
   acct1111	bill4	05/13/2012	80.00	06/15/2012

9. On 05/13/2012 23:59:00PM, the pmtRecurringPayment job runs again. It contacts Command Center and retrieves bills whose UPDATE_DATE are between 05/12/2012 23:59:00PM and 05/13/2012 23:59:00PM. bill4 is retrieved and the recurring_payments table is updated as shown in the following table.

   Column Name	Value
   payer_account_number	acct1111
   bill_scheduled	N means this bill has not been paid
   status	Inactive because next_pay_date is beyond the effective period
   last_process_time	05/15/2012 23:59:00PM, changes to job run time
   last_pay_date	05/14/2012, unchanged
   next_pay_date	06/14/2012, one day before due date, 06/15/2012
   bill_id	bill4

   After synchronization, the recurring payment is deactivated, and is never synchronized or scheduled again.