Implementation Guide for Oracle Self-Service E-Billing > Payment Processing > About Recurring Payment Processing >

Example of Scheduling the Amount Due on a Fixed Pay Date

This topic shows an example of how a recurring payment processes for the amount sue scheduled on a fixed pay date. You could use this feature differently, depending on your business model.

Example of How to Schedule the Amount Due with a Fixed Pay Date

The following steps describe an example of how to schedule the amount due with a fixed pay date:

1. On 04/09/2012, a customer with account number acct1111 creates a recurring payment. The amount is amount due, the pay date is day 31 of each month, the start date is 04/10/2012,and the recurring payment stops after 10 payments.

   Column Name	Value
   payer_account_number	acct1111
   bill_scheduled	Y
   status	active
   last_process_time	04/10/2012
   last_pay_date	01/01/1970
   next_pay_date	4/30/2012. This is the first available pay date after 04/10/2012 (because there is no April 31).
   bill_id	Null
   end_date	01/01/3000. The end date is so far in the future that the recurring payment will only be deactivated when the number of payments reaches maximum allowed.
   curr_num_payments	0. No payments have been made yet.

   The Bill table has the following values:

   Z_PRIMARY-ACCOUNT_NUM	Z_DOC_ID-STATEMENT_NUMBER	Z_DOC_DATE-STATEMENT_LOAD_DATE	AmountDue	DueDate
   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

   Even though the pay date is not related to the due date, DueDate must still be indexed because it is used to decide which bill is the latest.

2. The pmtRecurringPayment job runs on 04/10/2012 23:59:00PM. bill3 is found in the index table and inserted into the payment_bill_summaries table. The recurring_payments table is recalculated as shown in the following table.

   Column Name	Value
   payer_account_number	acct1111
   bill_scheduled	N, this bill has not been paid.
   status	Active, curr_num_payments is less than max_num_payments.
   last_process_time	01/01/1970. This is unchanged.
   last_pay_date	01/01/1970. This is unchanged.
   next_pay_date	04/30/2012. There is no April 31.
   bill_id	bill3
   curr_num_payments	0

3. On 04/27/2012, three days before next_pay_date, pmtRecurringPayment runs again. There is no synchronization (bill_scheduled is N), but a payment is inserted into the check_payments or creditcard_payments table. The amount of the check is $100.00 and its pay date is 04/30/2012. The recurring payment table is changed as shown in the following table.

   Column Name	Value
   payer_account_number	acct1111
   bill_scheduled	Y, means this bill has been paid.
   status	Active, curr_num_payments is less than max_num_payments.
   last_process_time	04/10/2012 23:59:00PM: not changed because there has been no synchronization.
   last_pay_date	04/30/2012. This was changed to next_pay_date.
   next_pay_date	05/31/2012. This was changed to next available pay date.
   bill_id	bill3
   payment_id	Points to the new payment_id inserted into the check_payments or creditcard_payments table.
   curr_num_payments	1

4. Repeat steps 2, 3 and 4 until curr_num_payments reaches 10. At step 4 of the tenth payment, the status changes to Inactive.

If no bills arrive for a month, then next_pay_date is automatically moved to next month. For example, if there is no bill for April, then the next_pay_date is automatically moved from 04/30/2012 to 05/31/2012 when the current job run time is May 1.