Demonstrating Meter Reading

Meter Reading supports the organization, execution and validation of periodic and aperiodic meter reading result determination.

Meter reading results are assigned to the registers of devices. These results are evaluated within the installation structure and billed using register rates. Ultimately, meter reading results serve as the primary source for billing.

The collection of periodic meter reading results for billing is the first step of the Meter-to-Cash process in SAP S/4HANA Utilities.

The consumption determination components of SAP S/4HANA Utilities depend on customer group and measurement technology:

• Meter Reading (MR) maps the yearly meter reading of residential customers with meters with display registers.
• Advanced Metering (AMI) maps the consumption determination of residential customers with intelligent meters.
• Intelligent metering (IM4G) maps the consumption determination of residential customers with intelligent measurement systems.
• Energy Data Management (EDM) maps the monthly upload and billing of load shapes of industrial customers with interval meters.

The meter reading strategy depends on the market role:

• Meter operators (Germany) or distributors (other countries) must organize and actively execute and monitor the meter reading.
• Distributors (Germany) or suppliers (all countries) receive meter reading results via market communication.

Devices may either be read periodically for routine billing or aperiodically for control meter reading or interim meter reading. In addition, devices can be read for specific operations such as moving-in/out, installation, replacement, removal, alteration, or goods receipt.

The meter reading reason is a fixed value from SAP and it denotes the process which demands a meter reading result. When meter reading orders are formulated for reasons 01, 02, and 03, billing orders are concurrently generated for the identical billing transactions 01, 02, and 03.

The meter reading reason

• is specified by the user during order creation for periodic meter reading or when entering an interim meter reading result
• is set automatically by the underlying processes such as move-in, move-out with final billing or device installation technical / billing-related

Scheduling arranges the service territory in accordance with the cyclic execution of the M2C core processes, which include meter reading and billing. The objective of scheduling is to distribute the workload of reading and billing as uniformly as possible throughout the 52 calendar weeks in a year. Scheduling strives to establish periodic schedule records for budget billing, regular billing, and meter reading. It exclusively serves the utilities function and does not integrate with other SAP components.

Scheduling needs to factor in the weekly workload of a meter reader and is therefore closely tied to the regional structure. Within the regional structure at the city or street level, you can assign a default value for a meter reading unit. When creating the utilities installation using its address, this proposal value can be selected.

Schedule records are used to periodically initiate all mass programs involved in the M2C core processes, which include meter reading, billing, and invoicing.

In the meter reading area, the relevant programs are for creating meter reading orders and downloading meter reading orders. In the billing area, the programs handle billing execution, invoicing execution, and bill printout. In the budget billing area, the programs are responsible for budget billing and partial billing.

Schedule records are created deriving from the schedule master records. They are generated utilizing the factory calendar of the foundational schedule master records. Factory calendars are essential because a year doesn't exactly consist of 52 weeks, rather, it comprises of 52 weeks plus one or two days (in a leap year). So, every target date within a specific year can possibly occur on a weekend or holiday, which can be rectified using the factory calendar.

Schedule master records are the basis for generating periodic schedule records.

The parameter record controls the creation of budget billing dates.

The portion oversees the generation of billing and budget billing dates. It groups contracts together for collective billing, which share identical billing and invoicing dates.

The meter reading unit governs the creation of meter reading dates. It groups installations together for joint reading that share the same reading dates. The meter reading unit holds organizational data such as the meter reading reason, meter reading category, entry interval, and street route.

One portion contains several meter reading units. The portions are structured according to scheduling and system requirements, for example the weekly parallel billing mass execution run. The meter reading units are structured according to scheduling and regional requirements, for example the weekly workload of a meter reader.

The meter reading unit is allocated directly to the installation and is a required entry field there. The portion is allocated indirectly to the contract via the meter reading unit of the installation that corresponds 1:1 to the contract.

The collection of periodic and billing-relevant meter reading results is the first step of the M2C process in SAP S/4HANA Utilities.The meter reading results are the source for the billing execution via one or more register rates.

The process is depicted from the point of view of residential customers with normal devices and yearly meter reading, but runs in the same way and slightly changed for residential customers with intelligent meters and industrial customers with interval meters.

Residential customers that utilize regular meters and display registers adopt normal meter readings and register-rates. Those with intelligent meters (AMI) use MDUS requests as an alternative to meter readings and use TOU-rates instead of register-rates. Industrial customers that employ interval Meters (EDM) opt for profile upload in place of meter readings and use RTP-rates instead of register-rates.

The meter reading part of the M2C process is described in detail in the following figure.

The figure shows the execution of a periodic meter reading process as soon as the scheduled date is reached.

The creation of meter reading orders, the output of these orders, as well as the execution of billing, are arranged as mass runs that can run in parallel. The meter reading unit is the selection criterion used in the creation of meter reading orders and the part constituted in billing, invoicing and printing jobs. Both the meter reading unit and the part are the selection criteria used in monitoring meter reading orders, meter reading results, and billing orders.

The process of creating meter reading orders generates these orders for all registers associated with the chosen meter reading units. This creation process also generates billing orders for all contracts since periodic meter reading always has relevance for billing.

The meter reading order is a prerequisite for reading and contains all data required for a meter reading.

• The document ID uniquely identifies the meter reading order and later the meter reading result.
• The device, register and meter reading date are also available, but the unique document ID is faster and safer.
• The expected result, expected consumption as well as upper and lower limits support the validation during the meter reading data entry.
• The meter reading reason identifies the process that requires a meter reading result and it has already been described in a previous figure.
• The meter reading type describes the origin of the meter reading such as Utility Company, Customer, Market Communication or Estimation.
• The meter reading status is described together with the billing order status in the next figure.

The billing order is a prerequisite for billing and contains all data required for billing.

• The contract, meter reading unit and billing date are available.
• The billing order status is described together with the meter reading status in the next figure.
• The billing transaction is derived from the meter reading reason and therefore has the same code (01 Periodic, 02 Interim, 03 Move-Out).

The meter reading order output can be a print, a download or a request to an intelligent metering data unification system (MDUS).

The meter reading data entry normally uses the same medium like the meter reading order output:

• If the orders were printed, then someone must manually enter the meter reading result.
• If the orders were downloaded to a mobile device, then an upload program with function module BAPI_MTRREADDOC_UPLOAD is needed.
• If the company has the market role Supplier, then the results are uploaded in MSCONS format by market communication processes.

The meter reading data entry, no matter if manually or uploaded, executes configurable validation checks in the background. The validation and weighting procedures themselves are described later in this lesson.

The meter reading correction supports the change, release or estimation of meter reading result or work order generation for control reading. The meter reading correction can be done either during meter reading entry or afterwards by the following transactions:

• correction of implausible meter reading results
• correction of plausible meter reading results, for example embedded in an invoicing correction process

Monitoring can be conducted either manually or automatically, aided by machine learning as outlined in unit 05. This monitoring assists the meter reading manager in detecting missing and implausible meter reading results. As a result, it provides you with the ability to delay billing execution. For instance, if a portion still contains an excessive amount of non-billable billing orders.

The meter reading order, billing order and meter reading result can be reversed.

The figure shows the update of the meter reading document status and the billing order status by executing the steps of the M2C process.

Creation of the meter reading document is done at the register level. Both the billing order and the billing document are created at the contract level. Meanwhile, the invoicing document is created at the contract account level.

The creation of a meter reading order for periodic meter reading results in a meter reading document with status 0, indicating an Order Created. Since it is relevant for billing, the creation of a meter reading order for periodic meter reading also results in a billing order with status 1, indicating Not Billable.

The input of plausible meter reading results changes the status of the meter reading document from 0 (Order Created) to 1 (Plausible). Similarly, it updates the status of the billing order from 1 (Not Billable) to 2 (Billable).

The input of implausible meter reading results changes the meter reading document's status from 0 (Order Created) to 2 (Implausible). However, the entry of implausible meter reading results doesn't affect the status of the billing order, which remains at 1 (Not Billable).

When implausible meter reading results are corrected, the status of the meter reading document is updated from 2 (Implausible) to either 1 (Plausible) or 4 (Released), depending on what the utilities metering specialist decides or the suggestion provided by Machine Learning. The correction of implausible meter readings also changes the billing order status from 1 (Not Billable) to 2 (Billable).

The billing execution updates the status of the meter reading document dynamically (which means it doesn't record the change in the database) from 1 (Plausible) or 4 (Released) to 7 (Billed). The billing execution removes the billing order and replaces it with a billing document, which can be regarded as an invoicing order. A meter reading result that has been billed, or a meter reading result that has a billing document instead of a billing order, can no longer be modified.

The execution of invoicing doesn't impact the status of the meter reading document, which remains at 7 (Billed). Invoicing does not affect meter reading. The invoicing execution process results in an invoicing document, which is connected to the billing document.

The full-reversal, this means the reversal of the invoicing- and billing document in 1 action (but 2 separate steps), has the following effects:

• A new reversal invoicing document is created.
• The old invoicing document is flagged as Reversed.
• The old billing document is flagged as Reversed as well, but no reversal billing document is created.
• The meter reading document has, because of the billing reversal, the status before billing again, that is 1 Plausible or 4 Released.

The consumption extrapolation is performed automatically during the following M2C core processes:

• during meter reading data entry to determine the expected meter reading result for the actual meter reading date
• during billing execution for budget billing amount determination on the next meter reading date
• during billing execution for consumption accrual/deferral on the price- or tax change date
• for unbilled revenue recognition for revenue determination at the end of the year

The consumption extrapolation runs through two phases.

• First, the reference value of the current extrapolation period is determined in comparison to the consumption and duration of the previous period. The minimum length of the base period is stored as a percentage of the current period in the register rate. If the minimum length is not reached, the period consumption maintained during device installation is used as a reference.
• The weighting portions of the current extrapolation period are then determined using the weighting procedure that is stored in the register operand of the register rate.

The register rate contains the following control parameters for extrapolation, weighting and independent plausibility check:

• validation group from the customizing of meter reading with the independent meter reading validations to be performed
• minimum length of the base period for extrapolation compared to the current period in percent
• register operand with billing unit of measurement
• register operand with weighting procedure

SAP provides the following preconfigured weighting procedures as well as all necessary settings to define the weighting portions:

• Linear weighting does not require weighting portions because each day is weighted equally.
• Degree Day weighting takes its weighting proportions as degree days from the weather office.
• Feed-In weighting obtains its weighting portions as energy feeding quantities from the grid operator.
• Load Profile weighting obtains its weighting portions from the synthetic load profile of the utility installation.

Independent plausibility checks refer to only one register and are allocated to the register rate.

Dependent plausibility checks refer to two registers and are allocated to a register relationship.

SAP provides the following preconfigured independent plausibility checks as well as all necessary settings to define the check parameter:

• Repeated Estimations and Customer Readings
• Tolerance Limits
• Register Overflow

SAP provides the following preconfigured dependent plausibility checks as well as all necessary settings to define the check parameter:

• Serial Switching
• Active / Reactive
• On-Peak / Off-Peak
• Control