Bookshelf Home | Contents | Index | PDF |
Implementation Guide for Oracle Self-Service E-Billing > Payment Processing > About Recurring Payment Processing > Rebill FeatureThe 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 SetupThe 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 ParameterWhen a rebill is not involved, you can choose options for this job parameter. Consider the following two possibilities:
Cancellation of a Scheduled Payment by the Recurring Payment JobA 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:
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 CycleRecurring 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 LimitsAfter 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 ExpiresIf 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 UnscheduledThere 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
Single Recurring Payment Failure ImpactA 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 TimeThe 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). |
Implementation Guide for Oracle Self-Service E-Billing | Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |