15 Creating Packages and Package Lists

Learn how to create packages and package lists to offer your services to customers in Oracle Communications Billing and Revenue Management (BRM).

Topics in this document:

Creating Packages

A package is a collection of bundles. You use packages to offer your services to customers. For example, if your company sells broadband access, email, and IP fax service, you might offer the following packages:

  • A package that sells only broadband access
  • A package that sells broadband access and email
  • A package that sells email and IP fax service

Figure 15-1 shows how you can include bundles and the services to which they apply in a variety of packages.

Figure 15-1 A Bundle Can Be Included in Multiple Packages

Description of Figure 15-1 follows
Description of "Figure 15-1 A Bundle Can Be Included in Multiple Packages"

A package can contain any number of bundles, and two different packages can share the same bundle. By grouping bundles into packages, you simplify the choices presented to your customers.

You have the following options when creating packages:

  • Bill customers when the package is purchased. Usually, you bill a customer at the end of the customer's billing cycle. On-purchase billing, however, enables you to bill a customer immediately for a purchase, even if the customer's billing cycle has not ended. When you create a package, you can flag it for on-purchase billing. When a customer purchases a package that is flagged for on-purchase billing, a bill is generated immediately for the purchase fees associated with the package.

    Note:

    On-purchase billing works with purchase fees only. It does not work with recurring, usage, or cancellation fees.

  • Activate all offers in the package when the first service is used. You can specify to activate all offers in a package when any of the offers are activated on first usage. For example, assume a package includes bundle 1 with offers A and B, and bundle 2 with offer C. If the first service a customer uses is in charge offer B on 15 May, all offers (A, B, and C) are activated on 15 May.

  • Configure required and optional bundles in a package. Required bundles are automatically purchased when a package is purchased. By default, all bundles are required. Optional bundles can be purchased at a later time.

  • Restrict discounts in a package. When creating a package, you can prohibit specified discount offers from being purchased or used while the package is owned.

    If an exclusion relationship exists between a discount offer and a package, a customer can own the discount offer or the package, but not both. Further, the customer cannot own any discount offers associated with the package if the customer owns the excluded discount offer.

    See "Configuring Mutually Exclusive Discount Offers" for information about configuring discount exclusion.

  • Set values for any product specification attributes defined in XML templates. See "Configuring Product Specification Attributes for Pricing Components".

See the following topics for more package configuration features:

Associating Terms with Packages

You can associate your packages with subscription terms, which govern the agreement between you and the customer who purchases the package. When a customer purchases a package with subscription terms, it becomes a contract.

Note:

Adding terms to packages is supported only by BRM 12.0.0.3.0 with Interim Patch 31426340 and later, and PDC 12.0.0.3.0 with Interim Patch 31426374 and later.

Subscription terms specify the commitment period, whether customers are allowed to cancel their contract early, and whether customers are charged an early termination fee for doing so.

A package's terms apply to all required bundles in the package, but any optional bundles are governed by their own, independent terms. See "About Bundle Terms and Package Terms".

Grouping Services

In packages, you can combine services into service groups. A service group consists of one subscription service, and one or more member services. For example, if the subscription service is GSM, the member services could be Voice and SMS.

Service groups provide the following benefits:

  • Member services can benefit from discounts owned by the subscription service.

  • Member services can be associated with the devices owned by the subscription service.

  • Customers can purchase services as a group.

The subscription service can be a service that subscribers use, such as telephony or broadband access, or it can be a representational service with no associated usage fees. Together, the subscription service and member services form a service group.

For example, in Figure 15-1, the GSM service is a subscription service, and SMS and Voice are its member services.

Grouped services usually apply to a particular device, such as a cable box. An account can contain multiple service groups.

To subscribe to a service group, customers subscribe to its subscription service.

Transitioning between Packages

You can configure rules for transitioning from one package to another. Each transition rule applies to a particular service. The package being transitioned to and the package being transitioned from must both contain that service, though each package can contain additional services that the other package does not contain.

PDC supports the following types of transitions:

  • Upgrade to a package that is typically more expensive and has more features. For example, a customer might transition from a package that provides broadband and cable TV services to a package that provides broadband, cable TV, and VOIP services. That transition adds a service and a bundle and possibly changes the bundles for the existing services.

  • Downgrade to a package that is typically less expensive and has fewer features.

Transitions enable you to limit the packages that customers can switch to while remaining fully provisioned. When transitioning to a designated package, your customers retain their devices, such as phone numbers, and their services.

Prorating Charges During Package Transitions

You can also configure how PDC handles charges when customers transition packages in the middle of their billing cycle. Charges can be applied from the original package, applied from the new package, or prorated for both packages. For example, assume a customer's billing day of month (DOM) is the 15th and on June 30 he transitions from Package A to Package B. If you configure PDC to:

  • Prorate the charges, the customer's July 15 bill would include charges for Package A prorated from June 15 through June 30, and charges for Package B prorated from July 1 through July 14. This is the default.

  • Apply charges from the original package, the customer's July 15 bill would contain charges for Package A only.

  • Apply charges from the new package, the customer's July 15 bill would contain charges for Package B only.

You configure how to prorate charges during package transitions by using the following:

  • The PDC UI. See "Defining Transition Rules for Bundles" in PDC Online Help.

  • The ImportExportPricing utility. In your input XML file, set the <prorationType> element under the <packageTransition> element to one of the following:

    • PRORATE_CHARGE: Specifies to prorate charges for both packages. This is the default.

    • ORIGINAL_CHARGE: Specifies to apply the full charges from the original package.

    • TRANSFER_CHARGE: Specifies to apply the full charges from the new package.

For information, see "Transitioning Bundles".

Defining Generation Changes

A generation change enables you to transition customers between 2G (second generation) and 3G (third generation) wireless packages and services. Packages are called 2G or 3G depending on whether the wireless service they provide runs on a 2G or 3G wireless network.

When creating a 2G or 3G package, you can set up generation change rules to specify which packages can replace the package when it is transitioned to a different generation.

For generation changes, the packages do not have to provide the same service.

Note:

The same package cannot be used in both a transition rule and a generation change.

Creating Package Lists

A package list is a group of packages that is usually offered to a single type of customer. For example, you might create the following package lists:

  • A package list that includes packages for customers above a certain age.

  • A package list that includes packages for customers in a particular location, such as Canada.

  • A package list that includes promotional discounts offered for a limited time.

You can create any number of package lists, and each package list can contain any number of packages. Different package lists can contain the same package.

The package list does not have to include all your packages. You can create packages and not include them in a package list until you need them. Or you can offer one set of packages to one group of potential customers and another set of packages to another group.

To make a package available for customers to purchase, you must include the package in a package list.

You can assign the following statuses to a package list:

  • Active: Use this status to indicate that customers can purchase packages in the list as soon as the list is added to your system.

  • Inactive: Use this status to indicate that the list is not visible to customers and customers cannot purchase packages from the list.

Specifying the Package List Segment and Type

The package list segment identifies the customer segment that the package list is offered to, and the package list type identifies the type of packages that are added to the package list.

The package list segment and type determines the package list name. By default, the package list segment must be CSR. The package list type can be either New or Add-on. For example:

  • The CSR-New package list contains packages that create accounts and add the services and bundles in the packages to the new accounts.

  • The CSR-Add-on package list contains packages that add services and bundles to existing accounts.

The package list segment and type are case sensitive and together uniquely identify package lists. For example, CSR-New and CSR-new are two different package lists.