Account Classes

An account class is a method for classifying an account according to its position and role in an account hierarchy. When setting up the hierarchy, end users define parent-child relationships among the accounts. Then they designate which account class applies to each new account, according to your customer’s requirements and organizational structure.

For example, with communications companies, it is common for the service to be delivered to one subsidiary while bills get sent to another subsidiary. Separate accounts are created for each subsidiary, one with the account class service and the other with the account class billing to reflect their different functions. An account given the account class service generally stores service item information and allows end users to analyze the customer’s usage or orders. An account given the account class billing generally stores information for the financial transaction or invoice.

Siebel Communications does not restrict parent-child associations by using the account class. Any class can be a child of any other class. For example, a customer account can be placed anywhere in the hierarchy, and a billing account can be the parent or the child of a service account. To enforce hierarchy rules by using the account class, you must set them up through state models. For more information about state models, see Siebel Business Process Framework: Workflow Guide.

By default,Siebel Communications provides the following classes for accounts:

• Customer Class. An account with this class represents the actual customer, person, or organization that is receiving service. A customer account includes basic customer information, such as the company name and headquarters address. It can receive both service and bills.

• Service Aggregator Class. An account with this class receives aggregate usage details for all of its subsidiary accounts. It can be anywhere in the account hierarchy. It allows you to generate and view multiple service accounts that share some specifications.

  Implementation example: A company has three offices in different states, and each office receives a wired phone service and a mobile phone service. Each office can have both services set up as separate service accounts, with each office set up as a service aggregate account for the services.

• Service Class. An account with this class receives service, but not bills. In the account hierarchy, it is the account level at which the physical delivery of the service or product occurs. It can represent a person or organization with multiple service addresses.

• Billing Aggregator Class. An account with this class receives aggregate billing details for all of its subsidiary accounts. It can be anywhere in the account hierarchy. It allows you to generate and view multiple billing accounts that have some of the same specifications. It can be set up to bill the customer by using certain requests, such as creating bills for the different services and rolling those separate billing statements into a billing aggregate account. It also allows you to create and maintain billing aggregation points and to support complex discounting methods. It receives and aggregates bills.

  Implementation example: A company has offices in different states, and each office receives services two different services: broadband TV and broadband Internet. Each office can have both services set up as separate billing accounts, and each office can be set up as a billing aggregate account for the services. Then the corporate headquarters can be set up as a billing aggregate for the three offices and a single payment can be made for the services.

• Billing Class. An account with this class is used to invoice the customer for products and services. In the account hierarchy, it is the account level at which the financial transactions for the service or product occur. It shows the collection of all charges applied to a customer in a given time frame for which the customer must submit payment.

Siebel Communications displays the following information that is based on the account class:

• The Service Account and Billing Account Explorers filter on account class.

• In the Quotes and Order Entry views, only those accounts with the appropriate account class appear in the dialog box for association.

Note: You can set up additional account classes or rename the default classes. However, when renaming, be careful to also rename the explorers because they filter accounts on class names. For information about modifying account classes, see Siebel Applications Administration Guide.

The following image shows an example of an account hierarchy in which parent-child relationships are established along service and billing account classes. In the following image, Customer Account has the following children:

• Service Aggregator Account

  Service Aggregator Account has the following children: Service Account and Service Aggregator Account.

  Service Aggregator Account has the following child: Service Account.

• Service Account

• Billing Account

• Billing Aggregator Account

  Billing Aggregator Account has the following children: Billing Account and Billing Aggregator Account.

  Billing Aggregator Account has the following child: Billing Account.