Skip Headers
Oracle® Application Integration Architecture Oracle Communications Billing and Revenue Management Integration Pack for Oracle E-Business Suite: Revenue Accounting Implementation Guide
Release 11.1

Part Number E27226-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

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.

Overview of Revenue Management

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

A G/L report generation utility in BRM generates G/L data. You can start this utility manually or automatically.

  1. BRM produces XML-based files that contain a complete and formatted G/L data set based on summary reports.

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

  3. ODI then loads the G/L data into the Oracle General Ledger INTERFACE table.

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

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

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

This integration uses the following XML files:

  • The BRM XML data files are the result of generating the G/L data in BRM.

  • The AIAConfigurationProperties.xml file specifies the Set of Books (SOB) ID (with Oracle E-Business Suite R11.5.10 CU2) or Ledger ID (with Oracle E-Business Suite 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 BRM currency codes to their corresponding Oracle E-Business Suite values.

Key Benefits

This integration offers the following 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.

Participating Applications

Participating applications are:

  • BRM

  • Oracle General Ledger (part of Oracle E-Business Suite Financials)

BRM

BRM 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 Oracle Communications Billing and Revenue Management Concepts.

Oracle General Ledger

For more information, see Oracle General Ledger User's Guide and Oracle General Ledger Implementation Guide.

Revenue Management Business Process Flow

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

Figure 1-1 Revenue Management Business Process Flow

Description of Figure 1-1 follows
Description of "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

BRM

Step 1: Configure and generate G/L data in 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 BRM-generated XML data into the Oracle General Ledger INTERFACE table.

Oracle General Ledger

Step 4: Import journal entries from the INTERFACE table and post them to Oracle General Ledger accounts.


Solution Assumptions and Constraints

This section discusses the solution assumptions and constraints.

Solution Assumptions

The assumptions are:

  • Oracle General Ledger accounts IDs are mapped and configured to BRM G/L accounts.

  • 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.

  • This design addresses revenue, receivables, and liabilities.

  • If you need to use exact Oracle General Ledger account IDs, you must import the Oracle General Ledger chart of accounts into BRM as an implementation solution.

    This implementation is not included ready-to-use.

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

    N can be from tens to hundreds.

  • To address importing nonmonetary journals into Oracle General Ledger (STAT currency), you must create and use a dummy account. This is because the extract from BRM G/L 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 and credit or the converse, depending on the setup, and Oracle General Ledger does not require balanced journals to create journal entries for nonmonetary transactions.

    However, for this integration you must create a balanced journal entry. For example, if you are importing 100 free minutes into Oracle General Ledger, the Billed Earned report extracts a debit and a credit of 100 free minutes. In Oracle General Ledger, you must set up any Oracle General Ledger 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. 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.

  • If the same report is loaded multiple times into the Oracle General Ledge INTERFACE table, it creates the additional accounting (double counting).

    Therefore, if you must reload a report into Oracle General Ledger, you must reverse the original entries created by the first report run and then reload the report.

  • One instance of BRM can publish G/L data to one Oracle General Ledger 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 Oracle General Ledger instance, you must configure the Oracle AIA configuration file per source system and ensure that 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.

  • BRM-generated G/L reports are available in XML format.

  • 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 G/L 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.

  • The time zone handling solution assumes that the BRM server and the Oracle E-Business Suite corporate time zone are set to the same value. The ODI flow that interfaces G/L data from BRM to Oracle General Ledger does not convert time zones.

Solution Constraints

This design assumes that the following statements are true:

  • Multiple BRM instances can contribute to G/L data, but only one target Oracle General Ledger system can exist.

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

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

  • One 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 BRM instances. Therefore, the relationship between a BRM instance and a SOB Id or Ledger Id is many to one.

  • Users must place the 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.

  • 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 ODI InProcess folder.

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