Managing Billing and Accounting Cycles

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 5-1.

Figure 5-1 Short Accounting Cycle

Description of "Figure 5-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 5-2.

Figure 5-2 Long Accounting Cycle

Description of "Figure 5-2 Long Accounting Cycle"

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

A short or long cycle can also occur when a customer creates an account and the billing DOM is different from the day of month when they the account is created. For example, your company might require that all customers be billed on the first day of the month. If a customer creates an account 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.

By default, BRM creates a short cycle and a one-month cycle. You can configure BRM to always create short cycles by setting the ShortCycle business paramater using the pin_bus_params utility. By default, the ShortCycle parameter is disabled. When this parameter is disabled, if the number of days in the current accounting cycle is less than 15 days, BRM creates a long cycle and adds the remaining days to the next month's accounting cycle. If the number of days in the current accounting cycle is greater than 15 days, BRM creates a short cycle.

To create short cycles:

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, set the value for the following entry to enabled:
```
<ShortCycle>enabled</ShortCycle>
```
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.

You can also 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.

To round up long billing cycles:

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

Change the value of the following entry to 1:

- fm_rate rating_longcycle_roundup_flag  1

Set the value of rounding precision to 0:

- fm_rate rating_quantity_rounding_scale 0

Save the file.
Stop and restart the CM.

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

Configuring Timestamp Rounding

By default, BRM rounds time stamps to midnight. You can configure BRM to use exact timestamps 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 timestamp rounding. Before disabling timestamp 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.
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.

To set the timestamp rounding:

Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
Set the timestamp_rounding entry to 1.
Save and close the file.

Note:

When a charge offer's purchase, cycle, and usage start and end units are set to 1 (seconds), 2 (minutes), or 3 (hours), and the validity period is less than 24 hours, time stamps are not rounded, regardless of your system configuration. If the validity is greater than 24 hours, the cycle end time stamp is rounded for the purpose of calculating the scale to determine the cycle fee amount to charge.

Aligning Account and Cycle Start and End Times

You can align 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 product offerings or when you create an account.
The delayed start and end time is a whole number, not a fraction.
The delay is measured in cycles.
The purchase, cycle, or usage start and end times are not modified when a bundle is purchased.

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

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, set the following entry to enabled:
```
<CycleDelayAlign>enabled</CycleDelayAlign>
```
Note:

If the entry is set to disabled or not set, the start and end times are not aligned.
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.

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 bundle 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 5-3 shows the cycle start time for the above example:

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

Description of "Figure 5-3 Aligning Account and Cycle Start and End Times"

Defining When Billing-Time Discounts Are Applied

BRM performs accounting operations, such as applying cycle fees, rollover, and billing-time discounts, at the end of every accounting cycle. You can configure BRM to apply billing-time discounts at the end of the billing cycle instead of the accounting cycle. You might do this, for example, when the billing cycle spans multiple accounting cycles and a billing-time discount is based on the aggregated usage for the billing cycle.

Note:

This configuration applies only to regular billing, not to bill-now and on-purchase billing.

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

To apply billing-time discounts at the end of the billing cycle:

Go to BRM_home/sys/data/config.

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

pin_bus_params -r BusParamsSubscription bus_params_subscription.xml

In the XML file, change disabled to enabled:

<BillTimeDiscountWhen>enabled</BillTimeDiscountWhen>

Save 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 BRM System Administrator's Guide.

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 the current nonpaying child bill unit balances: 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 nonpaying child bill unit balances.

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.

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

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.

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

Calculating 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 charge offer's purchase date has been backdated, you can use the CM configuration file calc_cycle_from_cycle_start_t entry to calculate fees based on the charge offer's purchase date. This feature is useful when activating an inactive charge offer.

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 charge offer. However, the cycle start time is aligned only after short and long billing cycle differences are considered.

To set the charge offer cycle start time:

Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
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 charge offer cycle start time to consider the date specified in the PIN_FLD_CYCLE_START_T field for calculating the cycle fees.
Save the file.

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