Implementation Guide for Oracle Billing Insight > Customizing Payment >

Handling Multiple Payee ACH Accounts

By default, Oracle Billing Insight only allows one payee (biller) ACH account for a DDN, which is limited by payment settings. However, some billers can have multiple ACH accounts and their users will usually choose to pay to one of the ACH accounts when scheduling a payment. The way that the user chooses the ACH account to pay with can be based on business rules added to the JSP. The rest of this topic describes a solution to this problem.

The assumptions for this solution are:

• All ACH accounts are at the same bank, which means they have the same immediate origination and immediate destination but different company name and company ID.
• The business logic elements required to route the payment transaction to one ACH account compared with another is available or can be made available in the Web application and in the execution context of an Oracle Billing Insight Payment plug-in.

Oracle Billing Insight also assumes there are multiple ACH accounts and there is one DDN for this biller. This DDN is the real DDN.

NOTE:  To implement multiple payees for use with convenience fees, see Configuring Convenience Fee Payments.

To handle multiple payee ACH accounts

1. Create a real DDN to use to configure payment settings for one of the ACH accounts.
2. Create N - 1 virtual DDNs, where each of their payment settings is configured to one of the N - 1 ACH accounts, respectively. Make sure the immediate origination and immediate destination are the same for all DDNs, but their company name and company ID are different.

   NOTE:  No load jobs run against these virtual DDNs. They are used solely for payment purposes.

3. Customize the UI with business logic to determine which DDN (effectively, ACH account) the payment transaction is to be entered against and set the payee ID of the payment to that DDN.
4. Configure a single pmtCheckSubmit job under the real DDN and configure it to pull payments from the all the N -1 virtual DDNs in addition to the real DDN. The payments from the same DDN will be under same batch.
5. Because return files include returns from all DDNs and the pmtCheckUpdate job can process these returns, create one pmtCheckUpdate job under the real DDN to process all the returned transactions (even though the returns could belong to other virtual DDNs).
6. A single recurring payment job configured with the real DDN is required. A Recurring Payment plug-in is required to execute the same logic as in scheduled payment. That is, apply the business rules to determine which DDN (effectively, ACH account) the recurring payment must be applied against. Override the preSchedulePayment() method of the plug-in for this purpose.
7. In the Payment pmtPaymentReminder Job settings, configure six payment reminders, one for each DDN.
8. Run the pmtARIntegrator Job. The AR_Query.xml file is an XML definition of the database query that queries the Oracle Billing Insight payment tables to build the default A/R file. Customize the default query to include the virtual DDNs. Because the query uses the DDN reference numbers, you must pass that information into the query using one of the following methods:
   • Directly hard code the DDN reference numbers in the query, though this is risky in the sense that if the DDN is recreated, then your query will fail.
   • Extend the SampleARIntegrator and overwrite the getMap() method and use com.edocs.payment.util.DDNUtil to find out the DDN reference number of a DDN, then set it as a "?" parameter used by the query. In this solution, the DDN names are hard coded but not the DDN reference numbers.
   • Pass in the names of virtual DDNs as a flexible job configuration parameter from the job UI. The getMap() method can then parse the parameter to get the list of virtual DDNs. This method is recommended.
9. If you are using the ACH prenote, then you must create pmtSubmitEnroll, pmtConfirmEnroll, and pmtNotifyEnroll jobs for each virtual DDN, which means you will get N prenote ACH files. The pmtSubmitEnroll job cannot aggregate prenotes from different DDNs into one.