Describing Special Types of Billing

• Employee Billing

  Utility company employees can be billed at a discount. The discount may apply to prices, flat rates, free quantities, etc. An interface to a payroll system (such as HR) to determine the imputed income is not yet available.

• Company and Plant Consumption

  The utility company's own consumption is divided into company consumption, which is the energy a utility uses for its own purposes (such as lighting an office building), and plant consumption, the energy used in the production and distribution of energy. Both types of consumption can be billed with the standard IS-U billing functions. For internal accounting purposes, the costs of company and plant consumption can be allocated to different cost centers.

• Small Power Producers/Co-generators

  The utility company may also be supplied with power from a number of different types of power producers, such as hydroelectric or solar power plants. These companies are called small power producers.

  Energy purchasing and energy supply are billed similarly in IS-U, using similar means of bill creation. The bill for energy purchasing and the bill for energy supply are created at the same time.

With the growing popularity of customer solar power installations, the need for net-metering solutions is significant. Many customers will produce power and supply it to the grid, becoming a net-producer rather than a net-user. Billing can accommodate these scenarios.

A billing schema contains rates, variant programs, and operands. You determine the following in a billing schema: the rates for billing, the schema steps used, and the sequence in which the schema steps are to be carried out.

A billing schema can contain more rates than are actually required to bill a certain installation. For this reason, a billing schema can, for example, contain two rates (off-peak and on-peak rate), even though the installation only has one single-rate meter. In this case, only the on-peak rate is billed. The off-peak rate specified in the schema is ignored.

The GROSS GROUP combines all the prices that are processed in different variants. These prices are components of gross prices. Each gross group can only have one variant for processing a gross price. For these variants, you must select the Gross line item field in the schema, and the corresponding price must be a gross price.

If you want to process the gross price, you must select the Gross line item field in the price schema.

The presort key stored in the billing documents (determined from the billing schema) for the printing the billing documents must refer to the function module ISU_BILL_TYPE_GROSS_PRICE_CONT (invoice category for gross prices for the billing). The billing document line items are sorted according to contracts; in other words, for each contract, one or more value-added tax line items are printed on the invoice. The No subtotal parameter is not taken into account when gross prices are processed.

You also define an account for entering gross price tolerances that may occur as a result of inconsistent gross billing documents. All the gross line items in the billing document are included in the bill sum total. They are not, however, relevant for posting. The actual posting-relevant line items in the billing document, including value-added tax, do not have to be identical with the gross price. To clear these differences, an offsetting item is posted to the open item.

The maximum permissible difference is 0.01 cent for each value-added tax item. If this is exceeded, the system stops invoicing the invoice unit.

Note that only the gross line items in the billing document are included in the print document. The individual price components cannot be printed.

The RTP interface can determine values for maximum demand as well as values for on- and off-peak rate times.

A synthetic profile represents the consumption template for a customer / customer group and is allocated to the installation A customer's individual consumption pattern is calculated using the consumption factor.

The values in synthetic profiles are determined using reference measurements or statistical methods, and saved as a day profile in the energy data repository.

The structure of the synthetic profile is determined depending on the allocation of season, day and time-of use groups.

When synthetic profiles are generated, the day profiles (standard load profiles) are determined according to the hierarchy. Profile values from the day types are then transferred to the synthetic profile according to the hierarchy specifications.

The consumption factor represents the relationship of customer consumption to the standardized consumption value of the synthetic profile.

In the example above, the synthetic profile is standardized to 1000 kWh. The actual customer consumption is 900 kWh. The consumption factor is automatically determined using the variant program QUANTI24. This is done by dividing the customer consumption by the standardized value of the synthetic profile.

• Usage factor = 900 kWh / 1000 kWh = 0.9

Update the consumption factor

• Usage factors are automatically calculated and updated by means of consumption quantity determination in IS-U Billing. During this process, the billing period in which the consumption occurred is included for each installation. It is possible to specify for each synthetic profile of the installation whether or not the consumption quantity determination updates the usage factor.

IS-U uses separate contracts and installations to model components of a contract that apply to several divisions, but belong to different companies and in turn to different company codes.

The water meter and its technical data is, therefore, installed in a (water) installation.

In addition to this, the water meter is installed for billing - this means, with rate data - in another installation with another division (waste water) and another company code.

The contracts can now be billed individually or jointly in one bill.

The consumption and the amount are written directly in the consumption history using QUANTI23. This enables you, for example, to display graphic of the customer consumption pattern and the accompanying amounts in the customer overview.

The consumption history is also evaluated for the internet self service scenario.

Data is also cumulated in BW (Business Information Warehouse) according to consumption month and contract, and updated. The system calculates the previous month from the extraction date in BW up to the point when the IS-U contracts in BW are supplied with consumption values. Normally, consumption values from the table DBERCHV (consumption history) are used for the billed billing documents from selected contracts.

All the billing master data can be transported using the report REA_BILL_MASTER_DATA_TRANSPORT.

Before transporting data, read the report documentation to familiarize yourself with the transport rules.

DPC enables you to process billing documents based on estimated consumption. You can correct all these estimated billings with real meter readings WITHOUT cancellation on ONE new billing document.

Unavailable meter reading results can be extrapolated.

These meter reading results are only required for creating billing documents and are not managed as data (saved).

Two options for multiple-contract billing in S/4HANA Utilities:

• EDM (Energy Data Management)

  • Formation of meter reading data pool before billing is carried out

  • Aggregation of technical data

• Multiple-contract billing (using the Master Agreement in CRM)

  • Pool formation during billing

  • Aggregation of business data

The SAP S/4HANA Utilities system provides three methods for mapping and billing serial switchings:

• The specific register relationship with the register relationship type "02" Serial Switching Relationship.

• Mapping with rate average (rate solution)

• Mapping using installation groups

One use of the installation groups is billing serial switchings:

• Define the utility installation with the primary register as the primary installation of an installation group

• You define the utility installation with secondary registers as secondary installations of the installation group

• You use the data exchange of secondary installations in the main installation in order to access the consumption values of the secondary installation when billing the primary installation.

• If you want the difference in consumption (consumption from primary registers minus sum of consumption from secondary registers) to be distributed to the secondary installations, you can exchange data from the primary installation to the secondary installation.

• Installation group connects multiple installations

• Billing allows the exchange of data within an installation group

  • Customizing controls access to secondary installation consumption values

  • Distribution as BAdI

  • Connection of billing documents

• Sequence control for billing

• Interval checks for meter reading results

• Move meter reading results

• Simulation of missing meter reading results and correction with DPC II

• Reversal

  • Reversal of the entire installation group

  • Individual reversal

• Outsorting

  • Outsorting of all documents for distribution bills

• Monitoring

  • Installation group as a selection criteria

The most important aspect of installation groups is that they support a new form of cross-installation billing. You can access data from secondary installation billing when billing primary installations. You can also access data from primary installation billing when billing secondary installations.

This is an alternative to the previous method for billing serial switchings, in which all secondary registers must be installed in both the secondary installation and the primary installation.

For a detailed description, see the Installation Groups document at http://service.sap.com/utilities→Product Information→→IS-U/CCS→Billing/Invoicing→Cookbooks&Guidelines. This document explains what Customizing is necessary, how the data exchange functions, and which types of billing are supported. You also find examples of various serial switching scenarios.