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

Rebill Feature

The Rebill feature lets you issue the same bill multiple times during one billing cycle to handle adjustments. All the rebills must have the same due dates. To decide which rebill is the latest bill to pay, the current IBillDepot implementation considers the latest one to be the one with latest Doc Date. If there is more than one bill with same Doc Date, then the bill with highest IVN number is chosen. Note, this implementation assumes that a later rebill is always indexed after a previous rebill, and no rebills will be put together in one data file. This would cause the rebills to have same Doc Date and IVN number. If you want to consider other factor such as amount for making the decision, then you must reimplement IBillDepot.

The Rebill feature is enabled by job configuration parameter When to synchronize with Oracle. To use the Rebill feature, you must choose the Whenever the Job Runs option. If you do not use the Rebill feature, then you can choose either Whenever the Job Runs or Only After Current Bill is Scheduled.

Technically, there is not much difference between a regular bill and rebill. The major difference is the logic required to decide which rebill is the latest bill, which goes beyond checking bill due date. You can think about non rebill as a special case of rebill. Rebill allows the same bill to appear more than once in a single billing period, but non rebill appears only once. The code and programming logic does not distinguish between these two cases.

A Current Bill Might Not Be Paid After Initial Setup

The recurring payment start date can only start from tomorrow, so the last_process_date is set to start from tomorrow. This means all the bills indexed before today will not be processed by the recurring payment. The reason is that, currently, there is no reliable way for recurring payment to know whether the current bill has been paid or not. The user might have paid it through a one-time payment or through paper check. To avoid paying the bill twice, recurring payment will only start processing bills indexed from tomorrow.

When a recurring payment is created, the JSP page checks whether there are any indexed bills for the account. If so, Oracle Self-Service E-Billing retrieves the latest bill for the account. Oracle Self-Service E-Billing also checks whether the latest bill has been paid by checking its doc ID against the bill_id of Oracle Self-Service E-Billing Payment tables. If there is no match, then it is reasonable to assume that the bill has not been paid, so Oracle Self-Service E-Billing prompts the user to make a one-time payment to pay that bill.

Options for the When to Synchronize with Oracle When a Rebill is Not Involved Job Parameter

When a rebill is not involved, you can choose options for this job parameter. Consider the following two possibilities:

• Performance can deteriorate if you choose Whenever the job runs because instead of waiting until current bill is scheduled, the job will try to synchronize with the Command Center for each recurring payment. This can be especially true if you are communicating with billing software other than the Command Center that has a slow connection.
• A scheduled payment can be cancelled because of an unexpected early-arrival of next bill. Because the user only wants to pay the latest bill, the scheduled payment will be canceled and the new bill will be scheduled.

Cancellation of a Scheduled Payment by the Recurring Payment Job

A scheduled payment can be cancelled only when the job parameter When to synchronize with Oracle is set to Whenever job runs. Cancellation can result from one of the following situations:

• After the original bill is scheduled, but before it is processed, the rebill arrives. In this case, the original payment will be cancelled, and the rebill will be scheduled.
• The bill for this billing cycle is still scheduled, but before it is processed, the bill of next billing cycle arrives early. In this case, this bill's payment is cancelled and the next bill is scheduled.

In the case of fixed pay date and pay amount due, if a scheduled payment is cancelled, then move the last_pay_date and next_pay_date back by the pay_interval before the next bill is scheduled. This ensures that the next bill is paid with the same pay date as the previous bill.

Fixed Pay Date and Pay Amount Due When There is no Bill for the Current Billing Cycle

Recurring payment can never be triggered for a billing cycle if there is no bill, or if the bill's balance is negative (recurring payment does not issue credit). For example, a user sets to pay the bill's amount due on the 15th of each month, and current month is Oct. The next_pay_date will be set to October 15. However, if no bill arrives before October 15, then after October 15, the next_pay_date will be changed to November 15 to ensure that the bill arrives it will be paid in the next pay period. Otherwise, the user might end up paying the November bill with the October pay date.

Default Recurring Payment Update UI Limits

After the recurring payment is started, some options are limited. For example, it is not possible to switch from the Pay on Fixed Date option to the Pay Before Due option. The logic to calculate the next pay date becomes extremely complicated, so it is disallowed. If a custom UI does allow such an update, then the behavior is undefined.

Impact When the Customer's Credit Card Account Expires

If a customer's credit card expires and they are set up to use the recurring payment feature, then Oracle Self-Service E-Billing does not schedule a payment. It deactivates the card and sends an email to the user to indicate that he or she must update his or her credit card account information. The user must log in to cancel the inactive recurring payment and create a new one.

Researching Bills That Remain Unscheduled

There can be many reasons why a bill can remain unscheduled. Follow these steps to research the issue when a bill remains unscheduled.

To research the problem of a bill that remains unscheduled

1. Check whether the bill cannot be scheduled because the payment account has been cancelled, deleted, or deactivated.
2. Check whether this is a false alarm. A bill can be synchronized and scheduled. Check the next_pay_date to see whether it reflects the correct pay date for the bill.
3. If the bill is not synchronized, then check whether it has been indexed. If the bill is indexed, then check whether it falls into the synchronization period. Only bills whose Doc Date fall between last_process_time and the current time will be considered.
4. Check whether the bill has valid information. For example, verify that the due date and amount due are valid strings that can be parsed. A bill with invalid bill information or a negative balance will not be paid.
5. Check whether the due date precedes the due date of the current bill associated with the recurring payment. The bill could be valid but might still be unpaid for this reason.
6. Verify that the custom code for any custom plug-ins has been thoroughly tested. This is particularly important if the custom plug-in directly manipulates the bill's due date, amount due, or recurring payment information.
7. Review the recurring payment logic described in About Recurring Payment Processing.

Single Recurring Payment Failure Impact

A single recurring payment failure will not fail the entire recurring payment job. If the job does fail, then it is a bug. For help with this bug, create a service request (SR) on My Oracle Support.

Last Process Time

The Last Process Time is the time when the last recurring payment job ran. It is used to ensure that a bill is only retrieved once from the Command Center. Oracle Self-Service E-Billing Payment only retrieves bills indexed between the Last Process Time and the current time. That is, bills whose Doc Date is greater than or equal to the Last Process Time and less than or equal to the current time. The Last Process Time only contains date information (because the Doc Date only contains date information).