Customer Based Payments

15.3.6 Customer Based Payments

The Payment Entry screen enables you to manually post customer based payments to a single customer account or multiple accounts linked to same customer. System accepts such type of payments based on Customer / Business # and allocates to the accounts linked to the customer. The allocation is based on the payment hierarchy which contains the account selection criteria and sorting order defined in setup (Setup > Administration > User > Payment Hierarchy screen).

To facilitate customer based payments, the system parameter UIX_CUSTOMER_BASED_PMT_IND has to be set to Y which enables Customer / Business # and Payment Hierarchy fields along with Populate Accounts button in Payment Entry screen.

Customer based payments can be entered into the system by manually creating in Payment Entry screen, bulk upload through file upload process and through Customer based Payments web services.

In the Payment Entry screen, when payment has to be allocated to multiple linked accounts of the customer, select Multi Account check box, select Customer / Business #, Payment Hierarchy details and click Populate Accounts button. System populates the accounts based on the account selection criteria defined in Payment Hierarchy setup screen.

Following validations are considered while filtering the accounts for payment allocation:

Accounts which has the same company, branch combination selected at batch level and either the selected customer is of primary relation to account or in case of business, accounts which are associated with the business are displayed.
Payment allocation order is as per the sequence defined in Setup > Administration > User > Payment Hierarchy screen > Hierarchy Order tab.
If the account is already closed and/or the account does not have outstanding dues, system excludes those accounts from being populated.

However note that, based on payment and outstanding dues on the accounts, sometimes the entire payment allocation may be consumed by first few accounts with higher dues even if there are other eligible accounts for selected Customer/Business #.

Consider the following example where payment allocation is to be done to accounts based on current dues. if there are 3 accounts linked to a customer and a payment of $100 is to be allocated to eligible accounts, then system populates the accounts in the following ways:

If Account 1 has current dues is greater than 100, then $100 may all be allocated to Account#1. In this case, Account 2 and Account 3 will not be populated.
If Account 1 dues are $80 and Account 2 dues are $50, then $100 may be allocated to Account 1 and Account 2. In this case, Account 3 will not be populated.
If Account 1 dues are $50, Account 2 dues are $30 and Account 3 dues are $40, then $100 may be allocated to Account 1, Account 2 and Account 3. In this case, all 3 accounts will be populated.

In case the Payment Hierarchy is selected as Equal Amount, system allocates the total amount into equal portions based on filtered accounts. The payment allocation is done even though there is no due on the accounts. For information on different types of payment allocation supported, refer to Setup > Administration > Users > Payment Hierarchy section.

Customer Based Payments File Upload

Customer based payments can be processed in bulk through file upload process. To do so, the payment file need to contain required field details in the Header and Detail block as indicated below:

Header Record need to contain the following:

Table 15-12 Header Record

Company	Total	Total Amount
Company Code	Total # of Detail Records	Total Amount i.e. sum of Details Records

Each field information is validated with the data maintained in the system and in case of any discrepancies, the entire payment upload batch is rejected. For example, when the specified company code is not maintained, or if Total Amount contains a non numeric data, the entire batch is rejected from processing.

The details of each transaction need to be maintained in the following format as indicated with system defined validations:

Table 15-13 Transaction Details

Field Name	Expected Values	Mandatory (Y/N)	Validation
Customer / Business #	Customer# / Business #	Y	Validates for mismatch in Customer# / Business #
Payment Hierarchy	Payment Hierarchy value	N	Payment Hierarchy is validated with setup. If the value is not matching the record is rejected and placed in bad file. If Payment Hierarchy is not provided system takes default value from Customer Details tab. If the Payment Hierarchy at customer Details is disabled, record is moved to bad file with error message Provided Payment Hierarchy is disabled. If the Payment Hierarchy at customer Details is not provided, system takes the value from system parameter. If system parameter is disabled, the default value Equal Amount is considered.
Currency	Currency Code	Y	Validates Currency code/exchange rate in OFSLL
Pmt Date	Pmt Date	Y	Cannot be a future date. Else, added to bad records.
Pmt Amount	Payment Amount	Y	Require numeric date to be provided.
Reference	Free text	N	Reference Number
Mode	Mode Code	Y	Validates for Mode code.
Reason	Reason Code	N	Validates for Reason code in OFSLL

For more details on processing, refer to Bulk Upload of Payment Transactions section.

Customer Based Payments Web Service

Customer based payments can also be added into the system through web services. To do so, the request/response files need to be updated with above field details (Details block information) and posted. System validates the field details and either displays in Payment Maintenance screen or rejects in case of a mismatch.

For details on web service used for payment posting, refer to Web Service documentation on OTN library.

Parent topic: Payments