Implementation Guide for Oracle Self-Service E-Billing > Customizing Payment >

Handling Multiple Payee ACH Accounts

By default, Oracle Self-Service E-Billing Payment 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 some 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 versus another is available or can be made available in the web application and in the execution context of an Oracle Self-Service E-Billing Payment plugin.

Oracle Self-Service E-Billing also assumes there are multiple ACH accounts and there is one DDN for this biller. This DDN is the Real DDN.

To handle multiple payee ACH accounts

1. Create a real DDN. You use this real DDN to configure Payment Settings for one of the ACH accounts.
2. Create virtual DDNs: 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:  There will be no ETL load jobs run against these virtual DDNs. They are used solely for payment purposes.

3. Customize the UI: The UI must employ some 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. Run the pmtCheckSubmit Job: 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. Run the pmtCheckUpdate Job: pmtCheckUpdate processes the ACH return file. 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. Run the Payment pmtRecurringPayment Job: 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. Change the Payment pmtPaymentReminder Job setting: Six payment reminders, one for each DDN, must be configured.
8. Run the pmtARIntegrator Job: The AR_Query.xml file is an XML definition of the database query that queries the Oracle Self-Service E-Billing Payment tables to build the default A/R file. The default query must be customized to include the virtual DDNs. Because the query is using the DDN reference numbers, you must pass that information into the query using one of the following methods:
   • Directly hard code the DDN references numbers in the query, though this is risky in the sense that if the DDN is recreated, 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. Add support for the ACH Prenote: If you are using ACH prenote, then you must create pmtSubmitEnroll, pmtConfirmEnroll and pmtNotifyEnroll jobs for each virtual DDN, which means you will get N prenote ACH files. pmtSubmitEnroll cannot aggregate prenotes from different DDNs into one.