Understanding Billing Commercial and Industrial Contracts

This lesson has 3 main topics:

1. 3-Peak Average with Floating Backbilling
2. Rate - Time Period Control - Variant Control
3. Demand Billing – Cosine Phi – Period-End Billing

The customer is charged for the service on the basis of the active power (kW) consumed, or on the service terms agreed in the contact. In this case, the active power consumed is equal to the average demand values (rounded to full kW) measured within one billing month over a period of n minutes (for example, n=15, 30, or 60 minutes).

The demand calculation in a monthly billing is based not only on the peak demand value measured in a month, but also on the average peak demand values over n periods. In the following example, the 3-peak averages of the highest measured demands are to be calculated and provided for billing. This calculation will provide the provisional peak demand value for the year, formed from the three highest monthly peak demands during the billing year. The following example explains how the 3-peak average is calculated on the basis of a 12-month billing period. The scheduling dates (end of the billing period - start of the backbilling period) are used as a comparison period.

The following table shows a section of the schema for this billing rule. In addition to the demand calculation (rate E7_3), the on-peak (rate E7_1) and off-peak consumption (rate E7_2) are charged in this example.

Variant: Name of the variant program

PR: Billing line items relevant to posting

1st Inp. Op.: First input operand

2nd Inp. Op.: Second input operand

1st Outp. Op.: Output operand

ExBB: Execute backbilling indicator

BB: Execute schema step in backbilling only indicator

AllBB1: Allocate backbilling indicator

RevBB1: Reverse backbilling indicator

In demand rate E7_3, the current measured demand is transferred to the installation facts using INFACT01. This demand is also updated to the operand planned for peak averaging and required for the current period using DEMAND14. At this point, it only contains one demand value (if only the peak monthly demand value is to be considered). In the next step, backbilling is triggered with BACKBI01. In the Execute backbilling indicator column, you specify which steps are to be carried out in backbilling. In the next step, you write the demand values for the previous periods (adjustment periods) to the output operand for peak averaging using the same group assignment and variant BACKBI03.

Example:

The backbilling period starts on January 1 and ends on December 31 of the same year. The current billing month is April. 40 kW was measured in April.

The following demand values have so far been entered using INFACT01 in the installation facts (demand values from the meter reading):

After the BACKBI03 variant has been run, the following values for calculating the 3-peak average are available in the current billing period:

During demand preprocessing, the 3-peak average is calculated on the basis of the number of peaks specified in the operand.

In the above example, the demand values 30 kW, 20 kW, and 40 kW are used to calculate the 3-peak average. The result is 30 kW.

In the next step, the calculated peak average is compared with the minimum demand, which is also entered in the facts (rate, rate category, or installation facts). For this purpose, variant DEMAND07 writes the result to the output operand that represents the demand to be cleared. Depending on the fine-tuning control settings, the higher or lower value in this comparison is written to the output operand.

This information is required for the following (+ 1 month) period billing. For this reason, the next step will, in the future (depending on the fine-tuning control setting), involve updating this value with INFACT01.

The demand is valuated for the current period with DEMAND01.

Up to this point, the 3-peak average has been calculated, a comparison has been made with the previous clearing demand, and the current clearing has been valuated.

Example:

The 3-peak average (calculated from the meter reading results from January to April) is 30 kW. The minimum demand as agreed in the contract is 15 kW; in other words, in the current billing period (April), billing line items are created (DEMAND01) for the demand value of 30 kW. Using INFACT01, you update this value to the installation facts for billing in May. The following schema steps now check whether backbilling for January to March is necessary.

30 kW peak average > 15 kW minimum demand results in the demand of 30 kW, which is to be cleared in the current billing period (April).

In the next step, you use variant IF00 to check whether the current clearing demand corresponds to the previous month's clearing demand. If so (condition fulfilled), backbilling is not carried out; in other words, billing for this installation is completed, since, in this example, no further processing steps are defined in the billing schema.

If the condition is not fulfilled (the current clearing demand is greater or smaller than that of the previous month), all the preceding periods have to be reversed and revaluated using the currently calculated clearing demand. For this reason, the current clearing demand is first written to the adjustment period by means of BACKBI02.

When backbilling is triggered using BACKBI01, the variant programs that have the same backbilling group (here 0003) are triggered. If these steps also contain an entry in the backbilling reversal column, schema steps marked in such a way cause the billing line items generated in the preceding periods (adjustment periods) to be reversed.

Example:

The billings up to March have taken into account a clearing demand of 20 kW.

In billing for April, a new clearing demand has been calculated. After variant BACKBI02 has been executed, the following data is available:

Backbilling is triggered using BACKBI01. By means of variant DEMAND01, which has the Execute backbilling indicator, 30 kW are charged for the individual adjustment periods, and (as a result of the backbilling reversal indicator) 20 kW from the individual adjustment periods are reversed. The current billing month (in this case April) remains unaffected by this.

The following descriptions refer to the demand rate, in which the peak average is formed and floating backbilling is carried out.

Key:

ExBB: Execute backbilling indicator

BB: Execute schema step in backbilling only indicator

AllBB1: Allocate backbilling indicator

RevBB1:Reverse backbilling indicator

The individual backbilling indicators for the BACKBI variants are defined in the billing schema. The backbilling indicators are modeled in Customizing using 'backbilling groups'. These groups are allocated in the backbilling indicators. You need these backbilling groups, for example, to carry out backbilling or period-end billing in the schema. Using these backbilling groups, you can combine rate steps for backbilling and period-end billing.

Backbilling groups can be found in the SAP Reference IMG. To access them, choose SAP Utilities→Contract Billing→Billing Mater Data→Rate Structure→Schemas→Define Backbilling Groups.

Variants of the variant type 09 (= backbilling variant) can trigger backbilling. To do so, you must enter a backbilling group in the execute backbilling indicator for each variant of this type in the schema.

This indicator contains a backbilling group that is assigned to a schema step. This enables the schema step to be backbilled.

Using this indicator, you assign the billing line items generated by this schema step to a backbilling group. The billing line items can be reversed during backbilling.

If this indicator is set, the schema step is only executed in backbilling. The indicator, therefore, must only be set if at least one backbilling assignment indicator is also set.

Operands of the type DEMAND and QUANT can be defined as register operands. The indicator defines the use of operands in the rate.

In the rate header, only operands whose indicator has also been set accordingly can be used as register operands. In the rate steps, operands can only be used if the indicator is not set, or if the operand is the same as the register operand in the rate header.

Furthermore, register operands of the type DEMAND must not be used to create facts in the rate, rate category, or installation. If an operand has already been defined once as a register operand or standard operand, you cannot reverse this, since this may result in inconsistencies. For this reason, you can only make changes by deleting or recreating the operand.

This operand is created for standard use. The operand is supplied with values from the rate, rate category, or installation facts.

During demand preprocessing, the value for the number of peaks is evaluated and the result of the calculation entered in this operand.

Rate models do not contain any special control features for floating backbilling or period-end billing. The time period control and variant fine-tuning control settings are, however, defined in the rate models.

Section of the rate for demand calculation.

Key:

No. Current rate step number

Variant: Name of the variant

program PC: Time period control

FT: Fine-tuned variant control

In the above example, a time period control function (entry 01 in column PC), which refers to the process for calculating the period to an exact number of days, has been accessed in Customizing. Customizing also provides time period control functions for taking special situations into account, for example:

• leap years

• move-ins

• move-outs

• values added/omitted sub-periodically (for example, device installation).

Using the period control function, you calculate the length of the billing-relevant periods. This length is also referred to as a proportion of a time slice.

Period control is specified in the rate for every rate step, in which a time-dependent calculation is carried out. Using table TE432, the period control function refers to one of three basic processes for calculating time periods (see below).

The time period is required in three cases:

1. For values valuated with time-dependent prices. In this case, the length of each time slice must be calculated, since it is used to valuate the price. Example for billing a demand to an exact number of days.

2. For values whose time slice lengths are used for calculations.

   Example for extrapolating a time-dependent amount on a monthly basis.

3. For prices whose blocks/scales are to be adjusted to the length of their time slices.

Basic procedure 01: For an exact number of days.

When the time period is calculated for an exact number of days, the difference in the number of days between the time slices is used as a time period.

In this procedure, the time period is calculated in whole months. The number of months is calculated depending on the key date. The advantage of this procedure, for example, is that exactly one month is billed if the billing period covers the key date, but not the whole month. The key date is maintained in the meter reading unit.

In this procedure, the time period is calculated in months. If the number of days in the billing period is within the interval days specified in the portion, the months in the planned billing period from the portion are used as a time period. If the days in the billing period are not within the interval, the time periods are calculated for exact days. The time portion in days can either be scaled to the standard month (30 days) or to the standard year (365 days).

Using the 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.

The following control functions have been activated here:

• Information lines relating to demand are not written

• Update in billing period with proration

This setting was selected so that all the values within the billing period are also available. It prevents information lines from being written, since this information is generated at a later stage using variant DEMAND01.

The following control functions have been activated here:

• Info lines relating to demand are not written

• Added during update

The information lines are not required here either. The control function relating to updating is not relevant in this example, since the operand is used for the first time in this rate.

The indicator for deleting the backbilling line items that are not required is not activated.

This indicator is not used in this example, since, for example, the maximum price in backbilling is not calculated, and line items that are not required may have to be deleted.

The following control functions have been activated here:

• Only billing-relevant information is written

• The higher demand is determined

• Data is overwritten during updating

• Information lines relating to the demand comparison are written

Information lines relating to demand, in particular register meter readings, are written. The level of detail can be specified as follows:

• No info lines are written.

• Infolines are written on the service(s) to be billed.

• Info lines relating to both the method for calculating the relevant demand and the meter readings not included in the calculation are written.

Information on the calculation method is provided with all the billing line items, which include additional information, rather than in separate info lines. The following fields are maintained:

ZAHL1 = First demand

MASS1 = Dimension of the first demand

ZAHL2 = Second demand

MASS2 = Dimension of the second demand

ZAHL3 = Greater/smaller than the two demands

You can also use the control function to prevent info lines from being written.

The control function specifies the two comparison options:

• Calculation of the greater of the two demands

• Calculation of the smaller of the two demands

Using the control function, you must also define the type of operand update procedure. Since the output operand is only being used for the first time in this example too, the control function is not required.

Example:

The calculated 3-peak average is compared with a predefined minimum demand in the contract (rate, rate category, or installation facts). The greater of the two demands is billed.

The following control functions have been activated here:

• Info lines regarding demand are not written

• Update future demand

The required information lines are written in the next step.

The demand (in this case, the demand to be cleared) must be updated for the future to ensure that this demand value is available for the next period billing. This value is written on a proration basis to the installation facts for the installation to be billed. If the operand is not available in the facts, it is created. In rate step 8, the value is compared with the new clearing demand and, if necessary, backbilling is carried out.

The following control functions have been activated here:

• Only billing-relevant information is written.

To enable the information to be displayed on the bill (these information lines were suppressed up to now), you choose this control function.

The following control functions have been activated here:

• Demand 1 = Demand 2

• Use current value

The relational operator between the two demands must be specified. You can basically choose the following for this purpose:

• If Demand1 > Demand2

• If Demand1 >= Demand2

• If Demand1 = Demand2

Demand1 corresponds to the previous month's clearing demand. Demand2 is the current clearing demand. If this demand is the same as the previous month's clearing demand, backbilling is not carried out. If these values are different (demand 2 is greater or less than demand 1), the previous month must be backbilled.

The billing period may contain several different values, for example, due to prorations. For this reason, you must specify the value to be used. For this setting, the value that is valid at the end of the billing period is used.

Not activated.

With this control function, billing line items for backbilling that are not required are not suppressed, since, in this case, they are not part of the contract.

Example of when this control function is activated:

Backbilling for calculating demand with a maximum price in previous billing periods is to be started to determine the maximum amount in each of the periods. If the total of the maximum amounts is greater than the total of all the energy and service amounts, the result from calculating the highest amount is to be reversed. If the control function for deleting backbilling line items that are not needed is selected, the billing line items for the maximum amount are deleted, otherwise the maximum amounts are set as negative values.

The rate category is entered in the utility installation. It determines the criteria for the billing rates, for example, the backbilling and/or period-end billing control function. When the rate category in the installation is changed, the periods in billing are analyzed separately.

During backbilling or period-end billing, you must not change the rate category within the backbilling period or period-end billing period.

Instead of charging the customer for the demand, the active energy during the on-peak rate period, active energy during the off-peak rate period, and basic price flat rates, you calculate a charge by multiplying the price limit by the minimum energy. The minimum energy in kWh is calculated from the sum of the active energy during the on- peak rate period and the active energy during the off-peak rate period used during the calendar year (period billing).

The bill is created either in a separate bill (period-end billing), or included with the last period billing.

In this period-end billing, the active energy consumed during the on-peak rate period and off-peak rate period (which is updated in the individual period billings) is added. This amount is valuated using a defined maximum price. The result of this calculation is compared with the sum of the amounts from the individual rates in the period billings. The amounts are updated for each rate in the period billings.

If you establish during period-end billing that the period billings during the calendar year were more favorable for the customer, no further billing is carried out. If the comparison yields a negative result, that is, during period-end billing, you establish that the bills created in the adjustment periods (period billings) are not in the customer's favor, the individual adjustment periods are credited, and the valuation from period-end billing is charged to the customer.

This example takes into account the following special features in period-end billing. It is assumed that the customer uses electricity with a defined cosine phi.

Overcompensation above this agreed value is billed at a special price.

The percentage ratio for the normal-rate reactive energy and the normal-rate active energy is used to calculate the current demand factor (cosine phi).

The following table shows an extract of the schema for this billing rule. In addition to the demand calculation (rate E8_3), on-peak (rate E8_1) and off-peak consumption (rate E8_2) are charged in this example. Overcompensation for the reactive current rate is calculated using a separate rate (rate E8_4).

In addition, deletion operand EAMOUNT_4 must be defined for schema step 18 to create a reference to the UTILIT01 variant in schema step 22.

Key:

Variant: Name of the variant program

PR: Billing line items relevant to posting

1st Inp. Op.: First input operand

2nd Inp. Op.: Second input operand

1st Outp. Op.: Output operand

ExBB: Execute backbilling indicator

BB: Execute schema step in backbilling only indicator

AllBB1: Allocate backbilling indicator

RevBB1: Reverse backbilling indicator

In addition to the calculation of the on-peak rate active energy (QUANTI01), the rate components of on-peak rate E8_1 contain a time-based flat rate calculation with variant LUMSUM01. The meter reading results and the calculated total amount are updated with the appropriate variants (INFACT06 = for the quantities and INFACT02 for the amounts) to the facts for the current installation. With variant QUANTI14, the current meter reading difference (which corresponds to the consumption) is transferred independently of the rate. This step is necessary to define the demand factor (cosine phi) in rate E8_4.

The off-peak rate (E8_2) is valuated using variant QUANTI01. In this case too, the quantity and the calculated amount is updated to the installation facts.

The demand rate only provides for the valuation of the current demand measured in the current month. This is obtained using variant DEMAND01. The calculated amount is also written to the installation facts.

The reactive current calculation is modeled in rate E8_4. In the first step of this rate, the cosine phi is calculated using QUANTI13 from the on-peak rate active energy and reactive energy. The value entered in the first operand is interpreted as active energy, and the value entered in the second operand as reactive energy. Each of the values entered are cumulated, that is, if more than one register is involved, the consumption values are added first. The on-peak rate value results from rate E8_1 that transferred the consumption independently of the rate. The IF03 now checks whether a cosine phi entered in the facts is greater than the current demand factor calculated. If so, a n-% proportion of the on-peak rate active energy is calculated using variant QUANTI09.

The result is deducted from the measured reactive energy using variant QUANTI02. With QUANTI01, this quantity is now valuated with a price. The rate nesting is ended using ENDIF.

The final rate, E8_E, is only run in period-end billing. Furthermore, the header data of this rate specifies that it may only be used in period-end billing. After the period billings, a separate period-end billing order is created if the rate category does not provide for period billing with integrated period-end billing.

With variant QUANTI10, the on-peak and off-peak rate quantities cumulated from the period billings are added. This result is valuated with the maximum price with variant QUANTI01. To be able to compare the amounts from the period billings with the amount just calculated, the cumulated on-peak and off-peak rate amounts from the period billings must first be added using variant COMPUT02. In the second step, the total is added to the amount for the demand rate from the period billings. Variant IF02 now compares these amounts. If the calculation in the period billing is more favorable for the customer, the billing line item generated during period-end billing is deleted using UTILIT01. If the comparison yields a negative result, variant BACKBI01 is used to reverse the billing line items (variants) for which the backbilling reversal group is set. The billing line items generated during period-end billing are charged to the customer.

The rate category is entered in the utility installation, and controls the following:

• monthly billing

• period-end billing and floating backbilling

• the outsorting check

• other billing-relevant data (for example, agreed quantities, demands, prices, or flat rates).

There are essentially three control options for period-end billing:

• No period-end billing

• Integrated period-end billing

• Separate period-end billing

The above example uses the 'separate period-end billing' process.

Billing does not provide for any billing rule relating to period-end billing.

If this indicator is set, integrated period-end billing is carried out for the contracts assigned to this rate category. In integrated period-end billing, period-end billing is carried out along with the last periodic billing for the period-end billing period (or final billing).

The billing line items resulting from period-end billing are added to the billing document (billing that triggers period-end billing). A separate period-end billing document is not created. In period-end billing, the number of periods covered by period-end billing must be entered.

If this indicator is set, separate period-end billing is carried out for the contracts assigned to this rate category. For this purpose, a period-end billing order is created when the last periodic billing for the period-end billing period (or final billing) is carried out. Period-end billing is executed when the period-end billing order is billed. To do so, you can determine whether period-end billing has to be executed before the next periodic billing.

You can also determine the minimum number of days after the last periodic billing that period-end billing can be carried out. Billing the period-end billing order results in a separate billing document (period-end billing document). In period-end billing, the number of periods covered by period-end billing must be entered.

If a period-end billing order is generated when a contract is billed, the value of the field is transferred from the corresponding rate category to the period-end billing order.

It has the following role here:

When this indicator is set, a period-end billing order has priority over another order. If there is another billing order with a different billing procedure for the same contract (periodic, interim billing, etc), this must not be billed until the period-end billing order has been billed.

If this indicator is not set, the period-end billing order does not have a priority. A periodic order for the same contract can be billed before the period-end billing order. This ensures that the next periodic billing is not missed because period-end billing is delayed. This indicator is only relevant for rate categories with period-end billing, and must be set so that the results of period-end billing are used in the next periodic billing.

Example: when the period-end billing rate is executed, values are written to the installation facts and are used in the next periodic billing. The indicator must be set for this procedure.

This field is only relevant in the event of a separate period-end billing. Here, you determine the number of days between the last periodic billing of a period-end billing period (or final billing) and the billing of the period-end billing order.

Period-end billing cannot be carried out before the specified number of days has passed.

Example: The difference specified is 5 days. The last periodic billing was executed on January 3, 2000. This means that the earliest date on which period-end billing can take place is January 8, 2000.

Here, you determine the number of periods covered by the period-end billing period in period-end billing.

In the header data for the period-end billing rate, you must set the usage indicator (permissibility) "Period-end billing permitted".

The rate steps for the period-end billing rate are actually only executed in period-end billing.

In the billing schema, exactly one rate can be added in the billing schema for which the indicator 'Permissible as period-end billing rate' is set. This means that period-end billing can be carried out with the schema. The key for this rate is displayed in the schema header. The steps for this rate are added at the end of the schema.