3 Setting Business Policies for Billing

This chapter describes how to configure Oracle Communications Billing and Revenue Management (BRM) billing and set up system-wide billing defaults (for example, the default billing-cycle length).

Before configuring billing, read "About Billing".

This chapter does not cover information on increasing billing performance, such as running multiple billing processes. For information on increasing billing performance, see "Tuning Billing Performance" in BRM System Administrator's Guide.

Note:

Many billing defaults are set by editing configuration files.

For information on setting defaults for invoicing, see "Setting Invoicing Defaults" in BRM Designing and Generating Invoices.

Setting Default Billing Properties for Account Creation

You can change the defaults for the following billing properties for new accounts:

• Setting the Default Accounting Day of Month (DOM)

• Setting the Default Billing-Cycle Length

• Setting the Default Accounting Type

• Setting the Billing DOM According to the Payment Method

• Setting the First Billing Cycle to the Day after Account Creation

For information about setting default invoicing properties, see "Setting Invoicing Defaults" in BRM Designing and Generating Invoices.

Setting the Default Accounting Day of Month (DOM)

Tip:

It is a good idea to leave the accounting DOM set to the date the account was created. This distributes the load for the billing utilities throughout the month.

For information about the accounting DOM, see "About Accounting Cycle Dates".

To set the default accounting DOM:

1. Open the Connection Manager (CM) configuration file (BRM_Home/sys/cm/pin.conf) in a text editor. BRM_Home is the directory where you installed BRM components.

2. Uncomment the following line and enter a value from 1 to 28.

   - fm_cust_pol actg_dom 28
   

   Note:

   To use the day that the account was created as the default, comment out the line by using the pound (#) symbol.

3. Save and close the file.

The new value becomes effective immediately and applies to the next account created. You do not need to restart the CM to enable this entry.

Setting the Default Billing-Cycle Length

For information about billing-cycle length, see "About Billing Cycles".

Note:

If you create a consumer account through Customer Center, the value of the PIN_FLD_BILL_WHEN field is always set to 1. If you create a business account through Customer Center, you can configure the value of the PIN_FLD_BILL_WHEN field. If the input flist of the PCM_OP_CUST_COMMIT_CUSTOMER opcode does not have any value defined for PIN_FLD_BILL_WHEN field, the value specified in the CM pin.conf file's - fm_cust_pol bill_when entry is considered.

To set the default billing-cycle length:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Add the following line and enter the number of months in one billing cycle.

   Note:

   The default is 1, which is monthly billing.

   - fm_cust_pol bill_when 2
   

3. Save and close the file.

The new value becomes effective immediately and applies to the next account created. You do not need to restart the CM to enable this entry.

Setting the Default Accounting Type

You set the default accounting type for all bill units by using the CM pin.conf file.

For information about accounting types, see "About Accounting Types".

To set the default accounting type:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Add the following line:

   - fm_cust_pol actg_type n
   

   • To set the default accounting type to open item accounting, enter 1.

   • To set the default accounting type to balance forward accounting, enter 2. This is the default.

3. Save and close the file.

The new value becomes effective immediately and applies to the next account created. You do not need to restart the CM to enable this entry.

Setting the Billing DOM According to the Payment Method

You can set the billing DOM for new customers according to the payment method. For example, you can set up all accounts that pay for bills using the invoice payment method to be billed for those bills on the same day. To do this, customize the PCM_OP_CUST_POL_PREP_BILLINFO policy opcode. Also, use event notification to implement your customization when existing customers change payment methods.

For more information, see "Preparing /billinfo Data".

Setting the First Billing Cycle to the Day after Account Creation

Normally, an account is billed after one month on the day on which the account is created. For example, if an account is created on January 10, the account is billed on February 10, then on March 10, April 10, and so on. However, you can set the first billing date to be the day after account creation. For example, if an account is created on December 16, the account is billed on December 17. After the first billing run, all remaining bills for the account are generated normally. In this example, the account is billed on January 17, February 17, and so on. This option is called advance billing cycle.

To set the first billing cycle to the day after account creation:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Add the following line and set the value to 1.

   - fm_bill advance_bill_cycle 1
   

   Note:

   To set the first billing cycle to one month after the account is created, comment out the line by using the pound (#) symbol.

3. Save and close the file.

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

Setting the Bill Unit Status When Billing Errors Occur

When the billing utility (pin_bill_accts) encounters an error while generating a bill for a bill unit (/billinfo object), the utility sets the billing status of the bill unit to PIN_BILL_ERROR. Bill units with an error status are not selected when billing is run.

Important:

When billing fails for a subordinate account, the status of the subordinate /billinfo object and of the parent account's /billinfo object are both set to PIN_BILL_ERROR. This status ensures that when billing fails for a subordinate account, the parent account is also not billed. Otherwise, the parent bill may not include charges from the subordinate account, resulting in incorrect billing.

After you have resolved the billing errors, you can rerun billing for the failed bill units by running the billing utility with the -retry option. See "pin_bill_accts".

To set the bill unit status when billing errors occur:

1. Open the billing utility configuration file (BRM_Home/apps/pin_billd/pin.conf) in a text editor.

2. Add the following line and enter the appropriate value:

   - pin_bill_accts unset_error_status 1
   

   • 0 sets the billing status in the /billinfo object. This is the default.

   • 1 does not set the billing status in the /billinfo object.

3. Save and close the file.

4. Run the billing utility.

Specifying the Minimum Payment to Collect

You can specify the minimum payment for billing. The pin_collect billing utility retrieves only those account bill units with an amount due greater than the minimum you specify.

The minimum value is expressed in terms of the account currency.

By default, the minimum amount is 2. When the amount due is less than 2, charges accrue in the account balances associated with the bill unit until they reach the minimum amount, and then the amount due is collected.

1. Open the billing utility configuration file (BRM_Home/apps/pin_billd/pin.conf) in a text editor.

2. Change the value of the minimum entry.

3. Save and close the file.

Setting the Minimum Amount to Charge

You set the default minimum amount to charge a customer in the CM pin.conf file minimum_payment entry. To check a batch of charges and refunds for any amounts below the minimum before charging and refunding customers, use the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode. The PIN_FLD_SESSION_OBJ field in the input flist references the type of session in which the event occurred: either /event/billing/batch/refund or /event/billing/batch/payment, depending on the batch type.

Note:

Ensure that the minimum credit card charge does not conflict with the minimum amount to collect.

Before performing the charges and refunds, the PCM_OP_PYMT_COLLECT opcode allocates the PIN_FLD_CHARGE array elements to open items and then calls the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.

The PCM_OP_PYMT_POL_PRE_COLLECT policy opcode then checks each element of the input PIN_FLD_CHARGES array to ensure:

• The result of selecting open items for allocating charges is set to PIN_SELECT_RESULT_PASS.

• The amount charged is greater than or equal to the minimum payment amount.

• The amount refunded is greater than or equal to the minimum and the account has a negative balance.

• The value of the input PIN_FLD_COMMAND field is valid.

By default, the results can be the following:

• If the amount charged is less than the minimum amount, the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode sets the PIN_FLD_DESCR field to ”Below minimum” and the result to PIN_CHARGE_RES_FAIL_NO_MIN.

• If the amount refunded is less than the minimum amount, the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode sets the PIN_FLD_DESCR field to ”Below minimum” and the result to PIN_CHARGE_RES_FAIL_NO_MIN.

• If PIN_FLD_COMMAND is set to PIN_CHARGE_CMD_REFUND and the account balance is zero or higher, the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode sets the PIN_FLD_DESCR field to ”No credit available” and the result to PIN_CHARGE_RES_NO_CREDIT_BALANCE.

You can change the minimum credit card charge amount by modifying the default minimum payment amount in the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.

You can also set minimums in configuration files:

• For information on setting the minimum charge amount, see "Specifying the Minimum Payment to Collect".

• For information on setting the minimum refund amount, see "Specifying the Minimum Amount to Refund".

You can also customize the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode to retrieve soft descriptor information that enables you to display the name under which you do business (your DBA name), product name, and customer service number on your customer's checking account or credit card statement. See the discussion on customizing the policy source file for soft descriptors in BRM Designing and Generating Invoices.

Setting the Minimum Amount for Invoices

There is no BRM configuration entry to set the minimum charge for accounts that pay their bills using the invoice payment method.

Setting the Minimum Amount for Finalizing Bills

At the end of a billing cycle, BRM can automatically suppress bills whose balance is less than a user-specified minimum required to finalize a bill. Such bills are suppressed for one billing cycle. If their balance is still below the minimum at the end of that cycle, they are suppressed for another billing cycle. For more information, see "About Automatic Bill Suppression".

Specifying the Minimum Amount to Refund

You can specify the minimum amount to give as a refund. The pin_refund billing utility processes refund items with an amount greater than the minimum you specify.

The minimum value is expressed in terms of the account currency.

By default, the minimum amount is 2. If the minimum amount is not reached, you can use Customer Center to transfer the amount to another item. For information, see the discussion managing A/R in the Customer Center Help.

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the value of the minimum_refund entry. For example, to process refund items only for amounts greater than 3:

   - fm_pymt_pol minimum_refund 3
   

3. Save and close the file.

You do not need to restart the CM to enable this entry.

Defining Non-refundable Items

By default, only refund items are nonrefundable.

You can make other credit items nonrefundable by modifying the ar parameter instance in the /config/business_params object. The PIN_FLD_PARAM_VALUE field contains a comma-delimited list of items to be excluded.

Important:

Do not remove /item/refund from the PIN_FLD_PARAM_VALUE string.

You modify the /config/business_params object by using the pin_bus_params utility. See "pin_bus_params" in BRM System Administrator's Guide.

To set an item as nonrefundable:

1. Use the following command to create an editable XML file from the ar parameter instance in the /config/business_params object:

   pin_bus_params -r BusParamsAR bus_params_AR.xml  
   

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

2. Search the XML file for following line:

   <NonrefundableCreditItems>/item/refund</NonrefundableCreditItems>
   

3. Add the nonrefundable /item objects after the /item/refund entry, separated by commas.

   Important:

   Do not remove /item/refund from the PIN_FLD_PARAM_VALUE string.

   Caution:

   BRM uses the XML in this file to overwrite the existing ar 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 BRM's billing configuration.

4. Use the following command to load the change into the /config/business_params object:

   pin_bus_params bus_params_AR.xml  
   

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

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

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

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

7. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Managing Cycles

You can customize how to handle billing cycles and cycle fees. See the following topics:

• About Time-Stamp Rounding

• Specifying How to Handle Partial Accounting Cycles

• Aligning Account and Cycle Start and End Times

• Specifying Which Billing Cycle to Assign to Deferred Purchase Fees

• About Billing Cycle Forward Fees in Advance

• About Applying Cycle Forward Fees in Parallel

• About Flexible Cycles

• Calculating Product Cycle Fees for Backdating

• About Bill Cycle Management

About Time-Stamp Rounding

By default, BRM rounds time stamps to midnight. You can configure BRM to use exact time stamps by changing the timestamp_rounding entry in the CM configuration file (BRM_Home/sys/cm/pin.conf) from 1 (enabled) to 0 (disabled). You might need to do that to support a custom application.

The following features are affected by time-stamp rounding. Before disabling time-stamp rounding, consider how that change might impact these features:

• Billing cutoff time. To use a billing cutoff time other than the default, time-stamp rounding must be enabled. Changing the cutoff time also changes the time to which time stamps are rounded throughout BRM. See "Configuring the Billing Cutoff Time" and "How TimeStamp Fields Are Affected by Changing the Cutoff Time."

• Unit interval used to calculate prorated cycle fees. If time-stamp rounding is enabled, the unit interval is calculated in days because time stamps are rounded to midnight. If time-stamp rounding is disabled, the unit interval is calculated in seconds, and proration begins from the time indicated by the time stamp. See "Calculating the Unit Interval."

• Validity period start time of resources granted by cycle events. Use the CM time-stamp rounding entry to specify whether this time stamp is rounded. See "Configuring Time-Stamp Rounding for Cycle Grants" in BRM Setting Up Pricing and Rating.

• Validity period start time of resources granted by purchase events. Use the CM time-stamp rounding entry and a business parameter to specify whether this time stamp is rounded. See "Configuring Time-Stamp Rounding for Purchase Grants" in BRM Setting Up Pricing and Rating.

Specifying How to Handle Partial Accounting Cycles

When you change the accounting cycle date in the middle of an accounting cycle, the new date does not take effect until after the current accounting cycle is over. This results in a gap of time between the end of the old accounting cycle and the start of the new accounting cycle.

For example, for a 30-day month, if the current accounting cycle ends on the 15th and the new cycle starts on the 1st, there is a gap of 15 days between the end of the old cycle and the start of the new cycle. By default, the BRM system treats those 15 days as a short, but complete accounting cycle. At the end of that short cycle, the accounting cycle resumes its normal monthly cycle. A timeline for this scenario is displayed in Figure 3-1.

Figure 3-1 Short Accounting Cycle

Description of ''Figure 3-1 Short Accounting Cycle''

If the short cycle is less than 15 days, a long cycle is created instead. In that case, the extra days are added to the next one-month accounting cycle. This results in a long cycle with the start date of the old cycle and the end date of the new cycle as seen in Figure 3-2.

Figure 3-2 Long Accounting Cycle

Description of ''Figure 3-2 Long Accounting Cycle''

Monthly charges are prorated for accounting cycles less than or greater than one month.

Short and Long Cycles with New Accounts

A short or long cycle can also occur when a customer registers and the billing DOM is different from the day of month when they register. For example, your company might require that all customers be billed on the first day of the month. If a customer registers on January 26, by default the first bill is created on March 1. To bill the customer on February 1, you must change the default partial billing cycle to short.

How BRM Calculates Long Billing Cycles

By default, BRM uses the following formula to calculate long billing cycles:

Use a short cycle unless one of the following is true:

• Future billing day of month > current billing day of month

  AND

  (Future billing day of month - current billing day of month) < 15

• Future billing day of month < current billing day of month

  AND

  (Current billing day of month - future billing day of month) > 15

Examples:

• The following example is shown in Figure 3-3. If the current billing DOM is 1 and the future billing DOM is 10:

  10 > 1

  10 - 1 = 9

  Use a long cycle.

  Figure 3-3 Long Cycle Example 1

  
  Description of ''Figure 3-3 Long Cycle Example 1''
  
  

• The following example is shown in Figure 3-4. If the current billing DOM is 1 and the future billing DOM is 20:

  20 > 1

  20 - 1 = 19

  Use a short cycle.

  Figure 3-4 Short Cycle Example 1

  
  Description of ''Figure 3-4 Short Cycle Example 1''
  
  

• The following example is shown in Figure 3-5. If the current billing DOM is 10 and the future billing DOM is 1:

  1 < 10

  10 - 1 = 9

  Use a short cycle.

  Figure 3-5 Short Cycle Example 2

  
  Description of ''Figure 3-5 Short Cycle Example 2''
  
  

• The following example is shown in Figure 3-6. If the current billing DOM is 20 and the future billing DOM is 1:

  1 < 20

  20 - 1 = 19

  Use a long cycle.

  Figure 3-6 Long Cycle Example 2

  
  Description of ''Figure 3-6 Long Cycle Example 2''
  
  

Rounding Up Long Billing Cycles

You can configure BRM to round up a long cycle so that the scale for the long cycle equals 2. This enables you to charge your customers for two full cycles.

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the value of the following entry to 1:

   - fm_rate rating_longcycle_roundup_flag  1
   

3. Set the value of rounding precision to 0:

   - fm_rate rating_quantity_rounding_scale 0
   

4. Save and close the file.

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

Changing How to Handle Partial Billing Cycles

To change how BRM handles short and long cycles, customize the PCM_OP_CUST_POL_PREP_BILLINFO policy opcode source code.

Aligning Account and Cycle Start and End Times

You can align the product purchase, cycle, and usage start and end times to the accounting cycle, but only if the following are true:

• You configure delayed purchase, cycle, or usage start and end times when you set up your price list in Pricing Center or when you create an account in Customer Center.

  For information, see "Managing Products" in BRM Managing Customers.

• The delayed start and end time is a whole number, not a fraction.

• The delay is measured in cycles.

• The product purchase, cycle, or usage start and end times are not modified when a deal is purchased.

To align the purchase, cycle, and usage start and end times with the accounting cycle:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the value of the cycle_delay_align entry to 1.

   Note:

   If the entry is set to 0 or not present, the start and end times are not aligned.

3. Save and close the file.

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

The delayed purchase, cycle, or usage start time is set to the accounting cycle start date.

For example, if you create a customer account on May 5 and the accounting cycle is monthly, the billing DOM is set to the 5th of each month by default. If you configured the cycle start delay for 1 cycle, the customer purchases a deal on May 20, and the accounting cycle is short, the charges begin on June 5. If the accounting cycle is long, the charges begin on July 5.

Figure 3-7 shows the cycle start time for the above example:

Figure 3-7 Aligning Account and Cycle Start and End Times

Description of ''Figure 3-7 Aligning Account and Cycle Start and End Times''

Including Previous Balances in the Current Amount Due in Open Item Accounting

When you set the accounting type to open item accounting, the total amount due on the bill is reflected in the PIN_FLD_PENDING_RECV field in the /billinfo object. It is calculated by using the sum of the current balance and current subordinate account(s) balance: the previous balance of open items is not included. As a result, the customer's bill will not include amounts from previous bills.

Note:

When you set the default accounting type to balance forward accounting, the total amount due on the bill is reflected in the PIN_FLD_TOTAL_DUE field in the /bill object. It is calculated by using the sum of the previous balance, the current balance, and the current subordinate account(s) balance.

You can configure BRM to include the previous total amount due (PIN_FLD_PREVIOUS_TOTAL field) in the total amount due of the current bill unit during open item accounting. This will cause the current bill to reflect the total open charges on an account.

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the value of the open_item_actg_include_prev_total entry.

   The values are:

   • 0: The previous total is not added to the pending amount due during open item accounting.

   • 1: The previous balance is added to the pending amount due during open item accounting.

3. Save and close the file.

4. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

Specifying Which Billing Cycle to Assign to Deferred Purchase Fees

You can assign deferred purchase fees to the previous billing cycle or to the next billing cycle. By default, the purchase fee is assigned to the next billing cycle.

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the value of the purchase_fees_backcharge entry.

   The values are:

   0: The purchase fees apply to the next cycle.

   1: The purchase fees apply to the previous cycle.

3. Save and close the file.

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

About Billing Cycle Forward Fees in Advance

Usually, cycle forward fees for the following cycle are billed on the same day as the start of a new billing cycle. However, you can set up your price list to bill cycle forward fees in advance. See "Charging Cycle Forward Fees in Advance" in BRM Setting Up Pricing and Rating.

About Applying Cycle Forward Fees in Parallel

For accounts with multiple services (for example, a wholesale market customer account), you can configure BRM to apply cycle forward fees in parallel for multiple services instead of applying cycle forward fees sequentially for each service, thereby reducing the time to complete billing.

When you configure your BRM system for applying cycle forward fees in parallel, you can also configure BRM to:

• Enforce cycle fee processing prior to billing. By doing so, BRM eliminates the process of applying cycle forward fees during billing and improves the performance of the billing process.

• Use a single item at the account level to accumulate the cycle charges for all the services. By doing so, BRM reduces the number of items to process and improves overall system performance that is important when you are doing billing for wholesale customer accounts. When BRM applies cycle forward fees in parallel with service-level charges aggregated to a single account-level item, the account can have only a single bill unit (/billinfo object). Even though the account-level item aggregates the service charges, the respective service balance groups are still updated with the service charges.

Before configuring your BRM system for applying cycle forward fees in parallel, your system must meet the following requirements:

• The number of services attached to a single balance group must be less than 10 in order to get the performance benefit of applying cycle forward fees in parallel.

• There should be no dependency on the order of applying cycle forward fees for hierarchies (subordinate, charge-sharing, or discount-sharing). This is because the cycle forward fees are applied by the pin_cycle_fees utility instead of by the billing application that gives more control on the order of processing accounts in hierarchies.

Applying parallel cycle forward fees involves the following processes:

1. Running the pin_cycle_fees utility in parallel at the services level, which processes cycle forward fees aligned to the accounting cycle.

   Note:

   When the parallel fee processing feature is enabled, cycle forward fees are applied by the pin_cycle_fees utility, which is run before the pin_deferred_act utility. However, when the parallel cycle forward fees processing fees feature is not enabled, cycle forward fees are applied by the billing application after running pin_deferred_act.

2. Running the pin_update_items_journals utility to post-process cycle forward fees.

3. Running the pin_bill_accts utility for regular billing.

4. Running the pin_cycle_fees utility to process flexible cycle forward fees.

5. Running the pin_update_items_journals utility to post-process flexible cycle forward fees.

Configuring BRM to Apply Cycle Forward Fees in Parallel

You use the StagedBillingFeeProcessing business parameter to specify how BRM applies cycle forward fees.

To configure BRM to apply cycle forward fees in parallel:

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

2. Run the following command, which creates 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 the XML file named bus_params_billing.xml.out in your working directory. To place this file in a different directory, specify the path as part of the file name.

3. Open the bus_params_billing.xml.out file in a text editor.

4. Search for the following line:

   <StagedBillingFeeProcessing>0</StagedBillingFeeProcessing>
   

   The default is 0. (BRM applies the cycle forward fees as part of the billing process.)

   Note:

   The cycle fee processing at the time of billing is only with reference to the cycle forward fees aligned with the accounting cycle boundary.

5. Do one of the following:

   • To apply cycle forward fees in parallel by service, specify 1.

   • To enforce cycle fee processing prior to billing and apply cycle forward fees in parallel by service, specify 2. See "About Enforcing Cycle Forward Fee Processing Prior to Billing" for more information.

   • To apply cycle forward fees in parallel by service with service-level charges aggregated to a single account-level item, specify 3. See "About Aggregating Service Charges to Account Level Items" for more information.

   • To enforce cycle fee processing prior to billing and apply cycle forward fees in parallel by service with service-level charges aggregated to a single account level item, specify 4. See "About Enforcing Cycle Forward Fee Processing Prior to Billing" and "About Aggregating Service Charges to Account Level Items" for more information.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 billing and subscription configurations.

6. Save this file as bus_params_billing.xml.

7. Go to the BRM_Home/sys/data/config directory.

8. Load this change into the appropriate /config/business_params object by running the following command:

   pin_bus_params PathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To run this command from a different directory, see the description for "pin_bus_params" in BRM Developer's Guide.

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

   See the description of using testnap in BRM Developer's Guide for instructions on using the testnap utility. See the description of "Reading Objects by Using Object Browser" in BRM Developer's Guide for information on how to use Object Browser.

10. Stop and restart the Connection Manager (CM). For more information, see the description of "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

About Enforcing Cycle Forward Fee Processing Prior to Billing

When BRM enforces cycle fee processing prior to billing, the following processes are impacted:

• The pin_cycle_fees utility performs additional error processing to set the error status (as needed) on the corresponding /billinfo object.

  Important:

  If you customize pin_cycle_fees and use the application global structure PIN_FLD_EXTENDED_INFO provided by the multithreaded application framework to hold custom information at run time, you must consider that pin_cycle_fees stores the error processing information in a single array element PIN_FLD_ERROR_INFO under PIN_FLD_EXTENDED_INFO.

• The billing process aborts if any of the following conditions is true:

  • The BILLING_STATUS_FLAGS field of the /billinfo object indicates that there was an error processing one of the cycle forward fees.

  • There is at least one service for which cycle fee processing (regular, deferred, deferred purchase, or deferred cancellation) has not been completed for the accounting cycle being billed.

• In rare cases, if billing is due for a bill unit for more than one accounting cycles, special handling is required. See "Handling Skipped Billing" for more information.

About Aggregating Service Charges to Account Level Items

When applying cycle forward fees in parallel by service with service-level charges aggregated to a single account-level item, multiple threads of pin_cycle_fees updates a single item. To avoid updating the same item by multiple threads, pin_cycle_fees logs the item and journal updates to temporary tables as follows:

• Logs item updates to the /tmp_events_to_process object in the TMP_EVENTS_TO_PROCESS_T table.

• Logs journal updates to the /tmp_journals_to_process object in the TMP_JOURNALS_TO_PROCESS_T table.

The pin_update_items_journals utility processes the temporary item and journal data and updates the main item and journal tables.

To ensure efficient access of these temporary tables, Oracle recommends the following:

• Resetting high water mark. Records are frequently inserted into and deleted from the temporary tables. This can result in fragmentation of the temporary tables. You must reset the high water mark for the temporary tables as the BRM schema user.

  Run the following commands every time before calling the pin_bill_accts inside the pin_bill_day script.

  ALTER TABLE TMP_JOURNALS_TO_PROCESS_T ENABLE ROW MOVEMENT;
  ALTER TABLE TMP_JOURNALS_TO_PROCESS_T SHRINK SPACE; 
  ALTER TABLE tmp_events_to_process_t ENABLE ROW MOVEMENT; 
  ALTER TABLE tmp_events_to_process_t SHRINK SPACE;
  

  For more information about the high water mark, see the Oracle Database documentation.

• Presetting statistics. Preset the statistics of the temporary tables that are created during BRM installation by running the following commands as a one-time activity. This enables BRM to avoid a full scan of these tables.

  Exec dbms_stats.set_table_stats('SCHEMA_NAME','TMP_EVENTS_TO_PROCESS_T','','','',200000000,40000000,1250) ;
  
  Exec dbms_stats.set_index_stats('SCHEMA_NAME','I_TMP_EVENTS_ID','',numrows=>200000000,numlblks=>1000000,numdist=>200000000,avglblk=>1,avgdblk=>1,clstfct=>200000000);
  
  Exec dbms_stats.set_column_stats('SCHEMA_NAME','TMP_EVENTS_TO_PROCESS_T','POID_ID0','',distcnt=>200000000,density=>1/200000000,nullcnt=>0,srec=>srec_eve,avgclen=>11); 
  
  Exec dbms_stats.set_table_stats('SCHEMA_NAME','TMP_JOURNALS_TO_PROCESS_T','','','',200000000,40000000,1250);
  
  Exec dbms_stats.set_index_stats('SCHEMA_NAME','I_TMP_JOURNALS_ID','',numrows=>200000000,numlblks=>1000000,numdist=>200000000,avglblk=>1,avgdblk=>1,clstfct=>200000000);
  
  Exec dbms_stats.set_column_stats('SCHEMA_NAME','TMP_JOURNALS_TO_PROCESS_T','POID_ID0','',distcnt=>200000000,density=>1/200000000,nullcnt=>0,srec=>srec_eve,avgclen=>11);
  
  Exec dbms_stats.lock_table_stats('SCHEMA_NAME','TMP_EVENTS_TO_PROCESS_T');
  Exec dbms_stats.lock_table_stats('SCHEMA_NAME','TMP_JOURNALS_TO_PROCESS_T');
  

  where SCHEMA_NAME is the BRM database user; for example, pin1.

Handling Skipped Billing

In rare cases, if billing is due for a bill unit for more than one accounting cycles, special handling is required. This multiple cycle overdue billing is referred to as skipped billing.

For example, consider that the current date is December 1 and BRM did not perform billing for the cycles ending November 1 and October 1. In this case, when you run pin_bill_day on the current date, three bills are due to be created.

When BRM tries to calculate the cycle forward fees, the following happens:

• pin_cycle_fees applies cycle forward fees due only as of October 1 because October 1 billing has not been processed yet.

• pin_bill_accts performs billing only on October 1 and aborts with an error when performing billing on November 1 because cycle forward fees due as of November 1 have not been processed yet.

To handle the case of skipped billing used in this example:

1. Run pin_cycle_fees, pin_update_items_journals, and pin_deferred_act in the following sequence:

   pin_cycle_fees -defer_purchase
   pin_cycle_fees -defer_cycle_fees
   pin_cycle_fees -defer_cancel
   pin_cycle_fees -regular_cycle_fees
   pin_update_items_journals
   pin_deferred_act
   

2. Run pin_bill_accts.

3. Repeat step 1 and step 2 two more times, which performs billing for November 1 and December 1.

Using the pin_bill_day Script to Apply Parallel Cycle Forward Fees

To support applying cycle forward fees in parallel, the pin_bill_day script includes the following commented out sections:

• Pre-Billing Parallel Cycle Fee Processing: Includes the following entries for pin_cycle_fees and pin_update_items_journals:

  ##### pin_cycle_fees -defer_purchase
  ##### pin_cycle_fees -defer_cycle_fees
  ##### pin_cycle_fees -defer_cancel
  ###### pin_cycle_fees -regular_cycle_fees
  ##### pin_update_items_journals
  

• Post-Billing Parallel Cycle Fee Processing: Includes the following entry for pin_update_items_journals:

  ##### pin_update_items_journals
  

To apply cycle forward fees in parallel by using the pin_bill_day script:

1. Make sure that the StagedBillingFeeProcessing parameter is not set to 0.

2. Open the BRM_Home/bin/pin_bill_day script in a text editor.

3. Uncomment the following entries in the Pre-Billing Parallel Cycle Fee Processing section:

   ##### pin_cycle_fees -defer_purchase
   ##### pin_cycle_fees -defer_cycle_fees
   ##### pin_cycle_fees -defer_cancel
   ###### pin_cycle_fees -regular_cycle_fees
   ##### pin_update_items_journals
   

4. Uncomment the following entry in the Post-Billing Parallel Cycle Fee Processing section:

   ##### pin_update_items_journals
   

5. Save and close the file.

6. Run pin_bill_day.

About Limitations and Impacts of Applying Cycle Forward Fees in Parallel

This section describes the limitations and impacts of configuring BRM to apply cycle forward fees in parallel:

• In rare cases, when the pin_cycle_fees utility successfully creates temporary item and journal data and the subsequent run of the pin_update_items_journals utility fails to update the item and journal tables, you must investigate and correct the problem in processing the temporary item and journal data before performing any accounts receivable action or generating ledger reports.

• If the parallel fee processing feature is configured to enforce cycle fee processing prior to billing, any balance impact event that occurs prior to running the pin_cycle_fees utility aborts with an error.

• If the parallel fee processing feature is not configured to enforce cycle fee processing prior to billing, any balance impact event that occurs prior to running the pin_cycle_fees utility results in triggered billing that can be slow due to serial application of cycle forward fees.

• There is no performance improvement to the following operations because parallel cycle fee processing does not apply to these operations:

  • Trial billing

  • Bill Now

  • Billing on demand

  • Account creation

  • Purchase of deals

  • Billing time discount

  • Cycle fold

  • Rollover

  • Account activation, account inactivation, or account cancellation

  • Best pricing

  • Rerating

About Flexible Cycles

In BRM, cycle forward events are triggered to charge cycle forward fees. Typically, cycle forward fees are charged monthly at the beginning of the accounting cycle to charge for services provided during that cycle. By default, BRM supports monthly, bimonthly, quarterly, semi-annual, and annual cycle forward events. You can also configure BRM to support flexible cycles. Flexible cycles can be daily, weekly, monthly, or multimonth cycles that are not restricted to the billing or accounting cycles.

You can use flexible cycles to set up cycle forward fees to grant free resources, provide discounts, or charge fees at any time during the accounting cycle. For example, you can set up a cycle forward fee to grant free minutes every week or every day rather than once a month. Or you can set up a monthly cycle forward fee to grant free minutes on the 15th of every month, which is different from the monthly accounting cycle that begins the 1st of every month.

Configuring Flexible Cycles and Cycle Forward Fees

You set up flexible cycles by configuring flexible cycle forward events.

To set up flexible cycles:

1. Define a custom cycle forward event subclass by using Storable Class Editor in Developer Center.

   For example, to define a cycle forward event that occurs every 10 days, create /event/billing/product/fee/cycle/cycle_forward_10days.

   Tip:

   Use the /event/billing/product/fee/cycle/cycle_forward_quarterly object specification as a model.

2. Map the new event to a valid purchase level:

   1. In the event map configuration file (BRM_Home/sys/data/pricing/example/pin_event_map), add an entry for the new cycle forward event. The entry must use the following format:

      purchase_level:event_type:event_description:count: unit
      

      where:

      count specifies the frequency of the cycle. It must be a positive number.

      unit must be day, week, month, or year.

      For example, to map a biannual (24-month duration) cycle forward event to an account-level purchase type, the pin_event_map entry is:

      /account:/event/billing/product/fee/cycle/cycle_forward_biannual:Biannual Cycle Forward Event:24:month
      

      or

      /account:/event/billing/product/fee/cycle/cycle_forward_biannual:Biannual Cycle Forward Event:2:year
      

      See "Creating Service and Event Storable Classes" in BRM Developer's Guide.

   2. Run the load_event_map utility. For information on load_event_map, see BRM Setting Up Pricing and Rating.

3. Map the new event type to a valid ratable usage metric (RUM):

   1. In the usage map configuration file, add an entry for the new cycle forward event. For example:

      /event/billing/product/fee/cycle/cycle_forward_biannual:Occurrence: 0: 0: 0: 0: 0: 0: 0: cycle_forward_biannual
      

      See "Mapping Event Types to RUMs" in BRM Setting Up Pricing and Rating.

   2. Run the load_usage_map utility. For information on load_usage_map, see BRM Setting Up Pricing and Rating.

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

5. Use Pricing Center to create products and deals that include your new cycle forward fee.

Charging Cycle Forward Fees Associated with Flexible Cycles

Cycle forward fees are charged when you run monthly billing or by running the pin_cycle_forward billing utility.

When a cycle forward event is generated, balance impacts are applied using resource-level validity dates.

If a cycle forward event balance impact for a non-currency resource is set up with a relative cycle start date, balance impacts are applied either to the current cycle or to a future cycle.

For example, if the relative cycle is set to 1 and the cycle is from 1/1/04 to 3/1/04, a sub-balance is created with a validity period from 1/1/04 to 3/1/04. If the relative cycle is set to 2, a sub-balance is created with a validity period from 3/1/04 to 5/1/04.

Prorating Cycle Forward Fees Associated with Flexible Cycles

Because flexible cycles are not aligned with accounting cycles, cycle forward fees are prorated based on cycle start and end dates. For more information, see "Calculating Prorated Cycle Fees".

Calculating Product Cycle Fees for Backdating

By default, cycle fees are calculated by using the date that the current accounting cycle ends.

To handle cases where a product's purchase date has been backdated, you can use the CM configuration file calc_cycle_from_cycle_start_t entry to calculate product fees based on the product's purchase date. This feature is useful when activating an inactive product.

Note:

If the cycle start time is not aligned with the billing DOM, the cycle start time is first aligned with the billing DOM before it is used to calculate the cycle charges for the product. However, the cycle start time is aligned only after short and long billing cycle differences are considered. For more information, see "Specifying How to Handle Partial Accounting Cycles".

To set the product cycle start time:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Edit the calc_cycle_from_cycle_start_t entry:

   - fm_bill calc_cycle_from_cycle_start_t 1
   

   • 0 retains the default BRM behavior to calculate cycle fees (based on the date specified in the PIN_FLD_ACTG_NEXT_T field).

   • 1 sets the product cycle start time to consider the date specified in the PIN_FLD_CYCLE_START_T field for calculating the cycle fees.

3. Save and close the file.

You do not need to restart the CM to enable this entry.

Customizing Accounting Cycles

To customize accounting cycles, use the PCM_OP_BILL_POL_SPEC_FUTURE_CYCLE policy opcode.

This policy opcode is called from the PCM_OP_BILL_MAKE_BILL or the PCM_OP_CUST_SET_BILLINFO opcode whenever BRM calculates PIN_FLD_ACTG_NEXT_T and PIN_FLD_ACTG_FUTURE_T.

By default, PIN_FLD_ACTG_NEXT_T is calculated if you do not specify it in the input flist, but PIN_FLD_ACTG_FUTURE_T will always be calculated based on PIN_FLD_ACTG_NEXT_T.

The PCM_OP_BILL_POL_SPEC_FUTURE_CYCLE policy opcode can be modified to calculate the next and future accounting cycles appropriate for your business policy.

Note:

To customize the time interval for applying cycle forward and cycle arrears fees for a specified product, use the PCM_OP_SUBSCRIPTION_POL_SPEC_CYCLE_FEE_INTERVAL policy opcode. See "Customizing the Cycle Interval for Products" in BRM Setting Up Pricing and Rating.

Customizing How to Bill Events That Occur Between Billing Cycles

Use the PCM_OP_ACT_POL_CONFIG_BILLING_CYCLE policy opcode to specify in which billing cycle to apply an event when an event occurs between the end of a billing cycle and when billing applications are run.

By default, this policy opcode selects the current month's bill, but you can customize this policy opcode to select the previous month's bill.

You specify how long after the billing cycle ends that new events are considered for the previous month's bill by using the config_billing_cycle entry in the CM configuration (pin.conf) file:

config_billing_cycle value

Set the config_billing_cycle entry to specify how long after the end of the billing cycle the new events are considered for the previous month's bill.

The PCM_OP_ACT_POL_CONFIG_BILLING_CYCLE policy opcode is called by the PCM_OP_ACT_USAGE opcode when the value of the config_billing_cycle entry is greater than 0 and less than or equal to the value of config_billing_delay.

If the config_billing_cycle value is greater than the config_billing_delay value, the CM returns an error.

You can customize the PCM_OP_ACT_POL_CONFIG_BILLING_CYCLE policy opcode to point qualifying events to either the previous month's bill or the current month's bill.

Enabling Product Priority While Applying Cycle Fees

When there are multiple products in a deal with cycle fees, you can configure BRM to apply cycle fees in the order of product priority by using the UsePrioritySubscriptionFees subscription business parameter.

You can apply cycle fees based on product priority during:

• Purchase or cancellation of a deal, for all the products per deal.

• Billing, for all the products in a deal per bill unit (/billinfo).

Note:

This parameter does not prioritize products for cycle fees applied using pin_cycle_fees -defer_cancel and does not prioritize products for any customized products.

To enable product priority while applying cycle fee:

1. Go to the BRM_Home/sys/data/config directory, where BRM_Home is the directory in which you installed BRM.

2. Run the following command, which creates an editable XML file from the subscription instance of the /config/business_params object:

   pin_bus_params -r BusParamsSubscription bus_params_subscription.xml
   

   This command creates the XML file named bus_params_subscription.xml.out in your working directory. To place this file in a different directory, specify the path as part of the file name.

3. Open the bus_params_subscription.xml.out file in a text editor.

4. Search the file for the following line:

   <UsePrioritySubscriptionFees>disabled</UsePrioritySubscriptionFees>
   

   By default, the UsePrioritySubscriptionFees parameter is disabled.

5. Change disabled to enabled.

   Caution:

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

6. Save this file as bus_params_subscription.xml.

7. Go to the BRM_Home/sys/data/config directory.

8. Load this change into the appropriate /config/business_params object by running the following command:

   pin_bus_params PathToWorkingDirectory/bus_params_subscription.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_subscription.xml resides.

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

   For more information, see the descriptions about using testnap and about reading objects by using Object Browser in BRM Developer's Guide.

10. Stop and restart the Connection Manager (CM). For more information, see the description of starting and stopping the BRM System in BRM System Administrator's Guide.

11. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

About Calculating Charges When You Change the Rate

When you change the rate for cycle events in the middle of a cycle and add a new rate tier for the product associated with the event, you can ensure that the two different rates are applied and prorated correctly for the periods they are valid. You can change the rate for cycle events:

• In the current cycle. See "About Rate Changes in the Current Cycle".

• In a future cycle. See "About Rate Changes in a Future Cycle".

About Rate Changes in the Current Cycle

If you change the rate for cycle forward or cycle forward arrears events: that is, after the cycle fees have been charged: you use the pin_rate_change utility to notify BRM about the change. When you run the pin_rerate utility, BRM recalculates the cycle fees by applying the old rate to the part of the cycle before the rate change and the new rate to the part of the cycle after the rate change. BRM adjusts the balance impact accordingly.

For example, suppose the cycle is from April 15 to May 15 and the cycle fee is $10. A cycle fee of $10 is charged to the account. Suppose you change the cycle fee from $10 to $20 on April 30. A new rate tier at $20, which is valid from April 30, is added to the product. When you run pin_rate_change and then pin_rerate, BRM recalculates the cycle fees for the accounts affected by the rate change as follows:

• Refunds $10 of the old cycle fee.

• Recalculates the cycle fees using the rate of $10 for the first 14 days and the rate of $20 for the next 16 days in the cycle:

  ($10 x 14/30) + ($20 x 16/30) = $15.33

For more information on pin_rate_change, see pin_rate_change in BRM Setting Up Pricing and Rating.

For more information on rerating, see "About Comprehensive Rerating Using pin_rerate" and pin_rerate in BRM Setting Up Pricing and Rating.

About Rate Changes in a Future Cycle

If you change the rate for a cycle arrears event for which the cycle fees are charged at the end of the cycle or if you schedule a rate change for a future cycle, the cycle forward and cycle arrears functions use the two different rates and calculate the charges correctly.

When you configure BRM to use multiple rates in a cycle, BRM correctly calculates and prorates other real-time events such as discounts, product purchases, product cancellations, and line transfers by using the appropriate rate for the period when the event occurs.

Calculating Charges When You Change the Rate in a Cycle

To calculate charges correctly when the rate changes in the middle of a cycle, perform these tasks:

1. Configuring BRM to Apply Multiple Rates in a Cycle.

2. Configuring Event Notification for Rate Changes.

3. Creating Rerating Requests When You Change the Rate.

4. Recalculating the Cycle Fees When the Rate Changes. Perform this task only if the change occurs in the current cycle for cycle forward and cycle forward arrears events.

   Note:

   Charges for cycle arrears events and for events in future cycles are calculated automatically by the cycle arrears and cycle forward functions.

Configuring BRM to Apply Multiple Rates in a Cycle

To enable BRM to apply multiple rates in a cycle and to generate rate change events:

1. Open the CM) configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Ensure that the following entries are set to 1:

   - fm_subscription rate_change 1
   - fm_price log_price_change event 1
   

   Important:

   To apply only one rate and not multiple rates in future cycles, disable these entries by setting them to 0. Using a single rate is more performance efficient than using multiple rates.

3. Save and close the file.

4. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

Configuring Event Notification for Rate Changes

When a rate changes in the middle of a cycle, BRM uses event notification to call the PCM_OP_SUBSCRIPTION_PREP_RATE_CHANGE opcode, which creates a /rate_change object in the database.

To enable BRM to do this, you must configure the event notification feature as follows:

1. If your system has multiple configuration files for event notification, merge them. See "Merging Event Notification Lists" in BRM Developer's Guide.

2. Ensure that the merged file includes the following information from the BRM_Home/sys/data/config/pin_notify file:

   # Rate change related event notification
   3768    0    /event/audit/price/product_update
   3768    0    /event/audit/price/product_complete
   

3. (Optional) If necessary to accommodate your business needs, add, modify, or delete entries in your final event notification list. See "Editing the Event Notification List" in BRM Developer's Guide.

4. (Optional) If necessary to accommodate your business needs, create custom code for event notification to trigger. See "Triggering Custom Operations" in BRM Developer's Guide.

5. Load your final event notification list into the BRM database. See "Loading the Event Notification List" in BRM Developer's Guide.

For more information, see "Using Event Notification" in BRM Developer's Guide.

Configuring Event Notification to Create Rerating Requests for Rate Changes

When you change the rates in the middle of the current cycle for cycle forward and cycle forward arrears events, you must configure event notification to trigger the creation of rerating requests when you run pin_rate_change.

When you run pin_rate_change, it calls the PCM_OP_SUBSCRIPTION_RATE_CHANGE opcode; this opcode returns a notification event of type /event/notification/rate_change for each account picked up by pin_rate_change. Depending on how automatic rerating is configured, the notification event triggers the creation of rerating requests.

To enable BRM to do this, you must configure the event notification feature as follows:

1. If your system has multiple configuration files for event notification, merge them. See "Merging Event Notification Lists" in BRM Developer's Guide.

2. Ensure that the merged file includes the following information from the BRM_Home/sys/data/config/pin_notify file:

   # Rerating related event notification
   3787    0    /event/notification/rate_change
   

3. (Optional) If necessary to accommodate your business needs, add, modify, or delete entries in your final event notification list. See "Editing the Event Notification List" in BRM Developer's Guide.

4. (Optional) If necessary to accommodate your business needs, create custom code for event notification to trigger. See "Triggering Custom Operations" in BRM Developer's Guide.

5. Load your final event notification list into the BRM database. See "Loading the Event Notification List" in BRM Developer's Guide.

For more information, see "Using Event Notification" in BRM Developer's Guide.

Creating Rerating Requests When You Change the Rate

When you change the rates in the middle of the current cycle for cycle forward and cycle forward-arrears events, you must run pin_rate_change to create rerating requests.

Note:

For rate changes in a future cycle or cycle arrears events, you do not need to run this utility.

Important:

To use only one rate for a cycle and not multiple rates, do not run pin_rate_change.

Enter this command to run the utility:

pin_rate_change -v -d

For more information, see pin_rate_change in BRM Setting Up Pricing and Rating and "Configuring Event Notification to Create Rerating Requests for Rate Changes".

Recalculating the Cycle Fees When the Rate Changes

To recalculate the cycle fees and adjust the balance impacts for the accounts affected by the rate change, run pin_rerate. See pin_rerate in BRM Setting Up Pricing and Rating.

Prorating Different Resources When the Rate Changes

When you configure BRM to use multiple rates in a cycle, if the rate changes in the middle of the cycle, BRM automatically prorates the non-currency resources, such as free minutes, for cycle events according to the rate applicable for the period in the cycle. You can configure BRM to use multiple rates for one type of resource, for example currency, and a single rate for another type of resource, for example free minutes.

To rate resources differently:

1. Create two products. For example, one for currency balance impacts and another for non-currency balance impacts.

2. Set one to prorate.

3. Set the other to be charged in full.

Using 31-Day Billing

By default, you can set the billing DOM to any day between 1 and 28. If your customer signs up on the 29th, 30th, or 31st, the billing DOM gets set to the 1st. This is done because all months do not have these days. This can result in a large number of customers being billed on the 1st of the month.

You can change this default setting to support billing on all days of the month. For example, if you create a customer account on the 29th, the billing DOM is set to the 29th instead of the 1st.

About Setting the Alternate Billing Day of Month

If your customers' billing DOM is the 29th, 30th, or 31st, for the months that do not have these days, you can configure whether billing should be run on the last day for the same month (set to back option) or the first day of the next month (set to forward option). By default, the billing DOM is set to the 1st of the next month.

For example, if a customer registers on March 31:

• The set to back option sets the following billing dates:

  • March 31

  • April 30

  • May 31

  In this example, because April does not have 31 days, the billing DOM is on the last day of April.

• The set to forward option sets the following billing dates:

  • March 31

  • May 1

  • May 31

  In this example, because April does not have 31 days, the billing DOM is on the first day of the following month, May.

  Tip:

  To set the billing DOM to always be the last day of the month, set it to 31 and use the set to back option.

  Note:

  • Using these special days means that the billing DOM varies from month to month in a calendar year.

  • The general ledger (G/L) earned and unearned report accounts for the variation in the number of days in different accounting cycles.

  • The cycle fees are charged in full regardless of how many days there are in a month. Cycle fees will be prorated only in special cases; for example, if you cancel a service in the middle of a month or if you register in the middle of a month and your billing DOM is different from the date of account creation, the cycle fee may be prorated for such months. See "Calculating Prorated Cycle Fees" for details on proration.

  • If 31-day billing feature is not enabled, by default, billing DOM is set to the 1st of the month. For example, if your customer signs up on October 29th, the billing DOM is set to December 1st instead of November 29th. Consequently, the period for which cycle fees is calculated is greater than one unit interval, and the cycle fee charged is greater than the cycle fee amount.

Setting the 31-Day Billing Feature

By default, billing does not use the special days 29th, 30th, and 31st. To use the special days, you must either modify the init_objects.source file before loading it into the database or modify the /config/fld_validate object using testnap.

Switching to 31-Day Billing during BRM Installation

Before loading init_objects.source, change the value of the PIN_FLD_MAXIMUM field from 28 to 31 in the /config/fld_validate object that has the Actg_cycle value in the PIN_FLD_NAME field as follows:

# /config/fld_validate  - Actg_cycle validation
<PCM_OP $PIN_OPNAME=$PIN_CONF_INIT_OPNAME; $PIN_OPFLAGS=$PIN_CONF_INIT_OPFLAGS>
0 PIN_FLD_POID                 POID [0] $PIN_CONF_DB_NO /config/fld_validate 606 0
0 PIN_FLD_DESCR                 STR [0] "Field Validation"
0 PIN_FLD_HOSTNAME              STR [0] "-"
0 PIN_FLD_NAME                  STR [0] "Actg_cycle"
0 PIN_FLD_PROGRAM_NAME          STR [0] "-"
0 PIN_FLD_VALIDATION      SUBSTRUCT [0]
1 PIN_FLD_FIELD_TYPE            INT [0] 2
1 PIN_FLD_MAXIMUM               NUM [0] 31
1 PIN_FLD_MINIMUM               NUM [0] 31
</PCM_OP> 

Important:

When you upgrade to a new BRM release, ensure that you make this change in the new init_objects.source file. The installation program overwrites the init_objects.source file, and the changes you have made will be lost.

Switching to 31-Day Billing after You Install BRM

To switch to 31-day billing after you have installed BRM, use the testnap utility to set the Forward or Back billing option in the /config/business_params object.

For instructions on how to find this object and change the value, see "Reading an Object and Fields" and "Modifying Objects" in BRM Developer's Guide.

In this example, PIN_FLD_MAXIMUM is set to 31, indicating that BRM will use 31-day billing:

0 PIN_FLD_POID               POID [0] 0.0.0.1 /config/fld_validate 606
0 PIN_FLD_VALIDATION    SUBSTRUCT [0]
1 PIN_FLD_MAXIMUM         DECIMAL [0] 31

Tip:

To verify that you changed the field, read the object by using the testnap utility or by displaying the /config/business_paramsobject in Object Browser. See "Reading an Object and Fields" in BRM Developer's Guide.

Important:

Stop and restart the CM after editing the object. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

Setting the Forward and Back Billing Options

By default, the billing DOM is set to the 1st of the next month. If you use 31-day billing, you can choose to run billing on the last day for the same month (set to back option) or the first day of the next month (set to forward option). See "About Setting the Alternate Billing Day of Month".

You configure the billing DOM by modifying a field in the billing instance of the /config/business_params object.

Important:

You cannot set this parameter differently for different brands.

You modify the /config/business_params object by using the pin_bus_params utility. For information on this utility, see pin_bus_params in BRM Developer's Guide.

To configure the billing DOM to be last day of the month or 1st of the next month:

1. 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 working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

2. Search the XML file for the following line:

   <MoveDayForward>firstDay</MoveDayForward>
   

3. Change firstDay to lastDay.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

4. Save the file as bus_params_billing.xml and close the file.

5. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

6. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description of 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" 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.

9. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Customizing Bill and Invoice Numbers

For information about customizing the way BRM generates bill and invoice numbers, see the following:

• About Bill Numbering in BRM

• About Numbering Corrective Bills in BRM

Customizing the Format of Bill and Invoice Numbers

You can customize the prefix and the numbering sequence for bills.

To use a different bill number format, use PCM_OP_WRITE_FLDS to modify the PIN_FLD_HEADER_STR field in the /data/sequence object. For example, to use a bill number format with numbers only and no letters, such as 100, 101, 102, and so on, set PIN_FLD_HEADER_STR to two colons (::). For information about modifying fields in an object, see "Writing Fields in Objects" in BRM Developer's Guide.

Use the PCM_OP_BILL_POL_SPEC_BILLNO policy opcode to customize bill numbers. The PCM_OP_BILL_POL_SPEC_BILLNO policy opcode assigns a default number to the /account storable object in the database. This policy opcode is called by the pin_fld_billno utility and uses the default implementation information to create a unique billing number. The billing number is then returned to the storable object in the database. For information on PCM_OP_BILL_POL_SPEC_BILLNO, see BRM Developer's Guide.

Specifying When to Apply Custom Bill Numbers

For corrective bills, BRM assigns a new bill number when it generates the corrective bill only. It does not support applying bill numbers at any other time in the corrective billing process.

For regular bills, you can control when custom bill numbers must be assigned to account bill units, which can be useful for revenue and expense accounting purposes. Custom bill numbers can be applied at the beginning of the first accounting cycle or at the end of the previous accounting cycle for multimonth billing cycles.

To specify when BRM assigns custom bill numbers:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the value of the custom_bill_no entry.

   • 0 assigns custom bill numbers at the end of the previous accounting cycle. This is the default.

   • 1 assigns custom bill numbers at the beginning of the first accounting cycle.

3. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

Configuring Bill Now

For information about Bill Now, see the following:

• About Bill Now

• How Bill Now Works

Selecting the Input for Bill Now

By default, Bill Now generates a bill that includes all pending items. You can customize Bill Now to include only specified pending items. To change the default behavior, edit the search criteria in the PCM_OP_BILL_POL_GET_PENDING_ITEMS policy opcode.

Important:

If you run Bill Now on a subordinate /billinfo, a bill is created for the parent /billinfo that only includes the items from the subordinate /billinfo. If you run Bill Now on a parent /billinfo, a bill is created that contains a total of the items from both the parent and any subordinate /billinfo objects.

Changing the Bill Now Due Date

The default due date for a bill created with Bill Now is calculated as the billing cycle length minus one day after Bill Now is run:

date_of_bill + billing_cycle_length - one_day

For example, if you run Bill Now on June 2, and the billing cycle is one month, the bill is due July 1.

To change the Bill Now due date to, for example, date_of_bill + billing_cycle_length - 7 days, you customize the PCM_OP_BILL_POL_CALC_PYMT_DUE_T policy opcode.

Providing Discounts to Closed Accounts

To apply discounts with Bill Now to closed accounts, you must ensure that BRM does not delete canceled discounts. For information about deleting canceled discounts, see "Specifying to Delete Canceled Discounts" in BRM Managing Customers.

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Set the keep_cancelled_products_or_discounts entry to 1:

   - fm_subscription_pol keep_cancelled_products_or_discounts 1
   

   If this entry is not present, add it.

3. Save and close the file.

4. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

Prorating Cycle Arrears and Cycle Forward Arrears for Bill Now

By default, when you use Bill Now, cycle arrears charges and cycle forward arrears charges are not prorated. You can specify to prorate cycle arrears charges and cycle forward arrears charges for Bill Now by modifying a field in the billing instance of the /config/business_params object.

Note:

When you use Bill Now, you can enable proration for cycle arrears and cycle forward arrears charges; however, cycle forward fees are not prorated.

You modify the /config/business_params object by using the pin_bus_params utility. For information on this utility, see pin_bus_params in BRM Developer's Guide.

To prorate cycle forward arrears charges when you use Bill Now:

1. 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 working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

2. Search the XML file for the following line:

   <ApplyCycleFeeForBillNow>disabled</ApplyCycleFeeForBillNow>
   

3. Change disabled to enabled.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

4. Save the file as bus_params_billing.xml and close the file.

5. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

6. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description for 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" 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.

9. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Creating Two Bills during the Delayed Billing Period

By default, generating two bills with Bill Now during the delayed billing period is disabled in BRM. You enable this feature by modifying a field in the billing instance of the /config/business_params object.

You modify the /config/business_params object by using the pin_bus_params utility. For more information, see the description of pin_bus_params in BRM Developer's Guide.

Delayed billing must already be set up before enabling this feature. If you have not already set up delayed billing, see "Setting Up Delayed Billing".

To enable Bill Now during the delayed period:

1. 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 working directory. If you do not want this file in your working directory, specify the path as part of the file name.

2. Search the XML file for the following line:

   <CreateTwoBillNowBillsInDelay>disabled</CreateTwoBillNowBillsInDelay>
   

3. Change disabled to enabled.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

4. Save the file as bus_params_billing.xml and close the file.

5. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

6. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description of 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" 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.

9. (Multischema systems only) Run the pin_multibd script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Calculating Deferred Taxes with Bill Now

When you run Bill Now on a parent /billinfo that includes subordinate /billinfo objects, Bill Now ignores the cycle_tax_interval entry in the CM configuration file. Normally, the entry specifies whether deferred taxes are calculated separately for the parent and each subordinate /billinfo or are consolidated into a single item for the parent. See "About Tax Calculation for Account Groups" in BRM Calculating Taxes.

With Bill Now, no matter which option you select, it always rolls activities for each subordinate bill unit into the parent bill unit and calculates taxes for the parent only. The single tax item for the parent includes taxes from both the parent and subordinate bill units.

Customizing Bill Now

You can use the PCM_OP_BILL_POL_GET_PENDING_ITEMS policy opcode to select only those pending items you want to be used by PCM_OP_BILL_MAKE_BILL_NOW opcode.

By default, the PCM_OP_BILL_POL_GET_PENDING_ITEMS opcode selects all pending items and passes them back to PCM_OP_BILL_MAKE_BILL_NOW.

If the bill is produced for the parent /billinfo object, this bill, by default, includes pending items from the parent and all subordinate /billinfo objects. To include items for just one of the subordinate /billinfo objects, add functionally to the PCM_OP_BILL_POL_GET_PENDING_ITEMS policy opcode to filter out the rest of the items for the /billinfo objects associated with the parent /billinfo.

Applying Discounts and Folds with Bill Now

To apply discounts or folds, your customer management application needs one of the values listed in Table 3-1 in the PIN_FLD_FLAGS field in the PCM_OP_BILL_MAKE_BILL_NOW input flist:

Table 3-1 Values to Apply Folds, Discounts, or Both

To include:	Set the Value To:
Folds	16
Discounts	32
Folds and discounts	48 (You add the values to get both actions.)

Important:

• A billing-time discount is not allowed when Bill Now includes only selected items or a specific service.

• When the billing-time discount flag is specified, you must ensure that a fold is configured for the specific resource used by the billing-time discount. In addition to the billing-time discount flag, you must also specify the fold flag to fold the resources used by the discount. If a fold is not configured for the resource used by the discount or the fold flag is not specified, the billing-time discount is applied again during regular billing.

• When the fold flag is specified, all resources are folded, even those not used by the billing-time discount. For example, when closing an account, you can specify the fold flag to fold all the resources. In other cases, you may not want to fold all the resources. In such cases, do not specify the billing-time discount or fold flag if there are other resources that are not used by the billing-time discount.

Running Bill Now for a Service

You can extend your customer management application to generate a Bill Now type of bill for a specific service. When the selected service belongs to a sponsored account, a bill can be generated for the sponsoring account of the charge sharing group.

For information on the relevant opcodes, see the following:

• PCM_OP_BILL_MAKE_BILL_NOW

• PCM_OP_BILL_CREATE_SPONSORED_ITEMS

• PCM_OP_BILL_POL_GET_PENDING_ITEMS

Disabling Auto-Triggered Billing

To disable auto-triggered billing, you must specify the following:

1. Billing delay interval. See "Disabling Auto-Triggered Billing by Specifying Billing Delay".

2. Value of AutoTriggeringLimit entry. See "Disabling Auto-Triggered Billing by Setting AutoTriggeringLimit".

For more information, see "About Auto-Triggered Billing".

Disabling Auto-Triggered Billing by Specifying Billing Delay

To disable auto-triggered billing, you must specify billing delay even if you do not use delayed billing.

Note:

If you do not use delayed billing, you can set the billing delay interval to 0.

When billing delay is specified, the system maintains an internal list of bill items for both the previous billing cycle and the next billing cycle so that new events impact bill items of the next billing cycle and old events impact bill items of the previous billing cycle.

Set or specify the billing delay as follows:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Uncomment the config_billing_delay entry.

   Caution:

   You can change the value of the config_billing_delay entry (for example, change the billing delay interval from 5 days to 3 days) at any time. However, after you begin rating events in a production database, do not comment or uncomment the config_billing_delay entry. Doing so might cause database errors.

   Important:

   If you do not use delayed billing but want to disable auto-triggered billing, set config_billing_delay to 0.

3. Save and close the file.

4. Stop and start the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

5. Open the billing application configuration file (BRM_Home/apps/pin_billd/pin.conf).

6. Set the config_billing_delay entry to the same value as in the CM pin.conf file.

7. Save and close the file.

Disabling Auto-Triggered Billing by Setting AutoTriggeringLimit

To disable auto-triggered billing, you must also set the AutoTriggeringLimit entry to be greater than 0. When auto-triggered billing is disabled, the AutoTriggeringLimit value is used as a precaution to trigger billing when the previous billing run is still pending and next billing is imminent.

By default, AutoTriggeringLimit is set to 2. For example, if billing for the previous cycle has not occurred and the billing for the next cycle is due in the next two days, then billing for the previous cycle is auto-triggered within these two days.

To change the AutoTriggeringLimit value, do the following:

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

   pin_bus_params -r BusParamsBilling bus_params_billing.xml 
   

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

2. Search the XML file for the following line:

   <AutoTriggeringLimit>N</AutoTriggeringLimit>
   

   To disable auto-triggered billing, set N greater than 0.

   For example, if you change the value to 5, auto-triggered billing is enabled only for the last 5 days of each billing cycle.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

3. Save the file as bus_params_billing.xml and close the file.

4. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

5. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description of pin_bus_params in BRM Developer's Guide.

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

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

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

8. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Auto-triggered billing is now disabled for all but the delay interval and the last N days of each bill unit's accounting cycle. If the delay interval is set to 0, auto-triggered billing is disabled for all but the last N days of the bill unit's accounting cycle.

For more information, see "About Auto-Triggered Billing".

Setting Up Delayed Billing

Important:

If you set up delayed billing, delayed events can borrow rollover from the current cycle even if events from the current cycle have consumed the rollover. Unless you set up rerating and rollover correction, current cycle events can remain rated as free even if their rollover has been consumed by delayed events. For more information, see "Enabling Rerating and Rollover Correction Due to Delayed Events".

Configuring Delayed Billing

To set up delayed billing, you must specify the following:

• Billing delay interval. See "Specifying the Billing Delay Interval".

• Value of AutoTriggeringLimit entry. See "Specifying Auto-Triggered Billing for Delayed Billing".

For information about delayed billing, see "About Delayed Billing".

Specifying the Billing Delay Interval

Set the billing delay interval as follows:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. If necessary, uncomment the config_billing_delay entry.

   The entry is enabled (uncommented) by default.

3. Change the value of the config_billing_delay entry to specify the delay interval:

   config_billing_delay D[:H]
   

   where D is the number of days and H is the number of hours. Leading zeros are allowed when specifying the delay interval.

   Note:

   The length of the delay interval must be shorter one accounting cycle.

   For example:

   • - fm_bill config_billing_delay 0:12 sets billing delay interval to 12 hours.

   • - fm_bill config_billing_delay 2 sets billing delay interval to 2 days.

   • - fm_bill config_billing_delay 1:3 sets billing delay interval to 1 day and 3 hours.

   • - fm_bill config_billing_delay 01:03 also sets billing delay interval to 1 day and 3 hours.

   • - fm_bill config_billing_delay 0 sets billing delay interval to zero.

   Caution:

   You can change the value of the config_billing_delay entry (for example, change the billing delay interval from 5 days to 3 days) at any time. However, after you begin rating events in a production database, do not comment or uncomment the config_billing_delay entry. Doing so might cause database errors.

4. Save and close the file.

5. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

6. Open the billing application configuration file (BRM_Home/apps/pin_billd/pin.conf).

7. Set the value of the config_billing_delay entry to the same value as in the CM pin.conf file.

8. Save and close the file.

Specifying Auto-Triggered Billing for Delayed Billing

When a systemwide billing delay is set in BRM, by default auto-triggered billing is disabled for all but the delay period and only the last two days of each bill unit's accounting cycle.

You can change the default to enable auto-triggered billing to be enabled for more than two days at the end of each accounting cycle or you can change it to be always enabled when delayed billing is used.

To change the default, use the pin_bus_params utility to modify the AutoTriggeringLimit parameter in the billing instance of the /config/business_params object. See BRM System Administrator's Guide for information on pin_bus_params.

Note:

This is a systemwide setting; it applies to the accounting cycle of every bill unit in your BRM system.

Configure the auto-triggered billing period for delayed billing as follows:

1. 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 the XML file named bus_params_billing.xml.out in your working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

2. Search the XML file for following line:

   <AutoTriggeringLimit>2</AutoTriggeringLimit>
   

3. To change the number of days for which auto-triggered billing is enabled at the end of each accounting cycle, change 2 to a number greater than 0 and less than one accounting cycle. For example, if you change the value to 10, auto-triggered billing is enabled for the last 10 days of every accounting cycle and in the billing delay interval.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

4. To always enable auto-triggered billing when delayed billing is used, change 2 to 0. For example, if billing delay interval is five days and AutoTriggeringLimit is 0, auto-triggered billing is enabled all the time.

5. Save the file as bus_params_billing.xml and close the file.

6. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

7. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description for pin_bus_params in BRM Developer's Guide.

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

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

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

10. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Specifying When to Apply Cycle Forward Fees and Cycle Rollovers

Cycle forward fees and cycle rollovers are normally applied at the beginning of the accounting cycle to charge for services provided during that cycle and to roll over unused resources for use in subsequent cycles. However, when your system is set up for delayed billing, cycle forward fees and cycle rollovers are applied during partial billing by default. For more information, see "About Delayed Billing".

The BRM system provides the flexibility to specify when to charge cycle forward fees and rollover resources when you use delayed billing. You can specify to charge cycle forward fees and rollover resources either during partial billing or final billing by setting the delay_cycle_fees entry in the CM configuration file (pin.conf).

Important:

New events that occur inside the billing delay interval are rated and recorded for the next billing cycle. If cycle forward fees and rollover resources are not applied when new events occur in the delay interval, rating of the new events might produce incorrect results. Oracle recommends applying cycle forward fees and cycle rollovers during partial billing unless reasons exist not to do so.

To specify when to apply cycle forward fees and cycle rollovers:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Add the - fm_bill delay_cycle_fees entry and set it to 0 or 1.

   • 0 (the default) applies cycle forward fees and cycle rollover during partial billing.

   • 1 applies cycle forward fees and cycle rollover during final billing.

     Note:

     You can change the setting for delay_cycle_fees either before partial billing or after final billing. Do not change this setting between partial billing and final billing.

3. Save and close the file.

4. Stop and restart the CM.

Enforcing Partial Billing in the Billing Delay Interval

Partial billing is run only when your BRM system is set up for delayed billing. The BRM system automatically triggers partial billing by default when it detects that a new event has occurred for the next billing cycle inside the billing delay interval. For more information about delayed billing, see "About Delayed Billing".

When there are no new events in the delay interval and partial billing has not occurred, you can force the BRM system to run partial billing when the billing utility is run in the delay interval. Later, if a new event occurs in the delay interval, the new event is processed immediately, without waiting for the partial billing run to complete.

To force partial billing:

1. Open the billing utility configuration file (BRM_Home/apps/pin_billd/pin.conf) in a text editor.

2. Set the - pin_bill_accts enforce_billing entry to 0 or 1.

   0 does not enforce partial billing.

   1 enforces partial billing. This is the default.

   Note:

   The enforce_billing entry is used by the BRM system to enforce partial billing only if the config_billing_delay entry is specified and set to a number greater than zero.

3. Save and close the file.

4. Run the billing utility.

Setting Delayed Cycle Start Dates to the 29th, 30th, or 31st

By default, when you delay a customer's cycle fees by one month: for example, to provide a promotional month of free service: BRM sets the delayed cycle start date to any date from the 1st through the 28th of the month. Therefore, any delayed cycle fees due on the 29th, 30th, or 31st of the month are advanced to the first day of the following month. For example, if you delay cycle fees by one month for a deal purchased on October 29, BRM sets the delayed cycle start date to December 1.

To configure BRM to enable delayed cycle start times on the 29th, 30th, or 31st of a month:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Change the fm_bill cycle_delay_use_special_days entry:

   • To set the delayed cycle start date to the 1st of the following month for all deals purchased on the 29th, 30th, or 31st, enter 0. This is the default setting.

   • To enable BRM to assign delayed cycle start dates to the 29th, 30th, or 31st of the month, enter 1.

3. Save and close the file.

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

Billing Cycle Override

You can override the billing cycle for events that occur during the delayed billing interval. By default, events recorded during the delayed billing interval are billed in the previous billing cycle when the event time precedes the previous billing cycle end date. Otherwise, the event is billed in the current billing cycle. You can configure BRM to specify whether such events are billed in the previous or current billing cycle. BRM enables you to specify a configurable billing cycle interval. You can then choose which events recorded during this interval are to be billed in the previous or current billing cycle. Events that are not recorded during this interval are billed as usual, using the default delayed billing implementation.

To configure the billing cycle for events that occur during the delayed billing interval:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Set the config_billing_cycle entry to the length of the configurable billing cycle interval.

3. For example, the following sets the interval to 5 days:

   - config_billing_cycle 5
   

   Important:

   The config_billing_cycle value must be greater than zero and less than or equal to the config_billing_delay (delayed billing interval value). Otherwise, BRM reports an error and terminates the CM.

   Note:

   Setting the configurable billing cycle to be the same as the delayed billing interval will affect system performance because each event occurring within the delayed billing interval is passed to the PCM_OP_ACT_POL_CONFIG_BILLING_CYCLE policy opcode for additional processing.

4. Modify the PCM_OP_ACT_POL_CONFIG_BILLING_CYCLE policy opcode:

   • To bill the event in the previous cycle, set the output flist field FLAGS to BILL_IN_PREVIOUS_CYCLE.

   • To bill the event in the current cycle, set the FLAGS field to BILL_IN_CURRENT_CYCLE.

   See PCM_OP_ACT_POL_CONFIG_BILLING_CYCLE.

Using Pipeline Manager to Trigger Billing

When you use pipeline batch rating, if an account is currently in the process of being billed, incoming call records are suspended (not rated) for that account until its billing is complete. The number of accounts being billed affects the time it takes to complete the billing process. When you need accounts to be billed quickly so that their new usage can be rated, you can set up Pipeline Manager to trigger billing. This will reduce the number of call records that might need suspending. When Pipeline Manager triggers billing for an account, it is billed in a separate billing process.

To set up pipeline-triggered billing, see "Setting Up Pipeline-Triggered Billing".

Enabling a Billing Delay for Rated Event Loader

If you use Rated Event (RE) Loader to load batch-rated events, RE Loader cannot load a CDR for the next billing cycle unless delayed billing is enabled. For more information, see the discussion on enabling a billing delay for CDRs to be loaded when billing is incomplete in BRM Configuring and Running Billing.

Enabling Rerating and Rollover Correction Due to Delayed Events

If a delayed event arrives after the end of the accounting cycle and during the delayed billing period, the event can borrow against the rollover of the current cycle even when the current rollover has been consumed by events of the current cycle.

If rerating and rollover correction is enabled and delayed events borrow from the rollover of the current cycle, the current cycle events are rerated and the rollover is reallocated so that it comes from the appropriate cycles.

For example, suppose the billing delay period is configured for 10 days.

On January 1, a monthly cycle event grants 100 free minutes that are valid from January 1 to February 1 as shown in Figure 3-8.

Figure 3-8 January Cycle Event Grant of 100 Free Minutes

Description of ''Figure 3-8 January Cycle Event Grant of 100 Free Minutes''

On February 1, the 100 free minutes from January are rolled over to the next cycle and are valid from January 1 to March 1. The cycle event creates a new sub-balance with 100 free minutes valid from February 1 to March 1 as shown in Figure 3-9.

Figure 3-9 January Rollover and February Cycle Event Grant of 100 Free Minutes

Description of ''Figure 3-9 January Rollover and February Cycle Event Grant of 100 Free Minutes''

On February 2, events from the current cycle consume the entire 100 free minutes in the rollover bucket as shown in Figure 3-10.

Figure 3-10 100 Free Minutes Consumed from Rollover Bucket

Description of ''Figure 3-10 100 Free Minutes Consumed from Rollover Bucket''

On February 5, a delayed event is rated for 100 minutes. These 100 minutes are consumed from the rollover bucket leaving a balance of +100 minutes as shown in Figure 3-11.

Figure 3-11 Additional 100 Minutes Consumed from Rollover Bucket

Description of ''Figure 3-11 Additional 100 Minutes Consumed from Rollover Bucket''

When rollover correction is enabled, the current cycle events are rerated and the original balance impacts are backed out. Therefore, 100 minutes are reallocated into the rollover bucket. Because the delayed event caused a balance impact of +100 and rerating caused a balance impact of -100, the rollover bucket balance becomes 0. The current cycle events are rated again and consume from the free resources granted on February 1.

Figure 3-12 Post Rerating Balance Impacts

Description of ''Figure 3-12 Post Rerating Balance Impacts''

Important:

If rollover correction is not enabled, rerating is not triggered to rerate the current cycle events. Therefore, current cycle events remain rated as free even if their rollover has been consumed by delayed events. By default, rerating and rollover correction for delayed events is disabled.

Note:

When delayed call detail records (CDRs) borrow from allocated rollover credit and there is a credit monitoring threshold, the monitoring results may be inaccurate until rerating is run. That is because some current CDRs appear to be free when they are not.

To enable rerating and rollover correction, you must do the following:

• Modify configurable business parameters.

  See "Modifying Business Parameters to Enable Rerating and Rollover Correction".

• Configure event notification.

  See "Configuring Event Notification for Rerating and Rollover Correction".

Modifying Business Parameters to Enable Rerating and Rollover Correction

To enable rerating and rollover correction, you must modify a field in the billing instance of the /config/business_params object by using the pin_bus_params utility as follows (for information on this utility, see pin_bus_params in BRM System Administrator's Guide):

1. 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 working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

2. Search the XML file for the following line:

   <RerateDuringBilling>disabled</RerateDuringBilling>
   

3. Change disabled to enabled.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

4. Search the XML file for following line:

   <RolloverCorrectionDuringBilling>disabled</RolloverCorrectionDuringBilling>
   

5. Change disabled to enabled.

6. Save the file as bus_params_billing.xml and close the file.

7. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

8. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description for pin_bus_params in BRM Developer's Guide.

9. 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" in BRM Developer's Guide.

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

11. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

For information about setting the length of the delayed billing period, see "Setting Up Delayed Billing".

Configuring Event Notification for Rerating and Rollover Correction

If rerating and rollover correction is enabled and delayed events borrow from the rollover of the current cycle, BRM rerating uses event notification to trigger automatic rerating of the event.

BRM rerating generates the non-persistent /event/notification/rollover_correction/rerate event specifically to use for event notification in this case.

By default, when this event occurs, BRM creates a rerate job.

To enable event notification for rerating and rollover correction, you must configure the event notification feature as follows:

1. If your system has multiple configuration files for event notification, merge them. See "Merging Event Notification Lists" in BRM Developer's Guide.

2. Ensure that the merged file includes the following information from the BRM_Home/sys/data/config/pin_notify file:

   # Rerating related event notification
   3787    0    /event/notification/rollover_correction/rerate
   

3. (Optional) If necessary to accommodate your business needs, add, modify, or delete entries in your final event notification list. See "Editing the Event Notification List" in BRM Developer's Guide.

4. (Optional) If necessary to accommodate your business needs, create custom code for event notification to trigger. See "Triggering Custom Operations" in BRM Developer's Guide.

5. Load your final event notification list into the BRM database. See "Loading the Event Notification List" in BRM Developer's Guide.

For more information, see "Using Event Notification" in BRM Developer's Guide.

Configuring the BRM Cutoff Time

By default, BRM defines the business day as starting at 12:00:00 a.m. and ending at 11:59:59 p.m. For example, if you run billing at any time on December 5, billing is performed for all activity that occurred until 11:59:59 p.m. on December 4 for the accounts to be billed.

You can change the cutoff time to start your billing activity at any time of the day. For example, if you set the cutoff time to 10 a.m., activity for events that occurred before 10 a.m. are billed.

Figure 3-13 shows how billing works for different cutoff times:

Figure 3-13 Billing Cutoff Time

Description of ''Figure 3-13 Billing Cutoff Time''

Changing the cutoff time does not just change how billing works; it changes how all activities in BRM work, including accounting and billing cycles, usage rating, cycle fees, proration, general ledger posting, and searches. The cutoff time is used for all accounts across all brands.

Important:

Ensure that you have a very good reason for changing the cutoff time. Changing the cutoff time can add complexity to your system. For example, if your cutoff time is 10 a.m. and you search for events between February 1 and February 26, the search finds events from 10:00:00 a.m. on February 1 to 9:59:59 a.m. on February 26. Events that occurred before 10:00:00 a.m. on February 1 are not displayed. All events that occurred until 9:59:59 a.m. on February 27 are displayed, even though you searched for events that occurred through February 26.

How Billing and Invoicing Are Affected by Changing the Cutoff Time

• The start and end dates for accounting and billing cycles are based on the cutoff time. For example, if the cutoff time is 10:00 a.m., a customer who registers for an account at 9:00 a.m. on December 5 has a billing date of December 4.

• The following utilities run by the pin_bill_day script use the cutoff time to calculate the billing periods:

  • pin_deferred_act

  • pin_bill_accts

  • pin_collect

  • pin_refund

  • pin_inv_accts

  • pin_deposit

  • pin_cycle_fees

• When searching for accounts, the pin_inv_accts, pin_inv_send, and pin_inv_export utilities use the cutoff time to calculate the start and end times for flagging accounts to be invoiced.

How Rating Is Affected by Changing the Cutoff Time

• When you define start and end times for any price list element: for example, the start and end times for a discount: BRM uses the cutoff time. For example, if you specify that a discount is valid until December 5 and the cutoff time is 10:00 a.m., the discount is valid until 10:00 a.m. on December 5.

• You can set up special rates for events that occur on certain days. BRM uses the cutoff time to determine which day an event is assigned to.

How General Ledger (G/L) Is Affected by Changing the Cutoff Time

When searching for events for collecting G/L information and generating G/L reports, the pin_ledger_report utility uses the cutoff time to calculate the start and end times for the G/L report.

How Searches Are Affected by Changing the Cutoff Time

• Event Browser uses the cutoff time for searching. For example, if your cutoff time is 10:00:00 a.m. and you search for events that occurred on December 5, Event Browser displays events that occurred from 10:00:00 a.m. on December 5 to 9:59:59 a.m. on December 6.

• Payment Tool uses the cutoff time to display bill information. For example, if your cutoff time is 10:00:00 a.m. and you search for bills created on December 5, Payment Tool displays bills created from 10:00:00 a.m. on December 5 to 9:59:59 a.m. on December 6.

How TimeStamp Fields Are Affected by Changing the Cutoff Time

Many BRM features use time stamps to determine how to perform activities. Time stamps are usually rounded to midnight. If you change the cutoff time, the time stamp is rounded to the cutoff time instead.

Note:

The cutoff time is also considered while setting the time-stamp values for the start and end dates through Customer Center.

These fields affect the accounting cycle dates:

• PIN_FLD_ACTG_LAST_T

• PIN_FLD_ACTG_NEXT_T

• PIN_FLD_ACTG_FUTURE_T

These fields affect rating and proration:

• PIN_FLD_PURCHASE_START_T

• PIN_FLD_PURCHASE_END_T

• PIN_FLD_USAGE_START_T

• PIN_FLD_USAGE_END_T

• PIN_FLD_CYCLE_START_T

• PIN_FLD_CYCLE_END_T

These fields affect billing cycle dates:

• PIN_FLD_LAST_BILL_T

• PIN_FLD_NEXT_BILL_T

Configuring the Billing Cutoff Time

Caution:

After you set the cutoff time, you cannot change it in a production system.

To configure the billing cutoff time, perform the following steps:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Set the timestamp_rounding entry to 1.

3. Save and close the file.

4. Use the following command to create an editable XML file for the BusParamsBilling parameter class:

   pin_bus_params -r BusParamsBilling bus_params_billing.xml 
   

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

5. Search the XML file for following line:

   <BillingCycleOffset>0</BillingCycleOffset>
   

6. Change 0 to the desired cutoff time. For example, to set the cutoff time to 10:00 a.m., change 0 to 10. The default for this field is 0, which is equivalent to 12:00 a.m.

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

7. Save the file as bus_params_billing.xml and close the file.

8. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

9. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description for pin_bus_params in BRM Developer's Guide.

10. 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" in BRM Developer's Guide.

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

12. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

Setting Up Billing for Sponsorship

By default, when billing is run, bill units are billed in this order:

1. All nonpaying child bill units in all accounts.

2. All remaining bill units in all accounts.

If you have sponsor groups or resource sharing groups in your BRM system, you must reconfigure your system to bill accounts in this order:

1. All nonpaying child bill units in all accounts.

2. All remaining discount group member bill units in all member accounts.

3. All remaining sponsored and charge sharing group member bill units in all member accounts.

4. All remaining bill units in all accounts.

This ensures that billing is run for all member accounts before it is run for any sponsor or resource sharing group owner account.

Caution:

If you do not reconfigure your system, sponsor owner accounts might be billed before some of their member accounts. When this occurs, the members' sponsored charges are not included in the owner's bill for the current billing cycle. Instead, they are added to the owner's bill for the next billing cycle.

To set up billing for sponsor groups, you modify a field in the billing-flow instance of the /config/business_params object.

You modify the /config/business_params object by using the pin_bus_params utility. For information on this utility, see pin_bus_params in BRM Developer's Guide.

Note:

The following setups ensures that two-level sponsor relationships are correctly billed. For sponsor relationships that exceed two levels, the billing sequence may be incorrect, thus resulting in incorrect billing.

For example, suppose account A sponsors a group to which account B belongs and account B sponsors a group to which account C belongs. Owner account A and member account B will be billed in the correct order: member before owner. Owner account B and member account C, however, might not be billed in the correct order. This happens because B is an owner of account C's group, and a member of account A's group. As a member, it will be billed at the same time all other member accounts are billed and thus might be billed before account C.

To set up billing for charge sponsor groups:

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

   pin_bus_params -r BusParamsBillingFlow bus_params_billing_flow.xml 
   

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

2. Search the XML file for following line:

   <BillingFlowSponsorship>undefined</BillingFlowSponsorship>
   

3. Change undefined to one of the following:

   • sponsorsFirst if you want sponsor group accounts to be billed before the member accounts.

   • sponsoreesFirst if you want the member accounts to be billed before the sponsor group accounts.

   If the billing order of the sponsor group account and member accounts does not matter, keep the original setting of undefined.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing-flow 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 BRM's billing configuration.

4. Save the file as bus_params_billing.xml and close the file.

5. Go to the BRM_Home/sys/data/config directory which includes support files used by the pin_bus_params utility.

6. Use the following command to load this change into the appropriate /config/business_params object.

   pin_bus_paramsPathToWorkingDirectory/bus_params_billing.xml
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To execute it from a different directory, see the description for 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" 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.

9. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.

To set up billing for discount sponsor groups:

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

   pin_bus_params -r BusParamsBillingFlow bus_params_billing_flow.xml 
   

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

2. Search the XML file for following line:

   <BillingFlowDiscount>undefined</BillingFlowDiscount>
   

3. Change undefined to one of the following:

   • discountParentsFirst if you want discount group owner accounts to be billed before the member accounts.

   • memberDiscountFirst if you want the member accounts to be billed before discount group owner accounts.

   If the billing order of the discount group owner and member accounts does not matter, keep the original setting of undefined.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing-flow 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 BRM's billing configuration.

4. Save and close the file.

5. Use the following command to load the change into the /config/business_params object:

   pin_bus_params bus_params_billing_flow.xml 
   

   You should execute this command from the BRM_Home/sys/data/config directory, which includes support files used by the utility. To execute it from a different directory, see pin_bus_params in BRM System Administrator's Guide.

6. 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" in BRM Developer's Guide.

7. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

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

For more information about sponsor groups, see "About Account Groups" in BRM System Administrator's Guide.

Setting Up Billing to Run in a Multischema Environment

You can run billing in a multischema BRM environment on one database schema at a time by using one instance of the billing utilities or on multiple schemas simultaneously by using multiple instances of the billing utilities. In other words, to bill accounts on a specific database schema, you must run the billing utilities from that database schema.

For instance, to bill accounts that reside on the primary and secondary database schemas, you can run the billing utilities from the primary schema to bill the accounts that reside on the primary database schema and run another instance of the billing utilities from the secondary schema to bill the accounts that reside on the secondary database schema.

Note:

When running the pin_bill_day script with the -file option, ensure that the accounts specified in the billing run configuration file reside on the same database schema where pin_bill_day is run. If the file contains accounts from different database schemas, pin_bill_day reports an error. See "Manually Running the pin_bill_day Script".

Running Billing on One Schema at a Time

Running billing utilities on multiple database schemas one at a time requires that you edit the billing utility configuration file before each time you run the billing utilities. Perform the following steps before each time you run billing:

1. Open the billing utility configuration file (BRM_Home/apps/pin_billd/pin.conf) in a text editor.

2. Change the value of the userid entry to the database schema against which you want to run billing. For example, to run billing on the 0.0.0.2 schema, change the userid entry as follows:

   - - userid 0.0.0.2 /service/pcm_client 1
   

3. Change the value of the login_name entry to an account that resides in the schema against which you want to run billing. For example, to run billing using the account root.0.0.0.2, change the login_name entry as follows:

   - nap login_name root.0.0.0.2
   

4. Save and close the file.

5. Run the billing utilities.

Running Billing on Multiple Schemas Simultaneously

Running billing on multiple database schemas simultaneously requires that you create parallel instances of the billing utility configuration files, each of which is configured for a particular schema. Then you run all instances of your billing utilities.

1. For each schema that you want to run billing on, create a subdirectory under BRM_Home/apps/pin_billd.

   For example, BRM_Home/apps/pin_billd/db1 for database 1, BRM_Home/apps/pin_billd/db2 for database2, and so on.

2. Copy the BRM_Home/apps/pin_billd/pin.conf file into each new subdirectory.

3. In each billing subdirectory, do the following:

   1. Open the pin.conf file.

   2. Change the database number in the login_name entry to a database account that resides in the schema against which you want to run billing. For example, to run billing against schema 0.0.0.2, change the login_name entry as follows:

      - nap login_name root.0.0.0.2
      

   3. Save and close the file.

4. Run the billing utilities from the new subdirectories.

About Suspending Billing of Accounts and Bills

By default, BRM generates bills for all bill units in all accounts. When you run billing in BRM, active accounts as well as inactive and closed accounts are billed. However, you may have accounts or account bill units in your system that you do not want to bill.

You can resume billing on suspended accounts.

For information about suspending bill units in your custom application, see "Suspending and Resuming Billing of Closed Accounts".

Tip:

By excluding accounts or bill units that do not need to be billed, you can reduce the time it takes to complete your billing run.

Note:

• If you suspend a parent account, all nonpaying child accounts are also suspended.

• To suppress billing, see "About Suppressing Bills". Unlike bill and account suspension, bill suppression does not inactivate bill units.

• For information about another way to reduce the duration of your billing run, see "Reducing Billing Run Loads".

Suspending Billing of Closed Accounts

By default, you can configure BRM to enable or disable billing of closed accounts. When billing of closed accounts is disabled, BRM excludes closed accounts from the billing run when the following conditions are met:

• The account's total balance due for every bill unit is zero.

  Note:

  For hierarchical accounts, the total balance due includes the totals from the subordinate bill unit of their child accounts.

• The account has had no billable activity since the previous bill.

To customize this default behavior, modify the PCM_OP_BILL_POL_POST_BILLING policy opcode.

To configure billing of closed accounts:

1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf) in a text editor.

2. Do one of the following:

   • To disable billing of closed accounts, set the value of stop_bill_closed_accounts entry to 1:

     - stop_bill_closed_accounts 1
     

   • To enable billing of closed accounts, set the value of stop_bill_closed_accounts to 0.

   By default, billing of closed accounts is enabled.

3. Save and close the file.

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

For information about configuration files, see "Using Configuration Files to Connect and Configure Components" in BRM System Administrator's Guide.

Suspending Billing of an Account's Bill

If you have additional bill units in accounts that you do not want to bill, such as inactive bill units, you can customize BRM to suspend billing of those bill units. See "Suspending and Resuming Billing of Closed Accounts".

Setting up Billing in Subordinate Hierarchies

If you use the subordinate hierarchy, BRM validates that all subordinate accounts have been billed successfully before billing the parent account. When billing fails for a subordinate account, the parent account is not billed. However, in rare instances when the subordinate account billing is continuously failing and you want to proceed with parent account billing, you can skip the validation of the subordinate account billing by enabling the SkipCheckForSubordinatesBilled parameter in the billing instance of the /config/business_params object.

You modify the /config/business_params object by using the pin_bus_params utility. For information on this utility, see "pin_bus_params" in BRM Developer's Guide.

To skip validation of the subordinate account billing:

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

2. Run 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 working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

3. Open the bus_params_billing.xml.out file.

4. Search the XML file for the following line:

   <SkipCheckForSubordinatesBilled>disable</SkipCheckForSubordinatesBilled>
   

5. Change disable to enable.

   • disable: BRM validates that the subordinate accounts have been billed successfully before billing the parent account. This is the default.

   • enable: BRM skips the validation of the subordinate account billing and bills the parent account.

     Note:

     When SkipCheckForSubordinatesBilled is enabled and subordinate account billing has errors, the parent bill will not include charges from the subordinate account.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing 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 BRM's billing configuration.

6. Save the file as bus_params_billing.xml.

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

8. Run the command:

   pin_bus_params PathToWorkingDirectory/bus_params_billing.xml 
   

   where PathToWorkingDirectory is the directory in which bus_params_billing.xml resides.

   Note:

   To run this command from a different directory, see the description for "pin_bus_params" in BRM Developer's Guide.

9. 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 testnap" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects by Using Object Browser" in BRM Developer's Guide.

10. Stop and restart the CM. See "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

11. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb" in BRM System Administrator's Guide.