Fusionpayments 140309033431 Phpapp02

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 Partners
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 Partners 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 Oracles 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 Oracles 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.
<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
2. Key Feature: Funds Capture
Prerequisites
Feature Summary
Deltas with EBS
DISBURSEMENTS
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
Feature Summary
Key Terminology
Payment Process Profile
Payment Payment Transmit

Payables Payment
Process File Payments
User 1 Build
Request 1
Payment
File Creation
Pool of Built
Select Documents Payments
Payable
Payment Print
Payables Payment Payment File Payments
User 2 Process Build
Request 2
Select Documents
Payable
Copyright 2011, Oracle and/or its affiliates. All rights reserved. Oracle Proprietary and Confidential.
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
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
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)
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.
The following settings control automation of steps

throughout the payment process:
Page Options Details
Manage Validation error Validation error handling setting defaults to
Disbursement handling payment process request (PPR) templates
System Options PPR Status report or directly to Submit PPRs page if no
submission template is used
Create Payment Printing Set for automatic initiation or manual
Process Profile Transmission initiation. Reporting includes payment file
Reporting register, positive pay, and separate
remittance advice
Submit Payment Validation error Choose to automatically remove any
Process Request handling 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 Options Details
Manage Review proposed Setting defaults to payment process request
Disbursement payments (PPR) templates or directly to Submit PPRs
System Options page if no template is used
Submit Payment Review selected Best practice: While you can stop at both
Process Request installments points, it is recommended to stop for review
Review proposed at most once. The stopping points offer
payments 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.
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.
Decentralized
Invoice Invoice Payment
Entry BU A Selection BU A Processing BU A
BU B BU B BU B
Centralized
Centralized Centralized Invoice Centralized Payment
Invoice BU A Selection Processing
Entry BU A & B
BU A & B
BU B BU A & B
Payment Factory
Invoice Invoice Centralized Payment
Entry BU A Selection BU A Processing
BU A & B
BU B BU B BU A & B
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
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
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
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
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
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
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
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
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
Payment Methods
Payment Process Profiles
Validations
Formats
Transmission Configurations
System Security Options
FUNDS CAPTURE
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
Feature Summary
Key Terminology
Receivables Internal Payment

Authorization
User Payee System
Routing
Funds Capture Process Profile
Receipt
Creation
Receivables Settlement Payment
Settlement
User Batch Creation System
Remittance
Payment Settlement Batch
Receivables
System Acknowledgment
Copyright 2011, Oracle and/or its affiliates. All rights reserved. Oracle Proprietary and Confidential.
Deltas with EBS
Improved Transaction Exception handling, through

Accounts Receivable
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
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
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
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
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
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
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
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
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
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
Payment Methods
Funds Capture Process Profiles
Internal Payees
Formats
Transmission Configurations
System Security Options
<Insert Picture Here>
Oracle Fusion Payments

Implementation and Configuration Considerations

Fusionpayments 140309033431 Phpapp02

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fusionpayments 140309033431 Phpapp02

Uploaded by

Copyright:

Available Formats

Disclaimer

Oracle Online Training Materials Usage Agreement

Oracle Fusion Payments

Payment Process Profile

Payment Payment Transmit

Terminology Change: Payment Instruction changed to

New setup entity Payment Code combines three EBS

What is your business process?

What validations do you need?

Straight Through Processing

The following settings control automation of steps

Optional stopping points for review during the

Best practices for process submission

Do not enable Create Payment Files Immediately, as this will limit

Create a scheduled process for each template to create PPRs

Best practices for process submission

Fewer payment files result in lower transaction processing

Select invoices to be paid with a broad selection

Select invoices to be paid with targeted selection

Choose broad payment methods like the seeded

You can use prepackaged validations designed to

Validations can be associated with payment methods or

Or after payment process request submission if the

Use the Positive Pay File to reduce fraud

Receivables Internal Payment

Funds Capture Process Profile

Improved Transaction Exception handling, through

What Payment Methods to Accept

Leverage existing banking or processing relationship

Find out what your processing partner supports

Modify seeded formats using BI Publisher

Find out what your processing bank supports

End Users Router over Leased Line

DMZ Public Zone

Comply with PA-DSS Security Standards

Use Oracle Wallet Manager to create a wallet

Bank account numbers are not encrypted immediately

Transactions are identified by Business Unit, but are

Oracle Fusion Payments

You might also like