An implementation of iReceivables and iPayment

Marcia D. Michalik

Starkey Labs, Inc.

An implementation of iReceivables and iPayment

Agenda

• Overview of Functionality

• iReceivables and iPayment Setups

• Tips and Tricks

• Lessons Learned

About Starkey

• Starkey is the world’s largest manufacturer of custom hearing devices; we strive to provide the ‘human touch’ to hearing health care

• Starkey employs about 4,000 people worldwide

• We are located in 33 countries, with HQ in Minneapolis, MN

About our Customers• Starkey distributes its products through hearing care

professionals; our customers are not end users

• Our customers’ profiles ranges from smaller ‘mom and pop’ shops to larger multi-location operations or ‘buying groups’

• Larger customers can have hundreds of invoices each

month; each order is

invoiced separately

About our Oracle Footprint

• Starkey has been using the Oracle applications since 1994

• We use Financials, Manufacturing, Engineering, Inventory, Purchasing, WIP, BOM, Cost

• iReceivables and iPayment were introduced as Phase I of a larger project to migrate AR and OM off a legacy system

• iReceivables is also being used for internal inquiry by salespeople, the Credit department, and customer service reps (they have no ability to transact)

Basic Functionality

• iReceivables gives customers the ability to:

– View account balance and aging

– invoices and credits

– Match credits to invoices

– Print copies of invoices and credits

• iPayment provides the ability to pay online

• Both are completely integrated with AR

iReceivables

Primary Screens: SEARCH

• Search by customer number, name, contact name, phone number, address or by specific transaction number

• If an account has multiple addresses, all will be displayed

Primary Screens: HOME

•Use Personalization functionality to create a custom look

Starkey’s HOME screen

Removed reference to Disputes, Discounts, Credit Requests

Added links to StatementPDF files, User Help Guide

Can add notes to ourCustomers as needed.

Primary Screens: ACCOUNT/Detail

Primary Screens: TRANSACTION

iReceivable Setups

• Minimal functional setup required

– Profile Options

• FND: View Object Max Fetch Size

• Currency:Negative Format

• OIR: Apply Credits

– Many technical activities to set up secured access to the apps through the Internet

– Primary activity was defining external users

iPayment

iPayment screens

• Account Detail screen has ‘shortcut’ to pay entire account balance

iPayment screens

• A Quick Payment utilizes the last payment method that the customer used as a default for this payment

iPayment screens

• The Advanced Payment screen allows the customer to enter a new credit card or bank account or chose a previously-saved payment method

iPayment screens

• The customer receives a confirmation when their payment has been accepted.

Payment Process

• Customer makes online payment in iReceivables; authorization is realtime and a code is returned

• The last-used payment method will default, but a new credit card or bank account can be entered instead

• The Automatic Remittance program batches payments made through iReceivables and performs additional validations

• The iPayment scheduler program transmit the batch to the processor for settlement

• This same program will report whether receipts were successfully settled or if there are issues to be addressed

iPayment Setups

• iPayment Payment Administrator (web-based) setups for security, system setups, payee setups

• Profile Options– OIR: Save Payment Instrument Information

– OIR: Maximum Future Payment Days Allowed

– OIR: Verify Credit Card Details

– AR: Mask Bank Account Numbers

• Receipt classes– Automatic Receipt class with a payment method for credit

cards and a method for ACH payments

iPayment Setups (Cont.)

• Document categories and sequencing

• Credit card accounts within a ‘Credit Card’ bank

• Payment Method at Customer and Site level

• Setups may differ depending on configuration:

– Use a Gateway or go direct to a Processor

– Need to do ACH as well as credit card processing

– Need to do inbound and outbound transactions

About our implementation

Tips ‘N Tricks

• Identify a technical resource to become the expert with personalizations in iReceivables. There is a LOT you can do with personalizations

• Set your profile option (Currency: Negative Format) correctly so that negative numbers have the negative sign, not brackets, to facilitate exporting to Excel

• Set the profile option (FND: View Object Max Fetch Size) so that all transactions can be viewed on a single page rather than scrolling through pages

Lessons Learned• Setup of external users is done by the Party number

assigned to a contact. This process may be complex depending on your customer structure. (We customized the lookup to assist with this.)

Lessons Learned (Cont.)

• The way transactions are shown can be misleading. For instance, below are two open payments. Both show a Remaining Amount of zero; the first one has the entire amount left to be applied, the second one has only $8 that hasn’t been applied.

Lessons Learned (Cont.)

• ‘Apply Credits’ functionality is not easy to use

The following example demonstrates the application of several credit memos to several open invoices…

Apply Credits Process – Initialize

• Sort by User Name

• Select transactions

Apply Credits Process – Step 1

• Select the credits you wish to use

• Go to the next step

Apply Credits Process – Step 2

• Select the invoices you wish to use

• Go to the next step

Apply Credits Process - Error

• It can be complicated to figure out how to ‘equalize’

Apply Credits – Step 3

• Reduced the amount of the invoice to match the credits

• May have to back-track through steps and de-select credits or invoices

Apply Credits – Confirmation

• Confirmation can be printed

Lessons Learned (Cont.)

• iPayment - technical configuration between Oracle, our processing provider and our network group took significantly longer than expected.

• In addition to our own testing, we had to pass connectivity and data testing performed by the processor

• We had to pass a strict security audit required by VISA/MC, performed by a third party, to maintain PCI compliance; this was done at our expense and audits are ongoing

• iPayment is being used more widely with iStore or custom OM packages than with iReceivables; Oracle support on this integration was limited

Lessons Learned (Cont.)

• Be prepared for customers calling with technical questions about accessibility (browser versions, for instance) and be prepared to route them appropriately

• Also be prepared to handle the ‘I forgot my password’calls

• A phased roll-out allowed us to work out the kinks with a select group of good customers before we opened it up to additional customers (still in the process)

In Conclusion

• Overall, setups were minimal

• Implementation required more technical resources than a standard financial application implementation

• There is a lot you can do with personalizations!

• Its hard to hide issues when the user is your customer

• Be prepared to support this new group of users who have no familiarity with the Oracle applications

Thank you!

[email protected]