Setting Up Delayed Billing

About Delayed Billing

You can set up BRM to delay billing for accounts after the end of a billing cycle. This is called delayed billing. Delayed billing essentially extends a billing cycle by the delay interval. You use delayed billing to bill for events that occur within a billing cycle but are not recorded during that cycle.

For example, if a batch of events does not arrive until after the end of the billing cycle, you delay billing until all events in the batch are recorded in the BRM database. When you use delayed billing, billing for all the accounts in your BRM system is delayed for the same amount of time; you cannot specify multiple billing delay periods.

Figure 7-1 shows that with delayed billing, the billing date occurs after the original billing date, during the next accounting cycle.

Figure 7-1 Delayed Billing Timeline

Description of "Figure 7-1 Delayed Billing Timeline"

Note:

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

When your system is set up to use delayed billing, an account is created with two pending bills, one for the current cycle and one for the next cycle, which are combined in the balance seen in Billing Care or Customer Center. The combined pending bill includes separate items for the previous accounting cycle and for the next accounting cycle. When the bill for the current cycle is finalized at the end of the delay interval, the system makes the bill for the next cycle to be the current bill and creates a new bill for the next cycle.

The BRM system automatically triggers billing inside the delay interval when it detects that a new event has occurred for the next billing cycle. When billing is triggered during the delayed billing period, the bill for the previous cycle is partially processed (partial billing), but the bill is not finalized.

BRM performs partial billing to enable the new event to be rated and applied to the correct billing period. Partial billing ensures that new events impact bill items of the next billing cycle and old events impact bill items of the previous billing cycle. BRM maintains an internal list of bill items for the previous and next bill cycles. The bill for the previous cycle is finalized (final billing) after the delay interval.

During partial billing, BRM does the following:

Applies deferred cycle forward fees to the next billing cycle.
Applies cycle arrears fees to the previous billing cycle.
Applies cycle forward fees.
Applies cycle rollovers.

During final billing, BRM does the following:

Applies cycle discounts (billing time discounts).
Applies cycle folds.
Applies cycle taxes.
Calculates a /bill object for the previous billing cycle.
Initializes the next billing cycle.
Creates a new empty /bill object for the next billing cycle with default and pre-created items.

The following example is illustrated in Figure 7-2:

An account's billing date is January 1 and the billing delay interval is five days.
On January 2, a new usage event for the account occurs for the next billing cycle.
To ensure that the new usage event impacts items in the next billing period (B2), BRM performs partial billing.
On January 6, final billing is run for the previous billing cycle (B1) by running the billing utility; the status of all the bill items for the previous bill is changed to open so that they stop accumulating charges.

Figure 7-2 Partial and Final Billing Timeline

Description of "Figure 7-2 Partial and Final Billing Timeline"

When you use delayed billing, auto-triggered billing is disabled for all but the delay interval and only the last two days of each bill unit's accounting cycle.

When a bill-triggering event occurs during the delayed billing period, BRM auto-triggers partial billing and, if final billing has not occurred before the last two days of the next billing cycle, BRM auto-triggers final billing. This ensures previous billing is run before the next billing run occurs.

For example:

An event for the next billing cycle is recorded after the billing delay interval on January 7.
The BRM system detects that the delay period is over but final billing for the previous billing cycle has not occurred yet.
- If auto-triggered billing is disabled (the default when delayed billing is configured), BRM does not run final billing on January 7. In this case, the delay interval is virtually extended until final billing is performed by running the billing utility or auto-triggered during the last two days of the next accounting cycle.
- If auto-triggered billing is enabled, BRM auto-triggers final billing for the previous billing cycle on January 7.
  Note:
  - You can change auto-triggered billing to be always enabled when delayed billing is used by setting the auto_triggering_limit parameter to 0.
  - You can also change the number of days auto-triggered billing is enabled at the end of each accounting cycle.

Delayed Billing and Rollovers

If you enable 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.

Changing the Billing DOM When Delayed Billing is Enabled

If you change a customer's billing DOM during the delayed billing period, BRM defers the DOM change until after the delay interval ends. This ensures that the change to the billing DOM occurs in the future billing cycle. For example, assume that a customer's billing DOM is 1 and the delay interval is 5, making the billing date for the first three months of the year to be January 1, February 1, and March 1. If on January 3 the customer changes the billing DOM to 15, BRM defers making the change until January 6 (January 1 plus 5 days). This changes the billing date for the first three months to January 1, February 1, and March 15.

Note:

To have the billing DOM change deferred until after the delay interval, auto-triggered billing must be disabled; otherwise, the billing DOM change occurs immediately. For example, changing the billing DOM to 15 on January 3 would change the billing date to February 15.

How BRM Assigns Delayed Events to Items

In BRM, every event object is associated with a bill item. When delayed events are rated by ECE, some of the events need to be assigned to the next accounting cycle. BRM pre-creates items in the following cases:

When an account is created.
When you run billing.
When a CSR uses Bill Now.
At the end of the accounting cycle when you use delayed billing.

To choose the correct bill item, ECE can do one of the following:

Assign the event to the current open bill item.
Assign the event to the next open bill item.

To decide which item to apply the bill to, ECE takes into account the following dates:

The date when the call occurred.
The current system date.
The date when the current accounting cycle ends. This is called the next accounting cycle date.
The number of days after the current accounting cycle ends when delayed billing runs. This number is called the delayed billing offset.

To assign the event to an item:

If the event date falls before the next accounting date, the event is assigned to the current item.
If the event date falls after the next accounting date, the event is assigned to the next item. This can happen because the event might occur after the close of the accounting cycle but before the delayed billing offset date.

Figure 7-3 shows how events are assigned:

Figure 7-3 Event Assignment

Description of "Figure 7-3 Event Assignment"

Note:

The customer billing date is not relevant when choosing which item to use for the event. There might be multiple accounting cycles in one billing cycle. New items are created for each accounting cycle.

If ECE needs to assign an event to the current item, but billing for that item has already occurred, ECE includes the event and assigns it to the current item. For example, if the event is rated on May 20 and loaded after the account cycle ends, it is still included in the current item as shown in Figure 7-4.

Figure 7-4 Current Event Assignment after Billing

Description of "Figure 7-4 Current Event Assignment after Billing"

Configuring Delayed Billing

By default, delayed billing is enabled. You can configure delayed billing by setting the ConfigBillingDelay parameter using the pin_bus_params utility. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.

To configure delayed billing:

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

Create an XML file from the /config/business_params object:

pin_bus_params -r BusParamsBilling bus_params_billing.xml

In the XML file, enter a value greater than 0:
```
<ConfigBillingDelay>D[:H]</ConfigBillingDelay>
```
where D is the number of days and H is the number of hours. Leading zeros are allowed when specifying the delay interval.

For example:
- 0:12 sets billing delay interval to 12 hours.
- 2 sets billing delay interval to 2 days.
- 1:3 sets billing delay interval to 1 day and 3 hours.
- 01:03 also sets billing delay interval to 1 day and 3 hours.
- 0 sets the billing delay interval to zero.
Note:
- To use delayed billing, set ConfigBillingDelay to a value ranging from 1 to 27. The length of the billing delay interval must be shorter than one accounting cycle.
- If you do not want use delayed billing, set ConfigBillingDelay to 0.
- To disable delayed billing, set this parameter to -1. This is supported for backward compatibility.
Caution:

You can change the value of ConfigBillingDelay at any time. However, after you begin rating events in a production database, do not reset this parameter. Doing so might cause database errors.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_billing.xml
```
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Configuring 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 specify auto-triggered billing to be enabled for more than two days at the end of each accounting cycle, or you can specify that it is always enabled when delayed billing is used.

To change this feature, run the pin_bus_params utility to change the AutoTriggeringLimit business parameter. For information about this utility, see BRM Developer's Guide.

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:

Go to BRM_home/sys/data/config.

Create an XML file from the /config/business_params object:

pin_bus_params -r BusParamsBilling bus_params_billing.xml

In the XML file, change the number of days for which auto-triggered billing is enabled at the end of each 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.

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.
```
<AutoTriggeringLimit>10</AutoTriggeringLimit>
```
Save the file as bus_params_billing.xml.
Load the XML file into the BRM database:
```
pin_bus_paramsbus_params_billing.xml
```
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Configuring an Accounting Cycle Delay Period

In offline charging, the following scenario can occur:

The event is rated by Offline Mediation Controller.
Before the event is loaded by Rated Event Loader (RE Loader), billing is run.
RE Loader must find the item that the event applies to and apply the balance impact.

Delayed billing assigns delayed events to items of the billing cycle in which they occurred. However, in the scenario described above, you might need to assign the delayed events to the accounting cycle in which they occurred. To assign delayed events to items of the accounting cycle in which they occurred, you configure an accounting cycle delay period. You can do this to enable accurate general ledger reporting.

When a billing cycle spans multiple accounting cycles, the items for those accounting cycles are not closed until billing is run. If you run a general ledger (G/L) report at the end of an accounting cycle for which billing has not yet been run, the status of the revenue in the G/L can change if additional events are rated and loaded for that cycle before the accounts are billed.

If you require that G/L data not change after the G/L report is run, you can configure an accounting cycle delay period after which events are no longer assigned to items of that accounting cycle, even if those items are not closed. You then run G/L reports after the accounting cycle delay period has ended. This ensures that the revenue reported in the G/L is accurately represented and that the state of the revenue (earned, unearned, billed, and unbilled) does not change after the G/L report is run.

When you configure an accounting cycle delay period, BRM assigns delayed events to items based on when the accounting cycle delay period ends. BRM assigns events to items when RE Loader loads the events into the database:

When delayed events (events that occurred in the previous cycle) are loaded after the accounting day of month (DOM), but before the end of the accounting cycle delay period, those events are posted to the item for which the DOM has just passed as shown in Figure 7-5:

Figure 7-5 Delayed Events Arriving During Cycle Delay Period

Description of "Figure 7-5 Delayed Events Arriving During Cycle Delay Period"

When the billing cycle has ended and delayed events are loaded after the end of the accounting cycle delay period, but before delayed billing is run, those events are posted to the item for the next (current) accounting cycle, even though the previous cycle has not been billed and its items are still pending. This is shown in Figure 7-6:

Figure 7-6 Delayed Events Arriving After Cycle Delay Period

Description of "Figure 7-6 Delayed Events Arriving After Cycle Delay Period"

After the account is billed, items for the billed cycle are closed so delayed events are posted to the item for the following (the current) cycle.

Note:

If the accounting cycle delay period is longer than the delayed billing period, the accounting cycle delay period is ignored after billing is run. After billing is run, if any remaining events that occurred in the previous cycle are rated and loaded in the current cycle, they are assigned to the current cycle's item.

You specify the accounting cycle delay period by running the pin_bus_params utility to change the AcctCycleDelayPeriod business parameter. For information on this utility, see BRM Developer's Guide.

To configure an accounting cycle delay period:

Go to BRM_home/sys/data/config.

Create an XML file from the /config/business_params object:

pin_bus_params -r BusParamsBilling bus_params_billing.xml

In the XML file, change -1 to the number of days in the accounting cycle delay period. The number of days must be a positive value. (A value of -1 indicates that there is no accounting cycle delay period.):
```
<AcctCycleDelayPeriod>3</AcctCycleDelayPeriod>
```
Note:

Do not set the accounting cycle delay period to be longer than the delayed billing period.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_billing.xml
```
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see 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 balances 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.

When you used delayed billing, the BRM system provides the flexibility to specify when to charge cycle forward fees and when to roll over balances. You can specify to charge cycle forward fees and roll over balances during either partial billing or final billing by setting the delay_cycle_fees entry in the CM configuration file (pin.conf).

Note:

New events that occur inside the billing delay interval are rated and recorded for the next billing cycle. If cycle forward fees and rollover balances 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:

Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
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.
Save the file.
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.

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:

Open the billing utility configuration file (BRM_home/apps/pin_billd/pin.conf) in a text editor.
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 ConfigBillingDelay business parameter is set to a number greater than zero. See "Configuring Delayed Billing" for more information.
Save the file.
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 bundle 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:

Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
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 bundles 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.
Save the file.
Stop and restart the CM.

Billing Cycle Override for Delayed Billing

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:

Go to the BRM_home/sys/data/config directory.
Create an XML file from the /config/business_params object:
```
pin_bus_params -r BusParamsRerate bus_params_billing.xml
```
This command creates an XML file named bus_params_billing.xml.out in your working directory.
Open the bus_params_billing.xml.out file.
Set the ConfigBillingCycle parameter to the amount of time after a billing cycle ends that new events are included in the previous month's bill:
```
<ConfigBillingCycle>days</ConfigBillingCycle>
```
where days is the number of days after a billing cycle ends. For example, enter 5 for 5 days.
Note:
- The ConfigBillingCycle value must be greater than zero and less than or equal to the delayed billing interval value (set in the ConfigBillingDelay business parameter). Otherwise, BRM reports an error and terminates the CM. For information about setting the delayed billing interval, see "Configuring Delayed Billing".
- 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.
Save and rename the file as bus_params_billing.xml.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_billing.xml
```
Stop and restart the CM.
(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.
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 "Customizing How to Bill Events That Occur between Billing Cycles" in BRM Opcode Guide.