1

2

3

4

5

6

7

A little bit about our legacy-legacy processes (IBM mainframes)

- 250,000 checks per year into over 20 lockboxes spread somewhat geographically,

driven by heat maps of customer locations

- Receive wire transfers from some of our larger customers

- Wires typically have EDI remittances (EDI 820) that we load into our system

- Some of our largest customers really love to take deductions… ~1 million claims

per year

8

- Legacy automation was high… and with some additional processes, % of payments

climbs to 96%

CHALLENGE WE RECEIVED – put this process into Oracle EBS and achieve similar

levels of automation

9

10

- Customer sends checks to the lockbox managed by the bank

- The bank keys the data and deposits the funds

11

- Bank transmits an encrypted file to EBS

12

- Users receive an email notification that a file was received and decrypted

- User submits the Process Lockboxes form, entering the transmission name, data

file name, and control file name

- Once completed, users search for receipts and apply them using images of the

remittances for details

13

- Users delete system messages… some users even wrote outlook rules to

automatically delete emails

- Users couldn’t/wouldn’t coordinate activities… files would get dropped, missed, or

duplicated

- Reliable super users were few, and when they were out processes would tend to

not get done

- Users don’t have visibility into the process until the system notifies of a file… hard

to troubleshoot

14

15

16

So what’s new?

- 3 new pieces of functionality

- We also used some SOA to help control the process… SOA can detect files in a

directory and submit the concurrent program

17

- Based on a rules engine

- Default applier available

- Can automatically allow workload assignment, or allow users to self-assign work

- Prevents duplication of effort

- Large checks may take hours to prepare an application

- Don’t want 2 appliers working the same item outside of the system

- Assignments prevent duplication of effort

18

Cash Application Work Queue Example Screen.

1. Search by customer, cash applier, receipt date, and more

2. Actions = “Apply Receipt” and “Identify Receipt” links take the applier directly to

the receipt

3. Multi-select items and re-assignment or self-assignment… we trained our users to

pick the top 5 or 6 at a time… first in first out queue

4. Can export the search results to Excel (CSV)… this exports the entire data set of

search results, even across multiple pages

5. Expandable details show more information… details like receipt date, receipt

method, and notes

Screenshot is from published Oracle documentation

19

- Report summarizes receipt counts by cash application owner

- Doesn’t account for differences in receipt complexity

- So it may help you, maybe not… we chose not to use it for now, and allow cash

appliers to assign work items to themselves instead of having the manager or the

rules engine do it

- Set is up so that everything is assign to a default “unassigned” cash applier

20

Example of the Cash Apps Work Load Review Report

Screenshot is from published Oracle documentation

21

- When an unidentified lockbox receipt with a payment instrument is associated to

a customer, the customer record is updated with the banking information (MICR

number)

- When importing future receipts, Auto Lockbox can automatically identify

customers based on the customer record MICR numbers

- Basically, Oracle will remember who owns that bank account and automatically

populate it next time

- This speeds up customer identification, and increases automation for repeat

customers

22

- Example of MICR saved on customer bill to site

23

- Previous form based submission enhanced to work with Standard Request

Submission (SRS) concurrent manager

- Lockbox processing can now be scheduled and automated

- Program name is “Process Lockboxes (SRS)”

- Notice that Oracle suggests that to improve productivity, customization can be

added around this functionality … this is what we will be exploring in the

remainder of this session

24

- Form based manual submission requires the user to know the transmission file

and data file names

25

- The key to it all… Oracle delivered on an ER to provide this program, which made

the whole process possible.

- Provides all the same functionality as the form, but as an SRS program

- The form spawns a concurrent program using the form input, so the SRS program

wasn’t a big leap

- This new concurrent program can be called by a service, script, or other custom

program and passed the data file and transmission file names

26

27

Path to Success:

1. Consolidated files – worked with bank to pull lockbox cuts from across multiple

boxes onto a single file, minimize costs and reduce program instances

• Generated heat maps of customer locations and mapping to the closest

geographical lockbox locations

• Rationalized lockboxes and transmission times to minimize cost and

maximize efficiency

• Single file per cut time reduces cost (pay per transmission)

2. SOA automation – used SOA integrations to pull files, perform the decryptions,

poll directories, and trigger the Process Lockbox (SRS) program

• Use mget to get all files, allows for auto-recovery if either system is down

• SOA services monitor inbound directories for encrypted files, and

decrypt and move to processing directories

• SOA services monitor processing directories for decrypted files, and

trigger process and archive procedures

3. Oracle SRS program – allowed us to call/schedule the jobs in the system and

avoid user interaction

• Still runs the standard Oracle process flow

28

1. New cash work queue – we set a single rule to assign a default UNASSIGNED user,

and allowed cash appliers to claim receipts a handful at a time to work. This

prevented users trying to work over top of each other, and also allowed managers

to assign work items when needed.

2. OPTIONAL LOGIC – Receipts API enabled bolt on logic engines… we designed logic

to automatically apply cash based upon our unique business rules, and process

the “easy” receipts as completely as possible

• Neat trick with the BAI transmission format to hide detail records from EBS

to allow proprietary logic to perform all matching and clearing

28

Standard options may not meet business needs

1. When customers are remitting with very detailed remittance instructions

2. When customers are paying very large numbers of invoices with a single payment

3. When there are many deductions or sophisticated deductions rules

4. When there are many write-offs or sophisticated write-off rules

Our Approach

- Sophisticated business rules developed over many years were implemented to increase

automation

- Updated our BAI specification with our banking partner to include gross, discount and net

amount fields, and invoice, PO, and account reference fields

Custom logic can run after receipt creation because a separate program is needed to

populate the Cash Queue.

29

Best practices:

1. Keep your banking partner in the loop… we were helped by our bank to find ways

to tweak our system interactions to make this process work

2. better… our banking partner provided ideas such as pooling files, consolidating

cut times, and updating the BAI specification

3. Test religiously… we uncovered many nuances of SOA, EBS, and the bank’s

platform by testing heavily and repeatedly

4. We found an Oracle limitation regarding batch numbers within a lockbox

transmission.

- Oracle program cannot process the same batch number within different

lockboxes in the same file.

- We worked with the bank to prevent this from occurring

- Open ER to update EBS functionality

5. There is a system limitation that cash cannot be applied across operating units in

R12

30

31

32

33