Configuring Bundle and Package Transitions

Transitioning Bundles

You can set up transitions that determine which bundles can be purchased subsequent to another bundle.

To transition bundles, you use PDC or Pricing Center to set up transition rules, which are applied when you upgrade or downgrade a bundle for a customer. This enables you to limit the bundles that customers can switch to and still remain fully provisioned.

A bundle cannot be transitioned under the following circumstances:

The new bundle is mutually exclusive to a bundle currently in the account.
The account is missing a necessary prerequisite bundle.
The bundle is associated with an inactive service.
The service being transitioned from and the service being transitioned to are not the same service.
The bundle is required in the associated package.

If a service was closed because it was associated with a package transition, you cannot change the closed status of the service.

To customize how to transition bundles, use the PCM_OP_SUBSCRIPTION_POL_PRE_TRANSITION_DEAL opcode. See BRM Opcode Guide.

Transitioning Packages

You specify the rules that govern the transition of an account from the source package to a target package. BRM imposes certain limitations on when accounts can transition to or from other packages. It requires you to define package transition rules for each package-to-package transition by manually configuring the transition rules in PDC or Pricing Center.

You can use the PCM_OP_SUBSCRIPTION_TRANSITION_PLAN and PCM_OP_SUBSCRIPTION_POL_PRE_TRANSITION_PLAN opcodes to customize package transitions. See BRM Opcode Guide.

When you transition accounts from one package to another package in BRM:

If the transition type is a generation change, the two packages do not have to share the same primary service. If the transition type is an upgrade or a downgrade, the two packages must share the same primary service.
If the source and target packages are a valid combination, you can configure the transition rule such that the source package retains the noncurrency grants as valid to the end of the cycle. To do so, set the value of PIN_FLD_FLAGS input to the PCM_OP_SUBSCRIPTION_TRANSITION_PLAN opcode to be PIN_SUBS_TRANSITION_CONTROL_ROLLOVER. (See pin_subscription.h.)
BRM checks the status of any add-on bundles (that are not part of the source package) owned by the account. If all add-on bundles are canceled, BRM closes the associated services and transitions the account to the target package. If the add-on bundles are not canceled, BRM returns an error and retains the source package for the account. Therefore, you must first cancel all add-on bundles owned by the account before you transition the account to the target package.

The following restrictions apply to package transitions in BRM:

You cannot backdate a package-transition or generation change to a prior period.
If you delete a service from a package, BRM closes that service and sets its status to PIN_STATUS_FLAG_DUE_TO_TRANSITION. You cannot change the status of a closed service.
BRM does not transfer extended rating attributes (ERAs) data during a package transition or a generation change. For example, if you have an account with ERA on friends and family and perform a package transition or generation change, the ERA data is not transferred to the new package.
BRM, by default, retains the credit limits associated with the source package for an account when the source and target packages for that account are associated with the same balance group but each package has different credit limits. To set new credit limits for the account, you can customize PCM_OP_CUST_POL_TRANSITION_PLAN opcode by doing the following:
1. Set the credit limit in the PIN_FLD_LIMITS array.
2. Pass this array in the input flist to the PCM_OP_SUBSCRIPTION_TRANSITION_PLAN opcode.

About Defining Package Transition Rules

You can manually configure the package transition rule for each package-to-package transition in PDC or Pricing Center. For each such package transition rule you configure, BRM creates a /transition object to store the rules.

You can perform package transitions to any package without creating transition objects. This is a useful approach because for each package in the BRM system, you need to specify all other packages to which the package can transition. For example, if you have 300 packages and each package can transition to or from any other package, you define 89,401 (299 x 299) package transition rules, thus creating 89,401 /transition objects.

In addition, every time you add a package, you must define the transition rules for each existing package to point to the new package. As a result, the number of transition rules that you need to define in PDC or Pricing Center increases in proportion to any increase in the number of packages you support.

You can perform package transitions to any package without creating /transition objects to store the transition rules.

You use the PCM_OP_SUBSCRIPTION_POL_PRE_TRANSITION_PLAN policy opcode to automatically enable package transitions to any package without /transition objects. See BRM Opcode Guide.

Defining a Generation Change for Packages

A generation change enables you to transition your customers between 2G (second generation) and 3G (third generation) wireless packages and services. Packages are called 2G or 3G depending on whether their primary service type runs on a 2G or 3G wireless network. A 3G wireless network is faster than a 2G network and can transmit video and two-way video telephone calls.

You can use any 2G or 3G service type, such as the following:

/service/telco/pdc, a 2G service type based on the Personal Digital Cellular standard for digital mobile telephony.
/service/telco/imt, a 3G service type based on the International Mobile Telecommunications (IMT) standard for 3G wireless communications.

Whether you are transitioning a customer from a 2G to a 3G package or from a 3G to a 2G package, both packages are valid all day on the day of transition. The package that is being phased out expires at 00:00:00 hours at the end of the transition day; the package being transitioned to becomes valid at 00:00:00 hours at the beginning of the transition day.

You set the transition rules between two packages. You can also set up standalone bundles as add-ons and specify that the transition rules apply to those bundles as well.

Note:

When a transition between two packages is under way, no other transition is allowed between the two packages for the duration of the transition day.
You can backdate the subscription actions to a prior period in case of a generation change, but doing so can lead to incorrect results.

For the package replacing the current package, the following happens at 00:00:00 hours at the start of the transition day:

The purchase, cycle, and usage start dates are set to 00:00:00 hours at the beginning of the transition day.
All dependent services and bundles associated with the package are included in the transition.
Any cycle fees for this package are charged from 00:00:00 hours at the beginning of the transition day to the end of the billing cycle.

Note:

Purchase and cancel fees can be configured to be waived during the transition.

The following happens at transition time or slightly after:

All configured bundles are purchased for the service.
The new service is provisioned.

For the package you are phasing out, the following happens at 00:00:00 hours at the end of the transition day:

The current service is closed.
Any dependent services are closed.
All associated charge offers and dependent services are canceled.
Forward and arrears cycle fees are prorated from the beginning of the billing cycle to the cancellation time.

Configuring Services for a Generation Change

By default, the service being phased out is active for one day, the day the generation change takes place. You can configure the number of days both services involved in a generation change are active.

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

To modify the number of days the phased-out service is active:

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 file, change 10 to the number of days you want the phased-out service to remain active (the default is 10 days).

For example, if you change the value to 15, the phased-out service remains active 15 days after generation of the new service. The minimum number of days you can keep a phased-out service active is 1 and the maximum is 31.
```
<ProdEndOffsetpackageTransition>10</ProdEndOffsetpackageTransition>
```
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.

Creating Custom Transition Types for Bundles and Packages

By default, BRM provides these transition types for packages and bundles:

Upgrade
Downgrade
Generation Change

To add custom transition types for bundles and packages:

Open the BRM_home/sys/data/pricing/example/pin_transition_type file in a text editor.
Add your custom transition types by using this syntax:
```
TransitionIDNumber    TransitionString 
```
where:
- TransitionIDNumber specifies the ID of the transition type. This value will be visible in the /transition object. Your custom ID numbers must be unique and greater than the number 100. However, they need not be in numerical order.
- TransitionString specifies the transition name that is displayed in PDC or Pricing Center.
For example, add the following line to create a custom transition type named RED:
```
101      RED
```
Save and close the file.
Go to the directory in which you saved the pin_transition_type file and enter the following command:
```
load_transition_type [TransitionTypeFile] 
```
where TransitionTypeFile specifies the name and location of the file that contains your custom transition types. By default, the utility uses the pin_transition_type file in the directory from which you run the utility.

Note:

For more information about the utility's syntax, see "load_transition_type".
Restart PDC or Pricing Center.

Your new transition types are loaded into the /config/transition_type object and are displayed in PDC or Pricing Center the next time you start it.