1 Understanding the Process Integration for Revenue Management

This chapter provides an overview of the process integration for revenue management and the business process flow. It also discusses the assumptions and constraints for the process integration.

Overview of the Process Integration for Revenue Management

The process integration for revenue management consists of the Revenue Management business flow and is part of the Oracle Communications Billing and Revenue Management Integration Pack for Oracle E-Business Suite: Revenue Accounting.

This process integration lets you use Oracle General Ledger as an accounting engine on top of Oracle Communications Billing and Revenue Management (BRM) by moving general ledger (G/L) data from BRM to Oracle General Ledger.

This process integration 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. Instead, the process integration for revenue management uses Oracle Data Integrator (ODI) to pick up BRM G/L data files and move them to Oracle General Ledger.

About the Revenue Management Business Process Flow

The Revenue Management business process flow moves G/L data from BRM to Oracle General Ledger as follows:

  1. A BRM utility generates G/L reports. The reports are XML files that contain a complete and formatted G/L data set based on summary reports. You can run the utility manually, or schedule it to run automatically.

  2. ODI picks up the reports and transforms them into G/L data according to mapping provided by AIA. AIA maps the G/L XML elements from BRM to the columns in the Oracle General Ledger GL_INTERFACE table. You can configure ODI to pick up the reports automatically when BRM generates them, or according to a schedule.

  3. ODI loads the G/L data into the Oracle General Ledger GL_INTERFACE table. The GL_INTERFACE table is where Journal Import utility receives accounting data imported to Oracle General Ledger from other systems.

  4. In Oracle General Ledger, you run the Journal Import utility. This utility validates the G/L data and converts it into journal entries.

  5. In Oracle General Ledger, you post the journals to accounts.

Figure 1-1 illustrates the Revenue Management business process flow.

Figure 1-1 The Revenue Management Business Process Flow

This figure is described in the surrounding text.

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.

  • Oracle recommends that all reports for a single cycle in the scope of one type of report data be processed before the next cycle.

    This action helps prevent picking up out-of-order reports.

  • This design addresses revenue, receivables, and liabilities.

  • If you need to use exact Oracle General Ledger account IDs, import the Oracle General Ledger chart of accounts into BRM. This implementation is outside the scope of the ready-to-use integration.

  • In the event of a configuration error in the account mapping between BRM and Oracle General Ledger, 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 import nonmonetary journals into Oracle General Ledger (STAT currency), create and use a dummy account. This is because the extraction 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 GL_INTERFACE table, it creates the additional accounting (double counting).

    To avoid double counting when reloading a report into Oracle General Ledger, first 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, configure the Oracle AIA configuration file per source system and ensure that BRM publishes the report with the appropriate source system information.

    You must specify one SOB (with Oracle E-Business Suite R11.5.10 CU2) or one Ledger ID (with Oracle E-Business Suite R12.1.1) for each 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, customize the integration so that each integration process instance targets a separate Oracle General Ledger system. If you use multiple instances for each instance, 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.

  • You must place the BRM-generated XML file in the defined integration folder.

    If any of the processed XML files fail, 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.

    Move this file from the ODI InProcess folder back to the input folder for reprocessing.