IUT 230 billing and invoicing

556
THE BEST-RUN BUSINESSES RUN SAP © SAP AG 2008 IUT230 Billing and Invoicing ERP2005 SAP for Utilities ECC 6.0 Version 92 Material number 50096723

description

SAP ISU Billing and Invoicing

Transcript of IUT 230 billing and invoicing

Page 1: IUT 230 billing and invoicing

© SAP AG 2009

IUT230 Billing and InvoicingFS310 Collections/Disbursements

THE BEST-RUN BUSINESSES RUN SAP

© SAP AG 2008

IUT230Billing and Invoicing

ERP2005 SAP for Utilities ECC 6.0

Version 92

Material number 50096723

Page 2: IUT 230 billing and invoicing

© SAP AG 2009

Copyright 2009 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Copyright

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,

OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or

registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web

Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and

implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well

as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Page 3: IUT 230 billing and invoicing

© SAP AG 2006

Prerequisites

Basic knowledge of the Windows operating system environment

Basic SAP knowledge

Course IUT110: Introduction to the IS-U/CCS System

Course IUT210: Master Data and Basic Functions

Page 4: IUT 230 billing and invoicing

© SAP AG 2008

Target Group

Participants:A project team implementing business processes with SAP Utilities

Administrators optimizing processes in the SAP Utilities environment

Consultants preparing for SAP Utilities implementation

Duration: 5 days

Page 5: IUT 230 billing and invoicing

© SAP AG 2008

Course Objectives

This course will enable you to:

Describe the process that starts with billing and invoicing and finishes with bill printout

Obtain knowledge about all billing related master data and functions in SAP Utilities

Obtain knowledge about displaying billing rules and prices in SAP Utilities

Page 6: IUT 230 billing and invoicing

© SAP AG 2008

Objectives

After completing this course, you will be able to:

Describe the billing master data of SAP Utilities

Perform billing and invoicing

Create the most important billing master data in the system

Make Customizing settings for billing and invoicing master data

© SAP AG 2007

Page 7: IUT 230 billing and invoicing

© SAP AG 2008

Course Content IUT230

Unit 7 Invoicing

Unit 8 Clearing Control

Unit 9 Budget Billing Amounts

Unit 10 Bill Printout

Unit 11 Special Billing Features

Unit 1 Business Scenario

Unit 2 Billing in SAP Utilities Data Model

Unit 3 Billing Master Data

Unit 4 Discounts/Surcharges

Unit 5 Billing

Unit 6 Manual Billing

Preface

Appendices

Page 8: IUT 230 billing and invoicing
Page 9: IUT 230 billing and invoicing

© SAP AG IUT230 1-1

SAP AG 2006

Business Scenario

Introduction to the business scenario and the relevant components

Page 10: IUT 230 billing and invoicing

© SAP AG IUT230 1-2

SAP AG 2008

Business Scenario: Unit Objectives

In this unit, you will learn about:

The business process used to explain billing master data and billing and invoicing with SAP Utilities

The steps required for processing the business scenario

SAP AG 2007

The main part of this course deals with mapping new billing and invoicing principles in SAP Utilities based on changed conditions. These changes can be the introduction of new divisions, the expansion of a supply area, or a change to legal conditions for example.

This provides the basis for creating billing runs and bill documents based on new billing principles and/or rate models.

Page 11: IUT 230 billing and invoicing

© SAP AG IUT230 1-3

SAP AG 2006

Energy and Service Company

IDES Utilities Inc.

Telecommuni-cations

Telecommuni-cations

MultimediaMultimediaElectricityElectricity

GasGas

WaterWater Waste waterWaste water WasteWaste

District heatingDistrict heating

IDES Utilities Inc. is a municipal utility company that deals with the classical divisions of district heating, electricity, gas, water, and waste water. New business areas are also being developed to create additional divisions such as waste, telecommunications, and multimedia.

Page 12: IUT 230 billing and invoicing

© SAP AG IUT230 1-4

SAP AG 2008

Potential

supply areaPotential

supply area

Deregulated Utilities Industry

Originalsupply area

Originalsupply area

As well as creating new business areas in the deregulation process, the company is aiming to acquire new customers.

To achieve this goal, the company offers attractive rates to customers situated outside the current supply area.

Page 13: IUT 230 billing and invoicing

© SAP AG IUT230 1-5

SAP AG 2006

Rate Structure

In the deregulated market, new and

more attractive rate models are

required. Sales personnel must

map and test the rate models developed

by the marketing department in the

system.Rate calculation:

1 kWh elec. =Basic price =Rental price =

USD 0.12USD 50.00USD 25.00

----------- IDES Utilities Inc. -------------

The sales employees are constantly confronted with new challenges. On the one hand, they have to make customers attractive offers, and on the other hand they must stay within the company's cost frame.

Page 14: IUT 230 billing and invoicing

© SAP AG IUT230 1-6

SAP AG 2006

Contract (Residential Customer - Electricity)

Customer without measured demand for annual consumption of less than 10,000 kWh/yahr

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average price limitationEnergy prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental prices

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Flat-rate demand 100 USD/year

This is a typical contract for residential customers in the electricity division.

Page 15: IUT 230 billing and invoicing

© SAP AG IUT230 1-7

SAP AG 2006

Maintainbilling

master data

Use of ratesin the

master dataInvoicing Bill

printoutBilling

Budget Billing

Additional functions:Additional functions:Discounts/surchargesDiscounts/surchargesManual billingManual billingSales statisticsSales statisticsSpecial billing featuresSpecial billing features

Billing/Invoicing: Business Scenario

The following is involved in the billing and invoicing processes:

Modeling new rates by creating new billing master data

Using new rates in customer and installation master data

Billing simulation

Invoicing simulation

Releasing the rates to the user department, which then makes them available to the company's customers

Other billing functions are available, which are used in the billing and invoicing processes.

All these functions are required to complete the business scenario. The relevant part of the business scenario is discussed at the beginning of the respective unit.

Page 16: IUT 230 billing and invoicing

© SAP AG IUT230 1-8

SAP AG 2006

Business Scenario: Unit Summary

The business scenario contains all the work steps required for the initial creation of billing master data

The business scenario is the basis for the practical exercises that you will be doing during the course

SAP AG

Page 17: IUT 230 billing and invoicing

© SAP AG IUT230 2-1

SAP AG 2008

Billing in SAP Utilities Data Model

SAP AG 2007

This unit will prepare you to:

Explain the bill creation process - from meter reading to bill printout

Describe the integration of billing master data in the SAP Utilities data model

Structure the component hierarchy for billing and invoicing

Outline the billing functions and the billing master data

Page 18: IUT 230 billing and invoicing

© SAP AG IUT230 2-2

SAP AG 2008

Objectives

SAP AG 2007

At the conclusion of this unit, you will be able to:

Identify billing tasks in SAP Utilities

Identify the master data relevant to billing

Page 19: IUT 230 billing and invoicing

© SAP AG IUT230 2-3

SAP AG 2006

Budget Billing

Maintain billingmaster data

Use of ratesin the

master dataInvoicing Bill

printoutBilling

Additional functions:Additional functions:Discounts/surchargesDiscounts/surchargesManual billingManual billingSales statisticsSales statisticsSpecial billing featuresSpecial billing features

Billing/Invoicing: Business Scenario II

The scenario in this unit will give you an initial overview of the billing functions and billing master data.

Page 20: IUT 230 billing and invoicing

© SAP AG IUT230 2-4

SAP AG 2006

MRorder

Billingorder

InvoicingInvoicingMeter readingorder creationMeter readingorder creation

Meter readingdata entry

Meter readingdata entry

BillingBilling

Billingdocument

Implausible MR results

Plausible MR results

Billingorder

Print document

Billprintout

Billprintout

The Bill Creation Process

Correction ofMR results

Page 21: IUT 230 billing and invoicing

© SAP AG IUT230 2-5

SAP AG 2008

Electricity

Gas

Water/Waste water

District heating

Cable televisionMultimediaCharges,

duties

Divisions

Residential customers

Commercial & industrial customers

Co-generator

Business partner

Billing rules, variantsBilling rules, variants

ConsumptionDemandFlat rates

Discounts,surcharges

Generalduties

Prorations Franchisefees

Priceadjustment

. . . . . .

Waste

SAP Utilities: Billing I

SAP Utilities can bill commercial and industrial customers, residential customers, and co-generators in the same data structures with the same functions. Differentiation only occurs in the data. The customers are managed as business partners in the system.

You can bill the following divisions using SAP Utilities: electricity, gas, water, waste water, district heating and waste disposal. Flat-rate charges for other divisions such as cable television and multimedia can also be included. In addition, all types of charges and duties can be included.

Examples of charges and duties are:

Cable television

Local charges

Dog license fee

Page 22: IUT 230 billing and invoicing

© SAP AG IUT230 2-6

SAP AG 2006

Billing (Utility Services)

Based on a universal billing engine

Billing of residential and commercial & industrialcustomer contracts

Supports the billing procedures of the international utilities industry, for example: periodic billing, interim billing, period-end billing, floating backbilling, final billing, budget billing, average monthly billing

Can handle new billing procedures

Convergent billing and intercompany invoicing

Thermal gas billing, billing of co-generators and flat-rate installations

The following billing procedures are supported:

Periodic billing is consumption billing carried out on a regular basis.

Floating backbilling is a form of monthly periodic billing. If necessary, values from previous months in a billing year are recalculated and backbilled using a current value.

Period-end billing is carried out separately after a billing cycle. Periodic billings can, if necessary, be recalculated and backbilled.

Interim billing is not controlled by scheduling functions and can be carried out manually at any time (upon customer request, for example).

Final billing is triggered when a customer moves out.

In the budget billing plan, an average amount is determined either by simulation or manually. The customer pays this average amount for a period of 12 months. At the end of this period, a new simulation is run for the next period.

In Average Monthly Billing/Equalized Billing, the customer is charged an average amount based on billings over the next 12 months (or less in the case of new customers).

Page 23: IUT 230 billing and invoicing

© SAP AG IUT230 2-7

SAP AG 2006

Business Objects/Utility Services

DevicecategoryDevice

category

Connectionobject

Connectionobject

ConnectionConnectionDevicelocationDevice

location

PremisePremise

RegionalstructureRegionalstructure

PoDPoD

ContractaccountContractaccount

InstallationInstallation

DeviceDevice

RegisterRegister

Contract(supply)Contract(supply)

Businesspartner

Businesspartner

Installation structure

In billing the most important business objects are the installation (contains the rate category) and the device, in particular the installation structure (contains the rate type for each register). Additionally, some fields in the following business objects are used in billing: installation, device, installation structure, contract and contract account. These will be described later on during the course.

In invoicing the most important business object is the contract account.

Page 24: IUT 230 billing and invoicing

© SAP AG IUT230 2-8

SAP AG 2008

Link Between Contract Text and SAP Utilities

Customer without measured demand for annual consumption of less than 10,000 kWh/year

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental Price

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Service Flat Rate 100 USD/year

Rate cat.e.g. residential

The rate category classifies the installation for billing.

The following are some examples of rate categories:

Household rate

Commercial rate

Commercial rate with demand measurement

Industrial rate

Minimal consumption rate

Basic price rate 1

Basic price rate 2

Domestic water

Reserve water

Water for fire fighting

Page 25: IUT 230 billing and invoicing

© SAP AG IUT230 2-9

SAP AG 2008

Rate Type

Rate Type

Link Between Contract Text and SAP Utilities II

Customer without measured demand for annual consumption of less than 10,000 kWh/year

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental Price

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Service Flat Rate 100 USD/year

Rate cat.e.g. residential

The rate type classifies the register for billing. The following are some examples of rate types:

On-peak rate active energy

Off-peak rate active energy

On-peak rate reactive energy

On-peak rate active power

Gas consumption

Water consumption

The rate types are usually known at the beginning of the project and only need to be maintained once.

Page 26: IUT 230 billing and invoicing

© SAP AG IUT230 2-10

SAP AG 2008

Rate Type

Rate Type

Link Between Contract Text and SAP Utilities III

Customer without measured demand for annual consumption of less than 10,000 kWh/year

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental Price

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Service Flat Rate 100 USD/year

Rate cat.e.g. residential

Rate

Rate

In this example, two rates are determined (on-peak household rate and off-peak household rate) with both rate types (on-peak rate and off-peak rate) in connection with the rate category (household customers without measured demand).

In this case, the energy price for the single-rate meter is identical to that of the on-peak rate meter, so the same rate can be used for both single and on-peak rates; in other words, you can use just one rate type for both single and on-peak rate. If the prices were different, then an additional rate type (single rate) and an additional rate (single household rate) would be necessary.

The rate bills the consumption from the register. It is determined in a Customizing table using the combination of rate category and rate type.

Page 27: IUT 230 billing and invoicing

© SAP AG IUT230 2-11

SAP AG 2008

Link Between Contract Text and SAP Utilities IV

Rate Type

Rate Type

Customer without measured demand for annual consumption of less than 10,000 kWh/year

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental Price

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Service Flat Rate 100 USD/year

Rate

Variant programs

Rate cat.e.g. residential

Rate

Variant programs are contained in rates as rate steps. Variant programs are basic calculation steps (e.g. consumption x price, determination of the basic price, or determination of the rental price). In this case, the demand price (basic price flat rate) and the rental price are included in the on-peak rate as variant programs.

Page 28: IUT 230 billing and invoicing

© SAP AG IUT230 2-12

SAP AG 2008

Link Between Contract Text and SAP Utilities V

Rate Type

Rate Type

Customer without measured demand for annual consumption of less than 10,000 kWh/year

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental Price

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Service Flat Rate 100 USD/year

Rate

Variant programs

Rate cat.e.g. residential

Rate

Prices

Facts

The prices in the system must be entered as price keys. Each application requires that different price categories are entered (e.g. quantity-based price, time-based price).

Page 29: IUT 230 billing and invoicing

© SAP AG IUT230 2-13

SAP AG 2008

Link Between Contract Text and SAP Utilities VI

Rate Type

Rate Type

Customer without measured demand for annual consumption of less than 10,000 kWh/year

1. Consumption prices

a) Without off-peak regulation

b) With off-peak regulation- On-peak rate- Off-peak rate

2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate

4. Rental Price

- Single-rate meter- Double-rate meter

0.24 USD/kWh

0.24 USD/kWh0.11 USD/kWh

0.48 USD/kWh0.11 USD/kWh

50 USD/year70 USD/year

3. Service Flat Rate 100 USD/year

Rate

Variant programs

Rate cat.e.g. residential

Rate

Prices

Facts

Schema

All rates that can be billed together in the same contract/installation (for example, on-peak rate for household customers, off-peak rate for household customers) must be brought together in one billing schema.

The schema contains the billing logic and the processing order of the rates and rate steps (variant programs). A schema can contain one or more rates.

Page 30: IUT 230 billing and invoicing

© SAP AG IUT230 2-14

SAP AG 2006

Generationof bill

line items

Validatonof billingresults

Executionof variantprograms

by schema

Quantityconversion

andproration

Data entryand

analysis

Universal Billing Engine

+

Ratedet.Ratedet.

Customer and inst.-related data

Rate data

Rate cat.

Prices andrate facts

Prices andrate facts

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Inst. structure/Rate category/

Inst. facts

Inst. structure/Rate category/

Inst. facts

Rate 1Rate 1

Rate nRate nRate cat.

The "billing engine" is at the core of billing.

The billing process follows a fixed procedure.

Data collection and analysis All data that is needed for billing is collected and prepared for analysis.

Proration If duties, prices, or taxes have changed during a billing period, the values relevant to billing (for example, consumption) must be prorated according to the date of the change.

Quantity conversion The quantities to be billed are determined from the meter reading results. Meter factors, PT/CT ratios, and conversions due to thermal gas billing are taken into account, for example.

Quantity valuation Quantity valuation is the actual contract billing: rates and their variant programs are processed on the basis of the billing schema.

Validation of billing results The billing results are validated after valuation.

Generation of billing line items

Page 31: IUT 230 billing and invoicing

© SAP AG IUT230 2-15

SAP AG 2008

Invoicing

SAP AG 2007

Invoicing in SAP Utilities

Invoicing Functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 32: IUT 230 billing and invoicing

© SAP AG IUT230 2-16

SAP AG 2008

Billing in SAP Utilities Data Model: Summary

SAP AG

Billing is the central component of SAP Utilities for calculating energy and water supplied to customers

The central billing engine enables you to model all possible combinations of billing steps

Dynamic rate determination allows for quick adjustment of entire customer groups to new rates

Invoicing is the standard SAP Utilities process that establishes the link to contract accounts receivable and payable and provides the basis for bill creation

Page 33: IUT 230 billing and invoicing

© SAP AG IUT230 3-1

SAP AG 2006

Billing Master Data

SAP AG 2006

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 34: IUT 230 billing and invoicing

© SAP AG IUT230 3-2

SAP AG 2008

Billing Master Data: Unit Objectives

SAP AG 2006

At the conclusion of this unit, you will be able to:

Identify billing master data in SAP Utilities

Describe the dependencies between the individual objects

Maintain the billing master data in the correct order

Page 35: IUT 230 billing and invoicing

© SAP AG IUT230 3-3

SAP AG 2006

Billing Modules: 1

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 36: IUT 230 billing and invoicing

© SAP AG IUT230 3-4

SAP AG 2006

Data Model for Billing – Billing Class

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecategory

Ratecategory

RatetypeRatetype

Prices Prices

SchemaFact groupFact groupFact groupFact groupFact groupFact group

RatetypeRatetype

Installationfacts

Installationfacts

Rate categoryfacts

Rate categoryfacts

Page 37: IUT 230 billing and invoicing

© SAP AG IUT230 3-5

SAP AG 2006

Billing Class: 1

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.

Page 38: IUT 230 billing and invoicing

© SAP AG IUT230 3-6

SAP AG 2006

InstallationInstallation

RateRate

PortionPortion

Billing class

(Classification,Validation)

Billing class

(Classification,Validation) MR unitMR unit

Ratecategory

Ratecategory

Rate typeRate type

Billing Class: 2

PricePrice

SchemaSchemaDiscountDiscount

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.

Page 39: IUT 230 billing and invoicing

© SAP AG IUT230 3-7

SAP AG 2006

Billing Modules: 2

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 40: IUT 230 billing and invoicing

© SAP AG IUT230 3-8

SAP AG 2006

Data Model for Billing: Rate Types

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecateogry

Ratecateogry

TarifartTarifart

Prices Prices

SchemaFact groupsFact groupsFact groupsFact groupsFact groupsFact groups

RatetypesRatetypes

Installationfacts

Installationfacts

Rate categoryfacts

Rate categoryfacts

Page 41: IUT 230 billing and invoicing

© SAP AG IUT230 3-9

SAP AG 2006

Used to classifyRegisters

Devices

Flat-rates

Reference values

for billing

Examples: On-peak and off-peak rates for active energy; On-peak rate for reactive energy; On-peak rate for active power; gas and water consumption; flat-rate installations

The rate type is used in conjunction with the rate category to determine the rate

Definition of Rate Type

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

Page 42: IUT 230 billing and invoicing

© SAP AG IUT230 3-10

SAP AG 2006

Rate Type: 1

Is valid for a particular division (obligatory) and billing class (optional)Use of the rate type can be permitted for:

RegistersMust be specified for registers relevant to billing

DevicesFor example: Rental price for devices that have no registers relevant to billing

FactsFor example: Flat-rates or installation flat-rates

Interval metersFor example: For billing real-time pricing rates

Period-end billingFor example: For determining a special fact group in the period-end billing

Waste billingFor example: For determining a special rate for waste management

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.

Page 43: IUT 230 billing and invoicing

© SAP AG IUT230 3-11

SAP AG 2008

Rate type

Rate category

Register

Device

Installation

Rate Type: 2

On-peak rate active energyOff-peak rate active energyOn-peak rate reactive energyOff-peak rate reactive energyGas consumptionWater consumptionInterval meter

Rental price(device-related)

Flat-rate installationsAdditional ratesFlat-rate

installationsReference valuesFacts for period-end billing

Rate types are generally maintained in the register. In some cases, it can be maintained at device level or in the installation facts. The rate type can also be entered in the rate category.

Page 44: IUT 230 billing and invoicing

© SAP AG IUT230 3-12

SAP AG 2006

Billing Modules: 3

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 45: IUT 230 billing and invoicing

© SAP AG IUT230 3-13

SAP AG 2006

Data Model for Billing - Prices

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecategory

Ratecategory

RatetypeRatetype

Preise Preise

SchemaFact groupFact groupFact groupFact groupFact groupFact group

PricesPrices

Installationfacts

Installationfacts

Rate categoryfacts

Rate categoryfacts

RatetypeRatetype

Page 46: IUT 230 billing and invoicing

© SAP AG IUT230 3-14

SAP AG 2006

Prices for Billing

Central price management

Price key

Header data- EUR- Dollar

History EUR01.01.2000 – 31.12.2005 10 €01.01.2006 – 31.12.9999 15 €

History USD01.01.2000 – 31.12.2005 19 $01.01.2006 – 31.12.9999 25 $

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.

Page 47: IUT 230 billing and invoicing

© SAP AG IUT230 3-15

SAP AG 2006

Price Categories

Quantity-based price for quantities and consumption values

Flat-ratefixed amounts per time unit (consumptionflat-rates and flat-rate amounts)

Rental pricefor the use of a measuring device over a certain period of time

Time-based pricefor demand and connection values

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

The price categories 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 category is a characteristic in the header data.

Page 48: IUT 230 billing and invoicing

© SAP AG IUT230 3-16

SAP AG 2006

Standard price:Price not based on quantity

Zone price:One or more quantity-based prices

Scale price:Quantity-based price

Price Types

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.

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.

The price type is a characteristic in the header data.

Block and scale limits are maintained in the historical data.

Page 49: IUT 230 billing and invoicing

© SAP AG IUT230 3-17

SAP AG 2006

Definition of Block Price and Scale Price

Z1 Z2 Z3 Z4 Z...

Block and scale prices

P1

P2

P3

P4

P5

Price type:- Block price- Scale price

Quantity limit- Inclusive up to block- Exclusive as of block

CustomizingCustomizing

Adjustment of quantity to billing periodin block price

0 500 700 1000

Zone definition

0 to 500500 to 700700 to 10001000 to 9999

Quantity

Price

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.

Page 50: IUT 230 billing and invoicing

© SAP AG IUT230 3-18

SAP AG 2006

Block price

P4

P3

P2

P1

Quantity to be billed 1200

Scale price

P4

P3

P2

P1

Quantity to be billed 1200

Price det. forscale price:

0 - 500 500 for P1500 - 700 200 for P2700 - 1000 300 for P31000 - 1200 200 for P4

Price det. forblock price:

Block and Scale Price

0 500 700 1000 0 500 700 1000

0 - 1200 1200 for P4

Quantity Quantity

PricePrice

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

Page 51: IUT 230 billing and invoicing

© SAP AG IUT230 3-19

SAP AG 2006

Adjusting Price Blocks for Billing Periods

Time basis: 365 daysPrice block adjustment activatedInterval lower limit: 350 daysInterval upper limit: 375 days

Quantity-based price

Price blocks0 - 3000

3000 - 50005000 - 10000

10000 - 9999999999

Price blocks0 - 3000

3000 - 50005000 - 10000

10000 - 9999999999

Adjustment of blocks to thebilling period, e.g. 340 days

Price blocks0 - 2795

2795 - 46584658 - 9315

9315 - 9999999999

Price blocks0 - 2795

2795 - 46584658 - 9315

9315 - 9999999999

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.

Page 52: IUT 230 billing and invoicing

© SAP AG IUT230 3-20

SAP AG 2006

Header Data for Price Key

Billing class

Division

Rounding parameters

Price adjustment clause

External price

Average price

Gross price

Block adjustment indicator

Overall, the price key is defined more precisely using the following three elements:

Price key

Price category

Price level

The price level is only used for rental prices.

Price adjustment clauses can be defined for all prices.

Defining authorization restricts the use of individual prices.

Rounding parameters are only needed in the following situations: price discount or using the price adjustment clause.

When using gross prices, you must create all the components of the gross price, such as ecological tax, franchise fee, and net price as separate prices. In the schema, you specify which prices are processed jointly in the Gross group field.

Several price contributions in different transaction currencies can be entered for one price key. The relevant transaction currency for billing is entered in the business partner's contract account.

You can historically define prices for a price key for each transaction currency.

Page 53: IUT 230 billing and invoicing

© SAP AG IUT230 3-21

SAP AG 2006

Price Adjustment Clause

Company Bill

Company Bill x y z

Basic price2.00

Priceadjustment

clause1.50

Addition

+Multiplication

*

Final price for the customer

Final price3.50

Final price3.00

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.

Page 54: IUT 230 billing and invoicing

© SAP AG IUT230 3-22

SAP AG 2006

Billing Modules: 4

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 55: IUT 230 billing and invoicing

© SAP AG IUT230 3-23

SAP AG 2006

Data Model for Billing - Operands

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecategory

Ratecategory

RatetypeRatetype

Prices Prices

SchemaFact groupFact groupFact groupFact groupFact groupFact groupInstallationfacts

Installationfacts

Rate categoryfacts

Rate categoryfacts

RatetypeRatetype

Page 56: IUT 230 billing and invoicing

© SAP AG IUT230 3-24

SAP AG 2006

Operand

Individually determined name or description for the allocated values that are used as input and output parameters in variant programs

Variable that is assigned values at runtime, for example Quantity (Q) x Price (P) = Amount (A)

An operand is allocated to one operand category. Operand categories are defined by SAP and cannot be changed by the customer.

Operands, however, are defined by the customer. It is important that you think about meaningful keys before creating operands.

An operand is always allocated to only one division.

Page 57: IUT 230 billing and invoicing

© SAP AG IUT230 3-25

SAP AG 2006

Operand category Description

AMOUNT AmountDEMAND DemandFACTOR Number with decimal placesQUANT QuantityQPRICE Quantity-based priceREFVALUE Reference valueSEASON SeasonTPRICE Time-based price

Operand Categories/Examples

USERDEF User-defined value

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.

Page 58: IUT 230 billing and invoicing

© SAP AG IUT230 3-26

SAP AG 2008

Operandcategories

Operands Operand values

• Predefined

• Control processing using variant programs

• Definedindividually

• Serve as theparameters forvariant programs

• Provide operandswith values

• Determine actualvalues

Rate Determination - Operands

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 (see above)

Facts from ERCHV

Values are read from DBERCHV

Register operand

Values are determined from meter reading results

Page 59: IUT 230 billing and invoicing

© SAP AG IUT230 3-27

SAP AG 2006

Parameters for Operands

Operand usage

Division

Operand group

Access control

History

Rounding

Weighting key

Demand control

Franchise fee control

Contract-related operand

BW relevance

ERCHV - Supply

The variants that are required within the rates will drive the types of operands that will be required to be created. Operands can be created within the rates by specifying the operand name in the field and by double-clicking on it. The system then automatically goes to the transaction for creating operands. Operands can also be created separately.

How the operand is used indicates whether it is a register operand (operand used to enter the consumption of the register in the rate), a normal operand (e.g. a price operand), or an operand used to represent a history (for example bill printout history or history of data transfer from legacy system).

Operands are generally for a specific division.

Rounding consists of two combined fields: rounding and rounding type. Rounding is controlled as follows: if you specify a positive value, numbers are rounded to that number of decimal places. If you specify a negative value, rounding is carried out to that number of pre-decimal places. The rounding type indicates the rounding principle (rounding up, down, or to the nearest whole number).

The demand control is used to define how many demand values of a register are to be taken into account during billing.

The franchise fee control specifies the type of calculation for the franchise fee.

You use this indicator to select the operands that are mainly used in the installation facts and that are to be extracted to SAP BW.

ERCHV - Supply with historical values (only for installation groups)

Page 60: IUT 230 billing and invoicing

© SAP AG IUT230 3-28

SAP AG 2006

Demandvalues

Contractual demand

Billeddemand

Ordered demand 25 kW

Minimum demand 10 kW

Maximum demand 32 kW

..........

..........

Operand groups

Oper

ands

Demand

Con tract dema nd

Order

Min imum dema n d

Billed d eman dDemand

Operand Groups

Reference values

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.

Page 61: IUT 230 billing and invoicing

© SAP AG IUT230 3-29

SAP AG 2006

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

ConsumptionGeneralweighting

Degree daysEnergy feedingLinear

Jan Feb . . . . Nov Dec

Weighting Procedures

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.

Page 62: IUT 230 billing and invoicing

© SAP AG IUT230 3-30

SAP AG 2006

Consumption Total

Degree days

LinearJan Feb . . . . Nov Dec

Linear Weighting

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.

Page 63: IUT 230 billing and invoicing

© SAP AG IUT230 3-31

SAP AG 2006

Access Control for Operands

All values are considered

Value at the end of the rate period

Value on the key date

Value at the end of the billing period

All values in the month-based billing period

Value at the start of the billing period

Value for date defined by customer

Facts

There are several ways to determine certain values from the facts (rate facts, rate category facts, and installation facts). You must note that these values are not from, for example, the meter reading results. Access control only accesses values that are stored in the facts.

You specify which access control you require in the operand.

Page 64: IUT 230 billing and invoicing

© SAP AG IUT230 3-32

SAP AG 2006

Demand01.03. 01.28.

01.29. 03.08.

03.09. 03.14.

03.15. Last day of month

10 kW

11 kW12 kW

13 kWRate1

Rate2

01.03. 02.05.

02.06. 03.30.

01.03. 03.30.Billingperiod

All values are considered:All values are considered:

Demand01.29. 02.05.

03.09. 03.14.

03.15.

10 kW

11 kW

12 kW 03.30.

01.03. 01.28.

13 kW

02.06. 03.08.11 kW

Access Control: Example 1

Facts

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

Page 65: IUT 230 billing and invoicing

© SAP AG IUT230 3-33

SAP AG 2006

The value at the end of the billing period is validThe value at the end of the billing period is valid

Demand 13 kW03.30.

01.03.

13 kW

02.05.

02.06.

Access Control: Example 2

Demand01.03. 01.28.

01.29. 03.08.

03.09. 03.14.

03.15.

10 kW

11 kW12 kW

13 kWRate1

Rate2

01.03. 02.05.

02.06. 03.30.

01.03. 03.30.Billingperiod

FactsLast day of month

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.

Page 66: IUT 230 billing and invoicing

© SAP AG IUT230 3-34

SAP AG 2008

Allocation of Operand Values: 1

Rate category factsRate category facts

Rate facts and rate fact groupRate facts and rate fact group

Have precedence over

Have precedence overH i

e r a

r c

h y

Installation factsInstallation facts

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).

Page 67: IUT 230 billing and invoicing

© SAP AG IUT230 3-35

SAP AG 2006

Contract-Related Operand – Not Activated

Contract2

Contract2

Customer2

Customer2

Customer1

Customer1

Contract1

Contract1

Move-out

InstallationInstallation

08.01.2001

Interval 1:04.15.97- 07.31.01

Interval 2:08.01.01

Move-in

1st May 1st June 1st July 1st Sep. 1st Oct. 1st Nov.1st Aug.

Installation factsInstallation facts

Facts?Facts?

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.

Page 68: IUT 230 billing and invoicing

© SAP AG IUT230 3-36

SAP AG 2006

Contract-Related Operand - Move-In

Contract2

Contract2

Customer2

Customer2

Customer1

Customer1

Contract1

Contract1

Move-out

InstallationInstallation

08.01.2001

Interval 1:04.15.97- 07.31.01

Interval 2:08.01.01

Move-in

1st May 1st June 1st July 1st Sep 1st Oct 1st Nov1st Aug

Installation factsInstallation facts

Facts?Facts?

Installation factsInstallation facts

If you are carrying out a move-in without contract change, operand values from the period before the move-out are not copied. 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.

Page 69: IUT 230 billing and invoicing

© SAP AG IUT230 3-37

SAP AG 2006

Contract-Related Operand - Contract Change

Contract2

Contract2

Customer1

Customer1

Customer1

Customer1

Contract1

Contract1

Move-out

InstallationInstallation

08.01.2001

Interval 1:04.15.97- 07.31.01

Interval 2:08.01.01

Move-in

1st May 1st June 1st July 1st Sep 1st Oct 1st Nov1st Aug

Installation factsInstallation facts

Facts?Facts?

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.

Page 70: IUT 230 billing and invoicing

© SAP AG IUT230 3-38

SAP AG 2006

IS-U RateIS-U Rate

y1

Result Function Oper. cat.e1 Sum QUANTe2 Average DEMANDe3 Peak DEMAND

Rate: ON_OFF_PEAK

RegOperand

RTP-Interface ON_OFF_PEAK

001 ....

... ...

007 QUANTI01 ONPEA KCON ... Pr icing for ON-peak consumption

008 QUANTI01 OFFPEAKCON ... Pr icing for OFF-peak consumption

... ...

Transfer Result to RTP Operand

RTP interfaceRTP interface

EDM profileEDM profile

The discrete RTP operand values are the result of processing within the RTP interface. The RTP interface obtains its input data from Energy Data Management repository (EDM).

Page 71: IUT 230 billing and invoicing

© SAP AG IUT230 3-39

SAP AG 2006

Billing Modules: 5

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 72: IUT 230 billing and invoicing

© SAP AG IUT230 3-40

SAP AG 2006

QUANTITY FACTOR QUANTITYCalculates x% of a quantityQUANTITY FACTOR QUANTITYCalculates x% of a quantity

. . . . . .

. . . . . .

NUMBER OF DEMAND PEAKS DEMANDCalculates N peak averagesNUMBER OF DEMAND PEAKS DEMANDCalculates N peak averages

DEMAND PRICE BILL LINE ITEMS Valuates demand with a priceDEMAND PRICE BILL LINE ITEMS Valuates demand with a price

. . . . . .

QUANTITY QUANTITY QUANTITY Difference of two quantitiesQUANTITY QUANTITY QUANTITY Difference of two quantities

. . . . . .

. . . . . .

QUANTITY PRICE BILL LINE ITEMSValuates energy with a priceQUANTITY PRICE BILL LINE ITEMSValuates energy with a price

ACTIVE_KWH 0.5 ACTIVE_50%ACTIVE_KWH 0.5 ACTIVE_50%

REACT_kVar - ACTIVE_50% BILL_REACTREACT_kVar - ACTIVE_50% BILL_REACT

BILL_REACT 0.06 USD BILL LINEITEMS

BILL_REACT 0.06 USD BILL LINEITEMS

Variant PoolVariant Pool

Variant PoolVariant Pool

Contract Text:The reactive energy that exceeds 50% of the active energy is valuated using a separate price.

Contract Text:The reactive energy that exceeds 50% of the active energy is valuated using a separate price.

*

*

**

*

-

Flexible Structure of Billing Rules

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 (e.g. 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.

Page 73: IUT 230 billing and invoicing

© SAP AG IUT230 3-41

SAP AG 2006

Variant Programs 1

Are small, independent ABAP/4 programs

Perform elementary calculation steps

Are used in combination to model the billing rules in the rate

Variant programs are small, independent ABAP/4 programs (function modules).

Variants perform elementary calculation steps. Many variant programs calculate values relevant to billing and generate billing line items. Other variant programs convert values and, in turn, make the results available to subsequent variants.

Variant programs can be used in any combination. This allows you to model complex billing rules.

You can also create your own variant programs to represent special, non-standardized calculations.

Page 74: IUT 230 billing and invoicing

© SAP AG IUT230 3-42

SAP AG 2006

Variant Programs 2

ABAB/4Function modules

function isu_quanti01.

Include ievarbasic.Data: ...........

If wprei-preisart = ‘2’.loop at .........endendif.ndendfunction.

Inputoperands

Outputoperands

Billline Items

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.

Page 75: IUT 230 billing and invoicing

© SAP AG IUT230 3-43

SAP AG 2006

Characteristics of a Variant

Rate permissibility: Checks when rates are created

Block period: Controls whether block periods can be included? Selection options in schema

Bill line items relevant for posting: Controls whether fields for account determination subtransactions have to be maintained for the rate

Optional: Controls whether the user has the option of setting this indicator in the rate

Not for extrapolation: Prevents the variant from being executed during budget billing extrapolation

Type of quantity: Controls the statistics update

Operand categories of input and output operands

Document line item types

Customer variants must have the variant categories '00' (normal), '01' (IF variant) and possibly '10' (lighting variant).

Variant category '10' contains a check for the reference value type 'lighting unit'. Variant category '01' is important for correctly structuring the nestings during a schema workflow.

The indicator for posting-relevant bill line items means that a posting-relevant bill line item is written. However, this is purely for information. It does not control anything. The billing line item writing must be programmed in the variant. In addition to this, an indicator ensures that the fields for statistics control can be maintained in the schema.

The IF variants, for example, are variants that can never be set to optional. If these are not included in the schema due to missing operand values, the nesting logic will be incorrect during billing.

Preventing the execution of variants during budget billing extrapolation is normally used for variants that write in installation facts and variants for backbilling.

Page 76: IUT 230 billing and invoicing

© SAP AG IUT230 3-44

SAP AG 2006

Examples of Variant Programs

COMPUT01 Subtraction of two amounts

DEMAND01 Valuation of a demand with a price

DISCNT01 Quantity discount, percentage or absolute amount

IF01 Condition: If Quantity1 >,>=,= Quantity2

ELSE Start of a NOT operation for an IF variant

ENDIF End of an IF nesting

INFACT01 Writing of a demand in the installation facts

QUANTI01 Valuation of a quantity with a price

QUANTI05 Writing of info lines for the quantity

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)

Page 77: IUT 230 billing and invoicing

© SAP AG IUT230 3-45

SAP AG 2006

Doc. line item types rel. to postingDoc. line item types rel. to posting Information line itemsInformation line items

Examples of Document Line Item Types

000001 Energy price

000002 Demand price

000003 Flat rate

000004 Rental price

000005 Reference value

000006 Amount discount

IQUANT Quantities (meter readings)

IDEMAN Demand (meter readings)

IT001 Flat rate x factor

IT002 Addition of two operands

IT001 Quantity x (/) factor

IT004 Demand x (/) factor

IT005 Subtraction of amounts

IT006 Comparison of two quantities

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.

Page 78: IUT 230 billing and invoicing

© SAP AG IUT230 3-46

SAP AG 2006

Billing Modules: 6

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 79: IUT 230 billing and invoicing

© SAP AG IUT230 3-47

SAP AG 2008

Rate Characteristics

Permissibility of the rate

Value relevant to billing measured by a register (register operand)

Register-based data

RTP rate and RTP interface

Calculation formulae

Allocation of values to operands (rate facts)

Account determination

Handling of bill line items

Header Data:

Rate Step Data:

The rate contains many fields with a controlling function. They will be described in more detail later on.

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.

An RTP interface can only be assigned to rates for which interval meters are allowed (permissible).

Page 80: IUT 230 billing and invoicing

© SAP AG IUT230 3-48

SAP AG 2006

Rate

Rate steps

Variant program

Operand

Operandcategory

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

Page 81: IUT 230 billing and invoicing

© SAP AG IUT230 3-49

SAP AG 2006

Rate headerDivisionBilling classPermissibilityRegister-based dataNotes

Rate Attributes

Rate steps

Variant programsSubtransactionsOperands ---> Rate factsStatistical rateFranchise fee groupControl parameters

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.

Page 82: IUT 230 billing and invoicing

© SAP AG IUT230 3-50

SAP AG 2008

Invoicing Transactions

In the rate, you must enter a debit and credit billing subtransaction for every rate step that creates billing line items relevant for posting. When the rate step is executed during contract billing, the plus or minus sign of the net amount determines which of these two subtransactions is used.

0023

D-ST

QUANTI01

Variant

1

CNo

011001200013

BBCSBBDSC-ST

Transactions describe the business scenario that forms the basis for posting a document line item

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.

Note:

Budget billing subtransactions from the rate step are allocated to the budget billing extrapolation line items.

Budget billing subtransactions are only used for account determination. Receivables accounts are only found via the main transaction. Revenue and tax accounts via the debit transaction.

Budget billing amounts with different budget billing subtransactions are managed separately in the budget billing plan.

Budget billing subtransactions and billing subtransactions must be maintained separately.

Page 83: IUT 230 billing and invoicing

© SAP AG IUT230 3-51

SAP AG 2006

Transactions

• Account det.• Tax det.

• IS-U settings• Debit/credit• Interest key• Stat./non-stat.

• Allocation tointernaltransactions • Default setting

by SAP

Sub-trans.

FI-CA

Maintrans.

FI-CA

IS-Utrans.

IS-UAllo-

cation

IS-U

InternalSubtrans.

SAP

Internalmain trans.

SAP

Transactions describe the business scenariothat forms the basis for posting a document line item

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.

Page 84: IUT 230 billing and invoicing

© SAP AG IUT230 3-52

SAP AG 2006

Example Transactions in Invoicing

Invoicing uses the following internal posting transactions in the program:

Invoicing: Receivable from posting00200250

Invoicing: Credit from posting00100250

Manual receivable backbilling00200300

Manual credit backbilling00100300

Receivable final billing00200200

Credit final billing00100200

Receivable consumption billing00200100

Credit consumption billing00100100

DescriptionInternalsubtrans.

Internalmain trans.

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.

Page 85: IUT 230 billing and invoicing

© SAP AG IUT230 3-53

SAP AG 2006

Subtransactions in IS-U Billing / Invoicing

Maintransaction

Periodicbill

CreditEnergy price

CreditDemand price

.....

ReceivableDemand price

ReceivableEnergy price

..........

Freely definable / integrated in rates / acct determ. (main transaction and transaction)

Allocated to internal transactions / no account determination

ReceivablePeriodic billReceivablePeriodic bill

CreditPeriodic bill

CreditPeriodic bill

CreditProvisioning

price

ReceivableProvisioning

price

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).

Page 86: IUT 230 billing and invoicing

© SAP AG IUT230 3-54

SAP AG 2006

Subtransactions in the Statistical Budget Billing Procedure in IS-U

BB planDebit

BB pay-outTransf. posting

BB paymentTransf. posting

Budget billingpayment

Budget billingpay-out

..........

Allocation to internal transactions / No account determination

Can be freely defined (stat.) /included in rates /account determination (BB amount)

Maintransaction

BBstat. proc.

BB planCredit

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.

Page 87: IUT 230 billing and invoicing

© SAP AG IUT230 3-55

SAP AG 2008

Accountdetermination(Posting area

R000)

Balance sheetaccount: 140500

(Receivables forenergy supply)

Receivablesaccount

Account Determination: Receivables Account

For example, billing:

Main trans. 0010

Businesstransaction

Company code 0001Division 01Account det. ID 01

Contract /contract account

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

Page 88: IUT 230 billing and invoicing

© SAP AG IUT230 3-56

SAP AG 2008

For example, billing:

Main trans. 0010Subtrans. 0010

Businesstransaction

Contract /contract accountCompany code 0001Division 01Account det. ID 01

Accountdetermination

(Postingarea R001)

Transactiondetermination

P/L account: 800010

(Revenue fromenergy price:

Electricity)

Sales revenueaccount

Transaction

0010-0010

Account Determination: Sales Revenue Account

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.

Page 89: IUT 230 billing and invoicing

© SAP AG IUT230 3-57

SAP AG 2006

CO Account Assignment

Profit center PC001

Cost center

Order

PSP element

Result object 4711

NoYes

Contract:Company code: 0001Company code: 0001

Business area: U001Business area: U001

CO accountassignment: V01CO accountassignment: V01

Determination of CO accountassignment

Determination of CO accountassignment

Account assignmentdetermined?

Determination of CO accountassignment

Determination of CO accountassignment

Accountdetermination:

Company code: 0001Company code: 0001

Business area: U001Business area: U001

CO accountassignment: K01CO accountassignment: K01

Account assignments are derived from account specifications in the master record of the IS-U contract, account determination (posting area R001), or from the standard values of the cost element to be posted.

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.

Page 90: IUT 230 billing and invoicing

© SAP AG IUT230 3-58

SAP AG 2006

IMGIMG

...........

..........

..........

..........

Customizing forTime Period Control

Time Period Control

Time period procedureTo-the-day

Key date

Interval (+ enhanced interval procedure)

Alternative procedures are possible for the following special cases:

Move-in

Move-out

Values added/omitted sub-periodically

Consideration of leap years

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).

Page 91: IUT 230 billing and invoicing

© SAP AG IUT230 3-59

SAP AG 2006

Variant Control

COMPUT01COMPUT02COMPUT03COMPUT04COMPUT08QUANTI02QUANTI08QUANTI09QUANTI10QUANTI15

COMPUT01COMPUT02COMPUT03COMPUT04COMPUT08QUANTI02QUANTI08QUANTI09QUANTI10QUANTI15

• Operand update - Addition• Operand update - Overwrite• Operand update - Addition• Operand update - Overwrite

Variant control

QUANTI*DEMAND*QUANTI*DEMAND* • Write info lines on quantity• Write info lines on quantity

Variant control

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.

Page 92: IUT 230 billing and invoicing

© SAP AG IUT230 3-60

SAP AG 2006

Billing Modules: 7

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 93: IUT 230 billing and invoicing

© SAP AG IUT230 3-61

SAP AG 2006

Data Model for Billing – Fact Group

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecategory

Ratecategory

RatetypeRatetype

Prices Prices

SchemaInstallation

factsInstallation

facts Fact groupFact groupFact groupFact groupFact groupFact group

Rate categoryfacts

Rate categoryfacts

RatetypeRatetype

Page 94: IUT 230 billing and invoicing

© SAP AG IUT230 3-62

SAP AG 2006

Factgroup

A

Fact Group

Rate

Operand AValue 1

Operand AValue 2

Fact groups enabledifferent operand values to be used within onerate

Factgroup

B

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.

Page 95: IUT 230 billing and invoicing

© SAP AG IUT230 3-63

SAP AG 2008

Price C0.70

Price C0.70

Price B0.60

Price B0.60Rate category factsRate category factsRate category facts

Rate facts and rate fact groupRate facts and rate fact groupRate facts and rate fact group

Have precedence over

Have precedence over

Price A0.55

Price A0.55

H i

e r a

r c

h y

Allocation of Operand Values

Installation factsInstallation facts

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.

Page 96: IUT 230 billing and invoicing

© SAP AG IUT230 3-64

SAP AG 2006

Installation 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

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

Ratecategory

Ratecategory

Rate typeRate typeRateRate

Installationfacts

Installationfacts Rate factsRate facts

Rate categoryfacts

Rate categoryfacts

Page 97: IUT 230 billing and invoicing

© SAP AG IUT230 3-65

SAP AG 2006

Extension: EBIS0002Extension: EBIS0002

Rate TypeRate Type Rate Fact GroupRate Fact Group

EXIT_SAPLE20Q_001 Search help rate typeEXIT_SAPLE20Q_002 Search help rate fact groupEXIT_SAPLE20Q_003 ChecksEXIT_SAPLE20Q_004 Proposal logic

EXIT_SAPLE20Q_001 Search help rate typeEXIT_SAPLE20Q_002 Search help rate fact groupEXIT_SAPLE20Q_003 ChecksEXIT_SAPLE20Q_004 Proposal logic

Function Exits

SAP Extension (Rate Type + Rate Fact Group)

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.

Page 98: IUT 230 billing and invoicing

© SAP AG IUT230 3-66

SAP AG 2006

Billing Modules: 8

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 99: IUT 230 billing and invoicing

© SAP AG IUT230 3-67

SAP AG 2006

Data Model for Billing – Schema

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecategory

Ratecategory

RatetypeRatetype

Prices Prices

SchemaInstallation

factsInstallation

facts Fact groupsFact groupsFact groupsFact groupsFact groupsFact groups

Rate categoryfacts

Rate categoryfacts

RatetypeRatetype

Page 100: IUT 230 billing and invoicing

© SAP AG IUT230 3-68

SAP AG 2006

Billing Schema: 1

Is valid for a certain division

Is valid for a certain billing class

Contains one or more rates

Determines the sequence of the rate steps for billing

Rates and their variant programs and operands are included in a billing schema. The following are specified in a billing schema: the rates used for billing, the schema steps used, and the sequence of the schema steps.

More than one rate can be contained in a billing schema than is necessary for the billing of a certain installation. Therefore, it is possible that a billing schema can contain two rates (on-peak household rate and off-peak household rate). Only one single-rate meter is installed in the installation. In this case only the on-peak rate is billed. The off-peak rate is simply ignored in the schema.

Page 101: IUT 230 billing and invoicing

© SAP AG IUT230 3-69

SAP AG 2006

Billing Schema: 2

Controls how bill line items are dealt with statistically (quantity and/or amount)

Controls gross billing

Controls dynamic period control

Controls billing in advance

Is dependent on the rate category in the installation

Page 102: IUT 230 billing and invoicing

© SAP AG IUT230 3-70

SAP AG 2006

Schema Attributes

Schema Header

DivisionBilling classBilling blockEnd of period billing/backbillingNotes

Schema Steps

RatesControl indicatorPresort keyDeletion operandGross line itemsNotes at step level

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.

Page 103: IUT 230 billing and invoicing

© SAP AG IUT230 3-71

SAP AG 2008

Installation Disconnection in Billing

Technical reasons

Customer request

Vacant status(no move-in after move-out)

FI-CA disconnectiondunning level reached

2006

01.09. .... .... .... .... .... .... 01.14.

Calculate basic price for disconnection period?Control at schema step level

Calculate basic price for disconnection period?Control at schema step level

Billing period

Disconn. period

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.

Page 104: IUT 230 billing and invoicing

© SAP AG IUT230 3-72

SAP AG 2008

Schema E1Rate Var.pr. Stat. Group QuantityRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002

. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002

I_ABRMENGE

St. gr. '000001'

I_ABRMENGE

St. gr. '000001'COCO--PAPA

WWABRWWABRWWLEIWWLEI

CO-PA actual data(yes/no)

CO-PA actual data(yes/no)

Statistics Groups: Quantities

Billing documentBilling document

COCO--PAPA

WWABRWWABRWWLEIWWLEI

CO-PA statisticaldata

CO-PA statisticaldata

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.

Page 105: IUT 230 billing and invoicing

© SAP AG IUT230 3-73

SAP AG 2008

Schema E1Rate Var.pr. Stat. Group: AmountRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002

. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002

NETTOBTR

Stat. group ‘000001’

NETTOBTR

Stat. group ‘000001’

VVNETVVNETVVARBVVARBVVLEIVVLEI

CO-PA Actual Data(Always Transfer)

CO-PA Actual Data(Always Transfer)

Statistics Groups: Amounts

Billing DocumentBilling Document

COCO--PAPA

COCO--PAPA

VVNETVVNETVVARBVVARBVVLEIVVLEI

CO-PA StatisticalData

CO-PA StatisticalData

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 the BW. 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 the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.

Page 106: IUT 230 billing and invoicing

© SAP AG IUT230 3-74

SAP AG 2006

Sorting for Bill Printout

Presort keys are for sorting billing line items before printout

Billing line items with the same presort keys form a group

Billing groups are sorted in ascending order according to the presort key

Function modules are used for sorting within billing groups

Presort keys must be allocated to all document lines in the schema

The presort keys are allocated in the schema of every billing or information line item and specifies how individual billing line items are sorted for bill printout.

You have to take all schemas into consideration. If, for example, an electricity and gas bill is to be created, the presort keys in the electricity and gas schemas should be checked against each other.

We will look at the function of the presort key in more detail in the chapter on bill printout.

Page 107: IUT 230 billing and invoicing

© SAP AG IUT230 3-75

SAP AG 2006

Contract Billing Modules: 9

Billing class

Rate type

Price

Operand

Variant program

Rate

Fact group

Schema

Rate category

Page 108: IUT 230 billing and invoicing

© SAP AG IUT230 3-76

SAP AG 2006

Data Model for Billing – Rate Category

Ratedetermination

Ratedetermination

Customer andinstallation data

Process data

Schema IRate Var.pr. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5

. . .

. . .

. . .

Rate n- Step 1 VarProg. A xxx

EXECUTION

ContractContract

InstallationInstallation

Installationstructure

Installationstructure

Billing class

Ratecategory

Ratecategory

RatetypeRatetype

PricesPrices

SchemaInstallation

factsInstallation

facts Fact groupFact groupFact groupFact groupFact groupFact group

Rate categoryfacts

Rate categoryfacts

RatetypeRatetype

Page 109: IUT 230 billing and invoicing

© SAP AG IUT230 3-77

SAP AG 2006

Rate Category I

Valid for one division only

Belongs to a single billing class

Contains one valid billing schema

Controls billing - used to determine the rate in conjunction with the rate type

Determines which outsorting checks occur during billing

Controls accompanying backbilling and period-end billing for nonresidential customers

Controls advance billing and dynamic period control

The rate category classifies the installation for billing. The rate category is used in conjunction with the rate types to determine the rate.

Rate determination: rate type + rate category = rate

Page 110: IUT 230 billing and invoicing

© SAP AG IUT230 3-78

SAP AG 2006

Rate CategoryBilling Class

OutsortingGroup

Division

Notes BackbillingPeriod-End Billing

DynamicPeriod Control

Billing Scheme

Billing in Advance

Rate Category II

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).

Page 111: IUT 230 billing and invoicing

© SAP AG IUT230 3-79

SAP AG 2006

STATISTICS GROUPSSTATISTICS GROUPS

Statistics groups forStatistics groups for ContractsContractsRatecategories

Ratecategories

Standardcustomers

C&Icustomers

Division Contract Rate cat. Update group01 ’ ‘’ ‘ 0101 SISU

01 0101 0101 Z00001

Residentialcustomers

Individualstatistics

Stats. group ‘ ‘ Stats. group 01Stats. group 02 Stats. group 01

Determination of Update Group

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.

Page 112: IUT 230 billing and invoicing

© SAP AG IUT230 3-80

SAP AG 2006

Statistics GroupStatistics Group

Update GroupSISU

Update GroupUpdate GroupSISU SISU

CustomerSchultz

CustomerCustomerSchultzSchultz

Update GroupZIND

Update GroupUpdate GroupZINDZIND

CustomerSAP

CustomerCustomerSAPSAP

UpdateUpdateRulesRules UpdateUpdate

RulesRules

1.1.

2.2. 3.3.

BW

Customer = “Dummy”

Customer = “Dummy”

Customer = “SAP”

Customer = “SAP”

If update group = SISUthenname = “Dummy”

Why Update Groups?

Billing Document

Division 01

Statistics Group ‘ ‘Contract

Statistics Group 01Rate Category

Update GroupSISU

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

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

Page 113: IUT 230 billing and invoicing

© SAP AG IUT230 3-81

SAP AG 2006

Ratecategory

Ratecategory

RatetypeRatetype

Historical

Dynamic Rate Determination

TarifTarifTarifTarif

TarifTarifTarifTarif

RateRate

Several rates can be determined,for example, for best-rate billing

Several rates can be determined,for example, for best-rate billing

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).

Page 114: IUT 230 billing and invoicing

© SAP AG IUT230 3-82

SAP AG 2006

Rate type (e.g. on-peak rate)

Rate type (e.g. ripple control receiver)

Rate type (e.g. flat-rate installation)

Installation structureRegister

Device

Billing-relevantobjects

Billingmaster data

Use of Rates

Rate categoryfacts

Installationfacts Rate type (e.g. flat-rate installation)

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).

Page 115: IUT 230 billing and invoicing

© SAP AG IUT230 3-83

SAP AG 2006

Initial Creation of a Rate Structure

Rate typeRate type

Prices (create from rate)Prices (create from rate)

Link tofact group

DetermineVariantprogramsVariantprograms

Determine Sequenceof ratesSequenceof rates

Select BillingschemaBillingschema

AllocateRatesRates

Rate categoryRate category

RatesRates

Billing schemaBilling schema

Operands (create from rate)Operands (create from rate)

Rate determinationRate determination

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.

Page 116: IUT 230 billing and invoicing

© SAP AG IUT230 3-84

SAP AG 2006

Determines whether the master data can be billed by checking the completeness of:

The rate determination data

The operand values

The overall check is carried outDuring billing

During move-in

Upon special request

During data migration

Overall Check

The overall check ensures that all data relevant to the billing process is complete and correct.

Page 117: IUT 230 billing and invoicing

© SAP AG IUT230 3-85

SAP AG 2006

Automatic Billing and Simulation: Initial ScreenDisplay Document Billing Reversal Invoice Simulation Display Print Document

Status

Log

Log

Big-Check

Billing Types

SimulationBilling SimulationBilling

-31.12.9999

Portion

Selection CriteriaContractInstallationContract Account

Billing Order Selection

Billing TransactionDivisionCompany Code

End of RuntimeCheck Runtime

DateTime

31.12.999913:31:10

Overall Check

XYZ0815

U100

Execution of different billing types

For different selection criteria

Automatic Billing/Simulation Edit Goto Settings Utilities System Help

- Rate determination- Billing view of installation- Operand determination- Simulation of period-end billing/backbilling

- Rate determination- Billing view of installation- Operand determination- Simulation of period-end billing/backbilling

Billing Analysis

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

To do so, you can also activate the debugging function and specify an existing variant program as a break point. During the billing run, processing stops at this point. You can then display the internal field content.

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

Page 118: IUT 230 billing and invoicing

© SAP AG IUT230 3-86

SAP AG 2006

Contract 2 VAT Ind. A1 Amount 80 $

Contract 1 VAT Ind. A2Amount 20 $

Contract 2 VAT Ind. A1 Amount 30 $

Contract 1 VAT Ind. A2 Amount 20 $

Document Analysis

Print document

Posting document 0815

Contract 1

Billing document 4711Contract 1VAT Ind. A1 Amount 100 $

Document items for general

ledger

Contract 2Contract 2 VAT Ind. A1 Amount 50 $

Billing document 4712

Document items for subledgerContract 1 VAT Ind. A1Amount 100 $Business partner

Contract account

Contract 1

Installation 1

Contract 2

Installation 2

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)

Page 119: IUT 230 billing and invoicing

© SAP AG IUT230 3-87

SAP AG 2008

Billing Master Data: Summary

Billing is the central component of SAP Utilities for calculating energy and water supplied to customers.

The central billing engine enables you to model all possible combinations of different billing steps.

The consistency of all required data is checked to ensure correct billing.

Dynamic rate determination allows for quick adjustment of entire customer groups to new rates.

SAP AG

Page 120: IUT 230 billing and invoicing

© SAP AG IUT230 3-88

Page 121: IUT 230 billing and invoicing

© SAP AG IUT230 3-89

Exercises

Unit: Billing Master Data Topic: Rate Type

Find the rate type definition in the implementation guide.

As a member of the sales department in your company, you should understand the elements of billing master data and be able to use them to create test data.

1-1 Check the implementation guide (SAP Reference IMG) for information regarding rate types, and answer the following questions.

True or false:

1-1-1 A rate type is allocated to just one division. _________________________________________________________

1-1-2 A rate type can be allocated to a billing class. The billing class is optional. _________________________________________________________

1-1-3 The rate type classifies a register for billing. _________________________________________________________

1-2 Check the definition of the rate type in the implementation guide.

1-2-1 Which menu path would you use to define a rate type? _________________________________________________________

1-2-2 To which division is rate type 1001 allocated? _________________________________________________________

1-2-3 At what master data levels can you define the rate type? _________________________________________________________ _________________________________________________________ _________________________________________________________

1-2-4 In addition to the classification and identification of different objects (such as registers), the rate type has an additional function. What is the most important task the rate type carries out? _________________________________________________________ _________________________________________________________

Page 122: IUT 230 billing and invoicing

© SAP AG IUT230 3-90

1-2-5 You can limit the rate type permissibility. Name the different limitation options.

Permissibility Text

Can you allocate a rate type more than once to the permissibilities mentioned above? _________________________________________________________ _________________________________________________________

1-2-6 What control is stored behind the column CA? _________________________________________________________ _________________________________________________________

Page 123: IUT 230 billing and invoicing

© SAP AG IUT230 3-91

Exercises

Unit: Billing Master Data Topic: Price

Find the price definition in the implementation guide.

Define a new price key for an energy price.

Adjust an existing price key.

New price keys have to be specified in the system to define the new rate. An existing price is adjusted to accommodate a price adjustment on January 1st.

2-1 Check the price definition in the implementation guide.

2-1-1 Which menu path would you use to define a price? _________________________________________________________

2-1-2 Which elements must you maintain before you can define a rental price? _________________________________________________________ In which master data object can you store a default value for determining the clearing price? _________________________________________________________ Can a clearing price also be defined as a flat rate? _________________________________________________________

2-1-3 Name 4 different price categories.

Price category Text

Page 124: IUT 230 billing and invoicing

© SAP AG IUT230 3-92

2-1-4 Where can you store the prices and which master data objects can you use for this? _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________

2-2 Enter a new price using the following data. A price for billing kilowatt-hours in the electricity sector. Selection data Price PE1_1_1## Transaction currency USD Price category Quantity-dependent price Price type Standard price Header data Price text Energy price ## Billing class Residential customer Division Electricity Unit of measurement Kilowatt-hours

Historical data (tab page history) Valid from 01/01/1997 QTY base 1 Price amt 0,24

Do not fill in the valid to date, otherwise the price cannot be used in the future. Choose Save.

2-3 Maintain an existing price key by raising the price from January 1st of this year.

A price for billing kilowatt-hours in the electricity sector.

Selection data Price TE1_1_2## Price category Quantity-dependent price Select the currency USD and choose Currency Details.

Historical data (tab page history) Valid from 01.01. of this year Qty base 1 Price amt 0.28 Select save.

Page 125: IUT 230 billing and invoicing

© SAP AG IUT230 3-93

2-4 True or false.

2-4-1 The decision as to whether the price is quantity or time-based is made using the price type. _________________________________________________________

2-4-2 A time-based price depends not only on a quantity, but also on a time period. _________________________________________________________

2-4-3 A price adjustment clause can only be used to add changes to a base price. _________________________________________________________

2-4-4 A price can also be specially defined for a selected installation. _________________________________________________________

2-4-5 Prices that have their origin in CRM can also be maintained in IS-U. _________________________________________________________

Page 126: IUT 230 billing and invoicing

© SAP AG IUT230 3-94

Page 127: IUT 230 billing and invoicing

© SAP AG IUT230 3-95

Exercises

Unit: Billing Master Data Topic: Operand

Describe the relationship between the operand category and operand.

Display an operand.

Certain operands have to be used to define new electricity rates. Suitable operands must be determined for variant programs.

3-1 Various discounts are needed to map the new rate.

3-1-1 Using the operand list, determine which operand categories are available in the system for mapping discounts and surcharges. ____________________________________________________________

3-1-2 Which operands are maintained in the system for the operand category quantity discount? ____________________________________________________________

3-2 Consumption is billed with a variant program by using the operands EQUANT___1 and EQPRICE__1.

3-2-1 Which operand category does the operand EQPRICE__1 belong to? ____________________________________________________________

3-2-2 How is quantity operand EQUANT___1 rounded off? ____________________________________________________________

3-3 The operand use is specified when the operand is created.

3-3-1 What are the four different uses you can choose? ____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

Page 128: IUT 230 billing and invoicing

© SAP AG IUT230 3-96

Page 129: IUT 230 billing and invoicing

© SAP AG IUT230 3-97

Exercises

Unit: Billing Master Data Topic: Variant Programs

Describe the relationship between operands and variant programs.

Find a variant program necessary for a billing step.

The online documentation helps you to understand variant programs.

Certain variant programs must be used to define the new rates. You have to determine suitable variant programs to calculate accordingly.

4-1 The new rate contains the determination of an average price.

4-1-1 Determine all variant programs in the system that use the input operand from operand category QUANT and AMOUNT and that deliver the output operand with the operand category QPRICE. ___________________________________________________________

4-1-2 How is the average price determined? For information, read the documentation on the variant program. ___________________________________________________________

4-1-3 Which variant program do you generally use to allocate a price to a quantity? ___________________________________________________________

4-2 Read the online documentation.

4-2-1 Select program QUANTI04 from the variant list.

4-2-2 Call the documentation for the program and read the information on the variant program function.

4-2-3 What input and output operand categories does the variant program require?

Input operand category Output operand category

1 1

2 2

Page 130: IUT 230 billing and invoicing

© SAP AG IUT230 3-98

4-2-4 Does the variant also write bill line items relevant for posting?

___________________________________________________________ Which document line item types does the variant program create?

Document line type Description

4-2-5 What are settings can you make with the variant control? Explain the meaning of the different control features. ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________

4-2-6 What naming conventions are the variant programs subject to? ___________________________________________________________

Page 131: IUT 230 billing and invoicing

© SAP AG IUT230 3-99

Exercises

Unit: Billing Master Data Topic: Rate

Find the definition of a rate in the implementation documentation.

Find and describe the components of a rate.

Create a new rate.

Create and change the facts of a rate.

The new contract contains a rate for billing an energy price according to which 60% of the consumption is billed with one price and the other 40% with another price.

5-1 Check the definition of the rate in the implementation guide.

5-1-1 Which menu path would you use to define a rate? ____________________________________________________________

5-2 Display the definition of rate TE1_1## in the system.

5-2-1 What do you control by using the Min.port. (minimum portion) field? Which value is used to extrapolate consumption when meter reading results are missing? ____________________________________________________________

5-2-2 How many and which variant programs are used in the rate? Go to the rate steps display to find out. ____________________________________________________________

5-2-3 Which output operand is used to determine the amount? ____________________________________________________________ How is this output operand updated? ____________________________________________________________

Page 132: IUT 230 billing and invoicing

© SAP AG IUT230 3-100

5-3 Create a new rate using the following data.

5-3-1 A rate for billing electricity consumption.

Header data Rate PE1_1##

Data Division Electricity Text Rate ## Billing class Residential customer Permissibility Register license Min.Portion 60 % Val. class Check for residential customers Register operand EQUANT___1

Rate steps: 1. Write the info lines for the original consumption quantity. 2. Determine the 40% and 60% portions (you first store percentages 0.4 and 0.6 for the facts in the next exercise). 3. Valuate the 40% portion with an on-peak rate price. 4. Valuate the 60 % portion with an off-peak rate price.

Use the following processes: Debit energy price Credit energy price Extrapolation budget billing (debit) Extrapolation budget billing (credit)

Use the following operands: EQUANT___1 EQUANT___4 EQUANT___5 EQPRICE__1 EQPRICE__2 EAMOUNT__1 EAMOUNT__2 EFACTOR__1

Page 133: IUT 230 billing and invoicing

© SAP AG IUT230 3-101

Exercises

Unit: Billing Master Data Topic: Facts

Describe the definition of a fact group.

Maintain the facts of a rate.

Find the different operand values at all hierarchy levels.

The new rate is valid for two different contract forms. These differ only in the portion of consumption quantity. In addition, special terms are agreed for a special business partner. The standard breakdown is 40% on-peak rate and 60% off-peak rate. The special business partner has 50% on-peak rate and 50% off-peak rate.

6-1 Check the definition of the fact group in the implementation guide.

6-1-1 Which fact group is maintained in the system for residential customers? ____________________________________________________________

6-1-2 With which element of the rate structure is the fact group always linked? ____________________________________________________________

6-2 Determine the individual factor for business partner TF0415A0##. Use the CIC to answer the following questions (from the SAP menu, select: Utilities Industry Customer Service Front Office/Customer Interaction Center

Customer Interaction Center)

6-2-1 In which master data object is the factor entered? ____________________________________________________________

6-2-2 Which factor is used for the business partner? ____________________________________________________________

6-2-3 What rate step is influenced by this factor? ____________________________________________________________

6-3 Maintain the facts for the rate that you created earlier.

6-3-1 Maintain all operands as necessary in the rate using the following:

Factor 0.4 Price 1 E1_1_1 Price 2 E1_2_1 EQUANT___4 Determination at runtime EQUANT___5 Determination at runtime

Page 134: IUT 230 billing and invoicing

© SAP AG IUT230 3-102

6-3-2 What other replacement values can you name? ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________

Page 135: IUT 230 billing and invoicing

© SAP AG IUT230 3-103

Exercises

Unit: Billing Master Data Topic: Schema / Rate Category

The online documentation helps you to understand schemas.

Create a new schema and a new rate category.

Determine and display the rates of a schema.

After all the necessary rates have been defined, they are brought together to form an overall billing design. by creating a new billing schema. This billing schema is entered in a new rate category as a standard schema.

7-1 Read the online documentation.

7-1-1 Select the menu path Define schemas using the implementation guide.

7-1-2 Access the documentation from the menu.

7-1-3 Read the information regarding prerequisites.

7-2 Create a new billing schema using the following data.

7-2-1 An electricity billing schema

Header data Schema PE1## Text Billing schema ## Division Electricity Billing class Residential customers

Rate From the previous exercise PE1_1## Presort key 1 0002 Presort key 2 0002

7-2-2 Display the operand list for your schema. How many operand categories do you use? ________________________________________________________

Page 136: IUT 230 billing and invoicing

© SAP AG IUT230 3-104

7-2-3 Use your new schema to define a new rate category. Take the following information into account.

Rate category of the electricity division

Header data Rate category PE1## Division Electricity

Data Text Rate category ## Billing class Residential customer Outsorting group Residential customer Statistics group Residential customer Billing schema PE1## Backbilling No backbilling Period-end billing No period-end billing Facts Not required, values are taken from rates

Page 137: IUT 230 billing and invoicing

© SAP AG IUT230 3-105

Exercises

Unit: Billing Master Data Topic: Rate Determination

Create a new rate determination.

Determine the billing master data used in the master data.

Derive the billing scheme used from the individual billing master data.

All the new billing components are brought together with the rate determination mechanism to be used in the system. All billing-relevant data in the system is determined for an existing business partner, for whom the new contract components are to be tested.

8-1 True or false?

8-1-1 Different rate type and rate category combinations can result in the same rate. ____________________________________________________________

8-1-2 You can set the rate determination to change on a certain date. ____________________________________________________________

8-1-3 You can only specify the rate type at device level. ____________________________________________________________

8-2 Create a new rate determination for your rate (PE1_1##) using the combination of your rate category (PE1##) and the rate type 1001.

8-2-1 Use January 1st of this year as the valid date. ____________________________________________________________

Page 138: IUT 230 billing and invoicing

© SAP AG IUT230 3-106

8-2-2 A business partner (TF0502A0## ) already exists in the system with a rate. Determine all important billing master data for the business partner.

What rate category is entered? ____________________________________________________________

Which rate type is entered on the register of the built in meter? ____________________________________________________________

Which rate is determined with the rate determination for billing runtime? ____________________________________________________________

Which billing schema is linked to the rate category? ____________________________________________________________

8-2-3 Are special price keys which differ from the rate used for this business partner? ____________________________________________________________

8-3 Supply the application master data (TF0501A0##) with the billing master data that you have just created. Use the rate maintenance (EC30) to do this. Go to the SAP menu and select: Utilities Industry Customer Service Process Execution Rate Data Maintain Rate Data. Alternatively, you can call the rate maintenance screen from the CIC. To do this, identify the business partner in the CIC and select the installation in the navigation area. Use the secondary mouse button to open a context menu. Select rate maintenance.

8-3-1 Test your new rate using the billing analysis and use the data for business partner TF0501A0##.

____________________________________________________________

8-3-2 What alternatives are available for rate maintenance. ____________________________________________________________ ____________________________________________________________ What are the disadvantages of selecting these alternatives? ____________________________________________________________ ____________________________________________________________

Page 139: IUT 230 billing and invoicing

© SAP AG IUT230 3-107

Exercises

Unit: Billing Master Data Topic: Billing Master Data and Rate Determination

To completely create the billing master data, define a rate determination and to connect the billing rule with the IS-U master data.

Derive the billing scheme used from the individual billing master data.

To interpret the billing documents and check the billing master data

All the new billing components are brought together with the rate determination mechanism to be used in the system. All billing-relevant data in the system is determined for an existing business partner, for whom the new contract components are to be tested.

9-1 To clarify how all the billing master data interacts, you can do the following exercise: Create a completely new rate construct with all the required billing master data. Base your data on the contract text in Unit 3. Proceed in the same order as described in Unit 3. You do not have to create operands and prices. They exist already.

9-1-1 Create two new rates (on-peak rate and off-peak rate) using the following:

Header data Rate (on-peak rate) PE2_1## Rate (off-peak rate) PE2_2##

Data Division Electricity Text (on-peak rate) On-peak rate ## Text (off-peak rate) Off-peak rate ## Register operand (on-peak rate) EQUANT___1 Register operand (off-peak rate) EQUANT___2

Rate steps (on-peak rate): 1. Valuate the on-peak rate quantity with a quantity-based price (energy

price)

2. Calculate a fixed demand price (basic flat-rate price)

3. Valuate the on-peak rate quantity with a quantity-based price (maximum price).

4. Compare the amount operand from steps 1, 2, and 3. Set a maximum price limitation.

5. Calculate a rental price based on the size of the meter.

Page 140: IUT 230 billing and invoicing

© SAP AG IUT230 3-108

Rate steps (off-peak rate): 1. Valuate the off-peak rate quantity with a quantity-based price (energy

price)

9-1-2 Maintain the facts for both rates. Supply the operands with values. Use the existing price key.

9-1-3 Create a new billing schema using the following data. Apply the rates you created earlier.

Header data Schema PE2## Rates PE2_1## and PE2_2##

9-1-4 Enter a new rate category using the following:

Header data Rate category PE2## Schema PE2##

9-1-5 Create a rate determination for your new rates (PE2_1## and PE2_2##) and your new rate category (PE2##) and rate types 1001 / 1002. Use January 1st of this year as the valid date.

9-1-6 Test your rate using the data construct TF0503A0##. Check also that both billing rules are used correctly (depending on consumption). Choose a simulation from 01.01.yyyy to 31.12.yyyy (yyyy = current year).

Page 141: IUT 230 billing and invoicing

© SAP AG IUT230 3-109

Solutions

Unit: Billing Master Data Topic: Rate Type

1-1 Check the implementation guide (SAP Reference IMG) for information regarding rate types and answer the following questions. From the SAP menu, choose Tools

Customizing IMG Edit Project. Call up the SAP Reference IMG.

True or false:

1-1-1 A rate type is allocated to just one division.

True 1-1-2 A rate type can be allocated to a billing class. The billing class is optional.

True 1-1-3 The rate type classifies a register for billing.

True 1-2 Check the definition of the rate type in the implementation guide.

1-2-1 Which menu path would you use to define a rate type?

In the SAP Reference IMG, choose: SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Types.

1-2-2 To which division is rate type 1001 allocated?

Electricity 1-2-3 At what master data levels can you define the rate type?

1) Installation structure: At device or register level 2) Facts: In the installation facts rate category facts

1-2-4 In addition to the classification and identification of different objects (such as registers), the rate type has an additional function. What is the most important task the rate type carries out? In addition to the rate category, the rate type defines the billing rule (rate) that is found. This kind of indirect rate allocation using a rate type has advantages if, for example, you want to change a rate: You only have to enter a new rate category in the utility installations in question, and then expand the rate determination. You do not have to make extensive changes to the rate types of every individual register for the utility installations that are affected.

Page 142: IUT 230 billing and invoicing

© SAP AG IUT230 3-110

1-2-5 You can limit the rate type permissibility. Name the different limitation options.

Permissibility Text

R Registers

D devices

F Facts

PIM Interval meter

PE Period-end billing

WB Waste billing

In rate determination, you can only combine rate types and rates that have the same permissibility or use. Can you allocate a rate type more than once to the permissibilities mentioned above?

No You can only select one permissibility.

1-2-6 What control is stored behind the column CA? This is the indicator: Ignore contract allocation of register during extrapolation You can only use this indicator for rate types that are permitted for registers. It influences the analysis of contract allocation when registers are extrapolated. Example: A register is installed for billing in two utility installations. Both utility installations have a rate type where the indicator is not set. One installation has been allocated a contract and the other has not. Outcome: During extrapolation, the system calculates a consumption larger than zero for the register.

Page 143: IUT 230 billing and invoicing

© SAP AG IUT230 3-111

Solutions

Unit: Billing Master Data Topic: Price

2-1 Check the price definition in the implementation guide.

2-1-1 Which menu path would you use to define a price?

In the SAP Reference IMG, choose: SAP Utilities Contract Billing Billing Master Data Rate Structure Prices Define Prices.

2-1-2 Which elements must you maintain before you can define a rental price? Price classes and price levels

In which master data object can you store a default value for determining the clearing price? In the device category. From the SAP menu, select Utilities Industry Device Management Technology Device Category Display. Display device category TD-SRA-00. The price class is stored in the General Data group box. Can a rental price also be defined as a flat rate? Yes. In this case, however, you do not have dynamic rental price determination. Normally, this is executed automatically by the variant program SETTLE01.

2-1-3 Name 4 different price categories.

Price category Text

1 Quantity-based price

2 Flat Rate

3 Rental price

4 Time-based price

2-1-4 Where can you store the prices and which master data objects can you use for this? You can save prices in the facts. You maintain these facts at rate, rate category and/or installation level.

Page 144: IUT 230 billing and invoicing

© SAP AG IUT230 3-112

2-2 Enter a new price using the following data.

A price for billing kilowatt-hours in the electricity sector.

In the SAP Reference IMG, choose: SAP Utilities Contract Billing Billing Master Data Rate Structure Prices Define Prices Create Prices.

Maintain the field contents in the data screen as described in the exercise and save.

2-3 Maintain an existing price key by raising the price from January 1st of this year.

A price for billing kilowatt-hours in the electricity sector.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Prices Define Prices Change Prices.

In the initial screen, enter the price key TE1_1_2##.

Maintain the field contents in the data screen as described in the exercise and save.

2-4 True or false.

2-4-1 The decision as to whether the price is quantity or time-based is made using the price type.

False 2-4-2 A time-based price depends not only on a quantity, but also on a time

period.

True 2-4-3 A price adjustment clause can only be used to add changes to a base price.

False 2-4-4 A price can also be specially defined for a selected installation.

Correct Select the tab page Header Data 2. Enter the installation number for the price. If you try and allocate this price to another installation, the process is terminated and an error message is issued.

2-4-5 Prices that have their origin in CRM can also be maintained in IS-U. False These prices come from the CRM price calculation. Prices can only be changed there and copied to the IS-U system.

Page 145: IUT 230 billing and invoicing

© SAP AG IUT230 3-113

Solutions

Unit: Billing Master Data Topic: Operand

3-1 Various discounts are needed to map the new rate for the electricity division.

3-1-1 Using the operand list, determine which operand categories are available in the system for mapping discounts and surcharges.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands

Display Operand.

Choose the List of operands button.

Select the possible entries button for the Operand category field.

This contains the following operand categories ADISCABS ADISCPER DDISCNT PDISCNT QDISCNT

3-1-2 Which operands are maintained in the system for the operand category quantity discount?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands

Display Operand.

Choose the List of operands button.

Enter QDISCNT in the operand category field. Choose Execute.

This contains the following operands: EQDISCNT_1 GQDISCNT_1 WQDISCNT_1

Page 146: IUT 230 billing and invoicing

© SAP AG IUT230 3-114

3-2 Consumption is billed with a variant program by using the operands EQUANT___1 and EQPRICE__1.

3-2-1 Which operand category does the operand EQPRICE__1 belong to?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands

Display Operand.

In the initial screen, enter the operand EQPRICE__1.

Operand category: QPRICE 3-2-2 How is quantity operand EQUANT___1 rounded off?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands

Display Operands .

In the initial screen, enter the operand EQUANT__1.

Rounding: 0 to whole numbers Rounding type: X round up or down to nearest whole number

3-3 The operand use is specified when the operand is created.

3-3-1 What are the four different uses you can choose? The operand is supplied with values from the rate, rate category, and installation facts. The value can also be determined as a result of different calculation steps in the rate. Register: This use can only be selected for operands with the category QUANT and DEMAND. The indicator specifies how operands are used in the facts:: - In the rate header, only operands that have the indicator set can be used as register operands - In the rate steps, you can only use operands when the indicator is not set, or when the operand is identical to the register operand from the rate header. Total history These operands can only be processed by special variants. RTP operand: RTP-Operands are used in RTP rates to copy the results of the RTP interface assigned to the RTP rate.

Page 147: IUT 230 billing and invoicing

© SAP AG IUT230 3-115

Solutions

Unit: Billing Master Data Topic: Variant Programs

4-1 The new rate contains the determination of an average price.

4-1-1 Determine all variant programs in the system that use the input operand from operand category QUANT and AMOUNT and that deliver the output operand with the operand category QPRICE.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Analyze Variant Programs.

Enter the value QUANT in the first input operand category field, AMOUNT in the second input operand category field, and QPRICE in the first output operand category field.

Choose Execute.

You find, for example, the QUANTI06 variant program 4-1-2 How is the average price determined?

The ratio from the amount and the quantity is mapped. The result is updated in the output operand.

4-1-3 Which variant program do you generally use to allocate a price to a quantity?

The QUANTI01 variant. If the second input operand (category) QPRICE is the average price, then the QUANTI06 variant (output operand) must be used in an earlier rate step to determine this operand value.

4-2 Read the online documentation.

4-2-1 Select program QUANTI04 from the variant list.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Analyze Variant Programs.

Enter the value QUANTI04 in the Variant Program field. Choose Execute. You find the list with variant program QUANTI04. Select and display the variant program.

4-2-2 Call the documentation for the program and read the information on the variant program function.

Select Documentation.

Page 148: IUT 230 billing and invoicing

© SAP AG IUT230 3-116

4-2-3 What input and output operand categories does the variant program require?

Input operand category Output operand category

QUANT QUANT (quantity maintained based on the factor)

FACTOR QUANT (remaining quantity)

4-2-4 Does the variant also write bill line items relevant for posting?

No. In the General Data box, the field Line Item Rel. to Post. is not selected. Which document line item types does the variant program create?

Document line type Description

IQUANT Quantities (meter readings)

IT008 Breakdown of consumption values

4-2-5 What are settings can you make with the variant control? Explain the meaning of the different control features. Info lines written about quantity Info lines written on breakdown Values added during update Values overwritten during update You use the variant control to specify how much detail is in the information that you need, for example, for bill printout. If you do not include the information line item written about quantity, you cannot print the data and quantities on the bill (for example, date of old and new meter reading). The update has more meaning if you have used the output operands from the billing schema in a rate, before the variant is executed. Values in this operand are added or overwritten by the result of the calculation step.

4-2-6 What naming conventions are the variant programs subject to? All variant programs are ABAP/4 function modules, which you can process using the function builder. The naming convention is: ISU_variant program name (e.g. ISU_QUANTI04)

Page 149: IUT 230 billing and invoicing

© SAP AG IUT230 3-117

Solutions

Unit: Billing Master Data Topic: Rate

5-1 Check the definition of the rate in the implementation guide.

5-1-1 Which menu path would you use to define a rate?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Create Rates/Change Rates/Display Rates.

5-2 Display the definition of rate TE1_1## in the system.

5-2-1 What do you control by using the Min.port. (minimum portion) field? Which value is used for extrapolation when meter reading results are missing?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Display Rates.

In the initial screen, enter the rate TE1_1_2##.

Register-based data, Min.port.: 60 %

This field is used to determine periods in which meter reading results must be available for the system to be able to extrapolate. If there are no meter reading results, the system uses the period consumption.

5-2-2 How many and which variant programs are used in the rate? Go to the rate steps display to find out.

Select Rate Steps.

Number of variant programs : 4

Variant programs: QUANTI01 LUMSUM01 REFVAL01 SETTLE01

Page 150: IUT 230 billing and invoicing

© SAP AG IUT230 3-118

5-2-3 Which output operand is used to determine the amount?

Scroll right in the rate steps display.

Output operand 1: EAMOUNT__1

In this case, the output operand has no other function, as it is not used as an input operand for any subsequent variant programs. The output operand is automatically added during the update since an explicit variant control does not exist in any variants for updating.

5-3 Create a new rate using the following data.

5-3-1 A rate for billing electricity consumption.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Create Rates.

In the initial screen, enter the rate PE1_1##.

Maintain the field content as described in the exercise.

Select Rate Steps.

Maintain the field content in the Rate Steps as described in the exercise and save.

Variant programs: QUANTI05 QUANTI04 QUANTI01 ( twice )

Processes: Debit energy charge 0021 Credit energy charge 0011 Extrapolation budget billing 0120 Extrapolation budget billing 0110

Page 151: IUT 230 billing and invoicing

© SAP AG IUT230 3-119

Solutions

Unit: Billing Master Data Topic: Facts

6-1 Check the definition of the fact group in the implementation guide.

6-1-1 Which fact group is maintained in the system for residential customers?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rate Fact Groups.

Rate fact group: 0001 Residential customers

6-1-2 With which element of the rate structure is the fact group linked?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rate Fact Groups.

Highlight the menu entry. Select Documentation by clicking on the menu entry.

Linked element: Rate type

6-2 Determine the factor for the consumption breakdown for the business partner TF0415A0##

6-2-1 In which master data object is the factor entered?

From the SAP menu, choose: Utilities Industry Customer Service Front Office/Customer Interaction Center Customer Interaction Center

Enter the business partner's number TF0415A0## in the Business partner field group and press Enter. In the navigation area (Environment tab page), select the installation and call up the installation display (double-click the installation data object). Call up the facts display.

6-2-2 Which factor is used for the business partner?

Select the operand EFACTOR__1 Operand value: EFACTOR__1 0,5

6-2-3 What rate step is influenced by this factor? Return to the installation display. Select Billing View. The rate found for billing the installation is displayed on the rate tab page.. Click on the rate to go to the rate display screen. Select Rate Steps. The operand EFACTOR__1 is used in the variant LUMSUM01 as a second input operand, A flat-rate price is halved.

Page 152: IUT 230 billing and invoicing

© SAP AG IUT230 3-120

6-3 Maintain the facts for the rate that you created earlier.

6-3-1 Maintain all the necessary operands in your rate.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Change Rates.

Enter the rate number PE1_1## in the initial screen. Select Facts. Select operand EQPRICE__1. Select Create operand values. Maintain the contents in the data screen as described in the exercise and save.

6-3-2 What other replacement values can you name?

Normal operand value: If this indicator is set, a replacement value is not used for the operand. As a result, an operand value must be entered. Optional value: If you enter this replacement value for an operand, the operand is proposed for maintenance in all installations that are allocated the rate category/rate. A value must not be entered for this operand in the installation facts. Mandatory value: If you enter this replacement value for an operand, the operand is proposed for maintenance in all installations that are allocated the rate category/rate. A value must be entered for this operand in the installation facts. Runtime: This replacement value must be entered when the operand is updated in subsequent rate steps as the output operand of a rate step.

Page 153: IUT 230 billing and invoicing

© SAP AG IUT230 3-121

Solutions

Unit: Billing Master Data Topic: Schema / Rate Category

7-1 Read the online documentation.

7-1-1 Select the menu path Define schemas using the implementation guide.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas.

7-1-2 Access the documentation from the menu.

Choose Define schemas. 7-1-3 Read the information regarding prerequisites.

7-2 Create a new billing schema using the following data.

7-2-1 An electricity billing schema

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas Create Schemas.

Enter the name of the schema (PE1## ) in the Billing schema field. Maintain the contents as described in the exercise. Select the Set default values icon. Select Insert rate and select the rate PE1_1##. Save.

7-2-2 Display the operand list for your schema. How many operand categories do you use?

Select Goto Overview List of Operands.

Operand categories : 3

Operand categories : QUANT QPRICE FACTOR

Page 154: IUT 230 billing and invoicing

© SAP AG IUT230 3-122

7-2-3 Use your new schema to define a new rate category. Take the following information into account.

Rate category of the electricity division

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rate Categories Define Rate Categories Create Rate Categories.

In the initial screen, enter the key PE1## in the Rate cat. field, and 01 in the Division field.

Maintain the contents in the data screen as described in the exercise and save.

Page 155: IUT 230 billing and invoicing

© SAP AG IUT230 3-123

Solutions

Unit: Use of Rates in the Master Data Topic: Rate Determination

8-1 True or false?

8-1-1 Different rate type and rate category combinations can result in the same rate.

True 8-1-2 You can set the rate determination to change on a certain date.

True 8-1-3 You can only specify the rate type at device level.

False

8-2 Create a new rate determination for your rate (PE1_1##) from the combination of your rate category (PE1##) and the rate type 1001.

8-2-1 Use January 1st of this year as the valid date.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Determination.

Enter the rate type and category as described in the exercise and save.

8-2-2 A business partner (TF0502A0## ) already exists in the system with a rate. Determine all the business partner’s billing components used in the master data.

Which rate category is entered at installation level?

From the SAP menu, choose Utilities Industry � Technical Master Data Installation Display.

Enter the installation number TF0502A0## in the initial screen.

Rate category: E1

Page 156: IUT 230 billing and invoicing

© SAP AG IUT230 3-124

Which rate type is entered on the register of the built in meter?

Goto Device - rate data

Rate type: 1001

Which rate is determined with the rate determination for billing runtime?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Determination.

Select the rate determination list. Choose Execute.

Rate: E1_1

Which billing schema is linked to the rate category?

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rate Categories Define Rate Categories Display Rate Categories.

Enter the rate category E1 in the initial screen.

Billing schema: E1

8-2-3 Are special price keys which differ from the rate used for this business partner?

From the SAP menu, choose Utilities Industry Technical Master Data Installation Display.

Enter the installation number TF0502A0## in the initial screen.

Select the installation facts.

No facts are available. No special price is used.

8-3 Go to the SAP menu and select: Utilities Industry Customer Service Process Execution Rate Data Maintain Rate Data.

8-3-1 Test your new rate using the billing analysis and use the data for business partner TF0501A0##. Adjust the data (rate category in the installation) of business partner TF0501A0##. Note the key date (01.01.yyyy, yyyy is the current year) and select prorate. Change the rate category.

From the SAP menu, choose Utilities Industry Billing Billing Execution Billing Analysis to test your rate. Execute a simulation for your installation from 01.01.yyyy to the present day and analyze the billing document once billing has been successfully completed (green traffic light). The quantity breakdown must be calculated in connection with your factor.

Page 157: IUT 230 billing and invoicing

© SAP AG IUT230 3-125

8-3-2 What alternatives are available for rate maintenance. You can also change the rate category using the transaction for changing the installation. Go to the SAP Menu and choose Utilities Industry Technical Master Data Installation Change. You can change the rate data of the installation structure from the SAP menu by selecting Utilities Industry Device Management Installation Installation Structure Rate Data Change. The rate maintenance (transaction EC30) enables you to maintain the installation rate category and the rate data from the installation structure in a dialog step. When you select alternatives, you can either change just the rate category (change installation – ES31) or just the installation structure data (EG70).

Page 158: IUT 230 billing and invoicing

© SAP AG IUT230 3-126

Page 159: IUT 230 billing and invoicing

© SAP AG IUT230 3-127

Solutions

Unit: Billing Master Data Topic: Billing Master Data and Rate Determination

9-1 To clarify how all the billing master data interacts, you can do the following exercise: Create a completely new rate construct with all the required billing master data. Base your data on the contract text in Unit 3. Proceed in the same order as described in Unit 3. You do not have to create operands and prices. They exist already.

9-1-1 Create two new rates (on-peak rate and off-peak rate) using the following.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Mater Data Rate Structure Rates Define Rates Create Rates.

Enter the rate PE2_1## and PE2_2## in the initial screen (execute twice).

Maintain the field content as described in the exercise. Select Rate Steps. Maintain the field content in the Rate Steps as described in the exercise and save.

Variant programs: PE2_1## QUANTI01 (energy price) LUMSUM01 (fixed basic price) QUANTI01 (maximum price) UTILIT02 (maximum price limitation) SETTLE01 (rental price)

Variant programs: PE2_2## QUANTI01 (energy price) 9-1-2 Maintain the facts for both rates. Supply the operands with values. Use the

existing price key.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Mater Data Rate Structure Rates Define Rates Create/Change Rates.

You can also create and maintain facts directly from the rates transaction. Select Facts. Select Create Operand Values. Maintain the contents in the data screen as described in the exercise and save.

9-1-3 Create a new billing schema using the following data. Apply the rates you created earlier.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas � Create Schemas.

Enter the name of the schema (PE2## ) in the Billing schema field.

Page 160: IUT 230 billing and invoicing

© SAP AG IUT230 3-128

Maintain the contents as described in the exercise. Select Insert Rate (twice) and choose the rates PE2_1## and PE2_2##.

After inserting the two rates, you must maintain the deletion operands. You can let the system propose deletion operands by checking the Propose deletion operands field in the default values.

Save. 9-1-4 Enter a new rate category using the following:

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rate Categories Define Rate Categories Create Rate Categories.

In the initial screen, enter the key PE2## in the Rate cat. field, and 01 in the Division field.

Maintain the contents in the data screen as described in the exercise and save.

9-1-5 Create a rate determination for your new rates (PE2_1## and PE2_2##) and your new rate category (PE2##) and rate types 1001 / 1002. Use January 1st of this year as the valid date.

In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Determination.

Enter the rate type and rate category in the initial and data screens as described in the exercise and save.

9-1-6 Adjust the billing master data for business partner TF0503A0## using the rate maintenance transaction (EC30). Test it using billing analysis (EA00). Do not be confused if you find an installation with a single-rate meter. In this context, viewing the on-peak rate (with the highest price) is very important. If necessary, adjust the period consumption (EC30 or EL56) of your meter in order to trigger an alternative calculation. You can also use EL28 to enter a current meter reading.

Page 161: IUT 230 billing and invoicing

© SAP AG IUT230 4-1

SAP AG 2006SAP AG 2006

Discount and Surcharge Options

Master Data

Effects on the Rate Structure

Discounts/Surcharges

Page 162: IUT 230 billing and invoicing

© SAP AG IUT230 4-2

SAP AG 2006

Discounts/Surcharges: Unit Objectives

At the conclusion of this unit, you will be able to:

Describe the discount and surcharge options

Explain the general and specific master data for discounts

Explain the effect on the rate structure

SAP AG 2006

Page 163: IUT 230 billing and invoicing

© SAP AG IUT230 4-3

SAP AG 2008

Reference Basis:- Amount Discount- Price Discount- Quantity Discount- Demand Discount

Reference Basis:- Amount Discount- Price Discount- Quantity Discount- Demand Discount

Discount Type:- Fixed Value- Percentage

Discount Type:- Fixed Value- Percentage

Discounts/surchargesDiscounts/surcharges

Discount and Surcharge Options in SAP Utilities

% + - exp

10% Community Discount on Final Amount

500 kWh Quantity Discount

3% Price Discount

2% Transformation Loss (Surcharge)

A discount or surcharge can refer to the following objects: amounts, prices, quantities, or demands.

A discount or surcharge can be either absolute or a percentage.

A discount or surcharge has to have a suitable operand so that this can be taken care of in the facts with the values.

A suitable variant program must exist in the rate for all discounts and surcharges, apart from the register discount.

Page 164: IUT 230 billing and invoicing

© SAP AG IUT230 4-4

SAP AG 2006

General Data Individual Data

Discount/Surcharge

Rate Facts

Rate Category Facts

Installation Facts

Installation StructureRegister Discount

Master Data for Discounts and Surcharges

A discount/surcharge key can be stored in the master data objects above, depending upon the use of the discount/surcharge.

Page 165: IUT 230 billing and invoicing

© SAP AG IUT230 4-5

SAP AG 2008

Entry of New Variant Programs:

DISCNT01 - Qty discount

DISCNT02 - Demand Discount

DISCNT03 - Qty-Based Price

DISCNT04 - ...

DISCNT05 - ...

DISCNT06 - ...

DISCNT07 - Amount Disc. (Perc.)

DISCNT08 - Amount Disc. (Fix.)

Rate StepsRate Steps

DiscountRate FactsRate Facts

Effects on the Rate Structure

After the discount/surcharge key has been defined, the appropriate variant programs must be entered in the rate steps.

The operands are given discount/surcharge keys in the rate facts.

Variant programs do not have to be entered for register discounts. These are the only exception.

Quantity, price, and demant discount variants must be positioned before the evaluation variants.

Amount discount variants are always used after the evaluation variants.

Page 166: IUT 230 billing and invoicing

© SAP AG IUT230 4-6

SAP AG 2006

Discounts/Surcharges: Unit Summary

SAP AG

Discounts and surcharges can apply to prices, quantities, demands, and amounts.

Discounts/surcharges can be calculated as a fixed value or a percentage.

Discounts/surcharges can be allocated to rate facts, rate category facts, and installation facts. A register discount can also be entered in the installation structure.

The discount or surcharge variants must be included in the rate steps.

Page 167: IUT 230 billing and invoicing

© SAP AG IUT230 4-7

Exercises

Unit: Discounts/Surcharges Topic: Discounts

Maintain a new discount/surcharge in the system.

Assign a discount to a business partner.

Your company has agreed to grant a customer a percentage discount on the energy price. The discount is entered in the customer services department and assigned to the business partner.

1-1 The business partner TF1001A0## is granted a discount on the energy price.

1-1-1 Create a new discount key in the system using the following information.

Header data Discount PE1## Valid from 1. January of this year Transaction currency USD Reference basis Price discount Discount type Percentage

Data Text Discount ## Division Electricity Billing class Residential customer Discount category Discount Percentage 10

1-1-2 To process the discount key you just created, you must include a new rate. Use rate E1_1 as a template and create new rate PE3_1##. In the first step, a discount of 10% applies to the on-peak rate energy price (quantity-based price) with this discount key in this rate. You need to include a suitable variant program in the rate.

1-1-3 However, the discount is not to be valid for all customers with this rate. It is only used 365 days after the contract first began. Include other variant programs and operands in the rate.

1-1-4 Once you have created the rate, you must create a new schema PE3##, a new rate category PE3## and the rate determination.

1-1-5 In the next step, you want to test this discount. Therefore allocate the new rate category to business partner TF1001A0## with installation TF1001A0##. Use the rate maintenance (transaction EC30) to do this.

Page 168: IUT 230 billing and invoicing

© SAP AG IUT230 4-8

Page 169: IUT 230 billing and invoicing

© SAP AG IUT230 4-9

Solutions

Unit: Discounts/Surcharges Topic: Discounts

1-1 The business partner TF1001A0## is granted a discount on the energy price.

1-1-1 Create a new discount key in the system using the following information.

From the SAP menu, choose: Utilities Industry Billing Master Data Define Discounts/Surcharges Create Discounts/Surcharges.

Enter your data as specified in the exercise and save. 1-1-2 In order to process the discount key that you have just created, you must

include a new rate. Use the rate E1_1 as a template and create the new rate PE3_1##. A discount of 10% applies to the on-peak rate energy price (quantity-based price) with this discount key in this rate. You need to enter a suitable variant program in the rate.

From the SAP Reference IMG, choose:

SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Create Rates.

In the initial screen enter rate PE3_1##, and rate E1_1 as the template.

Maintain the field content as described in the exercise.

Select Rate Steps.

Maintain the field content in the Rate Steps as described in the exercise and save.

Variant program: DISCNT03

Note that variant programs that calculate discounts based on prices must always be listed before the price key, to which the discount applies in the rate. In comparison, discount variants that refer to amounts are always listed after the amounts to which the discount applies.

Page 170: IUT 230 billing and invoicing

© SAP AG IUT230 4-10

1-1-3 However, the discount is not to be valid for all customers with this rate. It is only used 365 days after the contract first began. Include other variant programs and operands in the rate.

In the first step, you determine the number of days since the contract began. Use variant program COMPUT20 to do this. Create separate operands for the variant program. You must now check the calculated days against the days (365 here) fixed in the contract text. Use variant IF03 to do this. If the condition has been fulfilled, use DISCNT03 to calculate the discount. If the condition has not been fulfilled, a normal evaluation takes place with the undiscounted quantity-based price. Here is the sequence of the necessary variant programs: COMPUT20 IF03 DISCNT03 ENDIF QUANTI01

... Include the required facts to complete your rate.

1-1-4 Once you have created the rate, you must create a new schema PE3##, a new rate category PE3## and the rate determination.

From the SAP Reference IMG, choose:

SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas Create Schemas.

Enter the name of the schema in the Billing schema field (PE3##), and enter the data as specified in the exercise.

1-1-5 In the next step, you want to test this discount. Therefore allocate the new rate category to business partner TF1001A0## with installation TF1001A0##.

From the SAP menu, choose: Utilities Industry Customer Service Process Execution Rate Data

Maintain Rate Data. Enter installation number TF1001A0## in the initial screen and change the rate category. Note the proration date. The new rate category can only be allocated in a period that is not prorated and the allocation date should come after the validity date of your rate and rate determination. Go to the billing analysis (EA00) and test your discount.

Page 171: IUT 230 billing and invoicing

© SAP AG IUT230 5-1

SAP AG 2008

Billing

SAP AG 2007

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Page 172: IUT 230 billing and invoicing

© SAP AG IUT230 5-2

SAP AG 2006

Billing: Unit Objectives

SAP AG 2006

At the conclusion of this unit, you will be able to:

Explain the data elements of the billing process

Describe billing functions

Understand the billing process

Perform a billing simulation

Understand the concept of outsorting

Perform billing reversal

Describe the concept of parallel processing

Page 173: IUT 230 billing and invoicing

© SAP AG IUT230 5-3

SAP AG 2006

MRorder

Billingorder

InvoicingInvoicingMeter readingorder creationMeter readingorder creation

Meter readingdata entry

Meter readingdata entry

BillingBilling

Billingdocument

Implausible MR results

Plausible MR results

Billingorder

Print document

Billprintout

Billprintout

The Bill Creation Process

Correction ofMR results

Page 174: IUT 230 billing and invoicing

© SAP AG IUT230 5-4

SAP AG 2006

Billing: 1

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Page 175: IUT 230 billing and invoicing

© SAP AG IUT230 5-5

SAP AG 2006

MO TU WE TH FR SA SU18

152128

29

162229

310172330

411182431

5121925

6132026

7142127

Length of period for periodic billingn days; 1, 2, 3, 4, 6, or 12 months

Length of period for period-end billingn + n days; 1, 2, 3, 4, 6, or 12 months

To-the-day billingBased on the date of the meter reading

Month-based billingDependent on key date

Month-based billingDependent on intervals

Billing Periods

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.

Page 176: IUT 230 billing and invoicing

© SAP AG IUT230 5-6

SAP AG 2008

Schedule Master Records: Portions

PortionsGroup contracts that are to be billed together

Contain schedule master records for billing

A utility contract is allocated to a portion in one of two ways:

Indirectly via the meter reading units defined in the installation that corresponds to the contract

Directly in the contract

The portion controls billing orders.

You can bill for an entire portion, for all contracts allocated to a portion. Allocation is usually carried out with the meter reading unit in the installation. In certain cases, the portion can be overridden in the contract.

Several portions can be entered for one billing district to enable parallel background processing on different systems/computers.

Page 177: IUT 230 billing and invoicing

© SAP AG IUT230 5-7

SAP AG 2006

Schedule Master Records: Meter Reading Units

Group utility installations that are in the same region and that should be read by a certain date

Contain all data (schedule master records) relevant to meter reading scheduling

Can only be created if a portion already exists

Several meter reading units can be allocated to the same portion

Are the basis for meter reading

Meter reading units can be seen as a day's work for a meter reader, but could also refer to a larger meter reading/work list.

Page 178: IUT 230 billing and invoicing

© SAP AG IUT230 5-8

SAP AG 2006

PortionP_AUG01Portion

P_AUG01

MR unitA_AUG01MR unit

A_AUG01

P1P1Parameter recordParameter record

Schedule masterrecords

A_AUG01 2007A_AUG01 2007

A_AUG01 2006A_AUG01 2006

A_AUG01 2005A_AUG01 2005

MR unitMR unit

Schedulerecords

P_AUG01 2007P_AUG01 2007

P_AUG01 2006P_AUG01 2006

P_AUG01 2005P_AUG01 2005PortionPortion

Generation of

schedulerecords

Generation of

schedulerecords

Generation of Schedule Records

Schedule records can be generated for portions and meter reading units separately, or they can be generated together for all meter reading units of a portion.

When you generate the schedule records, you must specify the time period for which the dates are required.

You can easily check the generated schedule records (meter reading and billing dates, due dates, etc.) by choosing Schedule record => Analysis. This function can be performed for several portions or meter reading units at the same time.

The description of the portions and meter reading units must match the selection options.

If the dates in the schedule master records are changed, the existing schedule records can be regenerated.

Page 179: IUT 230 billing and invoicing

© SAP AG IUT230 5-9

SAP AG 2006

Scheduling: Annual Billing

20062006Portion 127.7. 28.7. 29.7. 30.7. 31.7. 1.8. 2.8. 3.8.

Portion 127.7. 28.7. 29.7. 30.7. 31.7. 1.8. 2.8. 3.8.

20072007

Portion 127.7. 28.7. 29.7. 30.7. 31.7. 1.8. 2.8. 3.8.

Sched.MRDate

Billing period

Meter reading period for meter reading unit 1

Meter reading period for meter reading unit 2

Meter reading period for meter reading unit 3

For all meter reading units

End of MR Period

EndofBillingPeriod

Planned Billing Date

Meter ReadingBilling

Meter ReadingBilling

End of billing period: This is the date on which the portion is to be billed for the first time. This date, together with the length of the billing period (that is, the period length) determines the date of the next billing.

Scheduled billing date:

Date on which billing is to begin for the contracts that belong to a portion.

When the schedule record is generated, this date is calculated by subtracting the number of days between the end of the billing period and the scheduled billing date for the schedule master record from the end date of the billing period for the schedule record.

This takes the SAP calendar into account.

End of meter reading period: Used as the basic date for determining the schedules for the further meter reading periods. The date must not be after the end of the billing period for the item allocated.

Scheduled meter-reading date: Date on which the meter reading unit can be read for the first time (is maintained in the meter reading unit under schedule record interval: meter reading to meter reading period end)

Page 180: IUT 230 billing and invoicing

© SAP AG IUT230 5-10

SAP AG 2006

Data for the Meter Reading Order

MR Order

Time-Dependent Data

Data Environment

• Entry number• Check number• Meter reading reason• Scheduled meter reading• Meter reader• Meter reading status• Control group• MDE number

Meter Reading Data

Entry-Specific Data

• Expected meter reading• Expected consumption• Upper limit of meter reading

• Scheduled meter reading date• Scheduled billing date

The entry number is used in fast entry to identify a meter reading order.

The check number is specified for each register and checks if the meter reading results are complete.

Meter reading status such as:

order created

billable

automatically locked

released by agent

The control group controls the meter reading order creation for time variable registers. For example, a register that is read annually but the maximum demand of which is determined monthly. When this is the case, the system prints twelve columns for the demand values. You specify control groups in Customizing.

The MDE (Mobile Data Entry) number is the number of the PC onto which the meter reading data is downloaded. This controls how the order is issued.

The expected meter reading/consumption, which can be projected from the historical values, can be downloaded onto the MDE devices where the meter reading checks can be carried out.

Page 181: IUT 230 billing and invoicing

© SAP AG IUT230 5-11

SAP AG 2006

Billing Order

Is created in addition to the meter reading order if a meter reading is relevant to billing (periodic meter reading, for example)

Is a prerequisite for billing

Contains data for billing, for example:Scheduled billing date

Portion

Installation

The billing order is used as a billing index.

The billing order reduces the program runtime because only billing orders which are actually billable are processed.

Once the contract/installation has been successfully billed, the billing order is deleted.

Page 182: IUT 230 billing and invoicing

© SAP AG IUT230 5-12

SAP AG 2006

Billing Order

Effects on the billing orderEffects on the billing orderActionsActions

Meter reading order creation

Entry of meter-reading results

Billing

Billing reversal

Status 1 = Cannot be billed

Status 2 = Can be billed

Billing order is deleted

Billing order is restored

Billing Order Status

The activities described in the upper left have certain effects on the billing order. The billing order is actually an index for billing. It is used for tracking the status and improving performance.

Page 183: IUT 230 billing and invoicing

© SAP AG IUT230 5-13

SAP AG 2006

Which devices did weread last week on Schiller

Street?

Monitoring

Monitoring of:Schedule records

Meter reading orders

Billing orders

Meter reading results

Information on, for example:Meter reading

Status

Meter reading reason

Scheduled billing date, scheduled meter reading date

Monitoring enables the current meter readings and billings to be tracked. You can, for example, establish in which meter reading units the readings are not complete. Follow-up activities can be triggered, such as a mass estimation run.

Monitoring can also be used to analyze non-billable contracts.

Page 184: IUT 230 billing and invoicing

© SAP AG IUT230 5-14

SAP AG 2006

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Billing: 2

Page 185: IUT 230 billing and invoicing

© SAP AG IUT230 5-15

SAP AG 2006

Billing Tasks

Standard process that processes billing orders, creates billing documents for each contract, and transfers information to invoicing

Determination of billing periods

Determination of rate data

Quantity conversion

Proration

Execution of variant programs

Creation of billing documents with billing line items

The billing document forms the base for the communication structure (UIS - Sales Statistics)

Page 186: IUT 230 billing and invoicing

© SAP AG IUT230 5-16

SAP AG 2008

BillingBilling InvoicingInvoicing

Billing documents with billing line items

Communication structure for sales statistics

Posting documents for contract accounts receivable and payable

Print documents for bill printout

Budget billing plans

Differentiating Billing from Invoicing

In SAP Utilities, the billing process includes billing and invoicing.

In billing, a billing document is created for each contract.

The billing document also forms the basis for the communication structure. The communication structure is used for sales statistics.

In invoicing, the billing documents of a contract account are grouped together into an invoicing document. In addition, billing documents are transferred to the Contract Accounts Receivable and Payable component, and print documents are created for bill printout.

Page 187: IUT 230 billing and invoicing

© SAP AG IUT230 5-17

SAP AG 2008

Invoicing Tasks

Standard SAP Utilities process that establishes the link to contract accounts receivable and payable, and provides the basis for bill creation

Groups billing documents of contracts from a contract account into a joint bill (invoicing unit)

Posts documents in subledger accounting

Processes budget billing plans

Page 188: IUT 230 billing and invoicing

© SAP AG IUT230 5-18

SAP AG 2008

Billing Transactions

Periodic billingScheduled billing occurring in fixed periods

Interim billingUnscheduled billing at any time

Final billingWhen the customer moves out or when the contract is terminated

Period-end billingThirteenth billing, backbilling for a year

Manual billingPossibility of making manual corrections (e.g., corrections to bills)

Periodic billing is consumption billing carried out on a regular basis. Scheduling controls how often it takes place. Periodic billing may take place daily, annually or every 2, 3, 4, or 6 months. If necessary, a new budget billing plan is created.

Period-end billing is carried out separately after a billing cycle. The billing cycle is usually a year, but it can also be a period of 2, 3, 4 or 6 months. Periodic billings can, if necessary, be recalculated and backbilled.

Interim billing is not controlled by scheduling functions and can be carried out manually at any time (upon customer request, for example). The subsequent periodic billing starts at the time of the interim billing. In the case of floating backbilling and period-end billing, it is not possible to carry out interim billing.

Final billing is triggered when a customer moves out. Final billing is similar to periodic billing, with the exception that in final billing all open budget billing payments of the period are canceled and no new budget billing plan is created. If necessary, a period-end billing is triggered.

A clerk can trigger manual billing at any time. In most cases, manual billing is used to make corrections to invoices.

Move-in billing is a special form of billing and is used duing move-in processing

Page 189: IUT 230 billing and invoicing

© SAP AG IUT230 5-19

SAP AG 2006

10 kW

15 kW 15 kW

20 kW 20 kW 20 kW

25 kW 25 kW 25 kW 25 kW

Month 01

Month 02

Month 03

Month 04

- 10 kW

- 2 * 15 kW

- 3 * 20 kW

Floating Backbilling / n Periods

Data: T-F-0015Schema: E7

Backbilling gives you the opportunity to correct values in periods (adjustment periods) which have already been billed:

Reverse the calculation

For this, billing line items of billing documents from the adjustment periods are added to the current billing document.

Backbilling

For this, schema steps are executed in the adjustment periods. The resulting billing line items are added to the current billing document.

In the rate category, you specify

how may periodic periods are covered by backbilling

if floating backbilling or backbilling was executed for the past n periods

Periodic or final billing triggers backbilling.

Page 190: IUT 230 billing and invoicing

© SAP AG IUT230 5-20

SAP AG 2008

01 02 03 04 05 06 07 08 09 10 11 12 13

01 02 03 04 05 06 07 08 09 10 11 12

. . . . . . . . .

. . . . . . . . .

Separate Period-End Billing

Period-End Billing and Final Periodic Billing

Period-end billing

Data: T-F-0016Schema: E8

Period-end billing enables you to bill based on several periods (period-end billing periods) that have already been billed. You can backbill in the adjustment period of the period-end billing period.

In the rate category, you specify

how many periods are covered by period-end billing

whether integrated or separate period-end billing should be carried out

You define which schema steps are to be performed in period-end billing in the rate for period-end billing. If you specify a period-end billing in the rate category, you must use a billing schema that contains a period-end billing rate.

Period-end billing is triggered when the last periodic billing or final billing is carried out.

Page 191: IUT 230 billing and invoicing

© SAP AG IUT230 5-21

SAP AG 2006

Month 01

Month 02

Currentbillingperiod

Next billing period

Billing in Advance

Data: T-F-0023Schema: E9

With periodic billing, you can also calculate schema steps in advance (for example, with monthly billing, the rental price is always calculated for the following period in advance).

The period for billing in advance covers the period from the end of the periodic billing period to the next scheduled meter reading date. You can use the indicator for controlling billing in advance in the billing schema to define which steps are to be carried out in the period for billing in advance.

Page 192: IUT 230 billing and invoicing

© SAP AG IUT230 5-22

SAP AG 2008

Billing SchemeBilling Scheme

Rate 1Step 1Step 2

Rate nStep 1

Variant Programe.g. Quantity x Price

Comparison of Two Demands

Rate TypeRate Type

Utility InstallationUtility Installation

Installation StructureInstallation Structure

RatesVariant ProgramRatesVariant Program

Control of Billing in Advance

Indicator for Billing in Advance

Data Model for Billing in Advance

Rate Category

Rate Category

Rate Determination

Rate Determination

Page 193: IUT 230 billing and invoicing

© SAP AG IUT230 5-23

SAP AG 2006

Controlling Billing in Advance in the Schema

Possible entries:

Control for billing in advance = ' ':The schema step is only carried out during the periodic billing period.

Control for billing in advance = '1':The schema step is carried out during the current periodic billing period for the advance period.

Control for billing in advance = '2':The schema step is carried out during the periodic billing period and the advance period.

The settings for controlling billing in advance determine which schema steps are billed in advance.

Page 194: IUT 230 billing and invoicing

© SAP AG IUT230 5-24

SAP AG 2006

Billing: 3

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Page 195: IUT 230 billing and invoicing

© SAP AG IUT230 5-25

SAP AG 2006

Simulation

Determination ofMR

Results

Determination ofBillingPeriod

ConsumptionExtrapolation

Determination ofRate DataSimulation

BillingSimulation

Types of Simulation Functions

Generate Billing Document

Simulation Functions

Two types of simulation are available:

Simulation

Billing simulation

Billing simulation requires a billable order. Because the billing order has to be billable, meter reading results must also be available.

Simulation does not need a billing order. The clerk can enter a simulation period. The system uses existing values to project meter reading results which are not available.

Page 196: IUT 230 billing and invoicing

© SAP AG IUT230 5-26

SAP AG 2006

Billing Simulation/Simulation

Billing OrderNo billing order available!Simulation period must be specified.

Billing SimulationBilling Simulation SimulationSimulation

Billing order must be able to be billed

Billing period is derived from billing order

Meter-reading results are used

Purpose: What will tonight's billing be like?

Billing order must be able to be billed

Billing period is derived from billing order

Meter-reading results are used

Purpose: What will tonight's billing be like?

Billing order is not required

Any billing period can be specified

Existing meter-reading results are used, otherwise data is extrapolated

Purpose: What would the billing for a certain billing period look like?

Billing order is not required

Any billing period can be specified

Existing meter-reading results are used, otherwise data is extrapolated

Purpose: What would the billing for a certain billing period look like?

Both these simulation types are based on master data that actually exists.

Page 197: IUT 230 billing and invoicing

© SAP AG IUT230 5-27

SAP AG 2006

Differences Between Billing and Simulation

BillingBilling SimulationSimulation

Creates billing documents which are then processed by the invoicing functions

The billing order is deleted

Status of the meter-reading results is dynamically set to billed

A new time-slice is proposed for maintaining data in the historical data of the installation

Creates billing documents which are then processed by the invoicing functions

The billing order is deleted

Status of the meter-reading results is dynamically set to billed

A new time-slice is proposed for maintaining data in the historical data of the installation

Creates simulation documents which can only be processed further by the invoicing simulation functions

The billing order is not deleted

Meter reading results are not changed

The master data is not changed

Creates simulation documents which can only be processed further by the invoicing simulation functions

The billing order is not deleted

Meter reading results are not changed

The master data is not changed

Billing and simulation documents can be assigned to different document number ranges with the document type, so they can easily be differentiated from one another.

Different number ranges also make archiving easier later on.

Page 198: IUT 230 billing and invoicing

© SAP AG IUT230 5-28

SAP AG 2006

BillingDocuments

BillingDocuments

Mass Simulation

PortionPortion

InvoicingDocumentsInvoicing

Documents

PurposePurposeMass Simulation

BillingMass Simulation

Billing

Mass SimulationInvoicing

Mass SimulationInvoicing

Simulation of rate reforms

Model bills

Effects of price changes

Simulation of rate reforms

Model bills

Effects of price changes

Page 199: IUT 230 billing and invoicing

© SAP AG IUT230 5-29

SAP AG 2006

Billing: 4

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Page 200: IUT 230 billing and invoicing

© SAP AG IUT230 5-30

SAP AG 2008

Processing Level

Meter readingBillingInvoicingBill printoutBill display

Meter readingBillingInvoicing

Display Bill Invoicing

Individual Processing

When you select contracts for individual billing, you can specify the processing level.

If the Display Bill indicator is set, the contract is billed and then invoiced, the bill is then printed and finally displayed on the screen.

If the Invoicing indicator is set, the contract is billed and invoiced. However, the bill is not printed or displayed.

In individual processing, you can also capture meter reading results.

You can also simulate individual bills. In the same way as individual billing, you can select different processing levels. However, you can simulate bills per individual document or contract account. The individual document invoice simulation does not run a mandatory/optional check. The contract account simulation runs the mandatory/optional check in the same way as actual invoicing.

Page 201: IUT 230 billing and invoicing

© SAP AG IUT230 5-31

SAP AG 2006

Mass Billing and Mass Overall Check

Individual ProcessingIndividual Processing Mass ProcessingMass Processing

Billing Analysis

Individual Overall Check

Individual Simulation

Individual Bill

Mass Overall Check

Mass Simulation

Mass Billing

Parallel Processing

Contract accountContractInstallation

Contract accountContractInstallation

PortionInstallation intervalCheck runtimeLog w/o success message

PortionInstallation intervalCheck runtimeLog w/o success message

There are two billing alternatives: individual and mass processing.

In individual processing, you can bill a contract account, a contract, or an installation.

With mass processing, you can start mass runs in the night batch job to prevent an unnecessary load to the system. This is used for billing large numbers of contracts.

The mass overall check ensures that the selected contracts are billable.

Mass processing enables you to limit the runtime by entering the check runtime indicator and the date and time fields.

You can also use parallel processing in mass processing. This means that several billing processes are run in parallel.

Page 202: IUT 230 billing and invoicing

© SAP AG IUT230 5-32

SAP AG 2006

Document line item types relevant to posting

Document line item types relevant to posting Information line itemsInformation line items

Billing Line Item Elements

From- and to-date

Line category

Billing quantity

Price key, amount, time portion

Net amount, tax code, sub-transaction

Rate, rate category

Billing class, industry

Sort key

etc.

From- and to-date

Document line type

Billing quantity

Device

Meter reading: from - to

Rate, rate category

Billing class, industry

Sort key

etc.

The system differentiates between billing line items relevant to posting and information lines. Billing line items relevant to posting contain information for the posting, such as net amount. Information line items contain additional information that is absolutely necessary for bill printout, for example, device number, meter reading from/to.

You should always write information lines.

Tax is not calculated until invoicing.

Page 203: IUT 230 billing and invoicing

© SAP AG IUT230 5-33

SAP AG 2006

Doc. line item types rel. to postingDoc. line item types rel. to posting Information line itemsInformation line items

Examples of Document Line Item Types

000001 Energy price

000002 Demand price

000003 Flat rate

000004 Rental price

000005 Reference value

000006 Amount discount

IQUANT Quantities (meter readings)

IDEMAN Demand (meter readings)

IT001 Flat rate x factor

IT002 Addition of two operands

IT001 Quantity x (/) factor

IT004 Demand x (/) factor

IT005 Subtraction of amounts

IT006 Comparison of two quantities

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.

Page 204: IUT 230 billing and invoicing

© SAP AG IUT230 5-34

SAP AG 2006

BillingDocument

Display

BillLine Items

Price Data

Rate Data

Device Data

Account Data

InternalBillingData

MR Data

Print Data

Functions of Billing Document Display

The billing document can be displayed on the screen using the billing document display. This transaction is used for example, when the billing is outsorted and the clerk has to check the billing line items.

Page 205: IUT 230 billing and invoicing

© SAP AG IUT230 5-35

SAP AG 2006

Billing: 5

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Page 206: IUT 230 billing and invoicing

© SAP AG IUT230 5-36

SAP AG 2008

Check pool

Selection of checks to be carried out

Company-specific checks possible

not OK

Billing InvoicingCheck

- standard- company-specific

Invoice Printout

Reversal

OK OK

Exception List or WorkflowException List or Workflow

not OK ReleaseRelease Release

Check- standard- company-specific

Outsorting in SAP Utilities

SAP provides a predefined set of checks.

You can check for certain net amount limits, for example after billing. Then the billing document can be checked, reversed, released, or it can also be manually billed.

After invoicing, you should check for gross amount limits. Credit checks should also be carried out during the invoicing process and not before, as clearing takes place during invoicing (budget billing payments, payments on account, cash security deposits).

You can create your own outsorting checks and include them in the billing or invoicing program without modification.

Outsorting can occur after billing or invoicing.

Page 207: IUT 230 billing and invoicing

© SAP AG IUT230 5-37

SAP AG 2006

Net amount checks

Checks for budget billing amounts

Check for estimations

Check for billing line items

Billing InvoicingInvoicingBillingBilling

Gross amount checks

Credit checks after settlement

Balance forward

Times of Outsorting

Outsorting can occur after billing or invoicing.

Different checks can be carried out according to the time of the outsorting.

On this slide, you can see the checks provided by SAP in the system.

Page 208: IUT 230 billing and invoicing

© SAP AG IUT230 5-38

SAP AG 2006

BillingBilling

ChecksChecks

Billings to be checked

ReleaseRelease

ReversalReversal InvoicingInvoicing

Automatic ChecksAutomatic Checks Manual OutsortingManual Outsorting

Electric. contr.Manual

outsorting: 0001Once

Electric. contr.Manual

outsorting: 0001Once

BillingBilling

Billings to be checked

ReleaseRelease

ReversalReversal InvoicingInvoicing

Outsorting Options: Billing

The system supports automatic checks. The agent can also store a manual outsorting in the contract.

The agent must check the outsorted billing documents on the screen and can either reverse the billing or release it for invoicing.

The agent can use a report to display the outsorted billing documents. He/she can also process them using a workflow. To display the outsorted billing documents, two events (OUTSORTED and RELEASED) are available for the BILLDOCAUT business object. To process them, the OUTSORTDISPLAY method is available.

Page 209: IUT 230 billing and invoicing

© SAP AG IUT230 5-39

SAP AG 2006

Outsorting groupsBilling0001 Residential cust.0002 C & I customer

Outsorting groupsBilling0001 Residential cust.0002 C & I customer

Automatic checksAutomatic checks

Rate category(Generaldefinition)

Rate category(Generaldefinition)

Contract(Individualoverrides)

Contract(Individualoverrides)

Billing procedure01 Periodic billing02 Interim billing03 Final billing04 Period-end billing05 Territory transfer06 Manual billing

Billing procedure01 Periodic billing02 Interim billing03 Final billing04 Period-end billing05 Territory transfer06 Manual billing

Billing checksOutsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1Outsorting Group 0002 + Billing Procedure 01 = Check NO_LINES

Billing checksOutsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1Outsorting Group 0002 + Billing Procedure 01 = Check NO_LINES

Outsorting Group: Billing

The outsorting groups are usually stored in the rate category and can be overridden in the contract in special cases.

The actual checks are found using a customizing table from the combination of the outsorting group and the billing procedure.

Page 210: IUT 230 billing and invoicing

© SAP AG IUT230 5-40

SAP AG 2006

Billing Checks

AMOUNT1Amount check on net amount

BBP_ABS1Absolute deviation of budget billing amount

BBP_PERC1Percentage deviation of budget billing amount

ESTIMATEEstimation

NO_LINESExisting billing line items

You can create additional outsorting checks. The check programs are small ABAP/4 function modules.

The check programs in the billing are subject to a naming convention. They start with ISU_VAL_.....

The check programs for invoicing are start with Z.

Page 211: IUT 230 billing and invoicing

© SAP AG IUT230 5-41

SAP AG 2006

Customizing Functions: Billing

..........

..........

..........

...........

IMGIMG

Define check pool for billing (SAP)

Define outsorting groups for billing

Define checks for each outsorting group for billing

Define manual bill outsorting for billing

Page 212: IUT 230 billing and invoicing

© SAP AG IUT230 5-42

SAP AG 2006

Billing: 6

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Page 213: IUT 230 billing and invoicing

© SAP AG IUT230 5-43

SAP AG 2008

Billingdocument

100,-

Billingdocument

100,-

Billingdocument.

.

. Reversal...

Renewedbill

111,-

.

.

.

OutsortingOutsorting ActionsActions

Reversal Process in Billing

Reversal

Change meter reading result

Change rate category

Change rate type

etc.

Reversal

Change meter reading result

Change rate category

Change rate type

etc.

You can reverse a billing document more than once as long as it has not been invoiced. This is the case, for example, if the billing document was outsorted in billing.

The agent can reverse the billing document and carry out additional activities such as changing the meter reading result. Then the contract can be billed again.

The reversed billing document does not affect the customer, as nothing has been posted in the contract account and a bill has not been created.

Functions were added to the reversal process specifically for processing installation groups.

Page 214: IUT 230 billing and invoicing

© SAP AG IUT230 5-44

SAP AG 2006

BillingBilling Billing Document

Invoicing Document

InvoicingInvoicing

BillingOutsorting

BillingOutsorting

InvoicingOutsortingInvoicing

OutsortingBilling

ReversalBilling

ReversalInvoicingor TotalReversal

Invoicingor TotalReversal

Reversal Times

There are two times at which a reversal is possible in the system. Reversal can occur after billing or invoicing. There are two possibilities for a reversal after invoicing: either a reversal of invoicing, or a full reversal (reversal of invoicing and of billing).

Page 215: IUT 230 billing and invoicing

© SAP AG IUT230 5-45

SAP AG 2006

Reversed Billing

Document

BillingReversalBilling

Reversal

Billing Order

Billing Reversal Elements

Reversed billing document is marked accordingly

Billing order is restored

Page 216: IUT 230 billing and invoicing

© SAP AG IUT230 5-46

SAP AG 2006

Reasons for Reversal

Incorrect meter reading

Estimation

Meter is stuck

Meter is working backwards

Meter is defective

Wrong meter read

Wrong rate used

Water pipe break

Incorrect billing period

Ripple control receiver is defective

Page 217: IUT 230 billing and invoicing

© SAP AG IUT230 5-47

SAP AG 2006

Data Elements of the Billing Process

Billing Process

Billing Simulation

Billing Documents

Outsorting in Billing

Billing Reversal

Parallel Processing

Billing: 7

Page 218: IUT 230 billing and invoicing

© SAP AG IUT230 5-48

SAP AG 2008

Aim: Processing times can only be shortened by dividing up the processes

Parallel processing of dataset

Jobs should finish at roughly the same time

Large volume of data:

Billing

Invoicing

Bill Printout

Budget Billing Request

Creation of Partial Bills

Parallel Processing - Situation

Page 219: IUT 230 billing and invoicing

© SAP AG IUT230 5-49

SAP AG 2006

Size of Interval = 3

No. of Intervals = 4

No. of Intervals = 3

Size of Interval = 4

Interval_1 Interval_2Interval_3

Interval_1

Interval_2

Interval_3

Interval_4

BP_1

BP_3

BP_4

BP_5

BP_9

BP_19

BP_20

BP_30

BP_21

BP_35

BP_40

BP_31

Parallel Processing: Interval Creation

Using the number of intervals parameter, you can define the number of intervals that are to be created.

You can also use the interval size parameter, which defines the number of processes per interval.

When creating intervals, you can take different objects into account (business partner, contract account, billing order). This depends on the background process that is to run, for example:

Mass billing = billing orders

Invoicing = EITR (pool of contracts that have not been invoiced yet)

Request budget billing amounts = contract accounts

Bill printout = EITERDK (pool of bills that have not been printed yet)

Page 220: IUT 230 billing and invoicing

© SAP AG IUT230 5-50

SAP AG 2006

Parallel Processing: Problems of Portioning

ProblemsHow is the dataset to be portioned?The dataset is not distributed evenly:

Contract account numbers or business partner numbers are generally more concentrated in some number intervals than in others.

Contract accounts have varying numbers of items.

How many portions should be allocated to each process?Each processing run does not contain the same processes or number of processes:

Processes on different servers have varying degrees of "performance".

Furthermore, performance is dependent on other processes that are being carried out at the same time.

Page 221: IUT 230 billing and invoicing

© SAP AG IUT230 5-51

SAP AG 2006

mOIs

mOIs

mOIs

...

Interval1

Interval4

Interval9

Interval3

Interval6

Interval2

Interval10

Client AJob 1

Client AJob 2

... Client XJob n

Dispatcher forMass Data Program

m = Block value

Parallel Processing: Implementation

Page 222: IUT 230 billing and invoicing

© SAP AG IUT230 5-52

SAP AG 2008

Billing: Summary

SAP AG

Billing in SAP Utilities follows a process controlled by billing orders.

A clerk can either perform actual or simulated billing.

Extensive outsorting functions are available.

Billing can be completely reversed by a clerk.

The billing run can be processed in parallel.

Page 223: IUT 230 billing and invoicing

© SAP AG IUT230 5-53

BillingExercises

Unit: Billing Topic: Schedule Records

Understand scheduling and be able to determine the data used in the master data.

Be able to describe and carry out the billing process in IS-U.

Understand the differences between meter reading and billing orders.

Billing in IS-U follows a specific predefined process. These processes are planned and carried out for regular billing using the scheduling function.

1-1 Check the existing scheduling to be used for the business partner (TF0601A0##).

1-1-1 Which meter reading unit is the business partner’s installation allocated to? ____________________________________________________________

1-1-2 What meter reading unit is this portion allocated to? ____________________________________________________________

1-1-3 Which schedule records are generated for this portion? ____________________________________________________________

1-1-4 Check the status of the billing process for the business partner. Select the monitoring function in Meter Reading and check the status of the billing order.

Which status does your business partner’s billing order have? ____________________________________________________________

1-1-5 Which scheduled billing date does the billing order have? ____________________________________________________________

Page 224: IUT 230 billing and invoicing

© SAP AG IUT230 5-54

Page 225: IUT 230 billing and invoicing

© SAP AG IUT230 5-55

Exercises

Unit: Billing Topic: Billing/Simulation

Carry through the procedure of billing a hypothetical situation.

Monitor the status of the meter reading and billing order.

Billing in IS-U follows a specific predefined process. Apart from real billing, you can also simulate billing. Both billing forms are used to test new rates.

2-1 A meter reading order has already been created for the business partner TF0602A0##.

2-1-1 For which meter reading date is the order? ___________________________________________________________

2-1-2 What is the meter reading order number? ___________________________________________________________

2-1-3 Go to the IS-U area device/meter reading and create a suitable meter reading for your meter reading order. ____________________________________________________________

2-1-4 Carry out the billing procedure for the business partner. Which document number does your bill have? ____________________________________________________________

Page 226: IUT 230 billing and invoicing

© SAP AG IUT230 5-56

Page 227: IUT 230 billing and invoicing

© SAP AG IUT230 5-57

Exercises

Unit: Billing Topic: Simulation/Document Display

Be able to define the differences between billing and simulation.

Be able to carry out a simulation without meter reading data.

A customer is billed according to the rate valid up to now. Before the new rate structure is introduced, the clerk checks what would be the result of a bill with the old data.

3-1 The individual billing simulation must be executed for a period from January 1st of this year to today’s date. Use the business partner TF0603A0## and the contract TF0603A0##.

3-1-1 What is the bill’s document number? ____________________________________________________________

3-2 True or false?

3-2-1 You always need a billing order for simulation. ____________________________________________________________

3-2-2 Billing simulation affects the business partner’s contract account. ____________________________________________________________

3-2-3 Billing simulation does not change the master data. ____________________________________________________________

3-3 Display the current billing document for the business partner TF0605A0## and the contract TF0605A0##.

3-3-1 How many billing line items does the document contain? ____________________________________________________________

3-3-2 Which billing schema was used for billing? ____________________________________________________________

Page 228: IUT 230 billing and invoicing

© SAP AG IUT230 5-58

Page 229: IUT 230 billing and invoicing

© SAP AG IUT230 5-59

Solutions

Unit: Billing Topic: Schedule Records

1-1 Check the existing scheduling to be used for the business partner (TF0601A0##).

1-1-1 To which meter reading unit is the business partner’s installation allocated?

From the SAP menu, choose Utilities Industry Technical Master Data Installation Display.

Enter the installation number TF0601A0## in the initial screen.

Meter Reading Unit: T-C-00

1-1-2 To which portion is this meter reading unit allocated?

Mark the meter reading unit and branch to display the meter reading unit.

Portion: T-C-00

1-1-3 Which schedule records are generated for this portion?

From the SAP menu, choose Utilities Industry Scheduling Schedule Record Evaluation Schedule Record.

Select the indicator Portion Choose Execute.

1-1-4 Check the status of the billing process for the business partner. Select the monitoring function in Meter Reading and check the status of the billing order.

Which status does your business partner’s billing order have?

From the SAP menu, choose Utilities Industry Device Management Meter reading Monitoring

Manual.

Choose Business partner. Enter the business partner TF0601A0## in the Business partner field. Choose Billing order Execute.

Billing order status: 1

1-1-5 Which scheduled billing date does the billing order have?

The date is stored in the field Sched. MRD.

Page 230: IUT 230 billing and invoicing

© SAP AG IUT230 5-60

Page 231: IUT 230 billing and invoicing

© SAP AG IUT230 5-61

Solutions

Unit: Billing Topic: Billing/Simulation

2-1 A meter reading order has already been created for the business partner TF0602A0##.

2-1-1 For which meter reading date is the order?

From the SAP menu, choose Utilities Industry Device Management Meter reading Monitoring

Manual.

Choose Business partner. Enter the business partner TF0602A0## in the Business partner field. Select Meter reading order. Choose Execute.

2-1-2 What is the meter reading order number?

From the SAP menu, choose Utilities Industry Device Management Meter reading Monitoring

Manual.

Choose Business partner. Enter the business partner TF0602A0## in the Business partner field. Select Meter reading order. Choose Execute.

Take the number from the Entry no. field.

2-1-3 Go to the IS-U area device/meter reading and create a suitable meter reading for your meter reading order.

From the SAP menu, choose Utilities Industry Device Management Meter reading Entry of Meter Reading Results Single Entry.

Enter the business partner TF0602A0## in the Business partner field and select the meter reading reason 01.

Choose Continue.

Enter a meter reading as described in the exercise and save.

Page 232: IUT 230 billing and invoicing

© SAP AG IUT230 5-62

2-1-4 Carry out the billing procedure for the business partner.

Which document number does your bill have?

From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing

Individual Bill.

Select the selection criterion Contract and enter the contract TF0602A0##. You can also enter meter readings directly using the individual bill transaction.

Choose Execute.

You will find the document number in the log following billing.

Page 233: IUT 230 billing and invoicing

© SAP AG IUT230 5-63

Solutions

Unit: Billing Topic: Simulation/Document Display

3-1 The individual billing simulation must be executed for a period from January 1st of this year to today’s date. Use the business partner TF0603A0## and the contract TF0603A0##.

3-1-1 What is the bill’s document number?

From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing

Individual Simulation Billing.

Choose the simulation type Simulation. Select the time period specified in the exercise. Select the selection criterion Contract and enter the contract TF0603A0##.

Choose Execute.

You will find the document number in the log following billing.

3-2 True or false?

3-2-1 You always need a billing order for simulation.

False

3-2-2 Billing simulation effects the business partner’s contract account.

False

3-2-3 Billing simulation does not change the master data.

True

3-3 Display the current billing document for the business partner TF0605A0## and the contract TF0605A0##.

3-3-1 How many billing line items does the document contain?

From the SAP menu, choose Utilities Industry Billing Billing Execution Display Document.

Look for the current billing document number of the business partner TF0605A0##. Enter the business partner number in the selection data and select Continue. Look for the current billing document for the contract above and select it by double-clicking it.

Line item: number of document line items.

Page 234: IUT 230 billing and invoicing

© SAP AG IUT230 5-64

3-3-2 Which billing schema was used for billing?

Select the Int. billing data tab page.

Billing schema: E1

Page 235: IUT 230 billing and invoicing

© SAP AG IUT230 6-1

SAP AG 2008

Manual Billing

SAP AG 2007

Manual Billing Functions

Examples of Use

Individual Bill

Joint Invoicing

Page 236: IUT 230 billing and invoicing

© SAP AG IUT230 6-2

SAP AG 2006SAP AG 2006

At the conclusion of this unit, you will be able to:

Describe manual billing functions

Provide examples of manual billing

Create a manual billing

Recognize the difference between an individual bill and joint invoicing

Manual Billing: Unit Objectives

Page 237: IUT 230 billing and invoicing

© SAP AG IUT230 6-3

SAP AG 2008

Calculation Options Functions

ManualBilling

Meter Reading from/to

Net Amount

Price Determination

Billing QuantityRate

Determination

StatusManagement

TaxDetermination

Individual Bill/Joint Invoice

Template

Manual Billing Functions

A manual billing can be created as an individual bill or be incorporated into the next bill.

Using the reference function, you can use existing billing documents/line items as a reference.

The manual billing function can be used as an alternative to reversal to correct the bill.

The customer can also be billed for additional services or additional consumption.

Page 238: IUT 230 billing and invoicing

© SAP AG IUT230 6-4

SAP AG 2008

(Time-based)

Data Objects Invoicing

Business partner

Contract account

Contract

Installation

Installation Structure

(optional)

BillMs. Brown

....

Electricity ............. 900Discounts.................- 800

Manual credit memo -50

Amount due ........... 50

Bill Ms. Brown

Manual backbilling

Amount due ................. 50

Manual Billing

Manual creation of billing document line items

An Overview of Manual Billing

Necessary prerequisite Unlike in automatic billing, the billing line items are not automatically created based on the existing data objects. Despite this, the same data must exist for manual billing as for automatic billing. This information is required for open item accounting or for sales statistics, for example.

Contract and installation This data is kept historically. This means that it is possible to create manual bills for installations and contracts that no longer belong to the same business partner as at creation (as a result of a move-in/out, for example).

Installation structure In manual billing, you need the installation structure for device-related credit memos or backbilling (however, it is not needed not for flat-rate installations).

Invoicing When the manual bill is being created, a decision is made based on the entries whether to create an individual bill or to include the billing line items in the next invoicing procedure that affects that contract.

Credit memo or backbilling If the result (total of all billing line items) is positive, a credit memo is created, and if it is negative, a backbilling is created.

Page 239: IUT 230 billing and invoicing

© SAP AG IUT230 6-5

SAP AG 2008

Selection of- Affected Line Items- Billing Order

Selection of- Affected Line Items- Billing Order

Print Action Record

Control DataJoint Invoicing

Copy Prorations

Initial EntryContract

Key Date

Control DataCopy of Doc. Line Items

Reversal

TemplateBilling Document

Maintenance

Basic Data

- Rate Data- Quantity Data- Line Items Control Data- Price Data- Amount Data

Device Data

- Device- Operand Data

Additional Data

- Line Category- Franchise Fee Data- Account Assignment Data

Manual Billing: Initial Entry

Initial entry Manual billing always refers to a contract. You cannot create a manual billing for several contracts and contract accounts. The key date is required for contracts and installations where the current business partner is not the business partner who is to receive the bill (this does not refer to the alternate bill recipient).

Reference If the manual billing is created with reference to an existing billing document, this data can be copied to the document line items. If there are several line items, a selection can be made.

Print action record When you create or change a manual billing you can create a print action record, which allows you to include additional detailed information in the bill when you print it.

Page 240: IUT 230 billing and invoicing

© SAP AG IUT230 6-6

SAP AG 2006

With Reference toBilling Order

Billing Document

Contract

Billing Order

ReleaseReleaseBill

PrintoutInvoicing

Explicit Releasefor Invoicing

Open Item Accounting

Statistics

Manual Billing Process

Release Manual billing must be released explicitly for invoicing.

Billing order If a billing order exists for this contract, it can be selected. The data from the billing order is then transferred to manual billing. When the manual billing is released, the order is deleted. If the manual billing is deleted, the billing order is regenerated.

Page 241: IUT 230 billing and invoicing

© SAP AG IUT230 6-7

SAP AG 2006

ManualBilling

ManualBilling

Bill

Last bill not reversibleLast bill not to be reversedNo bill available

Examples of Manual Billing

500 kWh backbillingdue to incorrect meter reading

40 USD credit memo due to broken water pipe (goodwill)

Bill corrected because wrong meter was read

Manual billing can be used for various purposes, for example, when a bill can no longer be reversed (because, for example, it is not the most recent bill).

Manual billing has no effect on existing billing documents. This is additional credit/backbilling line items, which can be invoiced either individually or together with the next bill.

Page 242: IUT 230 billing and invoicing

© SAP AG IUT230 6-8

SAP AG 2008

Invoicing

Manual Billing Document

Bill PrintoutPrint Document with Print Items

Automatic Billing

Document

Invoicing Bill PrintoutPrint Document with Print Items

Manual Billing Document

Joint InvoicingJoint Invoicing

Individual Bill

Joint Invoicing/Individual Bill

Bill

Bill

When you create a manual billing document, you have to decide whether the document is to be invoiced as an individual bill, or whether the billing line items are to be included in the next invoicing run (for example in the next periodic billing).

The manual billing document no longer has to be billed, as the 'billing' took place when the clerk entered the billing line items.

Page 243: IUT 230 billing and invoicing

© SAP AG IUT230 6-9

SAP AG 2006

Manual Billing: Unit Summary

SAP AG

In manual billing you can specify 'from' and 'to' dates, quantities, and net amounts.

The manual billing transaction can be used instead of reversal functions.

A manual billing can be sent as an individual bill or be included in the next billing.

Extensive reference functions are available to make it easier for clerks to enter billing line items.

Page 244: IUT 230 billing and invoicing

© SAP AG IUT230 6-10

Page 245: IUT 230 billing and invoicing

© SAP AG IUT230 6-11

Exercises

Unit: Manual Billing Topic: Manual Billing

Create a manual billing.

A customer has received a bill containing errors. As the bill is two years old, it can no longer be reversed. Therefore, you bill the customer manually.

1-1 Carry out the manual billing procedure for the business partner TF1101A0##. The incorrect billing and invoicing for this business partner can no longer be reversed.

1-1-1 Create a billing document manually for the contract TF1101A0##. Enter today’s date as the key date. The manual billing is to be invoiced as an individual bill. Therefore, you must leave the joint invoicing field blank. Use the last billing document for the contract as a reference document. Use the second line item in the last billing document as a reference. Enter a backbilling line item for 250 kWh. ________________________________________________________________________________________________________________________

1-1-2 Create a second line item. You want to use this line item to reverse the document line item, which you selected as a template. ______________________________________________________________________________________________________________________

1-1-3 What is the total amount of the line items you created? ________________________________________________________________________________________________________________________

1-1-4 Now the manual billing document has to be invoiced. You do not execute invoicing until the next unit. Release your manual billing document for invoicing. Display the (manual) billing document. What main transaction is determined for this billing document? ____________________________________________________________

Page 246: IUT 230 billing and invoicing

© SAP AG IUT230 6-12

Page 247: IUT 230 billing and invoicing

© SAP AG IUT230 6-13

Solutions

Unit: Manual Billing Topic: Manual Billing

1-1 Carry out the manual billing procedure for the business partner TF1101A0##. The billing and invoicing for this business partner can no longer be reversed.

1-1-1 Create a billing document manually for the contract TF1101A0##. Enter today’s date as the key date. The manual billing is to be invoiced as an individual bill. Therefore, you must leave the joint invoicing field blank. Use the last billing document for the contract as a reference document. Use the second line item in the last billing document as a reference. Enter a backbilling line item for 250 kWh.

From the SAP menu, choose: Utilities Industry � Billing � Billing Execution � Manual Billing � Create.

Key date: Current date Joint invoicing: Leave empty

This takes you to the data entry screen for the billing document line item. All fields are empty. Select the icon Transfer Line Items. Select the last billing document.

Select the second document line item and choose Transfer. This line item is used as a reference. You can now enter 250 kWh in the quantity field and backbill.

1-1-2 Create a second line item. You want to use this line item to reverse the document line item, which you selected as a template. Do not leave the transaction. Select the icon Transfer Line Items again. Enter the same billing document as you selected as the template. Activate the Reversal field. Select the second document line item and choose Transfer. This document line item is transferred along with the correct transactions for the reversal. You can no longer change the quantity.

1-1-3 What is the total amount of the line items you created? Select the icon for executing manual billing. Copy the line items. The total amount is stored on the basic data tab page in the amount data group box.

Page 248: IUT 230 billing and invoicing

© SAP AG IUT230 6-14

1-1-4 Now the manual billing document has to be invoiced. You do not execute invoicing until the next unit. Release your manual billing document for invoicing. Display the (manual) billing document. What main transaction is determined for this billing document? Select the icon release for invoicing. The following dialog box asks you if you want to save the document and release it for invoicing. If you answer yes, you cannot make any subsequent changes to the document. If you do want to make any changes, you must first of all delete the document. From the SAP menu, choose Utilities Industry � Billing � Billing Execution � Display Document. Enter the business partner number and find your manually created billing document in the navigation area. Double-clicking on the document takes you to the detail view screen. Select the header data tab page. The entry Manual Credit Memo/Backbilling (0300) is defined as a main transaction here.

Page 249: IUT 230 billing and invoicing

© SAP AG IUT230 7-1

SAP AG 2008

Invoicing

SAP AG 2007

Invoicing in SAP Utilities

Invoicing Functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 250: IUT 230 billing and invoicing

© SAP AG IUT230 7-2

SAP AG 2006SAP AG 2006

At the conclusion of this unit, you will be able to:

Describe the invoicing functions

Explain how items from accounts receivable and payable are processed

Explain how due dates are determined

Describe payment method determination

Outline the concept of joint invoicing/integration

Describe the outsorting concept

Invoicing: Unit Objectives

Page 251: IUT 230 billing and invoicing

© SAP AG IUT230 7-3

SAP AG 2006

Invoicing: Business Scenario 10

MaintainBillingMaster Data

Use of Ratesin the

Master DataInvoicing Bill PrintoutBilling

Budget Billing Amounts

Additional Functionality:Additional Functionality:Discounts/SurchargesDiscounts/SurchargesManual BillingManual BillingSales StatisticsSales StatisticsSpecial Billing FeaturesSpecial Billing Features

The scenario in this unit deals with test invoicing.

A customer has made a payment within the current billing period and was billed according to the corresponding rate. The customer also wishes to receive an interim bill.

Another customer receives a bill but is not in agreement with the meter reading results billed. The meter reading results are too high. Invoicing and billing are reversed (full reversal). An adjustment bill is created.

Page 252: IUT 230 billing and invoicing

© SAP AG IUT230 7-4

SAP AG 2008

Invoicing: 1

Invoicing in SAP Utilities

Invoicing functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 253: IUT 230 billing and invoicing

© SAP AG IUT230 7-5

SAP AG 2006

Meter Reading

Order

Billing Order

InvoicingInvoicingCreation ofMeter Reading Order

Creation ofMeter Reading Order

Entry ofMeter Reading Data

Entry ofMeter Reading Data

BillingBilling

Billing Document

Implausible Meter Reading Results

PlausibleMeter Reading

Results

Billing Order

Correction ofMeter Reading

Results

Correction ofMeter Reading

Results

Print Document

BillPrintout

BillPrintout

Bill Creation

Page 254: IUT 230 billing and invoicing

© SAP AG IUT230 7-6

SAP AG 2008

Invoicing Tasks

Invoicing Tasks:Group invoicing orders and billing documents from contracts in acontract account into a joint bill*Supply print documents for bill creationPost documents in subledger accountingProcess budget billing plansClear items in contract accounts receivable and payable

Standard SAP Utilities process that establishes the link to contract accounts receivable and payable, and provides the basis for bill creation

* Bills are created per contract account and not per contract/business partner.

Page 255: IUT 230 billing and invoicing

© SAP AG IUT230 7-7

SAP AG 2006

FI-CA Documents

Budget Billing Plans

BillingDocuments

Receivables$100

PhysicalPrintout

Invoicing- Data Entry- Validations - Processing ofFI-CA Documents

Receivables$100Receivables100 USD

Manual Billing Print Documents

Print Documents

PostingDocuments

FI-CA

PostingDocuments

FI-CA

Budget Billing Plans

Budget Billing Plans

SD Documents

Invoicing

Invoicing

Generates posting documents for bill receivables or credit memos from the billing documents

Clears the posting documents with down payments, especially budget billings (only for statistical budget billing)

Supports determination and charging of taxes, charges, and duties

Prepares data for bill printout, that is, generates print documents

Creates budget billing plans for the next budget billing period

Creates the posting documents and the budget billing plans in FI-CA

FI-CA documents can be processed in invoicing as part of clearing control (for example, settling payments on account with receivables from invoicing)

Page 256: IUT 230 billing and invoicing

© SAP AG IUT230 7-8

SAP AG 2008

Invoicing and Master Data

Business partner

Contract

Contract account

FI-CAR/3 central functionsSAP Utilities

Invoicing document

Print document

Contract accounts receivable and

payable document

Invoicing

Reads the business partner

Uses the contract account from contract accounts receivable and payable that contains agreements for processing business transactions with the business partner. Procedures are defined in the contract account that are used for processing document items.

A business partner can have several contract accounts

A contract account can only be allocated to one business partner

Uses the SAP Utilities contract, which contains division-related agreements between the business partner and the utility company. A contract is allocated to a contract account.

Invoicing can create a bill for several contracts for an account master record

Page 257: IUT 230 billing and invoicing

© SAP AG IUT230 7-9

SAP AG 2006

Invoicing Data General Data

ContractAccount

General Data

• Payment terms• Clearing category• Account assignment data• Payment methods• Transaction currency

Invoicing Block

Outsorting Data• Manual outsorting• Check group

General DataAdditional Functions

• Interest key• Dunning procedure• CB account

Correspondence• Bill form• Alternative Bill Recipient• Shipping control• Different indicators

Budget Billing Data• Budget billing procedure• Participation in YAP• Budget billing request cash payer

Invoicing Data from Contract Account

• Blocking reason• Block validity

The following occurs based on the contract account data (table FKKVKP):

Correspondence and bill printout are controlled

Bill outsorting is controlled

Budget billing amounts are processed

Bills are blocked

Page 258: IUT 230 billing and invoicing

© SAP AG IUT230 7-10

SAP AG 2006

Invoicing Data General Data

Contract

General Data• Contract account• Company code• Division• Statistics group• etc.

Invoicing Data• Joint invoicing• Finally invoiced

Acct. Assignment Data

• Account determination ID• CO Account determination key• Business area

Deregulation Fields

Budget Billing Data

Invoicing Data from Contract

• Budget billing adjustment• Budget billing cycle• Payment plan data

Page 259: IUT 230 billing and invoicing

© SAP AG IUT230 7-11

SAP AG 2006

Invoicing

Budget billingclearing

Clearing of firstbudget billing

Inclusion ofopen items

Creditprocessing

Due datedetermination

Budget billingdetermination

Jointinvoicing

Cross-company code

invoicing

Invoicing Functions

Page 260: IUT 230 billing and invoicing

© SAP AG IUT230 7-12

SAP AG 2006

Create bill (EA10)Create partial bill (EA11)Create bill and partial bill together (EA46)Request budget billings (EA12)Create collective bill (EA10_COLL)

Individual processing that creates bills for a business partner or contract account:

Mass processing that creates bills for a business partner or contract account interval:

Create bill (EA19)

Create partial bill (EA25)

Create bill and partial bill together (EA45)

Bill Creation

Partial bills are only created when you enter Partial bill procedure for budget billing collection as the budget billing procedure.

Budget billing amounts are only requested if you enter statistical procedure for budget billing collection as the budget billing procedure.

Collective bills can only be created when the collective bill concept is used.

You can find invoicing in the SAP menu under Utilities Industry -> Invoicing -> Execute Invoicing

Page 261: IUT 230 billing and invoicing

© SAP AG IUT230 7-13

SAP AG 2006

Data Selection

During invoicing processes, contract accounts are selected in different ways:

An invoicing order triggers:Bill creationCollective bill creationJoint bill/partial bill creation

Contract accounts to be processed are selected using the budget billing plan items in the following cases:

Budget billing requestCreation of partial billsJoint bill/partial bill creation

Page 262: IUT 230 billing and invoicing

© SAP AG IUT230 7-14

SAP AG 2006

Create BillCreate Bill Create Partial BillCreate Partial Bill

Document Date

Posting Date

Reconciliation Key

Document Date

Posting Date

Reconciliation Key

SimulationSimulation

Individual Processing

You can bill or partially bill a contract account or business partner with the individual processing function. You must specify the following:

Document Date

Posting Date

Reconciliation Key

You can run a simulation for both processing forms with a special indicator.

Page 263: IUT 230 billing and invoicing

© SAP AG IUT230 7-15

SAP AG 2006

ParallelProcessing

ParallelProcessing

ParallelProcessing

ParallelProcessing

BillBill x y z

RechnungRechnung x y z

RechnungRechnung x y z

RechnungRechnung x y z

BillBillx y z

CreateBill

CreateBill

CreatePartial Bill

CreatePartial Bill

RequestBudget Billing

RequestBudget Billing

End of Runtime

Log

End of Runtime

Log

ParallelProcessing

ParallelProcessing

Parallel Processing

The parallel processing function in invoicing is used to process a large number of contract accounts.

Here, you can

Create bills

Create partial bills

Request budget billing

You can also carry out the above processes in mass processing.

Page 264: IUT 230 billing and invoicing

© SAP AG IUT230 7-16

SAP AG 2008

Invoicing: 2

Invoicing in SAP Utilities

Invoicing functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 265: IUT 230 billing and invoicing

© SAP AG IUT230 7-17

SAP AG 2006

Invoicing Unit and Grouping Options

Invoicing orders or budget billing plan items are grouped into invoicing units so that they can be jointly invoiced and displayed on a bill. A unit forms the basis of invoicing processes.

A grouping proposal is automatically created

Grouping parameters in the contract and billing document control the grouping proposal

You can edit the grouping proposal inevent R403

Examples of an invoicing unit: The electricity and gas contracts of a contract account are periodically billed. A bill correction is entered in the electricity account. All three billing documents are grouped together to form an invoicing unit. A bill is created.

The budget billing items from the electricity and gas contract are requested on one bill. They are an invoicing unit.

Page 266: IUT 230 billing and invoicing

© SAP AG IUT230 7-18

SAP AG 2006

Electric. contr.Joint invoice: 1Electric. contr.Joint invoice: 1

Gas contractJoint invoice: 1Gas contract

Joint invoice: 1Water contractJoint invoice: 1Water contractJoint invoice: 1

Cable televisioncontract

Joint invoice: 2

Cable televisioncontract

Joint invoice: 2

Electricity installation

Meter reading unit:T0001

Electricity installation

Meter reading unit:T0001

Gas installationMeter reading unit:

T0001

Gas installationMeter reading unit:

T0001

Water installationMeter reading unit:

T0002

Water installationMeter reading unit:

T0002

Cable televisioninstallation

Meter reading unit:K0001

Cable televisioninstallation

Meter reading unit:K0001

Contract Account

Contract Account

Joint Invoicing: Master Data

Billing documents of selected contracts in a contract account are grouped to form invoicing units in order to create a suitable bill that includes as many of the customer's contracts as possible. For this purpose, contracts are divided into three distinctive groups:

Contracts for which the documents must be invoiced jointly. The billings of these contracts must always appear together on one bill (for example, a residential customer's contracts for electricity, gas, and water). If a document has to be invoiced with other documents, a search for the corresponding billing documents of the other contracts is carried out. If no valid document is found, invoicing is stopped.

Contracts for which the documents can be invoiced jointly. The documents of these contracts are also grouped together, if possible, with the documents that must be invoiced jointly.

Contracts for which the documents must be invoiced separately.

The billing documents that qualify for joint invoicing are transferred to FI-CA in an accounting document. During this process, the data from the individual billing documents is summarized according to fixed FI-CA criteria and other, company-specific controls (such as account determination and transaction determination).

Page 267: IUT 230 billing and invoicing

© SAP AG IUT230 7-19

SAP AG 2008

Contract 1Mandatoryjoint invoice

Contract 1Mandatoryjoint invoice

Contract 2Mandatoryjoint invoice

Contract 2Mandatoryjoint invoice

Contract 3Mandatoryjoint invoice

Contract 3Mandatoryjoint invoice

ContractOptional

joint invoice

ContractOptional

joint invoiceDocumentOptional

DocumentOptional

Document 3Mandatory

Document 3Mandatory

Document 1Mandatory

Document 1Mandatory

DocumentOptional

DocumentOptional

Billing

ContractExclusive invoiceContract

Exclusive invoiceDocumentExclusive

DocumentExclusive

DocumentExclusiveDocumentExclusive

InvoicingContract Account

Bill

Event: R403

Joint Invoicing: Example 1

Bill

In the first example, contracts 1, 2, and 3 must always be billed together. As contract 2 has not been billed yet, the contracts are not invoiced.

The other two contracts can be invoiced. However, the customer receives two bills, as one of the contracts can only be invoiced exclusively.

Event R403 can be used to influence how the invoicing unit is formed.

Page 268: IUT 230 billing and invoicing

© SAP AG IUT230 7-20

SAP AG 2008

Contract 1Mandatoryjoint invoice

Contract 1Mandatoryjoint invoice

Contract 2Mandatoryjoint invoice

Contract 2Mandatoryjoint invoice

Contract 3Mandatoryjoint invoice

Contract 3Mandatoryjoint invoice

ContractOptional

joint invoice

ContractOptional

joint invoiceDocumentOptional

DocumentOptional

Document 3Mandatory

Document 3Mandatory

Document 1Mandatory

Document 1Mandatory

DocumentDocument

Billing

ContractExclusive invoiceContract

Exclusive invoiceDocumentExclusive

DocumentExclusive

DocumentExclusiveDocumentExclusive

InvoicingContract Account

Bill

Document 2Mandatory

Document 2Mandatory

Event: R403

Joint Invoicing: Example 2

Bill

In the second example, the billing documents for the contracts 1, 2, and 3 exist, which means that they can be invoiced jointly.

As there is also a billing document for the optional contract, it can also be included in the invoicing unit.

In either case, the exclusive contract has to be invoiced separately.

Event R403 can be used to influence how the invoicing unit is formed.

Page 269: IUT 230 billing and invoicing

© SAP AG IUT230 7-21

SAP AG 2006

Contract Account

Terms of Payment:

Contract Account

Terms of Payment:

0001

Due Date

PostingDate

PostingDate

Document DateDocument Date

System DateSystem Date

Receivable/Credit

Receivable/Credit

FI-CA Termsof Payment

FI-CA Termsof Payment

FI Terms of Payment:Receivable 14 Days

FI Terms of Payment:Receivable 14 Days

FI Termsof Payment:

Credit Immediately

FI Termsof Payment:

Credit ImmediatelyIncoming PaymentsOutgoing PaymentsIncoming PaymentsOutgoing Payments

Elements of Due Date Determination

The terms of payment are also used by other standard components (e.g. FI, SD).

A predefined payment condition that refers to a term of payment is entered in the contract account.

If other payment conditions should be used for different services, several contract accounts have to be created.

The terms of payment could depend on the following data: Posting date, document date, system date.

Maintain the payment conditions and terms of payment in the Financial Accounting Customizing menu under:

Contract Accounts Receivable and Payable -> Basic Functions -> Postings and Documents -> Document -> Maintain Payment Conditions

Accounts Receivable and Accounts Payable -> Business Transactions -> Incoming Invoices/Credit Memos -> Maintain Terms of Payment

Page 270: IUT 230 billing and invoicing

© SAP AG IUT230 7-22

SAP AG 2006

Basics of Due Date Determination

The due date of the bill is based on the general elements of due date determination

Final bill amount (credit/receivable) forms the basis for due date determination

The due date is determined in the event Document: Determine due date from payment condition (1330)

The bill due date is stored in all business partner items from the newly created posting documents and in the print document header.

For the budget billing request or partial bill creation, the due date is:

Transferred from the budget billing plan

Re-determined if the request is delayed

When a collective bill is created, the due date is copied from the individual bills

Bill due date consist of net due date, cash discount percentage rate.

When consumption billing is invoiced, the balance of evaluated consumption values incl. tax minus paid budget billing amounts is the basis for due date determination. Account maintenance and creation of sub-items take place.

You can use a different due date determination in a user-specific function module for event 1330. In the case, the SAP function module is not executed.

The day entries (date limits) must be made in ascending order and cover the whole month.

You must propose a date type (basis date). Recommendation: Document date or date of entry. When you are maintaining several date limits, you can only use one date type for each term of payment.

Cash discount:

Only single-level cash discount entry permitted

Calculated net due date cannot come before the cash discount due date

Page 271: IUT 230 billing and invoicing

© SAP AG IUT230 7-23

SAP AG 2006

Grouping Bill Due Date and Budget Billing Amount Due Date

Only possible when invoicing consumption billingPrerequisites are:

Bill ReceivableThe BB/Bill Due Dates field (ABRABS) must be active in the portion.

1: Bill is due together with next budget billing amount2: Next budget billing amount is due together with bill

Control of billing due date (table TE501)Amount checkInterval check

Event IS-U Invoicing: Budget billing clearing (R420): Due date determination by including budget billing due dates.

Grouping bill due date and due date of the next budget billing amount

This grouping allows you to influence the bill due date for the last time in invoicing.

The following applies in the control table TE501:

The due date can be adjusted separately for direct debit payers/cash payers

Amount check: Final bill amount < upper limit

Interval check: Number of days between bill due date and budget billing due date

If the due date of the next budget billing amount and the bill are grouped together, the budget billing amount is included in the print document as a line item and, as a result, becomes relevant for the final amount. This budget billing amount can no longer be requested, or a partial bill is not created for it.

When several contracts are invoiced and each of these have a budget billing plan, the due date is only adjusted if the fixed value 2 is maintained in the field ABRABS in all portions.

Page 272: IUT 230 billing and invoicing

© SAP AG IUT230 7-24

SAP AG 2008

Payment Method Determination: Incoming

Contract Account

Incoming payment method:E Automatic debitK Credit card

Determination of incoming payment

method

Determination of incoming payment

method

Amount limit:Lower limit

Amount limit:Lower limit

Check for incoming

payment blocks

Check for incoming

payment blocks

User exitEvent R430User exit

Event R430

Determination of incoming payment method

In invoicing, a payment method is determined based on the final bill amount according to specifications set in the contract account. The determined payment method is transferred to the print document header.

The invoicing posting documents, however, do not have a payment method so that they can be regulated together in a payment run with other open items for the contract account. The items are reinterpreted during the payment run.

If the final bill amount represents a receivable, invoicing tries to determine an incoming payment method.

In the contract account, you can enter the customers desired incoming payment method (such as automatic debit, credit card).

Amount limits in Customizing or incoming payment blocks that may have been set in the contract account, can also influence the determination of the appropriate incoming payment method.

An incoming payment block ensures that a direct debit payer is treated as a cash payer - i.e. a payment method is not determined.

Page 273: IUT 230 billing and invoicing

© SAP AG IUT230 7-25

SAP AG 2006

Contract Account

Outgoing Payment MethodsP Postal transferC Check

Contract Account

Outgoing Payment MethodsP Postal transferC Check

Posting AreaR401

P Priority 1S Priority 2U Priority 3

Posting AreaR401

P Priority 1S Priority 2U Priority 3

Determination ofOutgoing Payment

Methods

Determination ofOutgoing Payment

Methods

Amount LimitCheck

Amount LimitCheck

Checks forOutgoing

Payment Blocks

Checks forOutgoing

Payment Blocks

User ExitEvent R430User Exit

Event R430

Payment Determination: Outgoing

Determination of the outgoing payment method depends on several factors. When the system determines remaining credit during invoicing, the invoicing process tries to enter the suitable outgoing payment method in the print document. This is necessary because information on the repayment method is required at printing time. However, payment methods are not entered in the FI-CA document. The items are reinterpreted during the payment run.

You can enter the customer's desired outgoing payment methods in the contract account (such as postal transfer, or check).

There is a posting area in Customizing for invoicing, where you can define the priorities of the outgoing payment methods to be used for each company code (for example, postal transfer has a higher priority than check or bank transfer).

Amount limits in Customizing or outgoing payment blocks, that may have been set in the contract account, can also influence the determination of the appropriate outgoing payment method.

Determination of the outgoing payment method can also be influenced by a user exit, that is, event R430.

Page 274: IUT 230 billing and invoicing

© SAP AG IUT230 7-26

SAP AG 2006

Tax rate(s) inbillingperiod

Tax rate at time of invoicing

No proration, tax is dependent on point in time:

System date

Posting date

Document date

TaxReference Basis

(Alternative)

Account Determination

Account Determination

Proration of billing line items if tax changes (in billing)

Tax Determination

Using the settings in Customizing for FI-CA, the invoicing process determines the account (posting areas R000 and R001) and the corresponding general ledger accounts.

It also determines the value-added tax. The billing component transfers only net amounts. Value-added tax is determined using the posting area R001.

You can specify whether the tax rate is determined from the billing period or from the tax rate that is valid at the time of invoicing. If you choose to determine taxes based on the time of invoicing, you must also specify which date is to be used: the entry date, document date, or posting date.

In Italy, Spain, and Portugal, for example, the tax is determined on the basis of the billing date. In this type of tax determination, the billing line items are not prorated if there is a tax change.

The tax code for sales and purchases is defined by the tax determination code, the country (from table T001) and the date. The tax code for sales and purchases is also used by other standard components (such as FI, SD) and is defined in the Customizing menu of Financial Accounting under Financial Accounting Global Settings -> Tax on Sales and Purchases -> Calculation -> Define Tax Code for Sales and Purchases.

The tax determination code is defined in the same way as the revenue account determination (posting area R001).

Page 275: IUT 230 billing and invoicing

© SAP AG IUT230 7-27

SAP AG 2006

Item :10.03.99 155.43

10.03.99 0.03 -

Billamount

155.43 SFR 1

~ 155.40 SFR

Currency rounding

One rounding per bill

Rounding

Item :10.03.99 155.43

10.03.99 0.03 -

Billamount

155.43 USD

~ 155.40 USD

Final amount rounding

Rounding carried forward to next bill

Rounding information is stored as print document line items in the print document and have the document line item type ROUND. You can define the rounding rules in the Financial Accounting Customizing menu under Contract Accounts Receivable and Payable -> Basic Functions -> Postings and Documents -> Basic Settings -> Define Rounding Rules for Currencies.

Currency rounding is mandatory in some countries due to the currency used in payment transactions (for example, 5 rappen rounding in Switzerland). This occurs at posting document or posting item level, is a one-off occurrence for each bill, is displayed on the bill and is executed according to rounding rules defined in contract accounts receivable and payable.

Rounding information is stored in the print document as print document line items with the document line item types ROUND (rounding amount current bill) and ROUNDO ( rounding amount from previous bill).

Activate the function in Customizing for SAP Utilities under Invoicing -> Basic Settings -> Define Basic Settings. You can define the rounding rules under Invoicing -> Invoice Processing -> Define Invoice Rounding Rules or Define Rounding Limits for Rounding Amount Carryforward.

Rounding is executed at rounding level; it is considered for the next bill (rounding amount carryforward), displayed in the account and on the bill, activated in invoicing Customizing and is executed according to predefined rounding rules. The rounding balance is cleared when a contract account is finally invoiced.

Page 276: IUT 230 billing and invoicing

© SAP AG IUT230 7-28

SAP AG 2008

Invoicing: 3

Invoicing in SAP Utilities

Invoicing functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 277: IUT 230 billing and invoicing

© SAP AG IUT230 7-29

SAP AG 2006

Bill 4711 Date: 02.01.06

Valuated consumption +_________+_________+_________

Credit memos/backbillings +/-________

Billamount =========

Budget billings paid -__________

Items above +/-________

1. Budget billing +_________Final billamount =========

Sub-items +/-________

Amount to be paid =========

Manual billings are automatically included

Paid budget billing amounts are automatically included and posted (only for statistical budget billing)

Main items (such as payment on account, statistical items) can be included and settled using the settlement control

Settlement against the first or next budget billing

Sub-items can be shown on the bill. No settlement occurs

Item Processing

Manual billings (such as corrections to bills) are automatically included in invoicing. You do not need to make additional settings in Customizing.

Paid budget billing amounts are automatically included and posted in statistical budget billing. In the debit entry procedure, the budget billing amounts remain and are not reposted.

During the invoicing process, FI-CA items can be processed using settlement control. To allow this, you have to configure settlement control accordingly in Customizing. For example, payments on account could be settled against receivables from the annual consumption billing. Cash security deposits should also be settled in a final billing.

You can also use settlement control to settle remaining credit against the first or next budget billing amount.

The due dates of outstanding receivables are not grouped with the first or next budget billing amount as there is nothing to settle (both are receivables). For this reason, the due dates are grouped in a separate Customizing table in invoicing.

Sub-items (open items in the contract account) can be displayed on the bill. However, you must note that these items are not part of the contract accounting document, and still have separate due dates. Therefore, you should check if you really want to include the items in the account balance.

Page 278: IUT 230 billing and invoicing

© SAP AG IUT230 7-30

SAP AG 2006

AdditionalFunctionsAdditionalFunctions

Event: 5010Account

Maintenance Event: 5010

Interest Calc.Cash Security

DepositsEvent: 5010Interest Calc.Receivables

% exp % exp

Open Items:Clearing

03.10.06 150,00 150,00

03.08.06 70,00 50,00

03.22.06 200,00 - 200,00 -

03.19.06 123,00 -

Difference: 0.00

Additional Functions in Invoicing

LPCReceivables

Event: 5010Dunning

LPCInstallm. plan

Debit EntryStat. Item

You can define the following for each settlement type and category:

Account maintenance: you must activate account maintenance in invoicing if you want to use settlement control, such as settlement with the first budget billing amount, settlement of cash security deposits in the final billing, settlement of payments on account.

Interest calculation of debit items in invoicing

Interest calculation of cash security deposits in invoicing

Dunning in invoicing

Charge (LPC - late payment charge) for late items in invoicing.

Charge (LPC - late payment charge) for installment plan items in invoicing.

Debit entry for statistical items in invoicing, such as for dunning charges (only for statistics key G)

Page 279: IUT 230 billing and invoicing

© SAP AG IUT230 7-31

SAP AG 2006

Open Items:Clearing

03.08.06 150.00 150.00

03.10.06 70.00 50.00

03.19.06 200.00 -

03.22.06 123.00 - 123.00 -

Difference: 77.00

Bill 4711 Date: 01.7.2006

Valuated consumption +_________+_________+_________

Credit memos/backbillings +/-________

Billamount =========

Open items on 06.15.06 +/-________

Amount to be paid =========

Dunning in Invoicing

In the course of invoicing the contracts of a contract account, reminders can be sent out for any business partner items which are due to the contract account.

The dunning text has to be taken into account when you create the billing form.

Dunning charges cannot be posted if the dunning is triggered during invoicing.

Dunning in invoicing is mostly used by North American customers, as meter reading and billing generally occur every month.

Page 280: IUT 230 billing and invoicing

© SAP AG IUT230 7-32

SAP AG 2006

IMGIMG

...........

..........

..........

..........

Bill 4711 Date: 02.07.06

Valuated consumption +_________+_________+_________

Credits/backbillings +/-________

Billamount =========

Budget billings paid -__________

Items above +/-________

1. Budget billing +_________Final billamount =========

Sub-items +/- 343.58

Amount to bepaid =========

Please note that your bill of 343.58 USDfrom 05/04/2006, has not yet been paid.

Alternative 1

Alternative 2

Include sub-items (open items) in the balance

Print an informative note about sub-items (open items) on the bill

Selection of Items in InvoicingSelection of items using

clearing type and category, mainand sub-transaction, and interval

Sub-Items

Sub-items are open items that you wish to include in the printed bill. You can print the last unpaid bill on the current bill.

There are two ways of printing the sub-items on the bill:

You include the sub-items in the balance of the bill. In this case, you must make sure to print a new due date for the old open item on the bill (implies that due date is moved forward). This is not permitted in every country and should be verified. Another problem is that the changed due date is not reflected in the account. Programs such as the dunning program continue to use the old due date. Exception: credit memos can, however, be included in the bill balance as they do not have a due date (for example a payment on account).

In this case, information about the open item is printed on the bill, but the open items are not included in the bill balance.

You select the open items to be printed on the bill in the item selection procedure in invoicing.

This table also allows you to deactivate statistical items (such as dunning charges) in invoicing (for example, during final billing).

Page 281: IUT 230 billing and invoicing

© SAP AG IUT230 7-33

SAP AG 2006

Item Selection for Invoicing (Subitems)

Calculate Interest for

Items

Calculate Interest for

Items

Defer ItemsDefer Items

Clearing Without

Subsequent Posting

Clearing Without

Subsequent Posting

TransferTransfer

Debit EntryDebit Entry

Final Bill Amount

Final Bill Amount

ItemsPrint

ItemsPrint

ActionsActions

In "Item Selection for Bill Display" you can select the open items to be printed. You can decide whether or not items are included in the final amount.

You can also trigger various actions for the individual items in invoicing:

Debit entry of statistical items: Once you have activated the debit entry in the additional functions, you can select the items here.

Transfer of items to a credit or receivable for invoicing. For example, you can transfer a cash security deposit to the final bill.

Clearing without subsequent posting: This indicator is recommended for statistical requests (for example, dunning charge or down payment requests), which are to be waived after invoicing.

Defer items: The open item contains the due date for invoicing as a deferral date.

Calculate interest for items: Once you have activated the interest calculation in the additional functions, you can select the items here.

The due date adjustment offers another option for including items in the bill. An open item with the clearing restriction 8 is included during invoicing and is given the same due date as the invoicing.

Page 282: IUT 230 billing and invoicing

© SAP AG IUT230 7-34

SAP AG 2008

Invoicing: 4

Invoicing in SAP Utilities

Invoicing functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 283: IUT 230 billing and invoicing

© SAP AG IUT230 7-35

SAP AG 2008

Invoicing of Different Services

Joint Billing #4711:Bill (#1-#5) 4375 USD- Amt paid (#1-#3) -3600 USDRemainder due: 775 USDDue on 15-Jan-06

Simplifiedrepresentation

without tax!

JointJointInvoicingInvoicing

-- AccountAccount-- Due DatesDue Dates-- OptionalOptional

Account A. SmithBill #4711 775 USDLine items for each receivable:

Bill #1 ...Bill #2 ...

................

Sale #5Radiators 350 USD

Maint. charge #4 Gas heating 45 USD

Other services #3Cable TV 180 USD

Other services #2Waste water 500 USDWaste disposal 200 USD

Cons. billing #1Electricity 1000 USDGas 1500 USDWater 600 USD

You can also include additional services in invoicing.

Page 284: IUT 230 billing and invoicing

© SAP AG IUT230 7-36

SAP AG 2008

Incorporation of Additional Documents

SDbilling doc.

SDbilling doc.

SAP UtilitiesBilling

SAP UtilitiesBilling

SAP UtilitiesInvoicingBilling documentsBilling documents

SD Sales

PM-CSInstallation Services

IS-UUtility

Services

Invoice RequestOptional

Invoicing can process different types of documents:

The type of document that the invoicing program has to process most often is billing documents created in SAP Utilities billing.

It is possible to incorporate SD billing requests (side business, maintenance etc.) in SAP Utilities invoicing and to integrate these with the IS-U bill.

Page 285: IUT 230 billing and invoicing

© SAP AG IUT230 7-37

SAP AG 2008

Integration: SD Billing Document

FI-CA

FI-ARFI-AR

SDbilling doc.

SAP Utilitiesbilling

IS-Ubilling doc.

FI customerFI customer

Contract acct

Billing Request

Acco

unt g

roup

Doc. typePosAr R400

Doc. typePosAr 1210

SD invoicing cat. "U"

SD b

illing

type

Event: R403

The account group of the SD customers controls whether the accounting document is posted in FI-AR or FI-CA.

If the billing category is 'U' in the SD billing type, no document is posted in the SD billing document. Instead an IS-U billing request is generated. The billing request is posted during the next invoicing run and is then billed.

The default settings mean that SD documents cannot be invoiced alone. You can, however, allow this invoicing in event R403. To do this, you must allocate a grouping key other than zero for E_GROUP to the SD documents in the table T_EITR. For further information, see SAP note 924706.

Page 286: IUT 230 billing and invoicing

© SAP AG IUT230 7-38

SAP AG 2008

Invoicing: 5

Invoicing in SAP Utilities

Invoicing functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 287: IUT 230 billing and invoicing

© SAP AG IUT230 7-39

SAP AG 2008

Check pool

Selection of checks to be carried out

Company-specific checks possible

not OK

Billing InvoicingCheck- standard- company-specific

Invoice Printout

Reversal

OK OK

Exception List or WorkflowException List or Workflow

not OK ReleaseRelease Release

Check- standard- company-specific

Outsorting in SAP Utilities

SAP provides a predefined set of checks.

You can check for certain net amount limits, for example after billing. The billing document can be checked, reversed, released, or it can also be billed manually.

After invoicing, you should check for gross amount limits. Credit checks should also be carried out during the invoicing process and not before, as clearing takes place during invoicing (budget billing payments, payments on account, cash security deposits).

The customer can create their own outsorting checks and include them in the billing or invoicing program without modification.

Outsorting can occur after billing or invoicing.

Page 288: IUT 230 billing and invoicing

© SAP AG IUT230 7-40

SAP AG 2006

Net amount checksChecks for budget billing amountsCheck for estimationsCheck for billing line items

Billing InvoicingInvoicingBillingBilling

Gross amount checksCredit checks after settlementBalance forward

Times of Outsorting

Outsorting can occur after billing or invoicing.

Different checks can be carried out according to the time of the outsorting.

On this slide, you can see the checks provided by SAP in the system. For invoicing, these are:

AMOUNT2: Gross billing amount checked against minimum and maximum limitations

AMOUNT3: Final bill amount checked against minimum and maximum limitations

FORWARD1: Balance forward checked against maximum amount for credit memo/ receivable

The customer can also create additional outsourcing checks. The check programs are small ABAP/4 function modules. You can find the following points in the IMG:

Define check pool for invoicing (SAP)

Define outsorting groups for invoicing

Define checks for each outsorting group for invoicing

Define manual bill outsorting for invoicing

Page 289: IUT 230 billing and invoicing

© SAP AG IUT230 7-41

SAP AG 2008

ControldocumentControldocument

ControldocumentControldocument

InvoicingInvoicing

ChecksChecks

Invoicingsto be checked

ReleaseRelease

ReversalReversal Billprintout

Billprintout

Automatic checksAutomatic checks Manual outsortingManual outsorting

Contract accountManual outsorting:

0001 Once

Contract accountManual outsorting:

0001 Once

InvoicingInvoicing

Invoicingsto be checked

ReleaseRelease

ReversalReversal Billprintout

Billprintout

Outsorting Options: Invoicing

The system supports automatic checks. In addition, the clerk can define manual outsourcing in the contract account.

The clerk has to check the outsourced invoiced/printed documents on the screen and can either reverse the invoice or release it to print the bill.

You can use a report to display the outsorted invoicing documents. Alternatively, you can process the outsorted invoicing document in a Workflow. To display the outsorted billing documents, two events (OUTSORTED and RELEASED) are available for the PRINTDOC business object. To process them, the OUTSORTDISPLAY method is available.

Note that in outsorting in invoicing, the invoicing document is a control document, which means the document is not posted in FI-CA. This is necessary because with a real posting FI-CA functions such as payment run and dunning run have access to the posting.

After the control document is released, real invoicing is carried out.

Page 290: IUT 230 billing and invoicing

© SAP AG IUT230 7-42

SAP AG 2006

Outsorting Groups:Invoicing

0001 Res. customer0002 Nonres. cust.

Outsorting Groups:Invoicing

0001 Res. customer0002 Nonres. cust.

Automatic checksAutomatic checks

Contract Account(Individual

setting)

Contract Account(Individual

setting)

Invoicing ChecksOutsorting Group 0001 = Check AMOUNT2Outsorting Group 0002 = Check AMOUNT3

Invoicing ChecksOutsorting Group 0001 = Check AMOUNT2Outsorting Group 0002 = Check AMOUNT3

Outsorting Group: Invoicing

Outsorting groups are always stored individually in the contract account.

Checks are found using a customizing table from the the outsorting group.

Billing is based on contracts while invoicing is carried out for contract accounts. This is why the outsourcing group for invoicing can no longer be defined globally (for example in the rate type). Instead, the outsourcing group is entered in the contract account.

Page 291: IUT 230 billing and invoicing

© SAP AG IUT230 7-43

SAP AG 2008

Invoicing: 6

Invoicing in SAP Utilities

Invoicing functions

Inclusion of Open Items

Integration

Outsorting in Invoicing

Invoice Reversal

Page 292: IUT 230 billing and invoicing

© SAP AG IUT230 7-44

SAP AG 2006

Invoicing Reversalor TotalReversal

Open old budget

billing plan

Delete newbudget billing

plan

Indicate old posting

document

Create reversal document

Indicate old billing document

Invoice Reversal Billing Reversal

Create billing order

Invoicing Reversal Functions

The reversal has to be carried out in a certain sequence. You have to start with the latest document and work backwards to earlier documents.

Page 293: IUT 230 billing and invoicing

© SAP AG IUT230 7-45

SAP AG 2008

-1000.-

.

.

.

Bill reversal

100.-

.

.

.

Bill

Bill

1000.-

.

.

.

Action e.g., changemeter reading result

and redo billing/invoicing

Action e.g., changemeter reading result

and redo billing/invoicing

Billing orderFull Reversal

Reversal Process in Invoicing/Full Reversal

Reversedbilling

document

There are two times at which a reversal is possible in the system. Reversal can occur after billing or invoicing. There are two possibilities for a reversal after invoicing: either a reversal of invoicing, or a full reversal (reversal of invoicing and of billing).

Page 294: IUT 230 billing and invoicing

© SAP AG IUT230 7-46

SAP AG 2008

Invoicing Document

Full bill is not to be reversedFull bill is not to be reversed

Bill DocumentBill Document

Billing Reversal/Adjustment Reversal

Individual reversalof a billing document

Individual reversalof a billing document

In addition to full, billing and invoicing reversal, there is also an adjustment reversal function.

Adjustment reversal enables you to recalculate the time period of the adjustment reversal billing document and thus create a correction bill. It allows you to to recalculate the time period of the adjustment reversal billing document and thus create a correction bill. The billing order is reconstructed and marked with the old billing document number.

Page 295: IUT 230 billing and invoicing

© SAP AG IUT230 7-47

SAP AG 2006

Adjustment ReversalAdjustment Reversal

RebillingRebilling

Changeto

Dataset

Changeto

Dataset

Bill 4711 Date: 06.02.2006

Bill correction

Original document - 50- 70

New document 4060

-------

Total - 20

1

2

Rebilling

When you rebill following an adjustment reversal, the billing lines of the old billing document are entered as negative along with the newly created billing lines. A differential bill is created.

The adjustment reversal can be carried out if, for example, there is only one incorrect billing document in the invoicing document. A full reversal would be unnecessary in this case.

Page 296: IUT 230 billing and invoicing

© SAP AG IUT230 7-48

SAP AG 2006

Bill Correction

Print Document 4

Print Document 3

Print Document 2

Print Document 1

Invoicing Sequence

This document is to be reversed

Reversal Sequence

The bill correction allows you to process multiple reversals in an overview.

All reversal options are integrated:

Full Reversal

Invoicing reversal

Adjustment reversal

Page 297: IUT 230 billing and invoicing

© SAP AG IUT230 7-49

SAP AG 2006

Select billing documents

Set billing block

Create meter reading order

Wait until meter reading document is created

Display meter reading results

Decide if correction should be made

Reverse invoicing

Reversal/adjustment reversal of billing doc.

Correct meter reading results

Steps in the WorkflowWorkflow

starts

Workflow for Bill Complaints

SAP delivers a sample workflow for bill complaints with the system (WS 20500045, ISUBIMRCOR02).

You can use this workflow as a template to create your own workflow.

This workflow is also included in the CIC configuration delivered with the system and is called 'Control reading - bill complaints'.

Page 298: IUT 230 billing and invoicing

© SAP AG IUT230 7-50

SAP AG 2006

Search for billing documents to be reversed

Adjustment reversal of billing document

New estimation of incorrect MR results

Steps in the WorkflowWorkflow

starts

Overestimation of meter reading

results

2006200613.02. 16.03. 15.04.14.01.

Meter Readings:

500read

800estimated

750read

1. Reversal of billing document from Feb 13th2. Reestimation of overestimated meter

reading results from 800 to 625

Workflow Assessment - Meter Overflow in Estimation

SAP delivers a sample workflow for meter overflow in estimation (assessing) with the system (WS 20500105, ISU_ASSESS).

The workflow is started if the event UtilContract.Assessed is triggered (overestimation of meter reading results). The event belongs to the business object ISUCONTRCT (utility contract).

You can use this workflow as a template to create your own workflow.

Page 299: IUT 230 billing and invoicing

© SAP AG IUT230 7-51

SAP AG 2008

Invoicing: Summary

SAP AG

Invoicing creates the link to the Contract Accounts Receivable and Payable (FI-CA) component.

All billing documents of a contract account can be grouped together in one bill (optional).

Invoicing can clear and print contract account items.

Extensive outsorting options are available.

As well as an individual reversal, invoicing and billing can be fully reversed.

Page 300: IUT 230 billing and invoicing

© SAP AG IUT230 7-52

Page 301: IUT 230 billing and invoicing

© SAP AG IUT230 7-53

InvoicingExercises

Unit: Invoicing Topic: Invoicing

Be able to name the differences between billing and invoicing.

Carry out the invoicing procedure.

A customer has made a payment within the current billing period and was billed according to the rate valid up until now. The customer wishes to receive an interim bill. For this, billing and invoicing are started in the system.

1-1 Bill and invoice the business partner TF0701A0## and the contract TF0701A0##.

1-1-1 Use the existing billing order. ____________________________________________________________

1-1-2 Display the print document for this process. ____________________________________________________________

1-1-3 Simulate billing in the document display. ____________________________________________________________

1-1-4 Display the postings in the account balance display. ____________________________________________________________

1-2 Invoice the business partner TF1101A0## and the contract TF1101A0##. In the previous unit, you created a manual billing document for this customer.

1-2-1 Use the existing billing document. ____________________________________________________________

1-2-2 Display the print document for this process. ____________________________________________________________

1-2-3 Simulate billing in the document display. ____________________________________________________________

1-2-4 Display the postings in the account balance display. ____________________________________________________________

Page 302: IUT 230 billing and invoicing

© SAP AG IUT230 7-54

1-3 Check the definition of invoicing outsorting in the Implementation Guide.

1-3-1 Which menu path would you use to define outsourcing in invoicing? ____________________________________________________________

1-3-2 Which outsourcing is maintained for residential customers in the system? ____________________________________________________________

Page 303: IUT 230 billing and invoicing

© SAP AG IUT230 7-55

Exercises

Unit: Invoicing Topic: Reversal

Be able to trigger full reversal of billing and invoicing.

Be able to name the differences and effects of the reversal.

A customer has received a bill and does not agree with the meter reading billed. It is too high due to a bad reading. The bill is fully reversed and recalculated.

2-1 The business partner’s existing bill must be checked and recalculated with the correct meter reading.

2-1-1 Display the last billing document for the business partner TF0703A0## and the contract TF0703A0##.

2-1-2 Use the print document display function. ____________________________________________________________

2-1-3 Trigger a full reversal of the bill (invoicing and billing). Select the reconciliation key TF0703A0##.

2-1-4 Which options are available for carrying out this procedure? List the menu paths. ____________________________________________________________

2-1-5 Change the result of the meter reading. Use the correction function for meter reading results and the installation TF0703A0##. What is the new meter reading? ____________________________________________________________

2-1-6 Carry out the new billing and invoicing procedure with the billing order.

Which document numbers are created by the system (in billing and invoicing)? ____________________________________________________________

Page 304: IUT 230 billing and invoicing

© SAP AG IUT230 7-56

Invoicing

Page 305: IUT 230 billing and invoicing

© SAP AG IUT230 7-57

Solutions

Unit: Invoicing Topic: Invoicing

1-1 Bill and invoice the business partner TF0701A0## and the contract TF0701A0##.

1-1-1 Use the existing billing order.

From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing

Individual Bill.

Do not change the document or posting date. Enter the user IUT230-## in the reconciliation key field. Select yes in the dialog box when you are asked whether you want to create a reconciliation key. In Level of processing, select Display bill. Choose the selection criterion Contract and enter the contract TF0701A0## and a reconciliation key.

Choose Execute.

You will find the document numbers in the log following billing/invoicing.

1-1-2 Display the print document for this process.

From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Display Print Document. Enter the print document number. Select the table overview. Navigate through the various screen areas.

1-1-3 Simulate billing in the document display.

Select Simulate Bill. This function does not produce an original printout. The original printout was already produced in step 1-1-1.

1-1-4 Display the postings in the account balance display.

From the SAP menu, choose Utilities Industry Contract Accounts Receivable and Payable Account

Account Balance.

Choose the selection criterion Business partner and enter the business partner TF0701A0##. Enter the All open items as the list category.

Choose Execute.

Page 306: IUT 230 billing and invoicing

© SAP AG IUT230 7-58

1-2 Invoice the business partner TF1101A0## and the contract TF1101A0##. In the previous unit, you created a manual billing document for this customer.

1-2-1 Use the existing billing document.

From the SAP menu, choose: Utilities Industry Invoicing Execute Invoicing Individual Processing Create Bill. The invoicing process determines that an invoicing order already exists for this business partner. The billing document number is displayed in a dialog window.

1-2-2 Display the print document for this process. From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Display Print Document. Enter the print document number. Select the table overview. Navigate through the various screen areas.

1-2-3 Simulate billing in the document display. Select Simulate Bill.

1-2-4 Display the postings in the account balance display.

From the SAP menu, choose Utilities Industry � Contract Accounts Receivable and Payable � Account � Account Balance.

Choose the selection criterion Business partner and enter the business partner TF1101A0##. Enter the All open items as the list category.

Choose Execute.

1-3 Check the definition of invoicing outsorting in the Implementation Guide.

1-3-1 Which menu path would you use to define outsourcing in invoicing?

In the SAP Reference IMG, choose SAP Utilities Invoicing Invoice Processing Outsorting for Invoicing.

1-3-2 Which outsourcing is maintained for residential customers in the system?

Select checks per outsourcing group for invoicing.

Validation: AMOUNT2 = Gross billing amount with minimum and maximum limitations.

Page 307: IUT 230 billing and invoicing

© SAP AG IUT230 7-59

Solutions

Unit: Invoicing Topic: Reversal

2-1 The business partner’s existing bill must be checked and recalculated with the correct meter reading.

2-1-1 Display the last billing document for the business partner TF0703A0## and the contract TF0703A0##.

2-1-2 Use the print document display function.

From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Display Print Document. Enter the print document number. Select the table overview.

You can also find the bill in the archive. If your local PC is configured accordingly, you can also display the bill from the archive. Another possibility is to simulate the bill. This formats the form using data from the print document.

2-1-3 Trigger a full reversal of the last bill (invoicing and billing). Select the reconciliation key TF0703A0##.

From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Individual Processing Full Reversal.

Select the reconciliation key TF0703A0##. Select the business partner’s document number TF0703A0##. Choose Execute. Also select the billing document for reversal Press Enter to carry out the complete reversal of the invoicing and billing documents.

Page 308: IUT 230 billing and invoicing

© SAP AG IUT230 7-60

2-1-4 Which options are available for carrying out this procedure? List the menu paths.

From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Individual Processing Full Reversal.

From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Mass Processing

Full Reversal.

Two steps for the individual reversal of billing and invoicing.

From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Mass Processing

Reverse Bill.

and

From the SAP menu, choose Utilities Industry Billing Billing Execution Reversal Billing Reversal.

Another option: Adjustment Reversal

From the SAP menu, choose Utilities Industry Billing Billing Execution Reversal Adjustment Reversal.

Another option: Bill correction

From the SAP menu, choose Utilities Industry Billing Billing Execution Bill Correction.

Another option: Workflows for invoice correction and assessing

2-1-5 Change the result of the meter reading. Use the correction function for meter reading results and the installation TF0703A0##. What is the new meter reading?

From the SAP menu, choose Utilities Industry Device Management Meter reading Correction of Meter Reading Results Plausible Results.

Select the business partner TF0703A0##. Select the last reading of the device. Select the reading and choose Continue. Change and save the meter reading.

Page 309: IUT 230 billing and invoicing

© SAP AG IUT230 7-61

2-1-6 Carry out the new billing and invoicing procedure with the billing order.

Which document numbers are created by the system (in billing and invoicing)?

From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing

Individual Bill.

In Level of processing, select Display bill. Choose the selection criterion Contract and enter the contract TF0703A0## and a reconciliation key.

Select Execute You will find the document numbers in the log following billing/invoicing.

Page 310: IUT 230 billing and invoicing

© SAP AG IUT230 7-62

Page 311: IUT 230 billing and invoicing

© SAP AG IUT230 8-1

SAP AG 2006

Fundamentals of clearing control in invoicing

Contents:

Clearing Control

Page 312: IUT 230 billing and invoicing

© SAP AG IUT230 8-2

SAP AG 2006

Describe the purpose of clearing control

Explain the components of clearing control for account maintenance in invoicing

Make the necessary Customizing settings for clearing strategies in invoicing

At the end of this unit you will be able to:

Clearing Control: Objectives

Page 313: IUT 230 billing and invoicing

© SAP AG IUT230 8-3

SAP AG 2006

You have to maintain a new clearing control in the system

This excludes a cash security payment deposit made during periodic billing

This amount has to be cleared with the final bill amount during final billing

Clearing Control: Business Scenario

Page 314: IUT 230 billing and invoicing

© SAP AG IUT230 8-4

SAP AG 2006

Orientation

Every open item, that is every open receivable or payable, must be cleared at some point. There are different procedures that enable you to clear an item. The following are the most common:

Payment: The customer pays his/her receivable

Clearing: Receivables and credit for a contract account or business partner are cleared against each other

Since these clearing processes are normally mass processes, the system must be able to automatically determine payment usage, or automatically create the clearing proposal according to preset rules

Page 315: IUT 230 billing and invoicing

© SAP AG IUT230 8-5

SAP AG 2006

Definition

FI-CA clearing control is a tool for configuring a company's clearing strategy.

It contains rules for an automatic clearing proposal or automatic payment assignment.

By splitting the clearing algorithm into several processing steps and combining a few basic rules, it can configure diverse clearing scenarios flexibly and based on different tables.

Page 316: IUT 230 billing and invoicing

© SAP AG IUT230 8-6

SAP AG 2006

General Overview

Clearing VariantClearing Type Clearing Category

1-n clearing steps

Clearing Proposal

Clearing proposal:

Clearing

10.03.99 150.00 150.00

08.03.99 70.00 50.00

22.03.99 200.00 - 200.00 -

19.03.99 123.00 -

Difference: 0.00

Contract Account

4711

Business Transaction

Open Items

DFKKOP

You can configure clearing control in the Financial Accounting Customizing menu under Contract Accounts Receivable and Payable -> Basic Functions -> Open Item Management -> Clearing Control. You can also find a detailed description of clearing control here.

Page 317: IUT 230 billing and invoicing

© SAP AG IUT230 8-7

SAP AG 2008

The clearing type represents the business transaction.

For example, payment lot, payment at cash desk, periodic invoicing (R41)

The clearing category represents the reference to the contract account. It is stored in the contract account. In this way, different customer groups can have their own clearing categories.

For example, private, commercial and industrial, collectors

The user can freely assign the category.

Basic Terms

Clearing rules are defined based on the clearing type. They can also be made dependent on the clearing category (optional).

Page 318: IUT 230 billing and invoicing

© SAP AG IUT230 8-8

SAP AG 2006

Clearing Variant

The clearing variant is at the center of clearing control. It contains the actual clearing logic for creating a clearing proposal.

The clearing variant makes it possible to split the clearing algorithm into different clearing steps.

The individual clearing steps control:

The open items that are included in clearing

How the items are to be grouped Grouping enables you to process items that meet the same criteria together.

How items are sorted for the analysis and clearing sequence

Amount checks and tolerance analyses

The distribution algorithm within groups for partial clearing

Page 319: IUT 230 billing and invoicing

© SAP AG IUT230 8-9

SAP AG 2008

Determination of Clearing Variants

Clearing Variant05 PY119 PY1

R41 AM1R41 + SAM AM2

Clearing TypePayment lot 05Cash desk 19Periodic invoicing R41

BusinessTransaction

Contract Account Clearing Category

Private STDC&I SONCollector SAM

0815

Optional

Clearing variants are determined depending on the clearing type of the underlying processes and, optionally, on the clearing category of the contract account.

Page 320: IUT 230 billing and invoicing

© SAP AG IUT230 8-10

SAP AG 2006

Clearing Control and Account Maintenance

Bill 4711 Date: 02.1.1999

Valuated consumption +_________+_________+_________

Credit memos/backbillings +/-________

Billamount =========

Paid budget billings -__________=========

Remaining amount +/-_________

Account Billing

1st Budget Billing +________

Other credit/rec. +/-________

Final billamount =========

Sub-Items +/-________

Amount tobe paid =========

Please note that the bill amount for 12.16.2001...

Account maintenance: Clearing the final bill amount with next budget billing or other credit memo/receivable

Print an informative note about sub-items (open items) on the bill

IMGClearing Control

In account maintenance, document items posted during invoicing can be cleared with other open items from the contract account, for example:

Clearing using the first budget billing amount

Clearing cash security deposits in the final bill

Clearing payments on account

Page 321: IUT 230 billing and invoicing

© SAP AG IUT230 8-11

SAP AG 2006

Clearing Control Example

Other open itemsOld bill 10,-New BB 150,-

Open itemsNext budget billing 60.-

InvoicingRec. 400.- Division 01 Cred. 200.- Division 02Cred. 300.- Division 03

Clearing

Other open itemsPayment on account 50.-Cash sec. deposit 500,-

Open itemsCredit 250.-

InvoicingReceivable 300.-

Clearing

Example 1

Example 2

Example 1: Invoicing in IS-U determines credits from consumption valuation. These are to be cleared against other receivables and the next budget billing amount of the contract account during account maintenance triggered by invoicing.

Example 2: Payments on account are to be cleared in invoicing. It should also be possible to clear any cash security deposits during final billing.

Page 322: IUT 230 billing and invoicing

© SAP AG IUT230 8-12

SAP AG 2008

Clearing Steps

Nex

t cle

arin

g st

ep

Nex

t gro

up

Group processingtaking the following into account:

• Sort sequence• Amount-dependent group rules• Tolerance limits • Splitting algorithm for partial

clearing• Customer-specific allocation

Form OI groupsfrom specifications in grouping string

Spec. for subsequent processing• Specifications for next

clearing step• Specifications for completion

of allocation

1-n clearingsteps

. . . .

A clearing variant consists of 1-n clearing steps. The steps are normally executed in the sort sequence defined by their numbers. However, they can also be directly triggered by the clearing rules.

The individual clearing steps inherit the clearing proposal and the remaining open amount from the previous steps.

Items that are completely cleared in a clearing step are not included in subsequent steps.

Rules for the selection, grouping, sorting and amount-dependent allocation of items are stored in the individual clearing steps.

The rules are processed in the following sequence: 1. Item grouping 2. Sorting the groups and items within the groups 3. Applying amount rule to group balance 4. Applying clearing rule for clearing the items in the group ( insofar as these have qualified for clearing acc. to 3)

Items are grouped and sorted according to predefined characteristics. Grouping and sorting strings can consist of up to 5 characteristics that are linked to each other using a logical AND.

Page 323: IUT 230 billing and invoicing

© SAP AG IUT230 8-13

SAP AG 2006

Clearing Control and Account Maintenance

During this process, a clearing document is posted.

The clearing document takes on the origin, document date and posting date from the bill.

The clearing document is entered in the print document with the document identification C (table ERDB).

Items that were already posted before invoicing and cleared are stored in the print document with the document line item ACCMNT.

They are included in the final bill amount.

The clearing document can be reversed independently of the bill reversal, using FI-CA document reversal.

Integrated account maintenance means that document items posted during invoicing can be cleared with other open items from the contract account

Account maintenance is supported in all invoicing processes, with the exception of statistical budget billing requests (clearing type R6).

Page 324: IUT 230 billing and invoicing

© SAP AG IUT230 8-14

SAP AG 2006

Prerequisite: Item Selection

Open items are selected for clearing analysis in the table Item Selection for Account Maintenance (TE514).

Items are selected depending on the clearing type of the invoicing unit and, amongst other factors, according to the transaction and due date of the item.

This table is interpreted in the same way as the table for selecting items for bill display (TE529). You can override the proposal created via table TE514 using the customer-specific event OIs for account maintenance (R401).

Caution: Open item selection only determines whether they are included in the clearing analysis. The actual decision whether the items are (partially) cleared ismade based on the clearing variant that is allocated to the clearing type.

You maintain the Item Selection for Account Maintenance table (TE514) in Customizing for SAP Utilities under Invoicing -> Invoicing Processing -> Selection of Items in Invoicing -> Define Item Selection for Account Maintenance.

Account maintenance is activated in table TE502, Central Control of Additional Invoicing Functions, according to clearing type and category.

Caution: In contrast to item selection using table TE529, the selection specifications in table TE514 refer to document items that have already been posted as well as posting items that have recently been created in invoicing.

Recommendation: To guarantee the consistency of the bill display, the open items selected should form a partial quantity of the selected sub-items for account maintenance. This is because the items selected using TE514 are only displayed in the bill if they have already been (partially) cleared.

Page 325: IUT 230 billing and invoicing

© SAP AG IUT230 8-15

SAP AG 2008

Item Selection

OISel Open item selection, , = all items '2' = Items of contracts to be invoiced'4' = items from completed contracts '9' = no items, and so on

Print int. Interval days for due item

00050 BB amount for stat. procedure

000020/0010 Cash security deposit payment

Table TE514: Item Selection for Account Maintenance

0010

SubTrans

14STD

9

21

IntervalOISel

0050STD

Main-Trans.

Clear. type

Application Area

Clearing Type

R - utility company

R41 - periodic billing

STD 0020

The fields clearing type, clearing category, main and subtransaction make up the key for table TE514.

The selection can be set at different levels:From the specification of the clearing category, main and subtransactions of the items to be selected, to general selection with unspecified clearing category, main and subtransactions. As a result, the control table is read repeatedly to determine the selection criteria.

The selection rule (field OISel) specifies the items to be selected. You can include a variety of different values (not mentioned here).

The print interval determines the items to be included based on whether or not they are due (based on the document date of invoicing). Caution: If you do not enter an interval, it is interpreted as 0. As a result, only items due on the invoicing document date are selected.

For a more detailed description of the individual fields, see the documentation on the IMG activity: Item Selection for Account Maintenance/Define Sub-Items.

Page 326: IUT 230 billing and invoicing

© SAP AG IUT230 8-16

SAP AG 2008

The following applies for the clearing category STD in the periodic bill (R41):

1. Only items that are due in the next 14 days (from document date) at the latest are selected

2. The next budget billing amount (main transaction 0050) is cleared when it is due in the next 21 days.

3. The cash security deposit payment (transaction 0200 0100) is not selected

Clearing Control and Account Maintenance: Example

OISel Selection of open items‚ ‚ = all items'9' = no items

Interval Interval days for due item selection

0010

SubTrans.

14STD

9

21

IntervalOISel

0050STD

MainTrans.Clear. type

Application Area

Clearing Type

R - utility company

R41 - periodic billing

STD 0020

The table is read up to four times for each open item in order to find an entry. The following criteria is used for the search:

Access using a fully qualified key consisting of the clearing type, clearing category, main and sub-transactions.

Access using an unspecified sub-transaction

Access using an unspecified sub- and main transaction

Access using an unspecified sub-transaction, main transaction and clearing category

The entry that is found first of all is used for the selection.

Once a valid entry has been found for an open item, the system decides whether the item is included in clearing based on the selection rule and the interval days.

If the system cannot find a table entry for an item, the item is excluded from selection.

Page 327: IUT 230 billing and invoicing

© SAP AG IUT230 8-17

SAP AG 2008

Characteristics in Clearing Control

Characteristics normally describe certain characteristics of an item (such as item is payment on account, or due) or events (such as the payment is made by entering the document number)

Characteristics do the following:

Group open items. Open items that have identical grouping characteristic values in a clearing step are regarded as a unit (for example, all items that belong to the same company code)

Specify (filter) the items that are processed in the clearing step (for example, only due items, or company code 0001)

Specifies (switch) the condition required if a clearing step is to be executed (for example, only execute the step if the payment was made by entering a document number)

Sorts open items Sorting determines the sequence in which the groups are processed and the sequence of clearings within the group.

Page 328: IUT 230 billing and invoicing

© SAP AG IUT230 8-18

SAP AG 2006

Derivation of Characteristics I

Example: Characteristic 001 'company code'

The characteristic refers to the original field FKKOP- BUKRS. As a result, the value for this characteristic is transferred directly from the open item field BUKRS.

01.31.03

11.10.02

10.10.02

12.10.02

FAEDN

4000021

3000023

6000034

50

BETRW...

00012

BUKRSOPBEL

T_FKKCLCharacteristic 001

Direct transfer

0002

0002

0003

0001

VALUE

GROUP 3

GROUP 2

GROUP

2

3

4

1

OPBEL

For example, OI'sgrouped

characteristic 001

GROUP 1

Company Code

Page 329: IUT 230 billing and invoicing

© SAP AG IUT230 8-19

SAP AG 2006

Derivation of Characteristics II

Example: Characteristic 010 'due date'

The characteristic refers to the original field FKKOP- FAEDN. As a result, the value for this characteristic is transferred directly from the open item field FAEDN.

01.31.2003

11.10.2002

10.10.2002

12.10.2002

FAEDN

401

303

604

50

BETRW...

2

...OPBEL

Characteristic 010

Direct transfer

2002 12 10

2002 11 10

2003 01 31

2002 10 10

VALUE

20030131

20021210

20021110

20021010

SORT

2

1

4

3

OPBEL

For example, OIsgrouped

characteristic 010

SOR

T

Due Date

Page 330: IUT 230 billing and invoicing

© SAP AG IUT230 8-20

SAP AG 2008

Example: Account Maintenance I

Clearing all items according to due date

3011.15.02CreditBill.Elec.4711

6012.05.02DebitBBReq.Elec.4712

10

Amnt

09.15.02

Due Date

Rec.Bill.Elec.4710

SubTransMainTransDiv.Document

40

0

0

Open

30

20

10

Clearing

If no characteristics are entered in the grouping string, all items

are processed in one group

Example 1

Clearing variant V01

V01

Characteristic

Grouping string

Step 1

12...

Sort characteristic

010 due date

Sorting string

12...

Example: Since a characteristic has not been entered, the open items from documents 4710, 4711 and 4712 form a group.

Within the group, the items are sorted according their due dates.

The bill credit (30.- USD) is calculated step-by-step in the following way:

The bill receivable for 10.- USD from Sept. 15th is first of all cleared.

The remaining credit of 20.- USD is cleared against the budget billing request from December 12, 2002. The budget billing request remains open at 40.- USD.

Page 331: IUT 230 billing and invoicing

© SAP AG IUT230 8-21

SAP AG 2008

Example: Account Maintenance II

020

900

600

6535

0

0

0

Open

30

10

25

Clearing

Example 2

2010.22.02PymntPymnton Acct

4710

3011.15.02CreditBill.Elec.4711

10011.15.02Rec.Bill.Gas4711

9012.05.02DebitBBReq.Gas4712

10,-05.12.02CreditBBReq.Gas4712

6012.05.02DebitBBReq.Elec.4712

25

Amount

09.15.02

Due Date

Rec.Bill.Elec.4709

SubTransMainTransDivisionDocu-ment

Clearing open items, which have not been grouped together correctly produces the wrong clearing results!

V01

Clearing variant V01

Characteristic

Grouping string

Step 1

1

Sort characteristic

010 due date

Sorting string

1

Example: Since a characteristic has not been entered, the open items from documents 4709, 4710, 4711 and 4712 form a group.

Within the group, the items are sorted according their due dates.

The clearing algorithm produces the following processing steps:

The payment on account of 20.- USD is cleared against the bill receivable from Sept. 15, 2002

This is completely cleared using the bill credit from November 15, 2002.

The remaining credit of 25.- USD can be used for partially clearing the bill receivable from November 15, 2002, in the division gas.

The budget billing repayment request (10 USD) is cleared against the remaining bill receivable in the gas division dated from September 15, 2002. The remaining receivable from the bill 4711 is still 65.- USD.

Page 332: IUT 230 billing and invoicing

© SAP AG IUT230 8-22

SAP AG 2008

Example: Account Maintenance III

Example 3: Clearing in 2 steps

010

200

900

5010

7030

60

0

25

Open

30

0

0

Clear.

1005.12CreditBBReq.Gas4712

2022.10PymntPymnton Acct

4710

3015.11CreditBill.Elec.4711

10015.11Rec.Bill.Gas4711

9005.12DebitBBReq.Gas4712

6005.01DebitBBReq.Elec.4712

6005.12DebitBBReq.Elec.4712

25

Amount

15.09

Due

Rec.Bill.Elec.4709

SubTransMainTransDivisionDocu-ment

00

020

900

500

700

60

0

5

Open

0

0

20

Clear.

Step 1 Step 2

Characteristic

Grouping string

Clearing step 1

1

Sort characteristic

010 due date

Sorting string

018 doc. number

2 010 due date 21

Characteristic

Grouping string

Clearing step 2

1Sort characteristic

010 due date

Sorting string

2 2

1

Example: Clearing step 1 produces the following processing steps. Document number and due date are entered as characteristics. As a result, the following groups are created: Group 1: Open item document 4709 Group 3: Open item document 4711 Group 2: Open item document 4710 Group 4: Open item document 4712 with the due date in December 5th. Group 5: Open item document 4712 with due date January 5th The following clearing steps are executed: Clearing step 1 No clearing in groups 1, 2 and 5. In group 3, the credit of 30 USD from the division electricity is cleared against the gas receivable of 100 USD so that a receivable of 70 USD is left. In group 4, the budget billing repayment requests from December 5th are balanced so that a budget billing amount of 140 USD is due on December 5th. Clearing step 2 No further characteristics have been specified. As a result, all items still open are grouped together. The payment in account of 20 USD can still be used for clearing and is used for clearing the bill that has been open for the longest amount of time. There is still a receivable of 5 USD.

Page 333: IUT 230 billing and invoicing

© SAP AG IUT230 8-23

SAP AG 2006

Clearing Control Strategy: Account Maintenance

Clearing :

03.10.99 150.00 150.00

03.08.99 70.00 50.00

03,22.99 200.00 - 200.00 -

03.19.99 123.00 -

Difference: 0.00

FKKKOP

All items sorted according to due date

Division 1 Division 2 Division 3

Doc. 1Due date 1

Doc. 1Due date 2

Document nDue date m

Step 1

Step 3

Step 2

Clearing strategy for account maintenance

In account maintenance, the following strategy normally applies:From the detailed to the general view. That is, the clearing variant starts with a detailed grouping in the first step, and generalizes this with each subsequent step.

In contrast to payment assignment, clearing processing in account maintenance is only done within a contract account's previously entered open items.

In account maintenance, it is, therefore, not normally a good idea to assign items according to exact amounts. Here, strategy concepts such as clearing sequence and clearing within certain groups (such as company code- or division-based) with permitted partial clearance play a more important role.

In account maintenance, the following strategy normally applies:From the detailed to the general view. The clearing variant starts with a detailed grouping in the first step that becomes more general with each subsequent step.

A clearing variant designed for payment assignment is not suitable for account maintenance.

Page 334: IUT 230 billing and invoicing

© SAP AG IUT230 8-24

SAP AG 2008

Tips for Clearing Control

This includes a clearing variant for:

Payment allocation

Account maintenance

Clearing original items from an installment plan

Clearing original items from a collective bill

Clearing individual items from a summarization group

Each area of use has a different clearing strategy. As a result, each area of use should be given its own clearing variant.

Recommendation: As a rule, different clearing variants can be used for each clearing type and clearing category. However, it generally makes sense to use the same clearing clearing variant(s) in all clearing types of payment allocation (payment lot, cash desk...). This also applies to account maintenance clearing types.

Page 335: IUT 230 billing and invoicing

© SAP AG IUT230 8-25

SAP AG 2006

Explain the clearing control components

Carry out the settings required for creating a completely new clearing control (with the emphasis on invoicing)

Maintain clearing control in Customizing

Notice different business processes in invoicing, and in doing so, control the processing of open items

You are now able to:

Clearing Control: Summary

Page 336: IUT 230 billing and invoicing

© SAP AG IUT230 8-26

Page 337: IUT 230 billing and invoicing

© SAP AG IUT230 8-27

Exercises

Unit: Clearing Control Topic: Mapping a Clearing Strategy

At the conclusion of these exercises, you will be able to:

Describe the elements of clearing control for account maintenance in invoicing

Make the appropriate settings in Customizing

Test these settings

You want to create a new clearing strategy. You want to process a partially cleared payment of a cash security deposit in different ways, based on the billing process used - Within the framework of a periodic bill, the remaining open amount has to be printed on the bill.

- When the customer moves out, the cash security deposit payment that has been made has to be cleared against the final bill amount, and the unpaid cash security deposit request has to be reversed.

1-1 Using the SAP reference IMG, find out the information you need to meet the above requirements.

In the SAP menu, choose Tools Customizing IMG Edit Project.

1-1-1 Enter the menu path for maintaining clearing control.

___________________________________________________

___________________________________________________

1-1-2 Create a new clearing category (GR##, ## is your group number) with the name: Clearing category group ##. ___________________________________________________

___________________________________________________

Page 338: IUT 230 billing and invoicing

© SAP AG IUT230 8-28

1-1-3 What are the clearing types for Periodic Billing and Final Billing: Contract Account (move-out) for the utilities industry application area?

Appl.area

Clearing type Name

1-1-4 Determine the default clearing variant allocated to the two clearing types (invoicing specifications).

Appl.area

Clearing type Clearing Variant

1-2 Now maintain the data for item selection in invoicing.

1-2-1 Enter the menu path for maintaining item selection in invoicing.

_________________________________________________

_________________________________________________

1-2-2 In this activity, what are the two functions you can define item selection in invoicing for?

_________________________________________________

_________________________________________________

1-2-3 The selection of items to be considered depends on the clearing type. What other selection options can you use for detailed clearing selection?

_________________________________________________

_________________________________________________

_________________________________________________

Page 339: IUT 230 billing and invoicing

© SAP AG IUT230 8-29

1-2-4 Select the activity for maintaining item selection for bill printout. You want to display all open items that are due in the next 14 days (from the document date), at the latest, in a periodic bill for the clearing category GR##. These items are not to be included in the final bill amount. - With the exception of the unpaid cash security deposit requests (transaction 0020 0020). Print these and include them in the final bill amount. - Do not print the cash security deposit payment (payment 0020 0010). Make the appropriate settings. _________________________________________________

_________________________________________________

_________________________________________________

1-2-5 Go to Item Selection for Account Maintenance. You want to do the following in a periodic bill for the clearing category GR##: - Clear all open items - Not clear the cash security deposit payments (transaction 0020 0010) Make the appropriate settings. _________________________________________________

_________________________________________________

_________________________________________________

1-2-6 Check the system settings in the Customizing menu for SAP Utilities under Invoicing Invoice Processing. You have to activate the additional invoicing function Account Maintenance for the clearing category GR##. Make the appropriate settings. _________________________________________________

_________________________________________________

_________________________________________________

1-3 Test your settings.

To do this, you must first of all allocate the new clearing category GR## to the contract account of business partner TF1401A0##.

1-3-1 Go to the SAP menu and select Utilities Industry Business Master Data Contract Account Change. In the clearing category, select the entry clearing category group ##.

_________________________________________________

_________________________________________________ Save your entries.

Page 340: IUT 230 billing and invoicing

© SAP AG IUT230 8-30

1-3-2 Display an overview of all posted items for business partner TF1401A0##. Display all items in the account balance display of contract accounts receivable and payable. Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. What and how many items exist for the business partner?

_________________________________________________

_________________________________________________

_________________________________________________

1-3-3 Execute periodic billing and invoicing for business partner TF1401A0##. In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill.

Field Name

Bill to 01.04.2004

Document date 01.04.2004

Posting date 01.04.2004

Reconciliation key TF1401A0##

Contract account TF1401A0##

Enter billing order/ME results X

Scheduled meter reading date 19.03.2004

Meter reading reason 01

Enter Invoice as the processing level and execute individual billing. Enter and save plausible meter readings.

_________________________________________________

_________________________________________________

_________________________________________________

1-3-4 Make sure billing and invoicing were successful. Analyze and check the print document that has been created. How many individual lines does the document have? _________________________________________________

_________________________________________________

_________________________________________________

Page 341: IUT 230 billing and invoicing

© SAP AG IUT230 8-31

1-3-5 Display the changes that have occurred after invoicing in the account balance display for contract accounts receivable and payable. Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. How many items have been added?

_________________________________________________

_________________________________________________

_________________________________________________

1-4 When the customer moves out, the cash security deposit payment has to be cleared with the final bill amount, and the unpaid cash security deposit request reversed. To do this, you have to make further entries in Customizing. Call up the SAP reference IMG in the SAP menus under Tools Customizing IMG Edit Project.

1-4-1 Select Item Selection in Bill Printout. In the final bill, you want to display all open items on the bill for the clearing category GR##. However, the following items should not be displayed in the final bill amount: - The unpaid cash security deposit requests (transaction 0020 0020) - Transfer post the cash security deposit payment (transaction 0020 0010) to a bill credit and include in the final bill amount Make the appropriate settings. _________________________________________________

_________________________________________________

_________________________________________________

1-4-2 Select the Item Selection for Account Maintenance. You want to enable all items to be cleared in a final bill for the clearing category GR##. Make the appropriate settings. _________________________________________________

_________________________________________________

_________________________________________________

1-4-3 Execute a move-out (move-out date is today’s date) for business partner

TF1401A0##. In the SAP menu, select: Utilities Industry Customer Service Process Execution Move-Out Create. Enter plausible meter readings

and save the move-out document.

_________________________________________________

_________________________________________________

_________________________________________________

Page 342: IUT 230 billing and invoicing

© SAP AG IUT230 8-32

1-4-4 Execute final billing and invoicing for business partner TF1401A0##. In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill.

Field Name

Bill to Today’s date

Document date Today’s date

Posting date Today’s date

Reconciliation key TF1401A0##

Contract account TF1401A0##

Enter Invoice as the processing level and execute individual billing.

_________________________________________________

_________________________________________________

_________________________________________________

1-4-5 Make sure billing and invoicing were successful. Analyze and check the print document that has been created. How many individual lines does the document have? _________________________________________________

_________________________________________________

_________________________________________________

1-4-6 Display the changes that have occurred after invoicing in the account balance display for contract accounts receivable and payable. Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. How many items have been added?

_________________________________________________

_________________________________________________

_________________________________________________

What has happened to the item unpaid cash deposit request?

_________________________________________________

_________________________________________________

_________________________________________________

Page 343: IUT 230 billing and invoicing

© SAP AG IUT230 8-33

Solutions

Unit: Clearing Control Topic: Mapping a Clearing Strategy

1-1

From the SAP menu, choose Tools Customizing IMG Edit Project.

1-1-1 In the SAP reference IMG, select Financial Accounting Contract Accounts Receivable and Payable Basic Functions Open Item Management Clearing Control

In clearing control, you map the automatic allocation and clearing strategy for your company. You can define this in different ways depending on the contract account and the clearing business process. Selection rules and clearing variants form the basis of clearing control. Selection rules define what is cleared; clearing variants define it is cleared.

1-1-2 To create a new clearing category, go to the SAP reference IMG menu and select, Financial Accounting Contract Accounts Receivable and Payable Basic Functions Open Item Management Clearing Control Define Clearing Categories Select New Entries and enter the information from the exercise. Save your entries. Clearing categories are used together with clearing types to determine clearing variants. Clearing categories are defined in the contract account. As a result, you can use the clearing category to allocate individual clearing rules to different customer groups, such as household, industry and public institutions.

1-1-3 Select the Customizing activity Define Clearing Types

Appl.area Clearing type Name

R

R41 Periodic Billing

R

R43 Final billing contract account (move-out)

The clearing type represents the business transaction in which items are allocated or grouped for clearing postings. Clearing types are structured according to their areas of use (for example, incoming payment, account maintenance).

Page 344: IUT 230 billing and invoicing

© SAP AG IUT230 8-34

1-1-4 In order to analyze the allocated clearing variant, go to the SAP reference IMG and select Financial accounting Contract Accounts Receivable and Payable Basic Functions Open Item Management Clearing Control

Define Specifications for Clearing Types Define Specifications for Invoicing

Appl.area Clearing type Clearing Variant

R

R41 040

R

R43 040

Specifications are maintained according to areas of use for the clearing types: - Incoming payment specifications - Account maintenance specifications - Specifications for collective bills/installment plans, and so on - Invoicing specifications (IS-U).

1-2

1-2-1 To maintain the item selection in invoicing, go to the SAP reference IMG and select SAP Utilities Invoicing Invoice Processing Item Selection in Invoicing Item Selection in Account Maintenance/Define Sub-Items.

Posting documents created within the framework of the current invoicing of contract billing (minus possible budget billing repayments) are a fixed part of an invoicing/print document. In addition to this, open items that were (partially) cleared during account maintenance in invoicing are displayed in the print document. This activity determines which items are considered for clearing.

1-2-2 In this activity, you define the item selection for: 1. Account maintenance in invoicing (table TE514) 2. Bill display (sub-items, table TE529)

1-2-3 A selection can be set at different levels: From a detailed selection with the specification of clearing category, main and subtransaction of items to be selected, to a general selection with unspecified clearing category, and main and subtransactions.

Page 345: IUT 230 billing and invoicing

© SAP AG IUT230 8-35

1-2-4 The table must contain the following settings.

Item selection for bill printout TE529

Application area: Utilities industry

Clearing type R41

Clear. Cat.

MainTrans. SubTrans. OISel PrintInt. PD Rsum Umb Kb

GR## 14 X

GR## 0020 0010 9

GR## 0020 0020 X X

1-2-5 The table must contain the following settings.

Table TE514: Item Selection for Account Maintenance

Application area: Utilities industry

Clearing type R41

Clear. Cat.

MainTrans. SubTrans. OISel Inter.Days

GR##

GR## 0020 0010 9

1-2-6 You maintain all additional functions in invoice processing in the Utilities

Customizing menu under SAP Utilities Invoicing Invoice Processing Define Control of Additional Invoicing Functions. Maintain the following entries here:

ClearType Clear.Cat. ActMain.

R41 GR## X

R43 GR## X

Page 346: IUT 230 billing and invoicing

© SAP AG IUT230 8-36

1-3

1-3-1 Carry out the instructions set in the exercise.

1-3-2 Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. What and how many items exist for the business partner? The business partner has three items in their contract account: 1) Cash security deposit payment of 150.- 2) Cash security deposit request of 150.- (both items are cleared with the same document number) 3) Open cash security deposit request of 50.- Select the document number of the cash security deposit request. To display the security deposit, select Environment Document Cash Security Deposits. The current status is partially paid, and there is a requested amount of 200.-.

1-3-3 In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill. Enter the data from the exercise.

Choose Execute.

Select the register and choose estimate. Save the meter reading result.

1-3-4 Check the log after billing and invoicing. Call up the list by double-clicking on the last entry. You can find the print document number for the invoicing unit in the detailed display.

From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Display Print Document.

Enter the print document number in the print document field.

Choose single lines.

Choose the tab page Doc. Overview. The first three line items correspond to the billing document line items. The fourth line item is the VAT line added during invoicing. The fifth line item is the sub-item (unpaid cash deposit request). Note the columns BillTotal (consider items in bill sum total), LineItmTyp (document line type) and Print-rel. (bill line is relevant for printing).

1-3-5 Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance.

One item has been added. It is the line item with the transaction text receivables consumpt.

Page 347: IUT 230 billing and invoicing

© SAP AG IUT230 8-37

1-4

1-4-1 The table must contain the following settings.

Item selection for bill printout TE529

Application area: Utilities industry

Clearing type R43

Clear. Cat.

MainTrans. SubTrans. OISel PrintInt. PD Rsum Umb Kb

GR## X

GR## 0020 0010 X X

GR## 0020 0020 X

1-4-2 The table must contain the following settings.

Table TE514: Item Selection for Account Maintenance

Application area: Utilities industry

Clearing type R43

Clear. Cat.

MainTrans. SubTrans. OISel Inter.Days

GR## 999

1-4-3 In the SAP menu, select: Utilities Industry Customer Service Process

Execution Move-Out Create. Enter the business partner number TF1401A0## in the business partner field. Select Create Move-Out. To enter the meter readings in the move-out document, select the tab page meter reading data. Select the line item and choose estimate.

Save the move-out document.

1-4-4 In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill. Enter TF1401A0## in the contract account field. Select the processing level invoice. Choose Execute.

Page 348: IUT 230 billing and invoicing

© SAP AG IUT230 8-38

1-4-5 From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Display Print Document. Enter the print document number in the print document field.

Choose single lines.

Choose the tab page Doc. Overview. The first three line items correspond to the billing document line items. The fourth line item is the VAT line added during invoicing. The next two lines display the cash security deposit payment of 150, which was cleared within the account maintenance, and the subitem (Periodic Billing Not Paid). Note the columns Items BST (consider items in bill sum total), LineItmTyp (document line type) and Print-rel. (bill line is relevant for printing).

1-4-6 Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance.

The partially cleared ‚unpaid cash security deposit request’ has been reversed. The item for the final bill has been added and the cash deposit payment cleared.

Page 349: IUT 230 billing and invoicing

© SAP AG IUT230 9-1

SAP AG 2008

Budget Billing Amounts

SAP AG 2007

Budget billing procedure

Budget billing amountsBudget billing functions

Budget billing plan

Budget billing cycles

Budget billing due dates

Budget billing printout

Budget billing settlement

Page 350: IUT 230 billing and invoicing

© SAP AG IUT230 9-2

SAP AG 2006

Budget Billing: Unit Objectives

SAP AG 2006

At the conclusion of this unit, you will be able to:

Describe the different budget billing procedures

Describe the budget billing functions

Create a budget billing plan and change budget billing amounts

Explain the processes behind the budget billing printout

Describe budget billing settlements

Page 351: IUT 230 billing and invoicing

© SAP AG IUT230 9-3

SAP AG 2006

Budget Billing/Partial Bill: Business Scenario

Maintain billingmaster data

Use of rates in master

dataInvoicing Bill printoutBilling

Budget Billings

Additional functions:Additional functions:Discounts/surchargesDiscounts/surchargesManual billingManual billingSales statisticsSales statisticsSpecial billing featuresSpecial billing features

The scenario in this unit deals with changing an existing budget billing plan.

A customer phones up to change his budget billing amount because the number of people living in the household has changed.

Page 352: IUT 230 billing and invoicing

© SAP AG IUT230 9-4

SAP AG 2006

Budget Billing: 1

Budget billing procedure

Budget billingsBudget billing functions

Budget billing plan

Budget billing cycles

Budget billing due dates

Budget billing printout

Budget billing settlement

Page 353: IUT 230 billing and invoicing

© SAP AG IUT230 9-5

SAP AG 2008

Statistical Budget Billing Procedure

Partial Billing Procedure

AMB - Average Monthly Billing

BBP - Budget Billing Plan

Payment Scheme

Statistical Budget Billing Procedure

Partial Billing Procedure

AMB - Average Monthly Billing

BBP - Budget Billing Plan

Payment Scheme

Budget Billing Procedure

In the statistical procedure, the budget billing amounts are not posted as debits until they are paid by the customer.

In the partial bill procedure, the individual amounts are posted directly as debits.

In the budget billing plan, an average amount is determined either by simulation or manually. The customer pays this average amount for a period of 12 months. At the end of this period, a new simulation is run for the next period. In addition, actual consumption is calculated monthly, and the results are printed on the bill. In addition, the difference between the customer's actual consumption and the average amount is calculated, updated monthly, and printed on the bill. In the last month of the billing period, the actual amount and the accumulated difference are billed.

In average monthly billing/equalized billing, the customer is charged an average amount based on billings over the last 12 months (or less in the case of new customers). In addition, actual consumption is calculated monthly, and the results are printed on the bill. The amounts due for later months are calculated using the average of the previous (maximum 11) months plus the current bill and the accumulated difference. This difference is updated monthly and is also printed on the bill. In final billing, the amount due is derived from the actual consumption and the accumulated difference.

In the payment scheme, the bill amount from the latest billing is copied to the next budget billing plan. This means that the bill amount need not be cleared through a direct payment. The budget billing amount is made up of a portion of the bill and a portion of the extrapolation for the subsequent budget billing periods.

Page 354: IUT 230 billing and invoicing

© SAP AG IUT230 9-6

SAP AG 2006

Budget Billing PlanDue Date Amount

11.15.2006 USD 15012.15.2006 USD 15001.15.2007 USD 15002.15.2007 USD 15003.15.2007 USD 15004.15.2007 USD 15005.15.2007 USD 15006.15.2007 USD 15007.15.2007 USD 15008.15.2007 USD 15009.15.2007 USD 150

Account Balance Display

11.15.2006 15012.15.2006 15001.15.2007 15002.15.2007 15003.15.2007 15004.15.2007 15005.15.2007 15006.15.2007 15007.15.2007 15008.15.2007 15009.15.2007 150

1. Request budg. billing2. Print report1. Request budg. billing2. Print report Budget

BillingRequest

Statistical Items

PaymentGenerates actualitems and value-added tax posting(actual charges)

Transfers paid budgetbilling amounts

Invoicing

Statistical Budget Billing Procedure

Budget billing amount due dates are administered in a budget billing plan.

The budget billings can be displayed as statistical postings (that is, they are not posted to the general ledger) in the account balance display immediately (for example, after the budget billing plan has been created).

The budget billing amounts can be printed, by due date, for example. To do this, first start the budget billing request report. This report generates the print documents that form the basis for the print report. After that, start the print report, which generated the actual bills for budget billing.

When payment occurs, the budget billing amount is first posted. This includes value-added tax.

During invoicing, the budget billing plan is deactivated and the paid budget billing amounts are transferred.

Page 355: IUT 230 billing and invoicing

© SAP AG IUT230 9-7

SAP AG 2006

1. Create Partial Bill2. Print Report1. Create Partial Bill2. Print Report Budget

BillingBill

Account Balance Display

11.15.2006 150

Actual Items

PaymentClears the itemsonly. Value addedtax already posted

Partial bills arereposted

Invoicing

Partial Bill Procedure

Budget Billing PlanDue Date Amount

11.15.2006 USD 15012.15.2006 USD 15001.15.2007 USD 15002.15.2007 USD 15003.15.2007 USD 15004.15.2007 USD 15005.15.2007 USD 15006.15.2007 USD 15007.15.2007 USD 15008.15.2007 USD 15009.15.2007 USD 150

Create Partial BillCreate Partial Bill

Budget billing amount due dates are administered in a budget billing plan.

The budget billing amounts cannot be displayed immediately (for example after you have created the budget billing plan) in the account balance display. In the partial bill procedure, the budget billing plan is administered in a shadow table, which is not used by FI-CA.

The item is not transferred in FI-CA until the Enter partial bill report is started (debit entry procedure). This is the first posting with value-added tax. This report must be scheduled periodically, even if you do not want to print any partial bills. In addition, this report generates the print documents that form the basis for the partial bill printout, should it be required.

The budget billing amounts can be printed, by due date, for example. To do this, start the print report after the Enter partial bill report has run. This generates the physical partial bill.

During payment, only open items are cleared. No changes are made to the value-added tax posting. It was already posted.

During invoicing, the budget billing plan is deactivated and the posted partial bills are transferred.

Page 356: IUT 230 billing and invoicing

© SAP AG IUT230 9-8

SAP AG 2006

The Average Monthly Billing (AMB) and Budget Billing Plan (BBP) payment plan procedures are used mainly in the North American market for monthly meter readings/billing

Customers use these payment plans to even out the monthly payments to their utility companies

In the AMB procedure, the amount to be paid monthly is a calculated average amount. A customer using a BBP procedure pays the same monthly amount for the entire 12 months

The difference between the billing amount and the AMB/BBP amount is updated in a separate item (balance forward)

Payment Plan Procedure AMB/BBP

Page 357: IUT 230 billing and invoicing

© SAP AG IUT230 9-9

SAP AG 2006

AMB Amount

HistoricalBilling Documents

First AverageAmount

End of period:Remaining clearing amount

Date Billamount

AMBamount

Balanceforward

01.20.2006

02.19.2006

03.21.2006

04.20.2006...

100

110

85

80...

92

95

93

91...

8

23

15

4...

Average Monthly Billing (AMB) Procedure

In an AMB procedure, the customer pays an average amount every month. The amount is calculated from the last n months (generally 12 months).

The AMB amount can differ from month to month.

The balance forward becomes smaller and smaller as the end of the period approaches. In the AMB procedure, the remaining amount to be paid at the end of the period is less than the amount in the BBP procedure.

Depending on the Customizing settings, the customer only has to pay the AMB amount or the AMB and balance forward amount at the end of the period.

Page 358: IUT 230 billing and invoicing

© SAP AG IUT230 9-10

SAP AG 2006

BBP Amounts

AverageAmount per Month

End of period:Remaining clearing amount

Date Billamount

BBPamount

Balanceforward

01.20.2006

02.19.2006

03.21.2006

04.20.2006...

100

110

60

100...

80

80

80

80...

20

50

30

50...

HistoricalBilling Documents

Budget Billing Plan (BBP) Procedure

In a BBP procedure, the customer pays the same amount every month. The amount is calculated from the last n months (generally 11 months).

The remaining amount the customer has to pay at the end of the period (balance forward) is generally higher in BBP procedures than in AMB procedures.

At the end of the period, the customer has to pay the BBP amount and the balance forward. The settings are specified in the contract.

In a BBP procedure, the BBP amounts are managed technically in a budget billing plan. However, these amounts cannot be viewed in the account balance display, but in a shadow table. This table is also used for the partial bill procedure in budget billing.

Page 359: IUT 230 billing and invoicing

© SAP AG IUT230 9-11

SAP AG 2006

Create

Change ContractContract Edit Goto Extras System Help

Contract TF0801A001

Payment Plan

Payment Plan Cat. 0001

Start Month 1 Alt. Start Month 3

Contract Period Amount Currency

HistoricalBilling Documents

Manual History

Change to the Contract

Initializing the Payment Plan Procedure

The payment plan procedures (AMB/BBP) are controlled in the contract using the Payment plan category, Start month and Alternative start month fields.

These fields can be entered manually in the contract. You can also enter this data using the transaction for creating a payment plan.

The main function of the payment plan category is to determine which payment plan procedure is being used. You define the payment plan category in Customizing.

When the start month has been reached, the payment plan is created in invoicing.

The system processes any changes you make in the contract fields during the next invoicing. For example, you must delete the start month in the contract if the customer wants to terminate his/her payment plan immediately. The balance forward is then settled in the next invoicing, and the customer must pay the remaining amount.

One payment plan is always maintained for each contract. However, there is now also a maintenance transaction that can be used for the maintenance of multiple payment plans for multiple contracts. For example, across different divisions.

Page 360: IUT 230 billing and invoicing

© SAP AG IUT230 9-12

SAP AG 2006

Budget Billing: 2

Budget billing procedure

Budget billingsBudget billing functions

Budget billing plan

Budget billing cycles

Budget billing due dates

Budget billing printout

Budget billing settlement

Page 361: IUT 230 billing and invoicing

© SAP AG IUT230 9-13

SAP AG 2006

Budgetbilling

Budgetbilling plan

Budget billingcycle

Budget billingadjustment

Budget billingprintout

Budget billingsettlement

Variousbudget billingprocedures

Budget Billing Functions

The parameters needed for budget billing are defined in the portion.

Various budget billing procedures can be used. These meet the different requirements of utility companies in Europe and North America.

Page 362: IUT 230 billing and invoicing

© SAP AG IUT230 9-14

SAP AG 2006

Budget Billing Cycle and Budget Billing Frequency

12Period Length Months

1

2

3

4

6

12

0No budget billings

Monthly

Every 2 months

Every 3 months

Every 4 months

Every 6 months

Every 12 months

1 2 3 4 5 6 7 8 9 10 11 12

Budget billing cyclesBudget billing cycles Possible number of budget billings per budget billing periodPossible number of budget billings per budget billing period

( 1 ( 2 ( 3 ( 4 ( 5 ( 6

( ( 1 ( ( 2 ( ( 3 ( ( 4

( ( ( 1 ( ( ( 2 ( ( ( 3

( ( ( ( ( 1 ( ( ( ( ( 2

( ( ( ( ( 1 ( ( ( ( ( (

Condition:Budget Billing Cycle x No. of Budget Billings = Length of the Billing Period

When you maintain the portion you enter all permissible combinations of budget billing cycle and number of budget billings.

A permissible combination refers to any pair of numbers for the budget billing cycle and number of budget billings where the product is smaller or equal to the billing period (= period length and period category).

Example:

Period length: 12 months. Period starts: 08/01/03 Budget billing cycle 01/No. of budget billing amounts: 11 =>1st budget billing amount: 08/30/06 2nd budget billing amount: 09/30/99 11. Budget billing 06/30/07 Budget billing cycle 01/Number of budget billings 12 => 1st budget billing 08/30/06 etc. 12th budget billing 07/30/07

If no combination is entered, no budget billings are collected.

Page 363: IUT 230 billing and invoicing

© SAP AG IUT230 9-15

SAP AG 2008

Portion

Cycle: 01/12Cycle: 02/6Default: 01

Portion

Cycle: 01/12Cycle: 02/6Default: 01

Budget billing plan

Cycle: 02

Budget billing plan

Cycle: 02

Scheduling:Definition of maximumpossibilities and thedefault budget billing cycle

Contract

Cycle: 02

Contract

Cycle: 02

Contract :Individual overridingof the default budget billing cyclefor generating the next budget billingplan

Budget billing plan:Overriding of the defaultbudget billing plan affectsthe budget billing amount due dates immediately

Defining Budget Billing Cycles

In scheduling, all possible budget billing cycles for this portion are defined. A default budget billing cycle is given in the portion and this is valid for all customers in this portion.

The budget billing cycle can be overridden in the contract (for generating the next budget billing plan) or directly in the budget billing plan itself (with immediate effect).

Page 364: IUT 230 billing and invoicing

© SAP AG IUT230 9-16

SAP AG 2006

Forms the basis for defining budget billing plans and manages all the budget billings for a billing period of a contract

Budget Billing PIan: 1

Determines the size of the budget billing amount and the due dates for the amounts

Can be created, changed, or adjusted manually or automatically.Example: individual processing in a move-in; automatic creation in invoicing

Header data (such as start and end of budget billing period, document number)

Due dates valid for all contracts in the budget billing plan (proposal from scheduling)

Cumulated budget billing amounts and cumulated open budget billing amounts (total from all contracts of a budget billing plan)

Budget billing amounts and open budget billing amounts from the active contract

Page 365: IUT 230 billing and invoicing

© SAP AG IUT230 9-17

SAP AG 2006

Information for calculating budget billing amounts

Manual Specification

(Move-In)

Quantity-dependent extrapolation

Standing budget billing amount

Budget billing plan

Budget Billing Plan: 2

The budget billing plan can be maintained either automatically or manually.

The quantity-based extrapolation is carried out, for example, during billing by extrapolating the demand up to the next planned meter reading date. The budget billing items created in this way are transferred to invoicing in the billing document. Invoicing accepts these amounts and distributes them to the individual budget billing due dates.

The standing budget billing amount is entered in the header data of the budget billing plan. This budget billing amount is always used when a budget billing plan is created. If an amount is not entered, the budget billing is determined using the extrapolation document.

Page 366: IUT 230 billing and invoicing

© SAP AG IUT230 9-18

SAP AG 2006

20062006

01.11. .... .... .... .... .... .... 01.08.

Billing period20072007

01.09. .... .... .... .... .... .... 01.14.

Budget billing period

Actualmeter reading

Extrapolation of consumption using configured weighting procedure;billing simulation for this period

Next scheduledmeter reading date from scheduling

Distribution of total simulated amount over the budget billing due dates

Distribution of total simulated amount over the budget billing due dates

Quantity-Based Extrapolation

Billing calculates the consumption up until the next scheduled meter reading date. Simulated billing is carried out for the budget billing period. The budget billing items created in this way are transferred to invoicing in the billing document. Invoicing accepts these amounts and distributes them to the individual budget billing due dates.

For this reason, ensure you have generated schedule records for the next billing period before you simulate billing.

Page 367: IUT 230 billing and invoicing

© SAP AG IUT230 9-19

SAP AG 2006

Cycle: 02Print date/debit entry date:01.31.200603.31.200605.31.200607.31.200609.31.200611.30.2006

Cycle: 02Print date/debit entry date:01.31.200603.31.200605.31.200607.31.200609.31.200611.30.2006

Scheduling:Definition of the Print Datesfor all Budget Billing Cycles

The payment condition from the contract account is used to determine the due dates for the budget billing plan

Schedule record portion

Cycle: 01Print date/debit entry date:01.31.200602.28.200603.31.200604.30.200605.31.200606.30.200607.31.200608.31.200609.30.200610.31.200611.30.200612.31.2006

Cycle: 01Print date/debit entry date:01.31.200602.28.200603.31.200604.30.200605.31.200606.30.200607.31.200608.31.200609.30.200610.31.200611.30.200612.31.2006

Schedule record portion

Budget billing planDefault cycle: 02

15.02.200615.04.200615.06.200615.08.200615.10.200615.12.2006

Budget billing planDefault cycle: 02

15.02.200615.04.200615.06.200615.08.200615.10.200615.12.2006

Budget Billing Due Dates

The planned budget billing print/due dates for each budget billing cycle are specified in the portion.

Terms of payment from the contract account are referred to to determine the actual budget billing due dates.

Under certain circumstances you should not use the terms of payment to determine the due dates for budget billings. In the Document: Determine Due Date from Payment Conditions event (1330), you can execute a due date determination that differs from the normal bills, and is specificly for budget billing dates.

Page 368: IUT 230 billing and invoicing

© SAP AG IUT230 9-20

SAP AG 2006

Water contractJoint

invoice: 2

2. Budget billing plan03.15.06 USD 7004.15.06 USD 7005.15.06 USD 7006.15.06 USD 70....

Electric. contr.Joint

invoice: 1

Gas contractJoint

invoice: 1

1. Budget billing plan03.15.06 USD 15004.15.06 USD 15005.15.06 USD 15006.15.06 USD 150....

Sub-Budg.Bill. Plan03.15.06 USD 5004.14.06 USD 5005.15.06 USD 5006.15.06 USD 50....

Sub-Budg.Bill. Plan03.15.06 USD 10004.15.06 USD 10005.15.06 USD 10006.15.06 USD 100....

Cumulated and Sub-Budget Billing Plan

A joint budget billing plan for two or more contracts is created if these are a required group, that is, if they are always invoiced jointly. A budget billing plan such as this consists of two or more sub-budget billing plans.

A contract that does not have to be invoiced with another contract has a separate budget billing plan.

Page 369: IUT 230 billing and invoicing

© SAP AG IUT230 9-21

SAP AG 2006

04.01. 100,--

07.01. 100,--

10.01. 100,--

01.01. 100,--

Budget Billing Planfrom Invoicing (*):

Budget Billing Plan After ActivationOf Advance Payment:

04.01. 100,--

07.01. 100,--

07.01. 100,--

10.01. 100,--

01.01. 100,--

X

X

L

Advance PaymentActivated on: 05.01.2006

Advance PaymentActivated on: 05.01.2006

NewNew

NewNew

Jan. - Mar.

April - June

July - Sept.

Oct. - Dec.

Jan. – Mar.

Consumption/Prepayment PeriodConsumption/Prepayment Period

Jan.- Mar.

April- June

July - Sept.

Oct. - Dec.

(*) Billing period 1.2. - 1.1.4 Budget Billings per Year

(*) Billing period 1.2. - 1.1.4 Budget Billings per Year

Key: X = Prepayment indicatorL = Last due date for prepayment

If necessary, a new budget billing period is generated at the end of the budget billing period

Budget Billing Advance Payments

You can define a budget billing plan to be an advance payment plan (for unreliable customers, for example). S If you do this, an additional due date is inserted into the budget billing plan. The other due dates represent advance payments for the next payment period. The final due date in the budget billing plan is the advance payment for the first payment period in the next billing or budget billing period. It is not cleared when the bill is created for the current billing period.

If a budget billing plan is defined as an advance payment plan then, during invoicing, the new budget billing plan is also created as an advance payment plan.

An advance payment plan can also be deactivated.

Page 370: IUT 230 billing and invoicing

© SAP AG IUT230 9-22

SAP AG 2006

Automatic Manual

Percentage- Increase- Decrease- Percent. Rec.

Extrapolation

- Cumulatedbudget billings

- Budget billingper contract

- Budget billingper due date

Messageto thecustomers

Budget Billing Adjustment

The existing budget billing plans in the system can be adjusted either automatically or manually.

Manually adjusting means changing the customer's budget billing amount or due dates.

Automatic adjusting means that a selection of budget billing plans defined by selection parameters can be changed automatically. There are two different methods to choose from:

Adjusting by percentage (increasing, decreasing)

Adjusting by extrapolation

Within rate maintenance and the express transaction for budget billing maintenance, you can make adjustments either manually, or using extrapolation. In the express transaction it is also possible to execute an extrapolation with meter reading results or period consumptions that have not yet been saved.

In the case of an interim billing, you can decide when creating the meter reading order whether the budget billing plans are to be adjusted.

A letter can be sent out automatically to inform the customer of the budget billing adjustment.

Page 371: IUT 230 billing and invoicing

© SAP AG IUT230 9-23

SAP AG 2006

OpenBillingsOpen

Billings

OpenInvoices

OpenInvoices

List /Budget Billing Plan Extension

List /Budget Billing Plan Extension

Budget Billing Requests11.15.2006 USD 15012.15.2006 USD 15001.15.2007 USD 15002.15.2007 USD 15003.15.2007 USD 15004.15.2007 USD 15005.15.2007 USD 15006.15.2007 USD 15007.15.2007 USD 15008.15.2007 USD 15009.15.2007 USD 150

10.15.2007 USD 15011.15.2007 USD 150

New Due Dates

Extending a Budget Billing Plan

You can use this report to evaluate open billings (for example, missing/implausible meter reading result) and invoices (for example, outsorted billing) according to certain criteria.

The report shows you a list of all billings and invoicings that are still open.

You can also extend the existing budget billing plan. This means that the system includes new budget billing amount due dates in the budget billing plan.

In the next periodic bills, all due dates from the extended budget billing plan are cleared, and the new budget billing plan starts subsequently.

Page 372: IUT 230 billing and invoicing

© SAP AG IUT230 9-24

SAP AG 2006

Budget Billing: 3

Budget billing procedure

Budget billingsBudget billing functions

Budget billing plan

Budget billing cycles

Budget billing due dates

Budget billing printout

Budget billing settlement

Page 373: IUT 230 billing and invoicing

© SAP AG IUT230 9-25

SAP AG 2006

Print Document with Print

ItemsSAP Spool

Print ReportPrint Report

Request budget billings

Request budget billings

Create partial billCreate

partial bill

CustomizingForm

CustomizingForm

ContractAccount

Form

ContractAccount

Form

Alternative

Alternative

Raw DataInterface

Budget Billing Printout/Partial Bill Printout: Process

Budget billing change doc.

Budget billing change doc.

With the statistical budget billing procedure, you must create the relevant print documents using the Request Budget Billings report.

With the partial billing procedure, you create the relevant print documents using the Create Partial Bills report. This report also performs debit entry for the documents in FI-CA

Alternatively, you can use the 'Create Budget Billing Change Document' report in the statistical procedure to generate the relevant print documents.

The generated print documents can then be processed using the print report. This report generates the physical bills.

Page 374: IUT 230 billing and invoicing

© SAP AG IUT230 9-26

SAP AG 2006

Print budget billing amount by

due date

Print all budget billing amounts on

bill

Budget billing bill 4711Date: 01.02.1999

Budget billing: Electricity 100Budget billing: Gas 70Budget billing: Water 30

-----------Interim sum 200Value-added tax: 15% 30

-----------Final amount 230.00

The budget billing amount of 230 USD is due on 01.15.1999.

Budget Billing Form

You have several options when printing budget billings. You can specify the appropriate settings in a Customizing table.

Page 375: IUT 230 billing and invoicing

© SAP AG IUT230 9-27

SAP AG 2006

Budget Billing: 4

Budget billing procedure

Budget billingsBudget billing functions

Budget billing plan

Budget billing cycles

Budget billing due dates

Budget billing printout

Budget billing settlement

Page 376: IUT 230 billing and invoicing

© SAP AG IUT230 9-28

SAP AG 2006

Bill 4711 Date: 02.07.06

Valuated consumption +_________+_________+_________

Credit memos/backbillings +/-________

Billamount =========

Paid budget billings -1,278

Items above +/-________

1. Budget billing amount +_________Final bill amount =========

Sub-items +/-________

Amount topay =========

Budget Billing Settlement: Paid Budget Billing Amounts

Paid budget billing amounts are automatically included and posted (only for statistical budget billing)

Budget billing payments are settled using the billing procedure and the billing period as references.

In a move-out with final billing, all of the budget billing payments are taken into account.

In interim billing, only the budget billing amounts that were paid within the billed period are taken into account.

Budget billing plans are deactivated.

The budget billing settlement of paid budget billings in invoicing cannot be set and takes place automatically.

Page 377: IUT 230 billing and invoicing

© SAP AG IUT230 9-29

SAP AG 2006

...............

...............

IMG

FI-CA

1. Budget Billing

100 USD

Clearing

Remaining BudgetBilling Amount

40 USD

InvoicingCredit

60 USD

Settlement Control

Example: Remaining Credit

Clearing Control

Settlement with the First/Next Budget Billing Amount: 1

In settlement control, you can settle an oustanding credit from invoicing with either the first or subsequent budget billing amount.

In the partial bill procedure, the first/next partial bill must already have been generated. This can be done within periodic invoicing. You can activate this function in Customizing, under SAP Utilities -> Invoicing -> Invoice Processing -> Define Control of Budget Billing Amounts in Invoicing.

Page 378: IUT 230 billing and invoicing

© SAP AG IUT230 9-30

SAP AG 2006

...............

...............

IMG

Utilities Industry

1. Budget Billing

100 USD 02.01.06

No Clearing

Same Due DateBill 120 USD

BB Amount 100 USD02.01.2006

InvoicingReceivable

120 USD 01.15.06

Grouping of Due Dates

Example: Outstanding Receivable

Invoicing

Clearing Against First or Next Budget Billing Amount: 2

If there is an outstanding receivable from invoicing then you can amalgamate the due due dates of the bill, and either the first or subsequent budget billing amount. You make these settings in the IMG for invoicing, and not in clearing control. Clearing control cannot be used in this case, since nothing can be cleared.

Page 379: IUT 230 billing and invoicing

© SAP AG IUT230 9-31

SAP AG 2008

Customizing for Budget Billing

Budget billing procedure

Control parameters for budget billing amount

Minimum/maximum budget billing amount

Rounding parameters for budget billing plan

General amount adjustment factors

Budget billing form

Payment plan type

...............

...............

IMG

...............

...............

Page 380: IUT 230 billing and invoicing

© SAP AG IUT230 9-32

SAP AG 2008

Budget Billing Amounts: Summary

SAP AG

The SAP Utilities budget billing control supports all known budget billing procedures.

The interface with the SAP Utilities print workbench means that budget billing requests and partial bills can be generated.

The system is based on settlement control, which can be maintained in Customizing.

Page 381: IUT 230 billing and invoicing

© SAP AG IUT230 9-33

Exercises

Unit: Budget Billing Topic: Budget Billing Plan

Process a budget billing plan.

Execute a budget billing request run, and a debit entry run.

Create a payment plan.

A customer phones up to change his budget billing amount because the number of people living in the household has changed.

1-1 Business partner TF1201A0## has made the following request.

1-1-1 Adjust the budget billing plan accordingly. Use the following information:

Business partner TF1201A0## New budget billing amount 200.-- USD

1-1-2 Determine the header data of the budget billing plan. Was the budget billing plan created manually or by invoicing? ____________________________________________________________ What is the budget billing plan for this budget billing plan? ____________________________________________________________

1-1-3 What is the tax portion in the next budget billing amount? ____________________________________________________________ How was the budget billing amount determined? ____________________________________________________________

1-1-4 From which billing portion are the original due dates and budget billing cycles generated? ____________________________________________________________ Where do you store the period text for a due date? ____________________________________________________________

Page 382: IUT 230 billing and invoicing

© SAP AG IUT230 9-34

1-1-5 A customer always wants to pay the same amount, regardless of his/her consumption pattern. Where do you make the settings to make this possible for the customer? ____________________________________________________________ Do you have to do more than select the field Do not adjust budget billing amount automatically? ____________________________________________________________

1-2 Carry out budget billing request run for a business partner.

1-2-1 The statistical budget billing procedure features a budget billing request report. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. Execute the budget billing request report for business partner TF1201A0##. Use the following information:

Business partner TF1201A0## Selection date 30th April of this year

1-2-2 The budget billing request report creates a print document. You can display the print document from the log.

1-3 Carry out partial bill run for the business partner.

1-3-1 You can use the partial bill report (create partial bills) during the partial bill procedure. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. The report also posts the items in contract accounts receivable and payable. Execute the partial bill report for business partner TF1301A0##. Use the following information:

Business partner TF1301A0## Document date 30th April (plus year of the current budget billing plan) Posting date 30th April (plus year of the current budget billing plan) Selection date 30th April (plus year of the current budget billing plan)

1-3-2 The partial bill report creates a print document. You can display the print document from the log. To view the posting of the budget billing amount in Contract Accounts Receivable and Payable, call the account balance display.

Page 383: IUT 230 billing and invoicing

© SAP AG IUT230 9-35

1-4 Optional. In the North American market, budget billing plans are not generally used because North American customers are billed monthly. Payment plan procedures are used instead, which even out a customer's monthly payments. Business partner TF0803A0## wants to use the BBP payment plan procedure.

1-4-1 Business partner TF0803A0## decides to use the budget billing plan procedure. The business partner wants the procedure to start next month. He/she has not yet received a monthly bill for the payment plan. Therefore, enter an amount (obtained from the customer- and in USD) for the last month in the manual history of contract TF0803A0##.

1-4-2 Call the transaction for creating a payment plan using the following data:

Initial data Contract TF08030A## Payment plan category 0001 BBP Start month Next month Save the payment plan the system has proposed.

1-4-3 To determine the balance forward, you must bill and invoice the contract for both the next month, and the month after that. To do this, use the individual bill You must also use the individual bill to enter the meter reading results.

1-4-4 Check the balance forward using the account balance display.

Page 384: IUT 230 billing and invoicing

© SAP AG IUT230 9-36

Page 385: IUT 230 billing and invoicing

© SAP AG IUT230 9-37

Solutions

Unit: Budget Billing Topic: Budget Billing Plan

1-1 Business partner TF1201A0## has made the following request.

1-1-1 Adjust the budget billing plan accordingly. Use the following information:

Business partner TF1201A0## New budget billing amount 200.--USD

From the SAP menu, choose Utilities Industry Invoicing Budget Billing Plan Statistical/Partial Bill Procedure Change

Select the budget billing plan of business partner TF1201A0##.

Choose Change. Change the amount as described in the exercise. Choose Save and save your changes.

1-1-2 Determine the header data of the budget billing plan. Was the budget billing plan created manually or by invoicing?

Select Header data. You can find the information you need in the BBP crtn type (creation type: budget billing plan) field. What is the budget billing plan for this budget billing plan? Select Header data. You can find the information you need in the field BB Procedure. Select F1 help for this field.

1-1-3 How much will the tax be on the next budget billing amount?

Select a line. Select Budget Billing Amount – Composition.

Use the forward navigation to access the information you need. How was the budget billing amount determined? Select Header data. You can find the information you need in the field billing document number. To display the billing document, double-click on the field. Here, you can analyze the amounts of the document line items that are highlighted in column A (bill line items from budget billing extrapolation). Multiply this amount by the current tax rate and divide this by 12 (11 budget billing amounts + the next periodic bill).

Page 386: IUT 230 billing and invoicing

© SAP AG IUT230 9-38

1-1-4 From which billing portion are the original due dates and budget billing cycles generated?

Select Scheduling.

Portion: T-A-00 Where do you store the period text for a due date? These entries are maintained in the schedule records of the accompanying portion T-A-00.

1-1-5 A customer always wants to pay the same amount, regardless of his/her consumption pattern. Where do you make the settings to make this possible for the customer? Select Header data. Maintain data for the standing budget billing amount. Do you have to do more than select the field Do not adjust budget billing amount automatically? No. This field is only interpreted when the automatic budget billing adjustment report is executed.

1-2 Carry out a budget billing request run for the business partner.

1-2-1 The statistical budget billing procedure features a budget billing request report. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. Execute the budget billing request report for business partner TF1201A0##. Use the following information:

From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Mass Processing

Request Budget Billing Amounts.

Choose the selection criteria in the data screen as described in the exercise and execute. The print date in the budget billing plan was set and the due date, April 30 was changed to the system date.

1-2-2 The budget billing request report creates a print document. You can display the print document from the log.

Select Display document.

Page 387: IUT 230 billing and invoicing

© SAP AG IUT230 9-39

1-3 Carry out partial bill run for the business partner.

1-3-1 You can use the partial bill report (create partial bills) during the partial bill procedure. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. The report also posts the items in contract accounts receivable and payable. Execute the partial bill report for business partner TF1301A0##. Use the following information:

From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Mass Processing

Create Partial Bill.

Choose the selection criteria in the data screen as described in the exercise and execute. The print date in the budget billing plan was set and the due date, April 30 was changed to the system date.

1-3-2 The partial bill report creates a print document. You can display the print document from the log. To view the posting of the budget billing amount in Contract Accounts Receivable and Payable, call the account balance display.

Select Display document. From the SAP menu, choose Utilities Industry Contract Accounts Receivable and Payable Account

Account Balance.

Page 388: IUT 230 billing and invoicing

© SAP AG IUT230 9-40

1-4 Optional. In the North American market, budget billing plans are not generally used because North American customers are billed monthly. Payment plan procedures are used instead, which even out a customer's monthly payments. Business partner TF0803A0## wants to use the BBP payment plan procedure.

1-4-1 Business partner TF0803A0## decides to use the budget billing plan procedure. The business partner wants the procedure to start next month. He/she has not had a monthly bill so far. Therefore, enter an amount (obtained from the customer- and in USD) for the last month in the manual history of contract TF0803A0##.

From the SAP menu, choose Utilities Industry Invoicing Budget Billing Plan Payment Plan Manual History.

Choose Create. Enter the amount from last month and choose USD as your currency. Save.

1-4-2 Call the transaction for creating a payment plan using the following data:

From the SAP menu, choose Utilities Industry Invoicing Budget Billing Plan Payment Plan Create

Enter your data as specified in the exercise. Save the payment plan the system has proposed.

1-4-3 To determine the balance forward, you must bill and invoice the contract for both the next month, and the month after that. To do this, use the individual bill You must also use the individual bill to enter the meter reading results.

From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing

Individual Bill.

In Level of processing, select Display bill. Select the selection criterion Contract and enter the contract TF0803A0##. Select the Enter meter reading results check box and enter 01 in the Meter reading reason field.

Choose Execute.

Repeat the individual bill for the month after next.

1-4-4 Check the balance forward using the account balance display.

From the SAP menu, choose Utilities Industry Contract Accounts Receivable and Payable Account

Account Balance.

Page 389: IUT 230 billing and invoicing

© SAP AG IUT230 10-1

SAP AG 2008

Bill Printout

SAP AG 2007

Bill Printout Functions

Print Action Records

Raw Data Interface, Optical Archiving

Page 390: IUT 230 billing and invoicing

© SAP AG IUT230 10-2

SAP AG 2006

Bill Printout: Unit Objectives

SAP AG 2006

At the conclusion of this unit, you will be able to:

Describe the concept of bill printout

Explain the hierarchy for billing forms

Outline the bill printout process

Outline the options for sorting bill line items

Describe print action records

Explain the raw data interface and describe the optical archiving options

Page 391: IUT 230 billing and invoicing

© SAP AG IUT230 10-3

SAP AG 2006

Bill Printout Functions

Print Action Records

Raw Data Interface, Optical Archiving

Bill Printout: 1

Page 392: IUT 230 billing and invoicing

© SAP AG IUT230 10-4

SAP AG 2008

Form Hierarchy

SAPscript Form- Layout- Paragraphs- Character strings- Windows- Page windows

SAPscript Form- Layout- Paragraphs- Character strings- Windows- Page windows

Print workbenchSAP Utilities formPrint workbench

SAP Utilities form

Customer

Account

Contract

Installation

...

...GeneratedPrint Program-represents the form structure-can be changed/ extended byusers

-customer exits

GeneratedPrint Program-represents the form structure-can be changed/ extended byusers

-customer exits

SAP Standard Text- Free texts- Fields

SAP Standard Text- Free texts- Fields

A SAPscript form is allocated to the SAP Utilities form. In the SAPscript form, you determine the layout of the application form (for example, paragraphs, windows, page windows).

Standard SAP texts can be allocated to the individual hierarchy levels. Literals and variables are stored in these standard texts.

The SAP Utilities application form is used to generate an executable print program, which is called from the application.

Page 393: IUT 230 billing and invoicing

© SAP AG IUT230 10-5

SAP AG 2006

IS_U_BI_BILLIS_U_BI_BILL

DOC_HEADERDOC_HEADER

DOC_ITEMDOC_ITEM

CONT_ACCTCONT_ACCT

CONTRACTCONTRACT

Text forDOC_HEADERText forDOC_HEADER

Text forDOC_ITEMText forDOC_ITEM

Root Level

Document Level

1:1 Level

Text Level

Form Level

1:1 Level

Text Level

Structure of the Bill Form

The document level (DOC_HEADER) and item level (DOC_ITEM) are the two most important levels in the bill form. Fields such as customer ID, bill number, and due date are available at this level. The item level is run once per billing line item (loop).

In addition to the above-mentioned levels, there are 1:1 levels. These contain additional information such as contract account data or contract data.

One or more text elements can be assigned to each level. These text elements contain user-defined texts (text literals) or fields (variables) that are filled with actual data at runtime.

Page 394: IUT 230 billing and invoicing

© SAP AG IUT230 10-6

SAP AG 2006

Bill Form

Bill 4711 Date: 01.02.06

Group Service Device Tax Code Net Amount0001 Energy Price G1 A1 123.450001 Energy Price G2 A1 201.500001 Energy Price G3 A1 300.35Subtotal for Value Added Tax 93.80

0002 Provisioning G1 A1 203.550002 Provisioning G2 A1 344.010002 Provisioning G3 A1 470.89Subtotal for Value Added Tax 152.77

---------- ----------Bill Amount 1643.75 246.57

The final bill amount of 1890.32 USD is due on 01.15.2006.

The next budget billing amounts are due on the following dates:1.1., 3.1., 4.1., 5.1., 6.1., 7.1.,Please pay a budget billing amount of 50.00 USD by these dates.

Sort Order of Billing

Line Items ?????Sort Order of Billing

Line Items ?????

The billing form can be displayed in various ways:

Consumption and amount determination are split up

Presented without groups

Bill line items sorted according to divisions and contract number

Bill line items are sorted according to meter number

With a cover page, detailed description on the following slides

Without a cover page

The print workbench can model any of these requirements. The next few slides will describe how to sort bill line items according to certain criteria.

Page 395: IUT 230 billing and invoicing

© SAP AG IUT230 10-7

SAP AG 2006

Print ReportPrint ReportPrint

Document with Print Items

Raw DataInterface

SAP Spool

Bill Printout Procedure

The print documents created in invoicing are then processed using a print report. The output of the print report are the printed bills.

Page 396: IUT 230 billing and invoicing

© SAP AG IUT230 10-8

SAP AG 2006

NavigationShipping Control-->Shipping Types

Shipping Control 0001

Shipping Types

12EMAILPRINTER

11

**33

No.Trnsm.mthdPrintoutsRDIArch.Mod.Copy

Shipping Control BPShipping Control alt.BTPShipping Control alt.DR

Contract Account

Print ReportPrint Report

FAXPrinter E-mail R-MailFax

Communication Types in Business Partner

Shipping Control

Shipping control allows you to define options for sending correspondence. For example, you can specify that two copies of a document are to be printed, or that one copy is to be printed and another copy is to be sent by e-mail.

Page 397: IUT 230 billing and invoicing

© SAP AG IUT230 10-9

SAP AG 2008

Payment Form Reference

Invoice 4711 Date: 02-Jan-06

Block Service Device Tax Code Net Amt0001 Energy price D1 A1 123.450001 Energy price D2 A1 201.500001 Energy price D3 A1 300.35Value added tax: Subtotal 93.80

0002 Provisioning D1 A1 203.550002 Provisioning D2 A1 344.010002 Provisioning D3 A1 470.89Value added tax: Subtotal 152.77

---------- ---------- Invoice amount 1643.75 246.57

The bill sum total of 1890.32 USD is due on 15-Jan-06. Please transfer the amount using the transfer slip attached.

Bill Receivable

XYZ Municipal Utility

123456 672 500 30

Bank XYZ

1890.32 USD

283764159 4711

Smith, Peter

The payment form number is an internally assigned, unique number that can be allocated to a payment form and that cash payer can use to pay the bill.

The payment form number is allocated regardless of whether a payment form is created during bill printout.

It is saved in the field NRZAS in the print document header.

The payment form number determines which open items are paid with the payment form.

You can select these open items using the payment form number, for example in the cash desk.

Invoicing allocates payment scheme numbers only for cash payers and for bill requests.

Page 398: IUT 230 billing and invoicing

© SAP AG IUT230 10-10

SAP AG 2006

Financial Accounting

Basic Settings: Financial Accounting

Correspondence

Attached Payment Medium

CountryFORM IDCountryFORM ID

Function Modulefor Formattingthe Payment

Medium

Function Modulefor Formattingthe Payment

Medium

Company CodeFORM ID

Company CodeFORM ID

SAPscriptForm

SAPscriptForm

FIFI

Posting AreaR401

CoCd FORM ID

Posting AreaR401

CoCd FORM ID1200

Payment MediumOne thousand two hundred

Walldorf, 12/29/94

Bill

Payment Medium

IMG

Das Customizing der Zahlungsträger muss in der Komponente Finanzwesen (FI) durchgeführt werden. Sie finden die relevanten Aktivitäten unter den Grundeinstellungen Korrespondenz Anhängende Zahlungsträger.

Sie können pro Land eine FORM ID definieren. Zusätzlich wird ein Funktionsbaustein angegeben, der die Aufbereitung des Zahlungsträgers landesspezifisch vornimmt (z.B. für DE = PAYMENT_MEDIUM_DE_BANKTRANSFER).

In einer weiteren Aktivität müssen Sie zum Buchungskreis und der FORM ID ein SAPscript Formular angeben, welches für den Druck des anhängenden Zahlungsträgers verwendet wird.

Für die IS-U Fakturierung müssen Sie im Buchungsbereich R401 die zu benutzende FORM ID dem Buchungskreis zuordnen. Die Fakturierung setzt dann die FORM ID in den Belegen, wenn folgende Bedingungen erfüllt sind:

In dem relevanten Buchungskreis ist eine FORM ID hinterlegt

Es handelt sich bei dem zu fakturierenden Vertragskonto um einen Barzahler

Es handelt sich bei der Fakturierung um eine Restforderung

Nur in wenn die o.g. Bedingungen erfüllt sind, dann wird das Feld FORM ID im Druckbeleg gesetzt und der Rechnungsdruck erzeugt zusätzlich zur Rechnung einen Zahlungsträger.

Zusätzlich wird für den Zahlungsträger eine Zahlscheinnummer erzeugt. Diese Nummer kann auch auf den Verwendungszweck angegeben werden. Der Nummernkreis muss definiert sein.

Page 399: IUT 230 billing and invoicing

© SAP AG IUT230 10-11

SAP AG 2006

Formatting Bill Printout

Billing document: 3010 - Contract: 1000

Doc. Line Type Presort.Key Tax Code Net Amnt.

IQUANT B1000001 B2 A1 295.20000003 B2 A1 300.00

Bill 4711 Date: 10.22.2006

Consumption contract 1000 11/01/2001 - 10/15/20022460 KWh

Consumption contract 2000 11/01/2001 - 10/15/20026240 KWh

Contract 1000:Energy price: 2460 KWh · 0.12 USD 295.20 USDProvisioning: 12 · 25 USD 300.00 USD Value Added Tax:

95.23 USD

Subtotal: 690.43 USD ___________

Contract 2000:Energy price: 6240 KWh · 0.12 USD 748.80 USD Provisioning: 12 · 25 USD 300.00 USD Value Added Tax:

167.81 USD___________

Subtotal: 1216.61 USD

Final bill amount 1907.04 USD

B1

B2

B2

Sort module: ISU_B

ILL_TYPE_CO

NTRACT

Billing document: 3011 - Contract: 2000

Doc. Line Type Presort.Key Tax Code Net Amnt.

IQUANT B1000001 B2 A1 748.80000003 B2 A1 300.00

Sort Order of Billing Line Items:

Sort all billing line items according to presort key (ascending)

Sort according to VAT code within a presort group (ascending)

Call each sort module in order to create blocks, for example, according to contract.

Calculation of subtotal (SUBTOTAL) according to Customizing settings

Internal workflow for bill sorting and creating subtotals: All billing line items (cross-document) are sorted according to presort key (ERCHZ line sort) and divided into groups with the same presort key. Within these groups, items are sorted again based on VAT codes (ERCHZ-MWSKZ). The resulting groups are then transferred to the separate sort modules. Items are then further sorted within the sort module according to contract, company code or customer-specific, for example. Depending to the Customizing settings, a sub total line item (SUBT) is also generated in the sort module.

Page 400: IUT 230 billing and invoicing

© SAP AG IUT230 10-12

SAP AG 2006

Presort Key Function

Billing Document 1 Billing Document 2

Function ModuleISU_BILL_TYPE_CONTRACT

Invoicing

Presort Keys:0001 = Sort according to contract w/o subtotals0002 = Sort according to contract with subtotals

Electric.Presort. Doc.Line Type Contr. Amount0001 IDEMAN 47120001 IQUANT 47120002 000001 4712 12.45 USD 0002 000002 4712 33.78 USD

Electric.Presort. Doc.Line Type Contr. Amount 0001 IDEMAN 47110001 IQUANT 47110002 000001 4711 312.45 USD 0002 000002 4711 31.78 USD

Im vorangehenden Beispiel sind einem Vertragskonto zwei Stromverträge zugeordnet. Im Abrechnungsschema ist den Infozeilen der Vorsortierungsschlüssel 0001 zugeordnet. Den buchungsrelevanten Rechnungszeilen ist der Vorsortierungsschlüssel 0002 zugeordnet.

Im Customizing der Vorsortierungsschlüssel ist den beiden Schlüsseln 0001 und 0002 jeweils der Sortier Funktionsbaustein ISU_BILL_TYPE_CONTRACT zugeordnet. Dieser nimmt eine Sortierung der Rechnungszeilen nach der Vertragsnummer vor.

Page 401: IUT 230 billing and invoicing

© SAP AG IUT230 10-13

SAP AG 2006

Presort Key Function - Step 1

Electric.Presort. Doc.Line Type Contr. Amount 0001 IDEMAN 47120001 IQUANT 47120001 IDEMAN 47110001 IQUANT 4711

0002 000001 4712 12.45 USD0002 000002 4712 33.78 USD0002 000001 4711 312.45 USD0002 000002 4711 31.78 USD

Document Line Items SortedAccording to Presort Key(cannot be changed by user)

Presort Keys:0001 = Sort according to contract w/o subtotal0002 = Sort according to contract with subtotal

Print Document

Im ersten Schritt werden die Rechnungszeilen nach dem Vorsortierungsschlüssel an sich sortiert. D.h. die Rechnungszeilen mit dem Vorsortierungsschlüssel 0001 kommen vor den Rechnungszeilen mit dem Vorsortierungsschlüssel 0002.

Diese Sortierung ist vom Benutzer nicht änderbar. Sie kann nur durch die Definition der geeigneten Vorsortierungsschlüssel beeinflusst werden.

Page 402: IUT 230 billing and invoicing

© SAP AG IUT230 10-14

SAP AG 2006

Presort Key Function - Step 2

Electric.Presort. Doc.Line Type Contr. Amount 0001 IDEMAN 47110001 IQUANT 47110001 IDEMAN 47120001 IQUANT 4712

0002 000001 4711 312.45 USD0002 000002 4711 31.78 USD0002 000001 4712 12.45 USD0002 000002 4712 33.78 USD

Document Line Items SortedAccording to Contract

(Function Module SU_BILL_TYPE_CONTRACT)

User-Defined => Dependenton Presort Key

Print Document

Presort Keys:0001 = Sort according to contract w/o subtotal0002 = Sort according to contract with subtotal

Im zweiten Schritt werden die Rechnungszeilen nach der Logik im Funktionsbaustein sortiert. In diesem Fall erfolgt eine Sortierung nach der Vertragsnummer. Diese Sortierung wird durch den Funktionsbaustein ISU_BILL_TYPE_CONTRACT vorgenommen.

Page 403: IUT 230 billing and invoicing

© SAP AG IUT230 10-15

SAP AG 2006

Presort Key Function - Step 3

Electric.Presort. Doc.Line Type Contr. Amount0001 IDEMAN 47110001 IQUANT 47110001 IDEMAN 47120001 IQUANT 4712

0002 000001 4711 312.45 USD0002 000002 4711 31.78 USD

SubTotal(City Tax) 12.56 USDSubTotal(Country Tax) 15.66 USD

0002 000001 4712 12.45 USD0002 000002 4712 33.78 USD

SubTotal(City Tax) 2.56 USDSubTotal(Country Tax) 5.66 USD

Create subtotal line items when contract changes

(see above function module)

Print Document

Presort Keys:0001 = Sort according to contract w/o subtotal0002 = Sort according to contract with subtotal

Im dritten Schritt werden Zwischensummen eingefügt. Beim Vorsortierungsschlüssel 0002 ist im Customizing angegeben, dass eine Zwischensumme erzeugt werden soll. Das System erkennt einen Gruppenwechsel für den Vertrag und fügt spezielle Zwischensummenzeilen in den Druckbeleg ein.

Pro Abrechnungsschema muss mindestens eine Rechnungszeile mit einem Vorsortierungsschlüssel versehen sein, der eine Zwischensumme erzeugt.

Ziel der Vorsortierungsschlüssel sollte es sein, dass die Rechnungszeilen genau in der zu druckenden Reihenfolge im Druckbeleg hinterlegt werden. Eine spätere Umsortierung im Rechnungsdruck ist aufwendig und evtl. sogar fehlerhaft (z.B. bei der Bildung von eigenen Zwischensummen im Rechnungsdruck).

Page 404: IUT 230 billing and invoicing

© SAP AG IUT230 10-16

SAP AG 2006

Bill Printout Functions

Print Action Records

Raw Data Interface, Optical Archiving

Bill Printout: 2

Page 405: IUT 230 billing and invoicing

© SAP AG IUT230 10-17

SAP AG 2006

Functions:Reproduce any texts on IS-U application forms

Determine whether additional information (such as flyers) is to be sent out with IS-U application forms

Print Action Records: 1

Druckaktionssätze werden genutzt, um dem Kunden zusätzliche Infomationen auf Schreiben (z.B. Rechnung) mitzuteilen.

Zusätzlich kann gesteuert werden, dass bestimmte Beilagen von der Poststraße dazu sortiert werden.

Page 406: IUT 230 billing and invoicing

© SAP AG IUT230 10-18

SAP AG 2008

CustomerReportfor BuildingPrint Action Records

CustomerReportfor BuildingPrint Action Records

FunctionModule

for Writinga PrintActionRecord

Form ClassForm Class

Print ActionRecord

Print ActionRecord

Mass Creation of Print Action Records

Print Action Records: 2

Print action records can also be created in very large numbers (for example, information for all customers with E1 as rate category). The customer must create a report that selects all contracts that have E1 as their rate category. The next step is to create a print action record for each of these contracts. SAP provides you with a function module to do this.

Page 407: IUT 230 billing and invoicing

© SAP AG IUT230 10-19

SAP AG 2008

ContractContract

BusinessPartner

BusinessPartner

ContractAccountContractAccount

Print Action Records: 3

Transaction forDisplaying,

Changing, andDeleting

Print Action Records

Transaction forDisplaying,

Changing, andDeleting

Print Action Records

Form ClassForm Class

Print ActionRecord

Print ActionRecord

Creation of One Print Action Record

A print action record always refers to a form class and a business object. By allocating it to a form class, you define on which form the text is to be printed. By allocating it to a business object, you define at which hierarchy level the text is to be printed.

Page 408: IUT 230 billing and invoicing

© SAP AG IUT230 10-20

SAP AG 2006

Send rate informationSend collection authorizationSend questionnaire on gas actionText information: Meter replacement in next billing periodText information: GreetingText information: Move-in/out...

Valid from: Valid to:Send x No. of times:Form class:

Send rate informationSend collection authorizationSend questionnaire on gas actionText information: Meter replacement in next billing periodText information: GreetingText information: Move-in/out...

Valid from: Valid to:Send x No. of times:Form class:

Print Action Records: 4

xx

x

01.01.1997 31.12.19971IS_U_BI_BILL

Option ofEntering a User-

Defined Text(Standard SAPText Module)

Option ofEntering a User-

Defined Text(Standard SAPText Module)

Adds FlyerAdds Flyer

Prints an Additional TextPrints an Additional Text

Structure

Print action records are allocated to a certain object (e.g. contract, contract account) and an additional form class. This ensures that a certain text is only printed on the corresponding form, for example, the bill correction text should only be printed on the bill and not on other forms.

You can also save general texts that are frequently reused in a Customizing table.

Page 409: IUT 230 billing and invoicing

© SAP AG IUT230 10-21

SAP AG 2006

Bill Printout Functions

Print Action Records

Raw Data Interface, Optical Archiving

Bill Printout: 3

Page 410: IUT 230 billing and invoicing

© SAP AG IUT230 10-22

SAP AG 2006

22

11

22

11Print

WorkbenchIS-U

ApplicationForm

PrintWorkbench

IS-UApplication

Form

SAPscriptform

(layout, text,data)

SAPscriptform

(layout, text,data)

ApplicationApplication PrintProgram

PrintProgram

Spool file

Alternative

External systems• Mass data• Mailroom system• Postage determination• Sort• Creation of layout

External systems• Mass data• Mailroom system• Postage determination• Sort• Creation of layout

Raw data interface

Com

plete formfor online printing

Generates

Net form

for raw data interface

Concept of Raw Data Interface

An interface is available for printing mass data or for additional optimal processes, such as postage determination, sorting for delivery, and use of barcodes for mail processing. Output can be transferred to the raw data interface instead of to the SAP spool file.

SAPscript can be used in two ways to generate forms:

Online using a spool file

- for generating immediate bills

Raw data interface

- for transferring information to an external system SAP recommends this solution for mass printing.

Page 411: IUT 230 billing and invoicing

© SAP AG IUT230 10-23

SAP AG 2008

Bill Printout: Summary

SAP AG

Integration with the SAP Utilities print workbench allows you to create bills.

The bill line items can be sorted according to individual requirements.

Using the print action records, you can include individual or standard texts on a bill.

Bill printout processes the print document and writes data to the spool file or to a raw data interface.

Bill printout provides the option of optically archiving bills.

Page 412: IUT 230 billing and invoicing

© SAP AG IUT230 10-24

Page 413: IUT 230 billing and invoicing

© SAP AG IUT230 10-25

Exercises

Unit: Bill Printout Topic: Bill Printout

Be able to print and reprint a bill.

Be able to create a print action record.

A customer received a bill and has mislaid it. He/she would like to have a new copy of the bill sent to him/her. You will also create a print action record for another customer.

1-1 How do you display a record in the system?

1-1-1 List the menu paths. ____________________________________________________________

1-2 Reprint the last bill for the business partner TF0701A0##. You have already performed billing and invoicing for this business partner in exercise 7-1.

1-2-1 Which menu path would you use to reprint a bill? ____________________________________________________________

1-2-2 Carry out the procedure for reprinting a bill. Use the print report. Note that you can only carry out the procedure for reprinting a bill if the original bill was already printed.

1-3 Create a print action record for a business partner. The customer is to be informed on his next bill that he is being billed with a new rate.

1-3-1 Create a print action record for the business partner TF0703A0##. Use the ISUPARTNER object type and the IS_U_BI_BILL form class. Enter your own text.

1-3-2 Which object types and form classes are supported by the print action records at present? ____________________________________________________________

Page 414: IUT 230 billing and invoicing

© SAP AG IUT230 10-26

Page 415: IUT 230 billing and invoicing

© SAP AG IUT230 10-27

Solutions

Unit: Bill Printout Topic: Bill Printout

1-1 How do you display a record in the system?

1-1-1 List the menu paths.

From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Display Print Document. Under this menu path there are various options: Display line items, simulate bill, display bill from optical archive.

From the SAP menu, choose Utilities Industry Customer Service Front Office/Customer Interaction Center Customer Interaction Center Customer overview. Double-click Bill or the display function from the optical archive.

1-2 Reprint the last bill for the business partner TF0701A0##. You have already performed billing and invoicing for this business partner in a previous exercise.

1-2-1 Which menu path would you use to reprint a bill?

From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Mass Processing

Print out Print Document.

From the SAP menu, choose Utilities Industry Customer Service Front Office/Customer Interaction Center Customer Interaction Center Customer overview

Edit Reprint bill. This function will print the original bill if this has not already occurred. Otherwise the bill is reprinted

Page 416: IUT 230 billing and invoicing

© SAP AG IUT230 10-28

1-2-2 Carry out the procedure for reprinting a bill. Use the print report. Note that you can only carry out the procedure for reprinting a bill if the original bill was already printed.

Enter 01 (Print consumption billing) as the creation reason. Select the posted documents. Then you can maintain the print parameters by choosing Print parameters.

Find the most recent print document for the business partner TF0701A0## using the F4 search help.

Define the print parameters.

Enter 01 as the creation reason and select the Document posted checkbox.

When reprinting bills you must enter a date in the print date field. Otherwise it is a print of the original bill. You can find the print date in the header data of the print document. You can also enter a range (print date from – to).

Choose Execute.

1-3 Create a print action record for a business partner. The customer is to be informed on his next bill that he is being billed with a new rate.

1-3-1 Create a print action record for the business partner TF0703A0##. Use the ISUPARTNER object type and the IS_U_BI_BILL form class. Enter your own text.

From the SAP menu, choose Utilities Industry Tools Print Workbench Print Action Records

Create.

Select the ISUPARTNER object type and the IS_U_BI_BILL form class. Enter the business partner number as the object key.

Press Enter.

Enter a short description of the print action record in the description field. To enter your own text, you must first save. After you save, a create icon will appear in the Individual text field. Clicking on this icon takes you to a screen where you can enter your individual text. Enter your individual text. Save the text. Go back to the print action record.

Save your entries.

Page 417: IUT 230 billing and invoicing

© SAP AG IUT230 10-29

1-3-2 Which object types and form classes are supported by the print action records at present?

ISUACCOUNT IS_U_BI_BILL ISUACCOUNT IS_U_BI_COLLECTIVE_BILL ISUCONTRCT IS_U_BI_BILL ISUCONTRCT IS_U_BI_COLLECTIVE_BILL ISUPARTNER IS_U_BI_BILL ISUPARTNER IS_U_BI_COLLECTIVE_BILL

Page 418: IUT 230 billing and invoicing

© SAP AG IUT230 10-30

Page 419: IUT 230 billing and invoicing

© SAP AG IUT230 11-1

SAP AG 2008

Special Billing Features

SAP AG 2007

This unit will prepare you to:

Describe the various franchise fee procedures

Explain gas billing with SAP Utilities

List deregulated contracts with the liberalization of new markets

Explain how reference values and street lighting are billed

Perform archiving tasks

Describe special types of billing

Page 420: IUT 230 billing and invoicing

© SAP AG IUT230 11-2

SAP AG 2006

At the conclusion of this unit, you will be able to:

Describe how franchise fee procedures are supported by the system

Explain the different types of gas billing

List the master data required for billing deregulated contracts

Explain the functions of reference values and street lighting

Archive billing data

Describe special types of billing

SAP AG 2006

Special Billing Features: Unit Objectives

Page 421: IUT 230 billing and invoicing

© SAP AG IUT230 11-3

SAP AG 2006

Franchise Fee

Gas Billing

Reference Values/Lighting

Billing Deregulated Contracts

Archiving Billing Data

Special Types of Billing

Special Billing Features: 1

Page 422: IUT 230 billing and invoicing

© SAP AG IUT230 11-4

SAP AG 2006

Quantity

Amount * FF Factor

FF Price

=

=

FFAmount

FF based on a quantity and an amount (electricity and gas divisions)

FF based on an amount and a percentage ratewithout price grouping

FFAmount*

Amount FF Factor =

FF based on an amount and a percentage rate (water division)with price grouping

FFAmount*

Franchise Fee Procedure in Germany/N. America

There are several franchise fee procedures:

In Germany, an amount procedure is used in the electricity division. The franchise fee is included in the price on the bill. Conversely, a percentage procedure is used in the water division. In this case, the franchise fee is also included in the price on the bill.

A percentage procedure is also used in North America but the franchise fee is listed separately on the bill.

Page 423: IUT 230 billing and invoicing

© SAP AG IUT230 11-5

SAP AG 2006

Net Procedure Gross Procedure Max. Gross Procedure

Price incl. FF Price incl. FF Price incl. FF

Price TablePrice incl. FF

Price TablePrice incl. FF

FF-Contract-Amount

Amount < Max.

Max. - Amount

Franchise Fee Procedure

FF-Contract-Amount-Max.

PriceTable

+ -

A franchise contract establishes the duties that a utility company must pay to a particular political entity. In return, the utility company receives the right to supply energy directly to customers in the municipality and may use public traffic routes for installing and operating lines.

Three different procedures are supported in the system:

Net procedure: The prices in the price definition are net prices without a franchise fee contribution. The franchise fee contribution is determined via the franchise contract.

Gross procedure: The franchise fee contribution is included in the prices.

Maximum gross procedure: The franchise fee contribution is already included in the price. A maximum franchise fee amount is determined in the franchise contract. If a franchise fee is not charged by the municipality, the price is reduced accordingly for the customers. If municipalities receive a franchise fee from the utility company that is higher than the maximum tax contained in the price, the customer is only charged the maximum price.

Page 424: IUT 230 billing and invoicing

© SAP AG IUT230 11-6

SAP AG 2008

Installation(FF Contract) Premise PremiseConnection

Objectconsumption

stelleRegionalStructure

Rate Steps

Franchise Fee Group

Prices

FF ContractFF Procedure

Franchise Fee GroupFF Amnts, FF Contribution

Rate

PricesFF Amounts Can

Be Overriden

Franchise Fee: Data Retention

You must create a franchise contract separately. A franchise contract always refers to the municipality with which it is agreed. It also contains the supporting procedure (net, gross, or max. gross procedure) and the franchise fee amounts or franchise fee contributions (factors).

When you create an installation, the regional structure suggests a franchise contract, which is then stored in the installation. This improves performance considerably, as the system does not have to look for the contract in the regional structure. If there is no franchise contract in the installation, the franchise fee cannot be calculated.

In the rate steps, you define whether an amount procedure (used in Germany in the electricity division for example), a percentage procedure with price grouping (Germany, water), or a percentage procedure without price grouping (USA, Canada) is used.

The franchise fee group in the rate steps is used to determine the relevant franchise fee amount or contribution in the franchise contract. Usually, you do not define a value for the franchise fee in the price keys or factors. In exceptional cases, you can define a value there, which then overrides the amounts or contributions defined in the franchise contract.

There are specific variant programs available to you (COMPUT13, 14, 15, 16, and 19), which can split up prices using a factor.

Page 425: IUT 230 billing and invoicing

© SAP AG IUT230 11-7

SAP AG 2006

Franchise Fee

Gas Billing

Reference Values/Lighting

Billing Deregulated Contracts

Archiving Billing Data

Special Types of Billing

Special Billing Features: 2

Page 426: IUT 230 billing and invoicing

© SAP AG IUT230 11-8

SAP AG 2008

Volumetric Gas Billing

Thermal Gas Billing

Gas Billing According to Standard Cubic Meters

Gas Procedure

In gas billing, the measured operating volume of a gas is evaluated to determine the actual billing quantity. Each register of a gas meter is assigned a gas procedure that defines how the gas volume will be evaluated. Gas billing types include:

According to standard cubic meters Operating cubic meters are converted into standard cubic meters using the gas volume correction factor.

Thermal Operating cubic meters are converted into a heat quantity using the volume correction factor and the calorific value.

Volumetric The operating cubic meters measured are billed directly.

Page 427: IUT 230 billing and invoicing

© SAP AG IUT230 11-9

SAP AG 2006

Measured Operating Cubic Meters

*Volume Correction Factor

=Standard Cubic Meters

*Calorific Value

=Heat Quantity

Gas Procedure=

(Volume Correction Factor Procedure, Calorific Value Procedure)

Gas Procedure=

(Volume Correction Factor Procedure, Calorific Value Procedure)

Thermal Gas Billing

In thermal gas billing, the measured operating cubic meters are multiplied by the volume correction factor to determine the standard cubic meters. In turn, the standard cubic meters are multiplied by the calorific value to determine the heating quantity (such as kWh) that is to be billed.

In IS-U, the system determines the volume correction factor in the volume correction factor procedure. The calorific values are defined in the calorific value procedure. The volume correction factor procedure and the calorific value procedure combine to produce a gas procedure.

Page 428: IUT 230 billing and invoicing

© SAP AG IUT230 11-10

SAP AG 2008

Gas Billing

Gas ProcedureEntry at Register Level

Modeling in Customizing

Calorific Value Procedure

• Defined Calorific Value• Calculation of Arithmetic Average• Calculation of Weighted Average

VCF Procedure

• Defined Volume Correction Factor• Calculated Volume Correction Factor• Special Procedure

CustomizingCustomizing CustomizingCustomizing

Calorific value procedure The following procedures are available for averaging the calorific value:

Arithmetic annual average The calorific values of the last 12 months are arithmetically averaged.

Weighted annual average The calorific values of the last 12 months are multiplied by the respective sendouts of each month. The sum of the products is divided by the total sendout during the 12 months. This results in the weighted annual average of the calorific values.

Arithmetic average of the billing period The calorific values of the months in the billing period are arithmetically averaged.

Weighted average of the billing period The calorific values of the months in the billing period are multiplied by the respective sendouts of each month. The sum of the products is divided by the total sendout during those months. This results in the weighted average of the billing period.

Volume correction factor procedure The volume correction factors (VCFs) allow you to convert volumetric gas consumption into standard cubic meters. The VCF is determined using the following components: temperature, air pressure, measured pressure, and the gas law deviation factor. In the VCF procedure, the system determines which components of the VCF play an important role in gas billing. If you choose volumetric gas billing, you do not have to maintain the components and activities of the VCFs.

Page 429: IUT 230 billing and invoicing

© SAP AG IUT230 11-11

SAP AG 2008

PremiseConnection Object

PostalRegional Structure

RegisterRegister

• Calorific Value District• Air Pressure Area• Temperature Area• Gas Pressure Area CustomizingCustomizing

Gas Procedure

Calorific Value

Volume Correction Factor

=

+

• No Thermal Gas Factors• Temperature• Temperature and Pressure• Temperature, Pressure and

Gas Law Deviation Factor

Installation Edit Help

Time-Dependent Data- Rate Category- Temperature Area

Gas Billing Type• Thermal• Volumetric• According to Standard

Cubic Meters

Gas Billing Type• Thermal• Volumetric• According to Standard

Cubic Meters

Installation

Gas Billing: Overview

Installation StructureGas Procedure

Fixed Temperature

Postal regional structure Regional data that influences billing for thermal gas billing can be stored in the postal regional structure. This data can be individually adjusted in the installation or installation structure.

Installation The rate category defines the type of gas billing.

Installation structure The gas procedure is defined here. It specifies how the calorific value and volume correction factor are determined.

Register description The register description defines which factors are already taken into account for gas billing.

Page 430: IUT 230 billing and invoicing

© SAP AG IUT230 11-12

SAP AG 2006

CustomizingCustomizing

Basic Functions

Master Data

Device Management

Contract Billing

Invoicing

FI-CA

Customer Service

Work Management

Information System

Tools

SAP UtilitiesSAP Utilities

Special FunctionsSpecial Functions

Gas BillingGas Billing

Volume Correction FactorVolume Correction Factor

Calorific ValueCalorific Value

Gas ProcedureGas Procedure

Allocation DataAllocation Data

Temperature, measured pressure, monthly/annualair pressure, defined VCF,VCF Procedure

Calorific value district, monthly/annualcalorific values, cogenerators,billing calorific values, calorific value procedures

Gas Billing: Customizing

Temperature The system either uses gas temperatures measured monthly or daily, or a fixed temperature.

Gas procedures The gas procedures group the volume correction factor procedure and the calorific value procedure.

Allocation data Here you can use the 'deviation' and 'default' fields to control how the gas month is to be defined. This is particularly relevant for entry of meter reading results.

Page 431: IUT 230 billing and invoicing

© SAP AG IUT230 11-13

SAP AG 2006

Volume Correction Factor

Air Pressure

Gas Temperature

Gas Pressure

Gas Law Deviation Factor, calculated using pressure and temperature

Calorific Value

Gas Billing Components

The gas law deviation factor is a ratio of the real gas factors of the gas in operating and standard conditions. It can be determined using the following methods:

Specified for each device

Calculated using pressure and temperature

Page 432: IUT 230 billing and invoicing

© SAP AG IUT230 11-14

SAP AG 2008

ST AP + Act.P 1VCF = ------- x ------------------- x -------

T SP GLDF

Temperature

Volume Correction Factor: 1

Standard temperature ST = 273.13 K

Standard air pressure SP = 013.25 mbar

Gas temperature T = ST + Gas temperature in °C

Air pressure AP

Actual pressure Act.P

Operating cubic meters Operating volume

Gas law deviation factor GLDF

Volume correction factor Ratio between standard and operating volume

Billing quantity Standard volume x Calorific value

Page 433: IUT 230 billing and invoicing

© SAP AG IUT230 11-15

SAP AG 2006

The following applies:MP = Measured pressure of the meterAP = Air pressureSP = Standard air pressureGLDF = Gas law deviation factorTo = Zero degrees on the temperature scale in use (Celsius or Fahrenheit)defined in absolute units (273.15 Kelvin or 460 Rankine) ST = Standard temperature (in absolute units, that is, Kelvin or Rankine)t = Gas temperature in a non-absolute unit (Celsius or Fahrenheit)

Standard Temperature in Absolute Units Zero Temperature in Absolute Units

VCF = ST * (MP + AP) / ((To + t) * SP * GLDF)

Volume Correction Factor <--> Temperature

Volume correction factor (VCF) SP and ST refer to standard physical conditions. In the metric system, the standard conditions in example 1 usually apply; in countries with non-metric systems, the standard conditions in example 2 can also apply. The constants To and ST are used to adjust the above formula so that you can enter the gas temperature t in the units of measure used in that country (such as degrees Celsius or Fahrenheit) into the corresponding temperature tables.

Example 1 Metric system: Gas temperature in degrees Celsius. The following values apply: ST = 273,15 Kelvin and To = ST = 273,15 Kelvin. In the temperature tables, t is maintained in degrees Celsius.

Example 2 English (imperial) system: Gas temperature in degrees Fahrenheit: The following values apply: ST = 520 Rankine and To = 460 Rankine (zero on the Fahrenheit scale). In the temperature tables, t is maintained in degrees Fahrenheit.

Page 434: IUT 230 billing and invoicing

© SAP AG IUT230 11-16

SAP AG 2006

Arithmetic Annual Average

Weighted Annual Average

Fixed Temperature

Arithmetic Average for the Billing Period

Weighted Average for the Billing Period

Arithmetic Annual Average

Weighted Annual Average

Fixed Temperature

Arithmetic Average for the Billing Period

Weighted Average for the Billing Period

Temperature Procedure

Page 435: IUT 230 billing and invoicing

© SAP AG IUT230 11-17

SAP AG 2008

ST AP + Act.P 1VCF = ------- x ------------------ x -----

T SP C

Pressure

Volume Correction Factor: 2

Page 436: IUT 230 billing and invoicing

© SAP AG IUT230 11-18

SAP AG 2006

Annual Air Pressure

Air Pressure Measured each Month

Arithmetic Average for the Billing Period

Weighted Average for the Billing Period

Air Pressure

Page 437: IUT 230 billing and invoicing

© SAP AG IUT230 11-19

SAP AG 2008

ST AP + Act.P 1VCF = ------- x ------------------- x -----

T SP C

Gas Law Deviation Factor

Volume Correction Factor: 3

Page 438: IUT 230 billing and invoicing

© SAP AG IUT230 11-20

SAP AG 2008

Gas Law Deviation Factor

At Device/Register Level

Taking Temperature and Pressure into Account

User Exit

Not Taken into Account

Not calculated explicitly in IS-U

Compressibility

Gas law deviation factor (GLDF) The following options are supported for calculating the GLDF:

per device The defined GLDF is maintained at register level.

using pressure and temperature Here, you must maintain the GLDF table with a sufficient range of values of GLDFs and their corresponding pressure and temperature values.

using a user exit A user exit is called up and is provided with all the essential parameters such as pressure and temperature. The user exit returns the compressibility. For example, this allows you to use the GERG88 or AGA-NX19 procedure in the user exit.

The GLDF not taken into account

Note that the GLDF is never calculated directly in IS-U. It must always be calculated using one of the above options.

Page 439: IUT 230 billing and invoicing

© SAP AG IUT230 11-21

SAP AG 2006

Arithmetic Annual Average

Weighted Annual Average

Arithmetic Average for the Billing Period

Weighted Average for the Billing Period

Calorific Value Procedure

Page 440: IUT 230 billing and invoicing

© SAP AG IUT230 11-22

SAP AG 2006

RegisterFixed Temperature

Gas Procedure

Rate CategoryType of Gas Billing (Thermal, Volumetric, According to Standard Cubic Meters)

Regional StructureDefault Value for Device Installations

Air Pressure Area

Temperature Area

Calorific Value District

Relevant Master Data

Page 441: IUT 230 billing and invoicing

© SAP AG IUT230 11-23

SAP AG 2006

Franchise Fee

Gas Billing

Reference Values/Lighting

Billing Deregulated Contracts

Archiving Billing Data

Special Types of Billing

Special Billing Features: 3

Page 442: IUT 230 billing and invoicing

© SAP AG IUT230 11-24

SAP AG 2006

Street lighting is billed using reference values from the installations facts

REFVAL04REFVAL05REFVAL06

REFVAL04REFVAL05REFVAL06

Variant Programs

Group ManagementIndividual ManagementDifferent Connection LoadsBilling Using Energy PricesBilling Using Demand Prices

Lighting

Group management: all lighting can be managed as one group. Lighting with specific connection loads are stored and billed together.

Individual management: in contrast to group management, each light is managed and linked to the regional structure separately.

Different connection loads: the connection loads of a light are divided into different operation modes. You can enter the following connection loads for a light:

Demand for 24 hour lighting

Demand for the whole night

Demand for half the night

Billing using energy prices: The energy consumed by the street lights can be measured or calculated. A burning hour calendar can be used for storing monthly lighting periods. Lighting duration can be subdivided according to usage type and operation type in the calendar.

Billing using demand prices: lighting demand is determined and evaluated using connection loads.

Page 443: IUT 230 billing and invoicing

© SAP AG IUT230 11-25

SAP AG 2006

Required in order to calculate charges that are not based on measurements

Stored in the installation facts

The following types of reference value exist:General reference values, for example for energy or water supply (connection loads, no. of people, floor area)

Lighting

Heating Installations

Installation Facts: Reference Values

You can define which type of reference value is dealt with here. Different fields are available in the transaction maintenance depending on what you define here.

Page 444: IUT 230 billing and invoicing

© SAP AG IUT230 11-26

SAP AG 2006

Lighting: The different values for operation types are used in the burning hour calendar.

Value 2 = value for billingIf you only specify value 1 (= entry value), then value 2 = value 1

Indicator: Not relevant for billing

Repetition factorFor example: Lighting of the same type

Rate type/rate fact group

Reference Values: Data Relevant to Billing

Value 1 is the entry value, or the installed value. It can be different from value 2, the value to be billed.

The repetition factor indicates how many reference values of the same type exist (such as lighting). These reference values do not have to be specified individually. However, if you wish to enter details about reference values (such as the address of the lighting), you must enter them individually. The value specified in the Value 2 field is multiplied by the repetition factor.

Page 445: IUT 230 billing and invoicing

© SAP AG IUT230 11-27

SAP AG 2006

Franchise Fee

Gas Billing

Reference Values/Lighting

Billing Deregulated Contracts

Archiving Billing Data

Special Types of Billing

Special Billing Features: 4

Page 446: IUT 230 billing and invoicing

© SAP AG IUT230 11-28

SAP AG 2008

Distribution

Procurement

Transmission

DistributionDisposal

Transmission

SupplyProcurement

Distribution

Trans-mission

GenerationProcurement

AdditionalAdditionalDivisionsDivisions

For example:For example:Local heatingLocal heating

Public transportPublic transportCable TVCable TV

Waste removalWaste removalSale of appliancesSale of appliances

. . . . .. . . . .

Usually jointUsually jointcustomer service/billingcustomer service/billing

C o n t r o l l i n gInternal company structure according to plants, clients, and groups

Usuallyjointmeter reading

Customer100100

T o t al

S a a le s T a x

S u b t o ta l

S A L E S P E R SO ND A T E

TotalP r ic eD e s c ri pt i onQ ty S h i pp e dQ ty Or d er e d

I N VO I C E #: P .O . #:

Kunde VbrStelleBillBill

bet weenbet weenXXXXXXXXXXXXXXXXXX

andandEVU AGEVU AG

nnnn n nn nn n nn nn n nn nn n nn n nn nnnn nn n nn nnn nn nn n nn nn n nn n nn nnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kuuuu u uu uu u uu uu u uuuu u uu u uuuu uu u uu uu u uu uu u uu uu u uu u uu

zzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzz

bet weenbet weenXXXXXXXXXXXXXXXXXX

andandEVU AGEVU AG

nn nn n nn nnn nn nn n nn nn n nn n nnnnnn nn nnn nn n nn nn n nn nn nnn n nn nnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kuu uu u uu uuu uu uu u uu uu u uu u uuuu uuu uu uu u uu uu u uu uu uuu u uu

zzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzz

bet weenbet weenXXXXXXXXXXXXXXXXXX

andEVU AGEVU AG

nn nn n nn nn n nn nn n nn nn n nn n nn nnnn nn n nn nn n nnnn n nn nn n nn n nn nnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kuu uu u uu uu u uu uu u uu uu u uu u uuuu uu u uu uu uuu uu u uu uu u uu u uu

zzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzz

betweenbetween< Customer >< Customer >

andand< Utility Company >< Utility Company >

MRresults

MRresults

Distribution

Transmission

GenerationProcurement

Structures of a Regulated Utility Company/Municipal Utility

In Germany, there are many more municipal utility companies providing various types of utilities and complementary services than in any other country. Some of them have managed to integrate as many as 7 different types of utilities and services in the one utility company.

They integrate all their services on one annual bill.

However, the liberalization of the energy market causes complex problems for these companies, as each area of the company develops differently in a deregulated market.

Page 447: IUT 230 billing and invoicing

© SAP AG IUT230 11-29

SAP AG 2006

OneDivision

SeveralDivisions

SingleUCs

SeveralUCs

StandardBilling

StandardBilling

Multi-SectorBilling

Multi-SectorBilling

UnbundledBilling

UnbundledBilling

ConvergentBilling

ConvergentBilling

UC: Utility company

Standard Billing: Standard Billing: Billing of one division for services rendered by one utility companyMultiMulti--Division Billing:Division Billing:Billing of several divisions for services rendered by one utility company

Unbundled Billing: Unbundled Billing: Billing of basic services from one division for services rendered by several utility companies

Convergent Billing: Convergent Billing: Billing of several divisions or several basic services from one division rendered by several utility companies.

. . . . In one system, and if desired on one bill!

Billing Scenarios

Two of the billing types above have already been mentioned:

Standard billing: billing of one division for services rendered by one utility company.

Multi-division billing: billing of several divisions for services rendered by one utility company

Two more types of billing are included in the deregulated utilities industry:

Unbundled billing: billing of basic services from one division for services rendered by several utility companies

Convergent billing: billing of several divisions or several basic services from one division rendered by several utility companies

And an important condition: in one system and, if desired, on one bill!

Page 448: IUT 230 billing and invoicing

© SAP AG IUT230 11-30

SAP AG 2006

OneDivision

SeveralDivisions

SingleUCs

SeveralUCs

StandardBilling

Multi-SectorBilling

UnbundledBilling

UnbundledBilling

ConvergentConvergentBillingBilling

UC: Utility Company

Example:

Home ElectricityProvider

Home ElectricityProvider

Cx/Electricity/Energy . . . . . . . USDC1/Electricity/Distribution. . . . USDC1/Electricity/Cust. Service. . . USDTP/Cont. to standard assets. . .USD---------------------------------------------Total: . . . . . . . . . . . . . . . . . . . USD

Bill Mr. Smith/<Address>Energy Supply Service:

CompetingElectricityProvider

CompetingElectricityProvider

C1 Cx

Billing Scenarios: Unbundled Billing

Example of unbundled billing:

Two utilities, the home utility C1 and the competing utility Cx, both provide electricity services.

Both utilities agree that C1 has lost a customer to Cx, but that C1 will remain responsible for distribution and customer service for that customer.

Example: C1 is responsible for the billing process and creates a bill.

On the bill, the green row displays energy generation by Cx.

The two blue lines display distribution and customer service by C1.

In the gray line on the bill, there is an additional charge for the customer's contribution to standard assets. This charge is processed by another company, TP.

Result: This bill contains business volume for three different companies.

Page 449: IUT 230 billing and invoicing

© SAP AG IUT230 11-31

SAP AG 2008

BusinessPartner

BusinessPartner

ContractA/R & A/PContractA/R & A/P

Installation 1Installation 1

DeviceDevice

Contract 1Contract 1

Installation 2Installation 2

Contract 2Contract 2

BillingRelatedInstallation

BillingRelatedInstallation

Contract 1 with home electricity providerBilling of transmission charges in company code 0001

Contract 2 with SuppliersBilling of supplied energy in company code 0002

DeviceLocationDevice

LocationTechnical Installation

MMM

SupplierSupplierMMM

IDEIntercompanyData Exchange

Home ElectricityHome Electricity

Deregulation in the IS-U Data Model 1

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

The device is installed in one installation along with its technical data.

The device is installed in an additional installation, along with its rate data with another company code.

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

Using the IDE component (Intercompany Data Exchange), you can create IDocs for the supplier when certain events occur (such as bill creation, incoming payments). This component can also process IDocs coming in from the suppliers.

Page 450: IUT 230 billing and invoicing

© SAP AG IUT230 11-32

SAP AG 2008

Installation 1Installation 1

DeviceDevice

Contract 1Contract 1 PoDService

PoDService

BillingRelatedInstallation

Contract, distributionof grid usage costs to billing

Point of delivery service 'utility'

DeviceLocationDevice

LocationTechnical Installation

BusinessPartner

BusinessPartner

ContractAccountContractAccount

PoDPoD

Distributor View

Deregulation in the IS-U Data Model 2

Page 451: IUT 230 billing and invoicing

© SAP AG IUT230 11-33

SAP AG 2006

Separation of Device Management and BillingSeparation of Device Management and Billing

Device Info Record

Used in the billing-oriented approachContains only device data that are relevant for billing

PM functions are not available

Acts like a technically installed deviceDevice allocations and register relationships are possible

Proration in the case of final billing-related removal

Serial numbers and meter reading processing handled like normal devices

Created directly or at the time of billing-related installation

Page 452: IUT 230 billing and invoicing

© SAP AG IUT230 11-34

SAP AG 2006

Advantages of Separation

Separation of Device Management and Billing

Reduced range of CCS functions for energy service providers

Reduced range of CCS functions for meter operators/system operators

Reduced system overhead costs and required quantity of data

Simultaneous use of different points of delivery

Sequential use of same point of delivery

High-performance IDE supports data exchange

Page 453: IUT 230 billing and invoicing

© SAP AG IUT230 11-35

SAP AG 2008

EquipmentDevice

EquipmentDevice

MaterialDevice

Category

MaterialDevice

Category

PremisePremise

RegionalStructureRegionalStructure

InstallationInstallation Technical LocationConnection Object

Technical LocationConnection Object

Installation Structure

Installation Structure

Billing-Related Device

Installation

Device Installation: Device Information Record

In the device installation, you can automatically create the device info record using the billing-related installation. This means that a technical installation in a device location is unnecessary. Using the billing-related device installation, you can maintain rate data at installation structure level for points of delivery or devices.

Page 454: IUT 230 billing and invoicing

© SAP AG IUT230 11-36

SAP AG 2006

Franchise Fee

Gas Billing

Reference Values/Lighting

Billing Deregulated Contracts

Archiving Billing Data

Special Types of Billing

Special Billing Features: 5

Page 455: IUT 230 billing and invoicing

© SAP AG IUT230 11-37

SAP AG 2006

R/3 DBR/3 DB

Application Data

Archiving Session

Archiving Program of the "Archiving Object"

R/3 Database Archive Files

Offline Storage

The Archiving Process: Overview

For further information, go to the SAP Help Portal at http://help.sap.com

Generating archive files: The archiving program writes the data to be archived, which is stored in the R/3 database, to the archive files. Deleting data: The delete program imports the data from the archive file and then deletes it from the database.

When implementing an archiving strategy, you should also consider how the archive files are stored. The archive files must be stored at a secure location so that, if required, they can be accessed at any time.

Page 456: IUT 230 billing and invoicing

© SAP AG IUT230 11-38

SAP AG 2006

Franchise Fee

Gas Billing

Reference Values/Lighting

Billing Deregulated Contracts

Archiving Billing Data

Special Types of Billing

Special Billing Features: 6

Page 457: IUT 230 billing and invoicing

© SAP AG IUT230 11-39

SAP AG 2006

Employee Billing

Company and Plant Consumption

Small Power Producers/Cogenerators

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.

Page 458: IUT 230 billing and invoicing

© SAP AG IUT230 11-40

SAP AG 2006

Controlling the Gross Price in the Schema

Ensures that the billing line items contain gross prices. The tax is not calculated.

Data: T-F-0022 Schema: E6

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.

Page 459: IUT 230 billing and invoicing

© SAP AG IUT230 11-41

SAP AG 2008

Price Definition Rate Data

Prices andRate FactsPrices andRate Facts

Schema

Rate VarProg. ValuesRate 1

. . .

- Step 1 VarProg. A x1- Step 2 VarProg. B x2

. . .Rate 2

- Step 1 VarProg. A Gross Price

- Step 2 VarProg. C Gross Price

- Step 3 VarProg. A Net Price

- Step 4 VarProg. C Net PriceRate n

- Step 1 VarProg. A xxx

Price

Rate 1

Rate n

. . . . . .Generate

BillingLine Items

Check BillingResults

Execute Variant

Programs in Acc. with Schema

Net Price

and

Gross Price

GrossGroup

GrossLine It.

XZXZ

Gross Price Billing

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.

Page 460: IUT 230 billing and invoicing

© SAP AG IUT230 11-42

SAP AG 2006

Gross GroupGross Line Items

Net PriceNet Price

Variant Pr. Operand Gross Group Gross Line It. Relevant for PostingQUANTI01 BPreis ABC X EMPTY QUANTI01 NPreis ABC EMPTY X QUANTI01 KAbgabe ABC EMPTY X

Gross PriceGross Price

Sample 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.

Page 461: IUT 230 billing and invoicing

© SAP AG IUT230 11-43

SAP AG 2008

Application Example RTP Interface

Billing a commercial and industrial customer using an interval readingDetermine billing-relevant data

Consumption during the on-peak rate period

Consumption during the off-peak period

Max. demand

RTP Interface

IS-U/CCSBilling

Off-peak consumptionOff-peak consumption

Max. demandMax. demand

On-peak consumptionOn-peak consumption

EDMRepository

Data: TR0101A030Schema: EDM

Page 462: IUT 230 billing and invoicing

© SAP AG IUT230 11-44

SAP AG 2006

Example for Time-of-Use EDM

XXMax. demand

On-peak Off-peak

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

Page 463: IUT 230 billing and invoicing

© SAP AG IUT230 11-45

SAP AG 2008

Synthetic Profile

Su 03.28. Mo 03.29 Tu 03.30 We 03.31 Th 04.01 Fr 04.02 Sa 04.03 Su 04.04 Mo 04.05 Tu 04.06

Winter Summer

Working Day Working Day Working DayWeekendWeekend

Day profile 102

Day profile 101

Day profile 103

Day profile 104

Day profile 103

Installation: T-F-0011LSchema: E11

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.

Page 464: IUT 230 billing and invoicing

© SAP AG IUT230 11-46

SAP AG 2008

Customer consumption fromconsumption determination =

900 kWh

Th Fr Sa Su Mo Tu We Th Fr Sa 01.01.2003

Summer

Weekday

Summer

Weekday

Winter

Weekday

Winter

Weekday

Winter

Weekday

Winter

Weekday

Winter

Weekday

Summer

Weekend

Winter

Weekend

Summer

WeekendSynthetic profile for customer

group

Usage Factor

12.31.2003

Standardized to 1000 kWh p.a.

Usage factor =Customer consumption

Standardized profile consumption

= 900 kWh1,000 kWh

= 0,9

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.

Page 465: IUT 230 billing and invoicing

© SAP AG IUT230 11-47

SAP AG 2008

BusinessPartner

BusinessPartner

ContractAccountContractAccount

Installation 1Installation 1

DeviceDevice

Contract 1Contract 1

Installation 2Installation 2

Contract 2Contract 2

BillingRelatedInstallation

BillingRelatedInstallation

Water contract 1 with utility company in company code 0001

Waste water contract 2 with disposal company in company code 0002

DeviceLocationDevice

LocationTechnical Installn.

MMM

Waste waterWaste waterMMMWater utility Water utility

companycompany

Water and Waste Water Billing

Installation: T-F-0034Schema: S1

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.

Page 466: IUT 230 billing and invoicing

© SAP AG IUT230 11-48

SAP AG 2006

Consumption History

Consumption History

CIC Customer Overview

Installation: T-F-0005Schema: E5

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.

Page 467: IUT 230 billing and invoicing

© SAP AG IUT230 11-49

SAP AG 2008

Prices

Operands

Rates

Schemas

Rate

Categories

Rate Determinations

CUST QTSTComplete transport of allbilling master dataorselective rate transport

Transport of Billing Master Data

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.

Page 468: IUT 230 billing and invoicing

© SAP AG IUT230 11-50

SAP AG 2006

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).

Dynamic Period Control (DPC)

Page 469: IUT 230 billing and invoicing

© SAP AG IUT230 11-51

SAP AG 2006

Monthly scheduled billing

1.1.01 7.1.01|------|------|------|------|------|------| R E E E E E R

R = Real meter readingE = Estimated meter reading

5 estimated billing documents, which are corrected using one billing document with the correct values

|------|------|------|------|------|------|

|----------------------------------------|

Example of Using DPC

Page 470: IUT 230 billing and invoicing

© SAP AG IUT230 11-52

SAP AG 2006

You can also use the actual billing document to correct the following time slices:

|------|------|------|------|------|------|

|---------------------------------| All estimated billing documents in a time slice

|------|------|------|------|------|------| All estimated billing documents in the original time slice

Flexibility

Page 471: IUT 230 billing and invoicing

© SAP AG IUT230 11-53

SAP AG 2006

Billing Period Categories

Determining the current period: 4 possibilitiesThe current period can lie between the real and the estimated meter readings|------| R E

The current period can lie between two estimated meter readings|------| E E

The current period can lie between the estimated and the real meter reading|------|

E R

The current period can lie between two real meter readings|------|

R R

Page 472: IUT 230 billing and invoicing

© SAP AG IUT230 11-54

SAP AG 2006

Two options for multiple-contract billing in IS-U:

EDM (Energy Data Management)Formation of meter reading data pool before billing is carried out

Aggregation of technical data

Multiple-contract billing (as of CRM 4.0 only using the Master Agreement in CRM)

Pool formation during billing

Aggregation of business data

Multiple-Contract Billing: EDM

Page 473: IUT 230 billing and invoicing

© SAP AG IUT230 11-55

SAP AG 2006

X axis

Demand-time profile ofsubsidiary company 1

kW

Y-Ax

is

X -A x i s

Demand-time profile ofsubsidiary company 2

kW

Y-Ax

is

X -A x is

kW+ + .. +X axis

100

200

300

kW

Total demand of thecompany

Aggregated demand-timeprofile of the company

X axis

10

20

30

100

200

300

kW

Total demand of thecompany

X axis

kW

Contractually-agreeddemand

[ ]* 50,0

0

1

00,

00

1

50,0

0

200

.00

00:00 0 2:00 0 4:0 0 0 6:0 0 08:0 0 10:0 0 12: 00 14: 00 16: 00 18: 00 20 :00 22 :00 24 :00

DM/MW

Provisional current price

500,

00

100

0,00

150

0,00

2

000

.00

00:00 0 2:00 0 4:0 0 0 6:0 0 08:0 0 10:0 0 12: 00 14: 00 16: 00 18: 00 20 :00 22 :00 24 :00

EURO

Company energy costs for additional demand

-

Sum of allintervalsSum of allintervals

Billing with EDM

Page 474: IUT 230 billing and invoicing

© SAP AG IUT230 11-56

SAP AG 2006

Serial Switching Processing Options

The SAP IS-U 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. Installation groups are available as of SAP IS-U Release 4.72.

Overview Register Relationship 02 Rate Solution Inst. Groups Only install secondary register in secondary installation - - ++ Read primary and secondary registers on different days - - ++ Independent billing cycles for primary and secondary installations ++ ++ - Only standard rates required ++ - - Dependent validations ++ + + Multiple primary registers permitted - ++ ++ Negative difference consumptions permitted - ++ ++ Bill primary installation despite missing meter reading results for secondary installation +/++ +/++ ++ Distribution of consumption values and amounts to secondary installations is possible - - ++ Multi-level serial switchings ++ + + Budget billing simulation ++ ++ -

Legend: - Not supported + Supported, but high workload ++ Is supported

Page 475: IUT 230 billing and invoicing

© SAP AG IUT230 11-57

SAP AG 2006

Serial Switching

Primary installation

Secondary installation

SA1

Secondary installation

SA2

Secondary installation

SB2

Secondary installation

SB1

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.

Page 476: IUT 230 billing and invoicing

© SAP AG IUT230 11-58

SAP AG 2006

Highlights of Billing Installation Groups

Installation group connects multiple installationsBilling allows the exchange of data within an installation group

Customizing controls access to secondary installation consumption valuesDistribution as BAdIConnection of billing documents

Sequence control for billingInterval checks for meter reading resultsMove meter reading resultsSimulation of missing meter reading results and correction with DPC IIReversal

Reversal of the entire installation groupIndividual reversal

OutsortingOutsorting of all documents for distribution bills

MonitoringInstallation group as a selection criteria

Page 477: IUT 230 billing and invoicing

© SAP AG IUT230 11-59

SAP AG 2006

Consumption Distribution

Secondary Installation

SA1

Secondary Installation

SA2

Secondary Installation

SB2

SecondaryInstallation

SB1

Primary Installation MA

Data: T-F-0045 ...Schema: ISUWS002

Data: T-F-0044Schema: ISUWM002

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.

Page 478: IUT 230 billing and invoicing

© SAP AG IUT230 11-60

SAP AG 2008

Special Billing Features: Summary

SAP AG

The system supports the different franchise fee procedures.Gas billing in the SAP Utilities system represents different gas procedures.Assigning reference values enables you to bill lighting consumption. You can use the SAP Utilities data model and the universal billing engine for new types of billing in the deregulated utilities market.SAP Utilities provides archiving tools for large quantities of data. SAP Utilities provides methods for special types of billing.

Page 479: IUT 230 billing and invoicing

© SAP AG IUT230 12-1

SAP AG 2006SAP AG 2006

Sales StatisticsData Warehouse Concept

SAP Business Information Warehouse (BW)

Sales Statistics: (Appendix A)

Page 480: IUT 230 billing and invoicing

© SAP AG IUT230 12-2

SAP AG 2006SAP AG 2006

At the conclusion of this unit, you will be able to:

Describe the Data Warehouse concept

Describe the information from the application to the SAP Business Information Warehouse (BW)

Sales Statistics: Unit Objectives

Page 481: IUT 230 billing and invoicing

© SAP AG IUT230 12-3

SAP AG 2006

OnlineTransactionProcessing

DATAWARE-HOUSE

OLTP

OLAP

Analysis Tools

OnlineAnalytical

Processing

Summarized Information

Integrated Application Modules

ExternalData Sales and

Distribution Finance

IS-U/CCSMaterial

Management

Data Warehouse Concept

In the implementation of more performant, integrated information systems, the newest Data Warehouse concepts are based on a three-tiered model.

The three levels subdivide the complete flow of data from capturing data in operational systems to displaying information.

Operational, integrated applications in OLTP systems form the basis for capturing information. Large amounts of master and process data are collected in these applications, which then need to be displayed in a more refined form using information systems.

The data from the applications is summarized to a subset of meaningful key figure values, and is managed separately in database tables in a Data Warehouse.

In the third level, the statistics data gathered in the Data Warehouse is available to various analysis tools for evaluation.

The analysis tools provide a large array of options for high-quality analysis and presentation of statistical data. Thus they provide modern management with a performant tool for making quick decisions.

Page 482: IUT 230 billing and invoicing

© SAP AG IUT230 12-4

SAP AG 2006

Business Information Warehouse (BW)

Utilities

The SAP Business Information Warehouse (BW) is the mySAP.com business component that is used to extract and analyze data from operative business applications (OLTP systems). In addition to OLTP systems such as R/3 and SAP BBP (Business-to-Business Procurement: E-commerce business process used by employees to purchase goods and services directly from other suppliers), other external data sources such as databases or online services can also be integrated. OLTP stands for online transaction processing.

The SAP Business Information Warehouse supports online analytical processing (OLAP) and is designed to process large volumes of operational and historical data.

SAP BW contains all of the meta data required for common business processes. This includes InfoSources, InfoObjects, InfoCubes and standard reports, transfer structures for all releases and communication structures and update rules for each InfoCube. These elements form part of a “ready-to-go”strategy that supports automatic data transfer with immediate analysis once the system has been installed and the source system defined.

SAP BW requests application data from the source systems that have been assigned at regular intervals (pull-mechanism). Back-end systems contain extractors that collect data and transfer it to the SAP Business Information Warehouse.

Page 483: IUT 230 billing and invoicing

© SAP AG IUT230 12-5

SAP AG 2006

Data Extraction and Transformation

BW

SE

RVE

R

Transformation rulesTransformation rulesTransformation rulesTransformation rules Update rulesUpdate rulesUpdate rulesUpdate rules

Operational datastoreOperational datastore

DataSources DataSources

Update rulesUpdate rulesUpdate rulesUpdate rules

OLAP Processor

PSA PSA

InfoSources

BEx

Page 484: IUT 230 billing and invoicing

© SAP AG IUT230 12-6

SAP AG 2006

Query

Workbook

Transformation

InfoObject Regional StructureRegional StructureRegional StructureBusiness PartnerBusiness Partner

Extractor

InfoCube

InfoSource

Best-Practice ModelBest-Practice Model

Individualiza

tion

Standard

s

Business Content

Extractor Function model used to fill OLTP InfoObjects and InfoCubes for each infoSource.

InfoSource Structure that defines the fields (infoObjects) to be loaded in to the Business Information Warehouse (BW). An InfoSource can include extractors from different OLTP systems or dataSources.

InfoObjects Fields to be loaded into the BW (for example, billed amount, date of bill, business partner, and so on). Can be either characteristics or key figures.

Info Cubes Central objects on which analyses are based. They are closed datasets that are filled and aggregated according to their defined transformation rules.

Query Configurable view of InfoCube data.

Workbook A presentation layer of queries that can be stored as a self-contained dataset.

Page 485: IUT 230 billing and invoicing

© SAP AG IUT230 12-7

SAP AG 2008

IndustryIndustry

AttributesAttributes157 005

398

Revenue

Time ReferenceTime ReferenceTime Reference

RateRate NetAmount

NetNetAmountAmount

EnergyAmountEnergyEnergyAmountAmount

Demand Amount

Demand Demand AmountAmount

Billed QuantityBilled Billed

QuantityQuantity

MonthMonthMonth20062006

Jan. Feb.Mar.Apr. MayJunJuly . . .. . .. . .

Structuring Statistics

Key FiguresKey Figures

There are three basic types of information in an information structure:

Characteristics are criteria that you define for collecting data on a particular subject. For example, in BW you require information about divisions, rate categories, rates, industries, and billing classes.

The period unit is another criteria used in information structures. You can collect data for a specific day, week, month, or posting period.

Key figures provide key business information with regard to a certain characteristic.

From a technical perspective, characteristics and periods are essential units for sorting data in databases.

Page 486: IUT 230 billing and invoicing

© SAP AG IUT230 12-8

SAP AG 2006

BillingQuantity

April 2006 Bill 4711

1000 kWh

Jan Feb Mar Apr

ABAB

Jan Feb Mar Apr

BUDATBUDAT

Billing document invoiced

BillingQuantity

Period Determination

The system determines the period using the source date.

You can select different periods If you use the from-date of the billing line items, the total consumption for that billing period is divided up among the individual months using the set weighting procedure. You can also use the posting date. In this case, all consumption quantities are set to the posting date.

Page 487: IUT 230 billing and invoicing

© SAP AG IUT230 12-9

SAP AG 2006

General LedgerContract Accounts Receivable and PayableSales & DistributionMaint. & Serv. Mgmt, Material MgmtERP Central FunctionsIS-U

PM/PM/EquipmEquipm..

TotalsTotalsdocumentdocument

FIFI--CACAdocumentdocument

General General ledgerledgerdocumentdocument

InvoiceInvoicedocumentdocument

InvoicingInvoicingrequestrequest

SD cust.SD cust.

BillingBillingdocumentdocument

BusinessBusinesspartnerpartner

ContractContractaccountaccount

ContractContract

WarehouseWarehouse PurchasePurchaserequisitionrequisition

InstallationInstallation

DeviceDevice

RegisterRegister

DeviceDevicecategorycategory

TechnicalTechnicaldevicedevice ((categorycategory) )

datadata

MRMRresultresult

MRMRorderorder

CustomerCustomercontactcontact

BillingBillingportionportion

MRMRunitunit

PremisePremise

SchedulingScheduling

ScheduleScheduledatadata

ConnectionConnectionobjectobject/FL/FL

Rates, Rates, pricespricesconditionsconditions

DevDev. . locationlocation/ FL/ FL

ISIS--U U addadd..

Service Service notificationnotification

ConnectionConnection//EquipmentEquipment

CustomerCustomerinquiryinquiry

RegionalRegionalstructurestructure

Post.Post.Pol.Pol.CompComp..

GridGrid

MM/MM/MaterialMaterial

ISIS--U U addadd..

WorkWork orderorder((externalexternal))

Work orderWork order(internal)(internal)

ContractSD

The IS-U Data Model (Simplified)

With ERP2005, the IS-U data model is almost as complete as the content in BW.

Page 488: IUT 230 billing and invoicing

© SAP AG IUT230 12-10

SAP AG 2008

Reporting/Analysis

BW Content Transaction Data

ConsumptionRevenue

FI-CA

IS-U/CRMMaster Data

Device Management

Meter Reading

Data

KPI Process(BPEM)

Page 489: IUT 230 billing and invoicing

© SAP AG IUT230 12-11

SAP AG 2006

IS-U/CCS Business Content (1)

Stock statistics-> History of contracts, business partners, devices, ...

Transaction statistics-> Manually executed transactions (move-in, move-out, device replacement, ...)

Sales statistics – More than just sales figures-> Invoiced quantities, net and tax amounts- Reversal rates- Error handling- Master data checks (address check in exit)

Consumption statistics-> (Billed and extrapolated quantities and amounts)Target group selection possible, based on current data and consumption values

Stock statistics map the history of the stocks. The number of contracts, for example, distributed in a region during the last 12 months lies at the center of the analysis not, for example, a list of all contracts within a region.

Transaction statistics show the number of monthly transactions and processes. Only the manual transactions are entered and registered here, as these statistics display the utilization of the employee. The difference between manual and automatic transactions is highlighted by two examples:

Move-in is performed automatically in migration and IDE scenarios. This is automatic processing and is, therefore, not included in the statistics

Mass invoicing is also not relevant for the transaction statistics, whereas manual single invoicing represents an expense with regards to these statistics.

Page 490: IUT 230 billing and invoicing

© SAP AG IUT230 12-12

SAP AG 2006

IS-U objects (contracts, contract accounts, ...) as master data in BW-> Master data reporting (for example, list of all customers with water contract)

Unbilled revenue reporting-> Changes in the project are made using BW-BPS

Open items and cleared items-> (operational and strategic reporting)

CRM integration also in analytical areas-> For example:

- Comparison of campaigns in CRM and IS-U content- Analysis of sales figures for customers and their activities

IS-U/CCS Business Content (2)

Page 491: IUT 230 billing and invoicing

© SAP AG IUT230 12-13

SAP AG 2006

STATISTICS GROUPSSTATISTICS GROUPS

Statistics groups forStatistics groups for ContractsContractsRatecategories

Ratecategories

Standardcustomers

C&Icustomers

Division Contract Rate cat. Update group01 ’ ‘’ ‘ 0101 SISU

01 0101 0101 Z00001

Residentialcustomers

Individualstatistics

Stats. group ‘ ‘ Stats. group 01Stats. group 02 Stats. group 01

Determination of Update Group

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.

Page 492: IUT 230 billing and invoicing

© SAP AG IUT230 12-14

SAP AG 2006

Statistics GroupStatistics Group

Update GroupSISU

Update GroupUpdate GroupSISU SISU

CustomerSchultz

CustomerCustomerSchultzSchultz

Update GroupZIND

Update GroupUpdate GroupZINDZIND

CustomerSAP

CustomerCustomerSAPSAP

UpdateUpdateRulesRules UpdateUpdate

RulesRules

1.1.

2.2. 3.3.

BW

Customer = “Dummy”

Customer = “Dummy”

Customer = “SAP”

Customer = “SAP”

If update group = SISUthenname = “Dummy”

Why Update Groups?

Billing Document

Division 01

Statistics Group ‘ ‘Contract

Statistics Group 01Rate Category

Update GroupSISU

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

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

Page 493: IUT 230 billing and invoicing

© SAP AG IUT230 12-15

SAP AG 2006

E1 SchemeRate Var.Pr. Stat. Group: QuantityRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002

. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002

I_ABRMENGE

Stat. Group ‘000001’

I_ABRMENGE

Stat. Group ‘000001’ COCO--

PAPA

WWABRWWABRWWLEIWWLEI COCO--

PAPA

WWABRWWABRWWLEIWWLEI

CO-PA Actual Data(Yes/No)

CO-PA Actual Data(Yes/No)

Statistics Groups: Quantities

CO-PA StatisticalData

CO-PA StatisticalData

Billing DocumentBilling Document

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

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.

Page 494: IUT 230 billing and invoicing

© SAP AG IUT230 12-16

SAP AG 2008

Schema E1Rate Var.pr. Stat. Group: AmountRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002

. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002

NETTOBTR

Stat. group ‘000001’

NETTOBTR

Stat. group ‘000001’

VVNETVVNETVVARBVVARBVVLEIVVLEI

CO-PA Actual Data(Always Transfer)

CO-PA Actual Data(Always Transfer)

Statistics Groups: Amounts

Billing DocumentBilling Document

COCO--PAPA

COCO--PAPA

VVNETVVNETVVARBVVARBVVLEIVVLEI

CO-PA StatisticalData

CO-PA StatisticalData

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 the BW. 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 the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.

Page 495: IUT 230 billing and invoicing

© SAP AG IUT230 12-17

SAP AG 2006

Unbilled Revenue Reporting (New with BW 3.53)

URR InfoCubeURR InfoCube

URR InfoCubeURR InfoCube

Simulation IDSimulation ID

Simulation IDSimulation ID

Query1. Selection of SIM ID by user

2. Automatic derivation of print document creation date from SIM ID run date (by variable exit)

Sales statisticsSales statistics

Sales statisticsSales statistics

MultiCubeMultiCube

For performance reasons, data modeling for unbilled revenue reporting has been moved to SAP BW. Instead of storing all URR data in a Cube, the extrapolation data 0UCSA_C06 and the actual data 0UCSA_C05 is evaluated using MultiCube 0UCS_MC01

The data is identified using the simulation ID (extrapolation data) and the creation date of the print document (actual data). Therefore, the CPU date of the print doucment must be included in the SalesCube. (if necessary, include in exit BWESTA01).

The variable exit for the print document creation date is then called and filled in the query as a result of the simulation ID selection. (see standard example queries).

Before carrying out unbilled revenue reporting, you should read the Unbilled Revenue Reporting cookbook in the Service Marketplace. BW also contains Queries for MultiProvider "Simulated/Actual Sales Statistics" 0UCS_MC01, which you can use templates in BW.

Unbilled revenue reporting takes places in steps: 1. The actual data is stored in the sales statistics cube 0UCSA_C05 with the creation date for invoicing. 2. The simulted data is entered in the extrapolation cube 0UCSA_C06 with the simulation ID of the corresponding extrapolation run in IS-U. 3. The simulation ID contains the date that the extrapolation was started in IS-U. 4. All simulation data is analyzed in the MultiProvider using the simulation ID and the creation date <= start date.

Page 496: IUT 230 billing and invoicing

© SAP AG IUT230 12-18

SAP AG 2006

BillingDocuments and Master

Data

BillingDocuments and Master

Data

1.

Sales Statistics DS 0UC_SALES_STATS_01

Only closed reconciliation key

1. Full request from BW (1)Full update is supported and must be used if the same documents are to be extracted again or the documents are to be extracted for the first time

2. Initial request from BW (2)Initial request does not supply much data; only documents that were created after the full update

3. Delta request from BW (3)All new and reversed bills since the last Delta request

2.

3.

The sales statistics are the most important IS-U statistics for energy companies. For this reason we have gone to great lengths to improve performance during extraction, and the corresponding error handling. The following are the most important points:

Index Table DBESTA_BWPROTAll reconciliations that were created when invoicing contracts are saved here. During the extraction, the system checks whether the reconciliation key is closed, and then imports and extracts all documents for this reconciliation key.

Index Table DBESTA_BWPROTEAll invoicing documents that could not be extracted due to an incorrect status or error handling in the BEWSTA01 user exit are saved here. Correct the cause of the error. During each extraction run the system attempts to reload documents from this index table. If this is not possible, then the entry remains in the table. You must read the application log for the extraction. Either in the BW monitor (a message is issued if an error has been detected in the extractor) or within the mass activity (transaction EBW_DQ_SS).

Continued on the next slide.

Page 497: IUT 230 billing and invoicing

© SAP AG IUT230 12-19

SAP AG 2008

BillingDocuments and Master

Data

BillingDocuments and Master

Data

1.

Sales Statistics DS 0UC_SALES_STATS_02

Only closed reconciliation key

1. Full request from BW (1)Full update is supported and must be used if the same documents are to be extracted again or the documents are to be extracted for the first time

NO data is extracted; Index table DBESTA_BWPROT is stored

2. Initial request from BW (2)Initial request does NOT supply any data; only initialization takes place

3. Start mass activity in OLTP (3)All new and reversed bills since the last delta request are written in the delta queue via parallel processing

4. Delta request from BW (4)All entries in the delta queue are extracted (performance tip: Execute delta request twice)

2.

3. Delta QueueDelta

Queue4.

User Exit BWESTA01If you need to make adjustments to the sales extractor (import additional tables, change values), then you should never use the RSAP0001 generic BW exit. Instead you should use this user exit. This exit is run for each billing document. As well as the billing document, it also has many other tables in the interface (note the interface for the exit). This avoids most performance-intensive and time-consuming saving procedures. In addition, the exit also allows you to trigger an exception or error message of category 'E'. This means that the document is not extracted and written in the DBESTA_BWPROTE index table. Take advantage of the enhanced check in the exit. This has little effect on the performance, but significantly increases the time and effort required for subsequent corrections. Some cusotmers check address data here (for example, have the address codes been maintained?).

User Exit BWESTA02Normally only those documents are extracted, whose reconciliation key have been closed. This restriction is not sufficient for some customers. In order to be able to make comparisons with the general ledger, you should only process the reconciliation keys that have actually been transferred to the general ledger. For this reason you can check the reconciliation key in greater detail in this exit. However, you cannot extract an open reconciliation key.

For more information on the loading mechanism, see note 438606.

Page 498: IUT 230 billing and invoicing

© SAP AG IUT230 12-20

SAP AG 2006SAP AG 2006

Sales statistics data is kept in a data warehouse.

The SAP Business Information Warehouse means you do not have to use the UIS.

The detailed modeling of the 'Quantity and Amount' statistics groups and their proper use in the billing schema directly influences the storage of information in the SAP BW.

Note: The BW project group must be informed of the features of and every change to the statistics groups!

Sales Statistics: Unit Summary

Page 499: IUT 230 billing and invoicing

© SAP AG IUT230 13-1

SAP AG 2006

Contents:

Program Enhancement (Attachment B)

Technology of program enhancement

Program enhancements - billing

Program enhancements - invoicing

Page 500: IUT 230 billing and invoicing

© SAP AG IUT230 13-2

SAP AG 2008

Technology of Program Enhancements

Yes

Yes

No

No

SAP Utilities Program(Event)

SAP Utilities Program(Continuation)

Customer-specific

Industry-specific

Standardprogram

ISprogram

Customerprogram

Flexibility without modification of SAP programs

Page 501: IUT 230 billing and invoicing

© SAP AG IUT230 13-3

SAP AG 2008

Standard FunctionalityTFKFBMEvent

1330............

Text

Due date datedetermination

...

...

...

...

ABAP/4 module

FKK_SAMPLE_1330............

Industry FunctionalityTFKFBSEvent

R400............

Text

Clearing types............

ABAP/4 module

ISU_CLEARING_TYPE_R400............

Customer FunctionalityTFKFBCEvent

...

...R403

...

...

Text

...

...Invoicing unit

...

...

ABAP/4 module

...

...Z_USER_R403

...

...

SAPxxxxx

Program

...Event 1330

...

...Event R400

...

...Event R403

...

...

...

Technology of Program Enhancements

Page 502: IUT 230 billing and invoicing

© SAP AG IUT230 13-4

SAP AG 2006

Program Enhancements - Billing

EBIA0001 IS-U: Maintain customer-specific fields in billing document

EBIA0002 IS-U: Proration according to customer-specific schedules

EBIA0003 IS-U: Customer-specific checks in billing and overall check

EBIA0004 IS-U: User exit external calculation of compressibility

EBIA0005 IS-U: Termination of mass runs

EBIA0006 IS-U: Period control: Determine time portions in billing

EBIA0007 IS-U: Customer-specific actions in billing reversal

EBIA0008 IS-U: Customer-specific actions in the update of billing reversal

EBIA0009 IS-U: Move-in/move-out adjustment to the day/to the month

EBIA0011 IS-U: Billing update

EBIA0012 IS-U: Maintain customer data in the billing obj. OBJ

EBIA0013 IS-U: Customer checks in the billing selection

EBIA0014 IS-U: Maintain customer-specific fields in manual billing

EBIA0015 IS-U: Backbilling user exit

EBIA0016 IS-U: Determination of billing calorific value

Page 503: IUT 230 billing and invoicing

© SAP AG IUT230 13-5

SAP AG 2006

Program Enhancements - Billing II

EBIA0017 IS-U: Individual document display

EBIA0018 IS-U: Customer requirements during line item combination

EBIA0019 IS-U: Customer-specific bill comparison

EBIA0020 IS-U: Change current period during dynamic period control

EBIA0021 IS-U: Change current billing period during dynamic period control

EBIA0022 IS-U: Change contract sequence for billing

EBIA0023 IS-U: Fact checks

EBIA0024 IS-U: Enhancement for determining special operand value

EBIA0025 IS-U: Determine different weighting for measured quantities

EBIA0026 IS-U: Post processing of gas factors

EBIA0027 IS-U: Authority check for facts (enhancement)

EBIA0028 IS-U: Maintain/save customer facts in billing object

EBIA0029 IS-U: Permit repeated adjustment reversal

Page 504: IUT 230 billing and invoicing

© SAP AG IUT230 13-6

SAP AG 2006

Program Enhancements - Billing III

EBIA0030 User exit for customer overview reports in the BRE

EBIC0001 IS-U: Determine evaluation group for consumption history

EBIS0001 IS-U: User exit for external prices (EBL)

EBIS0002 IS-U: Enhancement for rate type and rate fact group

EBIS0003 IS-U: Reference value - Integration of customer-specific fields

EBIS0004 IS-U: Front office output of historical consumption values

EBIS0005 User exit for transferring installation facts

EBIS0006 IS-U: Rate category - subscreen integration and field checks

EBIS0007 IS-U: User exit for price checks

EBIS0008 IS-U: User exit for checking calorific value

EBIS0009 IS-U: Enhancement for displaying currency in facts

EBIS0010 IS-U: Enhancement for customer-specific transport control

Page 505: IUT 230 billing and invoicing

© SAP AG IUT230 13-7

SAP AG 2008

Program Enhancements: Invoicing I

R400: Determination of clearing type / change to document type

R401: Selection of items for account maintenance

R402: Enhancement of invoicing contract accounting documents

For creating business partner and general ledger items

Prevents the posting of documents with zero amounts

For creating new posting documents

R403: Customer-specific definition of invoicing units – what billing documents are invoiced together

R404: Transfer of dunning information

R405: Addition of customer-specific information from billing documents to posting items

R408: Data on revenue recognition (delayed revenue posting)

R409: Enhancement of rounding items, in which bill amount rounding has taken place

R410: Selection of items that are to be printed in the bill, or to be included in the final bill amount

Overrides the Customizing settings in “Item Selection for Bill Display (TE529)”

For further information on the program enhancements, see the documentation on each sample module.

The sample modules must have the naming convention ISU_SAMPLE_<Event>

Sample modules are stored in the function group E21U.

Create your customer-specific modules in a copy of the function group E21U.

You must save the customer-specific modules in the table TFKFBC. You maintain this in Customizing for Financial Accounting, under Contract Accounts Receivable and Payable -> Program Enhancements -> Define Customer-Specific Function Modules.

Page 506: IUT 230 billing and invoicing

© SAP AG IUT230 13-8

SAP AG 2006

Program Enhancements - Invoicing II

R411: Document selection for due date adjustmentR412: Set permanent or temporary print blocksR413: Tax determination for billing (change tax code)R417: Override due dateR428: Maintain customer-specific fields in the invoicing order (EITR)R430: Determine payment method for business partner items and set clearing restrictions

When used in connection with the 'due date adjustment', you can make the appropriate settings so that items from the current bill are requested with the next bill.

R431: Invoicing unit is finishedR433: Print document number is assigned - update customer-specific tables etc.R434: Rollback of customer-specific enhancements for processing errors (see events R431 and R433)R436: Maintain customer-specific fields in the print document

Is connected to the Customizing include "CI_ERDZ" in the print document line items

Page 507: IUT 230 billing and invoicing

© SAP AG IUT230 13-9

SAP AG 2006

Program Enhancements - Invoicing III

R437: Set parameter for each invoicing unit

R469: Invoice reversal: Set print block

R470: Invoice reversal: Check permissibility

R471: Reversal document number is assigned - update customer-specific tables etc.

R472: Rollback customer-specific enhancements for processing errors

R501: Determine posting date and document type

R979: Customer-specific definition of LPC amount

R983: Set payment lock for items

Page 508: IUT 230 billing and invoicing

© SAP AG IUT230 13-10

SAP AG 2006

Program Enhancements - Budget Billing Plan 1

R923: Amount transfer in portion change

R925: Change date when adding a budget billing plan

R974: Create ABP: Amount limits per contract

R976: Amount change of budget billing amount items

R977: Amount change for several due dates

R978: Budget billing request, adjust due dates

R984: Determine extrapolation period

R985: Add contract to existing budget billing plan, change budget billing amounts

R987: Change printed or migrated items

R988: Use general ledger account as key

R989: Change creation date

R990: YAP documents when creating budget billing plan

R991: Post YAP bonus in invoicing

Page 509: IUT 230 billing and invoicing

© SAP AG IUT230 13-11

SAP AG 2006

Program Enhancements - Budget Billing Plan II

R992: Change due date when creating budget billing plan

R469: Invoice reversal: Set print block

R994: Change budget billing amount (when creating and adjusting)

R995: Manipulate budget billing / adjust standard budget billingamount

EA610002: Correct items in a budget billing plan

EINA0001: Dynamic budget billing cycle determination

Page 510: IUT 230 billing and invoicing

© SAP AG IUT230 13-12

Page 511: IUT 230 billing and invoicing

© SAP AG IUT230 14-1

SAP AG 2003

Appendixes C and D

SAP AG 2001

Appendix C: Billing Commercial and Industrial Contracts

Appendix D: Recommendation for the Billing Schema

Page 512: IUT 230 billing and invoicing

© SAP AG IUT230 14-2

Page 513: IUT 230 billing and invoicing

© SAP AG IUT230 14-3

Appendix C Commercial and Industrial Billing 3-Peak Average with Floating Backbilling Business Description 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.

Page 514: IUT 230 billing and invoicing

© SAP AG IUT230 14-4

Overview

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.

No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExBB BB All BB1

RevBB1

1 E7_1 QUANTI01 X EQUANT_1

EQPRICE_1

EAMOUNT_1

2 E7_2 QUANTI01 X EQUANT_2

EQPRICE_2

EAMOUNT_1

3 E7_3 INFACT01 EDEMAND1

EDEMAND7

4 E7_3 DEMAND14

EDEMAND1

EDEMAND6

5 E7_3 BACKBI01 0002

6 E7_3 BACKBI03 EDEMAND7

EDEMAND6

X 0002

7 E7_3 DEMAND07

EDEMAND6

EDEMAND4

EDEMAND5

8 E7_3 INFACT01 EDEMAND5

EDEMAND8

9 E7_3 DEMAND01

X EDEMAND5

ETPRICE_1 EAMOUNT_1

0003 0003

10 E7_3 IF00 EDEMAND5

EDEMAND8

11 E7_3 ELSE

12 E7_3 BACKBI02 EDEMAND5

EDEMAND5

13 E7_3 BACKBI01 0003

14 E7_3 ENDIF

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

Page 515: IUT 230 billing and invoicing

© SAP AG IUT230 14-5

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):

January February March

|----------------------|----------------------|----------------------|

30 kW 20 kW 10 kW

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

January February March April

|----------------------|----------------------|----------------------|----------------------|

40 kW (April)

30 kW (January)

20 kW (February)

10 kW (March)

Page 516: IUT 230 billing and invoicing

© SAP AG IUT230 14-6

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).

January February March April May

|---------------------|---------------------|----------------------|----------------------|----------------|

Current billing

30 kW

Page 517: IUT 230 billing and invoicing

© SAP AG IUT230 14-7

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.

January February March April May

|--------------------|----------------------|----------------------|----------------------|---------------|

< -----30 kW---- >

Adjustment periods:

< ---30 KW--- >

< -----30 kW---- >

< -----30 kW---- >

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.

January February March

|----------------------|----------------------|----------------------|

Adjustment periods:

< -----20 kW--- >

< -----20 kW----- >

< -----20 kW------ >

Page 518: IUT 230 billing and invoicing

© SAP AG IUT230 14-8

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

January February March April May

|--------------------|----------------------|----------------------|----------------------|---------------|

< -----30 kW---- >

Adjustment periods:

< ---30 KW--- >

< -----30 kW---- >

< ----30 KW----- >

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.

Page 519: IUT 230 billing and invoicing

© SAP AG IUT230 14-9

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

No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExBB BB

All BB1

RevBB1

. . .

. . .

3 E7_3 INFACT01

EDEMAND1

EDEMAND7

4 E7_3 DEMAND14

EDEMAND1

EDEMAND6

5 E7_3 BACKBI01

0002

6 E7_3 BACKBI03

EDEMAND7

EDEMAND6

X 0002

7 E7_3 DEMAND07

EDEMAND6

EDEMAND4

EDEMAND5

8 E7_3 INFACT01

EDEMAND5

EDEMAND8

9 E7_3 DEMAND01

X EDEMAND5

ETPRICE_1

EAMOUNT_1

0003 0003

10 E7_3 IF00 EDEMAND5

EDEMAND8

11 E7_3 ELSE

12 E7_3 BACKBI02

EDEMAND5

EDEMAND5

13 E7_3 BACKBI01

0003

14 E7_3 ENDIF

Key:

ExBB: Execute backbilling indicator BB: Execute schema step in backbilling only indicator AllBB1: Allocate backbilling indicator RevBB1: Reverse backbilling indicator

Page 520: IUT 230 billing and invoicing

© SAP AG IUT230 14-10

Description 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.

Execute backbilling indicator: ExBB1

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.

Allocate backbilling indicator: AllBB1

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

Reverse backbilling indicator: RevBB1

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.

Execute schema step in backbilling: BB

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.

Page 521: IUT 230 billing and invoicing

© SAP AG IUT230 14-11

Detailed Description The following variant programs are required for the billing rule in floating backbilling with 3-peak averages. These are listed in the same order they appear in the sample billing schema (see above).

3 - INFACT01 - Writing a demand to the installation facts

In this special case, the output operand defines the operand name that is to be used to write to the installation facts. Input and output operands can have either the same name or different names. In the application itself, the value obtained from the meter reading (register operand) is updated to the output operand for the demand values measured on a monthly basis. If this output operand does not exist, it is created automatically in the installation facts.

4 - DEMAND14 - Rate-independent transfer of register operands

The demand represented by the input operand is updated without changes. This variant is only expedient if the input operand is a register operand. These are only known within the corresponding rate, but may also be needed for processing in the same or different rates.

This step transfers the demand value from the meter reading (register operand) to the output operand planned for the peak average. In its demand description, the operand has the value 3 for calculating the 3-peak average.

5 - BACKBI01 – Triggering backbilling

This variant triggers backbilling. You can hide billing line items that are not required for backbilling using the control function.

You carry out this variant step with the next step using the Execute backbilling indicator.

Page 522: IUT 230 billing and invoicing

© SAP AG IUT230 14-12

6 - BACKBI03 – Update demand from the adjustment period

This variant is only required in backbilling or period-end billing.

In backbilling, demands from the adjustment periods are updated to schema steps in the periodic billing period (current billing period).

In period-end billing, demands from the adjustment periods are updated to the schema steps in the rate for period-end billing.

In this variant, the Execute schema step in backbilling only indicator must be set. This indicator is set automatically when this variant is used, and it cannot be changed at a later stage.

The recorded monthly demand values are now exported from the installation facts and written to the output operand. In this way, the adjustment period values are also available for the current billing period in the billing schema. With this variant, the 3-peak average is calculated during demand preprocessing (output operand with no. of peaks = 3).

7 - DEMAND07 – Comparison of two demands

This step involves calculating the higher or lower demands from two alternatives.

The result of peak averaging is then compared with the minimum demand agreed in the contract. The higher demand value is updated to the output operand that represents the current clearing demand.

8 - INFACT01 – Writing a demand to the installation facts

In the future, this clearing demand will be updated to the installation facts as a demand for the previous month so that it is available for subsequent period billings. This demand value is essential for backbilling and reversing the demand values that have already been charged (adjustment periods).

9 - DEMAND01 - Valuating a demand with a price

The clearing demand calculated for the current month is valuated with a price. Price prorations are taken into account. The calculated amount is updated.

Page 523: IUT 230 billing and invoicing

© SAP AG IUT230 14-13

10 - IF00 - Condition: IF demand1 >,>=,= demand2

This variant introduces an IF nesting level. All the following schema steps are only executed if the condition is fulfilled. The condition is:

IF demand1 > (>=,=) demand2

whereby either the current or the highest values of the input operand are taken into account. The IF variant must be ended using an ENDIF variant. You can also use an ELSE variant.

In this step, the clearing demand is compared with the clearing demand from the previous month. If the demand values are the same, the variant programs after the IF variant are executed. Since no variants are listed here, the variants after the ENDIF variant are called up. If the demand values are different, backbilling must be carried out. This means that all the billing line items for the adjustment period are reversed and recalculated.

11 - ELSE – Start of a NOT operation for an IF variant

This variant introduces the ELSE part of an IF nesting level, that is, the following variants are only executed if the IF variant condition is not fulfilled.

Since the current clearing demand is different from the previous month's clearing demand, backbilling is to be carried out. This would, for example, be the case if the n-peak average had either increased or decreased.

12 - BACKBI02 – Update demand to the adjustment periods

This variant is only required in backbilling or period-end billing. If you use the variant in periodic billing with backbilling, the most recent demand value in the periodic billing period is updated to the adjustment periods. If you use the variant in a rate for period-end billing with backbilling, the most recent demand value in the period-end billing period is updated to the adjustment periods.

In this way, the current demand value is updated to the adjustment periods.

13 - BACKBI01 – Triggering backbilling

This variant triggers backbilling.

In more specific terms, the variant program steps are executed with the same backbilling control group. The schema steps that have the same group in the backbilling reversal indicator column are reversed.

14 - ENDIF – Ending an IF nesting level

This ends the IF nesting level you previously opened using an IF## variant.

Page 524: IUT 230 billing and invoicing

© SAP AG IUT230 14-14

Operands Register operand EDEMAND__1 for the month's measured demand

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.

Field Name Name Note

Header Data:

Operand EDEMAND_1 Name can be freely assigned.

Operand category DEMAND

Usage Register operand At the time of billing, the current recorded demand values are stored.

General Data

Rounding # As required.

Rounding type # As required.

Operand group Optional By assigning the operand group to an operand, you specify that the operand is always to be displayed in the fact hierarchy with reference to this operand group.

Access to operand 00 All values are considered.

History 0 No restrictions relating to the historical changeability are specified.

Special Control:

No. of peaks 1

In the specific example, the above-mentioned operand was defined as a register operand. In this way, the current value is exported from the meter reading results via the installation structure at billing runtime.

Operand EDEMAND__6 for the calculated 3-peak average

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

Page 525: IUT 230 billing and invoicing

© SAP AG IUT230 14-15

Field Name Name Note

Header Data:

Operand EDEMAND_6 Name can be freely assigned.

Operand category DEMAND

Usage Standard usage

General Data

Rounding # As required.

Rounding type # As required.

Operand group Optional See above

Access to operand 02 The value on the key date is valid. This control function is selected depending on the contractual conditions.

History 0 No restrictions relating to the historical changeability are specified.

Special Control:

No. of peaks 3 During demand preprocessing, which is activated for certain variants, this operand contains the result of the calculation (in this case the 3-peak average).

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

Page 526: IUT 230 billing and invoicing

© SAP AG IUT230 14-16

Rate - Time Period Control - Variant Control 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.

No. Variant PC FT Inp. Op.1 Inp. Op.2 Outp. Op.1

1 INFACT01 01 EDEMAND1

EDEMAND7

2 DEMAND14

01 01 EDEMAND1

EDEMAND6

3 BACKBI01

F

4 BACKBI03

EDEMAND7

EDEMAND6

5 DEMAND07

01 02 EDEMAND6

EDEMAND4

EDEMAND5

6 INFACT01 01 EDEMAND5

EDEMAND8

7 DEMAND01

01 02 EDEMAND5

ETPRICE_1 EAMOUNT_1

8 IF00 03 EDEMAND5

EDEMAND8

9 ELSE

10 BACKBI02

EDEMAND5

EDEMAND5

11 BACKBI01

F

12 ENDIF

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).

Page 527: IUT 230 billing and invoicing

© SAP AG IUT230 14-17

Period Control - PC

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.

Explanations of the different basic procedures

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.

Basic procedure 02: On a monthly basis with taking key date into account

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.

Basic procedure 03: On a monthly basis depending on interval

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).

Page 528: IUT 230 billing and invoicing

© SAP AG IUT230 14-18

Variant Control

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.

No. Variant PC FT Inp. Op.1 Inp. Op.2 Outp. Op.1

1 INFACT01 01 EDEMAND1

EDEMAND7

2 DEMAND14

01 01 EDEMAND1

EDEMAND6

3 BACKBI01

F

4 BACKBI03

EDEMAND7

EDEMAND6

5 DEMAND07

01 02 EDEMAND6

EDEMAND4

EDEMAND5

6 INFACT01 01 EDEMAND5

EDEMAND8

7 DEMAND01

01 02 EDEMAND5

ETPRICE_1 EAMOUNT_1

8 IF00 03 EDEMAND5

EDEMAND8

9 ELSE

10 BACKBI02

EDEMAND5

EDEMAND5

11 BACKBI01

F

12 ENDIF

Rate step no. 1 – INFACT01

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.

Rate step no. 2 – DEMAND14

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.

Page 529: IUT 230 billing and invoicing

© SAP AG IUT230 14-19

Rate step no. 3 – BACKBI01

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.

Rate step no. 5 – DEMAND07

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.

Page 530: IUT 230 billing and invoicing

© SAP AG IUT230 14-20

Rate step no. 6 – INFACT01

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.

Rate step no. 7 – DEMAND01

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.

Rate step no. 8 – IF00

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.

Page 531: IUT 230 billing and invoicing

© SAP AG IUT230 14-21

Rate step no. 11 – BACKBI01

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.

Page 532: IUT 230 billing and invoicing

© SAP AG IUT230 14-22

Rate category 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.

Field Name Name Note

Header Data:

Rate category E7 Name can be freely assigned.

Division

General Data

Billing class # As required.

Outsorting price group billing # As required. The outsorting checks during billing are entered (for example, maximum net amount) here.

Billing schema:

Billing schema Here, you must enter all the rates for an installation that are required for calculation.

Backbilling:

Floating backbilling X See below

Number of periods 12 Periods for floating backbilling. With this entry, the peak average calculation is restarted after 12 periodic billings.

Indicator: Floating backbilling

If you set this indicator, floating backbilling can be carried out for the contracts assigned to this rate category. In floating backbilling, backbilling is carried out within a fixed billing period. In floating backbilling, you must specify the number of periods that backbilling covers.

Floating backbilling can be triggered from a periodic billing (or a final billing).

Page 533: IUT 230 billing and invoicing

© SAP AG IUT230 14-23

Demand Billing – Cosine Phi – Period-End Billing Business Description

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).

Page 534: IUT 230 billing and invoicing

© SAP AG IUT230 14-24

Overview 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).

No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExBB BB

All BB1

RevBB1

1 E8_1 QUANTI01

X EQUANT_1

EQPRICE_1

EAMOUNT_1

0004

2 E8_1 LUMSUM01

X ELPRICE_1 EFACTOR_1

EAMOUNT_1

0004

3 E8_1 INFACT06 EQUANT_1

EQUANT_6

4 E8_1 INFACT02 EAMOUNT_1

EAMOUNT_1

5 E8_1 QUANTI14

EQUANT_1

EQUANT_3

6 E8_2 QUANTI01

X EQUANT_2

EQPRICE_2

EAMOUNT_2

0004

7 E8_2 INFACT06 EQUANT_2

EQUANT_7

8 E8_2 INFACT02 EAMOUNT_2

EAMOUNT_2

9 E8_3 DEMAND01

X EDEMAND1

ETPRICE_1 EAMOUNT_3

10 E8_3 INFACT02 EAMOUNT_3

EAMOUNT_3

11 E8_4 QUANTI13

EQUANT_3

EQUANT_9

EFACTOR_3

12 E8_4 IF03 EFACTOR_4

EFACTOR_3

13 E8_4 QUANTI09

EQUANT_3

EFACTOR_2

EQUANT_10

14 E8_4 QUANTI02

EQUANT_9

EQUANT_10

EQUANT_11

15 E8_4 QUANTI01

X EQUANT_11

EQPRICE_5

EAMOUNT_1

16 E8_4 ENDIF

17 E8_E QUANTI10

EQUANT_6

EQUANT_7

EQUANT_8

18* E8_E QUANTI01

X EQUANT_8

EQPRICE_4

EAMOUNT_4

19 E8_E COMPUT02

EAMOUNT_1

EAMOUNT_2

EAMOUNT_5

20 E8_E COMPUT02

EAMOUNT_5

EAMOUNT_3

EAMOUNT_6

Page 535: IUT 230 billing and invoicing

© SAP AG IUT230 14-25

21 E8_E IF02 EAMOUNT_4

EAMOUNT_6

22 E8_E UTILIT01 EAMOUNT_4

23 E8_E ELSE

24 E8_E BACKBI01

0004

25 E8_E ENDIF

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.

Page 536: IUT 230 billing and invoicing

© SAP AG IUT230 14-26

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.

Page 537: IUT 230 billing and invoicing

© SAP AG IUT230 14-27

Detailed Description The following variant programs are required for the existing billing rule. These are listed in the same order they appear in the sample billing schema.

Active Energy On-Peak Rate

1 - QUANTI01 - Valuating a quantity with a price

A quantity is valuated with a price. Price prorations are taken into account. If several registers are included in the quantity to be billed, the total consumption of the registers is used when you determine the amount; in other words, the registers are not valuated individually. The calculated amount is updated. The updated amount is used for a maximum price limitation in period-end billing.

2 - LUMSUM01 - Billing a flat rate taking one factor into account

Calculating a flat rate in accordance with a price table. This factor is multiplied with a factor. Prorations of the flat rate prices and the factor are taken into account. The calculated amount is updated and added to the amount calculated in step 1.

3 - INFACT06 - Writing a quantity to the installation facts

In this special case, the output operand defines the operand name that is to be used to write to the installation facts. Input and output operands can have either the same name or different names.

4 - INFACT02 - Writing an amount to the installation facts

In this special case, the output operand defines the operand name that is to be used to write to the installation facts. Input and output operands can have either the same name or different names. This amount is used in period-end billing to calculate the maximum amount.

5 - QUANTI14 - Rate-independent transfer of register operands

The quantity represented by the input operand is updated without changes. This variant is only expedient if the input operand is a register operand. These are only known within the corresponding rate, but may also be needed for processing in different rates. The quantity is required for calculating the cosine phi demand factor.

Active Energy Off-Peak Rate

6 - QUANTI01 - Valuating a quantity with a price

An off-peak rate quantity is valuated with a price.

7 - INFACT06 - Writing a quantity to the installation facts

This quantity is also written to the installation facts.

8 - INFACT02 - Writing an amount to the installation facts

The calculated amount from the valuation of the off-peak rate is written to the installation facts.

Page 538: IUT 230 billing and invoicing

© SAP AG IUT230 14-28

Demand Rate 9 - DEMAND01 - Valuating a demand with a price

A demand is valuated with a price. Price prorations are taken into account. The calculated amount is updated. A measured demand is billed here. You can also bill a predefined demand (in conditions, rate category, installation facts), or a demand calculated in a previous schema step. The updated amount is used for a maximum price limitation.

10 - INFACT02 - Writing an amount to the installation facts

The calculated amount from the valuation of the demand rate is written to the installation facts.

Reactive Energy Rate

11 - QUANTI13 - Calculating cosine phi from active energy and reactive energy

The cosine phi is calculated using the active energy and reactive energy. The value entered in the first operand is interpreted as active energy (measured quantity of the on-peak rate register), and the value entered in the second operand as reactive energy (measured quantity of the reactive energy register). Each of the values entered is cumulated, that is, if more than one register is involved, the consumption values are added first.

You must ensure that the calculation for the consumption values in question is based exclusively on the operand name and the consumption values assigned using it. The specifications made at the register level regarding the use of an active energy or reactive energy register are not taken into account.

The cosine phi is calculated as follows:

CosPhi = 1 / SQRT((reactive*reactive) / (active*active) + 1)

For the following, cosine phi is calculated as:

Reactive = 0, active > 0 ==> CosPhi = 1 Reactive > 0, active = 0 ==> CosPhi = 0 Reactive = 0, active = 0 ==> CosPhi = 0

In this way, a cosine phi is calculated and updated for the entire period to be billed.

12 - IF03 - Condition: IF factor1 >,>=,= factor2

This variant introduces an IF nesting level. All the following schema steps are only executed if the condition is fulfilled. The condition is:

IF factor1 > (>=,=) factor2

whereby either the current or the highest values of the input operand are taken into account. In this example, the factor1 > factor2 comparison and the analysis of the current quantity are chosen. Factor1 contains the calculated cosine phi, while factor2 receives the value from the facts.

The IF variant must be ended using an ENDIF variant. You can also use an ELSE variant. If the demand factors are identical, this query generates an additional billing line item for overcompensation.

Page 539: IUT 230 billing and invoicing

© SAP AG IUT230 14-29

13 - QUANTI09 - Multiplying a quantity

A quantity is multiplied by a factor, and the result updated. The calculation is made taking into account prorations of the factor. In this example, the measured on-peak rate quantity is multiplied by a factor (n % of the on-peak rate consumption). The percentage is entered in the rate, rate category, or installation facts. The quantity has been transferred in the on-peak rate (E8_1) independently of the rate.

14 - QUANTI02 - Subtracting two quantities

The quantities represented by both input operands are subtracted, and the result updated. If negative results are permitted (see control options), prorations are not relevant. If, however, because of the control setting, you have to know whether this yields a negative result, the time slices resulting from prorations must be analyzed individually.

The n % on-peak rate quantity calculated in the previous step is now subtracted from the measured reactive energy consumption.

15 - QUANTI01 - Valuating a quantity with a price

The calculated difference is valuated with a price.

16 - ENDIF – Ending an IF nesting

You use this variant to end an IF nesting level, that is, all the following variants are executed again.

Period-End Billing Rate

The following steps are only taken in period-end billing.

17 - QUANTI02 - Adding two quantities

The quantities represented by both input operands are added, and the result updated. If historical quantities exist in the period to be billed, these are all added. The origin of the quantities is not relevant, that is, the quantities could be both current meter reading results or values from the installation facts. Info lines relating to the quantity or consumption are written. You can use the control function to define how the operands are to be updated. In period-end billing, the on-peak and off-peak rate consumption values were updated and are now to be added to determine whether the customer is entitled to a particular discount in period-end billing.

18 - QUANTI01 - Valuating a quantity with a price

The total calculated is valuated with a defined maximum price and updated in an amount operand.

19 and 20 - COMPUT02 - Adding two amounts (twice)

The on-peak rate amounts calculated in the period billings are added to the calculated off-peak rate amounts. The result is then added to the calculated demand amounts.

Page 540: IUT 230 billing and invoicing

© SAP AG IUT230 14-30

21 - IF02 - Condition: IF amount1 >,>=,= amount2

This variant introduces an IF nesting level. All the following schema steps are only executed if the condition is fulfilled. The condition is:

IF amount1 >= amount2

In this case, only the current input operand values are analyzed.

In this step, the total of the period billings (total of all the amounts for the rates in question) is multiplied by the result of the valuation of the total quantity (on-peak consumption + off-peak consumption), and compared with a defined maximum price.

22 - UTILIT01 - Deleting the billing line items

The billing line items for the amount received are deleted along with their info line items. The billing line items can also be marked as info line items. In this way, they are not relevant to posting or statistics, although they can be printed on the bill. The billing line items to be deleted are identified using the deletion operand.

The schema step is only executed if the condition for variant IF02 is fulfilled. It is fulfilled if the amount calculated using QUANTI01 in the period-end billing rate is greater than the amount resulting from the total of the amount calculations for the rates (period billings).

23 - ELSE – Starting a NOT operation for an IF variant

If this is not the case, the NOT operation variants are executed.

24 - BACKBI01 – Triggering backbilling

This variant triggers backbilling. You can hide billing line items that are not required for backbilling using the control function.

Backbilling is to be carried out or a credit memo issued for all the billing line items created in previous billing periods.

The billing line items to be reversed are selected using the backbilling reversal indicator (backbilling group).

This applies to schema steps 1 and 2 for the on-peak rate, and schema step 6 for the off-peak rate.

25 - ENDIF – Ending an IF nesting

The nesting level opened in the schema step must be ended using this variant.

Page 541: IUT 230 billing and invoicing

© SAP AG IUT230 14-31

Rate category 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).

Field Name Name Note

Header Data:

Rate category # Name can be freely assigned.

Division #

General Data

Billing class # As required.

Outsorting price group billing # As required. The outsorting checks during billing are entered (for example, maximum net amount) here.

Billing schema:

Billing schema # Here, you must enter all the rates for an installation that are required for calculation.

Backbilling:

No backbilling X

Number of periods 0

Period-End Billing

Separate period-end bill. X See below

PEB prio. X

Diff. in days 1

Number of periods 12

Page 542: IUT 230 billing and invoicing

© SAP AG IUT230 14-32

Period-End Billing Indicator 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.

No period-end billing:

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

Period-end billing with last 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.

Separate period-end billing

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.

Page 543: IUT 230 billing and invoicing

© SAP AG IUT230 14-33

Period-end billing prioritization

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.

Difference days: Bill Period-end billing

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.

Period lengths in period-end billing

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

Page 544: IUT 230 billing and invoicing

© SAP AG IUT230 14-34

Period-End Billing Rate

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

Rate Header Data

Permissibility: Period-end billing permitted

Rate Steps

No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1

1 E8_E QUANTI10

EQUANT_6

EQUANT_7

EQUANT_8

2 E8_E QUANTI01

X EQUANT_8

EQPRICE_4

EAMOUNT_4

3 E8_E COMPUT02

EAMOUNT_1

EAMOUNT_2

EAMOUNT_5

4 E8_E COMPUT02

EAMOUNT_5

EAMOUNT_3

EAMOUNT_6

5 E8_E IF02 EAMOUNT_4

EAMOUNT_6

6 E8_E UTILIT01 EAMOUNT_4

7 E8_E ELSE

8 E8_E BACKBI01

9 E8_E ENDIF

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

Period-End Billing Schema Header Data 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.

Page 545: IUT 230 billing and invoicing

© SAP AG IUT230 14-35

Appendix D Recommendation for the Billing Schema

There is no limit to the number of steps you can include in a billing schema. In principle you can create a billing schema with any number of steps. Very large billing schemas are firstly difficult to maintain, and secondly have a negative influence on the performance of billing.

Maintenance: In principle, you can include all the rates for a joint division and billing class in the same schema. However, SAP recommends that you create billing schemas with a maximum of a few hundred steps. Smaller schemas are easier to maintain and analyze. There is a limit as to how small a billing schema may be; all rates that are found using a rate category must exist in the associated billing schema.

Performance: The performance of the billing program is dependent on the number of steps to be executed. If billing involves many schema steps, the runtime can be very long. You should note this when designing billing schemas.

The number of schema steps that are executed internally is also vital for performance. Example:

A billing schema contains steps for the rates T1, T2 .... T10

When you bill a contract, the system only finds rate T1.

The runtime of the billing is therefore dependent on the number of schema steps that belong to rate T1. The number of schema steps for rates T2 to T10 is of no importance in this case.

Some schema steps are executed more than once for schemas with backbilling or dynamic period control. If, for example, a backbilling takes place for the past 10 months, there are schema steps that are executed 10 times internally in the billing. Billing schemas with many steps affect the runtime accordingly when you perform a backbilling.

There is no simple answer to explain how the number of schema steps influences the runtime of the billing program. It is due to the fact that runtimes of some program components (such as database accesses) are dependent on the length of the schema. The runtime of other program components is to a certain extent proportional (for example, analysis of operand values). There are also program components whose runtime is over proportional (analysis of dependencies between the schema steps. The analysis is required for the update).

Experience shows that the runtime is greatly independent of the schema layout when billing residential customers with simple rates. Billing an contract with 15 schema steps requires little more time than a contract with 8 steps.

This does not apply for very large billing schemas. The analysis of billing schemas and dependencies between the schema steps influences the total runtime. SAP highly recommends the following:

Try to enter as few schema steps in the schema layout as possible.

Test the runtime at an early stage using test cases.

Avoid a large number of schema steps if the schema is to be used for many contracts.

Experience shows that persons who are proficient in designing schemas find it easier to map complex requests using few schema steps. If you want to create very complex schemas, it may be appropriate to allow an experienced specialist to check the concept at an early stage.

Page 546: IUT 230 billing and invoicing

© SAP AG IUT230 14-36

Page 547: IUT 230 billing and invoicing

© SAP AG IUT230 15-1

SAP AG 2006

Master Data for Collective Bill

Collective Bill Documents

Collective Bill Process

Contents:

Collective Bill (Appendix E)

Page 548: IUT 230 billing and invoicing

© SAP AG IUT230 15-2

SAP AG 2006

Master Data

C Acct.: 8711Acct cat.: 02

Acct.: 4712Acct cat.: 01CB acct.: 8711

Collector Inc. Anne Miller John Smith Mary Meier

Contract account cat."Collective Bill"

"Normal contract account type" withreference to collective bill account

Acct.: 4713Acct cat.: 01CB acct.: 8711

Acct.: 4714Acct cat.: 01CB acct.: 8711

The collective bill guarantees that contract accounts are processed together in bill creation and other business processes from contract accounts receivable and payable.

The collective bill concept is used in the following areas:

Property management

Housing company

Branch-central office relationships

Example: Tenants in a housing company are supplied by a utility company. The housing company carries out the payment transactions (payments, dunning, returns, correspondence) with the utility company and bills the tenants separately. The bills are paid by the housing company.

The individual contract accounts are allocated to the collective bill contract account (CB account). The CB account is classified by a special contract account category. The individual contract accounts (individual accounts) are allocated to the CB account. You can allocate these in the utilities menu under Business Master Data -> Contract Account -> Create/Change. In the Bill Creation group box, enter the CB account in the field Coll.bill acct. The individual accounts are allocated to contract partners.

Changes to master data will be included in future bill creation. They do not affect existing transaction data.

Page 549: IUT 230 billing and invoicing

© SAP AG IUT230 15-3

SAP AG 2006

Posting Document - Contract Accounts Receivable and Payable

Collector Inc. Anne Miller

Business partneritem 116 USD

General ledger item100.00 USD16.00 USD

Doc. 471200

CB document 4711

Business partneritem 116 USD

Doc. 4711

Stat. key: SStat. key: S

When posting documents are created for individual accounts, a statistical posting document is automatically created for the CB account (CB document).

The amount is calculated from the total amounts of the accompanying individual documents.

Posting relevant to the general ledger - if at all necessary - always takes place at individual account level.

In transactions from contract accounts receivable and payable that automatically create a statistical CB document, there is a 1:1 relationship between the individual documents and the CB document. These transactions include:

Post document (FPE1)

Create security deposit (FPSEC1)

Calculate interest individually (FPI1)

Interest run (FPINTM1)

Page 550: IUT 230 billing and invoicing

© SAP AG IUT230 15-4

SAP AG 2006

Posting Document - Invoicing

Collector Inc. Anne Miller John Smith

Business partneritem 116 USD

General ledger item100.00 USD16.00 USD

Doc. 471200

CB document 4711

Business partneritem 232.00 USD

General ledger item200.00 USD32.00 USD

Doc. 471300

CB document 4711

Business partneritem 348.00 USD

Doc. 4711

Stat. key: SStat. key: S

When contracts that are allocated to an individual account of a CB construct are invoiced, statistical CB (total) documents are automatically created in the CB account.

When contracts that are allocated to an individual account of a CB construct are invoiced, statistical CB (total) documents are automatically created in the CB account.

For invoicing transactions, several individual documents are grouped together to form a CB document. This means that when these individual accounts are invoiced, a statistical CB document is gradually created according to the structure of the individual documents.

Example: The two individual documents 471200 and 471300 are posted to the contract accounts of contract holders Anne Miller and Henry Smith. These documents can be created by invoicing, a budget billing request or a partial bill. Since the joint CB account 8711 is entered in both contract accounts, the two individual documents are consolidate into one joint CB document; This means that they are allocated to the same CB document 4711. This CB document refers to the business partner Collector Ltd and the CB account 8711. The amount in the CB document is the total amount from the individual contracts.

Page 551: IUT 230 billing and invoicing

© SAP AG IUT230 15-5

SAP AG 2006

Posting Document - Budget Billing Amount Request

Collector Inc. Anne Miller John Smith

02.01. 116.00 USD02.02. 116.00 USD02.03. 116.00 USD

Doc. 4711

Business partneritem 348.00 USD

Stat. key: S

BB amount 0815 BB amount 0816

Budget billing request for MM.DD.YYYY creates the statistical collective bill request in the collective bill account.

Collective bill4711

02.01. 232.00 USD02.02. 232.00 USD02.03. 232.00 USD

Request by 01/02Request by 01/02

When the budget billing plan is being created, the system checks whether an individual account is allocated to a CB account. If it is, the CB account is stored in the BB plan and displayed during budget billing plan processing. For regulation purposes, the budget billing items are given the clearing restriction Collective Bill: Refer to Collective Bill Account (6). They can only be paid using a CB document.

During statistical budget billing procedure, posting items from a budget billing plan represent an exception with regards to the time that a collective bill is created. The items are first of all posted without a reference to a collective bill document. The collective bill document is created separately in the budget billing request process.

If you reverse the allocation of a contract account to a collective bill account, clearing restriction 6 is deleted from the budget billing items that have not yet been entered in a budget billing collective bill.

Page 552: IUT 230 billing and invoicing

© SAP AG IUT230 15-6

SAP AG 2006

Print Document

Collector Inc. Anne Miller

Bill amount 116.00 USDDue on 05/15

Bill 3334

CB document 4711

John Smith

Bill amount 232.00 USDDue on 05/15

CB document 4711

Cover sheet bill

Bill total 406.00 USD

Due on 05/15

Bill 1018

When a collective bill is created, a collective bill print document is also created. This print document forms the basis of the collective bill cover sheet.

When a collective bill is created, a collective bill print document is also created. This print document forms the basis of the collective bill cover sheet.

Invoicing order 4711Document line item type Z

Bill 3335 Budget billingrequest re58.00 USDDue on 05/15

Bill 2221

CB document 4712

Mary Meier

Invoicing order 4712 Document line item type Z

Collective bill print documents are used for joint bill creation and for correspondence with the collective bill contract partner.

They are created using the collective bill transaction.

In order to create a collective bill print document, an invoicing order (EITR with document line item type Z) is created for each statistical item in the transaction Create Collective Bill. Individual bills cannot be printed at this time.

They can only be printed after the transaction Create Collective Bill has been executed.

For example: Individual bills 3334 and 3335, and individual documents 471200 and 471300 (see previous slide) have been created for the contract accounts belonging to Anne Miller and Henry Smith. Contract account owner Maria Bush receives the budget billing request 2221. Since the joint CB account 8711 has been entered in all contract accounts, the two individual bills have been grouped together as the joint CB document 4711 and the invoicing order 4711 created. This in turn enables the creation of a collective bill print document. During the creation of the budget billing request, CB document 4712 and invoicing order 4712 were created. These invoicing orders refer to the business partner Collector Ltd and the CB account 8711, and are included in a joint collective bill print document.

Page 553: IUT 230 billing and invoicing

© SAP AG IUT230 15-7

SAP AG 2008

Processes at Individual and CB Account Level

Billing• Billing document

• Invoicing index

BillClearing type R41, R42, R43Creation reason 01

CB InvoicingClearing type R4ZCreation reason 05

• CB print document

• Print index

• Collective billClearing restriction 7 has beendeleted

• CB invoicing orderis deleted

Budget billingrequestClearing type R6Creation reason 02

Partial BillClearing type R5Creation reason 03

Level ofindividual accounts

CB - Printout

Level of CB

account

• Individual print document- Representative Doc.

ABWBL = 8711

• No print index

• Collective bill- FI-CA document- Document number

OPBEL = 8711- Clearing restriction

AUGRS = 7

• CB invoicing order- Document No. BELNR = 8711- Document type BEL_ART = Z

During the invoicing of individual accounts, print documents are created as the basis of individual bills.

Individual bills cannot be printed at this time.

Statistical CB posting items created during the invoicing of individual accounts are given the clearing restriction Collective Bill: Only Regulate After Collective Invoicing (7) As a result, the CB posting items and accompanying individual documents are blocked for payment and clearing regulation. This prevents them from being (partially) cleared before the collective bill print document has been constructed. They are released by the subsequent transaction Create Collective Bill.

In order to create a collective bill print document, an invoicing order (EITR with document line item type Z) is created for each statistical item in the transaction Create Collective Bill.

Individual bills can only be printed and regulated after the transaction Create Collective Bill has been executed.

Page 554: IUT 230 billing and invoicing

© SAP AG IUT230 15-8

SAP AG 2008

Processes at Individual and CB Account Level

• CB reversal print document

• Print index

• Collective billClearing restriction 7 is set

• CB invoicing indexis restructured

Level of individual accounts

CB printoutCB reversal (EA15)Clearing type R4Z

Creation reason 04

Reversal of collective bill does not automatically lead to reversal of individual bills

Level of CB account

You can reverse a collective bill using the transaction Bill Reversal (Mass Reversal) (EA15). This reverses the CB print document as well as the posting documents (interest documents, account maintenance documents) created when the CB print document was created . The individual account bills grouped together in the print document are not automatically reversed.

When a CB print document is reversed, the statistical CB posting items created during the invoicing of individual accounts are given a clearing restriction again, and are blocked for payment. After the reversal, a new CB print document can be created for the CB account. This document can group together the individual invoicing documents that were contained in the original CB print document.

If you want to reverse an individual bill, you do not have to reverse the accompanying CB document. Exception: If the individual bill has was (partially) cleared when the CB was created within the framework of integrated account maintenance. Note: If you want to display the reversal document for the individual bill in the printout, you must reverse the CB print document.

Individual bills and reversal bills that were reversed before before being entered in a CB are not included in a CB.

Page 555: IUT 230 billing and invoicing

© SAP AG IUT230 15-9

SAP AG 2006

Basic Functions

When a collective bill is created, the clearing type Create Collective Bill (R4Z) is used as standard.

Transaction and account determination, as well as tax determination do not take place at CB level.

When a collective bill is created, a new due date is notdetermined.

All statistical CB items processed in the CB print document have the original due date they were given when the individual accounts were invoiced. This is also transferred to the CB print document at individual document level.

Note: At the start of the transaction Create Collective Bill (EA10_Coll), set the date in the net due date field (group frame General Selections) so far in the future that the payment date is not changed.

Note: Because CB documents that have the same due dates can be grouped together to form a CB print document, you can minimize the volume of correspondence for each CB account by using a payment condition that determines fixed days in a month as payment targets (for example, due on the 15th of the following month instead of due in 14 days). This means the CB recipient only receives a CB bill once a month.

Page 556: IUT 230 billing and invoicing

© SAP AG IUT230 15-10