18 About Branding

This chapter provides an overview of brands and describes brand-aware functionality in a single Oracle Communications Billing and Revenue Management (BRM) system.

You must have the Brand Manager component to create and use brands.

About Managing Multiple Brands of Service

You can use BRM to host Internet services for branded service providers (BSPs). A BSP is any business that offers Internet access and other services under its own brand identity without building the infrastructure necessary to support the services. Instead, a BSP retains its own brand image and relies on a host service provider (HSP) to provide services to its subscribers.

For example, if a credit card company wants to provide Internet access to its customers under the credit card brand name, it can have an HSP supply the service. The HSP uses the credit card logo and brand image on all interfaces to the subscriber, including billing invoices and self-administration Web sites. The service subscribers never know that the Internet service they ordered from the credit card company is provided and managed by a different Internet service provider (ISP). Any corporation can use its name and customer base to offer Internet services.

You can also use the BRM branding functionality to divide one company into distinct groups, such as regional sales divisions. The only difference is that the HSP is not concealed; it controls all services and billing under its own logo and brand image because the brands are part of the same company. Each brand has its own pricing structure, general ledger (G/L) accounts, and control of the brand-specific interfaces to the BRM database. The HSP sets up and maintains each brand in a single BRM system.

An HSP can:

Create a brand, by using the BRM mechanism for keeping customer accounts and other data for a BSP separate from data for other brands in the same BRM system. See "Creating Brands".
Control which BRM personnel can access customer accounts and other data in each brand. See "Controlling Access to Top-Level Brands".
Create separate price lists for each brand. See "Creating a Price List for Brand Accounts".
Create brand-specific Web pages for customers to register and modify their accounts. See "Creating a Brand-Specific Web Page".

You need the Brand Manager component to host services for BSPs. See "When to Use Account Groups Instead of Brands" if you are not certain if your company requires branding.

Understanding Brands

A brand is implemented as a type of BRM account. You create and modify brands by using the Brand Manager component of Configuration Center.

Note:

Because brands are a type of account, you can also view and modify them in Customer Center.

When you create a brand, you include the login names of one or more brand administrators who manage that brand. Only the host administrator, a brand administrator, or a customer service representative (CSR) with access privileges for the brand can create and modify the brand-specific data. Use Access Privileges, another Configuration Center application, to give additional BRM users access to a brand. For more information, see "About Granting Access to Brands".

After the host administrator creates a brand, the brand administrator creates the price lists, customer accounts, and other data that is specific to that brand.

About Brand-Aware Data

When using certain BRM client applications such as Customer Center and Configuration Center, you select a brand before you create or modify any data. You must either be a brand administrator or have access privileges for a brand to select that brand in an application. (This is not a requirement for Customer Center; you can open accounts from multiple brands at the same time.) See "About Granting Access to Brands" for more information.

When you select a brand, the BRM system limits your access and allows you to only modify the data saved in that brand; for example, pricing information and general ledger information. This data can be configured uniquely for each brand in one BRM system.

Some BRM data is system-wide and is shared among all brands. For example, any brand administrator with proper permissions can read the data dictionary, which contains all BRM storable classes. Some data in the data dictionary, such as resources, impact categories, and usage maps, cannot be configured specifically for one brand because the data is shared among all brands. If you do not want one brand to draw information on the strategies of another brand based on shared data, the host administrator should name configuration data cryptically or non-descriptively. See "About Duplicate Service Logins Across Brands" for an example of how to name services.

Brand-Aware Information

Table 18-1 describes how branding affects certain BRM applications and features. The descriptions in the table apply only when you implement brands.

Table 18-1 Branded Data Behavior

Branded Data	Branding Behavior
Access Privileges tool	You use the Access Privileges tool to add users to an access group for a brand or account group. The access group limits who can access and manage the branded accounts. See "About the Root Access Group".
Account sponsorship	Sponsorship is valid within a brand; an account in one brand cannot not sponsor an account in a different brand, including sub-brands.
Customer Center	You create and change accounts only in the brand you select from the Brand list in Customer Center. Only brand administrators and CSRs with proper access privileges can see brand-specific information and accounts.
Brand Manager	Host administrators and brand administrators log into Configuration Center and use Brand Manager to create brands and sub-brands. See "Creating Brands".
Credit card merchant IDs	All brands must use the credit card processing service configured for the BRM system; however, you define merchant IDs for each brand. See "Setting Up Payment Methods for Brands".
Customer Center	Only brand administrators and CSRs with proper access privileges can see brand-specific information and accounts.
Device Management framework	/device objects and the /config objects used to configure them are brand-aware. You can associate /device objects only with /service objects in the same brand. You can specify different device life cycles and service mappings for device types in different brands. See "Device Management and Brands" in BRM Developer's Guide for more information.
Event Browser	The events available through Event Browser are those related to the login and password that the CSR uses to log in to Customer Center. You can review these events to see the changes a CSR makes to accounts in a brand the CSR has access to.
G/L IDs	The host administrator defines one set of G/L IDs for the database and one G/L segment for each brand in the database. You set up G/L information for brands in the pin_glid file.
BRM Reports	The host administrator must install and configure BRM Reports, after which brand administrators can create reports for their brand. See "Reporting by Brand" in BRM Reports for more information.
Invoice Browser	The host administrator can change the default invoice template for a BRM system. Brand administrators can design custom invoice templates and save them to their brands.
Multischema support	If your BRM system is installed in a multischema environment, you can install each top-level brand in a chosen database schema. All accounts and sub-brands in a brand must reside in the same schema as the brand account.
Payment Tool	To process payments in a branded environment, you must be logged in to Payment Tool as the root user. After you are logged in, you can only create and change payment batches in the brand you select from the Active Brand list. See Payment Tool for more information.
Pricing Center	Pricing Center is brand-aware based on the login of the brand administrator; the price list displayed in the tool is for that brand. You cannot switch between brands after you log in to Pricing Center. All pricing components, including products, deals, plans, plan lists, and price lists, are brand aware; brands cannot share pricing components. Only the brand administrator for a brand can create the price list for that brand. See "Creating a Price List for Brand Accounts".
Self-Care Manager registration	You can create a customer self-care home page for each brand in your system. Each self-care home page includes code that specifies the brand to use when displaying account information. See "About Registering Customers".
Zone Mapper	Host administrators and brand administrators log into Pricing Center and use Zone Mapper to create zone maps for pricing and save them to a specific brand.

System-Wide Information

Data that cannot be separated according to a brand should be handled only by the host administrator because all brands access and use the same data. System-wide applications and objects include the data shown in Table 18-2:

Table 18-2 System-wide Data and Branding Behavior

System-wide Data	Branding Behavior
Billing utilities	The host administrator should run billing scripts, such as pin_bill_day, for all brands at one time. Billing for one brand is possible, but it is resource intensive. See "Running Utilities with a Branded Database".
Configuration information	Configuration information such as ratable usage metrics (RUMs), currencies, and tax supplier IDs are system-wide, with the exception of the following: /config/glid, /config/invoice_templates, and /config/invoice_events. These can be configured for a specific brand. See "Setting Up the General Ledger to Support Brands" and "Setting Up Invoicing to Support Brands".
Credit card processing	All brands must use the payment processor connected to the credit card data manager; for example, Paymentech. See "About BRM-Initiated Payment Processing" in BRM Configuring and Collecting Payments for more information.
Developer Workshop and the data dictionary	The BRM object schema is a shared resource between all brands; therefore, only the host administrator should modify it.
Facility Module (FM) policy opcodes	By default, FM policy opcodes are not brand-aware; however, some policy opcodes will pass brand-aware data.
Services	Although service names are system-wide and all brands can share the same service object, each brand uses a different instance of the service.
Taxation	All brands in a BRM system must use the same tax calculation software.
Remittance for service providers	A brand account cannot contain a remittance product; however, you can set up a separate remittance account in a branded BRM system. The account receiving remittance can be in the same brand as the accounts paying the remittance funds. The remittance account can also be part of another brand or a system-level account.

About Organizing Brand Hierarchies

You organize accounts within a brand by using sub-brands and account groups:

Create sub-brands in Brand Manager. For example, if a brand has regional offerings or subsidiary brands, you can create hierarchies of sub-brands within the parent brand.
Create account groups in Customer Center. For example, you might want to assign different CSRs to different groups of accounts by using access privileges.

Figure 18-1 shows how a brand hierarchy might be organized, with a mixture of brands, sub-brands, and account groups:

Figure 18-1 Brand Hierarchy

Description of ''Figure 18-1 Brand Hierarchy''

About Naming Brands

Under the same parent brand, each sub-brand must have a unique name. However, sub-brands under different parent brands can share the same name. For example, in the figure above, BRM cannot contain two top-level (parent) brands named East Coast Enterprises. However, the East Coast Enterprises brand and the Last Chance Internet brand can each contain a sub-brand named Global Music. This is valid because the Global Music sub-brands are part of different brand hierarchies that have different parent brands.

Note:

The same rules apply for sponsor groups. You cannot have two sponsor groups with the same name under one parent brand.

About Brands and Account Groups

All accounts under one brand are in the same account group. One brand can contain any number of sub-brands and account groups that do not have to be brands. Account groups can be organized into groups for billing and reporting. See "About Account Groups" in BRM System Administrator's Guide for more information.

A brand can contain an unlimited number or type of account groups, but certain rules apply when moving accounts between brands and account groups to keep data separated.

You cannot transfer a customer from one brand to another brand or to a non-branded mode.
You cannot move an account from a non-branded to a branded mode.
You can move an account from one account group to another account group within a brand, but not between brands.
You can drag nonpaying (subordinate) child accounts and paying (nonsubordinate) child accounts between account groups within the same brand.

When to Use Account Groups Instead of Brands

Before you create customer accounts in your BRM system, first determine if you require branding to separate accounts into divisions or if using account groups meets your requirements. You can create account groups whether or not you enable branding.

Use account groups rather than branding if the following circumstances are true:

You plan on moving accounts in and out of different clusters. Moving an account from one brand to another, or from a non-branded environment to a brand, is prohibited by branding and requires the accounts to be closed and recreated, which is a time-consuming process.
You will share BRM pricing data such as products, deals, and plans, or general ledger revenue reporting. This eliminates the need to copy the same pricing component into each brand's price list and then maintain multiple instances of that component.
You need strict divisions between account hierarchies and want to segregate data into isolated groups.
You will have sponsored accounts. You cannot apply sponsored rates across brand boundaries, and you cannot apply sponsored rates to a parent brand for accounts in a sub-brand.

See "About Brand-Aware Data" for more information.

About Creating Sub-Brands

You use Brand Manager to create any number of sub-brands in a brand. Before you create a sub-brand:

You must have access to the parent brand, either as a brand administrator or through access privileges. See "Controlling Access to Top-Level Brands".
You must create a custom price list and commit it to the parent brand before you create sub-brands.
Brand administrators must have service/admin_client permissions to log into Configuration Center and create brands. Therefore, when host administrators create brands in their BRM system, they must include service/admin_client in the default plan for the brand. This service gives brand administrators access to BRM client tools. Similarly, when creating sub-brands, brand administrators must include service/admin_client in the default plan for the sub-brand if they want sub-brand administrators to create additional sub-brands.

You can change most information for a brand, but you cannot change the plan or logins for brand managers.

About Granting Access to Brands

You control which BRM users can access data belonging to a brand or an account group. Open the Access Privileges tool in Configuration Center and create an access group.

Two categories of BRM users have access to brands without belonging to access groups:

The host administrator has root access to the entire BRM system.
Brand administrators have full access to their brand and any of its sub-brands. Brand administrators are the login names entered as part of creating a brand. You can create one or more brand administrators when you create a brand, but you cannot change or delete them later.

Other BRM users, such as CSRs, must be part of a brand's access group to work with customer accounts and other data for that brand. For more information on creating access groups, see "Controlling Access to Top-Level Brands".

An access group includes:

A single brand, sub-brand, or account group
The logins of one or more BRM users

You can assign a BRM user to one or more access groups.

When using Customer Center or other BRM tools, you only see and work with data that belongs to the brand or account group you have access to. In Customer Center, you can access multiple brands concurrently if you have proper permission.

Note:

Only the brand administrator can create a price list for a brand. Access group members do not have this ability.

Figure 18-2 shows the structure of an access group:

Figure 18-2 Access Group Structure

Description of ''Figure 18-2 Access Group Structure''

Note:

If you have access to a brand, you also have access to its sub-brands. You do not have implicit access to parent brands in your brand hierarchy.
Access privileges also apply to creating access groups. You need privileges to work with a brand to set up access groups for sub-brands or account groups within that brand.
In Customer Center, CSRs belonging to multiple access groups can open accounts from multiple brands concurrently.
You can add CSRs to an access group only if the CSRs already have access to a brand or account group within the hierarchy of an active brand. If the CSR was created in another brand hierarchy, the administrator of the parent brand must add the CSR to the desired brand.

Table 18-3 lists each access level available in a branded system.

Table 18-3 Available Access Levels

This Access Level	Grants this Permission
Brand Account Administrator The user's login ID is used to create a brand.	The brand administrator can access all accounts in the brand or account group and all sub-brands and sub-account groups. You do not need to add a brand administrator to an access group for that brand or account group.
Access Group Member The CSR's login ID is added to an access group for a brand or account group.	The CSR can access all accounts in the brand or account group that the access group was created for, including sub-brands and sub-account groups in the hierarchy.
Brand Member The CSR account was created in a brand, but the CSR is not a member of an access group.	The CSR can access only the accounts that he or she created. The access level in Customer Center is shown as [Self].

This Access Level

Grants this Permission

Brand Account Administrator

The user's login ID is used to create a brand.

The brand administrator can access all accounts in the brand or account group and all sub-brands and sub-account groups. You do not need to add a brand administrator to an access group for that brand or account group.

Access Group Member

The CSR's login ID is added to an access group for a brand or account group.

The CSR can access all accounts in the brand or account group that the access group was created for, including sub-brands and sub-account groups in the hierarchy.

Brand Member

The CSR account was created in a brand, but the CSR is not a member of an access group.

The CSR can access only the accounts that he or she created. The access level in Customer Center is shown as [Self].

About the Root Access Group

When you install BRM and enable branding, a default access group, or access control list (ACL), is created for the root database. The host administrator assigns a personal login ID as the owner, and then adds any number of CSRs to the list. Members of the root access group for BRM can see and change all accounts in the database.

For more information, see "Giving Users Access to All Accounts in BRM".

About Price Plans for Brands

To create a brand, the host administrator must first create a host price list for the BRM system. This price list is never used for rating; it only allows for the creation of brands. The price list must contain a plan list named brand, which contains plans needed to create brands. A plan provides services to the brand that enable the brand administrator to perform necessary tasks. The following services are often required by brand accounts:

admin_client service for any brand to enable access to BRM client applications.
pcm_client service if you use applications, such as testnap, that log in to BRM through this service.

When you create a plan in Pricing Center, you can give the plan any name, but you must include it in a plan list named brand. Figure 18-3 shows a brand host price list that contains the brand plan list. The plan list contains a plan named Brand Plan that contains two services to create top-level brands with.

Figure 18-3 Brand Host Price List

Description of ''Figure 18-3 Brand Host Price List''

After the BrandHost price list is committed to the BRM database, the plan Brand Plan will be displayed in Brand Manager.

Note:

Unlike Customer Center, Pricing Center limits access to multiple brands. When logging in to Pricing Center, you can only see the price list for the brand whose login and password you used. Therefore, when the host administrator logs in to Pricing Center as root, the host administrator can only see the Brand Host plan, and not the price plans created by each brand. To see a brand price list, the host administrator must log in to Pricing Center by using the brand administrator's login and password.

About Brand Currency

Brands and account groups can have a different currency from the system currency, and sub-brands and account groups can have a different currency from the parent brand or account group.

Brands and sub-brands can also be created in the system currency, even if the parent brand has a different primary or secondary currency.

For more information on account currency and system currencies, see "Managing System and Account Currencies".

About Closing, Inactivating, and Reactivating Brands

You can set a brand to be active, inactive, or closed from either Brand Manager or Customer Center.

When inactivating or closing a brand, the following rules apply:

All accounts you create in a brand are created with the same status as the brand.
Inactivating a brand inactivates all accounts in the brand. It does not inactivate the sub-brands or their accounts.
A brand and all of its accounts can be reactivated if no changes were made to the brand or accounts in the brand after the brand was inactivated.
If you inactivate an account before inactivating its parent brand, the account will be reactivated when the brand is reactivated. If desired, you must manually deactivate it again by using Customer Center.
Inactivating a brand moves all closed accounts in the brand to inactive status.

For more information, see "Changing Account and Service Status".

About Duplicate Service Logins Across Brands

User access to most BRM objects is validated by using the object's Portal object ID (POID). However, user access to a service is validated by combining the service name with the user's login name and then checking the user's password information. Therefore, if two brands use the same service and define the same login name for that service, errors will occur.

To ensure that only one brand contains a particular login/service combination, you configure unique service subclasses for each brand. For example, Table 18-4 shows host ISP database containing two brands. Each brand uses the IP service, but each instance of the service is named differently for each brand:

Table 18-4 Service and Login Names for Brands

Brand Name	Service Name	Login Name
A1 Internet, Inc.	/service/ip/ISP_A	admin
Best Internet, Inc.	/service/ip/ISP_B	admin

Because the service names are different, the login name can be the same because the actual service is not shared between brands. But, if you use the same service name across brands, the login names must be unique across all brands that use that service name; it is not sufficient that the service instances be unique to a brand.

Tip:

Use a generic naming convention for services to limit the transfer of company-specific information among brands. Notice that the services in the example are named /service/ip/ISP_* rather than the company name, such as /service/ip/A1.

See "Creating Custom Fields and Storable Classes" in BRM Developer's Guide for more information on creating service subclasses. If you do not want to duplicate services across brands, you can modify the login policy to append the brand's domain name to the login name when a customer registers. For more information, see "Adding or Changing Login Options" in BRM Developer's Guide.

About Using Brands with Multiple Database Schemas

If your BRM system is installed in a multischema environment, you can choose a specific database schema when you create each top-level brand. All sub-brands and accounts that belong to a brand must be in the same schema as the parent brand.

Only the host administrator can specify a schema for a brand.

Tip:

Before choosing a schema for a particular brand, take into account the size of each schema and the number of accounts you expect in each brand. You cannot move a brand or its accounts to another schema after you create them.

About A/R Accounts and Brands

By default, a brand account is not designed to handle accounts receivable (A/R) operations. If a CSR creates a customer account and makes it a subordinate bill unit to the brand account, the services used by the customer might be received for free because the brand account is not set up for billing. Brand Manager does not enable you to configure billing information when you create the brand account; you must set this up in Customer Center after you create the brand account.

To prevent A/R problems, use Customer Center to create a separate business account in the brand and make it the designated A/R account.

Note:

Although it is not recommended, you can configure the brand account to handle A/R. Open the brand account in Customer Center and set up the billing and payment information. Then, when you make a customer account nonpaying (subordinate) to the brand account, change the nonpaying child account's billing date to match the brand bill unit's billing date.

About Running Billing

Using brands does not change the way you run billing for your BRM system. The host administrator should run billing for the entire database at one time.

However, you can run billing for each brand individually. It is not recommended because the process is very resource-intensive and slows system performance. See "Running Utilities with a Branded Database" for details.