Oracle EBS R12 iReceivables: Self-Service Module for Customer Accounts

Oracle E-Business Suite Release 12 iReceivables
All You Need to Know
Ajaz Ahmed
Royal College of Physicians and Surgeons of Canada
Introduction
This paper introduces Oracle iReceivables functionality and process flows and offers a peek into the
integration details with other EBS modules. It is meant for a range of audiences i.e., ranging from
customers to finance department to EBS professionals. Oracle iReceivables is a self-service module
within E-Business suite (EBS) that allows customers to view, print, pay and even dispute their
transactions on a 24/7 basis. Oracle iReceivables works seamlessly with other Oracle E-Business Suite
products to drive better decision-making, sustainable financial discipline, and regulatory compliance at
the lowest cost. It helps in reducing the cost of billing and collections while improving overall customer
service. Automated payment processing and dispute management reduces receivables and collections
cycle times, improves cash flow, and lowers days sales outstanding (DSO).

Salient Features
iReceivables gives organizations control of receivables data presentment and search functionality using
the personalization options and customization architecture. It offers capabilities to control data security in
dispute and payment processing via functional security, user registration, and Oracle database and
application server technology. iReceivables offers customers self-service access to their accounts with
real-time balance and transaction information. In addition, customers can:

 print their transactions – invoices, debit memo, credit memos or a list of variety of transactions;
 dispute an invoice or any transaction on an invoice;
 pay their invoices while they are logged on to iReceivables; and
 can pay in any currency

Figure 1 – Oracle EBS R12 – iReceivables Salient Features

Page 1 of 14
COLLABORATE 12 – OAUG Forum Copyright © 2012 by Ajaz Ahmed

Functionality

iReceivables is a bolt-on module to the Oracle Receivables module. Any transactions or activities in
Oracle Receivables can be made visible to a customer logged on to iReceivables. The product can be
implemented with or without “Pay” functionality. When used without Pay functionality, it will still allow
customers to view, print and dispute their transactions online. However, the “Pay” functionality allows
customers to pay their invoices online and puts payment control in the customer’s hands. iReceivables
offers easy to use and intuitive payments pages and offers customers a worry free online payment
experience. A payment made in iReceivables is tightly coupled to the invoice(s) selected by the customer
and online payments are credited only to selected invoices. Payments of any amount can be made
ranging from the minimum allowed to the maximum total of the outstanding invoice(s) that was selected to
pay.

Figure 2 – Oracle EBS R12 – iReceivables Home Page

iReceivables pages in EBS release 12 have been developed using Oracle Applications Framework (OAF)
technology. Navigation through iReceivables is simple. Pages can be grouped into four major areas of
functionality – Accounts summary/details pages, Payment pages, Dispute pages and Print pages. The
Home Page displays Account Summary, the status of disputed transactions and alerts regarding
discounts. The Home page also offers a Related Information Area in the form of a side bar where news,
messages or web links can be published for customers’ information. The Statement Download area
allows customers to download up-to-date statements. iReceivables uses templates that have been
developed using Bills Presentment Architecture (BPA) to offer flexible printing options. This architecture
gives organizations control of receivables data presentment to customize the content and format of the
customer facing documents such as invoices, debit memos, credit memos, etc. BPA allows multiple
templates for a transaction class and then assigns these templates at the time of viewing or printing
based on assignment rules. For example, a different template can be used to view or print invoices based
on criteria such as organizational unit, customer name or invoice amount thresholds.

Accounts Summary area is located at the top left side of the page and displays totals of various types.
Clicking on any of the hyperlinks in the Accounts Summary area of the home page will open the Account
Details page.

Page 2 of 14

The Account Details page allows users to select transactions based on a variety of criteria such as Any
Status, Closed, Open/pending, and Overdue or Current Transactions. All types of transactions such as,
invoices, payments, credit memos or debit memos can be further drilled down to display their details.

Figure 3 – Oracle EBS R12 – iReceivables Account Details

Any open invoice(s) can be selected to make an online payment. Customers can pay invoices in two
ways:- a) by selecting the required invoice and clicking on the Pay button; or b) or by clicking on the
Transaction hyperlink or view the transaction details on a new page and then clicking the Pay button on
the transaction details page. In both cases customers are taken to a Payment page where customers
provide their credit card details, enter the amount to pay, and click the Apply button.

Figure 4 – Oracle EBS R12 – iReceivables Payment Page

Please note that the message “Enter your credit card information for one time use only….” means that the
credit card information from the Payment page will be deleted and will not be visible when customer logs
on next time. However, credit card numbers are stored in Oracle Payments tables although in an
encrypted format. This meets the compliance requirements with industry standards such as Payment
Card Industry Data Security Standards (PCI DSS) for online payments.

Page 3 of 14

Disputing an invoice is another powerful feature of iReceivables. The Dispute process is spread over
three pages. On the opening page, the customer picks a Reason for Dispute from the drop down list and
selects the desired section of the invoice. On the second page, the customer provides a disputed amount
or a percentage of the actual amount along with textual details, if any, and on the third page, the
customer reviews the dispute details and submits it.

Figure 5 – Oracle EBS R12 – iReceivables Dispute Page

From this point onward, the dispute gets routed to the relevant approval chain in the organizations using
Oracle workflow. For example, when the final approver, often someone in the Accounts Receivables
department, approves a disputed amount, an approved credit memo is issued and applied to the same
invoice against which the dispute was launched and a notification is sent to the customer. If however, the
dispute is rejected, then no further action is taken except customer notification. Customer is able to view
these notifications when he logs in to iReceivables next time or he would receive an email depending
upon his notification preferences settings.

Figure 6 – Oracle EBS R12 – iReceivables Dispute and Credit Memo process flow

Page 4 of 14

Configuration Nuts and Bolts

Most Oracle EBS implementations are deployed completely within an Organization’s intranet as they are
only accessible by trusted users within the Organization. Any employee requiring access to EBS through
the internet is provided with a Virtual Private Network (VPN) account that uses a secure connection tunnel
with the intranet before accessing EBS. Oracle iReceivables, however, is a self-service (accessible from
the internet) application within the EBS Credit to Cash suite of solutions. The customers using
iReceivables could be in the hundreds of thousands, residing in different parts of the world and hence the
VPN solution could not work for them. Customers expect a hassle-free internet access using the internet
whereas at the same time organizations are reluctant to expose the entire EBS suite to the outside world.
Oracle has documented various methods for making a subset of EBS R12 functionality accessible via the
internet to external users such as customers using iReceivables module. All of these methods require use
of Demilitarized Zone (DMZ) protected with firewalls to ensure that only authorized traffic is allowed to
cross firewall boundaries. This arrangement ensures that even if intrusion attempts against the DMZ are
successful, it remains contained within the DMZ, leaving intranet unaffected.

The following configuration options are supported:

 Using separate web node for external usage
 Setting of server level profile options
 Associating trust levels to application middle tier nodes
 Limiting available responsibilities to a restricted set for the external web node
 Deploying reverse proxy in front of the external web node
 Configuring a URL firewall and “mod security” in the reverse proxy in front of external web node
 Running only essential Oracle EBS Applications services on the external web tier

iReceivables seamlessly integrates with a number of Oracle EBS R12 modules after the required
implementation steps are followed. Integration with third party Payment Processors or Gateways is
required to allow iReceivables customers to pay online. Some payment system solutions come with an
out of the box integration whereas, others may require significant development effort to integrate Oracle
Payments and the third party payment system.

Figure 7 – Oracle EBS R12 – iReceivables configuration in DMZ along with rest of the EBS in Intranet

Page 5 of 14

Figure 8 – Oracle EBS R12 – iReceivables integration and dependencies with other modules.

The above diagram highlights some of the major elements required for implementing iReceivables
solution. It shows that other than setting up iReceivables, relevant setups in Oracle Receivables, Oracle
Payments, Bills Presentment Architecture, Oracle Workflow and System Administration have to be
completed as well. Moreover, integration between Oracle Payments R12 and a 3rd party Payment
Processor/Payment Gateway would be a step required to be completed if the online payment capability of
iReceivables needs to be made available.

Oracle Payments needs to communicate with third party financial institutions and payment processors
over open networks such as the Internet. PayPal as well as the following out-of-the-box payment systems
integrations require such open-network connectivity:

 Cybercash
 Concord EFSNet

Whereas the following out-of-the-box payment system integrations communicate with their destination
payment systems using non-open networks (e.g., a leased line):

 First Data North
 Paymentech

The complexity of integrating payment processors or gateways with Oracle Payments varies from vendor
to vendor.

Technical Process Flows - Credit Cards Processing

Credit Cards Storage:

iReceivables calls Oracle Payments instrument creation Application Programming Interface (API) to store
/retrieve credit card information to Oracle Payments tables. The request data is sent via a HTTP call-out

Page 6 of 14

from the database to a servlet on the middle-tier application server. The “key-encryption” key is retrieved
from the Oracle Wallet file and this key, and the original request data, is passed back to the database and
another stored procedure using Java Database Connectivity (JDBC). The results of the request are
returned to the original stored procedure (instrument creation API) in the HTTP response.

Credit Card Authorizations:

The authorization API makes a HTTP call-out to a servlet on the middle-tier application server. The
servlet uses the access encryption key from the wallet to decrypt any transaction data, formats it into a
payment system-native instruction format, and passes the payment instruction to the payment system
either directly or through a delivery servlet deployed outside the customer’s intranet. If the payment
system has a gateway interface (such as, Cybercash or Paypal), then this flow represents settlements
and chargebacks as well. For processor interface type payment systems (Paymentech, First Data) the
settlement and chargeback flow is slightly different. A scheduled concurrent program runs from a
concurrent progressing node and executes Oracle Payments within an embedded Java Virtual Macchine
(JVM). Oracle Payments retrieves the access encryption key from the wallet file and passes it to the
database using the JDBC to perform bulk decryption of transaction data. The data is returned to the Java
layer and formatted into a batch payment instruction file delivered to the payment system either through a
direct network connection or through transmitting the request to a specialized servlet outside the
deployment intranet.

Payment Servlet Cleanup

Paymentech and First Data North servlets both store acknowledgment data that includes primary account
number (PAN) to prevent data loss to the middle-tier or check duplicate processing of a payment
instruction. These acknowledgment files are always stored in encrypted format using a data-encryption
key provided by the Payments engine. The Payments servlet archives payment system acknowledgments
in the directory specified by the ARCHIVE_DIR servlet initialization parameter. The contents of this
directory must be periodically wiped by a secure data wipe executable.

rd
Example integration of a 3 Party Payment System:
PayPal Gateway – Payflow Pro (formerly Verisign)

PayPal has created its own integration with Oracle Payments for its Payflow Gateway. This integration
was formerly built and maintained by VeriSign. Oracle Metalink note "Implementing PayPal With Oracle
Payments Release 12 [ID 879378.1] has replicated documentation that comes along with PayPal
Payment Solution for R12. The Oracle note however, is a well written document and is easier to follow but
it is a good idea to compare the two sets of instructions to ensure that they are the same before starting
the integration work. The latest PayPal servlet package at the time of writing this paper was version v4.50
(pfpro_oPayments_R12_v4.50.zip). It is free to download from the following location:
https://skydrive.live.com/?cid=586bda469e09784f&sc=documents&id=586BDA469E09784F%212693

PayPal solution Payflow Pro (PFP) comes with 7 Jar files, 3 configuration file and one sql script. Jar files
and configuration files need to be copied on the application tier, and the SQL script need to be run as
apps user in order to create two database tables. Make sure to follow all the instructions step by step
when copying files, adding classpaths, or modifying a configuration file. In order to test the integration, a
PayPal test account is required to access PayPal Manager. The free test account can be obtained by
registering at http://manager.paypal.com Note that a PayPal test account only allows use of designated
credit card numbers for testing purposes and all payments must be less than nine dollars in amount.

Page 7 of 14

These credit card numbers are also documented in Oracle Metalink note “Test Credit Card Numbers [ID
395462.1]”.

Here are the major implementation steps for PayPal integration.

1. Copy Payflow Pro Jar files and Payflow Pro configuration files to required locations.
2. Add Jar files to classpaths
3. Create Logging directory for PayPal
4. Configure Payflow Pro servlet in OC4J by updating the template file orion_web_xml_1013.tmp
and running AutoConfig and bouncing the concurrent manager
5. Run the “PFPRO_Create_Table.sql” script to create two tables for use by the PayPal Payflow
plugin.
6. Modify “options” field in the concurrent program definition window for the concurrent program
named “Submit Offline Transactions”
7. Ensure the relevant Profile values are setup correctly using System Administrator responsibility.
8. Login with Oracle Payments Administrator responsibility and define PayPal Payment system
under Payment Systems section and Payee for PayPal under Payee section. This is where
PayPal servers URL and PayPal account details are provided.
9. Bounce the oacore on all application tier hosts.
10. Bounce the concurrent manager.

If integration is successful, the payment instruction would be passed on to the PayPal gateway that would
communicate to the Payment Processor and return a message from Payment Processor back to the user
in iReceivables. PayPal offers a choice of all major Payment Processors. This means the existing
merchant account with a Payment Processor can be used without going through the hassles of applying
for a new merchant account. The ability to work with a variety of Payment Processors is a strong feature
of PayPal’s solution. Moreover, due to a pre-configured plug-in for EBS R12, PayPal solution is much
easier and quicker to implement for credit card processing.

Page 8 of 14

Start

iReceivables
user initiates
online
payments
request

Pass Payment
Information to
Credit Card
Oracle Yes No
details valid?
Payments
Servlet

Create a
Oracle Payment Receipt in
formats the Payment Oracle
Payment Response from Gateway Yes
Authorized? Receivables
instruction and with status =
passes it to Confirmed
Payment
Gateway = PayPAL

Payment Processor
communicates it to Return a
Gateway
Credit Card Issuer and No Message to
communicates
transmits response User
with Payment
back to Gateway, to
processor =
Oracle payments and
Moneris
to iReceivables
Payment Page

End

Figure 9 – Oracle EBS R12 – iReceivables Credit Card Authorization process flow

Online Credit Card Payment processing in Oracle payments is a two-step process. Oracle Payments
mandates that authorization is invoked before a transaction can be settled in Oracle Receivables. Oracle
Payments enforces that the settlement amount is equal to or less than the authorized amount and
explains why one can’t make overpayments through iReceivables. This means fewer claims in
Receivables or Oracle Trade Management due to overpayments. After successful payment authorization,
a settlement job “Automatic Remittances Master Program” needs to run in order to transfer funds from the
Credit Card issuer. This job can be scheduled as a concurrent program to run at a desired frequency.

When a payment is settled, Oracle Receivables changes the status of the corresponding receipt from
“confirmed” to “remitted”. The receipt will ultimately be assigned “cleared” status when it clears the bank
statement reconciliation in Oracle Cash Management.

Page 9 of 14

Complying with Payments Application Best Practices

Online Payment applications, when implemented into a complete Payment Application Best Practices
(PABP)-compliant environment and according to the information in Oracle whitepaper –Payment
Applications Best Practices [ID 738344.1], facilitate and support a retailer in their Payment Card Industry
Data Security Standard (PCI-DSS) initiatives. Oracle Payments conforms to all applicable PABP
requirements allowing implementers to achieve compliance with Payment Card Industry (PCI) Data
Security Standards (DSS). It provides a secure payment instrument storage and funds capture processing
functionality for the entire Oracle eBusiness Suite.

Security Architecture

The Payments security architecture secures PABP-incidental data such as Credit Card numbers using a
chain key approach. The chain key consists of a site-wide key-encryption key (master key or system key)
that encrypts one or more data-encryption keys (subkeys), each of which is used to encrypt a fixed
amount of data before a new data-encryption subkey is generated. This approach ensures quicker
rotation of the system key.

The architecture is comprised of the following components:

 Payments System Key and Payments System Subkeys
 Oracle Wallet
 Secure Segments Storage

Payments System Key and Subkeys:

When encryption is enabled in Payments, a system-level security key is generated which is a password
comprised of a maximum of 24-characters. The system key is the key-encryption master key for the entire
installation. It is stored in the Oracle Wallet and is used to encrypt the Payments data-encryption subkeys.
Payments subkeys are randomly system-generated symmetric-cipher keys that are encrypted using the
system-level Payments Security Key. Rotating the master key re-encrypts only the Payments subkeys,
rather than the data they are responsible for (for example, credit card numbers). A Payments subkey
typically encrypts one thousand rows of data. According to PCI DSS standard 3.6.4, key rotation must
occur at least annually. Key rotation is performed in the Payments Security Options page. Key rotation
results in the immediate re-encryption of all data-encryption subkeys with the new system key.

Oracle Wallet:

Oracle Wallet is a graphic user interface (GUI) application that can be launched from
$ORACLE_HOME/bin directory by typing owm. A wallet is a secured repository to store encryption
passwords and security certificates. System Administrators must ensure that wallet files are secured
using file system security.

Secure Segments Storage:

Encrypted data is stored in the Payments IBY_SECURITY_SEGMENTS table. Credit card primary
account numbers are stored in this table as encrypted. Extra security measures should be taken to limit
access to this table.

Page 10 of 14

Minimum required setups for other EBS modules:

In order to turn on Payments and Dispute features in iReceivables, a number of EBS modules need to be
configured along with iReceivables configuration. These modules include Oracle Receivables, Oracle
Payments, and Oracle Workflow. Following is a brief discussion of all such modules and the required
setups. Details about these setups can be found in the implementation guides of each of the modules.
EBS Module Name: iReceivables
EBS Responsibility Name: iReceivables Setup
System Profile options, System Parameters, and Global and Operating unit level Rules can be setup
using iReceivables Setup responsibility. Setups are very simple and are done on separate pages.
iReceivables also includes the configuration package ARI_CONFIG, written in PL/SQL. The
ARI_CONFIG configuration package lets you modify attributes in iReceivables without having to make
changes to any other part of the code. The package contains functions and procedures that are
referenced elsewhere in the iReceivables code. You can modify the following components using the
ARI_CONFIG configuration package

 :Account Summary page information section
 Account Summary page discount alerts and dispute statuses section
 Contact Us global button e-mail address
 iReceivables transaction search and customer search
Dispute pages can also be customized. iReceivables messages can also be edited using look up codes in
Oracle Application Object Library.

Figure 10 – Oracle EBS R12 – iReceivables Setup Checklist

'Credit Card Receipt Method' and 'Bank Account Payment Method' need to be setup under the System
Parameters. These values would have been defined in Receivables. These settings would default to the
receipts that would be created from customers payments in iReceivables. Please note that iReceivables
supports cross-currency payments using a credit card or bank account that has a different currency from
that of the invoice; the receipt created in iReceivables will still have the same currency as the invoice.

EBS Application Name: Oracle Receivables
EBS Responsibility Name: Receivables Manager
Oracle Receivables setups are required in order to turn on the online payment functionality in
iReceivables. The most important setups are setting up a Receipt Class with creation method of
Automatic and defining at least one Receipt Method associated with this Receipt Class. Information from

Page 11 of 14

these setups is used while generating a receipt in Receivables for customers’ online payments. The
receipt is then applied to the invoice that the customer selected at the time of making the online payment.
Other important setups are Credit Memo approval limits and defining a Credit Memo batch source.

Figure 11 – Oracle EBS R12 – Receipt Class setup in Receivables

EBS Application Name : Oracle Payments
EBS Responsibility Name: Oracle Payments Administrator

The most important setups are setting up System Security Options and Payment Systems under Shared
Setups node as well as setting up Payment Methods, Payees and Credit Card Brands under Funds
Capture node. System Security setup facilitates setting up encryption keys to encrypt credit cards and
other sensitive data according to recommendations and suggestions provided in Oracle White Paper -
“Payment Applications Best Practices [ID 738344.1]”

Figure 12 – Oracle EBS R12 – Oracle Payments Setup page

Page 12 of 14

EBS Application Name: Bills Presentment Architecture (BPA)
EBS Responsibility Name: Bills Presentment Super User
BPA offers a new kind of reporting architecture for various modules of EBS R12. Oracle Receivables is
predefined primary data source in BPA. A set of default templates for different transaction classes in
Oracle Receivables are available as out-of-the box solutions however, templates can be easily modified
or created using BPA template editing tool. External templates can also be registered in BPA by defining
external data sources first. Rules can be setup in BPA for example, to select different invoice templates
based on different criteria e.g., operating unit or the invoice amount.

Figure 13 – Oracle EBS R12 – Oracle Bills Presentment Architecture (BPA) configuration page

EBS Application Name: Oracle Workflow
EBS Responsibility Name: Workflow Administrator
Oracle workflow acts as a communication vehicle for approvals throughout EBS. Oracle Workflow can be
setup to specify which users receive approval requests. Please see “Setting Up the AME Credit Memo
Request Workflow” topic in Oracle Receivables User Guide for details.

EBS Application Name: Oracle System Administration
EBS Responsibility Name: System Administrator
This is where a number of system administration tasks are performed for iReceivables. For example,
internal and external users are created, and Function security is implemented for external users by
modifying menu attached to the iReceivables Account Management responsibility. Moreover, a job to
index customer database is also run from here.

Page 13 of 14

Benefits of implementing iReceivables

 Reduced DSO (Days Sales Outstanding)
 Empowers customers to view, pay, print their outstanding invoice from around the world - any
location where internet is available
 Reduces time spent by support services in resolving log-in issues as passwords can be reset by
customers through password hint functionality
 Quick and easy mechanism to dispute invoices. Offers customers to register their dispute online
against any invoice or any of its lines
 Streamlining of back end processing of dispute resolution process. Facilitates automated
generation of credit memo and its application against the original outstanding invoice, when
dispute is resolved in customers favor
 Customers are kept up to date with the progress of their disputed cases.
 Easy to manage and customize customer facing documents templates

Conclusion

iReceivables is part of Oracle’s Credit to Cash family of software solutions. It helps organizations with
increased efficiencies by reducing the cost of billing and collections, improving cash flow, and improving
customer relationships. It puts accounts receivables’ control in the customer’ hands. Implementation is
fairly straightforward, however, setting up the online payments functionality requires additional technical
expertise to integrate iReceivables with third party payment systems securely. It is imperative that all of
the recommendations provided in Oracle’s “Payments Application Best Practices” document are followed
in their entirety to ensure compliance with applicable standards and regulations for setting up online
payments. iReceivables is accessed by customers using the internet and therefore, special security
measures are required to be taken to avoid hacking and other technology risks. iReceivables should be
exposed to the outside world through a Demilitarized Zone (DMZ) configuration protected with firewalls to
ensure that only authorized traffic is allowed to cross firewall boundaries. This arrangement ensures that
even if intrusion attempts the DMZ are successful, it remains contained within the DMZ leaving the EBS in
intranet unaffected.

Useful links

 https://support.oracle.com/CSP/ui/flash.html
 https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-gateway-overview-outside
 http://www.pcisecuritystandards.org
 http://www.pcicomplianceguide.org

Oracle Notes:

 Payment Applications Best Practices [ID 738344.1]
 Oracle E-Business Suite R12 Configuration in a DMZ [ID 380490.1]
 Tips and Queries for Troubleshooting Advanced Topologies [ID 364439.1]
 iReceivables uptake of Oracle Payment [ID 414659.1]
 How To Setup a Wallet At R12 Level In scope Of PA-DSS Implementation? [ID 1118887.1]

***

Page 14 of 14

Oracle EBS R12 iReceivables: Self-Service Module for Customer Accounts

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Oracle EBS R12 iReceivables: Self-Service Module for Customer Accounts

Similar to Oracle EBS R12 iReceivables: Self-Service Module for Customer Accounts (20)

Recently uploaded

Recently uploaded (20)

Oracle EBS R12 iReceivables: Self-Service Module for Customer Accounts