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 BRM_home/sys/data/config.

2. Use the following command to create an editable XML file from the billing instance of the /config/business_params object:

   pin_bus_params -r BusParamsBilling bus_params_billing.xml

   This command creates an XML file named bus_params_billing.xml.out in your current directory. If you do not want this file in your current directory, specify the path as part of the file name.

3. In bus_params_billing.xml.out, set the following entry:

   <NonCurrencyResourceJournaling>value</NonCurrencyResourceJournaling>

   where value is one of the following:

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

   • +:balance_element_ID,balance_element_ID,...: To create /journal objects for specific noncurrency balance impacts

     Spaces are not allowed. For example:

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

   • -:balance_element_ID,balance_element_ID,...: To create /journal objects for all except specific noncurrency balance impacts

     Spaces are not allowed. For example:

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

   • all: To create /journal entries for all noncurrency balance impacts. This is the default.

   Note:

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

   Caution:

   BRM uses the XML in this file to overwrite the existing instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM configuration.

4. Save and exit the file.

5. Rename the bus_params_billing.xml.out file to bus_params_billing.xml.

6. Use the following command to load your changes into the /config/business_params object:

   pin_bus_params bus_params_billing.xml

   You should run this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

7. Read the object with the testnap utility or the Object Browser to verify that all fields are correct.

   For general instructions on using testnap, see "Using the testnap Utility to Test BRM" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects" in BRM Developer's Guide.

8. Stop and restart the CM.

   For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

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.

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.

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.

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

2. Use the following command to create an editable XML file from the billing instance of the /config/business_params object:

   pin_bus_params -r BusParamsBilling bus_params_billing.xml

   This command creates an XML file named bus_params_billing.xml.out in your current directory. If you do not want this file in your current directory, specify the path as part of the file name.

3. In bus_params_billing.xml.out, set SegregateJournalsByGLPeriod to enabled:

   <SegregateJournalsByGLPeriod>enabled</SegregateJournalsByGLPeriod>

   Caution:

   BRM uses the XML in this file to overwrite the existing instance of the /config/business_params object. Use care when updating parameters in the file.

4. Save and exit the file.

5. Rename the bus_params_billing.xml.out file to bus_params_billing.xml.

6. Use the following command to load your changes into the /config/business_params object:

   pin_bus_params bus_params_billing.xml

   You should run this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

7. Read the object with the testnap utility or the Object Browser to verify that all fields are correct.

   For general instructions on using testnap, see "Using the testnap Utility to Test BRM" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects" in BRM Developer's Guide.

8. Stop and restart the CM.

   For more information, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.