Payment Agreement Request

Oracle Revenue Management and Billing provides the ability to schedule payments in installments for a set of unpaid bills of an account through a payment agreement request. Let us understand this with the help of an example. The following bills of the account A1 are unpaid:

  • B1 (Bill Amount - 100$, Unpaid Amount - 75$)

  • B2 (Bill Amount - 250$, Unpaid Amount - 125$)

  • B3 (Bill Amount - 150$, Unpaid Amount - 150$)

Through a payment agreement request, you can schedule payments for these three bills in various installments. For example, you can schedule the following payments for the account A1:

Schedule Date Schedule Amount
01-Jan-2017 100
15-Jan-2017 100
01-Feb-2017 100
15-Feb-2017 50

While creating a payment agreement request, you need to specify the payment agreement request type using which you want to create the payment agreement request. It is the payment agreement request type which helps the system to determine:

  • The business object using which the payment agreement request should be created

  • Whether the approval is required for the payment agreement request

You can only add completed bills of the account which are unpaid in a payment agreement request. Once a payment agreement request is created for an account, the status of the payment agreement request is set to Draft. You can then edit or delete the payment agreement request, if required. Once you add the unpaid bills of the account, you can submit the payment agreement request. On submitting a payment agreement request, the status of the payment agreement request is set to Active.

You can optionally configure the system to use the approval workflow process for a payment agreement request. If the Approval Required flag is set to Yes in a payment agreement request type, then on submitting the respective payment agreement request, the approval workflow process creates a To Do for the approver to review the payment agreement request. Once the approver approves the payment agreement request, the status of the payment agreement request is set to Active. The approver can approve, reject, or resubmit the payment agreement request. When the payment agreement request is resubmitted to the submitter, the status of the payment agreement request is set to Draft.

Even if the approval workflow is configured for a payment agreement request type, you can skip the approval workflow for a payment agreement request. The system enables you to skip the approval workflow for a payment agreement request until you exceed the maximum limit defined in the C1-PASUBMIT algorithm. You can define the following parameters in the C1-PA-SUBMIT algorithm:

  • Number of days to consider in past to check whether any payment agreement request with a particular status exist in the specified duration (for example, 365)

  • Maximum number of payment agreement requests which can be activated without approval (for example, 1)

  • Status in which payment agreement request should exists in the specified duration (for example, Broken Promise)

In the above example, on clicking the Submit button, the system will check how many payment agreement requests for the account in the last 365 days exists in the Broken Promise status. If the system finds one or more than one payment agreement requests in the Broken Promise status in the last 365 days, the approval workflow process creates a To Do for the approver to review the payment agreement request. However, if the system does not find any payment agreement request in the Broken Promise status in the last 365 days, the payment agreement request is not sent for approval and the status of the payment agreement request is directly changed to Active.

When the Payment Agreement Request Periodic Monitor (C1-PAREQ) batch is invoked, the system checks whether there are any payment agreement requests in the Active status. If there is a payment agreement request in the Active status, the system checks whether the total unpaid amount of the bills is equal to zero and whether each bill is fully matched. If so, the status of the payment agreement request is changed to Kept Promise. However, if the total unpaid amount of the bills is not equal to zero, the system checks whether the current date is later than the schedule date and does not fall within the grace period. If so, the system checks whether total unpaid amount is greater than the total future schedule amount. If so, the status of the payment agreement request is changed to Broken Promise. However, if the current date is earlier than the schedule date or falls within the grace period, or the total unpaid amount is less than the total future schedule amount, the status of payment agreement request remains in Active. The system enables you to edit a payment agreement request which is in the Active status.

While defining a payment agreement request, you need to specify the payment method through which the payment will be done and whether the payment will be done through the payor or third party payor account. If the Auto Pay flag is set to Yes for a payment method, you need to also specify the automatic payment option using which the automatic payment should be created on the schedule date. One more batch named Generate Auto Pay for Payment Agreement (C1-APPAB) is introduced in this release. When the Generate Auto Pay for Payment Agreement (C1-APPAB) batch is invoked, the system checks whether there are any payment agreement requests in the Active status. If so, whether the account for which the payment agreement request is created is eligible for automatic payment and the defer auto pay date (if any) defined for the account is earlier than the batch business date. If so, the system checks whether the extract date of the unpaid bill (with the earliest due date) is earlier than the schedule date.

If so, the system creates the automatic payment for the unpaid bill on the schedule date. However, if the account is not eligible for automatic payment, or the defer auto pay date is equal to or later than batch business date, or the extract date is equal to or later than the schedule date, the automatic payment is not generated for the account.

During the payment agreement request process, a payment agreement request creation goes through various statuses in its lifecycle. For more information about the payment agreement request statuses, see Payment Agreement Request (Without Approval) Status Transition and Payment Agreement Request (With Approval) Status Transition. If the payment agreement request type is without approval then payment agreement status will automatically move from draft to active. The approval configuration algorithm C1-PA-APPEXT decides whether the request will be sent for approval or not. If the payment agreement request type is with approval then payment agreement will be sent for approval depending on:
  • The number of days checked for approval workflow

  • Payment agreement statuses (active, broken, kept) to be considered

  • The maximum number of payment agreements allowed

Note: The lifecycle of a payment agreement request creation is driven by the respective business object using which the request is created. The payment agreement request feature explained in this document is articulated based on the lifecycle and logic defined in the business objects.

For more information on how to setup the payment agreement request process, see Prerequisites.

Related Topics

For more information on... See...
Payment Agreement Request Type screen Payment Agreement Request Type
Payment Agreement Request screen Payment Agreement Request (Used for Searching)
Payment Agreement Request screen Payment Agreement Request (Used for Viewing)

Parent Topic: Oracle Revenue Management and Billing Generic Business Processes