Implementation Guide for Oracle Self-Service E-Billing > Payment Processing > About Recurring Payment Processing >
Example of Scheduling a Fixed Amount Before the Due Date
This topic shows an example of how a recurring payment processes for a fixed amount scheduled before the due date. You could use this feature differently, depending on your business model. Example of How to Schedule a Fixed Amount Before the Due Date
The following steps describe an example of how to schedule a fixed amount before the due date:
- On 04/09/2012, a customer with account number as acct1111 creates a recurring payment from the UI. The amount is $50, the pay date is one day before the due date, 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 |
01/01/300 |
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 the maximum allowed. |
curr_num_payments |
0. No payments have been made yet. |
Index table entries are as follows.
|
Z_DOC_ID-STATEMENT_NUMBER |
Z_DOC_DATE-STATEMENT_LOAD_DATE |
|
acct1111 |
bill1 |
03/10/2012 |
04/15/2012 |
acct1111 |
bill2 |
04/10/2012 |
04/25/2012 |
acct1111 |
bill3 |
04/10/2012 |
05/15/2012 |
Amount due is not required for this case.
- The pmtRecurringPayment job runs on 04/10/2012 23:59:00PM, after running the ETL load and after the new bill has been inserted. In this case, bill3 is found in the index table and inserted into the payment_bill_summaries table. bill3 details are retrieved from the OLAP schema tables 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 |
04/10/2012 23:59:00P. This changes to job run time. |
last_pay_date |
01/01/1970. The value is unchanged. |
next_pay_date |
05/14/2012. This date is one day before the due date, 05/15/2012. |
bill_id |
bill3 |
curr_num_payments |
0 |
- On 05/11/2012, three days before next_pay_date, pmtRecurringPayment runs again. There is no synchronization (because bill_scheduled is N), but a payment is inserted into the check_payments or creditcard_payments table. The amount of the payment is $50.00 and its pay date is 05/14/2012. The recurring_payments table is changed as follows.
|
|
payer_account_number |
acct1111 |
bill_scheduled |
Y means this bill has been paid. |
status |
Active, next_pay_date is not after end_date. |
last_process_time |
04/10/2012 23:59:00PM. This value is unchanged because there was no synchronization. |
last_pay_date |
05/11/2012. This value changed to next_pay_date. |
next_pay_date |
05/11/2012. This value is changed. The next bill is not known. |
bill_id |
bill3 |
payment_id |
Points to the new payment_id inserted into the check_payments or creditcard_payments table. |
curr_num_payments |
1 |
- These steps repeat until next_pay_date is after end_date, when status changes to inactive.
|