1. Collecting General Ledger Data
  2. General Ledger Configuration Options

5 General Ledger Configuration Options

Learn how to configure how the Oracle Communications Billing and Revenue Management (BRM) server runs and exports general ledger (G/L) data.

Topics in this document:

Disabling G/L Collection in BRM

You can disable G/L collection to improve system performance. When G/L collection is disabled, /journal objects are not created.

To disable G/L collection:

  1. Go to the BRM_home/sys/data/config directory.

  2. Create the bus_params_billing.xml file: 

    pin_bus_params -r BusParamsBilling bus_params_billing.xml

  3. Disable the GeneralLedgerReporting entry: 

    <GeneralLedgerReporting>disabled</GeneralLedgerReporting>

  4. Save the file.

  5. Load the bus_params_billing.xml file into BRM: 

    pin_bus_params bus_params_billing.xml

  6. Stop and restart the CM.

For more information, see "pin_bus_params" in BRM Developer's Guide.

Disabling Creation of /journal Objects for Noncurrency Balance Impacts

To improve system performance, you can disable creating /journal objects for noncurrency balance impacts. To do so, run the pin_bus_params utility to change the NonCurrencyResourceJournaling business parameter. For more information, see "pin_bus_params" in BRM Developer's Guide.

To disable the creation of /journal objects for noncurrency balance impacts:

  1. Go to the BRM_home/sys/data/config directory.

  2. Create the bus_params_billing.xml file: 

    pin_bus_params -r BusParamsBilling bus_params_billing.xml

  3. In the NonCurrencyResourceJournaling entry, do one of the following:

    • To disable creation of all /journal objects for noncurrency balance impacts, enter none: 

      <NonCurrencyResourceJournaling>none</NonCurrencyResourceJournaling>

    • To create /journal objects for specific noncurrency balance impacts, use this format: 

      <NonCurrencyResourceJournaling>+:balance_element_ID,balance_element_ID,...</NonCurrencyResourceJournaling>

      Spaces are not allowed. For example:

      <NonCurrencyResourceJournaling>+:23466,199990,200000</NonCurrencyResourceJournaling>

    • To create /journal objects for all except specific noncurrency balance impacts, use this format: 

      <NonCurrencyResourceJournaling>-:balance_element_ID,balance_element_ID,...</NonCurrencyResourceJournaling>

      Spaces are not allowed. For example:

      <NonCurrencyResourceJournaling>-:458745,190000,2000444,77778</NonCurrencyResourceJournaling>

      Caution:

      If a balance element ID is not valid, the default value all is used.

  4. Save the file.

  5. Load the bus_params_billing.xml file into BRM: 

    pin_bus_params bus_params_billing.xml

  6. Stop and restart the CM.

Setting the Number of Paying Accounts per G/L Report

To make generating G/L reports more scalable, you can specify the number of paying accounts to include in a G/L report.

To change the default number of paying accounts included in a G/L report:

  1. Open the BRM_home/apps/pin_billd file in a text editor.

  2. Edit the following entry:

    pin_ledger_report transaction_grouping 100000

  3. Save and close the file.

Generating G/L Reports Based on the Actual Billing Date

Note:

This configuration applies for event-based revenue recognition and individual G/L reports only.

Billing can be run on a date past when the billing cycle ended. For example, if a billing cycle ends on February 2, billing might be run on February 3. By default, BRM uses the end of the billing cycle as the date on which G/L reports are based. You can configure BRM to base G/L reports on the date that billing was run instead.

Caution:

  • To avoid discrepancies after enabling the use of the actual billing date, make sure, when running the G/L reports for the first time, that the G/L reporting period includes both the end date of the bill period and the actual billing date.

  • For accounts with skipped billing cycles, the revenue reported as billed in a previous G/L report period may again be reported as billed in a new G/L report period. To avoid this discrepancy, before you enable the use of the actual billing date, make sure of the following:

    • There are no subordinate accounts with skipped billing cycles.

    • The G/L reports for the subordinate accounts with skipped billing cycles have already been generated for a period past the billing date of the paying account.

  • After enabling the use of the actual billing date, do not disable it.

To use the actual billing date when generating G/L reports, configure the BRM database by using SQL. Specifically, create a view on the ITEM_T table and re-create the item_t_synonym synonym on the view on the ITEM_T table to enable the use of the actual billing date.

Note:

In a multischema system, run these steps for each schema.

  1. Open SQL*Plus: 

    sqlplus login/@database_alias
Enter password: password

    where:

    • login is the login name to use for connecting to the BRM database.

    • database_alias is the BRM database alias.

    • password is the encrypted password for login.

  2. Create the i_item_glseg_eff__id index on the gl_segment and opened_t columns of the ITEM_T table: 

    SQL>CREATE INDEX i_item_glseg_eff__id ON item_t (gl_segment, opened_t) tablespace tablespace_name storage_clause;

    where:

    • tablespace_name is the tablespace name where you want to create the index.

    • storage_clause specifies the storage parameters to use when you create the index; for example, storage (initial 30k next 30k maxextents unlimited pctincrease 0 freelists 2).

  3. Create the item_t_gl_view view on the ITEM_T table with all of the columns in the ITEM_T table, with the exception of the effective_t column of the view pointing to the opened_t column of the ITEM_T table.

    For example:

    SQL> CREATE OR REPLACE VIEW item_t_gl_view
AS SELECT POID_ID0, ACCOUNT_OBJ_DB, ACCOUNT_OBJ_ID0, ACCOUNT_OBJ_REV,
ACCOUNT_OBJ_TYPE,  ADJUSTED, ARCHIVE_STATUS,AR_BILLINFO_OBJ_DB,
AR_BILLINFO_OBJ_ID0,AR_BILLINFO_OBJ_REV,AR_BILLINFO_OBJ_TYPE,
AR_BILL_OBJ_DB,AR_BILL_OBJ_ID0,AR_BILL_OBJ_REV,AR_BILL_OBJ_TYPE,
BAL_GRP_OBJ_DB,BAL_GRP_OBJ_ID0,BAL_GRP_OBJ_REV,BAL_GRP_OBJ_TYPE,
BILLINFO_OBJ_DB,BILLINFO_OBJ_ID0,BILLINFO_OBJ_REV,BILLINFO_OBJ_TYPE,
BILL_OBJ_DB,BILL_OBJ_ID0,BILL_OBJ_REV,BILL_OBJ_TYPE,CLOSED_T,CREATED_T,
CURRENCY, CURRENCY_OPERATOR,CURRENCY_RATE,CURRENCY_SECONDARY,
DELTA_DUE,DISPUTED,DUE,DUE_T, OPENED_T "EFFECTIVE_T",EVENT_POID_LIST,   
FLAGS, GL_SEGMENT, ITEM_NO,ITEM_TOTAL, MOD_T, NAME, OPENED_T, POID_DB,
POID_REV, POID_TYPE, READ_ACCESS, RECVD,SERVICE_OBJ_DB, SERVICE_OBJ_ID0,
SERVICE_OBJ_REV, SERVICE_OBJ_TYPE, STATUS, TRANSFERED, WRITEOFF, 
WRITE_ACCESS FROM item_t;

  4. Create the item_t_synonym synonym on the item_t_gl_view view on the ITEM_T table: 

    SQL>CREATE OR REPLACE SYNONYM item_t_synonym FOR item_t_gl_view;

  5. Recompile the invalid objects:

    SQL>exec dbms_utility.compile_schema(USER,false);

  6. Reset the value of OPENED_T of the previously billed items for G/L reports.

  7. Exit SQL*Plus.

Segregating Unbilled Revenue by G/L Cycle within a Billing Cycle

Note:

This configuration applies for event-based revenue recognition and individual G/L reports only.

By default, the G/L report for unbilled revenue considers the time the journal was created to determine if the revenue was unbilled until the end of the G/L cycle. Because revenue for the same item across multiple ledger cycles is aggregated on the same journal entry, the G/L report shows the unbilled revenue as follows:

  • If there is a delay in loading the usage events across multiple ledger reporting cycles, the journal entry for these usage events is created in the new G/L cycle. The unbilled revenue report for the prior G/L cycle does not include these usage events. If an item is created in the prior G/L cycle and a usage event for that item occurs in the current G/L cycle, the usage revenue is considered as part of the prior G/L cycle. The unbilled revenue report for the prior G/L cycle includes this usage event.

You can configure BRM to segregate revenue for the same item across multiple G/L cycles by creating a separate journal entry for each of these G/L cycles for this item. This ensures the following:

  • If there is a delay in loading the usage events across multiple ledger reporting cycles, the journal entry for these usage events is created in the G/L cycle the event occurred in. The unbilled revenue report for the prior G/L cycle includes these usage events.

  • If an item is created in the prior G/L cycle and a usage event for that item occurs in the current G/L cycle, the usage revenue is considered as part of the current G/L cycle. The unbilled revenue report for the prior G/L cycle does not include this usage event.

Note:

Segregating unbilled revenue increases the number of /journal objects in the BRM system.

BRM makes the journal effective in the G/L cycle in which the event's endtime falls. In the case of delayed and backdated events that are processed after billing or after G/L posting, the event processing determines the G/L period the journal belongs to.

To segregate the unbilled revenue report for G/L cycle:

  1. Go to BRM_home/sys/data/config.

  2. Create the XML file:

    pin_bus_params -r BusParamsBilling bus_params_billing.xml

  3. Enable the SegregateJournalsByGLPeriod entry. 

    <SegregateJournalsByGLPeriod>enabled</SegregateJournalsByGLPeriod>

  4. Save the file.

  5. Load the file:

    pin_bus_params bus_params_billing.xml

  6. Stop and restart the CM.

Note:

When the SegregateJournalsByGLPeriod business parameter is enabled:

  • BRM assumes that a single G/L reporting cycle is used for all G/L segments in the system.

  • The future journals will be created based on the G/L calendar but existing journals will remain same.

  • If the existing G/L cycle start dates are modified in the /config/gl_calendar object, future journal creation will be based on the new calendar. However, the previously created journals will remain unchanged and do not reflect the new calendar.

Setting Up G/L Calendar Configuration

When you segregate unbilled revenue by G/L Cycle within a billing cycle, BRM uses the /config/gl_calendar object to get information related to the G/L reporting cycle.

This configuration includes an array of timestamps that indicates the start dates of the G/L cycle. For example, if the G/L reporting cycle starts on the third of every month, the configuration contains 12 timestamps for each year, each indicating the third day of the month.

Note:

Ensure that the current G/L cycle start date is part of this configuration. The timestamps must match the appropriate time zone of the BRM server.

To load data for the unbilled earned revenue report, manually configure the /config/gl_calendar object by using the PCM_OP_CREATE_OBJ opcode. See "Creating Objects" in BRM Developer's Guide.

Following is a sample flist to populate monthly G/L cycle start timestamps for three months in the US Pacific time zone.

0    PIN_FLD_POID                POID [0] 0.0.0.1 /config/gl_calendar -1 0
0     PIN_FLD_ACCOUNT_OBJ           POID [0] 0.0.0.1 /account 1 0
0     PIN_FLD_HOSTNAME          STR [0] "<any hostname>"
0     PIN_FLD_NAME             STR [0] "GL_CALENDAR"
0     PIN_FLD_PROGRAM_NAME          STR [0] "<any program name>"
0 PIN_FLD_CALENDAR_DATE             ARRAY [1] allocated 1, used 1
1 	 PIN_FLD_EFFECTIVE_START_T               TSTAMP [0] (1420099200) 01/01/2015 00:00:00:000 AM
0 PIN_FLD_CALENDAR_DATE           ARRAY [2] allocated 1, used 1
1  PIN_FLD_EFFECTIVE_START_T          TSTAMP [0] (1422777600) 01/02/2015 00:00:00:000 AM
0 PIN_FLD_CALENDAR_DATE             ARRAY [3] allocated 1, used 1
1  PIN_FLD_EFFECTIVE_START_T          TSTAMP [0] (1425196800) 01/03/2015 00:00:00:000 AM

After loading, read the configuration object with the testnap utility or Object Browser to verify that all fields are correct.

Note:

If you want to modify the /config/gl_calendar object, delete the existing object using the PCM_OP_DELETE_OBJ opcode and reload it using the PCM_OP_CREATE_OBJ opcode. See "Deleting Objects" in BRM Developer's Guide.