Leveraging Oracle Projects for Party and Site Centric Customer Billing

Leveraging Projects features and functionality to
bill customers modeled in multiple ways
by
Kalyan Pantina & Mani Kumar Manda
Session# 10362
OAUG Collaborate 2017
Las Vegas, Nevada
Wednesday, April 4, 2017

© 2017 Kalyan Pantina & Mani Kumar Manda. All rights reserved.
OAUG Collaborate 2017, Las Vegas, Nevada 2
Leveraging Projects features and functionality to bill customers
modeled in multiple ways
Kalyan Pantina Mani Kumar Manda
RJT Compuquest Inc. Rhapsody Technologies, Inc.
Kalyanc444@gmail.com mmanda@RhapTech.com
Abstract
Historically, customer data has been modeled in EBS per site centric model. But most of the
CRM and Cloud applications use Party Centric model. In this session we will discuss how Oracle
Projects can be implemented successfully under both customer models. Specifically in services
industry, the use of Service Contracts and Oracle Projects go hand-in-hand, and this session
addresses the implementation of Oracle Projects to effectively bill the Customer using Oracle
Projects.
Objective 1: Discuss the implementation of Oracle Projects for billing customer created using
party and site centric models.
Objective 2: Discuss how Oracle Projects can be integrated with Service Contracts and aid in
the customer billing process.
Objective 3: Discuss the Pros and Cons of using One Project vs. Multiple projects for billing a
single customer.
Objective 4: Have a dialogue with the audience about their challenges associated with customer
billing in service industry.
Objective 5: Pros and Cons of using Oracle Projects/Other approaches.
Business Need
1. Consolidated Billing in Service companies.
To produce consolidated bills to customers including detailed breakdown based on various
criteria including multiple projects, multiple services associated to a project, multiple
technologies.
2. Implement Complex Business Process via Standard and extended functionality across
modules
This requires careful orchestration of the design across Customers, Project Billing, Service
Contracts, Accounts Receivable and BPA with seamless integration.
3. Maintaining Reporting Dashboards

Requirement is to have a single profitability dashboard across multiple Customer Installations
that occur over a period of time and associated monthly services.
Oracle Trading Community Architecture & Customer Models:
In R11i of Oracle eBusiness Suite, Oracle released a new architecture called “Trading
Community Architecture” aka “TCA” to primarily solve the challenges associated with adding
new functionality into the application suite in the CRM space. This new architecture was needed
since the prior design could not accommodate use cases associated with the CRM and Customer
Service areas of the business. When TCA is released, the focus was on Customer domain and bit
of Employee related functionality was also included in the architecture.
Whereas in R12, the TCA functionality is further extended to incorporate Suppliers, Banks, Bank
Branches, Legal Entities, etc. Additionally, Oracle also built Supplier Life Cycle Management
module, Supplier Data Hub as well as Site Hub products to solve master data challenges for the
Supplier and Site domains. This further made an impact to the TCA Architecture and the
underlying data model as can be seen in the graphic below:

With all these changes, the TCA model in R12 EBS is more robust but also shares the tables
between multiple domains. For example, same party can be used for both Supplier and
Customer records with some caveats in terms of how you can get there. Though party layer of
the TCA is shared between Customer and Supplier, how overall TCA was implemented within
Customer and Supplier domains is quite different. The customer end supports the concept of
multiple customer accounts for a Party where as the Supplier end is hard-wired to support one
supplier account per party.
The TCA model with its complex design also gives way to flexibility in terms of how data can be
modeled in this architecture. Two popular models are Party Centric approach and Site Centric
approach. In a Party centric approach, one party is created for every location of the Customer.
Where as in Site Centric approach, one Party is created for all or some of the locations of the
Trading Community Architecture (TCA)

customers with each location represented as party site in the model. The party centric model is
conducive to data quality whereas the site centric model is conducive for operational ease of use
within Distribution and Financial modules, Order Management and Accounts Receivables for
example. In R12 implementation, how do we balance between these approaches, and how the
model was taken up in each of the modules poses challenges in terms of the implementation.
Party Centric Approach (aka Multiple Party Approach, Best Practices Model)
 is when a Party is created for every single site (location) of the Customer and party
relationships are used to build the corporate hierarchy
 The focus is on creating parties and relating them to each other.
Site Centric Approach (aka Single Party Approach, AR Customer Model, and Legacy Customer
Model)
 is when only one party is created for the Customer and all sites of the customer are
created as party sites of this party
 The focus is on creating multiple sites
Party 1
Account 1
Site 1
Party
Site 1
Party 2
Account 2
Site 2
Party
Site 2
Party 3
Account 3
Site 3
Party
Site 3
Party Centric Model

Most customers follow a model that is somewhere in between.
Company Background
The client is a technology services firm that provides Video Monitoring services starting with the
installation of the equipment at their customer locations and on-going monitoring and optional
back up of the recorded video. They currently use outdated home grown legacy applications that
has grown with customizations over many decades that are extremely complex and time
consuming to maintain. Due to this, they have decided to modernize their IT infrastructure and
implement Oracle E-Business Suite, Siebel as well as SalesForce.com as part of multiple IT
initiatives.
End Customer Scenario
One of the End Customer is a company called “XYZ Technologies” that has offices all across
United States with headquarters in New York. This customer has recently signed a Master
Services Agreement for providing Video Monitoring Services for their office locations. The
installation will occur in stages over a period of few months. Also this customer operates with
centralized payables department and expects to receive a consolidated bill on a monthly basis
addressed to the Payables Department located in their headquarters location of New York.
Decision on having one project Vs multiple projects per End customer/s
In order to meet the needs of our end customer’s business scenario, we considered multiple
approaches including having single project with multiple technologies and multiple customer
sites Vs having multiple projects each representing a customer site and a technology. Each model
had its own advantages and disadvantages in term of billing, reporting, accounting and future
Party
Account
Site 2
Party
Site 2
Party
Site 3
Site 3Site 1
Party
Site 1
Site Centric Model

scalability. After weighing in the benefits a decision is made to use the multiple project model
each tied to a customer and a specific technology. This option did provide scalability, satisfied
accounting and reporting needs. This model also helped capture individual Install and Service
activities tied to a particular technology. Further to that we utilized balance forward billing to
achieve the billing needs.
Customer model consideration
To meet the end customer scenario of having multiple billing sites for each contract, we have
considered using site centric and customer centric models. Even though both the models worked
by means of building customer relationships, site centric model had a limitation in which billing
address couldn’t be changed on the project. Due to this we had to resort to building a party
centric model which offered the flexibility to select multiple bill to addresses one by each task.
The below screenshots depict some of the advantages we had using party centric model in
comparison to site centric model. This is the one of the primary driver towards our selection of
party centric model.
Project created using site centric customer model
Site centric customer defined:

Project created

When tried to select a different bill to address at a task level to meet the business need, following
error occurred. This happened inspite of building customer relationships and enabling project
billing to accept customer relationships.

The following screenshots show how we got through the situation by using a party centric
customer model:
Party 1

Party 2

See below as to how the bill to and ship to sites of different parties can be used on the same
project.

Our decision was to have multiple projects representing multiple customer sites and technologies
which catered to the need of having reporting of Install and service activity by specific
technology of a customer. In conjunction we followed a party centric customer model that still
allowed selection of any site of the related party to satisfy the billing requirements and shipping
requirements
Conclusion:
In this session we have seen how Oracle Projects can be implemented successfully using the
party centric model which is uncommon for many implementations in comparison to a site
centric model. Project Billing has been successfully tested and works using the site centric
model. We have tried this approach for our client and it works but using additional DFF’s and
customizations. Whereas party centric model works without the additional DFF’s and custom
links. Also keeping in mind the benefits that go with a party centric model in terms of SCM and
CRM operations, we have picked a party centric approach.
In services industry, where Service Contracts and Oracle Projects are implemented, we have seen
how to effectively model customers to meet service specific needs as well use Oracle Projects to
effectively bill the Customers.
Detailed description of the scenario and the requirements and the solution process along with
some screenshots is provided below for the benefit of audience

Business Process
The following process flow model and descriptive steps take you through the solution
implemented at a high level after making decisions as explained in the previous section.
Solution Design – High Level
1. Configure Customers using Party centric model - TCA
2. Configure One Project per technology (using Party Centric Customer) to include
Installation and Service Tasks. - Project Billing
3. Configure Service Contracts and service lines and associate Projects and Tasks to service
lines – Service Contracts
4. Design Interface between Service Contracts and Projects/Tasks to move the Service
Revenue and Billing - Service Contracts, Project Billing
5. Interface Project Billing to Accounts Receivable including Customer Party, Site, Task -
Project Billing, Accounts Receivable

6. Utilize Balance forward billing and BPA to consolidate billing by Customer (Multiple
Projects by Technology), Task (Installation, Services), Customer (Multiple Parties –
Multiple Tasks) - Accounts Receivable, BPA
Step-By-Step User Process

1. Following the TCA approach described above, we have defined a party centric customer. Some screenshots to follow:

2. Once Customer is defined, Sales would book an order. The sales orders would then be converted into Contract
projects. While creating the project, customers would be associated to Project level and bill to and ship to sites associated
as needed at the site level.

3. Service contracts are created. At the Service contract level Project is associated as well at the line level Project and Task
information is associated. This is to help build the integration between Service Contracts and Projects.

4. Projects will then generate invoices for Installation activities utilizing Projects Billing functionality and will also inherit the
Service Invoices from the Service Contracts module. These service invoices are based on recurring service agreement
arrangements. Since the service lines are associated to Projects and Tasks, the integration could be built.

5. Projects will interface the draft invoices to accounts receivable for consolidation and final billing to the customer.

6. Accounts Receivable will further massage the data inputs from Projects and creates consolidated bills according to business
requirements. Sample balance forward bill attached below.

Web sites
OAUG MDM SIG http://groups.yahoo.com/group/cdmsig
http://cdmsig.oaug.org
UCM SIG http://groups.yahoo.com/group/ucmsig
Rhapsody Technologies, Inc. http://www.rhaptech.com
RJT Compuquest, Inc. http://rjtcompuquest.com
Check for Latest Version of this http://www.rhaptech.com/resources.html for this
Presentation as well as other presentations

About the Author
Kalyan Pantina is an accomplished lead/manager, solutions architect, SME and business analyst
professional with over 15 years of experience in multiple industries. Kalyan is a certified Oracle
functional professional and has Oracle EBS Projects Suite (R12 & 11i), Oracle EBS Financials
(R12 and 11i), Oracle Fusion/ Cloud Projects Portfolio Management R7, 8, 9, 10, 11.

Mani Kumar Manda is founder of Rhapsody Technologies, Inc. and founder/coordinator for
OAUG Master Data Management Special Interest Group (OAUG MDM SIG). Mani has been a
consultant for his entire career to mid-market and large customers and has been a recognized
Expert and Speaker in the areas of MDM and ERP/CRM with numerous presentations at OAUG,
Open World, MDM Summit and several local GEO and SIG groups. Mani has developed a
Methodology known as “RHYTHM” that significantly increases the “success factor” for any
MDM implementations.
About Rhapsody Technologies, Inc.
Rhapsody Technologies, a nationally recognized firm and a trusted advisor in implementing
enterprise wide solutions such as:
 Master Data Management (MDM) for domains such as Customer, Supplier, Product,
Location and Chart of Accounts,
 ERP and CRM Applications
 Fusion Applications
Rhapsody’s proprietary “RHYTHM” methodology supplements traditional SDLC methodologies
(such as AIM). Rhapsody also has a holistic training program on Customer Data Management
functional fundamentals for Oracle CDH and recently launched “Oracle DQM Search
Optimization”, “Oracle TCA Functional Support” services to help users’ better leverage the TCA
framework. These proven technologies have helped Rhapsody excel in guiding Clients in MDM
technologies from conception to operationalization. Rhapsody has helped clients in many
industries in implementing, re-architecting MDM, ERP and CRM solutions that enhance and
optimize the organizational operations. With its extensive community involvement in user
groups such as CDM SIG, NCOAUG, OAUG, Open World, etc., Rhapsody educates the users in
MDM, CDI, ERP and CRM technologies with a focus on Oracle eBusiness Suite/Oracle MDM
implementations.
Acknowledgments
Many thanks go to my Asha Manda for reviewing this white paper and providing valuable
suggestions that had certainly enhanced the quality of this document.

Leveraging Oracle Projects for Party and Site Centric Customer Billing

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to Leveraging Oracle Projects for Party and Site Centric Customer Billing

Similar to Leveraging Oracle Projects for Party and Site Centric Customer Billing (20)

More from Project Control | PROJ CTRL

More from Project Control | PROJ CTRL (8)

Recently uploaded

Recently uploaded (20)

Leveraging Oracle Projects for Party and Site Centric Customer Billing