Identifying Billing Master Data in SAP Utilities

• Classifies installations within a division, for example residential/C&I contract
• Can be valid for multiple rate categories
• Used for validation in scheduling and in the billing master data
• Enables several franchise fee groups to be defined
• Can be used as a statistical criterion
• If you change the billing class, you must also change the rate category. You do not have to perform a final billing

The billing class classifies installations for billing.

The billing class is also used for the following purposes:

• For consistency verifications between the master data and billing master data. For example, you can verify that a residential customer's installation has not been allocated to a nonresidential contract.
• As a statistical criterion, for example in the sales statistics.

The billing class is used in the following objects:

• Installation
• Rate category
• Rate type
• Price
• Rate
• Schema
• Portion
• MR unit

You can allocate the different billing master data to different billing classes. This means that each time the billing class is used, a mutual check is carried out for permissibility and consistency. The check is performed in connection with the division.

The billing class is optional in the meter reading unit, portion, and rate type.

You can maintain rate types in the following objects:

Register

In the case of registers relevant to billing, you must specify a rate type in the installation structure. In this way, you specify that the consumption or the demand of a register is billed using the corresponding rate. Quantity determination during extrapolation (zero consumption despite contract allocation) can be influenced by an additional indicator for rate types that are permitted for registers.

Device

You can specify a rate type for a device if, for example, you wish to levy a rental price at device level. This is particularly relevant if the device does not contain any registers relevant to billing.

Rate category

You can specify rate types in the rate category to perform billing of values not related to registers. For example: By means of the rate type, a rate is determined that is used to bill a flat rate.

Installation

If, for example, you wish to levy a flat rate for a certain installation only, you enter the rate type in the installation facts, but not in the rate category.

The price key is the name of a price; the price key is also called "price". Control data such as division, billing class, time basis, and rounding are also stored in the header data of prices.

The actual values are stored in the prices. Prorated price amounts are also managed in the prices. If the price changes, the new time slice is entered here. In this case, the header data does not change.

The price key also contains a currency key. This means that if you use different currencies for billing, you must maintain all prices in the different currencies.

You establish the currency that is valid for a particular customer in the Trans. currency field in the contract account.

Block and scale prices are defined centrally in price management. For both prices, you must define quantity limits. The price type specifies whether the price is a block or scale price.

According to the price type, the system determines different prices during billing.

• For block prices, the quantity is valuated with different prices depending on the interval.
• For scale prices, all quantity intervals are valuated with the price that the system determines for the total quantity to be billed.
• The following is generated in the billing document:- Four billing document line items for price type Block Price- One billing document line items for price type Scale Price.

You can adjust the blocks/scales for quantity-based prices if the billing period differs from the basic time specified in the price key.

If you want the blocks/scales to be adjusted, you have to set the Adj.PBlcks indicator (adjust price blocks). If the adjustment is to be dependent on an interval, you must also set the interval lower and upper limits.

The block adjustment indicator is part of the header data.

A block adjustment of the amounts only takes place for block prices - not for scale prices.

The price adjustment clause establishes the price adjustment factor by which the base price is multiplied. You enter the price adjustment clause in the price for quantity- and time-based prices, and also in the flat rates. If a price adjustment clause is allocated to a price master, the corresponding prices can be changed indirectly, that is, using the factor. In this way, the same price increase can be applied to all prices having the same price adjustment clause. This process contains components for both adding and multiplying.

The price adjustment clause is used, for example, for index-dependent billing (for example, a formula dependent on oil prices and labor costs). Only the result of the formula is stored in the price adjustment clause.

Operands link values to be billed and variant programs.

An operand is allocated to an operand category and a division. Operand categories determine the functions of the operands The variant program determines which operand categories can be used as input and output operands.

The system contains 20 different operand categories.

The operand categories are predefined by SAP and cannot be changed.

Facts (normal operand)

Rate facts

Rate category facts

Installation facts

Facts from RTP interface

The output parameter number of the RTP interface is stored in the facts

Facts from ERCHV

Values are read from DBERCHV

Register operand

Values are determined from meter reading results

Using the operand groups, you can group operands in rates, rate categories, and installation facts for display purposes.

You can define a hierarchy of operand groups with three levels.

Determination of expected values (e.g. meter readings) by means of:

• Linear weighting
• Weighting of energy feeding
• Weighting of degree days
• General weighting
• Customer-specific determination

The energy feeding volume per period is used 1) for weighting in the case of a time-based breakdown of consumption, and 2) in thermal gas billing for calculating a weighted average.

For weighting of degree days, you define temperature areas that have approximately the same air temperatures. You then specify the degree day coefficients for these areas and for each degree day.

You can define the general weighting as you please. You can define both the period and the weighting values.

The register operand determines the weighting of the consumption registers. As soon as a rate type is allocated to a meter, the weighting procedure is determined via Rate Type→Rate Determination→Rate→Register Operand→Weighting Key.

In addition to defining a different weighting procedure, you can specify a fixed, linear portion as either an absolute value or a percentage.

The portion indicated as a percentage refers to the period consumption.

You specify the fixed values for the linear or percentage portion during device installation.

In this example, every demand from the installation facts is taken into consideration. In addition, proration is carried out due to the rate change.

In this example, only two time slices are created, because of the rate change. For both time slices, however, the demand value at the end of the billing period from the installation facts is used.

Operand values are usually stored in the rate facts and are, therefore, valid at rate level. Cross-rate operand values can also be defined in the rate category facts and installation facts. They have priority over the rate facts.

At rate fact and rate category fact levels, you can also enter replacement values. These replacement values give you more flexibility when allocating operand values.

You can also historically overwrite operand values. In this way, a different price key can be allocated to a certain installation for only a certain period of time, for example, a month. In the other months, the values from the rate facts are used.

If no operand value can be determined during billing, the system cancels billing and outputs an error in the application log. Exception: the rate step is marked in the rate as an optional rate step.

You define general operand values that are valid for a larger group of customers in the rate and rate category facts, and you store individual values at the installation fact level (for example, installed demand, connection loads, ordered demand, number of persons, floor area).

Installation facts can be limited to a specific contract, or they can be unlimited and valid for any contract. Contract-specific facts will be ended when a move-out is executed.

If you use operands that are stored in the installation facts and you have not activated the Contract- Related Operand indicator, the facts within a move-in/out are also retained for the new customer.

Note that the business partner may change. For this reason, it is not expedient to copy values from previous time slices. If the move-in is reversed, the active time slices as of the move-in date are deleted.

If you execute the contract change function during the move-in, the time slices that were deactivated by the move-out are reactivated in the installation facts as of the move-in date. Note that, in this case, the business partner is not changed. The existing contract is replaced by a new one. If the move-in is reversed, the active time slices as of the move-in date are deactivated again.

SAP provides a pool of variant programs with the system. This pool contains many variant programs.

Variant programs are contained in rates as rate steps. Variant programs are basic calculation steps (for example, consumption x price, determination of the basic price, or determination of the rental price).

By combining variant programs, you can model certain contract texts in the system (for example, formula for reactive current calculation).

In the above example, three variant programs are required to represent the contract text. The variant programs communicate with each other using input and output parameters. Operands are simply variables or placeholders that are filled with actual values (such as consumption, price) at runtime.

In most cases, variant programs have input and output operands which represent the ingoing and outcoming parameters (variables) of the variant program. These operands belong to a particular operand category.

SAP defines which variant program needs which input and output operands (number, operand category).

In the system, the variant programs process specified tables. During data collection for billing, these tables are filled with all required data.

SAP provides a wide range of variant programs with the system.

A simple evaluation function helps you to select the variant programs you need for the billing rule.

The keys of the variant programs have a particular semantic. For example, all variant programs that begin with QUANTI deal with consumption/quantities to be billed.

The variants are grouped as follows:

BACKBI*

Variants dealing with billing nonresidential customers

COMPUT*

Arithmetic operation

DEMAND*

Demand valuation

DISCNT*

Discounts, surcharges

INFACT*

Writing of values in the installation facts

IF/ELSE/ENDIF

Conditions in rate

LUMSUM*

Valuation of flat rates

QUANTI*

Valuation of consumption/quantities

REFVAL*

Valuation of reference values

SETTLE*

Calculation of rental and settlement prices

UTILIT*

Special billing features (such as best-rate billing)

The document line items control and analyze the billing rule.

Billing document line items are primarily required for bill printing, where the system may need to know which line item it is dealing with, for example in the billing form. For example, different information needs to be printed for energy price line items than for basic charge line items.

Line item types are stored in the rate in the rate steps and are automatically proposed by the system.

If necessary, additional document line item types can be defined in the customer namespace and be allocated to a variant program or rate.

The rate consists of a key, header data, and one or more rate steps. A variant program is processed for each rate step.

These are some points that the rate determines:

• How the measured consumption is extrapolated or broken down for meter reading data processing and for proration
• Which technical billing values are measured by a register
• Which reference values are billed
• In which calculation formulas the values are used
• Which prices are used
• Which general ledger accounts the calculation (bill line items) results are posted to
• How the bill line items are statistically treated
• To which division and billing class the rate is allocated

The register operand is entered in the header data. The consumption of the register is made available to billing in the register operands. The register operand is determined by choosing: Register→Rate Type→Rate Determination→Rate→Register Operand.

Larger rates with several rate steps can be documented using the notes.

The subtransactions control the account determination but can also be used as statistics criteria.

The statistical rate is used to distribute revenues and quantities of the individual rate steps over different rates for evaluation in the sales statistics.

The franchise fee group controls the calculation of the franchise fee.

Normally, these billing subtransactions do not have to be so detailed for the business partner items. As a result, they are replaced by aggregated transactions in invoicing, which optimize the number of business partner items.

A transaction is a combination of main and sub-transactions

Texts allocated to the main and sub-transactions describe the business transaction and are made available for correspondence.

Main and sub-transactions control account determination.

They also control tax determination.

IS-U uses internal main and sub-transactions, which the system assigns to the different IS-U business processes, which they then control.

The internal transactions represent only a minimum of all transactions available in the IS-U functions. You can also maintain any number of transactions for manual postings.

You can specify transactions in IS-U by means of certain characteristics such as the debit/credit indicator, the interest key, and the statistics indicator.

The internal transactions control the invoicing program. They are allocated the external customer transactions in Customizing.

Main and subtransactions fulfill three functions:

• They document the aspect of the business scenario or process, which forms the basis for posting the document item.
• An explanatory text is allocated to every main and subtransaction. This text can be used for correspondence.
• Main transactions and subtransactions influence automatic account determination.

The accumulation transactions are allocated to the internal transactions, and do not have a defined account determination.

Transactions for the price components can be freely defined and are maintained in the rates. The account determination (main transaction relevancy and transaction relevancy) is defined for them.

Transactions must be defined for all main billing transactions (consumption billing / final billing / manual billing).

The payment and transfer procedures should be allocated to the internal procedures. Account determination is not necessary.

The payment transactions must be defined as "follow-up" transactions for the extrapolation transactions.

The sub-transactions for budget billing extrapolation are maintained in the rates. They must be defined statistically (debit = "P" / credit = "Z"). Account determination must be defined for these transactions.

The account determination ID can be found in the contract account for multiple-contract or contract- independent postings, or in the contract.

The account determination ID can be found in the contract account for multiple-contract or contract- independent postings, or in the contract.

The subtransaction is also required for the revenue account determination

Additional account assignments (for example, cost center, plant) and the tax determination ID are also determined through sales revenue account determination.

The posting items from invoicing are allocated the appropriate additional account assignments from CO so that they can be forwarded to the cost accounting components.

These additional assignments were already determined in contract billing. If the billing document line item is a line item relevant for posting and is posted to a cost element, the additional account assignment from CO is determined according to the following priorities:

• Direct entry of the account assignment when the billing document line item is manually entered (if you are dealing with manual billing)
• Specifications in the contract
• Specifications in account determination (posting area R001)
• Standard account assignment of cost element (for example in transaction KA02 'change cost element')

CO account determination keys (field COKEY) are allocated to the contract master record and contract determination. The CO account determination keys encode a valid combination of the CO additional account assignments. You can maintain the CO account determination keys in Customizing under Financial Accounting→Contract Accounts Receivable and Payable→Basic Functions→Postings and Documents→Document→Store Short Account Assignments for IS-U Contracts or for Define CO Short Account Assignments.

You can control how periods are to be calculated by means of the period control in the rate steps.

The following procedures are supported:

• To-the-day
• For an exact number of months with a key date
• For an exact number of months with intervals

The above procedures can also be dealt with differently in certain special cases (such as move- in/out).

The key date for month-related billing is entered in the meter reading unit.

The intervals for month-related billing are entered in the portion.

For calculating month-based time portions depending on an interval, additional values can be stored daily intervals using the enhanced interval procedure.

In the enhanced interval procedure:

• To the month with key date refers to the calendar month
• The interval procedure refers to the duration of the billing period. In the enhanced interval procedure, the limits can be specified for any period (rather than for just one month).

Using variant control, you can control the different variant programs. Control indicators are not the same for all variant programs, but depend instead on the task of each variant program.

Concrete values, keys that the operands have been allocated and that are valid for a particular period, are referred to as facts. Depending on the level at which the key is allocated, these are either installation, rate or rate category facts.

Using the fact group, you can assign different values to individual operands in the rate facts.

A fact group must always be entered in combination with a rate type.

At rate level or rate-category-fact level, you can enter a replacement value instead of a fixed operand value (mandatory/optional entries are required at sub-ordinate levels). These replacement values give you more flexibility when allocating operand values.

Operand values are usually stored in the rate facts and are, therefore, valid at rate level. Cross-rate operand values can also be defined in the rate category facts and installation facts. They have priority over the rate facts.

At rate fact and rate category fact levels, you can also enter replacement values. These replacement values give you more flexibility when allocating operand values.

You can also historically overwrite operand values. In this way, a different price key can be allocated to a certain installation for only a certain period of time, for example, a month. In the other months, the values from the rate facts are used.

If no operand value can be determined during billing, the system cancels billing and outputs an error in the application log. Exception: the rate step is marked in the rate as an optional rate step.

In the rate facts and rate category facts, you define general operand values. These apply to groups of customers. An installation fact level, you define individual values, such as connection values and number of persons.

You can override the data in the general rate category and in the facts to allow for customer-specific agreements.

You can also specify the rate type, and therefore the rate, in the facts.

However, only rate types for which the appropriate indicator is set can be used in the facts These rate types cannot be maintained at the device or register level.

This extension provides you with the following function exits:

• EXIT_SAPLE20Q_001 Adapting the search help to the rate type
• EXIT_SAPLE20Q_002 Adapting the search help to the rate fact group
• EXIT_SAPLE20Q_003 Customer-specific input checks for rate type and rate fact group
• EXIT_SAPLE20Q_004 Creating a proposal logic for the rate type and rate fact group

  For example, you can specify default if the corporation only uses one rate fact group It is also possible to let the rate fact group be recommended, for example, by regional factors.

After a rate has been changed, the schema is automatically blocked, and the billing block has to be lifted by a clerk.

A schema is always allocated to a certain billing class and division. This checks the permissibility of different billing master data against each other.

A schema is made for a particular customer group. If too many schema steps are contained in the schema, which are not processed for each customer, it results in unnecessary run time.

The schema must contain all rates that can be billed together in an installation:

• On-peak rate active energy
• Off-peak rate active energy
• On-peak rate active power

The presort key plays an important role in sorting individual billing line items for subsequent bill printout. We will look at the function of the presort key in more detail later on.

The deletion operand is required if billing line items have to be deleted while a contract is being billed, for example, in comparisons such as best-rate billing or maximum price limitation. The billing line items that are to be deleted must be provided with a deletion operand.

At each schema step, you can define whether or not the charge (such as basic price, service price, rental price) is to be billed for the disconnection period.

In Customizing for disconnection/reconnection and also in the disconnection document itself, you can differentiate more precisely whether or not the control in the schema is to be taken into account.

You enter the statistics group for quantities in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the quantities (for example, on- peak/off-peak rate active energy) in the BW. This also makes it easier to transfer data to CO-PA.

SAP ships the statistics groups 000000 to 000002 with the system as standard.

You should define the statistics groups in detail to ensure that the quantity in the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously (using rules in BW).

Always include quantity and amount as key figures and include statistic groups and the amount together in one dimension!

In the statistics group, you also define into which value fields of the operating concern the quantity in a billing line item is copied. This only applies to statistical postings in CO-PA (for example for unbilled revenue reporting).

You cannot assign any update rules to a statistics group for actual postings of the value flow in CO- PA. You control these updates using the PA transfer structure. Basically, all the billing line items in a billing document for which the field 'Billing line item relevant for posting' is set are processed for actual posting in CO-PA. The amounts from the billing line items are always transferred for actual posting. You can, however, prevent the amounts from being transferred by not setting the field 'Relevant for actual posting in CO-PA' in the statistics group quantity.

You enter the statistics group for amounts in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the amounts (for example, energy and flat rate amount) in BI. This makes it easier to transfer data to CO-PA.

SAP ships the statistics groups 000000 and 000001 with the system as standard.

You should define the statistics groups in detail to ensure that the amount in BI can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.

The rate category contains data that controls the processing of billing data. This includes:

• Billing Scheme
• Control of period-end billing and accompanying backbilling
• Outsorting checks

Any other billing-relevant data is also saved in the rate category. This includes any agreed quantities, demand, prices, or flat rates. In the case of flat rate services (such as cable services and street lights), no quantities are measured. You must therefore define replacement values that the system can use for evaluation (for example number of cable connections or number of street lights with a specific connection value).

You can group rate categories and contracts according to the statistics update procedure using statistics groups.

You find the statistics groups for rate categories on the rate category screen. The statistics group for contracts is on a contract screen.

The following are examples of different updates:

• Rate categories: "Residential customers" and Commercial and industrial customers".
• Contracts: "Standard customers" and "Individual statistics". For certain contracts (such as standard customers), individual statistics are stored.

The update group controls the update on a general level. It is determined by a combination of the various statistics groups and the division.

When contracts are billed, the division and the statistics group are determined from the contract and rate category.

Using the combination of division and statistics groups, the system determines the relevant update group and saves it in the billing document for statistics-relevant line items.

Only line items with an update group in which an entry has been made can be updated to BI.

On the basis of the update group, further differentiations can be made within BI, for example, industrial and residential customers.

Rate determination:

Rate type + rate category = Rate

The rate types/rate categories may not have to be changed in the master data if rates are reformed because the rate can be determined historically. It suffices to find new rates for a certain key date.

The system can also determine more than one rate per rate type and rate category. You can use this option, for example, to model best-rate billing in the system (low consumption rate, basic price rate 1, basic price rate 2).

The rate is comprised of a combination of the rate type and the rate category.

The rate type is generally maintained in the register. In some cases, it can be maintained at device level or in the installation facts. In addition, the rate type can be entered in the rate category facts (for example, if a device does not exist).

A rate type for reference values can also be defined in the installation facts (for example for street lighting, telephone booths).

Individual rate components must be created and maintained in a predefined sequence.

The sequence is determined by the respective links to the individual components.

The components are maintained in the following sequence:

• Rate types
• Operands
• Prices
• Rates
• Schemas
• Rate categories
• Rate determination

You do not normally create the operands and prices beforehand, instead you create them from the rate. To do so, you enter the new name (of the operand, for example) in the field and by double- clicking on it, the system automatically goes to the transaction for creating operands.

Using the billing analysis, you carry out a detailed check to ensure that your rate models are correct.

The billing analysis is not designed for processing in production operation.

Billing documents and print documents can be created from the billing analysis. These must be looked at in detail after successful billing (billing document for each contract) or invoicing (print document for each contract account).

Billing can executed as simulation.

The business partner items for the contract billing documents are constructed in detail according to:

• Company Code
• Business area
• Account determination ID
• Contract
• Division
• Main transaction
• VAT code

The general ledger items for the contract billing documents are constructed in detail according to:

• VAT code
• Sales revenue account
• CO account determination data (for example, cost center and so on)