ireceivables implementation: a unique case study

REMINDER

Check in on the

COLLABORATE mobile app

iReceivables Implementation: A Unique Case Study

Prepared by:

Anand Tuppad & Chris Preziotti

Applications Team

BIAS Corporation

Exploring iReceivables beyond the implementation guide

Session ID#: 10196

@preziotti / @BIASCORP

Next one hour…

■ Introduction

■ DMZ Architecture and Setups

■ iReceivables Setups

■ iReceivables “Self”-Registration

■ BPA Integration

■ Custom Solutions

■ Conclusion

© Copyright 2015 by BIAS Corporation. All Rights Reserved.

Introduction

Business Case Scenario

What is iReceivables?

Client Oracle Footprint


Business Case Scenario ■ Client: Premium Wine and Spirits Distributor

■ Track Supplier Chargebacks

▪ e.g. Free Goods, Samples

■ “Supplier AR”

▪ Suppliers treated as Customers

▪ Separate AR Team

■ Problems:

▪ Process inefficiencies

▪ Decentralized operations

■ Goals:

▪ Standardize “Supplier AR” process using Oracle Receivables

▪ Increase Visibility and Efficiency using iReceivables

■ Discussion Focus:

▪ The iReceivables Solution


What is iReceivables?

■ A web-based, self-service application used to access Receivables data

■ Gives customers easy access to account information


What is iReceivables? - continued

■ Reduces customer reliance on AR / Collections teams

■ Save money and time; improve customer service


Client Oracle Footprint – Financials System


DMZ Architecture and Setups


DMZ Server Architecture


DMZ Setups ■ Backup app tier and clone to DMZ tier

■ Modify EBS context file

<externURL oa_var="s_external_url">www.arportal.xxxxx.com:8000</externURL>

<HELP_WEB_AGENT oa_var="s_help_web_agent">http://finprdsar.xxxxx.com:8000</HELP_WEB_AGENT>

<webentryhost oa_var="s_webentryhost">www.arportal</webentryhost>

<login_page oa_var="s_login_page">http://www.arportal.xxxxx.com:8000/OA_HTML/AppsLogin</login_page>

■ Enable EBS Application server security

<appserverid_authentication oa_var="s_appserverid_authentication">SECURE</appserverid_authentication>

■ Configure URL Firewall in DMZ – remove # value

<urlfirewall oa_var="s_enable_urlfirewall"/>


DMZ Setups - continued ■ Profile “Node Trust Level” for DMZ Server set to “External”

■ Profile “Responsibility Trust Level” for “iReceivables Account Management” responsibility set to “External”

■ Add below responsibilities to GUEST user. Also change “Password Expires” to none for this user.

▪ iReceivables Account Management

▪ iReceivables Self Service

▪ iReceivables Registration responsibility

■ Assign all responsibilities starting with “iReceivables%” to SYSADMIN


DMZ Setups - continued ■ Profile UMX: Register Here Link - Default Registration

Process

▪ Set it at server level

■ More information: Oracle E-Business Suite R12 Configuration in a DMZ (Doc ID 380490.1)


iReceivables Setups


iReceivables Setups ■ All standard Receivables/iReceivables

setups performed

■ Notable configurations include:

▪ Personalized Account Summary page to

show Expanded Aging Bucket by Default

▪ Created “3”-Bucket Aging for iReceivables

to match customer requirements

▪ Updated the “Contact Us” AOL functions to

reflect correct email address for Support

— ARI_REG_CONTACT_US

— ARICONTACTUS

▪ Dispute functionality


iReceivables Setups – continued ■ Removed Worklist Region on Home Page

■ Profile Options:

PROFILE LEVEL VALUE

OIR: Aging Buckets Site 3-BUCKET OVER 60

OIR: Apply Credits Site No

OIR: Account Grouping Site Group Sites

OIR: Bill Presentment Architecture Enabled Site Yes

OIR: Hide Account Sites Site Yes

OIR: Search Default Customer Name and

Number

Site Show Check


iReceivables “Self”-Registration

What is iReceivables Self-Registration?

Business Scenario

Solution Walkthrough


What is iReceivables Self-Registration?

■ How external users gain access to iReceivables

■ Step-by-step process to verify user and account access

■ Two Phases of Registration

1. Registration Request

— Performed by Customer (External User)

2. Registration Approval

— Performed by Implementing Business


Registration Request

■ “Register here”

▪ Link enabled on External Landing Page


Registration Request - continued

■ 6 Step Process

1. Select Organization

2. Validate Customer Access

3. Select Location

4. Verify Access

5. Enter User Information

6. Review Access Request Submit


Registration Approval

■ Workflow sends the Approval Notification

▪ By default, SYSADMIN user receives Approval Notification

■ Once approved, Confirmation Email is sent to External User:


Registration Approval - continued

■ Behind the scenes:

▪ Creates User

▪ Assigns “iReceivables Account Management” Responsibility

▪ Creates Customer Contact with “Self Service User” Role


Business Scenario - The “Self” in Self-Registration

■ Key Aspects:

▪ Perform External User Registrations In-House

— “Make the customer’s transition as smooth as possible”

— One iReceivables Admin

▪ Customer Onboarding Process

1. Communication of iReceivables

2. Receive Welcome Email

3. Log-On


Business Scenario - continued - The “Self” in Self-Registration

■ Solution Objectives

▪ Simplify “Self”-Registration Process

▪ Redirect Registration Approvals

▪ Quickly Provide Add’l Account Access


Solution Walkthrough - Simplify “Self”-Registration Process

■ iReceivables Rules

▪ Menu Path: iReceivables Setup (T) Rules

▪ Update Global Rules

— Customer Verification Question: “What is the password?”

▪ Update Operating Unit Dependent Rules

— Site Verification Question: [Blank]


Solution Walkthrough - continued - Simplify “Self”-Registration Process

■ iReceivables Rules

▪ Global Rules – Screenshot of ‘Validate Customer Access’ Step:



■ Registration Personalization

▪ Menu Path: iReceivables Registration Responsibility

Personalize Table Layout: “RegAccess…”

▪ Remove ‘Select All Locations’ Checkbox

— Forces all Registrations to be at Account Site level



■ Registration Personalization

▪ Screenshot of ‘Select Location’ Step:


Solution Walkthrough - continued - Redirect Registration Approvals

■ Self-Registration Approval

1. Use AME to Create Custom Approval Transaction Type

2. Update iReceivables Self Registration Process

— Menu Path: User Management Registration Processes


Solution Walkthrough - continued - Redirect Registration Approvals

■ Self-Registration Approval

▪ Screenshot of Approval Notification:


Solution Walkthrough - continued - Quickly Provide Add’l Account Access

■ DQM Profile Options

▪ Menu Path: System Administrator Profile System

— HZ: Enable DQM Party Search = Yes

— HZ: Duplicate Allowed = No

— HZ: Enable Duplicate Prevention at Party Creation = Person and

Organization

— Keep default ‘HZ: Match Rule for Duplicate Prevention’ profile options

■ Providing Additional Account Access

▪ Recreate the existing contact


Solution Walkthrough - continued - Quickly Provide Add’l Account Access

■ Providing Additional Account Access

▪ Screenshot of DQM’s Duplicate Prevention Warning:


Solution Walkthrough - continued - Configuration Summary

■ Solution Objectives Revisited

▪ Simplify “Self”-Registration Process

iReceivables Rules

Registration Personalization

▪ Redirect Registration Approvals

Self-Registration Approval

▪ Quickly Provide Add’l Account Access

DQM Profile Options


BPA Integration

What is Bill Presentment Architecture?

Business Scenario

Solution Walkthrough


What is Bill Presentment Architecture?

■ How AR Transactions are viewed online, i.e. iReceivables

■ The face of:

▪ Invoices

▪ Debit Memos

▪ Credit Memos

▪ … etc.

■ Most environments leverage BPA to some degree

▪ Oracle provides pre-defined templates


Default Online Invoice Example


BPA Configurations in a Nutshell

■ The appearance is set up using …

1. Data Sources

— Where is the data coming from? e.g. Receivables, Interface Context

2. Content Items

— What additional data elements? e.g. Logos, Custom Text

3. Templates

— How should the transactions look? e.g. Arrangement, Formatting

■ The logic is set up using …

▪ Template-based Rules


Business Scenario - Making BPA Work for a Unique Business

■ Key Aspects:

▪ Pre-Defined Templates wouldn’t cut it

— Company Logos

— Transaction Labels

— Additional Data Elements

▪ Oracle AR Remit-To Addresses didn’t

reflect business operations

▪ Necessary to create “No Line”

Transactions


Business Scenario - continued - Making BPA Work for a Unique Business

■ Solution Objectives

▪ Familiarize the Transaction Look

▪ Replace the Default Remit-To Address

▪ Conditionally Hide Line Information


Solution Walkthrough - Familiarize the Transaction Look

■ Content Items – Image Type

▪ Menu Path: Bill Presentment Superuser

(T) Template Management Content Items

▪ Company Logo Images

▪ Transaction Label Images

» All image files were uploaded to the OA_MEDIA directory


Solution Walkthrough - continued - Familiarize the Transaction Look

■ Content Items – Image Type

▪ Screenshot of Invoice with Image Content Items:



■ Data Sources


(T) Configuration Data Sources

▪ Update Primary Data Source, ‘Oracle Receivables’

— Add ‘Account Name’ as Template Item

▪ Add Supplementary Data Source for Interface Data

— Add ‘Item’ and ‘Item Size’ as Template Items



■ Data Sources

▪ Screenshot of Invoice with Updated Data Sources:


Solution Walkthrough - continued - Replace the Default Remit-To Address

■ Content Items – Message Type


(T) Template Management Content Items

▪ Three ‘Remit-To’ Messages for each Location


Solution Walkthrough - continued - Replace the Default Remit-To Address

■ Content Items – Message Type

▪ Screenshot of Invoice with Message Content Items:


Solution Walkthrough - continued - Conditionally Hide Line Information

■ Templates


(T) Template Management Templates

▪ Create a New Template without touching ‘Lines and Tax’


Solution Walkthrough - continued - Conditionally Hide Line Information

■ Templates

▪ Screenshot of “No Lines” Invoice:


Solution Walkthrough - continued - Configuration Summary

■ Solution Objectives Revisited

▪ Familiarize the Transaction Look

Content Items – Image Type

Data Sources

▪ Replace the Default Remit-To Address

Content Items – Message Type

▪ Conditionally Hide Line Information

Templates


Custom Solutions

5 Custom Solutions:

Statement Downloads, Customer Search,

Backup Files, Statement Mailer, New Invoice Mailer


Statement Downloads ■ iReceivables Customer Statement

■ All Receivable Transactions

■ All Transactions

■ Credit Memo

■ Debit Memo

■ Invoice

■ Payment


Statement Downloads – Solution ■ Data definition RTF templates modified

■ Achieved through XML Publisher template modifications from Oracle seeded templates. Works great!!!

■ ER logged with Oracle to include Transaction Type on all these downloads – below field shows transaction class.


Customer Search ■ Screen to search for customer accounts.

■ Search by name, transaction number or payment

■ Page displayed only when user has multiple account access.

■ Include Account Description column and remove few

■ Important since external users know their accounts by name and not by number

■ Seeded column Customer Name is actual Party Name (TCA) – can have multiple AR accounts


Customer Search – Solution ■ Customer search customized using Oracle user hook

■ Oracle user hook

▪ Package: ARI_CONFIG

▪ Procedure: search_custom_customer

■ Personalization

▪ To show Attribute1 (mapped to Customer Account name)

▪ To hide Organization Name field

■ Lookup

▪ ARI_CUSTOMER_SEARCH_TYPE

■ iReceivables Custom Customer Search, An Oracle White Paper (Doc ID 278133.1)


Backup Files Architecture ■ Enabled View Attachments for iReceivables invoice detail

page using BPA templates

■ CSV detail files created programmatically after import

■ PDF summary files created using XML Publisher and bursting feature

■ Files attached to Transactions via FND Attachments

■ AR: BPA Print Attachment Document Category set to Miscellaneous

■ Readily available to customers – thus faster payments


Statement Mailer Architecture ■ Contacts are registered with email address

■ 2 types of statements

▪ Regular statements – emailed every week

▪ Over 60 days past due statements – emailed every 15 days

■ Technologies:

▪ Statement – XML Publisher Report

▪ Email – XML Publisher Bursting


Statement Mailer Architecture – continued


New Invoices Mailer ■ Anytime a new invoice is created in Oracle AR, email is sent

to account contacts

■ Invoice header – BPA Transaction Print Program

■ All backups attached to transaction are picked up for email

■ Single email with all new transactions per account per contact

■ Technologies:

▪ Audit trail – custom logic in PLSQL

▪ Download backup files to file system – PLSQL

▪ Send email – Workflow


New Invoices Mailer – continued ■ Invoice header – PDF file – same look and feel as online

iReceivables


Conclusion

Takeaways

Questions / Comments

Contact Us


Takeaways ■ Flexibility of iReceivables

■ Effectively Standardized Business Process

■ Quick Turnaround

▪ Implementation

▪ Training

■ Supplier AR Team Efficiencies

▪ 80% Reduction in Customer Inquiries

▪ 300+ Hours Saved Each Month

■ Improvement in Customer Service

■ Great feedback from Business and End Customers!


Questions / Comments


Contact Us

Chris Preziotti

Senior Applications Consultant

[email protected]

Anand Tuppad

Applications Architect

[email protected]


Please complete the session evaluation We appreciate your feedback and insight

Session ID#: 10196

You may complete the session evaluation either

on paper or online via the mobile app

ireceivables implementation: a unique case study

Documents