Statement Level Payment Distribution

Until now, you were able to match a payment against a particular bill of an account. Oracle Revenue Management and Billing now provides the ability to apply a payment on a statement which will get matched against the unpaid bills on the statement. The bills on a statement may belong to the same or different accounts of the person for whom the statement is created using the statement construct. Note that the system supports the statement level payment distribution for those statements:

  • Which are created using the statement constructs comprising of one or more accounts and no contracts (under construct details)

  • Which are in the Printed status

This feature is only applicable for accounts which practice open item accounting. The system supports the statement level payment distribution through the following modes:

  • Inbound web service

  • EDI 820 file

  • Payment request

  • Payment upload

While creating a match type for the statement level payment distribution, you must set the entity type of the match type to Statement. Earlier, the manual distribution algorithm of a match type was invoked only when payment distribution was done through the payment request feature. Now, the manual distribution algorithm of a match type is invoked when the payment distribution is done using any of the above modes. The existing manual distribution algorithm spot of a match type is enhanced to support the statement level payment distribution. In case of the statement level payment distribution, the manual distribution algorithm spot receives the statement ID as the input parameter. When this algorithm spot is invoked through the payment request feature, the statement ID is passed as the match value. However, when this algorithm spot is invoked through the inbound web service, EDI 820, or payment upload feature, the statement ID is not passed as the match value. Instead, the statement ID is directly fetched from the dataset. The manual distribution algorithm spot then returns a list of unpaid bills on the statement.

A new manual distribution algorithm named C1-MD-STMT is introduced in this release. It distributes the payment amount against the unpaid bills of the statement in the ascending order of due date (i.e. bill with the oldest due date will have high priority). If there are multiple unpaid bills with the same due date, the system distributes the payment amount against the unpaid bills in either of the following two ways:

  • In the ascending order of the unpaid amount (i.e. bill with the lowest amount will have high priority)

  • Using the weighted distribution based on the unpaid amount of each bill

If you want to distribute the payment amount using the former method, you must set the Weighted distribution of payments among bills of same age. (Valid Values :Y,N) parameter of the C1-MD-STMT algorithm to N. However, if you want to distribute the payment amount using the latter method, you must set the Weighted distribution of payments among bills of same age. (Valid Values :Y,N) parameter of the C1-MD-STMT algorithm to Y.

Once the system distributes the payment amount against the unpaid bills of the statement, the system creates a payment for each unpaid bill. Here, all these payments would be created under the same payment event.

Any excess amount that is left after distributing the payments on the unpaid bills of the statement should be applied on the on-account contract of the account. The person linked to the statement construct using which the statement is created should have an account which will be used to park the excess amount paid on a statement. If the account is not available and the payment against a statement is in excess of the total unpaid balance of the statement, then the entire payment on the statement ID will be errored out and won’t be applied on any of the bills.

The system derives the on-account contract of the account using the contract type specified in the On-Account Contract Type option type of the C1-ADJ-PAY feature configuration. If the on-account contract of the specified contract type is not available for the account, the system creates on-account contract using the contract type specified in the On-Account Contract Type option type of the C1-ADJ-PAY feature configuration. The system then parks the excess credit payment on the on-account contract of the account. While creating the excess credit payment, the system uses the match type which is specified in the On-Account Match Type option type of the C1-ADJ-PAY feature configuration.

Once all payments including the excess credit payment is created, the system will store the statement ID on all payments when the payment is applied at the statement level. The statement ID is stored as a characteristic using the characteristic type which is specified in the Statement Level Payment Characteristic Type option type of the C1-ADJ-PAY feature configuration. The C1-STPAY characteristic type is shipped with the product.

Note that you can apply payments on the statement level using the single-step approach of the PUPL batch and not using the three-step approach of the PUPL batch. Also, note that multi tender distribution is not supported for the statement level payment distribution.

Note: At the moment, you can delete a statement which is used for the payment distribution from the user interface. The system neither performs any validation during the statement deletion nor cancels any payments when a statement is deleted. Therefore, you need to ensure that you do not delete any statements which are used for payment distribution in the system.