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:
- 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.
|
|
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_DOC_ID-STATEMENT_NUMBER |
Z_DOC_DATE-STATEMENT_LOAD_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 |
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.
- 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.
|
|
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 |
- 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.
|
|
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 |
- 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.
|