Oracle Fusion Payments

Disclaimer
Oracle Online Training Materials – Usage Agreement
Use of the information, documents and online training courses (collectively, “Materials”) found on this area of the Site constitutes
agreement with the following terms and conditions (as well as those set forth in the Purpose and Disclaimer sections below):
1. Oracle is pleased to allow its business partner (“Partner”) to download and copy the Materials found on this area of the Site. The
Materials are proprietary information of Oracle. Partner or other third party at no time has any right to resell, redistribute or create
derivative works from the Materials. The use of the Materials is restricted to the non-commercial, internal training of the Partner’s
employees only. The Materials may not be used for training, promotion, or sales to customers or other partners or third parties.
2. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective
owners.
3. Oracle disclaims any warranties or representations as to the accuracy or completeness of any Materials. Materials are provided "as is"
without warranty of any kind, either express, implied or statutory, including without limitation the implied warranties of merchantability,
satisfactory quality, fitness for a particular purpose, accuracy, timeliness and non-infringement of third-party rights. The information
contained herein is subject to change without notice.
4. Under no circumstances shall Oracle be liable for any loss, damage, liability or expense incurred or suffered which is claimed to have
resulted from use of these Materials. As a condition of use of the Materials, Partner agrees to indemnify Oracle from and against any and
all actions, claims, losses, damages, liabilities and expenses (including reasonable attorneys' fees) arising out of Partner’s use of the
Materials.

1

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Oracle Proprietary and Confidential.

Disclaimer

Purpose:

This document provides an overview of features and enhancements included in Oracle Fusion Applications 11gR1 Release 11.1.1.5.0
and applicable updates. It is intended solely to help you assess the business benefits of upgrading your existing Oracle Products to
this release, or implementing completely new Oracle developed products, and planning your I.T. Projects.

Disclaimer:

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your
access to and use of this confidential material is subject to the terms and conditions of your Oracle Software License and Service
Agreement or other applicable contract with Oracle, with which you agree to comply. This document and information contained
herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without Oracle’s prior written consent. This
document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its
subsidiaries or affiliates.
This document is intended to outline our general product direction. It is intended for informational purposes only and solely to assist you
in planning for the implementation and upgrade of the product features described. Release information contained in this document
is not a firm development plan. Release information published here should not be used as the basis for customer delivery
commitments, as part of marketing efforts, or during contract negotiations. This is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features
or functionality, and inclusion or not thereof in the commercially available version of the Software, if any, is subject to change at any
time and is always at Oracle’s sole discretion. This document is not considered part of the applicable program documentation.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this document without
risking significant destabilization of the code.

2


<Insert Picture Here>

Oracle Fusion Payments
Implementation and Configuration Considerations

Agenda
1. Key Feature: Disbursements
•
•
•
•
•

Prerequisites
Feature Summary
Deltas with EBS
Key Decisions and Best Practices
Relevant Setup Tasks

1. Key Feature: Funds Capture
•
•
•
•
•

4

Prerequisites
Feature Summary
Deltas with EBS


Disbursements

5


Prerequisites
• The concepts covered in the following Fusion Version
1 TOIs are prerequisites for understanding this
implementation document:
• Manage Payments L3: Prepare and Record Payments
• Manage Payments L3: Process Payment Files
• Set Up Procurement L3: Define Disbursements and
Configure Payment System Connectivity

6


Feature Summary
Key Terminology

Payment Process Profile
Payables
User 1

Payment
Process
Request 1

Payment
File

Payment
Build

Pool of Built
Payments

Select Documents

Transmit
Payments

Payment
File

Print
Payments

Payment
File Creation

Payable
Payables
User 2

Payment
Process
Request 2

Payment
Build

Select Documents
Payable


Deltas with EBS
• Terminology Change: Payment Instruction changed to
Payment File
• New setup entity Payment Code combines three EBS
setup entities:
• Delivery Channel Code
• Bank Instruction Code
• Payment Reason Code

8


• What is your business process?
• Decide how much to automate

• What is your organizational structure?
• Support for decentralized, centralized, payment factory
models

• What are your processing goals?
• Targeted invoice selection or least effort

• What payment methods do you need?
• Broad, or granular with validations

9


• What validations do you need?
• Payment method or format
• User defined or predefined
• Document payable, payment, or payment file

• What formats can you use?
• Configuring or customizing for your needs

• Security (Encryption and Masking)

10


What is your business process?

• Straight Through Processing
• Advantages:
• Fewer touch points means less effort
• Exceptions handled outside the payment process, good
payments not held up by the few exceptions

• Tight Manual Control
• Advantages:
• Allows manual review and confirmation of payments in
process
• Allows step to be initiated manually to fit specific timing
needs
Note: Any combination of manual and automated steps can be used. It is not necessary to
be completely automated or completely manual. The best practice is to automate
everything except manual review of either selected invoices or proposed payments. See
following slides for further options and best practices.

11



• The following settings control automation of steps
throughout the payment process:
Page

Details

Manage
Disbursement
System Options

•Validation error
handling
•PPR Status report
submission

Validation error handling setting defaults to
payment process request (PPR) templates
or directly to Submit PPRs page if no
template is used

Create Payment
Process Profile

•Printing
•Transmission
•Reporting

Set for automatic initiation or manual
initiation. Reporting includes payment file
register, positive pay, and separate
remittance advice

Submit Payment
Process Request

12

Options

•Validation error
handling

Choose to automatically remove any
documents or payments with errors and
progress valid items, or stop the process
and review errors



• Optional stopping points for review during the
payment process:
Page

Details

Manage
Disbursement
System Options

•Review proposed
payments

Setting defaults to payment process request
(PPR) templates or directly to Submit PPRs
page if no template is used

Submit Payment
Process Request

13

Options

•Review selected
installments
•Review proposed
payments

Best practice: While you can stop at both
points, it is recommended to stop for review
at most once. The stopping points offer
different values, so pick the one that suits
your needs best



• Best practices for process submission
Object

Best Practice

Payment Process Create one template for each unique combination of submission
Requests
attributes. Ensure your templates cover all normal cases – avoid
off-cycle payments and the associated costs.
Do not enable Create Payment Files Immediately, as this will
limit payment file creation to within a single PPR.
Create a scheduled process for each template to create PPRs
automatically. This should be run frequently enough to meet due
dates, as well as to take advantage of early payment discounts.

14



• Best practices for process submission
Object

Best Practice

Payment Files

Create one or more scheduled processes that will run after all
PPR processes complete. The payment file will pick up any
waiting payments with the proper attributes, regardless of which
PPR they originated in, allowing for the fewest number of
payment files possible.
Fewer payment files result in lower transaction processing
costs.

15


What is your organizational structure?

Decentralized
Invoice
Entry

BU A

Invoice
Selection

BU A

Payment
Processing

BU B

BU B

BU A
BU B

Centralized
Centralized
Invoice
Entry

BU A

Centralized Invoice
Selection

Centralized Payment
Processing

BU A & B

BU B

BU A & B
BU A & B

Payment Factory
Invoice
Entry

BU A
BU B

16

Invoice
Selection

BU A

Centralized Payment
Processing
BU A & B

BU B


BU A & B

What is your organizational structure?

• Decentralized Processing
• Enable each BU to create its own payment process
• Enable each BU to decide who and when to pay

• Centralized Processing
• Reduce manpower costs by centralizing payment process
decisions and exception handling
• Reduce payment processing costs by pooling payments
together into fewer payment files
• Efficiencies of scale allow some users to specialize in
payment processing

• Payment Factory
• Enable each BU to decide who and when to pay
• Reduce payment processing costs by pooling payments
together into fewer payment files
17


What are your processing goals?

• Select invoices to be paid with a broad selection
criteria, thus creating as few payment process
requests as possible
• Recommended for a Centralized Processing model
• Payment process templates can be more generic, and fewer
of them
• Best practice for supporting broad selection is to ensure that
only one payment process profile (PPP) is active per unique
set of transactional attributes (business unit, payment
method, disbursement bank account, and currency)
• System can derive PPP automatically per payment,
instead of forcing all payments in a payment process
request to have the same PPP

18


What are your processing goals?

• Select invoices to be paid with targeted selection
criteria, thus allowing precise control over time
• Recommended for Decentralized or Payment Factory models
• Allows different types of payments to be managed in separate
processes, for example expense reports Monday, domestic
supplier payments Tuesday, and so on
• Best practice to support targeted selection is to create
specific payment process templates for each type, using pay
groups, payment priorities, or other targeted selection criteria

19


What payment methods do you need?

• Choose broad payment methods like the seeded
Check and Electronic, or choose to create your own
more granular payment methods, optionally with
targeted validations
• Use laser printed checks rather than numbered checks when
possible.

• For a detailed discussion of the costs and benefits of
more granular payment methods, see topic ‘Payment
Methods: Explained’ in the ‘Define Disbursements’
chapter of the Implementation Guide

20


What formats can you use?

• Favor standards-based formats that can be used with
multiple banks
• EDIFACT formats (PAYMUL, MT100, MT103, etc)
• NACHA formats (Generic, CCD, PPD, etc)

• Find out what your processing bank supports
• Modify seeded formats using BI Publisher
• An XML extract provides Payments data
• Use RTF templates to create or modify human-readable
layouts, for checks and reports
• Use ETEXT files to create fixed-position layouts, for
transmission and automated payment processing
• For a more detailed discussion of tailoring formats to your
needs, see the white paper ‘Format Customization In Oracle
Payments’ at support.oracle.com
21


What validations do you need?

• You can use prepackaged validations designed to
match specific formats
• You can create your own validations for almost all
transaction attributes
• Layer them on top of prepackaged validations when formats
or regulations change
• Or use them to create entirely new validations for your own
formats

22



• Validations can be associated with payment methods or
formats
• Validations can be performed at the following levels:
• Document payable
• Payment
• Payment File

• Documents payable are validated during invoice entry if
the validation is associated with a payment method…
• Immediate feedback
• Fastest way to resolve errors and make payments
• Requires knowledgeable invoice entry personnel and a larger
number of payment methods with different validations
associated
23



• … Or after payment process request submission if the
validation is associated with a format
• Allows a specialized payment process manager to queue up
and resolve errors
• Allows fewer payment methods and requires less knowledge
for invoice entry personnel

• For a detailed discussion of the costs and benefits of
validations, see topic ‘Validations: Critical Choices’ in
the ‘Configure Payment System Connectivity’ chapter
of the Implementation Guide

24


Security

• Use the Positive Pay File to reduce fraud
• Encrypt and mask supplier bank account numbers
before importing or entering any data in the system
• Use Oracle Wallet Manager to create a wallet
• Store wallet in a very secure, limited access file
system location
• Obtain encryption keys externally, or have Payments
generate them
• Rotate encryption keys periodically
• See System Security Options: Critical Choices in the
Implementation Guide

25


•
•
•
•
•
•

26

Payment Methods
Payment Process Profiles
Validations
Formats
Transmission Configurations
System Security Options


Funds Capture

27


Prerequisites
• The concepts covered in the following Fusion Version
1 TOIs are prerequisites for understanding this
implementation document:
• Process Customer Payments L3: Manage Funds Capture
• Set Up Order Fulfillment L3: Define Funds Capture and
Configure Payment System Connectivity

28


Feature Summary
Key Terminology
Receivables
User

Internal
Payee
Routing

Authorization

Payment
System

Funds Capture Process Profile
Receipt
Creation

Receivables
User

Settlement

Settlement
Batch Creation

Payment
System

Remittance
Payment
System

Settlement Batch
Acknowledgment


Receivables

Deltas with EBS
• Improved Transaction Exception handling, through
Accounts Receivable

30


•
•
•
•
•
•

31

What Payment Methods to Accept
What Payment Systems to Use
What Formats to Use
What Transmission Protocols to Use
Security Setup: Encryption and Masking
Tying It All Together: Internal Payee


What payment methods to accept

• Credit Cards
• Implement additional features to reduce processing fees
• Company card support
• Address verification
• Card verification code

• Bank Account Transfers
• Payer-initiated payment methods (such as checks
and cash) are recorded directly in Oracle Fusion
Receivables

32


What payment systems to use

• Leverage existing banking or processing relationship
• Your bank may process transactions, or have a partnership
with a processor

• Leverage processors with existing integrations with
Oracle Payments EBS
• Chase Paymentech (Certification Pending)
• First Data Global Gateway (formerly Concord EFSnet)
(Certification Pending)
• PayPal PayFlow Pro (Certification Pending)
• Other existing integrations have been built by gateways or
consulting firms

33


What formats to use

• Find out what your processing partner supports
• For a detailed discussion of tailoring formats to your
needs, see the white paper ‘Format Customization for
In Oracle Payments’ at support.oracle.com

34


What formats can you use?

• Modify seeded formats using BI Publisher
• An XML extract provides Payments data
• Use RTF templates to create or modify human-readable
layouts, for checks and reports
• Use ETEXT files to create fixed-position layouts, for
transmission and automated payment processing
• For a more detailed discussion of tailoring formats to your
needs, see the white paper ‘Format Customization In Oracle
Payments’ at support.oracle.com

35


What transmission protocols to use

• Find out what your processing bank supports
• Favor transmission protocols seeded in Oracle Fusion
Payments
• Use Funds Capture Process Profile for greater
configurability in transmission and formatting
• Avoid name-value pair approach

36


Deployment Architecture
External Connectivity

End Users

Router over Leased Line

DMZ Public Zone

OR
HTTP Load
Balancing

Payments
Transmission Servlet

Internet

DMZ Secure Zone

Payment System

Application Tier

Intranet

Database Tier

37


Security

• Comply with PA-DSS Security Standards
• Hard requirement for accepting credit card payments
• Minimize risk of exposing sensitive customer data
• Work with an PA-DSS auditor to ensure compliance and
avoid potential violations

• Encrypt and mask customer credit card and bank
account numbers before importing or entering data
into the system

38


Security

• Use Oracle Wallet Manager to create a wallet
• Store wallet in a very secure, limited access file
system location
• Obtain encryption keys externally, or have Payments
generate them
• Rotate encryption keys periodically
• See System Security Options: Critical Choices in the
Implementation Guide

39


Security Gotchas

• Bank account numbers are not encrypted immediately
upon entry
• Configure the Encrypt Bank Account Data program to run
frequently

• Credit Card Numbers that are entered through PLSQL
(via migration or import) are not encrypted
immediately
• Run the Encrypt Credit Card Data program after imports

40


Tying It All Together: Internal Payee

• Transactions are identified by Business Unit, but are
processed by Internal Payee
• If all Business Units require identical processing, create one
internal payee to serve them all
• If Business Units require different processing, create one
internal payee per business unit
• In a mixed model, use Routing Rules to determine how to
process each transaction

41


•
•
•
•
•
•

42

Payment Methods
Funds Capture Process Profiles
Internal Payees
Formats
Transmission Configurations
System Security Options


Oracle Fusion Payments

More Related Content

What's hot

Viewers also liked

Similar to Oracle Fusion Payments

Recently uploaded

Oracle Fusion Payments

Editor's Notes