1 Understanding the Process Integration for Revenue Management

This chapter provides an overview of the process integration for revenue management and discusses its key benefits, participating applications, and the business process flow.

This chapter includes the following sections:

• Section 1.1, "Revenue Management Overview"

• Section 1.2, "Key Benefits"

• Section 1.3, "Participating Applications"

• Section 1.4, "Revenue Management Business Process Flow"

• Section 1.5, "Solution Assumptions and Constraints"

1.1 Revenue Management Overview

The process integration for revenue management is part of the Oracle Communications Billing and Revenue Management Integration for Oracle E-Business Suite: Revenue Accounting. The process integration for revenue management moves general ledger (GL) data from Oracle Communications Billing and Revenue Management (Oracle BRM) to the Oracle E-Business Suite (Oracle EBS), enabling customers to use Oracle EBS General Ledger (Oracle GL) as an accounting engine on top of the Oracle BRM application.

Oracle BRM is the master for the process integration for revenue management. A GL report generation utility in Oracle BRM, generates GL data. This utility can be started manually or automatically.

1. Oracle BRM produces XML-based files that contain a complete and formatted GL data set based on summary reports.

2. The Oracle Data Integrator (ODI) picks up the reports and transforms them into GL data based on the mapping (provided by the process integration for revenue management) of the GL XML elements to the table columns in the Oracle GL INTERFACE table.

3. ODI then loads the GL data into the Oracle GL INTERFACE table.

   The Oracle GL INTERFACE table is where Journal Import receives accounting data that is imported from other systems into Oracle GL.

4. When Journal Import receives this data, it validates and converts the imported data into journal entries within Oracle GL.

The process integration for revenue management differs from other Oracle Communications integrations in that it does not use Enterprise Business Objects (EBOs) or other standard Oracle Application Integration Architecture (Oracle AIA) objects to complete this integration. Rather, the process integration for revenue management uses ODI to pick up the Oracle BRM GL data files and then move those files to the Oracle GL application.

This integration uses these XML files:

• The Oracle BRM XML data files are the result of generating the GL data in Oracle BRM.

• The AIAConfigurationProperties.xml file specifies the Set of Books (SOB) ID (with Oracle EBS R11.5.10 CU2) or Ledger ID (with Oracle EBS R12.1.1), Exchange Rate Type mappings for this integration, and other parameters required for this integration.

• The CurrencyCodeMapping domain value map (DVM) maps the Oracle BRM currency codes to their corresponding Oracle EBS values.

1.2 Key Benefits

This integration offers these key benefits:

• Strengthens revenue assurance with real-time charging and tighter controls between billing and financial applications.

• Enhances business information from integrated analytics and availability of accurate and consistent billing and financial data.

• Maintains regulatory compliances.

1.3 Participating Applications

Participating applications are:

• Oracle Communications BRM

• Oracle E-Business Suite Financials - General Ledger

1.3.1 Oracle Communications BRM

Revenue management is an end-to-end life cycle of processes for generating, capturing, and collecting revenue for each customer. Revenue management includes the ongoing process of analyzing, evaluating, and optimizing each phase of the life cycle, providing complete insight and intelligence into the revenue relationships that customers have with a service provider. Oracle Communications BRM provides a product-based solution for revenue management. It is built to industry standards on a highly available, real-time platform, and it is functionally rich enough to support all communications and media service provider business processes across all lines of business.

For more information, see the Oracle Communications Billing and Revenue Management (BRM) Documentation.

1.3.2 Oracle E-Business Suite Financials - General Ledger

Oracle GL is a comprehensive financial management solution that provides highly automated financial processing, effective management control, and real-time visibility into financial results. It enables an organization to meet financial compliance and improve its bottom line. Oracle GL is part of the Oracle E-Business Suite.

In today's complex, global, and regulated environment, finance organizations face challenges in trying to obey local regulations and multiple reporting requirements. Oracle GL allows companies to meet these challenges in a streamlined and automated way. They can assign multiple ledgers to a legal entity to meet statutory, corporate, regulatory, and management reporting. They can maintain all accounting representations simultaneously for a single transaction. For example, a single journal entered in the main record-keeping ledger can be automatically represented in multiple ledgers even if each ledger uses a different chart of accounts, calendar, currency, and accounting principle.

Oracle E-Business Suite Release 11.5.10 CU2 uses SOB (Set of Books). Release 12 replaces the SOB with Subledger Accounting (SLA), Ledgers, and Ledger Sets. Important differences exist between SOBs and Ledgers. A SOB is a general ledger with associated subledger books (AR. AP, and so on), and is self-contained regarding management, calendaring, and reporting. In Release 12, the SLA tables provide formal accounting for the subledgers. Ledger is the general data-transactions and balances-for a particular accounting entity. A Ledger Set is where management, calendaring, and GL Reporting live. The new multiple ledger approach keeps the data segmented, similar to a SOB, but unlike the SOB approach allows for processing and reporting across different accounting entities. Therefore, a group with several companies in a country where regulatory compliance demands one ledger for each company can maintain distinct ledgers, but the group can handle them for close, reporting, and adjustment purposes as if they were one.

Ledgers in a Ledger Set must have a common chart of accounts (COA). A COA is defined as a single global COA shared across an enterprise. In addition to sharing a COA, ledgers must share a common calendar to be in a Ledger Set, and different currencies and accounting principles are acceptable. The organization can capture and report on any number of currencies from the balance-level to the subledger-level. Currency conversion, revaluation, re-measurement, and translation are all performed in accordance with local and international accounting standards to improve internal controls and increase efficiency.

For more information, see the Oracle E-Business Suite Financials - General Ledger Guide.

1.4 Revenue Management Business Process Flow

Figure 1-1 illustrates the revenue management business process flow.

Figure 1-1 Revenue Management Business Process Flow

Table 1-1 illustrates the overall process for revenue management.

Table 1-1 Revenue Management: Overall Process

Work Location	Step
Oracle BRM	Step 1: Configure and generate GL data in Oracle BRM.
Integration process	Step 2: The integration process picks up the XML files automatically or based on the schedule you set in ODI. Step 3: Transform Oracle BRM-generated XML data into the Oracle GL interface table.
Oracle GL	Step 4: Import journal entries from the GL interface and then post them to GL accounts.

1.5 Solution Assumptions and Constraints

This section discusses the solution assumptions and constraints.

1.5.1 Solution Assumptions

The assumptions are:

1. Oracle GL accounts IDs are mapped and configured to Oracle BRM GL accounts.

2. In the scope of one type of report data, all reports for a single cycle are expected to be processed before the next cycle.

   This action is recommended to avoid the possibility of picking up out-of-order reports.

3. This design addresses revenue, receivables, and liabilities.

4. If customers are required to use exact Oracle GL account Ids, then they must implement the import of Oracle GL COA into Oracle BRM as an implementation solution.

   This implementation is not included in this release.

5. In the event of a configuration error in the Oracle BRM to Oracle GL account mapping, customers must manually reverse (N segments 7 types of reports = M batches) and regenerate the feeds to Oracle GL.

   N can be from tens to hundreds.

6. To address importing nonmonetary journals into Oracle GL (STAT currency), you must create and use a dummy account. This is because the extract from Oracle BRM GL Reports creates a Debit and Credit pair with the same amount in the Debit and the Credit.

   Nonmonetary items increase or decrease in the debit credit or vice versa, depending on the setup, and Oracle GL does not require balanced journals to create journal entries for nonmonetary transactions.

   However, for this integration you must create a balanced Journal Entry. As an example, let us say you are importing 100 free minutes into GL. The Billed Earned report extracts a Debit and a Credit of 100 free minutes. In Oracle GL, the way to set this up is to set up any GL account for this; one account must not be used for reporting purposes because it does not provide the actual net amount of 100 free minutes. So, let us say that you create account 7100 for the debit and 7200 (dummy account) for the credit with a classification of expense accounts. The net effect is 100 minutes, but the transaction creates a DR 7100 for 100 and Credit 7200 for 100. The reports must exclude account 7200 to report the 100 minutes. If you are required to reduce the amount to 80 free minutes, the corresponding entry is DR 7200 for 20 and CR 7100 for 20.

7. If the same report is loaded multiple times into the Oracle GL_Interface tables, it creates the additional accounting (double counting).

   Therefore, if customers must reload a report into Oracle GL, they must reverse the original entries created by the first report run and then reload the report.

8. One instance of Oracle BRM can publish GL data to one Oracle E-Business Suite GL instance.

   To target multiple SOB (with Oracle E-Business Suite R11.5.10 CU2) or Ledgers (with Oracle E-Business Suite R12.1.1) within a single GL instance, you must configure the Oracle AIA configuration file per source system and ensure that Oracle BRM publishes the report with the appropriate source system information.

   The user must specify a SOB (with Oracle E-Business Suite R11.5.10 CU2) or a Ledger ID (with Oracle E-Business Suite R12.1.1) per source system.

9. Oracle BRM-generated GL reports are available in XML format.

10. Oracle BRM report output values for the four types of revenue accounts within a given GLID are Gross, Net, Discount, and Tax.

    Choosing to use Gross, Net, or both is specific to the implementation. Implementations can also choose to ignore certain revenue account types even if valid GL accounts are populated. Therefore, the implementation must list in the integration layer all of the account types that must be ignored so that the process does not produce an error condition for those account types.

11. The time zone handling solution assumes that the Oracle BRM server and the Oracle Ebiz corporate time zone are set to the same value. The ODI flow that interfaces GL data from Oracle BRM to Oracle EBS GL does no time zone conversions.

1.5.2 Solution Constraints

This design assumes that the following statements are true:

1. Multiple Oracle BRM instances can contribute to GL data, but only one target GL system can exist.

   Each XML file generated by any Oracle BRM instance can go to only one Oracle GL system. To support multiple Oracle GL systems, you must customize the integration so that each integration process instance targets a separate Oracle GL system. If you use multiple instances for each instance, then you must add a Source SystemID in the configuration file.

2. The Oracle BRM-generated XML file contains the Source SystemID from which it is generated.

3. One Oracle BRM instance publishes data to one SOB Id (with Oracle E-Business Suite R11.5.10 CU2) or to one Ledger Id (with Oracle E-Business Suite R12.1.1).

   The same SOB Id or Ledger Id can be used by multiple Oracle BRM instances. Therefore, the relationship between an Oracle BRM instance and a SOB Id or Ledger Id is many to one.

4. Users must place the Oracle BRM-generated XML file in the defined integration folder.

   If any of the processed XML files fail, users must manually place those files in the process folder for reprocessing after making the necessary corrections.

5. If the agent stops in the middle of processing of a file, and if that file is not in the success or the failure folder, then it is in the ODIInProcess folder.

   Users must manually move this file from the ODIInProcess folder back to the input folder for reprocessing.