Managing Account and Bill Unit Hierarchies

About Account Groups

Accounts can be organized into groups for billing purposes or to represent the relationships between the accounts graphically in Billing Care or Customer Center. There are several kinds of account groups:

Hierarchical: An account hierarchy has a parent account and any number of child accounts and other account hierarchies. Account hierarchies are created for the following reasons:
- Solely to display relationships between accounts. In such cases, the parent account pays none of a child account's charges.
- To provide a mechanism that custom reports can use to identify related accounts and analyze those relationships.
- To provide the organizational structure for rolling charges of child accounts up to the parent account during billing.
  
  Note:
  
  Because bill unit hierarchies do not have to match account hierarchies, you do not need to set up account hierarchies to roll up charges among accounts. Typically, however, bill unit hierarchies exist within the structure of an account hierarchy, and applications such as Billing Care facilitate the creation of paying and nonpaying bill unit relationships during account hierarchy setup.
  
  For more information, see "About Bill Unit Hierarchies".
A child account can belong to only one parent account.

See "Managing Account and Bill Unit Hierarchies".
Charge or Discount Sharing: A charge or discount sharing group consists of an owner account or service and one or more member accounts or services. Charge or discount sharing groups are created so that charges and discounts can be shared among accounts.

See "Managing Charge and Discount Sharing Groups".
Sponsored top-up: A sponsored top-up group consists of an owner account and one or more member accounts. The owner account can top up a specified balance in each member account. See "About Sponsored Top-Ups" in BRM Configuring and Collecting Payments.

In all types of account groups, the bills and payments belong to the account's bill units. See "About Bill Units and Account Groups".

About Bill Units and Account Groups

Accounts can have one or more bill units. Each bill unit stores billing information and tracks the charges for a particular bill. When accounts are set up with group relationships, the payment type of the bill units in the accounts, not the accounts themselves, determine which accounts pay the charges.

In account groups, bill units have an additional internal group structure:

In an account hierarchy, the bill unit hierarchy can, but does not have to, match the account hierarchy. If necessary, a bill unit hierarchy can span multiple account hierarchies (that is, it can contain bill units of accounts that belong to different account hierarchies).

Typically, however, an account hierarchy has a top-level parent bill unit and any number of child bill units and other bill unit hierarchies. The charges of the hierarchy's nonpaying child bill units are rolled up to the top-level paying parent bill unit during billing.

If an account hierarchy is set up solely to display relationships among accounts, the bill unit in the parent account pays none of the charges in a child account's bill unit. Both the parent and child bill units are paying bill units.

A child bill unit can belong to only one parent bill unit.

See "Managing Account and Bill Unit Hierarchies".
A discount sharing group or charge sharing group consists of a group owner and one or more members. The group owner's account has an owning balance group. The owning balance group bears the financial impact of the sharing group, and the bill unit for this balance group pays for the member bill unit's charges.

Member accounts can have more than one bill unit. If a member account has multiple bill units, the bill unit that benefits from sharing is the one that has the balance group whose service has been chosen for sharing.

See "Managing Charge and Discount Sharing Groups".

Comparing Hierarchy and Sharing

The main differences between hierarchies and sharing groups are:

Relationships

Hierarchy: Creates parent-child relationships among accounts or bill units.
Sharing: Creates owner/member relationships in which the owner assumes certain charges for the member or shares balances with the members. Discount sharing is based on discount offers purchased by the owner as part of charge offer charges. Charge sharing is based on chargeshare offers.

Bill Units and Balance Groups

Hierarchy: Parent and child accounts have either paying bill units or nonpaying bill units.
Sharing: Charge and discount sharing group owner accounts have owning balance groups that are part of bill units. For charge sharing, charges for eligible member events impact the owning balance group and associated bill unit. For discount sharing, shared discounts impact the member's balance groups by either increasing noncurrency balances or reducing the currency impact of an event.

Charge Offer and Service Ownership

Hierarchy: Nonpaying child bill units of the same parent bill unit do not have to own the same charge offers.
Sharing: An owner account does not need to have the same charge offers or services as the members.

The owner bill units can provide sharing to group members even if, at group creation time, some members do not own the services for which sharing is provided. In this case, only members who currently own the shared services benefit from charge or discount sharing. Members who do not own the service when sharing is set up can participate in sharing if they purchase that service in the future.

Charge Offer Guidelines

Hierarchy: A parent bill unit can pay for any charge offer.
Sharing: An owner can pay for a member's charges in accordance with a chargeshare offer selected when the charge sharing group is created. An owner can share any discount included in the packages they purchase.

Number of Parents or Owners

Hierarchy: A child account can belong to only one parent account, and a child bill unit can belong to only one parent bill unit.
Sharing: Multiple owners can provide charge or discount sharing for the same service, and a member account can participate in multiple sharing groups for a service. Thus, a member bill unit can share charges with multiple owner bill units or receive discounts from multiple owners.

What the Parent or Owner Pays For

Hierarchy: A parent bill unit pays all the charges for its nonpaying child bill units. The parent bill unit cannot pay for only some of a nonpaying child bill unit's charges.

Bill items are created for nonpaying bill units, but the amounts in them are rolled up at billing to the paying bill unit's bill.
Sharing: An owner bill unit pays only the member charges that are defined as shared when the charge sharing group is created.

A charge sharing group can include some or all chargeshare offers in the database. The charges go directly to the bill items of the sharing group owner's bill unit.

Multiple Bill Units and Groups

Hierarchy: If a child account has multiple bill units, the parent account can pay the charges for none, one, several, or all of the child account's bill units, depending on whether the bill units are paying or nonpaying.
Sharing: If a member account has a service that participates in multiple charge and discount sharing groups from different owner accounts, the member's charges are distributed among the groups' owners and the member benefits from each owner's shared discounts. BRM distributes the charges among the owner bill units and applies discounts based on priorities defined when the member joins the sharing groups. The member account pays any charges that are not eligible for sharing.

Collecting Payment Information

Hierarchy: During account creation, payment information is not collected for child accounts' nonpaying bill units. Their payment method is Paid by Parent Account.
Sharing: During charge sharing group creation, the payment method of the owning balance group is set as the payment method for any shared charges. The members' payment method has no bearing on the sharing, so members can use any payment method.

Discounts do not generate bills, they only change the amount of a bill. Therefore, payment method is not a factor for discount sharing groups.

Tracking Balance Impacts

Hierarchy: Nonpaying bill units track and display their own balance impacts in real time. When you bill accounts in a hierarchy, balance impacts of nonpaying bill units are rolled up to their paying parent bill unit, and the account that owns the paying parent bill unit is billed for them. The account that owns the nonpaying bill unit and the account that owns the paying bill unit can be in different account hierarchies.
Sharing: Member bill units do not track or display the balance impacts of shared charges. The owning balance group tracks the balance impacts of usage resulting from noncurrency shared discounts; for example, included minutes.

Balances

Hierarchy Account hierarchies do not affect any type of balance. Bill unit hierarchies are concerned only with billing, so only currency balances are affected.
Sharing: Charge and discount sharing groups affect all types of balances. For example, you can apply an owner's discount for included minutes to each member or apply a 15% discount on a member's monthly fee.

Hierarchy Balance Impacts

The parent-child relationship has no financial impact unless a child bill unit is a nonpaying bill unit. Nonpaying bill units maintain all their charges until billing, when the charges are rolled up to their paying parent bill unit, which is then responsible for the bill.

No financial impact occurs when you move an independent account or bill unit into a hierarchy and make it a child. If you make the bill unit nonpaying, you choose whether to bill it for bill-in-progress charges or to transfer the charges to the new paying parent bill unit.

When you move a nonpaying bill unit from one paying parent bill unit to another, you can specify which parent pays the bill-in-progress charges. By default, the bill-in-progress charges transfer to the new parent bill unit.

Before you can move a nonpaying bill unit out of a bill unit hierarchy, you must change it to a paying bill unit and specify whether the bill unit or its former parent will pay any bill-in-progress charges.

Sharing Group Balance Impacts

When a member account's service is added to a charge or discount sharing group, a financial relationship is created between the sharing group owner account and the member account.

Discount sharing: If the owner account is active and the member account has services eligible for discount sharing, the shared discounts reduce the amount of money a member owes by applying the owner's discounts to the balance of the member account before finalizing the member's charges.
Charge sharing: If the owner account is active and the member service has events eligible for charge sharing, the shared charges impact the balance of the owner account rather than the member account.

The member account stops benefiting from charge and discount sharing groups in the following situations:

The owner account is inactive or closed.
The sharing group is deleted from the owner account.
The member account's service is removed from the sharing group.
Events generated by a member fall outside of the validity period for the shared charge or discount.
The charges or discounts that were included in the sharing group are deleted.
For discount sharing groups, the noncurrency balances that were offered as part of the discount have been depleted in the owner account (for example, a monthly discount of included minutes that has already been consumed by the owner or other members). In this case, the member still benefits from currency-type shared discounts, such as a 10% reduction on bills for email usage or a $15 discount on overseas calls.

About Account Hierarchies

An account hierarchy is a set of accounts organized according to their positions in relation to each other. The relationships among accounts in a hierarchy are similar to parent-child relationships. The hierarchy is headed by a parent account with child accounts beneath it. At each level above the bottom of the hierarchy, the child accounts themselves can be parent accounts.

You set up account hierarchies for the following reasons:

Solely to display relationships among accounts. In such cases, the parent account pays none of a child account's charges.
To provide a mechanism that custom reports can use to identify related accounts and analyze those relationships.
To provide the organizational structure for rolling charges of child accounts up to the parent account during billing.

Note:

Because bill unit hierarchies do not have to match account hierarchies, you do not need to set up account hierarchies to roll up charges among accounts. Typically, however, bill unit hierarchies exist within the structure of an account hierarchy, and applications such as Billing Care facilitate the creation of paying and nonpaying bill unit relationships during account hierarchy setup.

For more information, see "About Bill Unit Hierarchies".

For example, a corporate customer might have several accounts for corporate employees, but the corporation itself pays all the employees' bills. In this case, the corporation's account is the parent account with the paying bill unit, and the employees' accounts are child accounts with nonpaying bill units.

An account's position in a hierarchy does not necessarily indicate whether it pays its own bills. The top-level parent account is not required to have a paying bill unit. Any account, either a parent or child, can have a paying bill unit or a nonpaying bill unit.

For more information about paying and nonpaying bill units in account hierarchies, see the following sections:
- About Bill Unit Hierarchies
- Calculating Balance Due in Account and Bill Unit Hierarchies

Performance Impact of Account Hierarchies

To maintain data consistency, many operations lock an account at the beginning of a transaction. Therefore, in an account hierarchy, many of the associated accounts are also locked. Although this provides reliable data consistency, it can cause a lot of serialization, which decreases the throughput of the system.

If this problem affects your system, you can choose to lock specific balance groups instead of the whole account.

Note:

Balance group locking might enable separate contexts to attempt to lock the same object, causing a system halt. When balance group locking is used, every feature that uses it should be examined for overlap.

For more information about balance group locking, see "Locking Specific Objects" in BRM Developer's Guide.

About Bill Unit Hierarchies

Bill unit hierarchies are a set of bill units organized according to their positions in relation to each other. A bill unit hierarchy is headed by a parent bill unit with child bill units beneath it. At each level above the bottom of the hierarchy, the child bill units themselves can be parent bill units.

Typically, a bill unit hierarchy exists within the context of an account hierarchy used for billing purposes. The bill unit hierarchy can, but does not have to, match the account hierarchy. If necessary, a bill unit hierarchy can span multiple account hierarchies (that is, it can contain bill units of accounts that belong to different account hierarchies).

A bill unit's position in a hierarchy does not necessarily indicate whether it pays its own bills. Any bill unit, either a parent or child, can be a paying bill unit or a nonpaying bill unit, and both parent and child accounts can have paying bill units and nonpaying bill units:

A paying bill unit pays its own bill and, if it is a parent, the bills of its nonpaying child bill units.
A nonpaying bill unit's bill is paid by its parent bill unit. If its parent is also a nonpaying bill unit, its charges are rolled up the bill unit hierarchy to the next paying ancestor bill unit.

Figure 20-1 shows a simple bill unit hierarchy. The hierarchy contains three bill units, one in each account. Because the paying bill unit in the parent account pays the bill for the nonpaying bill unit in the child account, however, only two bills are generated for the three accounts.

Figure 20-1 Simple Bill Unit Hierarchy

Description of "Figure 20-1 Simple Bill Unit Hierarchy"

Account and bill unit hierarchies do not have to match. For example, a parent bill unit does not have to belong to a parent account, and a child bill unit does not have to belong to a child account.

Figure 20-2 shows an account hierarchy containing one parent account and one child account. Each account contains a bill unit. The parent account's bill unit is the nonpaying child of the child account's paying parent bill unit. In this situation, the child account pays the parent account's charges.

Figure 20-2 Nonmatching Account and Bill Unit Hierarchies

Description of "Figure 20-2 Nonmatching Account and Bill Unit Hierarchies"

When hierarchical accounts have multiple bill units, the bill unit hierarchy becomes more complex. A child account can have both nonpaying bill units and paying bill units. The parent account is not required to pay all of the child account's bills.

Figure 20-3 shows a parent account and a child account with two bill units each. One of the child account's bill units is a paying bill unit. The charges for that bill unit are paid by the child account, not by the parent account. In this case, three bills are generated: one for the parent account, one for the parent-child account, and one for the child account.

Figure 20-3 Complex Bill Unit Hierarchy

Description of "Figure 20-3 Complex Bill Unit Hierarchy"

At each level above the bottom of a hierarchy, the child bill units themselves can be parent bill units.

Figure 20-4 shows a three-level account hierarchy containing seven bill units. Because only three of the seven bill units are paying, only three bills are generated. The top parent account receives two bills, and the bottom child account receives one bill.

Figure 20-4 Three-Level Account Hierarchy with Multiple Bill Units

Description of "Figure 20-4 Three-Level Account Hierarchy with Multiple Bill Units"

A bill unit hierarchy can contain bill units of accounts that belong to different account hierarchies.

Figure 20-5 shows two account hierarchies with a total of five bill units. The bill units are grouped into two bill unit hierarchies, each containing bill units from both account hierarchies. Because only two bill units are paying, only two bills are generated. One parent account receives a bill, and one child account receives a bill.

Figure 20-5 Bill Unit Hierarchies That Span Multiple Account Hierarchies

Description of "Figure 20-5 Bill Unit Hierarchies That Span Multiple Account Hierarchies"

For information about creating bill unit hierarchies, see "Creating Account and Bill Unit Hierarchies".

How Account Status Changes Affect Hierarchies

Changing the status of an account in an account hierarchy changes the status of all accounts inside and outside the account hierarchy that have at least one nonpaying bill unit whose paying parent bill unit is owned by the initially changed account.

For example, Figure 20-6 shows the bill units that are inactivated in a multilevel hierarchy when a parent account is inactivated.

Figure 20-6 Effect of Parent Account Status Change on Bill Unit Hierarchy

Description of "Figure 20-6 Effect of Parent Account Status Change on Bill Unit Hierarchy"

Changing the status of a paying parent bill unit changes the status of all accounts that have at least one nonpaying child bill unit of the paying bill unit.

For example, Figure 20-7 shows the bill units that are inactivated in a multilevel hierarchy when the status of an individual paying bill unit is inactivated.

Figure 20-7 Effect of Parent Bill Unit Status Change on Bill Unit Hierarchy

Description of "Figure 20-7 Effect of Parent Bill Unit Status Change on Bill Unit Hierarchy"

Currency Requirements of Hierarchies

Nonpaying bill units must have the same currency as the account that owns their parent bill unit. If the accounts that own the parent and child bill units use two currencies, their primary and secondary currencies must match.

Billing Setups in Hierarchies

Because paying bill units handle the billing for nonpaying bill units, nonpaying bill units must have the same billing day of month (DOM), billing frequency, accounting cycle, and language as their paying parent bill unit.

Calculating Balance Due in Account and Bill Unit Hierarchies

An account hierarchy is a set of accounts organized according to their positions in relation to one another. Each hierarchy consists of one parent account and any number of child accounts and other account hierarchies.

When the accounts in a hierarchy are billed, however, the relationships among the accounts' bill units, not among the accounts, determine whether an account pays its own charges or rolls them up to another account inside or outside the hierarchy. To keep the charges within the account hierarchy, each bill unit in the hierarchy's accounts should be part of a bill unit hierarchy that is contained within the account hierarchy.

Note:

Bill unit hierarchies can, but do not have to, match account hierarchies. See "About Bill Unit Hierarchies".

Child accounts can have a paying bill unit or a nonpaying bill unit. The balance due is billed differently for accounts that have paying bill units and nonpaying bill units:

The balance due for a paying bill unit is billed to itself.
The balance due for a nonpaying bill unit is billed to its paying bill unit (the nonpaying bill unit's first paying bill unit ancestor).

BRM creates bills and bill items for all account bill units: parent, child, paying, and nonpaying. Billing, however, involves two different processes:

Changing the status of bills and bill items to open, and creating new pending bills and bill items for the next bill. This occurs for all accounts.

Note:

If a nonpaying child bill unit is billed before its paying parent bill unit, the nonpaying bill unit's items remains pending until the paying bill unit has been billed.
Requesting a payment for the bill (for example, initiating a credit card transaction). This occurs for paying bill units only. A nonpaying bill unit never receives a payment request.

Each bill unit includes a pending bill and one or more pending bill items. As an account incurs balance impacts, such as usage fees, the balance due accumulates in the pending bill items.

Each bill item includes these fields:

PIN_FLD_ACCOUNT_OBJ: The account that the item belongs to. This field always points to the account that owns the item.
PIN_FLD_BAL_GRP_OBJ: The balance group that the item belongs to.
PIN_FLD_BILLINFO_OBJ: The bill unit that the item belongs to.
PIN_FLD_BILL_OBJ: The bill that the item belongs to. This field always points to the account's own bill.
PIN_FLD_AR_BILLINFO_OBJ: The paying bill unit that the item belongs to.
PIN_FLD_AR_BILL_OBJ: The paying bill that the item belongs to.

The AR_BILLINFO_OBJ and AR_BILL_OBJ fields determine which account, bill unit, and bill handles billing for the item. If an item belongs to a nonpaying bill unit, the item's AR_BILLINFO_OBJ field points to the nonpaying bill unit's paying bill unit, and the AR_BILL_OBJ field points to a bill in the parent account of the paying bill unit. In a bill unit hierarchy with more than two levels, the balance due belongs to a nonpaying bill unit's first paying bill unit ancestor and its corresponding bill.

Figure 20-8 shows a parent account, a child account with a nonpaying bill unit, and a child account with a paying bill unit. Notice that in the child account with the nonpaying bill unit, the paying bill field (AR_BILL_OBJ) and paying bill unit field (AR_BILLINFO_OBJ) point to the parent account.

Figure 20-8 Paying Bill Unit Differences for Child Accounts

Description of "Figure 20-8 Paying Bill Unit Differences for Child Accounts"

Who Pays for Open Items and Pending Items?

An account might have open items and pending items. This might happen if the customer has not paid an open bill or has paid only part of it. In that case, there would be an open item and a pending item.

If that account's bill unit changes from nonpaying to paying or from paying to nonpaying, the payment responsibility for only pending items is affected. Payment responsibility for open items is not changed.

Figure 20-9 shows a child account with a nonpaying bill unit that was a parent account with a paying bill unit, so it has a pending item and an open item. The open item points to the child account as the owner of the paying bill unit (AR_BILLINFO_OBJ), but the pending item points to the parent account as the owner of the paying bill unit.

Figure 20-9 Account with Pending and Open Items

Description of "Figure 20-9 Account with Pending and Open Items"

In some cases, an account can accumulate balance impacts for part of a billing cycle before its bill unit becomes nonpaying. When the bill unit becomes a nonpaying child, the paying parent bill unit becomes responsible for pending charges accumulated before the child bill unit became nonpaying.

Figure 20-10 shows an account that is billed on the 5th day of each month. The account's bill unit becomes a nonpaying child on the 10th day of the month, but because it has already incurred balance impacts recorded in a pending item, the paying parent bill unit is billed for the balance due accumulated from the 5th through the 15th.

Figure 20-10 Account Charges before Bill Unit Became Nonpaying

Description of "Figure 20-10 Account Charges before Bill Unit Became Nonpaying"

Table 20-1 summarizes changes to payment responsibilities:

Table 20-1 Effect of Paying/Nonpaying Changes on Account Hierarchies

Change to Account	Open Items	Pending Items
Parent account with paying bill unit becomes child account with nonpaying bill unit.	Nonpaying bill unit in the child account is responsible for its open item balance due.	Paying bill unit in the parent account is responsible for the pending item balance due of the child account's nonpaying bill unit.
Nonpaying bill unit in a child account becomes a paying bill unit.	Paying bill unit in the parent account is responsible for the open item balance due of the former child account's nonpaying bill unit.	Paying bill unit in the child account is responsible for its pending item balance due.
Child account with nonpaying bill unit changes parent account and paying parent bill unit.	Paying bill unit in the old parent account is responsible for the open item balance due of the child account's nonpaying bill unit.	Paying bill unit in the new parent account is responsible for the pending item balance due of the child account's nonpaying bill unit.

To close all of an account's open items before you make the account a nonpaying child, use the Bill Now feature in Billing Care or Customer Center.

Multiple Levels of Parent Accounts

If all child accounts (some of which might also be parent accounts) in an account hierarchy have only nonpaying bill units, the balance due for pending items is always handled by the hierarchy's top parent account.

In Figure 20-11, account 300, which has a nonpaying bill unit, is a child of account 200, which is in turn a child of account 100. The balance due for account 300 is handled by account 100, not by account 200.

Figure 20-11 Multiple Levels of Parent Accounts

Description of "Figure 20-11 Multiple Levels of Parent Accounts"

Hierarchy Changes and Billing Dates

When you make an account a child account, BRM changes the child account's billing day of month (DOM) to match the parent account's billing DOM.

If the child account has a nonpaying bill unit whose paying parent bill unit is in the new parent account, the nonpaying bill unit must have the same billing DOM as the paying parent bill unit.

Note:

All bill units in a bill unit hierarchy must have the same billing DOM. BRM, however, does not enforce that requirement. Therefore, if the billing DOMs do not match in a bill unit hierarchy, you must manually align them.

The next billing date for the nonpaying bill unit, however, might not be the same as the next billing date of the paying parent bill unit. This happens because a change to a billing DOM always takes effect after the end of the current cycle.

As a result, the parent account's paying bill unit might be billed, but the nonpaying bill unit in the child account might not be billed. Therefore, the balance due for the nonpaying bill unit in the child account is not included in the parent account bill.

For example:

You create Account A on June 8.

The billing DOM is 8.
You create Account B on June 20 and then change its billing day to 8.

The next billing date is August 8. This happens because the current billing cycle, from June 20 through July 20, must be completed before the billing DOM changes. A long billing cycle, from June 20 through August 8, is created.
You make Account B a child account of Account A, changing Account B's bill unit to a nonpaying child of Account A's bill unit.
On July 8, Account A is billed, but Account B is not because Account B's next billing date is August 8.

Therefore, the bill includes the balance due for only Account A, the parent account.
On August 8, both accounts are billed.

The bill includes the balance due from both accounts:
- Parent account balance due from July 8 to August 8.
- Child account balance due from June 20 to August 8.
On all subsequent billing dates, both accounts are billed.

Figure 20-12 shows a time line for the billing dates for two accounts in a parent-child relationship where the child account has a nonpaying bill unit.

Figure 20-12 Hierarchy Changes and Billing Dates

Description of "Figure 20-12 Hierarchy Changes and Billing Dates"

Examples of Changes to Account Hierarchies

These examples show who is responsible for the balance due following various account hierarchy changes.

Note:

Except where noted, these examples assume that the child account's nonpaying bill unit is owned by the parent account's paying bill unit.

An Account Becomes a Child Account with a Paying Bill Unit

In this case, there is no change to how the balance due is handled. The parent account handles its own balance due; the child account handles its own balance due.

An Account Becomes a Child Account with a Nonpaying Bill Unit When It Is Created

In this case, the total balance due is handled by the parent account, which owns the paying bill unit, and the billing date of the child account is the same as the parent account.

An Account Becomes a Child Account with a Nonpaying Bill Unit Immediately after It Is Created

In this case, the account has not been billed yet, so all its items are pending. Therefore, its total balance due is handled by the parent account, which owns the paying bill unit.

Note:

By default, for customers who pay by credit card, BRM charges purchase fees and the first cycle forward fee at account creation. The balance due for these fees is stored in open items and is charged to the child account's bill unit. You can turn off credit card collection at account creation by editing the cc_collect entry in the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf).

An Account Becomes a Child Account with a Nonpaying Bill Unit Several Months after It Is Created

In this case, the balance due for all pending items in the child account's nonpaying bill unit is handled by the parent account, which owns the paying bill unit. Any open items are handled by the child account. The billing date of the nonpaying bill unit in the child account is changed to match the billing date of the account that owns the paying bill unit.

A Child Account with a Nonpaying Bill Unit Changes Parent Accounts

Note:

This example assumes that the nonpaying bill unit's paying parent bill unit was also changed to a paying bill unit owned by the new parent account.

In this case, the balance due for all pending items in the nonpaying bill unit of the child account is now handled by a different parent account and that parent account's paying bill unit. Any open items are the responsibility of the former parent account. The billing date of the child account is changed to match the billing date of the new parent account, which owns the current paying parent bill unit.

A Child Account with a Nonpaying Bill Unit Becomes a Child Account with a Paying Bill Unit

In this case, the fields in pending items that specify the paying bill unit and the bill both point to the paying bill unit in the child account. If the parent account's bill unit that formerly paid the child's charges has any open items that include amounts due from the child account, the parent account's bill unit is responsible for those amounts even when the child account's bill unit is no longer nonpaying.

Creating Account and Bill Unit Hierarchies

You can create account and bill unit hierarchies by using Billing Care or Customer Center, or by using custom applications that call BRM opcodes.

By default, accounts are created with one bill unit. When you create account hierarchies, the bill units are automatically assigned the same hierarchical position as the accounts to which they belong.

To enable customers to receive separate bills for different services, you can create additional bill units per account. You then specify whether the bill units are paying or nonpaying and parents or children.

The bill units of accounts that do not belong to the same account hierarchy can form a bill unit hierarchy. Nonpaying child bill units in one account hierarchy can have a paying parent bill unit in a different account hierarchy.

Managing Account Hierarchies

To manage account hierarchies, you can do the following:

Display account hierarchies in Billing Care or Customer Center.

You can see the structure of an account hierarchy in the Hierarchy tab of the hierarchy's parent account. Initially, this tab shows the direct lineage of an account, not its siblings or the siblings of its parent.
Change the parent of an account.

You can use Billing Care or Customer Center to change an account's parent at any time. You change an account's parent by adding the account to a hierarchy, removing it from a hierarchy, or moving it from one hierarchy to another.
Defer account hierarchy changes until a later date.

You can schedule a parent change for a future date. You can then use a daily billing utility, pin_deferred_act, to process the change automatically on the scheduled date.

See "Scheduling Status Changes in Advance".

Moving Closed Accounts into or out of Hierarchies

By default, BRM does not enable you to move closed accounts into or out of account hierarchies. To enable that functionality, configure the allow_move_close_acct entry in the CM configuration file.

Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
Set the allow_move_close_acct entry to 1:
```
- fm_bill allow_move_close_acct 1
```
By default, this entry is set to 0.
Save and close the file.