Billing master data enables you to specify contract billing rules for residential, commercial and industrial customers and provides the basis for a complete mapping of all rates.
The extremely flexible and universal structuring of rates allows you to implement new and creative sales and marketing concepts. An open architecture allows you to adapt and succeed in a changing environment.
The rate is determined dynamically from the rate type of the register and the rate category of the installation.
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 streetlights), 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 streetlights with a specific connection value).
Generally, you enter the rate type in the register. Examples of rate categories are peak and off-peak rates for active energy, peak rates for reactive energy, peak rates for active power, as well as gas and water consumption.
You can also allocate the rate type to the following objects:
- Device: for devices without registers (such as ripple control receivers) you can use the rate type to find special rates. Using these, you can calculate a device-based clearing price.
- Facts: used to determine rates that cannot be derived from registers. Also used to determines rates for flat rate installations without installed devices.
- Reference Values: used to model street lights, for example.
The rate determination is managed historically.
This has the advantage that rate changes can be performed easily. You are then not required to change the rate types and rate categories in the master data. Instead, a new rate is determined starting at a new from-date.
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.
A rate is a billing rule for a register or a reference value, that is, all billing-related steps executed during billing.
The rates specify the following:
- How measured consumption values are extrapolated or divided up during meter reading data processing and prorations.
- Which billing-related values are measured by a register.
- Which reference values are billed (for example, for flat-rate services).
- In which calculation formulas the measured values or reference values are used.
- Which prices are used.
- Which constants, factors, and influencing factors are included in the calculation.
- To which general ledger accounts the calculation results (bill line items) are posted.
- How the bill line items are treated statistically.
- The division and billing classes to which the rate is allocated.
A rate step is represented by one or more variant programs. These are small, independent programs that perform elementary calculation steps.
- Several rate fact groups can be allocated to one rate. In this way, if the same rate is used, the operands can still be filled with different values.
- A rate step is determined by the variant that is being used.
- Variants are small, independent programs that perform elementary calculation steps.
- Many variants calculate values relevant to billing and therefore generate billing line items. Other variants convert values and make the results available to subsequent variants.
- Variants usually have input and output operands which represent the parameters included in the variant. These operands belong to a particular operand category.
- In the rate, a combination of variants is used to model the billing rules.
- Example of fact group: the rate fact group X contains the rate facts "minimum demand = 20 kW" and "discount rate = 10%". This means that if the customer uses at least 20 kW, he/she receives a discount of 10%.
Variants are modules in the rate or in the schema that contain a billing rule.
A sub-transaction is a key that classifies the document item for account determination. It differentiates the main transaction.
Optional billing step indicator: Schema steps can only be executed in billing if all input operands are supplied with values for the entire period that the step covers. If this is not the case, the optional indicator is checked:
- If the indicator is not set, billing of the contract is terminated
- If the indicator is set, the schema step is not executed. Processing then continues with the next schema step.
Input and output operand: Description determined within a company for the values that are used as input and output parameters in variant programs.
Statistical rate: You must specify a statistical rate for all rate steps that generate billing line items. During billing, the statistical rate is written to the billing line item. This rate key can be used to analyze the billing documents.
Franchise fee group: A company's own grouping of business partners subject to the same franchise fee conditions (such as major customers or households).
Fine-tuned variant control: Some variant programs require additional input parameters to define the action of the variant programs. Example: Depending on the settings, a variant that subtracts two values can also create negative differences or suppress them.
A fact group is the grouping of individual facts allocated to a rate. Facts are:
- Concrete values such as 100 kW
- Keys, for example for prices that are allocated to operands and are valid for a certain period of time.
Operands are allocated to the fact group and manage the operand values.
The operand values represent the historically managed characteristics of the operands. Example: Fact group X contains the following rate facts:
- Minimum demand 20 kW
- Discount 10%
This means that if the customer uses at least 20 kW, he/she receives a discount of 10%.
The operand category classifies the operands for the variant programs.
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 predefined by SAP and cannot be changed.
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.
A schema is a structure that determines the sequence in which variant programs of the rates to be billed are executed.
The price categories are predefined by SAP and cannot be changed. They are used internally to control data processing. Normally, you create the prices based on the rate. In this case, the correct rate is proposed by the system.
The price type specifies how the particular price is to be used.
In addition to standard single prices, you can also use scale and block prices. Block and scale limits are maintained in the historical data.
Certain sequential quantity ranges (for demand and/or energy) are defined by price scaling. If one quantity range is exceeded, the price for the next quantity range applies for the entire quantity. In this way, higher consumption can be cheaper than lower consumption.
Certain sequential quantity areas (for demand and/or energy) are defined by price blocking for which certain prices apply, in other words different prices are used. This prevents higher consumption from being cheaper than lower consumption.
Billing is the process of evaluating pricing data, which is relevant for the period being billed, determining the quantity to be billed for the various components, and calculating the results. Billing is executed at the contract level. Billing simulation can be executed to test the results of the billing process. Billing thresholds and checks, through outsorting, can be implemented to temporarily prevent billing documents from processing to the next step.
- Meter reading orders are created for each register.
- Billing orders are created for each contract.
- A billing order is automatically created with the meter reading order. However, the billing order does not have billable status. The billing order can only be billed once plausible meter reading results have been entered.
- The billing order is deleted during billing. The billing process creates a billing document that is the basis for invoicing.
- The billing period for which the utility bills the customer can be determined in a number of ways. These are:
- For an exact number of days: Determines the exact length of the billing period in days, for example the period between the last billed meter reading and the current day of meter reading.
- Month-based: Bills a specific number of complete months. If the case of a move-in or move-out, the month-based procedure can be billed based on the number of days.
- There are two types of billing:
- Simulation, which creates simulation documents.
- Billing, which creates billing documents.
- Outsorted billing documents require additional processing - Documents must be either released or reversed. Reasons for outsorting:
- Failed validation.
- Indicator set in the contract.
- Individual or mass reversals enable quick correction and subsequent billing.
The invoicing process is executed after the billing process. Invoicing links contract billing to contract accounts receivable and payable and prepares bill printout.
The bill sum total is determined after clearing billing documents against the budget billings already paid, and against the taxes, charges, and duties that are due. Flexible clearing options, such as payments for open items, reduce the amount of manual processing required.
The bill sum total is calculated as follows:
Bill sum total = Total receivables from billing - paid budget billings - other credits (credit memo, payment on account) + other receivables (backbilling, dunning charge).
Invoicing is the process that integrates contract billing with the Contract Accounts Receivable and Payable (FI-CA) component. It also forms the basis for bill creation.
Optional invoicing tasks:
- Account maintenance.
- Interest on Cash securities.
- Interest on Receivables.
- Dunning.
- Late Payment Charges.
Invoicing is used for the following:
- Grouping together billing documents of contracts from the same contract account into one joint bill.
- Posting documents to FI-CA (sub-ledger accounting).
- Supplying bill printout documents for bill creation.
- Processing budget billing plans
Outsorted invoice documents require additional processing - Documents must be either released or reversed. Reasons for outsorting:
- Failed validation
- Indicator set in the contract contract
- Individual or mass reversals enable quick correction and subsequent invoicing
