iut230 billing and invoicing

IUT230 Abrechnung und Fakturierung IUT230

Release 463 25.09 .2003

1. IUT230 Abrechnung und Fakturierung..............................................................................................................0-1 Copy right 0-2

a. SAP Utilities (IS-U/CCS) 0-4

b. Course Prerequisites 0-5

c. Target Group 0-6

d. Course Goals 0-7

e. Course Objectives 0-8

f. Course Content IUT230 0-9 Busines s Scenario 1-1

a. Business Scenario: Unit Objectives 1-2

b. IDES Utilities Inc. 1-3

c. Deregulated Utilities Industry 1-4

d. Organizational Structure 1-5

e. Rate Structure 1-6

f. Contract (Residential Customer - Electricity) 1-7

g. Billing/Invoicing: Business Scenario 10 1-8

h. Business Scenario: Unit Summary 1-9 Bil ling in the IS-U Data Model 2-1

a. Billing in the IS-U Data Model: Unit Objectives 2-2

b. Billing/Invoicing: Business Scenario 2 2-3

c. IS-U/CCS Billing: 1 2-4

d. IS-U/CCS: Integration Model 2-5

e. Billing (Utility Services) 2-6

f. IS-U/CCS Billing: 2 2-7

g. Business Objects / Utility Services 2-8

h. Component Hierarchy / IMG 2-9

i. Link Between Contract Text and IS-U: 1 2-10

j. Link Between Contract Text and IS-U: 2 2-11

k. Link Between Contract Text and IS-U: 3 2-12

l. Link Between Contract Text and IS-U: 4 2-13

m. Link Between Contract Text and IS-U: 5 2-14

n. Link Between Contract Text and IS-U: 6 2-15

o. Universal Billing Engine 2-16

p. Flexible Structure of Billing Rules 2-17

q. Master Data and Billing Master Data 2-18

r. Invoicing 2-19

s. Billing in the IS-U Data Model: Unit Summary 2-20 Bil ling Master Data 3-1

a. Billing: Unit Objectives 3-2


c. Billing Master Data: 1 3-4

d. Billing Modules: 1 3-5

e. Data Model for Billing 3-6

f. Billing Modules: 2 3-7

g. Billing Class I 3-8

h. Billing Class: 2 3-9

i. Billing Modules: 3 3-10

j. Definition of Rate Type 3-11

k. Rate Type: 1 3-12

l. Rate Type: 2 3-13

m. Billing Modules: 4 3-14

n. Prices for Billing 3-15

o. Price Categories 3-16

p. Price Types 3-17

q. Definition of Block Price and Scale Price 3-18

r. Block Price and Scale Price 3-19

s. Adjusting Price Blocks to Billing Periods 3-20

t. Header Data for the Price Key 3-21

u. Quantity-Based Price 3-22

v. Time-Based Price 3-23

w. Flat Rate 3-24

x. Rental Price 3-25

y. Price Adjustment Clause 3-26

z. Billing Master Data: 2 3-27

aa. Flexible Structure of Billing Rules 3-28

bb. Billing Modules: 5 3-29

cc. Operand 3-30

dd. Operand Categories/Examples 3-31

ee. Indicators for Operand Categories 3-32

ff. Rate Determination - Operands 3-33

gg. Parameters for Operands 3-34

hh. Operand Groups 3-35

ii. Weighting Procedure 3-36

jj. Linear Weighting 3-37

kk. Access Control for Operands 3-38

ll. Access Control: Example 1 3-39

mm. Access Control: Example 2 3-40

nn. Allocation of Operand Values: 1 3-41

oo. Contract-Related Operand – Not Activated 3-42

pp. Contract-Related Operand - Activated 3-43

qq. Contract-Related Operand - Move-In 3-44

rr. Contract-Related Operand - Contract Change 3-45

ss. Transfer Result to RTP Operand 3-46

tt. Billing Modules: 6 3-47

uu. Variant Programs: 1 3-48

vv. Variant Programs 2 3-49

ww. Examples of Variant Programs 3-50

xx. Billing Modules: 7 3-51

yy. Rate Characteristics 3-52

zz. Rate 3-53

aaa. Rate Attributes 3-54

bbb. Transactions 3-55

ccc. Sub-Transactions in IS-U Billing / Invoicing 3-56

ddd. Sub-Transactions in the Statistical Budget Billing Procedure in IS-U 3-57

eee. Account Determination: Receivables Account 3-58

fff. Account Determination: Sales Revenue Account 3-59

ggg. Time Period Control 3-60

hhh. Variant Control 3-61

iii. Billing Master Data: 3 3-62

jjj. Billing Modules: 8 3-63

kkk. Fact Group 3-64

lll. Allocation of Operand Values 3-65

mmm. Installation Facts 3-66

nnn. Contract Billing Modules: 9 3-67

ooo. Billing Schema: 1 3-68

ppp. Billing Schema: 2 3-69

qqq. Schema Attributes 3-70

rrr. Installation Disconnection in Billing 3-71

sss. Sorting for Bill Printout 3-72

ttt. Billing Modules: 10 3-73

uuu. Rate Category I 3-74

vvv. Rate Category II 3-75

www. Billing Master Data: 4 3-76

xxx. Dynamic Rate Determination 3-77

yyy. Use of Rates 3-78

zzz. Initial Data Creation of a Rate 3-79

aaaa. Contract (Residential Customer - Electricity) 3-80

bbbb. Billing Mater Data: Unit Summary 3-81

cccc. Exercises Data 3-82

dddd. Billing Master Data: Exercises 3-85

eeee. Billing Master Data: Solutions 3-98 Use of Rates in Master Data 4-1

a. Use of Rates in Master Data 4-2


c. Use of Rates in Master Data: 1 4-4

d. Business Objects 4-5

e. Rate Type 4-6

f. SAP Extension (Rate Type + Rate Fact Group) 4-7

g. Rate Category II 4-8

h. Use of Rates in Master Data: 4 4-9

i. Overall Check 4-10

j. Billing Analysis 4-11

k. Use of Rates in Master Data: 5 4-12

l. Floating Backbilling / n Periods 4-13

m. Period-End Billing 4-14

n. Billing in Advance 4-15

o. Data Model for Billing in Advance 4-16

p. Controlling Billing in Advance in the Schema 4-17

q. Controlling the Gross Price in the Schema 4-18

r. Gross Price Billing 4-19

s. Sample Schema 4-20

t. Use of Rates in Master Data: 6 4-21

u. Transport of Billing Master Data 4-22

v. Use of Rates in Master Data: Unit Summary 4-23

w. Use of Rates in Master Data: Exercises 4-24

x. Use of Rates in the Master Data: Solutions 4-27 Bil ling 5-1

a. Billing: Unit Objectives 5-2


c. Billing: 1 5-4

d. Billing Periods 5-5

e. Billing Procedures 5-6

f. Billing Functions 5-7

g. The Billing Process 5-8

h. Differentiating Billing from Invoicing 5-9

i. Billing Tasks 5-10

j. Invoicing Tasks 5-11

k. Invoicing 5-12

l. Billing: 2 5-13

m. Schedule Master Records: Portions 5-14

n. Schedule Master Records: Meter Reading Units 5-15

o. Generation of Schedule Records 5-16

p. Scheduling: Annual Billing 5-17

q. Meter Reading Order Data 5-18

r. Billing Order 5-19

s. Billing Order Status 5-20

t. Monitoring 5-21

u. Billing: 3 5-22

v. Simulation Functions 5-23

w. Billing Simulation/Simulation 5-24

x. Differences Between Billing and Simulation Simulation 5-25

y. Mass Simulation 5-26

z. Billing: 4 5-27

aa. Individual Processing 5-28

bb. Mass Billing and Mass Overall Check 5-29

cc. Billing Line Item Elements 5-30

dd. Examples of Line Item Types 5-31

ee. Functions of Billing Document Display 5-32

ff. Billing: 5 5-33

gg. Outsorting in IS-U 5-34

hh. Times of Outsorting 5-35

ii. Outsorting Options: Billing 5-36

jj. Outsorting Group: Billing 5-37

kk. Billing Checks 5-38

ll. Customizing Functions: Billing 5-39

mm. Billing: 6 5-40

nn. Reversal Process in Billing 5-41

oo. Reversal Times 5-42

pp. Billing Reversal Elements 5-43

qq. Reasons for Reversal 5-44

rr. Billing: 7 5-45

ss. Parallel Processing - Situation 5-46

tt. Parallel Processing - Creation of Intervals 5-47

uu. Parallel Processing - Portioning Problems 5-48

vv. Parallel Processing - Realization 5-49

ww. Billing: Unit Summary 5-50

xx. Billing: Exercises 5-51

yy. Billing: Solutions 5-55 Invoicing 6-1

a. Invoicing: Unit Objectives 6-2


c. Invoicing: 1 6-4

d. Process of Billing/Invoicing 6-5

e. Billing Tasks 6-6

f. Invoicing Tasks 6-7

g. Invoicing 6-8

h. Invoicing Functions 6-9

i. Billing Procedures in Invoicing 6-10

j. Individual Processing 6-11

k. Mass Processing6-12

l. Tax Determination 6-13

m. Currency-Related Rounding/ Carried-Forward Rounding 6-14

n. Additional Functions in Invoicing 6-15

o. Invoicing: 2 6-16

p. Item Processing 6-17

q. Sub-Items 6-18

r. Settlement Control: Overview 6-19

s. Settlement Concept: 1 6-20

t. Settlement Concept: 2 6-21

u. Determination of Settlement Variants 6-22

v. Account Maintenance in Invoicing: 1 6-23

w. Account Maintenance in Invoicing: 2 6-24

x. Settlement Steps6-25

y. Invoicing: 3 6-26

z. Elements for Determining Due Dates 6-27

aa. Dunning in Invoicing 6-28

bb. Invoicing: 4 6-29

cc. Determination of Outgoing Payment Methods 6-30

dd. Invoicing: 5 6-31

ee. Joint Invoicing: Master Data 6-32

ff. Joint Invoicing: Example 1 6-33

gg. Joint Invoicing: Example 2 6-34

hh. Intercompany Invoicing 6-35

ii. Invoicing of Different Services 6-36

jj. Incorporation of Additional Documents 6-37

kk. Integration of SD Billing Documents 6-38

ll. Invoicing: 6 6-39

mm. Outsorting in IS-U 6-40

nn. Times of Outsorting 6-41

oo. Outsorting Options: Invoicing 6-42

pp. Outsorting Group: Invoicing 6-43

qq. Invoicing Checks 6-44

rr. Customizing Functions: Invoicing 6-45

ss. Invoicing: 7 6-46

tt. Invoicing Reversal Functions 6-47

uu. Reversal Process in Invoicing/Full Reversal 6-48

vv. Billing Reversal/Adjustment Reversal 6-49

ww. Rebilling 6-50

xx. Workflow for Bill Complaints 6-51

yy. Workflow Assessing - Meter Overflow in Estimation 6-52

zz. Invoicing: Unit Summary 6-53

aaa. Invoicing Exercises 6-54

bbb. Invoicing: Solutions 6-56 Budget Bil ling 7-1

a. Budget Billing: Unit Objectives 7-2


c. Budget Billing: 1 7-4

d. Budget Billing Functions 7-5

e. Budget Billing Cycle and Budget Billing Frequency 7-6

f. Storing Budget Billing Cycles 7-7

g. Budget Billing Plan: 1 7-8

h. Budget Billing Plan: 2 7-9

i. Quantity-Based Extrapolation 7-10

j. Budget Billing Due Dates 7-11

k. Accumulated and Sub-Budget Billing Plan 7-12

l. Budget Billing Advance Payment 7-13

m. Budget Billing Adjustment 7-14

n. Budget Billing Plan Extension 7-15

o. Budget Billing: 2 7-16

p. Budget Billing Procedure 7-17

q. Statistical Budget Billing 7-18

r. Debit Entry Procedure (Partial Bill Procedure) 7-19

s. AMB/BBP Payment Plan Procedure 7-20

t. AMB Procedure 7-21

u. BBP Procedure 7-22

v. Initializing the Payment Plan Procedure 7-23

w. Budget Billing: 3 7-24

x. Budget Billing/Partial Bill Printout Procedure 7-25

y. Budget Billing Form 7-26

z. Budget Billing: 4 7-27

aa. Budget Billing Settlement of Paid Amounts 7-28

bb. Settlement Against First or Next Budget Billing Amount: 1 7-29

cc. Settlement Against First or Next Budget Billing Amount: 2 7-30

dd. Customizing for Budget Billing 7-31

ee. Budget Billing: Unit Summary 7-32

ff. Budget Billing: Exercises 7-33

gg. Budget Billing: Solutions 7-36 Bil l Printout 8-1

a. Bill Printout: Unit Objectives 8-2


c. Bill Printout: 1 8-4

d. Form Hierarchy 8-5

e. Structure of the Bill Form 8-6

f. Billing Form 8-7

g. Bill Printout Process 8-8

h. Shipping Control 8-9

i. Payment Medium 8-10

j. Presort Key Function 8-11

k. Presort Key Function - Step 1 8-12

l. Presort Key Function - Step 2 8-13

m. Presort Key Function - Step 3 8-14

n. Collective Bill Print Process 8-15

o. Bill Printout: 2 8-16

p. Print Action Records: 1 8-17

q. Print Action Records: 2 8-18

r. Print Action Records: 3 8-19

s. Print Action Records: 4 8-20

t. Bill Printout: 3 8-21

u. Raw Data Interface: 1 8-22

v. Raw Data Interface: 2 8-23

w. Bill Printout: Unit Summary 8-24

x. Bill Printout: Exercises 8-25

y. Bill Printout: Solutions 8-26 Discounts /Surcharges 9-1

a. Discounts/Surcharges: Unit Objectives 9-2


c. Discount and Surcharge Options in IS-U 9-4

d. Master Data for Discounts and Surcharges 9-5

e. Effects on the Rate Structure 9-6

f. Discounts/Surcharges: Unit Summary 9-7

g. Discounts/Surcharges: Exercises 9-8

h. Discounts/Surcharges: Solutions 9-9 Manual Bi lling 10-1

a. Manual Billing: Unit Objectives 10-2


c. Manual Billing Functions 10-4

d. An Overview of Manual Billing 10-5

e. Manual Billing: Initial Entry 10-6

f. Manual Billing Process 10-7

g. Examples of Manual Billing 10-8

h. Joint Invoicing/Individual Bill 10-9

i. Manual Billing: Unit Summary 10-10

j. Manual Billing: Exercises 10-11

k. Manual Billing: Solutions 10-12 Special Bi lling Features 11-1

a. Special Billing Features: Unit Objectives 11-2


c. Special Billing Features: 1 11-4

d. Franchise Fee Procedure in Germany/N. America 11-5

e. Franchise Fee Procedure 11-6

f. Franchise Fee: Data Retention 11-7

g. Special Billing Features: 2 11-8

h. Gas Procedure 11-9

i. Thermal Gas Billing 11-10

j. Gas Billing 11-11

k. Gas Billing: Overview 11-12

l. Gas Billing: Customizing 11-13

m. Gas Billing Components 11-14

n. Volume Correction Factor: 1 11-15

o. Volume Correction Factor <--> Temperature 11-16

p. Temperature Procedure 11-17

q. Volume Correction Factor: 2 11-18

r. Air Pressure 11-19

s. Volume Correction Factor: 3 11-20

t. Compressibility 11-21

u. Calorific Value Procedure 11-22

v. Relevant Master Data 11-23

w. Special Billing Features: 3 11-24

x. Lighting 11-25

y. Installation Facts: Reference Values 11-26

z. Reference Values: Data Relevant to Billing 11-27

aa. Special Billing Features: 4 11-28

bb. Structures of a Regulated Utility Company / Municipal Utility 11-29

cc. Structures of a Deregulated Utility Company / Regional Supplier 11-30

dd. The Utilities Market from the Customer's Perspective 11-31

ee. Billing Scenarios 11-32

ff. Billing Scenarios: Unbundled Billing 11-33

gg. Deregulation in the IS-U Data Model 1 11-34

hh. Deregulation in the IS-U Data Model 2 11-35

ii. Device Information Record 11-36

jj. Advantages of Separation 11-37

kk. Device Installation - Device Information Record 11-38

ll. Special Billing Features: 5 11-39

mm. The Archiving Process: Overview 11-40

nn. Initial Run 11-41

oo. Archive File 11-42

pp. Delete Program 11-43

qq. Storing Archive Files 11-44

rr. Influencing Factors 11-45

ss. Characteristics 11-46

tt. The Archiving Process 11-47

uu. Print Document 11-48

vv. Archiving Sequence: Print Document 11-49

ww. Budget Billing Plan 11-50

xx. Archiving Sequence: Budget Billing Plan 11-51

yy. Billing Document 11-52

zz. Archiving Sequence: Billing Document 11-53

aaa. Meter Reading Documents 11-54

bbb. Archiving Sequence: Meter Reading Documents 11-55

ccc. Special Billing Features: 6 11-56

ddd. Special Types of Billing 11-57

eee. Dynamic Period Control (DPC) 11-58

fff. Example of Using DPC 11-59

ggg. Monthly Billing with Interim Bill 11-60

hhh. Flexibility 11-61

iii. DPC Customizing 11-62

jjj. Billing Period Categories 11-63

kkk. Periods to be Created 11-64

lll. Time Slice Generator 11-65

mmm. Example: Time Slice Generator and Schema Step 11-66

nnn. Example: DPC Flow 11-67

ooo. Rate Modeling and Schema Transfer 11-68

ppp. Period Billing 11-69

qqq. Multiple-Contract Billing 11-70

rrr. Multiple-Contract Billing: EDM 11-71

sss. Billing with EDM 2 11-72

ttt. Billing with EDM 1 11-73

uuu. Multiple-Contract Billing: Objectives 11-74

vvv. Reasons for Outline Agreements 11-75

www. Data Structure of Outline Agreements 11-76

xxx. Data Exchange 11-77

yyy. One-Level Outline Agreements 11-78

zzz. Multi-Level Outline Agreements 11-79

aaaa. Terms of Outline Agreements 11-80

bbbb. Transaction EAOUTL 11-81

cccc. Customer Include 11-82

dddd. Procedure 1 11-83

eeee. Procedure 2 11-84

ffff. Multiple Contract Billing: Modular System 11-85

gggg. Multiple-Contract Billing 11-86

hhhh. Action Points 11-87

iiii. Billing Program Flow 11-88

jjjj. Special Billing Features: Unit Summary 11-89 Sales Statis tics 12-1

a. Sales Statistics: Unit Objectives 12-2


c. Sales Statistics: 1 12-4

d. Data Warehouse Concepts 12-5

e. Logistics Information System (LIS) 12-6

f. Logistics Information System (LIS) 12-7

g. Business Information Warehouse (BW) 12-8

h. Sales Statistics: 2 12-9

i. Information Flow/Concept 12-10

j. Format of Information Structures 12-11

k. Period Determination 12-12

l. Graphics 12-13

m. Sales Statistics: 3 12-15

n. Architecture 12-16

o. Business Content for the Utilities Industry 12-17

p. Installation Stock Statistics 12-18

q. Extractors/DataSources 12-19

r. Update Mode: 1 12-20

s. Update Mode: 2 12-21

t. Update Mode: 3 12-22

u. Transaction Data 12-23

v. Master Data 12-24

w. Stock Statistics 12-25

x. Transaction Statistics 12-26

y. Sales Statistics 12-27

z. Why is Data Not Updated? 12-28

aa. Sales Statistics: 4 12-29

bb. Determination of Update Group 12-30

cc. Why Update Groups? 12-31

dd. Statistics Groups: Quantities 12-32

ee. Statistics Groups: Amounts 12-33

ff. Sales Statistics: Unit Summary 12-34 Sales Statis tics: LI S (Appendix A) 13-1

a. Sales Statistics: Contents 13-2

b. Sales Statistics: Unit Objectives 13-3

c. Billing/Invoicing: Business Scenario 11 13-4

d. Sales Statistics: 1 13-5

e. Data Warehouse Concepts: Overview 13-6

f. Data Warehouse Concepts 13-7

g. Logistics Information System (LIS) 13-8

h. Logistics Information System (LIS) 13-9

i. Sales Statistics: 2 13-10

j. Information Flow/Concept 13-11

k. Elements of the LIS 13-12

l. Information Flow / Technical View 13-13

m. Format of Information Structures 13-14

n. Field Catalogs 13-15

o. Setting Up an Information Structure 13-16

p. Generating Information Structures 13-17

q. Update Rules: Key Figures 13-18

r. Update Rules: Characteristics 13-19

s. Period Determination 13-20

t. Activating Updating 13-21

u. Determination of Update Group 13-22

v. Statistics Groups: Quantities 13-23

w. Statistics Groups: Amounts 13-24

x. Overview of Updating 13-25

y. Formulas and Conditions 13-26

z. User Exits in UIS 13-27

aa. Sales Statistics: 3 13-28

bb. Update Log and Simulation 13-29

cc. Why is Data Not Updated? 13-30

dd. Rebuilding of Statistics Data 13-31

ee. Sales Statistics: 4 13-32

ff. From the Document to the Analysis 13-33

gg. Standard Drilldown 13-34

hh. Switch Drilldown 13-35

ii. Comparisons 13-36

jj. Graphics 13-37

kk. Settings 13-39

ll. Early Warning System 13-40

mm. Capabilities of the Early Warning System 13-41

nn. Defining an Exception 13-42

oo. Sales Statistics: 5 13-43

pp. Flexible Analyses 13-44

qq. Flexible Analyses: Example Transaction Statistics 13-45

rr. Sales Statistics: 6 13-46

ss. Business Model: Controlling 13-47

tt. Typical Questions in Profitability and Sales Accounting 13-48

uu. Aim of Profitability Analysis 13-49

vv. Basic Concepts in CO-PA 13-50

ww. Origin of Value Fields 13-51

xx. Integration IS-U / CO-PA: 1 13-52

yy. Integration IS-U / CO-PA: 2 13-53

zz. Sales Statistics: Unit Summary 13-54

aaa. Sales Statistics: Exercises 13-55

bbb. Sales Statistics: Solutions 13-57 Appendix B and C 14-1

a. Appendix B 14-2

b. Appendix C 15-38

SAP AG 1999

IUT230 Abrechnung und Fakturierung

Billing and

Invoicing

Billing and

Invoicing

IUT230IUT230

� R/3 System

� mySAP Utilities 4.63 / IS-Utilities / Customer Care Service

� Oktober 2001

� 5004 4898

SAP AG 1999

Copyright 2001 SAP AG. All rights reserved.

Neither this training manual nor any part thereof may

be copied or reproduced in any form or by any means,or translated into another language, without the priorconsent of SAP AG. The information contained in this

document is subject to change and supplement without prior notice.

All rights reserved.

Copyright

� Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®,

Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ® are

registered trademarks of Microsoft Corporation.

� Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation.

� Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.

� ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken

� Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.

� TouchSend Index ® is a registered trademark of TouchSend Corporation.

� Visio ® is a registered trademark of Visio Corporation.

� IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation.

� Indeo ® is a registered trademark of Intel Corporation.

� Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape

Communications, Inc.

� OSF/Motif ® is a registered trademark of Open Software Foundation.

� ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.

� INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.

� UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation.

� ADABAS ® is a registered trademark of Software AG

� The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3,

R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime,

SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and ALE/WEB.

The SAP logo and all other SAP products, services, logos, or brand names included herein are also

trademarks or registered trademarks of SAP AG.

� Other products, services, logos, or brand names included herein are trademarks or registered trademarks

of their respective owners.

SAP AG 1999

SAP Utilities (IS-U/CCS)

Introduction to the IS-U/CCS

IUT110 5 days

Level 2 Level 3

Work Management

IUT221 3 days

Customer Service

IUT250 4 days

Contract Accounts Receivable and Payable

IUT240 5 days

Print Workbench

IUT280 2 days

Device Management

IUT220 3 days

Billing and Invoicing

IUT230 5 days

Basic Data/ BasicFunctions

IUT210 3 days

Real Time Pricing

IUT235 2 days

Energy DataManagement

IUT225 2 days

SAP AG 1999

Course Prerequisites

� Basic knowledge of the Windows operating system environment

� Basic SAP knowledge

� Course IUT 110: Introduction to the IS-U/CCS System

� Course IUT 210: Master Data and Basic Functions

SAP AG 1999

Target Group

� Audience:

� Project team modeling business processes with IS-U

� Administrators optimizing processes in the IS-U environment

� Consultants preparing for IS-U implementation

� Duration: 5 days

SAP AG 1999

Course Goals

This course will prepare you to:

� Describe the process that starts with billing and

invoicing and finishes with bill printout

� Outline all IS-U/CCS master data and functions relevant to billing

� Explain how rates and prices are modeled in the IS-U/CCS system

SAP AG 1999

Course Objectives

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

� Describe billing master data in IS-U/CCS

� Perform billing and invoicing

� Create the most important billing master data in the

system

� Configure Customizing settings for billing and invoicing master data

SAP AG 2000

SAP AG 1999

Unit 6 Invoicing

Unit 7 Budget Billing

Unit 8 Bill Printout

Unit 9 Discounts/Surcharges

Unit 10 Manual Billing

Unit 11 Special Billing Features

Unit 12 Sales Statistics

Unit 1 Business Scenario

Unit 2 Billing in the IS-U Data Model

Unit 3 Billing Master Data

Unit 4 Use of Rates in the Master Data

Unit 5 Billing

Preface

Appendices

Exercises and Solutions

Course Content IUT230

(C) SAP AG IUT230 1-1

SAP AG 1999

Business Scenario

� Introduction to the business scenario and the relevant components


SAP AG 1999

Business Scenario: Unit Objectives

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

� Discuss the business process used to explain billing

master data and billing and invoicing in IS-U/CCS

� Identify the steps required for processing the business scenario

SAP AG 2001


SAP AG 1999

Energy and Service Company

IDES Utilities Inc.

Telecommuni-

cations

MultimediaElectricity

Gas

Water Waste water Waste disposal

District Heating

� IDES Utilities Inc. is a municipal utility company that deals with the classical divisions of electricity,

gas, water and waste water. New business areas are also being developed to create additional divisions

such as waste, telecommunications and multimedia.


SAP AG 1999

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 gain new

customers.

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

area.


SAP AG 1999

Branches

Sales &Distribution

TechnicalBoard of Directors

Head Office

Market

EnergyIndustry

Data Processing

Grid

Logistics

Construction

CommercialBoard of Directors

Organizational Structure


SAP AG 1999

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 electr. =Basic price =Rental price =

UNI 0.24UNI 100.00UNI 50.00

------Municipal Services New X---------


SAP AG 1999

Contract (Residential Customer - Electricity)

1. Customer without measured demand

Consumption Prices

Without off-peak regulation

With off-peak regulation- On-peak rate

- Off-peak rate

Demand Price (fixed contribution per installation)

Rental Price

2. Average Price Limitation

Energy Prices- Maximum price (on-peak rate)- Off-peak rate

Rental Price

3. Rental Prices

- Single-rate meter- Double-rate meter

For annual consumption of less than 10,000 kWh/year

0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3

0.48 UNI/kWh0.11 UNI/kWh

50 UNI/year70 UNI/year

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

� This contract will be mapped in the system in the following units.


SAP AG 1999

MaintainMaintain

BillingBilling

Master DataMaster Data

Use of Ratesin the

Master Data

Use of Ratesin the

Master Data

InvoicingInvoicing Bill Printout

Bill Printout

BillingBilling

Budget BillingsBudget Billings

Additional Functionality:Additional Functionality:

Discount/SurchargeDiscount/Surcharge

Manual BillingManual Billing

Sales StatisticsSales Statistics

Special Billing FeaturesSpecial Billing Features

Billing/Invoicing: Business Scenario 10

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


SAP AG 1999

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


SAP AG 1999

Billing in the IS-U Data Model

SAP AG 2001

This unit will prepare you to:

� Describe the integration of billing master data in the IS-U data model

� Structure the component hierarchy for billing and

invoicing

� Outline the billing functions and the billing master data


SAP AG 1999

Billing in the IS-U Data Model: Unit Objectives

SAP AG 2001


� Identify the billing tasks in the IS-U system

� Identify the master data relevant to billing

� Explain how the rate data model is integrated in the component hierarchy


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master Data

InvoicingInvoicing Bill Printout

Bill Printout

BillingBilling

Budget BillingsBudget Billings


Discounts/SurchargesDiscounts/Surcharges





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


SAP AG 1999

Electricity

Gas

Water/

Waste waterDistrict heating

Cable T.V.Multimedia

Charges,

taxes

Divisions

Residential customer

Nonresidential customer

Co-generator

BusinessPartner

Billing Rules, VariantsBilling Rules, Variants

ConsumptionDemand

Flat Rates

Discounts,surcharges

Generalduties

Prororations Franchisefees

Priceadjustment

. . . . . .

Waste disposal

IS-U/CCS Billing: 1

� IS-U can bill nonresidential 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 IS-U: 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


SAP AG 1999

SD

AMMM

GIS,CAD,SCADA

GIS,CAD,SCADA

MMPM/CS

SD

FI

CO-

Sales &Distribution

Sales &Distribution

Contract

Rec. & P

ayable

(FI-C

A)Contract

Rec. & P

ayable

(FI-C

A)Billing/

Invoicing

Billing/

Invoicing

Insta

llatio

n

Serv

ices

Insta

llatio

n

Serv

ices

Co

nsu

mp

tio

nD

ata

Co

llecti

on

Co

nsu

mp

tio

nD

ata

Co

llecti

on

Third-PartyConsumption

Data CollectionSystems

Third-PartyConsumption

Data CollectionSystems

Third-PartySales

Systems

Third-PartySales

Systems

Standard SAP

Business

Partner

Customer careand service system

IS-Ucomponents

Standard SAPcomponents

External systems

Financial Accounting


DeviceManagement

DeviceManagement

C

USTOM E

RPlant Maintenance& Customer Service

Plant Maintenance& Customer Service

Asset andMaterials Management

Asset andMaterials Management

CA

RE

& S ERV

I CE

IS-U/CCS as an

integrated componentof the SAP corporate

information system

IS-U/CCS: Integration Model

� The utility services of a company are calculated in IS-U billing. In addition, other services that have

been billed can be included in IS-U invoicing using the Sales and Distribution (SD) component. The

same is true for billing results from external billing systems.

� Billing and invoicing in IS-U is an original component of IS-U/CCS, meaning that no essential part of

the R/3 core system is used.


SAP AG 1999

Billing (Utility Services)

� Based on a universal billing engine

� Billing of residential and nonresidential customers contracts

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

� Possibility of handling new billing procedures

� Convergent billing and intercompany invoicing

� Special features: 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 last 12 months (or less in the case of new customers).


SAP AG 1999

On a monthly basis

� Key date

� Period

� For an exact no. of days

� Season-based

� Comparative (best-rate

billing)

� Floating (backbilling,

period-end billing)

� Interim Billing

� Outsorting for

bill validation

� Simulation

� Manual billing

� Reversal procedure

� Unbilled revenue reporting

Functions

IS-U/CCS Billing: 2

� Manual billing is carried out in addition to automatic consumption billing.

Examples:

� Consumption billing if register is faulty

� Backbilling for theft of electricity

� Goodwill credit memo


SAP AG 1999

Business Objects / Utility Services

Device Category

Device Category

ConnectionObject

ConnectionObject

ConnectionConnectionDevice

Location

Device Location

PremisePremise

RegionalStructure

RegionalStructure

Point of Delivery

Point of Delivery

Contract Account

Contract Account

Utility Installation


DeviceDevice

Meter Reading

Meter Reading

Contract(Supply)Contract(Supply)

BusinessPartner

BusinessPartner

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


SAP AG 1999

Billing Master Data

Special Functions

Billing Execution

Billing

Bill Processing

Bill Printout

Budget Billing Plan

Invoicing

Basic Functions

Master Data

Device Management

Contract A/R & A/P

Customer Service

Work Management

Tools

Utilities Industry

Customizing

Component Hierarchy / IMG

Statistics

Information System

Contract Billing

Invoicing

Information System

� Component hierarchy: organizational tool for displaying all the R/3 components.

� The user interface of the component hierarchy works like a file manager with a hierarchical structure. In

this way, you can display the applications provided in the system and company-internal applications.

� The component view ensures component-related access to different models of the R/3 reference model

(for example, access to processes or business objects).

� The IMG for IS-U/CCS is for the most part identical to the component hierarchy at the two top levels. At

the lower levels, it may be structured differently.


SAP AG 1999


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3



Rate category,e.g. household

Link Between Contract Text and IS-U: 1

� The rate category classifies the installation for billing.

The following are some examples of rate categories:

� Household rate

� Trade rate

� Trade rate with measured demand

� Industry rate

� Low consumption rate

� Basic price rate 1


� Standard water

� Reserve water

� Extinguishing water


SAP AG 1999


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3




Rate Type

Rate Type


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


SAP AG 1999


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3



Rate category,e.g. household+

Rate Type

Rate Type

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.


SAP AG 1999


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3




Rate Type

Rate Type

Rate

Rate

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). In this case,

the demand price (basic price flat rate) and the rental price are included in the on-peak rate as variant

programs.


SAP AG 1999


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3




Rate Type

Rate Type

Rate

Rate

Variant Programs

Prices


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


SAP AG 1999


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3




Rate Type

Rate Type

Rate

Rate

Variant Programs

Prices

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.


SAP AG 1999

Rate

Determ.

Rate

Determ.

Rate Data

Rate category

Prices andRate FactsPrices andRate Facts

Procedural Data

Schema I

Rate Var.Prog. Values

Rate 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

EXECUTI

ON

ContractContract

Utility

Installation

Utility

Installation

Inst. Structure/Rate Cat. Facts/

Install. Facts

Inst. Structure/Rate Cat. Facts/

Install. Facts

Rate 1Rate 1

Rate nRate n

Generationof Billing

Line Items

Validation

of Billing

Results

Execution

of Variant

Programs

According to

Schema

Quantity

Conversion

and

Proration

Data Entryand

Analysis

Rate T

ype

Universal Billing Engine

Customer- andInstallation-Related Data

� 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 quantities read. 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


SAP AG 1999

QUANTITY FACTOR QUANTITYCalculates x% of a quantity


. . . . . .

. . . . . .

NUMBER OF DEMAND PEAKS DEMANDCalculates N peak averages


DEMAND PRICE BILLING LINE ITEMSValuates demand with a price


. . . . . .

QUANTITY QUANTITY QUANTITYDifference of two quantities


. . . . . .

. . . . . .

QUANTITY PRICE BILLING LINE ITEMSValuates energy with a price


ACTIVE_KWH 0.5 ACTIVE_50%ACTIVE_KWH 0.5 ACTIVE_50%

REACT_KWH - ACT_50% BILL_REACTREACT_KWH - ACT_50% BILL_REACT

BILL_REACT 0.06 UNI BILLINGLINE ITEMS


Variant PoolVariant Pool


Contract text:

The reactive energy that exceeds 50%

of the active energy is valuated using a

separate price.

Contract text:



separate price.

*

*

* *

*

-

Flexible Structure of Billing Rules

� SAP provides a pool of variant programs with the system. This pool contains many variant programs.


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.


SAP AG 1999

Master Data and Billing Master Data

Bus. Partner

Contract

Utility Install.

XYZ0011

Installation Structure

Device Zw Rate type

12345678 001 1001

12345678 002 1002

Installation Facts

EREFVAL=8kW

Rate category

E1

Schema:

E1

Rate Facts

EQPRICE1=

E1_1_1...

Rate Determ.

Rate cat. Rate type Rate

E1 1001 E1_1

E1 1002 E1_2

Schema E1

...

Rate Variant Operands

E1_1 QUANTI01 EQUANT1 EQPRICE1

E1_1 REFVAL01 EREFVAL ETPRICE1

...

Rate Variant Operands

E1_2 QUANTI01 EQUANT2 EQPRICE2

...

� This shows the connection between the master data and the billing master data.


SAP AG 1999

FI-CA Documents

Budget Billing

Plans

Maintenance of

Documents

Receivables:

$100

Physical

Printout

Invoicing- Data entry

- Validation

- Processing of

FI-CA Documents

Receivables:

$100Receivables:

100 UNI

Manual BillingPrint

Documents

Print

Documents

FI-CA

Posting

Documents

FI-CA

Posting Documents

Budget Billing

Plans

Budget Billing

Plans

SD

Documents

Invoicing

� Invoicing

� generates posting documents for bill receivables or credit memos from the billing documents

� settles 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 settlement control (for example, settling

payments on account with receivables from invoicing)


SAP AG 1999

Billing in the IS-U Data Model: Unit Summary

SAP AG

� Billing is the central component of the IS-U system for calculating energy and water supplied to

customers.

� The central billing engine enables you to model all

possible combinations of different billing steps.

� Rate determination allows for quick adjustment of entire customer groups to the company's new rates.

� Invoicing is the standard IS-U process that establishes the link to contract accounts receivable and payable, and provides the basis for bill creation.


SAP AG 1999

Billing Master Data

SAP AG 2001

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

Billing: Unit Objectives

SAP AG 2001


� Define the billing master data in the IS-U System

� Describe the dependencies between the individual objects

� Maintain the billing master data in the correct order


SAP AG 1999

MaintainBillingMaster Data

Use of Ratesin the

Master Data

Use of Ratesin the

Master Data

InvoicingInvoicing BillPrintout

BillPrintout

BillingBilling

Budget BillingsBudget BillingsBudget Billings

Additional Functionality:

Discounts/SurchargesManual Billing

Sales StatisticsSpecial Billing Features







� In this unit, you will create the billing master data. The master data is then tested in the billing process.

� As a member of the sales department, you should understand the process of defining billing master data

in the system, for which you will primarily use the implementation guide (IMG).


SAP AG 1999

Billing Master Data: 1

� Individual Components

� Modeling of the Billing Logic

� Facts

� Dynamic Rate Determination


SAP AG 1999

Billing Modules: 1

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

InstallationInstallation

Installation structure

Installation

structure

Rate categoryRate category

Rate typeRate type

Rate

determination

Ratedetermination

RatesVarProg.

RatesVarProg.

Billing schemaBilling schema

Rate 1Step 1Step 2

Rate nStep 1

VarProg.Example: Quantity x priceComparison of 2 demands

Operand values1000 kWh, 0.25UNI400 kW, 300 kW

Data Model for Billing

OperandsOperands

Operand valuesOperand values

� The billing master data that is to be dealt with is displayed here, along with the corresponding names.


SAP AG 1999

Billing Modules: 2

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

� Classifies installations within a division, for example

residential/nonresidential contract.

� Can be valid for several rate categories.

� Used for plausibility checks in scheduling and in the billing

master data.

� Enables several franchise fee groups to be defined.

� Can be used as a statistical criteria.

� If you change the billing class, you must also change the rate category. You do not have to perform a final billing.

Billing Class I

� 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 criteria, for example in the sales statistics.


SAP AG 1999

Utility

Installation

Utility

Installation

RateRate

PortionPortion

Billing Class

(Classification,

Validation)

Billing Class

(Classification,

Validation) Meter

Reading Unit

Meter

Reading Unit

Rate CategoryRate Category

Rate TypeRate Type

Billing Class: 2

PricePrice

SchemaSchemaDiscountDiscount

� The billing class is used in the following objects:

� Utility installation

� Rate category

� Rate type

� Price

� Rate

� Schema

� Portion

� Meter reading 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.


SAP AG 1999

Billing Modules: 3

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

� Used to classify

� Registers

� Devices

� Flat rates

� Reference values

for billing

� Examples: peak and off-peak rates for active energy; peak rate for reactive energy; peak rate for active power; gas and water

consumption; flat rate installations

� The rate category is used in conjunction with the rate type 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.

� In exceptional cases you can 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 settlement price.

� Facts

- Used to determine rates that cannot be derived from registers.

- Also used to determines rates for flat rate installations without installed devices.


- Used to model street lights, for example


SAP AG 1999

Rate Type: 1

� Is valid for a particular division (obligatory) and billing class

(optional)

� Use of the rate type can be permitted for:

� Register

Must be specified for registers relevant to billing

� DeviceFor example: Rental price for devices that do not have registers relevant to billing

� FactsFor example: Flat rates or installation flat rates

� Interval meterFor example: For billing real time pricing (RTP) rates

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

� Waste billingFor example: For determining special rates 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.

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


SAP AG 1999

Rate Type

Rate Category

Register

Device

Rate Type: 2




� Off-peak rate reactive energy

� Gas consumption


� Interval meter

� Rental price (device-related)

� Flat-rate installations

� Additional rates� Flat-rate installations


� Facts for period-end billing

Utility installation

� The rate type is 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.


SAP AG 1999

Billing Modules: 4

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

Prices

Price

Key

Prices for Billing

CentralPrice

Management

� 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. Historical 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.


SAP AG 1999

� Quantity-based price for quantities and consumption

� Flat ratefixed amounts per unit of time

(consumption flat rates and flat-rate amounts)

� Settlement price for the use of a measuring device over a certain

period of time

� Time-based pricefor demand and connection values

Price Categories

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


SAP AG 1999

� Normal pricePrice that is not based on the quantity

� Block priceOne or more prices that are based on the

quantity

� Scale pricePrice that is based on the quantity

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.


SAP AG 1999

Definition of Block Price and Scale Price

Q1 Q2 Q3 Q4 Q...

Block Price and Scale Price

P1

P2

P3

P4

P5

P...

Price type:- Block price

- Scale price

CustomizingCustomizing

Quantity limit- Inclusive up to block

- Exclusive as of block


Adjustment of quantity to billing period

in block 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.


SAP AG 1999

Block Price

P1

P2

P3

P4

P5

P...

Quantity to be billed

Scale Price

Q1 Q2 Q3 Q...

P1

P2

P3

P4

P5

P...

Quantity to be billed

Q1 --> P2

Q2 --> P2

Q3 --> P2

Rest --> P2

Price Determination

Scale Price:

Q1 Q2 Q3 Q...

Q1 --> P5Q2 --> P4

Q3 --> P3

Rest --> P2

Price DeterminationBlock Price

Block Price and Scale Price

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.


SAP AG 1999

Adjusting Price Blocks to Billing Periods

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

Interval upper limit: 375 days

Quantity-Based Price

Price Blocks0 - 3000

3000 - 50005000 - 10000

10000 - 9999999999

Price Blocks

0 - 30003000 - 5000

5000 - 1000010000 - 9999999999

Adjustment of blocks/scales to

billing period, e.g. 340 days


2795 - 46584658 - 9315

9315 - 9999999999


2795 - 4658

4658 - 93159315 - 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.


SAP AG 1999

Header Data for the Price Key

� Transaction Currency

� Billing Class

� Division

� Rounding Parameter

� Price Adjustment Clause

� External Price

� Average Price

� Gross Price

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

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


SAP AG 1999

Quantity-Based Price

Quantity-

basedprice

Quan

tity

ref.

Quan

tity

ref.

No tim

e ref.

No tim

e ref.

Unit of m

easure

Unit of m

easure

Quan

tity

base

Quan

tity

base

� Quantity-based prices are dependent on a quantity that is supplied,

(for example, energy prices).

� Quantity-based prices have no direct time reference. Exception: the price is a block or scale price. In this

case, for example, you may want the blocks to be adapted to a reduced billing period.

� To define a quantity-based price, base values are required for

- a unit of measure

- a quantity base

The corresponding calculations are performed in the system using these base values.

Example: Price per 1 kWh

Price per 1 cbm


SAP AG 1999

Time-Based Price

Time-Based

Price

Quan

tity

Ref

eren

ce Time R

eference

Time B

asis

Time

Cat

egory

� Time-based prices depend not only on a quantity but also on a time period.

Example: Demand prices

Connection loads

Reference values

� To define a quantity-based price, base values are required for

- a time basis

- a time category

benötigt. The corresponding calculations are performed in the system using these base values.

Example: Price per 1 kW per 12 months

Price per 1 cbm per 365 day


SAP AG 1999

Flat Rate

Flat Rate

No Q

uantit

y

Ref

eren

ce

No Q

uantit

y

Ref

eren

ce

Time R

eference

Time R

eference

Time B

asis

Time B

asis

Time

Cat

egory

Time

Cat

egory

� Flat rates are levied if values are not measured, for example, if using a meter would be uneconomical.

Flat-rate amounts are time-based prices without quantity reference. Examples are a basic price flat rate,

or street lighting.


SAP AG 1999

Rental Price

Rental

Price

Quan

tity

Ref

eren

ce

Quan

tity

Ref

eren

ce

Time R

eference

Time R

eference

Price Class

Price Class Pric

e Lev

el

Price

Level

� The rental price is the charge for supplying the customer with a measuring device (such as a meter) for a

certain period of time.

� The price level is used in the case of rental prices to differentiate prices with the same price class. In this

case, the price key takes on the function of a price class. This means that the permissible values for the

price key are defined in the check table for the price classes; you must maintain these values in

Customizing before you create prices.

� Price classes are allocated to the device category. This price class is transferred into the installation

structure when the device is installed and can be overwritten in exceptional cases.


SAP AG 1999

Price Adjustment Clause

Company

Bill

Company

Bill x y z

Basic Price

2.00

Price

Adjustment Clause1.50

Addition

+Multiplication

*

Final Price

for the CustomerFinal Price

3.50

Final Price

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


SAP AG 1999




� Facts



SAP AG 1999



. . . . . .

. . . . . .





. . . . . .



. . . . . .

. . . . . .



ACTIVE_KWH 0.5 ACTIVE_50%ACTIVE_KWH 0.5 ACTIVE_50%

REACT_KWH - ACT_50% BILL_REACTREACT_KWH - ACT_50% BILL_REACT





Contract text:



separate price.

Contract text:



separate price.

*

*

* *

*

-

Flexible Structure of Billing Rules

� SAP provides a pool of variant programs with the system. This pool contains many variant programs.


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.


SAP AG 1999

Billing Modules: 5

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

Operand

� Individually determined symbolic name or description for the

allocated values that are used as input and output parameters in variant programs

� Variable that is assigned a value 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.


SAP AG 1999

Operand category Description

AMOUNT Amount

DEMAND Services (general)

FACTOR Number with decimal places

QUANT Quantity (general)

QPRICE Quantity-based price

REFVALUE Reference value

SEASON Season

TPRICE Time-based price

Operand Categories/Examples

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


SAP AG 1999

Indicators for Operand Categories

� History

� Season-Based

� Obligatory/Optional Value

� Usage

� Unit of Measurement

� Access Control

� Real Time Pricing (RTP)

� These settings are stored in a system table (TE375). This table is part of the SAP system and should not

be changed by the customer. The table is not available in the IMG and has to be maintained using the

transaction SM30.

� Using the history, you can control whether the operand values for the operands can be maintained

historically, that is, whether the values of the operands at different periods of time can be displayed.

� The unit of measurement is the measuring value of a dimension (for example, kWh).

� With the Season indicator (season permitted for operand), you can control whether or not season-based

values can be maintained for operands of this category.

� The Optional and Mandatory indicator determines whether or not replacement values can be used for

this operand.

� The usage indicators define where operands of this category can be used. Examples: Installation, Rate

category

� Operands of the operand categories QUANT, DEMAND, and AMOUNT can be created as RTP

operands. RTP operands are used in RTP rates to copy the results of the RTP interface assigned to the

RTP rate.


SAP AG 1999

Operandcategories

Operands Operand values

• Predefined

• Control processing

via variant programs

• Determined

individually

• Serve as the

parameters for

variant programs

• Provide operands

with values

• Define actual

values

Rate Determination - Operands

� In the following objects, you can allocate values to the operands:

� rate facts

� Rate category facts

� Installation facts

� Dynamic determination at billing runtime


SAP AG 1999

Parameters for Operands

� Operand Use

� Division

� Operand Group

� Access Control

� History

� Rounding

� Weighting Key

� Demand Control

� Franchise Fee Control

� Contract-Related Operand

� You do not normally create the operands first. You can create the operands later in the rate.

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


SAP AG 1999

Demands

Contractual

Activities

Billed Demands

Ordered Demand 25 kW

Minimum Demand 10 kW

Maximum Demand 32 kW

..........

..........

Operand Groups

Opera

nds

Demands

Contract demands

Order

Minimum demand

Billed demand

Demands

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.


SAP AG 1999

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

Consumption

General

weighting

Degree days

Energy feeding

Linear

Jan Feb . . . Nov Dec

Weighting Procedure

� Linear weighting

� Weighting of energy feeding

� Weighting of degree days

� General weighting

� The energy feeding volume per period is used for weighting for the periodic distribution of consumption

and calculating a weighted average in thermal gas billing.

� For the weighting of degree days, you define temperature regions with similar temperatures. You then

specify the degree day coefficients for these areas and for each degree day.

� General weighting can be set individually. 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, weighting is determined via Rate Type �� Rate Determination �� Rate �� Register

Operand �� Weighting Key.


SAP AG 1999

Consumption Total

Degree Days

Linear

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


SAP AG 1999

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

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.


SAP AG 1999

Demand01/03 01/28

01/29 03/08

03/09 03/14

03/15 Last

day of month

10 kW

11 kW

12 kW

13 kWRate1

Rate2

01/03 02/05

02/06 03/30

01/03 03/30Bill. Period

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.


SAP AG 1999

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

Demand13 kW

03/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 kW

12 kW

13 kWRate1

Rate2

01/03 02/05

02/06 03/30

01/03 03/30Bill. Period

Facts

Last

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.


SAP AG 1999

Allocation of Operand Values: 1

Rate Category FactsRate Category Facts

Rate Facts and Rate Fact GroupRate Facts and Rate Fact Group

Have precedence over


H 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. You can also

define specifications for all rates in the rate category facts and the installation facts. These specifications

have preference over the rate facts.

� 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). With these replacement values,

flexible allocation of operand values is possible.

� You can also historically override 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, billing is aborted and the error is reported in the

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


SAP AG 1999

Contract-Related Operand – Not Activated

Contract

2

Contract

2

Customer2

Customer2

Customer1

Customer1

Contract

1

Contract

1

Move-out

Utility InstallationUtility Installation

08/01/2001

Interval 1:

04/15/97- 07/31/01

Interval 2:

08/01/01

Move-in

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

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.


SAP AG 1999

Contract-Related Operand - Activated


Interval 1:

04/15/97- 07/31/01

Interval 2:

08/01/01



Move-outMove-out 08/01/2001

� The time slices for the operand in the installation facts are prorated to the move-out date, and all future

time slices are deactivated. If the move-out is reversed, the original situation is restored.


SAP AG 1999

Contract-Related Operand - Move-In

Contract

2

Contract

2

Customer2

Customer2

Customer1

Customer1

Contract

1

Contract

1

Move-out


08/01/2001

Interval 1:

04/15/97- 07/31/01

Interval 2:

08/01/01

Move-in



Facts?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.


SAP AG 1999

Contract-Related Operand - Contract Change

Contract

2

Contract

2

Customer2

Customer2

Customer1

Customer1

Contract

1

Contract

1

Move-out


08/01/2001

Interval 1:

04/15/97- 07/31/01

Interval 2:

08/01/01

Move-in



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.


SAP AG 1999

IS-U billing schemaIS-U billing schema

y1

Result Function OperCat.

e1 Total QUANT

e2 Average DEMAND

e3 Peak DEMAND

Rate: ON_OFF_PEAK

RegOperand

RTP interface ON_OFF_PEAK

001 ....

... ...

007 QUANTI01 ONPEAKCON ... Pricing for ON peak consumption

008 QUANTI01 OFFPEAKCON ... Pricing for OFF peak consumption

... ...

Transfer Result to RTP Operand

� The concrete values of an RTP operand are the result of processing in the RTP interface. The RTP

interface obtains its input data from Energy Data Management (EDM).


SAP AG 1999

Billing Modules: 6

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

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.


SAP AG 1999

Variant Programs 2

ABAB/4

Function Modules

function isu_quanti01.

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

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

.....endif.

endfunction.

Input

Operands

Output

Operands

Billing

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


SAP AG 1999

Examples of Variant Programs

COMPUT01 Subtraction of two amounts

DEMAND01 Valuation of a demand with a price

DISCNT01 Quantity discount, percentg. or abs. 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)


SAP AG 1999

Billing Modules: 7

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

Rate Characteristics

� Permissibility of the rate

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

� Register-related data

� RTP rate and RTP interface

� Calculation formulae

� Allocation of values to operands (rate facts)

� Account determination

� Handling of billing line items

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


SAP AG 1999

Rate

Rate Steps

Variant

Programs

Operand

Operand

Category

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 billing values are measured by a register

� which reference values are billed

� in which calculation formulas the values are used

� which prices are used

� to which G/L accounts the calculation results (billing line items) are posted

� how the billing line items are dealt with statistically

� to which division and billing class the rate is allocated.


SAP AG 1999

Rate Header

� Division� Billing Class� Permissibility� Register-Related Data� Notes

Rate Attributes

Rate Steps

� Variant Programs� Sub-Transactions� Operands ---> Rate Facts� Statistical Rate� Franchise Fee Group� Control 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.


SAP AG 1999

Transactions

• Accountdetermination

• Tax det.

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

• Allocation to internal transactions • Default setting

by SAP

Sub-Trans-actions

FI-CA

MainTrans-actions

FI-CA

IS-UTrans-actions

IS-U

Allocation

IS-U

InternalSub-Trans.

SAP

InternalMain Trans.

SAP

Transactions describe the accounting transaction on which the posting of a document line item is based

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


SAP AG 1999

Sub-Transactions in IS-U Billing / Invoicing

Main

Trans.PeriodicBilling

Credit Memo

Energy Price

Credit Memo

Demand Price

.....

Receivable

Demand Price

Receivable

Energy Price

.....

.....

⇒⇒⇒⇒ can be freely defined / integrated in rates / account determination(main trans. and transaction)

⇒⇒⇒⇒ Allocated to internal transactions / no account determination

ReceivablePeriodic Billing

ReceivablePeriodic Billing

Credit MemoPeriodic Billing

Credit MemoPeriodic Billing

Credit Memo

Provisioning

Price

Receivable

Provisioning

Price

� The cumulation procedures should be allocated to the internal procedures. Account determination is not

defined for them.

� The procedures for price components can be freely defined and are included in the rates. Account

determination (relevant for main transactions and transactions) is defined for them.

� Transactions for all main transactions in billing (consumption billing / final billing / manual billing)

must be defined.


SAP AG 1999

Sub-Transactions in the Statistical Budget Billing Procedure in IS-U

BB Pay-Out Trans.

Transfer Posting

BB Payment

Transfer Posting

Budget Billing

Payment

.....

.....

⇒⇒⇒⇒ Allocation to internal transactions /no account determination

⇒⇒⇒⇒ can be freely defined (stat.) /included in rates /

account determination (BB amount)

Budget Billing

Pay-Out Trans. Budget Billing Plan

Credit

Budget Billing PlanDebit

MainTrans.

Budget Billing

Stat. Proc.

� The payment and transfer procedures should be allocated to the internal procedures. Account

determination is not necessary.

� The payment procedures should be defined as 'follow-on' transactions to the extrapolation procedures.

� The budget billing extrapolation sub-transactions are entered in the rates. They should be defined

statistically (debit = 'P' / credit = 'Z'). Account determination must be defined for these transactions.


SAP AG 1999

Account Determ.

(PosAr R000)Company Code 0001

Division 01

Account

determination ID 01

Balance sheet

account 140500

(Receivables for

energy supply)

ReceivablesAccount

Account Determination: Receivables Account

Contract /Contract Account

For example, billing:

Main trans. 0010

BusinessTransaction

� The account determination ID can be found in the contract account for multiple-contract or contract-

independent postings, or in the contract.


SAP AG 1999

For example, billing:

Main trans. 0010

Sub-trans. 0010

BusinessTransaction

Contract /Contract Account

Company Code 0001

Division 01

Account

determination ID 01

Account Determ.(PosAr R001)

TransactionDetermination

Profit/loss

account 800010

(Revenue from

energy price:

electricity)

Sales Revenue

Account

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.

� In addition, the sub-transaction is required for sales revenue account determination.

� Additional account assignments (for example, cost center, plant) and the tax determination ID are also

determined through sales revenue account determination.


SAP AG 1999

IMGIMG

...........

..........

..........

..........

Customizing forTime Period Control

Time Period Control

� Time Period Procedure

� For an exact number of days

� Key date

� Interval

� Alternative procedure 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:


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


SAP AG 1999

Variant Control

COMPUT01COMPUT02

COMPUT03COMPUT04

COMPUT08QUANTI02

QUANTI08QUANTI09

QUANTI10QUANTI15

COMPUT01COMPUT02

COMPUT03COMPUT04

COMPUT08QUANTI02

QUANTI08QUANTI09

QUANTI10QUANTI15

• Operand update - Addition

• Operand update - Overwrite

• Operand update - Addition• Operand update - Overwrite

Control Indicator

QUANTI*

DEMAND*

QUANTI*

DEMAND*• Write info lines about quantity• Write info lines about quantity

Control Indicator

� Using variant control, you can control the different variant programs. Control indicators are not the same

for all variant programs but depend on each variant program's task.


SAP AG 1999




� Facts



SAP AG 1999

Billing Modules: 8

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

FactGroup

Fact Group

Rate

Operand

Value A

OperandValue B

Fact groups enable different operand values to be used within one

rate.

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





SAP AG 1999

Price C0.70

Price C0.70

Price B0.60

Price B0.60Rate category

factsRate categoryRate category

factsfacts

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



Price A

0.55

Price A

0.55

H i

e r

a r

c h

yAllocation of Operand Values

Installation facts

Installation facts

� Operand values are usually stored in the rate facts and are, therefore, valid at rate level. You can also

define specifications for all rates in the rate category facts and the installation facts. These specifications

have preference over the rate facts.




� You can also historically override 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, billing is aborted and the error is reported in the

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


SAP AG 1999

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.

Rate

Category

Rate

Category

Rate

Type

Rate

Type

RateRate

Installation

Facts

Installation

Facts Rate FactsRate Facts

Rate Category

Facts

Rate Category

Facts


SAP AG 1999

Contract Billing Modules: 9

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

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.


SAP AG 1999

Billing Schema: 2

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

� Controls gross billing

� Controls dynamic period control

� Controls billing in advance

� Dependent on the rate category in

the installation


SAP AG 1999

Schema Attributes

Schema Header

� Division� Billing Class� Billing Block� Period-End Billing/

Backbilling� Notes

Schema Steps

� Rates� Control Indicator� Presort Key� Deletion Operand� Gross Line Items

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


SAP AG 1999

Installation Disconnection in Billing

Technical reasons

Customer request

Vacancy

(move-out w/o move-in)

Reach disconnection

dunning level FI-CA

1999

01/09 .... .... .... .... .... .... 01/14

Billing Period

Bill basic price for disconnection period?

Control at schema step level

Bill basic price for disconnection period?

Control at schema step level

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


SAP AG 1999

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.


SAP AG 1999

Billing Modules: 10

� Billing Class

� Rate Type

� Price

� Operand

� Variant Program

� Rate

� Fact Group

� Schema

� Rate Category


SAP AG 1999

� 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 floating backbilling and period-end billing for

nonresidential customers

� Controls advance billing and dynamic period control

Rate Category I

� The billing class classifies installations for billing. The rate category is used in conjunction with the rate

type to determine the rate. Examples of rates are:

� Household rate

� Commercial rate

� Commercial rate with demand measurement

� Industrial rate

� Minimal consumption rate



� Domestic water

� Reserve wasser

� Water for fire fighting

� Rate determination:

rate type + rate category = rate


SAP AG 1999

RateCategoryBilling Class

OutsortingGroup

Division

Notes Backbilling/Period-End Billing

Dynamic

Period Control

Billing Schema

Advance Billing

Rate Category II

� The rate category contains data that controls the processing of billing data. This includes:

� Billing Schema

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


SAP AG 1999




� Facts



SAP AG 1999

Rate

Category

Rate

Category

Rate TypeRate Type

Historical

Dynamic Rate Determination

RateRateRateRate

RateRateRateRate

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


SAP AG 1999

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

Rate type (e.g. ripple control receiver)

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

BillingMaster Data

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

Installation

Structure

Register

Device

Billing-RelevantObjects

Use of Rates

Rate Category

Facts

Installation Facts

� The rate is comprised of a combination of the rate type and the rate category.


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


SAP AG 1999

Initial Data Creation of a Rate

Rate TypeRate Type

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

Lin

k to

fac

t gro

up

Determine

VariantPrograms

VariantPrograms

Determine RateSequence

RateSequence

Select BillingSchema

BillingSchema

AllocateRatesRates

Rate Category

Rate Category

RatesRates

Billing SchemaBilling Schema

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

Rate Determ.Rate Determ.

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


SAP AG 1999

Contract (Residential Customer - Electricity)


Consumption Prices



- Off-peak rate


Rental Price



Rental Price

3. Rental Prices



0.24 UNI/kWh

0.24 UNI/kWh

0.11 UNI/kWh

100 UNI/year

See no. 3

See no. 3



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

� This contract will be mapped in the system in the following units.


SAP AG 1999

Billing Mater Data: Unit Summary

� Billing is the central component of the IS-U system

for calculating energy and water supplied to

customers.

� The central billing engine enables you to model all

possible combinations of different billing steps.

� Rate determination allows for quick adjustment of

entire customer groups to the company's new rates.

SAP AG


Exercises Data

Explanation of Symbols in Exercises and Solutions

Exercises

Solutions

Course Objectives

Business Scenario

Tips & Tricks

Warning or Note

Data in the Exercises

Data Data in the training system

Company code: U300

U400

Division: 01 Electricity

02 Gas

03 Water

06 Waste management

10 Cable TV

Currency: UNI

Billing class: 0001 Residential customer

0002 Nonresidential customer

0003 Company consumption

0004 Plant consumption

Account determination

ID:

01 Residential customer

02 Nonresidential customer


Operand: EQUANT___1

EQUANT___2

EQUANT___4

EQUANT___5

EQPRICE__1

EQPRICE__2

EAMOUNT__1

EAMOUNT__2

EPDISCNT_1

EQDISCNT_1

GQDISCNT_1

WQDISCNT_1

EFACTOR__1

Price: TE1_1_1##

E1_1_1

E1_2_1

Rate: TE1_1##

Business partner /

Contract account /

Contract /

Utility installation

TF0415A0##

TF0502A0##

TF0601A0##

TF0602A0##

TF0603A0##

TF0605A0##

TF0701A0##

TF0703A0##

TF0801A0##

TF0803A0##

TF1001A0##

TF1101A0##


Subtransactions: 0011

0021

0110

0120

Variant programs: COMPUT19

LUMSUM01

REFVAL01

SETTLE01

QUANTI01

QUANTI03

QUANTI04

QUANTI05

QUANTI11

QUANTI19

QUANTI21

UTILIT02


Billing Master Data: 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 rate types 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 the rate type 1001 allocated?

_________________________________________________________


Exercises


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 begin with the definition?

_________________________________________________________

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

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

Initial data

Price PE1_1_1##

Transaction currency UNI

Price category Quantity-based price

Price type Standard price

Header data

Price text Energy price ##

Billing class Residential customer

Division Electricity

Unit of measurement Kilowatt-hours

Historical data

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.

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


Initial data

Price TE1_1_2##


Price category Quantity-based price

Historical data

Valid from January 1st of this year

Qty base 1

Price amt 0,28

2-4 True or false.

2-4-1 The decision as to whether the price is quantity or time-based is made with 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.

_________________________________________________________


Exercises


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 the quantity operand EQUANT___1 rounded off?

____________________________________________________________


Exercises


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 Calculating a new rate involves evaluating a quantity with a price.

4-1-1 Determine all variant programs in the system that use the input operand from

operand category QUANT and QPRICE.

___________________________________________________________

4-1-2 Which output operands (category) are used for these variant programs?

___________________________________________________________

4-2 Read the online documentation.

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

4-2-2 Access the program documentation.

4-2-3 Read the information regarding the functionality of the variant program.


Exercises


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

to find out.

____________________________________________________________

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

____________________________________________________________


5-3 Create a new rate using the following.

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

Header data

Rate PE1_1##

Data


Text Rate ##


Permissibility Reg. Permiss.

Min.port. 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


Exercises


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 60% on-

peak rate and 40% 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 linked?

____________________________________________________________

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?

____________________________________________________________

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

____________________________________________________________

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

Price 1 E1_1_1

Price 2 E1_2_1

EQUANT___4 Determination at runtime

EQUANT___5 Determination at runtime


Exercises


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-1 In the implementation guide, choose Define Schemas.

7-1-2 Access the documentation.

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 ##



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?

________________________________________________________


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##


Data

Text Rate category ##


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


Billing Master Data: Solutions


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 �� AcceleratedSAP �� Customizing �� Project Management. 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


Solutions


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

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


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.

(C) SAP AG IUT230 3-100

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


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

(C) SAP AG IUT230 3-101

Solutions


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

Choose the List of operands button.

Click on 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?



→ → → → Display Operands.

Choose the List of operands button.

Enter QDISCNT in the operand category field. Execute.

This contains the following operands:

EQDISCNT_1

GQDISCNT_1

WQDISCNT_1

(C) SAP AG IUT230 3-102

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 initial screen, enter the operand EQPRICE__1.

Operand categor : QPRICE

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




In the initial screen, enter the operand EQUANT__1.

Rounding: 0 to whole numbers

Rounding cat.: X round up or down to nearest whole number

(C) SAP AG IUT230 3-103

Solutions


Topic: Variant Programs

4-1 Calculating a new rate involves evaluating a quantity with a price.

4-1-1 Determine all variant programs in the system that use the input operand from

operand category QUANT and QPRICE.


Billing Master Data →→→→ Rate Structure →→→→ Analyze Variant Programs.

In the first Input operand category field, enter the value QUANT, and in the

second, enter the value QPRICE.

Execute.

You will find, for example, the following variant programs:

COMPUT19

QUANTI01

QUANTI11

QUANTI19

QUANTI21

QUANTI23

QUANTI98

QUANTI99

4-1-2 Which output operands (category) are used for these variant programs?

You find the following output operands:

COMPUT19 QPRICE QPRICE

QUANTI01 AMOUNT

QUNATI11 AMOUNT

QUANTI19 QUANT QUANT QUANT

QUANTI21 AMOUNT

QUANTI23 -

QUANTI98 QUANT AMOUNT

QUANTI99 QUANT AMOUNT

(C) SAP AG IUT230 3-104


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


Billing Master Data →→→→ Rate Structure →→→→ Analyze Variant Programs.

Enter the value QUANTI03 in the Variant program.

Execute.

You find the list with variant program QUANTI03.

Select and display the variant program.

4-2-2 Access the program documentation.

Select Documentation.

4-2-3 Read the information regarding the functionality of the variant program.

(C) SAP AG IUT230 3-105

Solutions


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?


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?


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

(C) SAP AG IUT230 3-106

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.

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

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



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

(C) SAP AG IUT230 3-107

Solutions


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?


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?


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

(C) SAP AG IUT230 3-108

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

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


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.

(C) SAP AG IUT230 3-109

Solutions


Topic: Schema / Rate Category


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


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


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 → → → → Overviews →→→→ List of Operands.

Operand categories: 3

Operand categories:

QUANT

QPRICE

FACTOR

(C) SAP AG IUT230 3-110

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


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.


SAP AG 1999 SAP AG 2001

� Master Data Relevant to Billing

� Check Functions

� Special Billing Models

� Transport of Billing Master Data

Use of Rates in Master Data


SAP AG 1999


� Explain where billing parameters are linked to master data objects in the IS-U system

� Check billing master data for consistency

� Model special billing rules

� Transport billing master data

SAP AG 2001

Use of Rates in Master Data


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data


BillPrintout

BillingBilling



Discount/SurchargeManual Billing








� The scenario in this unit deals with linking the previously created billing master data with the master

data (installation and installation structure).

� You can enter a new rate determination and specify the billing master data in the master data.

� You can also create the complete range of billing data from the rate category to the rate determination to

help consolidate your newly acquired knowledge.


SAP AG 1999


� Check Functions



Use of Rates in Master Data: 1


SAP AG 1999

Contract Rec. & Payable

Contract Rec. & Payable

ConnectionConnection

Contract(Supply)Contract(Supply)

ConsumptionPremise

ConsumptionPremise

BusinessPartner

BusinessPartner

RegionalStructure

RegionalStructure

Meter Reading

Meter Reading

DeviceDevice



ConnectionObject

ConnectionObject

Business Objects

Device Category

Device Category

Point of Delivery

Point of Delivery

Device Location

Device Location

� The essential master data used for billing includes:

� Utility installation

� Device

� Installation structure

� These contain data for determining rates and also operand values for individual billing steps.


SAP AG 1999

Rate Type

Rate Category

Register

Device





� Off-peak rate reactive energy

� Gas consumption


� Interval meter



� Fact group for period-end billing

� Rental price (device-related)


� Additional rates

Rate Type


or in the installation facts. The rate type can also be entered in the rate category.

� The permissibility indicator in the rate type enables you to specify where the rate type can be allocated.


SAP AG 1999

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 Checks

EXIT_SAPLE20Q_004 Proposal logic

EXIT_SAPLE20Q_001 Search help rate typeEXIT_SAPLE20Q_002 Search help rate fact group

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


SAP AG 1999

RateCategoryBilling Class

OutsortingGroup

Division

Notes Backbilling/Period-End Billing

Dynamic

Period Control

Billing Schema

Advance Billing

Rate Category II

� The rate category contains data that controls the processing of billing data. This includes:

� Billing Schema

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


SAP AG 1999


� Check Functions





SAP AG 1999

� 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 out

� During 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.


SAP AG 1999

Automatic billing and simulation: Initial ScreenDisplay document Billing reversal Invoicing simulation Display print document

Status

Log

Log

Overall check

Billing types

SimulationBilling simulationBilling

-

31.12.9999

Portion

Selection criteriaContractInstallationContract acct.

Billing order selec.

Billing procedureDivisionCompany code

End of runtime

Check runtime

DateTime

31.12.999913:31:10

Overall check

XYZ0815

U100

Executing 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/back billing

- Rate determination- Billing view of installation

- Operand determination

- Simulation of period-end billing/back billing

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.


SAP AG 1999


� Check Functions





SAP AG 1999

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

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


SAP AG 1999

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

� 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 period-end billing covers

� if 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.


SAP AG 1999

Month 01

Month 02

Current

Billing

Period

Next

Billing

Period

Billing in Advance

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


SAP AG 1999

Rate Category

Rate Category

Rate Determ.Rate Determ.

Billing SchemaBilling Schema

Rate 1Step 1Step 2

Rate nStep 1

Variant Programe.g. Quantity x PriceComparison of two

demands

Rate TypeRate Type


Installation StructureInstallation Structure

RatesVariant Program

RatesVariant Program

Billing inAdvanceControl

Indicator for Billing in Advance

Data Model for Billing in Advance


SAP AG 1999

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.


SAP AG 1999

Controlling the Gross Price in the Schema

� Ensures that the billing line items contain gross prices. The tax is not

calculated.


SAP AG 1999

Price Definition Rate Data

Prices andRate FactsPrices andRate Facts

Schema

Rate Var.Prog. Values

Rate 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 price

- Step 1 VarProg. A xxx

Rate n

Price

Rate 1

Rate n

. . . . . .Generate

BillingLine Items

Check Billing

Results

Execute

Variant in

Programs

in Acc. With

Schema

Net Price

and

Gross Price

GrossGroup

GrossLine Item

X

Z

X

Z

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.


SAP AG 1999

Gross Group

Gross Line Item

Net PriceNet Price

Variant Pr. Operand Gross group Gross line item Relevant to PostingQUANTI01 BPrice ABC X BLANK

QUANTI01 NPrice ABC BLANK X

QUANTI01 KAbgabe ABC BLANK 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 DM (cent etc.) 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.


SAP AG 1999


� Check Functions





SAP AG 1999

Prices

Operands

Rates

Schemas

Rate Categories

Rate

Determinations

CUST QTSTComplete transport of all

billing master data

Transport of Billing Master Data

� All the billing master data can be transported using the report

REA_BILL_MASTER_DATA_TRANSPORT. Transporting a selection of individual billing master

data records is not possible.

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


SAP AG 1999 SAP AG SAP AG

� Data relevant to billing is specified in different master data entities.

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

� Since the rate structure is flexible, rates can modeled for both household customers and non-residential customers without further modifications.

� Billing master data can be transported from a source system/client to a target system/client using a tool.

Use of Rates in Master Data: Unit Summary


Use of Rates in Master Data: Exercises

Unit: Use of Rates in the 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.

1-1 True or false?

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

____________________________________________________________

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

____________________________________________________________

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

____________________________________________________________

1-2 Create a new rate determination for your rate (PE1_1##) from the combination

of your rate category (PE1##) and the rate type 1001.

1-2-1 Use January 1st of this year as the valid date. Test your new rate using the

billing analysis and use the data for business partner TF0501A0##.

____________________________________________________________

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

1-2-3 Which rate category is entered at installation level?

____________________________________________________________


1-2-4 Which rate type is entered on the register of the built in meter?

____________________________________________________________

1-2-5 Which rate is determined with the rate determination for billing runtime?

____________________________________________________________

1-2-6 Which billing schema is linked to the rate category?

____________________________________________________________

1-2-7 Are special price keys that differ from the rate used for this business partner?

____________________________________________________________

1-3 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.

1-3-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


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 and 3. Set a maximum price

limitation.

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

Rate steps (off-peak rate):

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


1-3-2 Maintain the facts for both rates. Supply the operands with values. Use the

existing price key.

1-3-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##

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

Header data

Rate category PE2##

Schema PE2##

1-3-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.

1-3-6 Test your rate using the data construct TF0503A0##.


Use of Rates in the Master Data: Solutions

Unit: Use of Rates in the Master Data

Topic: Rate Determination

1-1 True or false?

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

True

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

True

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

False

1-2 Create a new rate determination for your rate (PE1_1##) from the combination

of your rate category (PE1##) and the rate type 1001.

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

Adjust the data (rate category in the installation) of business partner

TF0501A0##. From the SAP menu, choose Utilities Industry �� Billing ��

Billing Execution �� Billing Analysis to test your rate.

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

1-2-3 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


1-2-4 Which rate type is entered on the register of the built in meter?

Goto �� Device - rate data

Rate type: 1001

1-2-5 Which rate is determined with the rate determination for billing runtime?

In the SAP Reference IMG , choose SAP Utilities �� Contract Billing �� Billing


Select the rate determination list.

Choose Execute.

Rate: E1_1

1-2-6 Which billing schema is linked to the rate category?


Master Data �� Rate Structure �� Rate Categories �� Define Rate Categories

�� Display Rate Categories.

Enter the rate category E1 in the initial screen.

Billing schema: E1

1-2-7 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.


Select the installation facts.

No facts are available. No special price is used.


1-3 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.

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


Master Data �� Rate Structure �� Rates �� Define Rates �� Create Rates.

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


Select Rate Steps.


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)

1-3-2 Maintain the facts for both rates. Supply the operands with values. Use the

existing price key.


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.


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

created earlier.


Master Data �� Rate Structure �� Schemas �� Define Schemas � Create

Schemas.

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

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.

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


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.

1-3-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.



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

the exercise and save.

1-3-6 Adjust the data for business partner TF0503A0## and use the billing analysis

for testing.



� Billing Process

� Data Elements of the Billing Process

� Billing Simulation

� Billing Documents

� Outsorting in Billing

� Billing Reversal

� Parallel Processing

Billing


SAP AG 1999

Billing: Unit Objectives

SAP AG 2001


� Describe billing functions

� Explain the data elements of the billing process

� Understand the billing process

� Perform a billing simulation

� Understand the concept of outsorting

� Perform billing reversal

� Describe the concept of parallel processing


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master Data


BillPrintout

Billing











� New rates must be released. These new rates are calculated in the test system with existing master data.


SAP AG 1999

Billing: 1

� Billing Process








SAP AG 1999

MO TU WE TH FR SA SU

1

8152128

2

9162229

3

10172330

4

11182431

5

121925

6

132026

7

142127

� Length of period for periodic billing

� x days; 1, 2, 3, 4, 6, or 12 months

� Length of period for period-end billing

� x + x days; 1, 2, 3, 4, 6, or 12 months

� Billing for an exact number of days

� based on the date of the meter reading

� Month-based billing

� dependent on key date

� Month-based billing

� dependent on intervals

Billing Periods

The billing period for which the utility bills the customer can be determined in a number of ways. These

are:


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.


SAP AG 1999

Billing Procedures

� Periodic Billing

� Scheduled billing occurring in fixed periods

� Interim Billing

� Unscheduled billing at any time

� Final Billing

� When the customer moves out or when the contract is terminated

� Territory-Transfer Billing

� Transfer of parts of the service territory

� Period-End Billing

� 13. 13th billing, backbilling for a year

� Manual Billing

� Possibility of making manual corrections (e.g., corrections to

invoices)

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

� Territory-transfer billing takes place if the utility company transfers parts of its service territory to

other utility companies.

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

to invoices.


SAP AG 1999

Billing Functions

� Best-Rate Billing

� The most favorable billing rule for the

customer is selected from several billing rules

� Quantity-Dependent Considerations

� The customer's actual annual consumption determines the billing

rule to be used

� Demand Billing

� The customer's actual demand determines the billing rule to be

used

� Seasonal Billing

� For example, different prices or billing rules according to season

� Floating Backbilling / n Periods

� For example, monthly comparison of any number of peak averages

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

� In best-rate billing, the most favorable rate for the customer is selected from several different rates.

� Seasonal billing. In season-based billing, variant program values can be defined according to season (for

example, different rates for winter and summer).


SAP AG 1999

Meter

Reading Order

Billing Order

InvoicingInvoicingCreation ofMeter Reading Order

Creation ofMeter Reading Order

Entry ofMeter Reading Data


BillingBilling

Billing Document

Implausible Meter Reading Results

Plausible Meter Reading

Results

Billing Order

Correction ofMeter Reading Results


Print Document

BillingPrintout

BillingPrintout

The Billing Process


SAP AG 1999

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 IS-U, 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 billing document 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.


SAP AG 1999

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


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


SAP AG 1999

Invoicing Tasks

� Standard IS-U 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


SAP AG 1999

FI-CA Documents

Budget Billing

Plans

Maintenance of

Documents

Receivables:

$100

Physical

Printout


- Validation

- Processing of

FI-CA Documents

Receivables:

$100Receivables:

100 UNI

Manual BillingPrint

Documents

Print

Documents

FI-CA

Posting

Documents

FI-CA

Posting Documents

Budget Billing

Plans

Budget Billing

Plans

SD

Documents

Invoicing

� Invoicing



budget billing)








SAP AG 1999

� Billing Process







Billing: 2


SAP AG 1999

Schedule Master Records: Portions

� Portions

� Group 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 through the meter-reading units that are

defined for the utility installation belonging 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.


SAP AG 1999

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 the required data (schedule master records) for scheduling meter reading

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


SAP AG 1999

Portion

P_AUG01

PortionP_AUG01

Meter reading unitA_AUG01

Meter reading unit

A_AUG01

P1P1

Parameter RecordParameter Record

Schedule Master Records

A_AUG01 2001A_AUG01 2001

A_AUG01 2000A_AUG01 2000

A_AUG01 1999A_AUG01 1999

Meter reading unitMeter reading unit

Schedule Records

P_AUG01 2001P_AUG01 2001

P_AUG01 2000P_AUG01 2000

P_AUG01 1999P_AUG01 1999

PortionPortion

Generationof

Schedule Records

Generationof

Schedule Records

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.


SAP AG 1999

Scheduling: Annual Billing

20002000

Portion 1

07/27 07/28 07/29 07/30 07/31 08/01 08/02 08/03

Portion 1

07/27 07/28 07/29 07/30 07/31 08/01 08/02. 08/03

20012001

Portion 1

07/27 07/28 07/29 07/30 07/31 08/01 08/02 08/03

Sched.Meter ReadingDate

Billing Period

Meter reading period for meter reading unit 1



For all meter reading units

EndofMeter ReadingPeriod

EndofBillingPer-iod

Sched. Billing Date

Meter Reading

Billing

Meter Reading

Billing

� End of the billing period: on this date the portion should be billed for the first time. This date and the

length of the billing period (period length) determine the date of the next billing.

� Scheduled billing date:

� Date on which billing of the contracts in a portion starts.

� When the schedule record is being created, the system calculates this date by subtracting the number

of days between the end of the billing period and the scheduled billing date from the date for the end

of the billing period of the schedule record.

� The SAP calendar is used.

� End of the meter-reading period: is used as the base date for determining the dates of further meter

reading periods. The date must not be later than the end of the billing period of the allocated portion.

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


SAP AG 1999

Meter Reading Order Data

Meter reading

order

Time-based data

Data environment

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

Meter reading data

Entry-specific data

• Expected meter reading• Expected consumption• Upper limit for 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. In this case,

twelve columns are printed for the demand values. You specify the control group 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.


SAP AG 1999

Billing Order

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

example)

� Is a prerequisite for billing

� Contains data for billing, such as:

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


SAP AG 1999

Billing

Order

Effect on the Billing OrderEffect on the Billing OrderActivitiesActivities

� Creation of meter-reading

order

� Entry of meter-reading results

� Billing

� Billing reversal

� Status 1 = order created

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


SAP AG 1999

Which devices did we read last week on Main 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.


SAP AG 1999

Billing: 3

� Billing Process








SAP AG 1999

Simulation

Consumption

Extrapolation

Determination of

Rate DataSimulation

Billing

Simulation

Types of Simulation Functions

Generation of

Billing Document

Simulation Functions

Determination ofMeter Reading

Results

Determination of

Billing

Period

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


SAP AG 1999

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.


SAP AG 1999

Differences Between Billing and SimulationSimulation

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.


SAP AG 1999

Billing

Documents

Billing

Documents

Mass Simulation

PortionPortion

Invoicing

Documents

Invoicing

Documents

PurposePurpose

Mass Simulation

Billing

Mass Simulation

Billing

Mass Simulation

Invoicing

Mass Simulation

Invoicing

� Simulation of rate reforms

� Model bills

� Effects of price changes

� Simulation of rate reforms

� Model bills

� Effects of price changes


SAP AG 1999

Billing: 4

� Billing Process








SAP AG 1999

Processing Level

Meter Reading

Billing

Invoicing

Bill Printout

Bill Display

Meter Reading

Billing

Invoicing

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.


SAP AG 1999

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 account

� Contract

� Installation

� Contract account

� Contract

� Installation

� Portion

� Installation interval

� Check runtime

� Log w/o success message

� Portion

� Installation interval

� Check runtime

� Log 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.


SAP AG 1999

Line Item Types Relevant to PostingLine Item Types Relevant to Posting Information Line ItemsInformation Line Items

Billing Line Item Elements

� From- and to-date

� Line item type

� 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

� Line item 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.


SAP AG 1999

Line Item Types Relevant to PostingLine Item Types Relevant to Posting Information Line ItemsInformation Line Items

Examples of 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 Compar. of two quantities

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


SAP AG 1999

Billing

Document Display

Billing

Line Items

Price Data

Rate Data

Device Data

Account Data

Internal

Billing

Data

Meter Reading

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.


SAP AG 1999

Billing: 5

� Billing Process








SAP AG 1999

� Check pool

� Selection of checks to be carried out

� Company-specific checks possible

not OK

Billing Invoicing

Check- standard- company-

specific

Bill Printout

Reversal

OK OK

Exception List or WorkflowException List or Workflow

not OK Rel-

ease

Rel-

ease

Rel-

ease


specific

Outsorting in IS-U

� 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 settlement 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.


SAP AG 1999

� 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 and/or after 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.


SAP AG 1999

BillingBilling

ChecksChecks

Billings

to be checked

ReleaseRelease

ReversalReversal InvoicingInvoicing

Automatic checksAutomatic checks Manual outsortingManual outsorting

Electricity contract

manual

outsorting: 0001

Once

Electricity contract

manual

outsorting: 0001

Once

BillingBilling

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


SAP AG 1999

Outsorting Groups:

Billing

0001 Res. customer

0002 Nonres. cust.

Outsorting Groups:

Billing

0001 Res. customer

0002 Nonres. cust.

Automatic ChecksAutomatic Checks

Rate Category(General

Definition)

Rate Category

(General

Definition)

Contract

(Individual

Overrides)

Contract

(Individual

Overrides)

Billing Procedure

01 Periodic billing

02 Interim billing

03 Final billing

04 Period-end billing

05 Territory transfer

06 Manual billing

Billing Procedure

01 Periodic billing02 Interim billing

03 Final billing

04 Period-end billing

05 Territory transfer

06 Manual billing

Billing ChecksOutsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1

Outsorting Group 0002 + Billing Procedure 01 = Check NO_LINES

Billing ChecksOutsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1

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


SAP AG 1999

Billing Checks

� AMOUNT1

Amount check on net amount

� BBP_ABS1Absolute deviation of budget billing

amount

� BBP_PERC1Percentage deviation of budget

billing amount

� ESTIMATE

Estimation

� NO_LINES

Existing billing line items

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


SAP AG 1999

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


SAP AG 1999

Billing: 6

� Billing Process








SAP AG 1999

Billingdoc.

100,-

Billingdoc.

100,-

Billingdoc.

.

.

. Reversal...

RenewedBilling

111,-

.

.

.

OutsortingOutsorting ActivitiesActivities

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 clerk 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 effect the customer, as nothing has been posted in the contract

account and a bill has not been created.


SAP AG 1999

BillingBilling Billing Document

Invoicing Document

InvoicingInvoicing

BillingOutsorting

BillingOutsorting

InvoicingOutsorting

InvoicingOutsorting

BillingReversal

BillingReversal

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


SAP AG 1999

Reversed

Billing

Document

Billing

Reversal

Billing

Reversal

Billing Order

Billing Reversal Elements

� Reversed billing document is marked accordingly

� Billing order is restored


SAP AG 1999

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


SAP AG 1999

� Billing Process







Billing: 7


SAP AG 1999

Aim: Processing times can only be shorted 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

� Partial bill creation

Parallel Processing - Situation


SAP AG 1999

Interval

Size = 3

No. of Intervals = 4

No. ofIntervals = 3

Interval

Size = 4Interval_1

Interval_2

Interval_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 - Creation of Intervals

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


SAP AG 1999

Parallel Processing - Portioning Problems

Problems

� How is the dataset to be portioned?

The dataset is not evenly distributed:

� As a rule contract account numbers or business partner

numbers are denser in certain number ranges than in others

� Contract accounts have differing numbers of items

� How many portions should be allocated to each process?The same processes and the same number of processes are not

available in each processing run:

� The performance of processes running on different servers is

different

� Performance depends on the other processes that are running

at the same time


SAP AG 1999

m

OIs

m

OIs

m

OIs...

Interval

1

Interval

4

Interval

9

Interval

3

Interval

6

Interval

2

Interval

10

Client AJob 1

Client AJob 2

... Client XJob n

Dispatcher forMass Data Program

m = block size

Parallel Processing - Realization


SAP AG 1999

Billing: Unit Summary

SAP AG

� Billing in IS-U 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.


Billing: Exercises

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 To which meter reading unit is the business partner’s installation allocated?

____________________________________________________________

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

____________________________________________________________

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.

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

____________________________________________________________

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

____________________________________________________________


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?

____________________________________________________________


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 agent checks what would be the result of a

bill with the old data.

3-1 The billing simulation should be done 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 effects 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?

____________________________________________________________


Billing: 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?


Utilities Industry →→→→ Technical Master Data →→→→ Installation →→→→ Display.


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?


Utilities Industry →→→→ Scheduling →→→→ Schedule Record →→→→ Evaluation →→→→

Schedule Record.

Select the Portion indicator and the time period January 1st 1995 to

December 31st 2010.

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.


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


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-6 Which scheduled billing date does the billing order have?

Scheduled billing date: April 2nd


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?



Manual.



Select Meter reading order.

Execute.

Scheduled meter reading date: March 30th

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



Manual.



Select Meter reading order.

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.


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.

Press Enter.

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


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

Which document number does your bill have?


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.

Execute.

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


Solutions

Unit: Billing

Topic: Simulation/Document Display

3-1 The billing simulation should be done 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?


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

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?


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.

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

Select the Int. billing data tab page.

Billing schema: E1



� Invoicing Functions

� Account Maintenance

� Due Dates

� Credit Processing

� Joint Invoicing/Integration

� Outsorting in Invoicing

� Invoice Reversal

Invoicing




� Describe the invoicing functions

� Explain how items from accounts receivable and payable are processed

� Explain how due dates are determined

� Describe credit processing

� Outline the concept of joint invoicing/integration

� Describe the outsorting concept

Invoicing: Unit Objectives


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master Data

Invoicing BillPrintout

BillPrintout

BillingBilling











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


SAP AG 1999



� Due Dates





Invoicing: 1


SAP AG 1999

Meter Reading

Order

InvoicingInvoicingCreation ofMeter Reading Order

Creation ofMeter Reading Order



BillingBilling

Billing DocumentBilling Order

Implausible Meter Reading Results

Plausible Meter Reading

Results

Billing Order



Print Document

BillingPrintout

BillingPrintout

Process of Billing/Invoicing


SAP AG 1999

� 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


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

Billing Tasks


SAP AG 1999

� Standard IS-U 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

Invoicing Tasks


SAP AG 1999

FI-CA Documents

Budget Billing

Plans

Maintenance of

Documents

Receivables:

$100

Physical

Printout


- Validation

- Processing of

FI-CA Documents

Receivables:

$100Receivables:

100 UNI

Manual BillingPrint

Documents

Print

Documents

FI-CA

Posting

Documents

FI-CA

Posting Documents

Budget Billing

Plans

Budget Billing

Plans

SD

Documents

Invoicing

� Invoicing



budget billing)








SAP AG 1999

Invoicing

Budget Billing

Settlement

Settlement

1. Budget Billing

AccountMaintenance

Credit

ProcessingDue Date

Determination

Budget Billing

Determination

Joint

Invoicing

Invoicing Functions

Cross-Company-

Code

Invoicing


SAP AG 1999

Periodic BillingPeriodic Billing

Interim BillingInterim Billing

Final BillingFinal Billing

New budget billingplan

01.01.200001.03.200001.05.200001.07.2000......

Old budget billingplan

01.01.199901.03.199901.05.199901.07.1999

......

Budget billingplan

01.01.199901.03.1999

01.05.199901.07.1999......

Old budget billingplan

01.01.199901.03.199901.05.199901.07.1999......

Billing Procedures in Invoicing

� During periodic billing, the old budget billing plan is deactivated and the invoicing process creates a

new budget billing plan for the next budget billing period.

� During interim billing, the budget billing amounts in invoicing are deactivated. The future budget

billing amounts are still valid and can be recalculated if required.

� During final billing, the old budget billing plan is deactivated. A new budget billing plan is not created

for the customer who is moving out.


SAP AG 1999

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.


SAP AG 1999

BillBill x y z

BillBill x y z

BillBill x y z

BillBill x y z

BillBillx y z

CreateBill

CreateBill

End of runtime

Log

End of runtime

Log

Parallel

Processing

Parallel

Processing

Parallel

Processing

Parallel

Processing

Parallel

Processing

Parallel

Processing

Mass Processing

CreatePartial Bill

CreatePartial Bill

Request

Budget Billings

Request

Budget Billings

� The mass 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.


SAP AG 1999

Tax rate(s) in

billing period

Tax rate at time

of invoicing

Tax

Reference Basis(alternative)

Account

Determination

Account

Determination

� Proration of billing line items if tax changes (in billing)

Tax Determination

� No proration, tax is dependent on point in time:

� System date or

� Posting date or

� Document date

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


SAP AG 1999

Items:

03/10/99 155.43

03/10/99 0.03 -

Billing

amount155.43 SFR

~ 155.40 SFR

Items:

03/10/99 940,145

03/10/99 145 -

Rounding Carried-Forward Rounding

Billing

amount940,145 ITL

940,000 ITL

One rounding per bill Rounding carried forward to next bill

Currency-Related Rounding/ Carried-Forward Rounding

� In certain countries (such as Switzerland - 5 Rappen rounding, New Zealand), posting lines are rounded

according to certain rules. Each bill is rounded once only. The rounding is displayed both on the account

and on the bill.

� Another option is to carry forward the rounding amount (for example in Italy). The posting lines are also

rounded according to certain rules. The difference is that the rounding amount is included in the next

bill.


SAP AG 1999

Additional

Functions

Additional

Functions

Event: 5010

Account

Maintenance

Event: 5010

LPC

ReceivablesEvent: 5010

Dunning

Event: 5010

Interest Calc.on Cash Security

DepositsEvent: 5010

Interest Calc.

Receivables

Event: 5010

LPC

Installment Plan

% ΣΣΣΣ exp % ΣΣΣΣ exp

Open Items:

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

Additional Functions in Invoicing

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


SAP AG 1999



� Due Dates





Invoicing: 2


SAP AG 1999

Bill 4711 Date: 01/02/00

Valuated consumption +_________

+_________

+_________

Credit memos/backbilling +/-________

Billing

amount =========

Paid budget billing amounts -__________

Main items +/-________

1. Budget billing amount +_________

Final

amount =========

Sub-items +/-________

Amount

due =========

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


SAP AG 1999

IMGIMG

...........

..........

..........

..........

Bill 4711 Date: 01/02/00


+_________

+_________


Billing

amount =========

Paid budget billing amounts -__________



Final

amount =========

Sub-items +/- 343.58

Amount

due =========

Please note that your bill of 01/04/1998

has an outstanding unpaid amount of

343.58 UNI.

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

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


SAP AG 1999

Incoming Payment

Business

Transaction

Contract

Account

Clearing Entry

SelectionRestriction

Settlement Variant

Settlement Type

Settlement Category

1-n Settlement Steps

Open Items

Settlement Control: Overview


SAP AG 1999

� In a multiple-level allocation or clearing strategy, settlement rules determine:

� Which open items in the contract account are selected for

settlement

� How items are grouped for analysis according to various

criteria

� In what order items are to be cleared

� The distribution algorithm within a group for partial clearing

Settlement Concept: 1


SAP AG 1999

� Settlement rules are determined from a combination of settlement category and settlement type.

� The settlement category refers to the contract account. It is stored in the contract account. Thus different customer groups

can have their own settlement categories:

Examples are: household, small business, public institutions,

collector

� The settlement type represents the business transaction.

� Examples are: periodic invoice, final invoice, account maintenance

� Can be controlled by user exits in invoicing.

Settlement Concept: 2


SAP AG 1999

Settlement Variant

ST1 + F1 ⇒⇒⇒⇒ VAR1

ST2 + F2 ⇒⇒⇒⇒ VAR2

ST1 + RB ⇒⇒⇒⇒ VAR1

Periodic invoicing F1

Account maint. F2

Cash desk pymt RB

Settlement Category

Settlement Type

Contract Account

Business

Transaction

Household ST1

Business ST2

Determination of Settlement Variants

� The settlement category refers to the contract account. It is stored in the contract account. Thus different

customer groups can have their own settlement categories. For example:

- Household

- Business

- Public institutions

- ...

� The settlement type represents the business transaction. For example:

- Periodic invoicing

- Final invoicing

- Account maintenance

- ...

� Especially in invoicing, you can assign settlement types according to your requirements using a user

exit. To help you make your decision, all information on the invoicing unit is available to you.


SAP AG 1999

Other Bill

1000 UNI

Settlement

Open Items900 UNI

(other bill)

Settlement Type

Settlement Category Algorithm

Grouping

Invoicing

Rec. 400 UNI Division 01

Credit -200 UNI Division 01

Credit -300 UNI Division 01

Account Maintenance in Invoicing: 1

� Invoicing in IS-U determines credits from consumption valuation.

� These are to be settled against other receivables of the contract account during the account maintenance

triggered during invoicing.


SAP AG 1999

Payment on Account

-1000 UNI

Cash Security Deposit

500 UNI

Settlement

Open Items-1200 UNI

(Credit)

Settlement Type

Settlement Category Algorithm

Grouping

Invoicing

Rec. 300 UNI

Account Maintenance in Invoicing: 2

� There is a requirement that it be possible to settle payments on account in invoicing.

� It should also be possible to settle any cash security deposits during final billing.

� If you require these functions, you must configure settlement control accordingly. Note that if the

characteristics are grouped and sorted incorrectly in settlement control, this can lead to undesired results.


SAP AG 1999

Ne

xt

Sett

lem

en

t S

tep

Ne

xt

Gro

up

Group Processing

taking the following into account:

• Sort sequenceAmount-based group rule

Dividing algorithm forpartial clearing

Customizedallocation rule

••

•

Form OI groups

(from specifications in grouping string)

Spec. for Subsequent Processing

• Tolerance handlingfor partial clearing

Specifications aboutnext settlement step

Specifications about completion of allocation

•

•

1-n SettlementSteps

. . . .

Settlement Steps

� A settlement variant contains several steps. Each individual step controls the selection, grouping, sorting,

and amount-dependent allocation of open items for clearing. The steps are carried out in the order of

their numbers.


SAP AG 1999



� Due Dates





Invoicing: 3


SAP AG 1999

Contract Account

Term of Payment:

Contract Account

Term of Payment:

0001

Due Dates

PostingDate

PostingDate

Document Date

Document Date

System DateSystem Date

Receivable/Credit

Receivable/Credit

FI-CA Terms

of Payment

FI-CA Terms

of Payment

FI Terms

of Payment:Receivable 14 Days

FI Terms

of Payment:

Receivable 14 Days

FI Termsof Payment:

Credit Immediately

FI Terms

of Payment:

Credit Immediately

Incoming PaymentsOutgoing PaymentsIncoming PaymentsOutgoing Payments

Elements for Determining Due Dates

� The terms of payment are also used by other standard components (e.g. FI, SD).

� If other payment conditions should be used for different services, several contract accounts have to be

created.

� Terms of payment can depend on the following data:

� Posting date

� Document date

� System date


SAP AG 1999

Open Items:

Clearing

03/08/98 150.00 150.00

03/10/98 70.00 50.00

03/19/98 200.00 -

03/22/98 123.00 - 123.00 -

Difference:

77.00

Bill 4711 Date: 07/01/98


+_________

+_________


Billing

amount =========

Open items on 06/15/98 +/-________

Amount due =========

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.


SAP AG 1999



� Due Dates





Invoicing: 4


SAP AG 1999

Contract Account

Outgoing Payment

MethodsP Postal transfer

C Check

Contract Account

Outgoing Payment

MethodsP Postal transfer

C Check

Posting Area

R401P Priority 1

S Priority 2U Priority 3

Posting Area

R401P Priority 1

S Priority 2U Priority 3

Determination of

Outgoing PaymentMethods

Determination of

Outgoing PaymentMethods

Amount LimitCheck

Amount LimitCheck

Checks for

OutgoingPayment Blocks

Checks for

OutgoingPayment Blocks

User ExitEvent R430

User ExitEvent R430

Determination of Outgoing Payment Methods

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


SAP AG 1999



� Due Dates





Invoicing: 5


SAP AG 1999

Electricity

Contract

Joint

Invoice: 1

Electricity

Contract

Joint

Invoice: 1

Gas Contract

Joint

Invoice: 1

Gas Contract

Joint

Invoice: 1

Water Contract

Joint

Invoice: 1

Water Contract

Joint

Invoice: 1

Cable TV

Contract

Joint

Invoice: 2

Cable TV

Contract

Joint

Invoice: 2

Electricity Installation

Meter Reading Unit:

T0001

Electricity

Installation

Meter Reading Unit:

T0001

Gas Installation

Meter Reading Unit:

T0001

Gas Installation

Meter Reading Unit:

T0001

Water Installation

Meter Reading Unit:

T0002

Water Installation

Meter Reading Unit:

T0002

Cable TVInstallation

Meter Reading Unit:

K0001

Cable TV

Installation

Meter Reading Unit:

K0001

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


SAP AG 1999

Contract 1mandatoryjoint invoice






Contractoptional

joint invoice

Contractoptional

joint invoice

Document

Optional

Document

Optional

Document 3

Mandatory

Document 3

Mandatory

Document 1

Mandatory

Document 1

Mandatory

Document

Optional

Document

Optional

Billing

Contractexclusive invoice


Document

Exclusive

Document

ExclusiveDocument

exclusive

Document

exclusive

InvoicingContract Account

Bill

Bill

Event: R403

Joint Invoicing: Example 1

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


SAP AG 1999







Contractoptional

joint invoice

Contractoptional

joint invoice

Document

Optional

Document

Optional

Document 3

Mandatory

Document 3

Mandatory

Document 1

Mandatory

Document 1

Mandatory

DocumentDocument

Billing



Document

Exclusive

Document

ExclusiveDocument

Exclusive

Document

Exclusive

InvoicingContract Account

Bill

Bill

Document 2Mandatory

Document 2Mandatory

Event: R403

Joint Invoicing: Example 2

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


SAP AG 1999

Cons. billing#1Electricity 1000 UNI

Gas 1500 UNIWater 600 UNI

Other Services #3

Cable TV 180 UNI

Misc. Services #2

Waste water 500 UNIWaste disposal 200 UNI

Total Bill #4711:

Bill (#1-#3) 3980 UNI

- paid BBAmt(#1-#3) -3600 UNI

Amount due: 380 UNI

Due on 01/15/96

Smith Account (xy)

Re. #4711 380 UNI

Line items perreceivable:

Bill #1 (xy) ...Bill #2 (zz) ...

Bill #3 (rs) ...

G/Ledger 0002loc. auth. "zz"

G/Ledger 0001Utility Co. xy

G/Ledger 0003(n/a to balance sheet)TV Co. "rs"

Rec. ElectricityRec. GasRec. Water

Rec. waste waterRec. waste disposal

Rec. cable TV

Contracts

for "xy" CoCd 0001

Contracts

for "zz"CoCd 0002

Contracts

for "zz"CoCd 0003

FI-CA

Total Bill #4711

Municipal Services xy:

Cross co.cde billg f. loc.auth.zz:

Cross co.cde billg f. TV Co.rs:

Intercompany

invoicing

Convergent

billing

ISIS--UU FIFI

Intercompany Invoicing

� You can allocate different company codes within a contract account.

� Revenues are kept in the general ledger in different company codes. The customer is billed for all

services.


SAP AG 1999

Invoicing of Different Services

Joint Billing #4711:

Bill (#1-#5) 4375 UNI

- Paid BB (#1-#3) -3600 UNI

Remainder due: 775 UNI

Due on 01/15/96

Simplifiedrepresentation

without tax!

JointJoint

InvoicingInvoicing

-- AccountAccount

-- Due DatesDue Dates

-- OptionalOptional

Account A. Smith

Bill #4711 775 UNI

Line items perreceivable:

Bill #1 ...Bill #2 ...................

Sale #5

Radiators 350 UNI

Maint. Charge #4

Gas heating 45 UNI

Other Services #3

Cable TV 180 UNI

Other Services #2

Waste water 500 UNI

Waste disposal 200 UNI

Cons. Billing #1

Electricity 1000 UNI

Gas 1500 UNI

Water 600 UNI

� You can also include additional services in invoicing in IS-U.


SAP AG 1999

SD

Billing Doc.

SD

Billing Doc.

IS-U

Billing

IS-UBilling

IS-U

InvoicingBilling DocumentsBilling Documents

SD Sales

PM-SMA

Installation Services

IS-U

Utility

Services

Incorporation of Additional Documents

Billing Request

Optional

� 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 IS-U billing.

� It is possible to incorporate SD billing requests (side business, maintenance etc.) in IS-U invoicing and

to integrate these with the IS-U bill.


SAP AG 1999

IS-CA

FI-ARFI-AR

SDBilling

Doc.

IS-UBilling

IS-UInvoice

FI CustomerFI Customer

Contract Account

Billing Request

Acco

unt G

roup

Document Type

PosAr R400

Document Type

PosAr 1210

⇓⇓⇓⇓

SD Billing

Category

'U'

Integration of SD Billing Documents

SD

Bill

ing T

ype

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


SAP AG 1999



� Due Dates





Invoicing: 6


SAP AG 1999

� Check pool

� Selection of checks to be carried out

� Company-specific checks possible

not OK

Billing Invoicing


specific

Bill Printout

Reversal

OK OK

Exception List or WorkflowException List or Workflow

not OK Rel-

ease

Rel-

ease

Rel-

ease


specific

Outsorting in IS-U

� 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 settlement takes place during invoicing (budget billing

payments, payments on account, cash security deposits).

� The customer can create his/her own outsorting checks and include them in the billing or invoicing

program without modification.



SAP AG 1999

� 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


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


SAP AG 1999

Control

Document

Control

Document

Control

Document

Control

Document

InvoicingInvoicing

ChecksChecks

Invoices

to be checked

ReleaseRelease

ReversalReversal BillingPrintout

BillingPrintout

Automatic ChecksAutomatic Checks Manual OutsortingManual Outsorting

Contract Account

Manual

Outsorting: 0001

Once

Contract Account

Manual

Outsorting: 0001Once

InvoicingInvoicing

Invoices

to be checked

ReleaseRelease

ReversalReversal BillingPrintout

BillingPrintout

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.


SAP AG 1999

Outsorting Groups:

Invoicing

0001 Res. customer

0002 Nonres. cust.

Outsorting Groups:

Invoicing

0001 Res. customer

0002 Nonres. cust.

Automatic ChecksAutomatic Checks

Contract Account

(individual

setting)

Contract Account

(individual

setting)

Invoicing ChecksOutsorting Group 0001 = Check AMOUNT2

Outsorting Group 0002 = Check AMOUNT3

Invoicing ChecksOutsorting Group 0001 = Check AMOUNT2

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


SAP AG 1999

� AMOUNT2Gross billing amount checked

against minimum and maximum limitations

� AMOUNT3Sum total checked against minimum and maximum limitations

� FORWARD1Balance forward checked

against maximum amount for credit memo/ receivable

Invoicing Checks

� The customer can also create additional outsourcing checks. The check programs are small ABAP/4

function modules.


SAP AG 1999

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

Customizing Functions: Invoicing


SAP AG 1999



� Due Dates





Invoicing: 7


SAP AG 1999

Invoicing Reversal

or TotalReversal

MarkOpen Posting

Document

Create

Reversal Document

Mark

Open Billing

Document

Invoice Reversal Billing Reversal

Create

Billing Order

Invoicing Reversal Functions

OpenOld Budget Billing

Plan

Delete

New Budget Billing

Plan

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


SAP AG 1999

-1000,-

.

.

.

ReversalBill

100,-

.

.

.

Bill

Bill

1000,-

.

.

.

Action e.g., change

meter reading result

and redo billing/

invoicing

Action e.g., change

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


SAP AG 1999

Invoicing

Document

Full bill is not to be reversedFull bill is not to be reversed

BillingDocuments

BillingDocuments

Reversal

of a singlebilling

document

Reversal

of a singlebilling

document

Billing Reversal/Adjustment Reversal

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


SAP AG 1999

Adjustment ReversalAdjustment Reversal

RebillingRebilling

Changesto the

Dataset

Changesto the

Dataset

Bill 4711 Date: 01/02/99

Correction Bill

Source Document - 50

- 70

New Document

40

60

-------

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.


SAP AG 1999

Selection of 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 Workflow Workflow WS 20500045

ISUBIMRCOR02

Workflow WS 20500045

ISUBIMRCOR02Workflow

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


SAP AG 1999


ISU_ASSESS


ISU_ASSESS

Search for billing documents to be reversed

Adjustment reversal of billing document

New estimation of incorrect MR results

Steps in the Workflow

Workflowstarts

Overestimation of meter reading

results

19991999

02/13 03/16 04/1501/14

Meter Reading:

500

read

800

estimated

750

read

1. Reversal of billing document of Feb. 13

2. New estimation of incorrect MR

results from 800 to 625

Workflow Assessing - 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.


SAP AG 1999 SAP AG

� Invoicing links IS-U to the Contract Accounts

Receivable and Payable (FI-CA) component

� All billing documents of a contract account can be

grouped together in one bill

� The invoicing process processes settlement of items of the contract account

� Extensive outsorting options are available

� Invoicing can be completely reversed by a clerk

� Invoicing and billing can be reversed fully

Invoicing: Unit Summary


Invoicing Exercises

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 Check the definition of invoicing outsorting in the Implementation Guide.

1-2-1 Which menu path would you use to define outsourcing in invoicing?

____________________________________________________________

1-2-2 Which outsourcing is maintained for residential customers in the system?

____________________________________________________________


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


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

____________________________________________________________


Invoicing: 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.

In Level of processing, select Display bill. Choose the selection criterion

Contract and enter the contract TF0701A0## and a reconciliation key.

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 →→→→ Invoice

Processing →→→→ Display Print Document.

Enter the invoice document number.

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

Execute.

1-2 Check the definition of invoicing outsorting in the Implementation Guide.

1-2-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-2-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.


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


2-1-2 Use the print document display function.


Processing →→→→ Display Print Document. Enter the invoice 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##.


Processing →→→→ Individual Processing →→→→ Full Reversal.

Select the reconciliation key TF0703A0##.

Select the business partner’s document number TF0703A0##.

Execute.

Also select the billing document for reversal

Press Enter to carry out the complete reversal of the invoicing and billing

documents.


2-1-4 Which options are available for carrying out this procedure? List the menu

paths.


Processing →→→→ Individual Processing →→→→ Full Reversal.


Processing →→→→ Mass Processing →→→→ Full Reversal.

Two steps for the individual reversal of billing and invoicing.


Processing →→→→ 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: 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.


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


In Level of processing, select Display bill. Choose the selection criterion

Contract and enter the contract TF0703A0## and a reconciliation key.

Execute.

You will find the document numbers in the log following billing/invoicing.



� Budget Billing

� Budget Billing Functions

� Budget Billing Cycles

� Budget Billing Plan

� Budget Billing Due Dates

� Budget Billing Procedure

� Budget Billing Printout

� Budget Billing Settlement

Budget Billing


SAP AG 1999

Budget Billing: Unit Objectives

SAP AG 2001


� Describe the budget billing functions

� Create a budget billing plan and change budget billing amounts

� Describe the different budget billing procedures

� Outline the budget billing printout process

� Describe the budget billing settlement process


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master Data


BillPrintout

BillingBilling

Budget BillingBudget Billing










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


SAP AG 1999

Budget Billing: 1

� Budget Billing









SAP AG 1999

Budget

Billing

Budget Billing

Plan

Budget Billing

Cycle

Budget Billing

Adjustment

Budget Billing

Printout

Budget Billing

Settlement

Different

Budget Billing

Procedures

Budget Billing Functions

� The parameters needed for budget billing are defined in the portion.

� There are a range of budget billing procedures to choose from, which cover the different demands of

North America and Europe.


SAP AG 1999

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 = Billing Period Length

� 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, start of period 08/01/97

Budget billing cycle 01/number of budget billings 11 => 1st budget billing 08/30/99 2nd

budget billing 09/30/99

etc...

11. Budget billing 06/30/00

Budget billing cycle 01/Number of budget billings 12 => 1st budget billing 08/30/99

etc.

12th budget billing 07/30/00

� If no combination is entered, no budget billings are collected.


SAP AG 1999

Portion

Cycle: 12/01Cycle: 6/02Default: 01

Portion

Cycle: 12/01Cycle: 6/02Default: 01

Budget Billing

Plan

Cycle: 02

Budget Billing

Plan

Cycle: 02

Scheduling:Definition of the maximum

options and thedefault budget billing cycle

Contract

Cycle: 02

Contract

Cycle: 02

Contract:Individual overrides

of the default budget billing cyclefor generating the next budget billing

plan

Budget Billing Plan:Overriding the default

budget billing cycles immediatelyaffects the budget billing amount due

dates

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


SAP AG 1999

Forms the basis for defining budget billing plans and manages all the budget billings for a billing period of a contract

Budget Billing Plan: 1

� Determines the budget billing amount and the due dates for the

amounts

� Can be created, changed, or adjusted manually or automatically.Example: individual processing in move-in; automatic creation in

invoicing

� Header data (such as start and end of a budget billing period,

document number)

� Due dates valid for all the contracts in the budget billing plan

(proposal from scheduling)

� Accumulated budget billing amounts and accumulated open budget

billing amounts (total for all the contracts in a budget billing plan)

� Budget billing amounts and open budget billing amounts from the

active contract


SAP AG 1999

Sources for Budget Billing Calculation

Manual

Specification

Quantity-Based

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 plans due.

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


SAP AG 1999

20002000

11/01 .... .... .... .... .... .... 08/01

Billing period20012001

09/01 .... .... .... .... .... .... 14/01

Budget billing period

Actual

meter reading

Extrapolation of consumption using

configured weighting procedure; Billing simulation for this period

Next scheduled

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

� When billing, schedule records must already be generated for the next billing period.


SAP AG 1999

Cycle: 02Print Date/Debit Entry Date:01/31/199903/31/199905/31/199907/31/199909/30/199911/30/1999

Cycle: 02Print Date/Debit Entry Date:01/31/199903/31/199905/31/199907/31/199909/30/199911/30/1999

Scheduling:

Definition of the Print Datesfor all Budget Billing Cycles

The due dates for the

budget billing plan are determined using the

terms of payment from thecontract account.

Schedule Record Portion

Cycle: 01Print Date/Debit Entry Date:01/31/199902/28/199903/31/199904/30/199905/31/199906/30/199907/31/199908/31/199909/30/199910/31/199911/30/199912/31/1999

Cycle: 01Print Date/Debit Entry Date:01/31/199902/28/199903/31/199904/30/199905/31/199906/30/199907/31/199908/31/199909/30/199910/31/199911/30/199912/31/1999

Schedule Record Portion

Budget Billing

PlanDefault Cycle: 02

02/15/199904/15/199906/15/199908/15/199910/15/199912/15/1999

Budget Billing

Plan

Default Cycle: 0202/15/199904/15/199906/15/199908/15/199910/15/199912/15/1999

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.


SAP AG 1999

Water Contract

Joint

Invoice: 2

2. Budget Billing Plan

03/15/99 70 UNI04/15/99 70 UNI05/15/99 70 UNI06/15/99 70 UNI....

Electricity

Contract Joint

Invoice: 1

Gas Contract

Joint

Invoice: 1

1. Budget Billing Plan

03/15/99 150 UNI04/15/99 150 UNI05/15/99 150 UNI06/15/99 150 UNI....

Sub-Budget Billing Plan

03/15/99 50 UNI04/15/99 50 UNI05/15/99 50 UNI06/15/99 50 UNI....

Sub-Budget Billing Plan

03/15/99 100 UNI04/15/99 100 UNI05/15/99 100 UNI06/15/99 100 UNI....

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


SAP AG 1999

04/01 100

07/01 100

10/01 100

01/01 100

Budget Billing Plan fromInvoicing (*):

Budget Billing Plan after Activation of Advance Payment

04/01 100

07/01 100

07/01 100

10/01 100

01/01 100

X

X

L

Advance Payment

Activated on

May 1st, 1999

Advance Payment

Activated on

May 1st, 1999

NewNew

NewNew

Jan. - March

April - June

July - Sep.

Oct. - Dec.

Jan. - March

Consumption/Advance PaymentConsumption/Advance Payment

Jan. - March

April - June

July - Sep.

Oct. - Dec.

(*) Billing Period 1/2 - 01/014 Budget Billings/Year

(*) Billing Period 1/2 - 01/01

4 Budget Billings/Year

Agenda: X = Advance paymentL = Last due date for an advance payment

If necessary, a new budget billing due date at the end of the budget billing periodis created

Budget Billing Advance Payment

� You can define a budget billing plan as an advance payment plan (for example, for customers who do

not pay on time) by adding a due date to the budget billing plan. All subsequent due dates represent an

advance payment 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 settled

when the bill is created for the current billing period.

� If a budget billing plan is defined as an advance payment plan at the time of invoicing, the new budget

billing plan is created as an advance payment plan.

� The advance payment plan can also be deactivated.


SAP AG 1999

Automatic Manual

Percentage- Increase

- Decrease- Percentage

Extrapolation

AccumulatedBudget

Billings

Message

to theCustomer

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 accumulated budget billing amount.

� 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

� A letter can be sent out automatically to inform the customer of the budget billing adjustment.


SAP AG 1999

OpenBillings

Open

Billings

OpenInvoices

Open

Invoices

List/Budget Billing

PlanExtension

List/

Budget Billing Plan

Extension

Budget Billing Requests11/15/98 150 UNI12/15/98 150 UNI01/15/99 150 UNI02/15/99 150 UNI03/15/99 150 UNI04/15/99 150 UNI05/15/99 150 UNI06/15/99 150 UNI07/15/99 150 UNI08/15/99 150 UNI09/15/99 150 UNI

10/15/99 150 UNI11/15/99 150 UNI

New Due Dates

Budget Billing Plan Extension

� 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 displays a list of billings and invoices that are still open.

� You can also extend the existing budget billing plan, that is, add new budget billing due dates to the

budget billing plan.


SAP AG 1999

Budget Billing: 2

� Budget Billing









SAP AG 1999

� Statistical Budget Billing

� Debit Entry Procedure (Partial Bill

Procedure)

� AMB - Average Monthly Billing

� BBP - Budget Billing Plan

� Statistical Budget Billing

� Debit Entry Procedure (Partial Bill

Procedure)

� AMB - Average Monthly Billing

� BBP - Budget Billing Plan

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.


SAP AG 1999

Budget Billing Plan

Due Date Amount

11/15/98 150 UNI12/15/98 150 UNI01/15/99 150 UNI02/15/99 150 UNI03/15/99 150 UNI04/15/99 150 UNI05/15/99 150 UNI06/15/99 150 UNI07/15/99 150 UNI08/15/99 150 UNI09/15/99 150 UNI

Account Balance Display

11/15/1998 15012/15/1998 15001/15/1999 15002/15/1999 15003/15/1999 15004/15/1999 15005/15/1999 15006/15/1999 15007/15/1999 15008/15/1999 15009/15/1999 150

1. Request Budget

Billings2. Print Report

1. Request Budget

Billings

2. Print ReportBudget Billing

Requisition

Statistical Items

PaymentGenerates real items and VAT posting(actual taxation)

Reposts paid amounts

Inv-

oice

Statistical Budget Billing

� The budget billing due dates are managed in a budget billing plan.

� The budget billings can be displayed as a 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 billings can be printed for each due date, for example. To do so, first start the budget billing

request report. This report creates the print documents on which the print report is based. You then

execute the print report, which creates the actual budget billing bills.

� When a payment is received, the budget billing amounts are actually posted along with VAT (actual

taxation procedure).

� When an invoice is created, the budget billing plan is deactivated and the paid amounts are reposted.


SAP AG 1999

Budget Billing Plan

Due Date Amount

11/15/98 150 UNI12/15/98 150 UNI01/15/99 150 UNI02/15/99 150 UNI03/15/99 150 UNI04/15/99 150 UNI05/15/99 150 UNI06/15/99 150 UNI07/15/99 150 UNI08/15/99 150 UNI09/15/99 150 UNI

1. Create Partial Bill

2. Print Report

1. Create Partial Bill2. Print Report Budget

Billing

Bill

Account Balance Display

11/15/1998 150

Actual Items

PaymentOnly clears the items. VAT already posted planned taxation)

Budget billings are not reposted

Create Partial BillCreate Partial Bill

Invoicing

Debit Entry Procedure (Partial Bill Procedure)

� The budget billing due dates are managed in a budget billing plan.

� The budget billings cannot be displayed immediately (for example, after the budget billing plan has been

created) in the account balance display. In the debit entry procedure, the budget billing plan is managed

in a 'shadow table', which is not used by FI-CA.

� No items are posted in FI-CA (debit entry) until the Create Partial Bill report has been started. This is a

real posting with value-added tax. This report must be scheduled periodically, even if you do not want to

print any partial bills. The report also creates print documents, which form the basis of a partial bill

printout.

� The budget billings can be printed for each due date, for example. To do so, you must execute the print

report that creates the actual partial bills after you have executed the Create Partial Bill report.

� When a payment is received, the open items are only cleared. No changes are made to the VAT posting.

The VAT has already been posted (planned taxation procedure).

� When an invoice is created, the budget billing plan is deactivated. However, budget billings are not

reposted.


SAP AG 1999

� 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 plan procedures to level their monthly payments to the utility company.

� In the AMB procedure, the amount to be paid monthly is a

calculated average amount. In the BBP procedure, the customer pays the same amount for all 12 months.

� The difference between the billing amount and the

AMB/BBP amount is updated in a separate item (balance forward).

AMB/BBP Payment Plan Procedure


SAP AG 1999

AMB Amount

Historical

Billing Documents

Initial Average

Amount

End of Period:Settlement of Remaining Amount

Date Billing

Amount

AMB

Amount

Balance

Forward

01/20/1999

02/19/1999

03/21/1999

04/20/1999

.

.

.

100

110

85

80

.

.

.

92

95

93

91

.

.

.

8

23

15

4

.

.

.

AMB Procedure

� In the AMB procedure, the customer pays an average amount every month, which is calculated from the

last n bills (usually 12 bills).

� The AMB amount, therefore, changes from month to month.

� At the end of the period, the balance forward is almost 0. 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.


SAP AG 1999

BBP Amounts

Average

Amount per Month

Period End:Settlement of Remaining Amount

Date Billing

Amount

BBP

Amount

Balance

Forward

01/20/1999

02/19/1999

03/21/1999

04/20/1999

.

.

.

100

110

60

100

.

.

.

80

80

80

80

.

.

.

20

50

30

50

.

.

.

Historical

Billing Documents

BBP Procedure

� In the BBP procedure, the customer pays the same amount every month, which is calculated from the

last n bills.

� In the BBP procedure, the remaining amount to be paid at the end of the period is greater than the

amount in the AMB procedure.

� 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 the BBP procedure, the BBP amounts are managed in a budget billing plan. These amounts, however,

are not displayed in the account balance display, but in a shadow table. This table is also used for debit

entry in budget billing.


SAP AG 1999

Creation

Change Contract

Contract Edit Goto Additional System Help

Contract TF0415A001

Payment Plan

Paym. Plan Cat. 0001

Start Month 1 Diff. Start Month 3

Contract Period Amount Currency

Historical

Billing Documents

Manual History

Change in the Contract

Initializing the Payment Plan Procedure

� The payment plan procedures (AMB/BBP) are controlled via the Payment Plan Category, Start Month,

and Different Start Month in the contract.

� These fields can be maintained manually in the contract. You can also enter this data using the

transaction for creating a payment plan.

� Above all, the payment plan category determines which payment plan procedure is used. The payment

plan category is defined in Customizing.

� The payment plan is created during invoicing, when the start month is reached.

� Changes to the contract fields are processed during the next invoicing procedure. This means, for

example, that the start month must be deleted in the contract if the customer no longer wants a payment

plan. During the next invoicing procedure, the balance forward is settled and the customer must pay the

remaining amount.


SAP AG 1999

Budget Billing: 3

� Budget Billing









SAP AG 1999

Print

Document

with Printed

Lines

SAP Spool

Print ReportPrint Report

Request Budget Billings

Request

Budget BillingsCreate

Partial Bill

CreatePartial Bill

Customizing

Form

Customizing

Form

Contract

Account

Form

Contract

Account

Form

Alternative

Alternative

Raw Data

Interface

Budget Billing/Partial Bill Printout Procedure

� With the statistical budget billing procedure, you must create the relevant print documents using the

Request Budget Billings report.

� With the debit entry/partial billing procedure, you create the relevant print documents using the Create

Partial Bills report. This report also carries out the debit entry for documents in FI-CA.

� The print documents created can be processed using the print report. The print report creates the actual

bills.


SAP AG 1999

Print Budget

Billings per Due Date

Print all Budget

Billings with Bill

Budget Billing Bill 4711Date: 01/02/99

Budget Billing Electricity 100 UNI

Budget Billing Gas 70 UNI

Budget Billing Water 30 UNI

-----------

Subtotal 200 UNI

VAT 15% 30 UNI

-----------

Final Amount 230 UNI

The budget amount of 230 UNI isdue on 01/15/99.

Budget Billing Form

� You have several options when printing budget billings. You can specify the appropriate settings in a

Customizing table.


SAP AG 1999

Budget Billing: 4

� Budget Billing









SAP AG 1999

Bill 4711 Date: 01/02/99


+_________

+_________


Billing

amount =========

Payed Budget Billings -1,278 UNI



Final

amount =========

Sub-items +/-________

Amount

due =========

Budget Billing Settlement of Paid Amounts

� Paid budget billing amounts are

automatically included and posted (only for statistical budget

billing)

� Settlement of budget billing payments is dependent on the

billing transaction and period

� In a move-out with final billing, all

of the budget billing payments are

taken into account.

� In interim billing, only budget

billing payments for the billed

period are considered.

� Budget billing plans are deactivated

� The budget billing settlement of paid budget billings in invoicing cannot be set and takes place

automatically.

� Paid budget billing amounts, however, are only reposted with statistical budget billing. No postings are

made in the debit entry procedure.


SAP AG 1999

...............

...............

IMG

Contract A/R & A/P

1. Budget Billing

100 UNI

Settlement

Remaining Budget Billing Amount

40 UNI

Invoicing

Credit

-60 UNI

Settlement

Control

Example: Remaining Credit

Settlement Control

Settlement Against First or Next Budget Billing Amount: 1

� Using settlement control, you can settle a remaining credit amount from the invoice against the first or

next budget billing amount.


SAP AG 1999

...............

...............

IMG

Utilities Industry

1. Budget Billing Amount

100 UNI 02/01/99

No Settlement

Same Due Date

Bill 120 UNI

Budget Billing Amount 100 UNI

02/01/1999

Invoicing

Receivable

120 UNI 01/15/99

Grouping of Due

Dates

Example: Outstanding Receivable

Invoicing

Settlement Against First or Next Budget Billing Amount: 2

� In the event of an outstanding receivable from invoicing, you can group the due dates of the bill with the

first and next budget billings. You make these settings in the IMG for invoicing, and not in settlement

control. Settlement control cannot be used in this case, since nothing can be settled.


SAP AG 1999

Customizing for Budget Billing


� Payment Plan Categories (North America)

� Control Parameters for Budget Billing Amount

� Minimum Amount/Budget Billing Amount Limits

� Rounding Parameters for Budget Billing Plan

� General Amount Adjustment Factor

� Budget Billing Form ...............

...............

IMG

...............

...............


SAP AG 1999

Budget Billing: Unit Summary

SAP AG

� Budget billing management in the IS-U system can

support all known budget billing procedures.

� Integration with the IS-U print workbench allows you

to create budget billing requests and partial bills.

� The system is based on settlement control that can

be set in Customizing.


Budget Billing: 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 TF0801A0## has put in the following request.

1-1-1 Adjust the budget billing plan accordingly. Use the following information:

Business partner TF0801A0##

New budget billing amount 200 UNI

1-1-2 Determine the header data of the budget billing plan. Was the budget billing

plan created manually or by invoicing?

____________________________________________________________

1-1-3 How much will the tax be on the next budget billing amount?

____________________________________________________________

1-1-4 From which billing portion are the original due dates and budget billing cycles

generated?

____________________________________________________________


1-2 Execute a debit entry procedure for the business partner.

1-2-1 The statistical budget billing procedure (German course) 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

TF0801A0##. Use the following information:


Selection date April 30th

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-2-3 A debit entry procedure makes use of the debit entry report ("Enter partial

bill"). 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 budget

billing request report for business partner TF0801A0##. Use the following

information:


Document date April 30th (plus year of the current budget billing plan)

Posting date April 30th (plus year of the current budget billing plan)

Selection date April 30th

(plus year of the current budget billing plan)

1-2-4 The debit entry report creates a print report. 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.

1-3 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-3-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 UNI) for the last month in the manual history of contract

TF0803A0##.


1-3-2 Call the payment plan simulation as follows:

Initial data

Contract TF08030A##

Payment plan category 0001 BBP

Start month Next month

Different start month Next month

Save the payment plan the system has proposed.

1-3-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-3-4 Check the balance forward using the account balance display.


Budget Billing: Solutions

Unit: Budget Billing

Topic: Budget Billing Plan

1-1 Business partner TF0801A0## has put in the following request.

1-1-1 Adjust the budget billing plan accordingly. Use the following information:


New budget billing amount 200 UNI

From the SAP menu, choose: Utilities Industry →→→→ Invoicing →→→→ Budget

Billing Plan →→→→ Change

Select the budget billing plan of business partner TF0801A0##.

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.

1-1-3 How much will the tax be on the next budget billing amount?

Select a line. Choose Composition of BB amount/contract.

You can find the information you need in the next dialog box.

1-1-4 From which billing portion are the original due dates and budget billing cycles

generated?

Select Scheduling.

Portion: T-A-00


1-2 Execute a debit entry procedure for the business partner.

1-2-1 The statistical budget billing procedure (German course) 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

TF0801A0##. Use the following information:


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 30th

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

1-2-3 A debit entry procedure makes use of the debit entry report ("Enter partial

bill"). 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 budget

billing request report for business partner TF0801A0##. Use the following

information:


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 30th, was changed to the system date.

1-2-4 The debit entry report creates a print report. 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.




1-3 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-3-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 UNI) for the last month in the manual history of contract

TF0803A0##.

From the SAP menu, choose: Utilities Industry →→→→ Invoicing →→→→ Payment

Plan →→→→ Manual History.

Choose Create. Enter the amount from last month and choose UNI as your

currency. Save.

1-3-2 Call the payment plan simulation as follows:

Utilities Industry →→→→ Invoicing →→→→ Payment Plan →→→→ Create

Enter your data as specified in the exercise. Save the payment plan the system

has proposed.

1-3-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


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.

Execute.

Repeat the individual bill for the month after next.

1-3-4 Check the balance forward using the account balance display.





� Bill Printout Functions

� Print Action Records

� Raw Data Interface, Optical Archiving

Bill Printout


SAP AG 1999

Bill Printout: Unit Objectives

SAP AG 2000


� 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


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master Data


BillingBilling

Budget BillingBudget BillingBudget Billing










� The scenario in this unit deals with the bill printout.


SAP AG 1999




Bill Printout: 1


SAP AG 1999

SAPscript Form

- Layout

- Paragraphs- Character strings

- Windows

- Page windows

SAPscript Form

- Layout

- Paragraphs

- Character strings

- Windows

- Page windows

IS-U Print

Workbench Form

IS-U Print

Workbench Form

Customer

Account

Contract

Installation

...

...Generated

Print Program-represents the formstructure

-can be changed/extended byusers-customer exits

Generated

Print Program-represents the formstructure

-can be changed/extended byusers

-customer exits

Form Hierarchy

SAP Standard Text

- Free texts

- Fields

SAP Standard Text

- Free texts

- Fields

� A SAPscript form is allocated to the IS-U application 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 IS-U application form is used to generate an executable print program, which is called from the

application.


SAP AG 1999

IS_U_BI_BILLIS_U_BI_BILL

DOC_HEADERDOC_HEADER

DOC_ITEMDOC_ITEM

CONT_ACCTCONT_ACCT

CONTRACTCONTRACT

Text for

DOC_HEADER

Text for

DOC_HEADER

Text for

DOC_ITEM

Text for

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


SAP AG 1999

Billing Form

Bill 4711 Date: 01/02/99

Group Service Device Tax code Net amount

0001 Energy price G1 A1 123.45



Subtotal value-added tax 93.80

0002 Provisioning G1 A1 203.55



Subtotal value added tax 152.77

---------- ----------

Invoiced amount 1643.75 246.57

The bill sum total of 1890.32 UNI is due on 01/15/1999.

The next budget billing amounts are due onthe following dates:1.2., 1.3., 1.4., 1.5., 1.6., 1.7.,Please pay a budget billing amount of 50 UNI by each of these dates

Sort Order of Billin

g

Line Items?????Sort O

rder of Billing

Line Items?????

� The billing form can be laid out 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.


SAP AG 1999


Print

Document

with Printed

Lines

Raw Data

Interface

SAP Spool

Bill Printout Process

� The print documents created in invoicing are then processed using a print report. The output of the print

report are the printed bills.


SAP AG 1999

NavigationShipping Control-->Shipping type

Shipping Control 0001

Shipping Types

12EMAILPRINTER

11

**33

No.Trnsm.mthdPrintoutsRDIArch.mod.Copy

Shipping Control BP

Shipping Control alt.BTPShipping Control alt.DR

Contract Account


FAX

Printer E-Mail R-MailFax

Communication Type

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.


SAP AG 1999


Basic Settings: Financial Accounting

Correspondence

Attached Payment Medium

Country

FORM ID

CountryFORM ID

Function Module

for Formatting

the Payment

Medium

Function Module

for Formattingthe Payment

Medium

Company Code

FORM ID

Company Code

FORM IDSAPscript

Form

SAPscript

Form

FIFI

Posting AreaR401

CoCd FORM ID

Posting AreaR401

CoCd FORM ID1200,-

Payment MediumOne thousand two hundred

Walldorf, 12/29/94

Bill

Payment Medium

IMG

� You configure Customizing for the payment medium in the Financial Accounting component (FI). You

can find the relevant activities by choosing Financial Accounting Global Settings � Correspondence �

Attached Payment Media.

� You can define one FORM ID per country/state. You also specify a function module that formats the

payment medium for a specific country (for example for Germany =

PAYMENT_MEDIUM_DE_BANKTRANSFER).

� In another activity, you have to specify a SAPscript form for a company code and FORM ID. This

SAPscript form is used to print the attached payment medium.

� For IS-U invoicing, you must allocate the FORM ID to the company code in the R401 posting area.

Invoicing puts the FORM ID in the documents when the following conditions are met:

� A FORM ID is defined in the relevant company code

� The contract account being invoiced is a cash payer

� An outstanding receivable is being invoiced

� The FORM ID field in the print document is only set if the above conditions apply. Then the bill printout

creates a payment medium in addition to the bill.

� The system also generates a payment form number for the payment medium. This number can be

specified on the note to payee. The number range must be defined.


SAP AG 1999

Presort Key Function

Billing Document 1 Billing Document 2

Function Module

ISU_BILL_TYPE_CONTRACT

Invoicing

Presort Keys:0001 = Sort according to contract w/o subtotals

0002 = Sort according to contract with subtotals

Electricity

Presort Line Item Type Contract Amount

0001 IDEMAN 47120001 IQUANT 4712

0002 000001 4712 12.45 UNI

0002 000002 4712 33.78 UNI

Electricity

Presort Line Item Type Contract Amount

0001 IDEMAN 47110001 IQUANT 4711

0002 000001 4711 312.45 UNI

0002 000002 4711 31.78 UNI

� In the above example, a contract account has two electricity contracts. The presort key 0001 is assigned

to the info lines in the billing schema. The presort key 0002 is assigned to the billing line items relevant

for posting.

� The sorting function module ISU_BILL_TYPE_CONTRACT is allocated to the 0001 and 0002 keys in

Customizing for presort keys. This function module sorts the billing line items according to contract

number.


SAP AG 1999

Presort Key Function - Step 1

Electricity

Presort Line Item Type Contract Amount0001 IDEMAN 4712

0001 IQUANT 4712

0001 IDEMAN 4711

0001 IQUANT 4711

0002 000001 4712 12.45 UNI

0002 000002 4712 33.78 UNI

0002 000001 4711 312.45 UNI

0002 000002 4711 31.78 UNI

Document Line Items SortedAccording to Presort Key

(cannot be changed by user)

Presort Keys:0001 = Sort according to contract w/o subtotal

0002 = Sort according to contract with subtotal

Print Document

� In the first step, the billing line items are sorted according to presort key; in other words, billing line

items with the presort key 0001 appear above billing line items with the presort key 0002.

� The user cannot change this sort order. It can only be influenced by the definition of the appropriate

presort key.


SAP AG 1999


Electricity

Presort Line Item Type Contract Amount0001 IDEMAN 4711

0001 IQUANT 4711

0001 IDEMAN 4712

0001 IQUANT 4712

0002 000002 4711 312.45 UNI

0002 000002 4711 31.78 UNI

0002 000001 4712 12.45 UNI

0002 000002 4712 33.78 UNI

Document Line Items SortedAccording to Contract

(Function Module SU_BILL_TYPE_CONTRACT)

User-Defined => Dependent

on Presort Key

Print Document



� In the second step, the billing line items are sorted according to the logic in the function module. In this

case, they are sorted according to contract number. The ISU_BILL_TYPE_CONTRACT function

module carries out the sorting.


SAP AG 1999


ElectricityPresort Line Item Type Contract Amount

0001 IDEMAN 4711

0001 IQUANT 4711

0001 IDEMAN 4712

0001 IQUANT 4712

0002 000002 4711 312.45 UNI

0002 000002 4711 31.78 UNI

Subtot.(City Tax) 12.56 UNI

Subtot.(Country Tax) 15.66 UNI

0002 000001 4712 12.45 UNI

0002 000002 4712 33.78 UNISubtot.(City Tax) 2.56 UNI

Subtot.(Country Tax) 5.66 UNI

Create subtotal line items when

contract changes(see above function module)

Print Document



� In the third step, the system inserts subtotals. Customizing for presort key 0002 specifies that subtotals

are to be generated. The system recognizes the control break for the contract and inserts special subtotals

in the print document.

� There must be at least one billing line item in each billing schema that has a presort key that generates a

subtotal.

� The aim of the presort keys should be to sort the billing line items in the print document in the exact

order in which they should be printed. Resorting the line items later on during bill printing is time-

consuming and can lead to errors (for example, if the clerk defines the subtotals manually).


SAP AG 1999

Print

Document

with Printed

Lines

Print Report

Collective Bills

Print Report

Collective Bills

InvoicingInvoicing

C. acct: 8711

Acct cat.: SR

C. acct: 4712

Acct cat.: ISUCB acct: 8711

Form: Cover Page Form: Individual BillIndividual

Bills

IndividualBills

Cover Pagewith Individual

Information

Cover Pagewith Individual

Information

C. acct: 8711

Acct cat.: SR

Collector LtdAnne Miller Henry Smith Maria Bush

Acct: 4712Acct cat.: ISUCB acct: 8711



Collective Bill Print Process

� When rental contracts are invoiced (invoicing consumption billing, budget billing request (statistical),

partial bill creation (debit entry)), a collective bill (statistical reference document in the collective

account) is created. A clearing restriction is placed on this, which blocks it for payment and clearing. In

contrast to the invoicing procedure for billing documents, this procedure creates an invoicing order for

the Create Collective Bill process instead of a print index.

� Using selection specifications, you can start the Create Collective Bill process periodically, for example,

according to due dates. This selects the invoicing orders created when the rental contracts were invoiced.

All the collective bills for a collector, which have the same due date, are invoiced in an invoicing unit.

The clearing restrictions set when the rental contracts were invoiced are canceled. A collective bill print

document and a corresponding print index for the print program is created.


SAP AG 1999




Bill Printout: 2


SAP AG 1999

� 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

� Print action records are used to inform the customer of additional information (such as a bill).

� You can also send other information with it.


SAP AG 1999

Customer

Reportfor Building

Print Action Records

Customer

Reportfor Building

Print Action Records

FunctionModule

forWriting

a PrintAction

Recordsatzes

Form ClassForm Class

Print Action

Record

Print Action

Record

� Mass Creation of Print Action Records


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


SAP AG 1999

ContractContract

Business

Partner

Business

Partner

Contract

Account

Contract

Account


Transaction for

Displaying,Changing, and

DeletingPrint Action Records

Transaction for

Displaying,Changing, and

DeletingPrint Action Records

Form ClassForm Class

Print Action

Record

Print Action

Record

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


SAP AG 1999

Send rate information

Send collection authorizationSend questionnaire on gas action

Text information: meter replacement in next billing periodText information: greeting

Text information: move-in/out.

.

.

Valid from: Valid to:Send x no. of times:

Form class

Send rate information

Send collection authorizationSend questionnaire on gas action

Text information: meter replacement in next billing periodText information: greeting

Text information: move-in/out.

.

.

Valid from: Valid to:Send x no. of times:

Form class


xx

x

01/01/1997 12/31/19971IS_U_BI_BILL

Option ofEntering a User-

Defined Text(Standard SAP

Text Module)

Option ofEntering a User-

Defined Text(Standard SAP

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


SAP AG 1999




Bill Printout: 3


SAP AG 1999

22

11

22

11Print

Workbench

IS-Uapplication

form

PrintWorkbench

IS-Uapplication

form

SAPscript

form

(layout, text,data)

SAPscript

form

(layout, text,

data)

ApplicationApplicationPrint

program

Print

program

Spool file

(alternative)

External systems

• Mass data

• Mailroom system

• Postage determination

• Sorting

• Creation of layout

External systems• Mass data

• Mailroom system

• Postage determination

• Sorting

• Creation of layout

Raw data interface

Co

mp

lete

form

for o

nlin

e p

rintin

g

Generates Ne

t form

for

raw

da

ta

inte

rfac

e

Raw Data Interface: 1

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


SAP AG 1999

Raw Data Interface

SAPscriptForm

SAPscriptForm

External Systems• Mass Data

• Mailroom System• Postage Determination

• Sorting• Creation of Layout

External Systems• Mass Data

• Mailroom System• Postage Determination

• Sorting• Creation of Layout

Spool FileOptical Archiving Systems

Raw Data Interface: 2

Header data:

Line item data:

Form window Text element Variable name Contents-----------------------------------------------------------------------------Window1 Element1 FKKKO-BUDAT 01/01/1997Window1 Element2 EVER-SPARTE 01...

� Bills can also be archived optically.


SAP AG 1999 SAP AG

� Integration with the IS-U 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.

Bill Printout: Unit Summary


Bill Printout: 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?

____________________________________________________________


Bill Printout: 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


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

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.


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

ISUACCOUNT IS_U_CS_MOVE_IN_WELCOME_LETTER

ISUCONTRCT IS_U_BI_BILL

ISUCONTRCT IS_U_BI_COLLECTIVE_BILL

ISUCONTRCT IS_U_CS_MOVE_IN_WELCOME_LETTER

ISUPARTNER IS_U_BI_BILL

ISUPARTNER IS_U_BI_COLLECTIVE_BILL

ISUPARTNER IS_U_CS_MOVE_IN_WELCOME_LETTER



� Discount and Surcharge Options

� Master Data

� Effects on the Rate Structure

Discounts/Surcharges


SAP AG 1999

Discounts/Surcharges: Unit Objectives


� Describe the discount and surcharge options

� Explain the general and specific master data for discounts

� Explain the effect on the rate structure

SAP AG 2001


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master Data


BillPrintout

BillingBilling











� The scenario in this unit deals with creating discount keys and assigning them to the business partner

installation.


SAP AG 1999

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



Discount and Surcharge Options in IS-U

% ΣΣΣΣ + - 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 an 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.


SAP AG 1999

General data Specific data

Discount /surcharge

Rate facts

Rate category

facts

Installation

facts

Installation structure

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


SAP AG 1999

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.


SAP AG 1999

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.


Discounts/Surcharges: 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 January 1st of this year


Reference basis Price discount

Discount type Percentage

Data

Text Discount ##



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


Discounts/Surcharges: 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 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##. 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 →→→→


Rates.

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


Select Rate Steps.


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.


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 →→→→ Technical Master Data →→→→

Installation →→→→ Change.

Enter installation number TF1001A0## in the initial screen and change the

rate category in the time-based data.

Go to the billing analysis (transaction EA00) and test your discount.



� Manual Billing Functions

� Examples of Use

� Individual Bill

� Joint Invoicing

Manual Billing




� 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


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the

Master DataInvoicingInvoicing

BillPrintout

BillPrintout

BillingBilling











� The scenario in this unit deals with creating manual billing documents.


SAP AG 1999

Calculation Options Functions

Manual

Billing

Meter Reading from/to

Net Amount

Price

Determination

Billing QuantityRate

Determination

StatusManagement

Tax

Determination

Individual Bill/

Joint Invoice

Reference

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.

� Status management is an additional control option. This enables, for example, double checking. One

person can enter a manual billing document, while someone else checks it and releases it for invoicing.


SAP AG 1999

(Time-based)

Data objects Invoicing

Business partner

Contract account

Contract

Installation

Installation

structure(optional)

Bill

Ms. Brown....

Electricity ............. 900

Budget billing amts -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).


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; if it is negative a

backbilling is created.


SAP AG 1999

Selection of

- Affected Line Items

- Billing Order

Selection of- Affected Line Items

- Billing Order

Print Action Record

Control Data

� Joint Invoicing

� Copy Prorations

Initial Entry

� Contract

� Key Date

Control Data

� Copy of Doc. Line Items

� Reversal

Reference

� Billing 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.


SAP AG 1999

With Reference toBilling Order

Billing Document

Contract

Billing Order

ReleaseReleaseBill

PrintoutInvoicing

Explicit Release

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


SAP AG 1999

Manual

Billing

Manual

Billing

Bill

� Last bill not reversible� Last bill not to be reversed

� No bill available

Examples of Manual Billing

� 500 kWh backbillingdue to incorrect

meter reading

� 400.00 UNI 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. It deals with additional credit/backbilling

line items, which can be invoiced either individually or together with the next bill.


SAP AG 1999

InvoicingBill

Manual Billing Document

Bill PrintoutPrint Document with Printed

Lines

Automatic Billing

Document

InvoicingBill

Bill PrintoutPrint Document with Printed

Lines

Manual Billing Document

Joint InvoicingJoint Invoicing

Individual Bill

Joint Invoicing/Individual 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.

(C) SAP AG IUT230 10-10

SAP AG 1999

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.

(C) SAP AG IUT230 10-11

Manual Billing: 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. Release the manual billing document.

1-1-2 Now the manual billing document has to be invoiced. Go to invoicing and carry

out the invoicing procedure for the business partner TF1101A0##. Go to the

print document and display the bill on the screen.

1-2 After invoicing the manual billing document, look at the customer’s account.

1-2-1 Use the account balance display for the business partner TF1101A0##.

(C) SAP AG IUT230 10-12

Manual Billing: 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. Release the

manual billing document.

From the SAP menu, choose: Utilities Industry →→→→ Billing →→→→ Billing Execution →→→→

Manual Billing →→→→ Create.

Key date: Today’s date

Joint invoicing: Leave empty

Find the last billing document for the contract using the search help and enter this

as a reference document. The reference document makes it easier to enter the line

items in the manual bill.

Copy document line items: check

Select the second document line item and choose Position. This line item is used as a

reference.

Enter the necessary data. The system only automatically proposes the (original)

quantity of 2000 kWh in the event of a reversal.

Release the manual billing document.

1-1-2 Now the manual billing document has to be invoiced. Go to invoicing and carry

out the invoicing procedure for the business partner TF1101A0##. Go to the print

document and display the bill on the screen.

From the SAP menu, choose: Utilities Industry →→→→Invoicing →→→→ Invoice Processing

→→→→Individual Processing →→→→ Create Bill.

1-2 After invoicing the manual billing document, look at the customer’s account.

1-2-1 Use the account balance display for the business partner TF1101A0##.

From the SAP menu, choose: Utilities Industry →→→→ Contract Account Receivable and

Payable →→→→ Account →→→→ Account Balance.



This unit will prepare you to to:

� Describe the various franchise fee procedures

� Explain gas billing with IS-U

� 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

Special Billing Features


SAP AG 1999


� 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 2001

Special Billing Features: Unit Objectives


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the


BillPrintout

BillPrintout

BillingBilling











� The scenario in this unit deals with special billing features.


SAP AG 1999

� Franchise Fee

� Gas Billing

� Reference Values/Lighting

� Billing Deregulated Contracts

� Archiving Billing Data

� Special Types of Billing

Special Billing Features: 1


SAP AG 1999

Quantity

Amount *FF Factor

FF Price

=

=

FF

Amount

FF based on a quantity and an amount (electricity and gas divisions)

FF based on an amount and a percentage ratewithout price grouping

FF

Amount*

Amount FF Factor =

FF based on an amount and a percentage rate (water division)with price grouping

FF

Amount*

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.


SAP AG 1999

Net Procedure Gross Procedure Max. Gross Procedure

Price incl. FF Price incl. FF Price incl. FF

Price Table

Price incl. FFPrice Table

Price incl. FFFF-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.


SAP AG 1999

Rate Steps

Franchise Fee Group

Prices

FF ContractFF Procedure

Franchise Fee GroupFF Amounts, FF Contribution

Rate

PricesFF amounts can

be overriden

Franchise Fee: Data Retention

Installation

(FF Contract)

Consumption

Premise

Connection

Object

Regional

Structure

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


SAP AG 1999

� Franchise Fee

� Gas Billing







SAP AG 1999

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

(C) SAP AG IUT230 11-10

SAP AG 1999

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.

(C) SAP AG IUT230 11-11

SAP AG 1999

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

Gas Billing

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

(C) SAP AG IUT230 11-12

SAP AG 1999

Consumption Premise

Connection Object

RegisterRegister

• Calorific Value District• Air Pressure Area• Temperature Area

• Gas Pressure AreaCustomizingCustomizing

Gas Procedure

Calorific

Value

Volume

Correction

Factor

=+

• No Thermal Gas Factors

• Temperature• Temperature and Pressure

• Temperature, Pressure, and Compressibility

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 TemperaturePostal

Regional Structure

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


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.

(C) SAP AG IUT230 11-13

SAP AG 1999


Basic Functions

Master Data

Device Management

Contract Billing

Invoicing

Contract A/R & A/P

Customer Service

Work Management

Information System

Tools

Utilities IndustryUtilities Industry

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/annual

calorific 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

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

(C) SAP AG IUT230 11-14

SAP AG 1999

� 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

(C) SAP AG IUT230 11-15

SAP AG 1999

ST AP + Act.P 1

VCF = ------- 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

(C) SAP AG IUT230 11-16

SAP AG 1999

Key:

� MP = Measured pressure of the meter

� AP = Air pressure

� SP = Standard air pressure

� GLDF = Gas law deviation factor

� To = 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.

(C) SAP AG IUT230 11-17

SAP AG 1999

� Arithmetic Annual Average

� Weighted Annual Average

� Fixed Temperature

� Arithmetic Average for the Billing Period

� Weighted Average for the Billing Period






Temperature Procedure

(C) SAP AG IUT230 11-18

SAP AG 1999

ST AP + Act.P 1

VCF = ------- x --------------------- x -------

T SP GLDF

Pressure


(C) SAP AG IUT230 11-19

SAP AG 1999

� Annual Air Pressure

� Air Pressure Measured each Month



Air Pressure

(C) SAP AG IUT230 11-20

SAP AG 1999

ST AP + Act.P 1

VCF = ------- x --------------------- x -------

T SP GLDF

Gas Law Deviation Factor


(C) SAP AG IUT230 11-21

SAP AG 1999

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.

(C) SAP AG IUT230 11-22

SAP AG 1999





Calorific Value Procedure

(C) SAP AG IUT230 11-23

SAP AG 1999

� Register


� Gas Procedure

� Rate Category

� Type of Gas Billing (Thermal, Volumetric, According to

Standard Cubic Meters)

� Regional Structure

� Default Value for Device Installation

� Air Pressure Area

� Temperature Area

� Calorific Value District

Relevant Master Data

(C) SAP AG IUT230 11-24

SAP AG 1999

� Franchise Fee

� Gas Billing






(C) SAP AG IUT230 11-25

SAP AG 1999

Street lighting is billed using reference

values from the installations facts

REFVAL04

REFVAL05REFVAL06

REFVAL04REFVAL05REFVAL06

Variant Programs

� Group Management

� Individual Management

� Different Connection Loads

� Billing Using Energy Prices

� Billing 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.

(C) SAP AG IUT230 11-26

SAP AG 1999

� Required to calculate charges that are not based on readings

� Stored in the installation facts

� Available for the following:

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

(C) SAP AG IUT230 11-27

SAP AG 1999

Lighting: The different values for operation types are used in the burning hour calendar.

� Value 2 = value to be billed

� If you only specify value 1 (= entry value), then

value 2 = value 1

� Indicator: not relevant for billing

� Repetition factor

� For 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.

(C) SAP AG IUT230 11-28

SAP AG 1999

� Franchise Fee

� Gas Billing






(C) SAP AG IUT230 11-29

SAP AG 1999

Distribution

Procurement

Transmission

Distribution

Disposal

Transmission

Extraction

Procurement

Distribution

Trans-

mission

Generation

Procurement

AdditionalAdditional

divisionsdivisions

Such as:Such as:Local heatingLocal heating

Public transportPublic transportCable TVCable TV

Waste removalWaste removalSale of appliancesSale of appliances

. . . . .. . . . .

Usually jointUsually joint

customer service/billingcustomer service/billing

C o n t r o l l i n gInternal company structure according to plants, clients, and groups

Usually

joint

meter reading

Customer

10

01

00

Total

Saales Tax

Subt otal

SALESPERSONDATE

TotalPr iceDescr iptionQty ShippedQty Ordered

INVOICE #: P.O. #:

Customer Premise

BillBill

EnergyEnergy

ContractContractbetweenbetween

XXXXXXXXXXXXXXXXXX

andand

EVUEVU LtdLtdnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Energy SupplyEnergy Supply

ContractContractbetweenbetween

XXXXXXXXXXXXXXXXXX

andand

EVUEVU LtdLtdnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Energy supplyEnergy supply

contractcontractbetweenbetween

XXXXXXXXXXXXXXXXXX

andand

EVUEVU LtdLtdnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Energy Energy

supplysupply

contractcontractbetweenbetween

< Customer >< Customer >

andand

< utility company>< utility company>

Meter readingresults


Distribution

Transmission

Generation

Procurement

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.

(C) SAP AG IUT230 11-30

SAP AG 1999

Distribution

company

Transmission

company

Generation

company

Energy trading &

service company

"Energy One"

Ac

tivit

y a

llo

cati

on

Highly regulated

Highly regulated

Regulated

Regulated

Competition

Competition

Deregulated

Deregulated Ene

rgy

tradin

g c

om

pan

y/bro

ker

En

erg

y tr

ad

ing c

om

pa

ny/

bro

ker

Customer

10

01

00

Total

Saales Tax

Subt otal

SALESPERSONDATE

TotalPr iceDescr iptionQty ShippedQty Or der ed

INVOICE #: P.O. #:

Customer Premise

BillBill



Structures of a Deregulated Utility Company / Regional Supplier

� As a result of liberalization and deregulation, enterprise areas are being unbundled analogous to the

value chain.

� Generation: Deregulated market directed at competitors. For the competition, not only the price counts,

but also how the energy is generated (for example, is generation harmful to the environment).

� Transmission: Highly regulated. The aim is to keep energy relatively independent of where it was

generated.

� Distribution: Basic services are regulated. However, there is room for improvement using modern

measuring devices, different service levels or additional services.

� Customer service: Very competitive. As well as selling the basic services mentioned above internally or

to third parties, customer service is also sold as a value in itself. Customer service is considered as part

of a service provider's added value, as part of their competitive leverage.

� Energy trading company/broker: Team of specialists that speculates in commodity trading of energy for

their own and third-party purposes, profit optimization or loss minimization by procuring missing

capacity or selling surplus capacity on the energy market.

� Generally: Unbundling creates increased demands on enterprise controlling within the concern.

(C) SAP AG IUT230 11-31

SAP AG 1999

Customer

Distribution

Company

Transmission

Company

Generation

Company

Energy Trading &

Service Company

Energy Trading &

Service Company

Org

an

iza

tio

n f

or

Inte

rna

l A

cti

vit

y A

llo

ca

tio

n

11

44

33

22

55 66

77

77

77

77

Highly Regulated

Highly Regulated

Regulated

Regulated

Deregulated

Deregulated

Competition

Competition

Ene

rgy

Tra

din

g C

om

pa

ny/

Bro

ke

rE

ne

rgy

Tra

din

g C

om

pa

ny/

Bro

ke

r

10

01

00

"Energy One""Energy One"Total

Saales Tax

Subt otal

SALESPERSONDATE

TotalPr iceDescr iptionQty ShippedQty Or der ed

IN VOICE #: P.O. #:

Customer Cons. Premise

BillBill

Meter ReadingMeter ReadingResultsResults

The Utilities Market from the Customer's Perspective

� From the customer’s perspective, the liberalized energy market is completely different to how it used to

be:

� The customer can choose from a range of energy generating companies.

� He generally doesn’t know who is involved in the transmission.

� The distribution company remains the same utilities company as before (at least during a longer

changeover period).

� The service company could be the same as before or it could be a new service provider.

� Completely new types of companies are appearing in the energy market:

� "Aggregators": Company that owns the customer but not his installation. They represent many

residential customers in comparison with the old utilities companies. They can also be the service

companies of other concerns.

� There will also be energy trading companies/brokers, whose customers are either industrial companies

or nonresidential customers.

� Activity allocation organization: unbundling of company parts on the one hand and the customer’s

ability to choose several suppliers of the same utility type on the other hand both result in one company

demand for another company. The result is there are fewer bills, but these are much more complex.

(C) SAP AG IUT230 11-32

SAP AG 1999

OneDivision

SeveralDivisions

Single

UC

Several

UCs

StandardBilling

StandardBilling

Multi-Sector

Billing

Multi-Sector

Billing

UnbundledBilling

UnbundledBilling

ConvergentBilling

ConvergentBilling

UC: Utility company

Standard Billing:Standard Billing:

Billing of one division for services rendered by one utility company

MultiMulti--Sector Billing:Sector 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!

(C) SAP AG IUT230 11-33

SAP AG 1999

OneDivision

SeveralDivisions

Single

UC

Several

UCs

StandardBilling

Multi-Sector

Billing

UnbundledBilling

UnbundledBilling

ConvergentConvergent

BillingBilling

UC: Utility company

Example:

Home Electricity

Provider

Home Electricity

Provider

Cx/Electricity/Energy . . . . . . . UNI

C1/Electricity/Distribution. . . . . UNI

C1/Electricity/Cust. Service. . . UNITP/Cont. to standard assets. . . . . UNI---------------------------------------------Total: . . . . . . . . . . . . . . . . . . . UNI

Bill Mr. Smith/<Address>

Energy Supply Service:

Competing

ElectricityProvider

Competing

ElectricityProvider

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.

(C) SAP AG IUT230 11-34

SAP AG 1999

Businesspartner

Businesspartner

Contract A/R & A/P

Contract A/R & A/P

Installation 1Installation 1

DeviceDevice

Contract 1Contract 1


Contract 2Contract 2

Billing-

relatedinstallation

Billing-

relatedinstallation

Contract 1 with home electricity provider

Billing of transmission charges in company code 0001

Contract 2 with suppliersBilling of supplied energy in

company code 0002

Device location

Device location

Technical installation

MMM

SupplierSupplierMMM

IDE

Intercompany

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

(C) SAP AG IUT230 11-35

SAP AG 1999

Technical installation


DeviceDevice

Contract 1Contract 1Point of deliveryservice

Point of deliveryservice

Billing-

related

installation

Contract, distribution

of grid usage costs to billing

Point of delivery service 'utility'

Device location

Device location

Businesspartner

Businesspartner

Contract account

Contract account

Point of delivery

Point of delivery

Distributor view

Deregulation in the IS-U Data Model 2

(C) SAP AG IUT230 11-36

SAP AG 1999

Separation of Device Management and BillingSeparation of Device Management and Billing

Device Information Record

� Usage in billing

� Only contains billing-relevant device data

� PM functions cannot be used

� Behaves like an installed device

� Device allocations and register relationships are possible

� Proration in last billing-related removal

� Treated the same as standard devices as far as serial

numbers and meter reading data processing are concerned

� Created explicitly or in billing-related installation

(C) SAP AG IUT230 11-37

SAP AG 1999

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

(C) SAP AG IUT230 11-38

SAP AG 1999

EquipmentDevice

EquipmentDevice

MaterialDevice

Category

MaterialDevice

Category

ConsumptionPremise

ConsumptionPremise

RegionalStructure

RegionalStructure

InstallationInstallationFunctional Location Connection Object

Functional Location Connection Object



Billing-

Relevant

Installation

Device Installation - Device Information Record

� During device installation, you can create the device information record automatically using the billing-

relevant installation. This means that a technical installation in a device location is unnecessary. Using

the billing-relevant installation, you can maintain rate data for registers or devices at an installation

structure level.

(C) SAP AG IUT230 11-39

SAP AG 1999

� Franchise Fee

� Gas Billing






(C) SAP AG IUT230 11-40

SAP AG 1999

R/3R/3 DBDB

Application Data

Archiving Session

Archiving Program of the "Archiving Object"

R/3 Database Archive Files

Offline Storage

The Archiving Process: Overview

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

(C) SAP AG IUT230 11-41

SAP AG 1999

Step 1: Initial Run* (Optional)

PreparationProgramPreparationProgramR/3

DatabaseR/3

Database Business object can be archived

* In IS-U/CCS provides preparation programs for:

• Billing Documents

• Print Documents

• Budget Billing Plans

• Meter Reading Documents

Initial Run

(C) SAP AG IUT230 11-42

SAP AG 1999

ArchiveFile

ArchiveFile

ArchiveFile

ArchiveFile

Step 2: Create Archive File

(*)

• With Preparation Program

Only the data to be archived is selected

• Without Preparation Program

Archiving program covers the archiving analysis process

Archive File

ArchivingProgram*ArchivingProgram*R/3

DatabaseR/3

Database

(C) SAP AG IUT230 11-43

SAP AG 1999

ArchivingProgram*ArchivingProgram*R/3

DatabaseR/3

Database

ArchiveFile 2

ArchiveFile 2

ArchiveFile 1

ArchiveFile 1

Step 3: Execute Delete Program (1)

DeleteProgramDeleteProgram

R/3 Database

R/3 Database

ArchiveFile 2

ArchiveFile 2

ArchiveFile 1

ArchiveFile 1

Execute Delete Program (2)

DeleteProgramDeleteProgram

Delete Program

� As soon as the archive file is closed, a new archive file is opened and the archiving process continues. At

the same time, the delete program is started for the first archive file.

� Only data records that have been archived correctly are deleted.

� When all the archive files are closed, the delete program is started manually.

(C) SAP AG IUT230 11-44

SAP AG 1999

Step 4: Store Archive Files

There are a number of ways to store/manage archive files:

� Hierarchical Management System (HMS)

The archive file system generated by the archiving process is added to the HMS.You only have to maintain the relevant file path in Customizing for archiving.

� Archiving System using ArchiveLink

If an external system is connected using ArchiveLink, this archiving system is instructed to store the archive files after the delete program has been run successfully.

� Manual Management:

If an external system is not required, the files can be managed by the IT department.

For each archiving object, you can display the current access status of a particular file in the defined directory using the administrative functions for

the archiving session.

Storing Archive Files

(C) SAP AG IUT230 11-45

SAP AG 1999

Factors Influencing Archiving Duration

� The hardware used

� Processes in R/3 and required checks (preparation program)

� Quantity of data to be archived in a session

� Archiving flow

� Parallel execution of archiving jobs

� Size of the data base

� Current workload

� Access to archive files

� . . .

Influencing Factors

� Warning: There is no general rule of thumb for the duration of an archiving session. The duration is

largely dependent on the above-mentioned factors.

(C) SAP AG IUT230 11-46

SAP AG 1999

Characteristics of R/3 data archiving with the ADK (Archive Development Kit)

� Archiving criteria check

� More reliable two-step process

� Online archiving

� Automatic conversion of old archive files

� Compression

Characteristics

� Main advantage of the automatic conversion of old archive files:

The conversion necessary as a result of a change to the hardware or software is carried out automatically

when the archived data is imported.

� The Archive Development Kit (ADK) can take into account changes to the database structure (field type,

field length, new fields) automatically. The adjustments are made when the archive file is imported.

However, the changes made to the data in the archive file are not permanent. As a result, a mass

conversion is not required when the hardware or software has been changed.

� During archiving, the data is automatically compressed by a factor of 5. If the data to be archived is

contained in cluster tables, it is not compressed further.

(C) SAP AG IUT230 11-47

SAP AG 1999

Characteristics of R/3 data archiving with the ADK

� Direct access to archived data

� Analysis of the archived data

� Link to external storage media

� Release of the ADK as a development tool

The Archiving Process

� The ADK enables you to access an individual document in the archived data. You can also read archived

data using reports and the archive information system.

� The ADK enables you to link external archive systems using SAP ArchiveLink.

You can also store archive files in an HMS. This does not require a special interface.

� Using the ADK, you can create the functionality required to archive customer-specific tables. Using the

ADK, you can also create customer-specific report program.

(C) SAP AG IUT230 11-48

SAP AG 1999

Two Archiving Objects:

a) Print Document Line Items (ISU_PRDOCL)

Archived Tables:

� DBERDZ Print Document Line Items

� DBERDL Print Document Line Items (from IS-U/CCS Release 4.61)

� DBERDLB Print Document Line Item Reference to a Billing Document Line Item(from IS-U/CCS Release 4.61)

b) Print Document Header (ISU_PRDOCH)

Archived Tables:

� ERDK Print Document Header

� ERDB Invoicing Document for a Print Document

� ERDO Outsorting Table for Invoicing

� DBERDR Discount Line Items for Print Document

� DBERDU Conversion Steps per Billing Line item

Print Document

� Because of problems with the size of the database, table DBERDZ in IS-U/CCS Release 4.61 has been

divided into the following two tables:

� DBERDL

� DBERDLB.

This has resulted in a reduction of almost 75% in the memory space required for a print document line

item.

� Separating document headers and document line items enables the document line items to be archived

after a relatively short retention period. The advantage of this is that a large quantity of data can be

removed from the system, and yet certain functions, such as reversing an individual print document, are

still available. Document headers, which require considerably less memory space, can exist in the system

over a very long period of time.

(C) SAP AG IUT230 11-49

SAP AG 1999

ISU_PRDOCL

Archiving Sequence

ISU_BILL

ISU_PRDOCH

ISU_BILLZ

ISU_BBPPrint Documents

Billing Documents

Budget Billing Plans

Archiving Sequence: Print Document

� The archiving objects in IS-U/CCS for print documents, billing documents, and budget billing plans

must be archived in a fixed sequence that is checked by every preparation program.

(C) SAP AG IUT230 11-50

SAP AG 1999

Budget Billing Plan (ISU_BBP)

Archived Tables:

� EABP Budget Billing Plan Header

� EJVL Data for the YAP (from mySAP Utilities 4.61 for IS-U/CCS)

� DFKKMOP Line Items of the Budget Billing Plan (Budget Billing Transaction 2 and3 only)

� DFKKMOPW Line Items of the Budget Billing Plan (Budget Billing Transaction 2 and 3 only)

Budget Billing Plan

� DFKKMOP: Line items of the budget billing plan (for debit memo entry and budget billing plans only)

DFKKMOPW: Line items of the budget billing plan (for debit memo entry and budget billing plans only)

The line items of statistics-related budget billing plans are archived using the archiving program for contract

accounts receivable and payable documents.

(C) SAP AG IUT230 11-51

SAP AG 1999

ISU_BBP

Archiving Sequence

ISU_PRDOCL

Print Documents Budget Billing Plans

ISU_PRDOCH

Archiving Sequence: Budget Billing Plan

� Before you can archive a budget billing plan, you must archive the whole print document (document

header and line items) that deactivated this plan.

As is the case when the print document is reversed, the deactivated budget billing plan is reopened. This

means that the budget billing plan must still be in the database.

(C) SAP AG IUT230 11-52

SAP AG 1999

Two archiving objects:

a) Billing document line items (ISU_BILLZ)

Archived tables:

� DBERCHR Discount line items for billing document

� DBERCHU Conversion steps for each billing line item

� DBERCHT

� DBERCHZ ...OR...

b) Billing document header (ISU_BILL)

Archived tables:

� ERCH Billing document header

� RCHC Invoicing history

� ERCHO Outsorting table for billing

� DBERDL Consumption history (from IS-U/CCS mySAP Utilities 4.61)

� ERCHP Periods to analyze for dynamic billing

- from mySAP Utilities 4.62

from mySAP Utilities 4.62:

DBERCHZ1, DBERCHZ2, DBERCHZ3, DBERCHZ4

Billing Document

� DBERCHR: Discount line items for billing document

DBERCHU: Conversion steps per billing line item

DBERCHZ: Billing document line items

DBERCHZ1: New (4.62) main table of billing document line items

DBERCHZ2: New (4.62) document line items (device data)

DBERCHZ3: New (4.62) document line items rate/amount data)

DBERCHZ4: New (4.62) billing document line items (rarely used fields)

DBERCHT: Texts billing document

� Because of problems with the size of the database, table DBERDZ in IS-U/CCS mySAP Utilities 4.62

has been divided into eight tables:

DBERCHZ1.......DBERCHZ8

� Tables 5-8 are copies of 1-4. Tables 1-4 contain the billing line items that are required for further

activities, such as reversal. Tables 5-8 only contain the entries that are required for printing the

customer's bill (for example, billing information line items). For this reason, they can be removed from

the system more quickly.

� In Customizing, you can define the importance of a billing line item (for each line item type) by

choosing SA Utilities -> Tools -> System Modifications -> User-Defined Variant Programs -> Define

Line Item Types.

� If you decide that some of the billing line items generated are not important, these entries are not

archived. After a predefined period of time, these entries are deleted from the tables by means of a

report.

(C) SAP AG IUT230 11-53

SAP AG 1999

ISU_BILLZ

Archiving Sequence

ISU_BILL

Print Documents

Billing Documents

ISU_PRDOCL ISU_PRDOCH

Archiving Sequence: Billing Document

� The archiving objects in IS-U/CCS for print documents and billing documents must be archived in a

fixed sequence that is checked by every preparation program.

(C) SAP AG IUT230 11-54

SAP AG 1999

Archiving Object: ISU_EABL

Archived Tables:

� EABL Meter Reading Document

� EABLG Reason for Meter Reading Document

Meter Reading Documents

� As of IS-U/CCS Release 4.62, the tables had the following sizes:

� EABL : 344 bytes/data record

� EABLG : 52 bytes/data record

(C) SAP AG IUT230 11-55

SAP AG 1999

Archiving Sequence

ISU_BILLISU_BILLZ

Meter Reading Documents

ISU_EABL

Install. 1

Install. 2

|------1-----| |------------| |------------| |-----------|

|--------------------------| |--------------------------|

Meter Reading

Documents Can Be

Archived

Retention Period for Billing

Documents (366 Days)

Archiving Sequence: Meter Reading Documents

� The archiving objects in IS-U/CCS for billing and meter reading documents must not be archived in a

fixed sequence. However, the documents are linked, and this must be taken into account for the meter

reading programs.

� The meter reading document basically provides the consumption data required to bill an installation. For

this reason, the meter reading document cannot be archived until all the installations for which the

document provides consumption data have been billed. A meter reading document can contain

consumption data for more than one installation.

� As with archiving billing documents, you cannot reverse a billing document when it is old enough and

due to be archived (the deadline is determined from the shortest retention period specified in

Customizing). Only then can the meter reading document be archived, since it is no longer required for

billing an installation.

� If the meter reading document in the example above refers to the period of bill 1 and was only used for

installation 1, it is ready to be archived (this billing document is older than the minimum retention period

and, therefore, can no longer be reversed). If, however, the meter reading document does refer to

installation 2, it is not ready to be archived, since the billing document does not lie entirely within the

archiving period and, therefore, can still be reversed. In the event of a reversal, the meter reading

document is needed to rebill the installation.

(C) SAP AG IUT230 11-56

SAP AG 1999

� Franchise Fee

� Gas Billing






(C) SAP AG IUT230 11-57

SAP AG 1999

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

(C) SAP AG IUT230 11-58

SAP AG 1999

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

Dynamic Period Control (DPC)

(C) SAP AG IUT230 11-59

SAP AG 1999

� Monthly scheduled billing

01/01/01 07/01/01

|------|------|------|------|------|------| R E E E E E R

R = Real meter reading

E = Estimated meter reading

� 5 estimated billing documents corrected using the values from 1 real billing document.

|------|------|------|------|------|------|

|----------------------------------------|

Example of Using DPC

(C) SAP AG IUT230 11-60

SAP AG 1999

G4

MR0 MR1 MR2 MR3

G1 G2 E4 E5 G3 . . . G3

In

Monthly Billing with Interim Bill

MRn Periodic meter-reading every 6 months

En Monthly billing/invoicing on estimated consumption

In Interim meter-reading with optional billing

E4 Monthly billing/invoicing

MR2 Periodic meter-reading

(C) SAP AG IUT230 11-61

SAP AG 1999

You can also correct the following periods with the realbilling document

|------|------|------|------|------|------|

|---------------------------------| all estimated billing documents in one

time slice

|------|------|------|------|------|------| all estimated billing documents in theoriginal time slice

Flexibility

(C) SAP AG IUT230 11-62

SAP AG 1999

� Field in the rate category to sign the rate category for DPC

� Field in the schema to sign the schema for DPC

� Fields in the schema steps:

� Time slice generator to define the periods that must be

corrected

� DPC variant programs for controlling the DPC in the schema

� DPC Execute to mark the schema steps that must be

recalculated

� DPC reversal execution to mark the schema steps that must be

reversed

� View cluster for controlling the DPC process

DPC Customizing

� Time slice generator

Depending on the period category, you use the time slice generator to determine which periods are

created in dynamic period control for each schema step.

(C) SAP AG IUT230 11-63

SAP AG 1999

Billing Period Categories

� Identification of the current period: 4 possibilities

� Current period can be between real and estimated meter reading |------|

R E

� Current period can be between two estimated meter readings

|------|

E E

� Current period can be between estimated and real meter reading

|------|

E R

� Current period can be between two real meter readings

|------|

R R

(C) SAP AG IUT230 11-64

SAP AG 1999

Periods to be Created

� All periods must be defined: 4 options

� For current period >

|------|------|------|------|------|------|

� All estimated periods and current period

|----------------------------------------|

� All estimated periods in one time slice

|---------------------------------|

� All estimated periods in the original time slices|------|------|------|------|------|

(C) SAP AG IUT230 11-65

SAP AG 1999

Time Slice Generator

� Definition of a time slice generator for the periods that

must be created: 2 examples

� Time slice generator: 0000

for current period >

|------|------|------|------|------|------|

� Time slice generator: CONS

current period plus all estimated periods>

|------|------|------|------|------|------|

|----------------------------------------|

(C) SAP AG IUT230 11-66

SAP AG 1999

Example: Time Slice Generator and Schema Step

� Connecting the time slice generator to the schema step

� Schema DPC with the following steps:

Time slice generator

1. QUANTI01 CONS

2. SETTLE01 0000

� Connecting the fields DPC Execute and DPC Cancel to the schema

step

� Schema DPC with the following steps:

DPC Execute DPC Cancel

1. QUANTI01 DYN1 DYN12. SETTLE01

(C) SAP AG IUT230 11-67

SAP AG 1999

Example: DPC Flow

� Defining the periods that must be created in the schema for the

different current periods in the EPERDET table:

Table EPERDET for schema DPC test:

Schema | Current Period | Tim. Gener. | Period to be created

DPCtest | E------G | 0000 | Current periodDPCtest | E------G | CONS | Current period

DPCtest | G------G | 0000 | Current period DPCtest | G------G | CONS | Current period DPCtest | G------E | 0000 | Current periodDPCtest | G------E | CONS | All estimated and current periods

(C) SAP AG IUT230 11-68

SAP AG 1999

Rate Modeling and Schema Transfer

� Start DPC with the variant program DYNBI01 in the schema and

set the field DPC Start:

Schema DPC with the following steps:

DPC Start DPC Exec. DPC Canc. Time slice gen.

1. QUANTI01 DYN1 DYN1 CONS

2. SETTLE01 0000

3. DYNBI0 DYN1

� The cancellation of estimated billing document line items is processed using the old billing documents.

� The estimated billing document line items that must be cancelled are identified with the DPC Cancel

fields.

� The new billing periods always have the from and to dates of the cancelled billing documents.

� The start date for DPC is stored in the table ERCHP.

(C) SAP AG IUT230 11-69

SAP AG 1999

� The following periods are determined during the

current billing:

1/1/01 7/1/01

|------|------|------|------|------|------|

R E E E E E R> QUANTI01, SETTLE01

|------| > QUANTI01, SETTLE01|------| > QUANTI01, SETTLE01

|------| > QUANTI01, SETTLE01|------| > QUANTI01, SETTLE01

|----------------------------------------| QUANTI01

+ |------| SETTLE01

Period Billing

� In the current Release (IS-U/CCS 4.62), estimated results must be entered in the system.

� In further developments for dynamic period control, estimated results will not have to be stored in the

system.

(C) SAP AG IUT230 11-70

SAP AG 1999

� Multiple-contract billing and billing with EDM

� Reasons for outline agreements

� Data structure

� Processing outline agreements in IS-U

Multiple-Contract Billing

(C) SAP AG IUT230 11-71

SAP AG 1999

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

� Pool formation during billing

� Aggregation of business data

Multiple-Contract Billing: EDM

(C) SAP AG IUT230 11-72

SAP AG 1999

X axis

Demand-time profile ofsubsidiary company 1

kW

Y-A

xis

X-Axis

Demand-time profile ofsubsidiary company 2

kW

Y-A

xis

X-Axis

kW+ + .. +10

20

30

X axis

100

200

300

kW

Total demand of thecompany

Aggregated demand-timeprofile of the company

X axis

100

200

300

kW

Total demand of thecompany

X axis

kW

Contractually-agreeddemand

[ ]* 50

,00

10

0,0

0

1

50

,00

20

0.0

0

00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 24:00

DM/MW

Provisional current price

50

0,0

0

1

00

0,0

0

1

50

0,0

0 2

00

0.0

0

00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 24:00

EURO

Company energy costs for additional demand

-

Sum of allintervals

Sum of allintervals

Billing with EDM 2

(C) SAP AG IUT230 11-73

SAP AG 1999

P1

EDM

P2

P3

P4

P6

P7

P8

P5

+

+

Request

Request

+

+

POD

POD

POD

POD POD

POD

= f ( P3, P4 )

Basic load profile

Aggregated load profile

Formula-based profile

Scheduling

Automatic

+

++

+

Billing with EDM 1

(C) SAP AG IUT230 11-74

SAP AG 1999

Objectives of multiple-contract billing in an open market:

� Ability to offer important customers new and highly flexible contracts:

� A discount can be granted if the total consumption is higher than that specified in the contract.

� A discount can be granted if the total amount is higher than that specified in the contract.

� A block price can be used for the total consumption.

� A scale price can be used for the total consumption.

� A discount of x-amount can be granted for the subsidiary company and a discount of x-amount for the company depending on the total amount.

� An average price can be calculated using the total consumption and total amount

� ..... there's no limit to what you can do!

Multiple-Contract Billing: Objectives

(C) SAP AG IUT230 11-75

SAP AG 1999

Reasons for Outline Agreements

� From the point of view of the utility company

� Middle- to long-term customer relationships

� Competition from other utility companies

� A way for Sales and Distribution to gain new customers

� From the point of view of the customer

� Reduce costs

� More transparent contract requirements

� Electricity customers can be joined resulting injoint contracts with good terms

(C) SAP AG IUT230 11-76

SAP AG 1999

Data Structure of Outline Agreements

� Definition:

� An outline agreement between the customer and the utility company

combines several energy consumption premises.

� 1:1 relationship between individual contract and (individual) installation.1:1 relationship between outline agreement and (outline) installation.

� One-level outline agreements

� Multi-level outline agreements

� Hierarchically

� Linked

(C) SAP AG IUT230 11-77

SAP AG 1999

Individual

contract 1

Individual contract 2

Billing data:Amounts, prices, demand, consumption, discounts, factors. . .

Outline agreement

Data Exchange

(C) SAP AG IUT230 11-78

SAP AG 1999

...

Outline Agreement 1Outline Agreement 1

Contract 1

Contract 1

Contract 2

Contract 2

Contract 3

Contract 3

Contract n

Contract n

Business Partner

1

Business Partner 1

Contract Account

1

Contract Account 1

Business Partner

2

Business Partner 2

Contract Account

2

Contract Account 2

Contract Account 3

Contract Account

3

One-Level Outline Agreements

(C) SAP AG IUT230 11-79

SAP AG 1999

...Contract 1

Contract 1

Contract 2

Contract 2

Contract 3

Contract 3

Contract n

Contract n

Business Partner 1

Business Partner 1

Contract Account 1

Contract Account 1

Business Partner 2

Business Partner 2

Contract Account

2

Contract Account

2Contract Account

3

Contract Account 3

Outline Agreement 3

Outline Agreement 3

Outline Agreement 2

Outline Agreement 2

Outline Agreement 1

Outline Agreement 1

Multi-Level Outline Agreements

(C) SAP AG IUT230 11-80

SAP AG 1999

Terms of Outline Agreements

� Price (joint blocking)

� Blocking is based on the total consumption values of all the

utility installations.

� Discount (bonus rule)

� Amount-based (energy [kWh], demand [kW])

� Flat rate (absolute, percentage)

(C) SAP AG IUT230 11-81

SAP AG 1999

Outline agreementsOA Rule group

OA1 R1OA2 R2… …

Individual contractsOA IC

OA1 IC1OA1 IC2OA2 IC3… …

ActivitiesAC01 Completeness02 Total consumption03 Individual discount… …

Allocation to rule groupRG AC01 0101 0202 01… …

Rule groupRG 01 Joint billing02 Year-end %… …

Transaction EAOUTL

� Define outline agreement facts

� Define activities

� Allocate function model to activity

� Define rule groups

� Allocate activities to rule groups

� Maintain outline agreement with rule group

� Allocate individual contract to outline

agreement

(C) SAP AG IUT230 11-82

SAP AG 1999

Customer Include

� The following fields have been added to the transparent table EVER:

� Outline agreement

� Valid from

� Valid to

� The current outline agreement is displayed

� This enables you to view the allocations outside transaction EAOUTL

(C) SAP AG IUT230 11-83

SAP AG 1999

Procedure 1

� Create structures

� Analyze industry-specific outline agreements and their structure.

� Adjust:

� Completeness controls

� Summarization routines

� Rule set

(C) SAP AG IUT230 11-84

SAP AG 1999

All templates in development class

EE20_CROSS_CONTRACT_BILLING

are available as of mySAP Utilities 4.61 for IS-U/CCS

Procedure 2

� Define billing master data

� Create the necessary reports using the sample function modules supplied

(C) SAP AG IUT230 11-85

SAP AG 1999

A modular system provides the required level of flexibility

� All the functions are distributed across different function modules

� SAP delivers the standard functions

� There are two procedures for multiple-contract billing:

� Joint blocking based on the total consumption

� X % discount for individual contract and Y % discount for outline

agreement at the end of the year

� New procedures are being planned

� Customers can integrate their own functions by:

� Copying or changing existing function modules, or creating new ones

� Developing separate multiple-contract billing procedures

Multiple Contract Billing: Modular System

(C) SAP AG IUT230 11-86

SAP AG 1999

Dataentry

Datacom-pression

Completecontrol

Dataexchange

BillingLockDataexchange

Unlock

SAPStandard

Customer-defined

Multiple-Contract Billing

(C) SAP AG IUT230 11-87

SAP AG 1999

Billing outline agreements

Billing individual contracts

Bill printoutCreating meter reading contract

Point 01After the meter reading results have been entered and before the individual contracts have been billed.

Point 02After the individual contracts have been billed and before the outline agreements have been billed.

Point 03Discounts granted provisionally are checked and, if necessary, corrected.

Meter reading

Action Points

The billing process offers several action points

(C) SAP AG IUT230 11-88

SAP AG 1999

Billing Program Flow

� Reads all the individual contracts for the outline agreement

� Completeness and status control

� Simulates individual contracts for creating cumulated

values

� Total energy, no. of contracts...

� Bills individual contracts

� Terms of contract based on cumulated values

The billing program uses the standard IS-U program and user

exits. It executes the following:

(C) SAP AG IUT230 11-89

SAP AG 1999 SAP AG

� The system supports the different franchise fee procedures.

� Gas billing in the IS-U system represents different gas procedures.

� Assigning reference values enables you to bill lighting consumption.

� You can use the IS-U data model and the universal billing engine for new types of billing in the deregulated utilities market.

� IS-U provides archiving tools for large quantities of data.

� IS-U provides methods for special types of billing.

Special Billing Features: Unit Summary



� Sales Statistics

� Data Warehouse Concepts

� Utility Information System (UIS)

� SAP Business Information Warehouse (BW)

Sales Statistics




� Describe the Data Warehouse concept

� Describe the information from the application to the SAP Business Information Warehouse (BW)

Sales Statistics: Unit Objectives


SAP AG 1999

MaintainBillingMaster Data

Use of Ratesin the

Master DataInvoicing

BillPrintout

Billing











� The scenario in this unit deals with sales statistics. You will evaluate billing quantities and revenues

using the Business Information Warehouse (BW).

� The appendix also contains the procedure with the Logistics Information System (LIS).


SAP AG 1999

Sales Statistics: 1





� Customizing


SAP AG 1999

OnlineTransactionProcessing

DATAWARE-HOUSE

OLTP

OLAP

Analysis Tools

OnlineAnalytical

Processing

Summarized Information

Integrated Application Modules

ExternalData

Sales &Distribution Finance

IS-U/CCSMaterial

Management

Data Warehouse Concepts

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


SAP AG 1999

CentralUpdating

Online/Background

Logistics DataLogistics Data

WarehouseWarehouse

PlanningCopy

Management

External DataExternal DataInternal DataInternal Data

(R/2 (R/2 -- R/3)R/3)

StandardAnalyses

FlexibleAnalyses

Logistics Information System (LIS)

� As well as automatically updating the logistics data basis based on an application, you can collect SAP

data or data from external systems (such as SAP R/2). A range of options for regenerating statistical data

is also available to you in the various information systems. In some areas, a link between R/2 and R/3

already exists.

� Additional information that was saved in the information structure during the planning function is also

added to the LIS data basis.

� Using the Copy Management functions, you can reorganize, extend, or further summarize information

structure data.

� When you analyze LIS information structures, flexible analyses allow you to add additional data from

the SAP system, if required.


SAP AG 1999

LISLISLIS

Information LibraryInformation Library

PP-ISPPPP--ISISSISSISSIS PURCHIS

PURCPURC

HISHISINVCOINVCOINVCO

UISUISUISQM-ISQMQM--ISIS PM-ISPMPM--ISIS WM-ISWMWM--ISIS

R1

:

R4

1988------------------

1994------------------

Purchase

Requisition Invoice

Projects PMOrder

SDOrder

PPOrder


� A range of application-based information systems with a common user interface and similar basic

functions are provided in SAP Logistics.

Data is kept identically in all information systems in Logistics. A range of special tools and methods

underline the typical Data Warehouse character of the LIS.

� The following information systems are available in Logistics:

UIS Utility Information System

SIS Sales Information System

PURCHIS Purchasing Information System

INVCO Inventory Controlling

WMIS Warehouse Management Information System

PPIS Production Planning Information System

QMIS Quality Management Information System

PMIS Plant Maintenance Information System

RIS Retail Information System


SAP AG 1999

Business Information Warehouse (BW)

� The SAP Business Information Warehouse (BW) is a mySAP.com business component that enables

you to extract and analyze data from live business applications (OLTP systems). In addition to OLTP

systems such as R/3 and SAP BBP (business-to-business procurement: e-commerce business processes

that enable employees to procure goods and services directly from other providers), other external data

sources, such as databases or online services, can be integrated. OLTP stands for Online Transaction

Processing.

� The SAP Business Information Warehouse supports Online Analytical Processing (OLAP) and is

particularly useful for processing large volumes of live and historical data.

� SAP BW contains all the necessary metadata for everyday business processes, including InfoSources,

InfoObjects, InfoCubes, and standard reports, transfer structures for all supported releases, as well as

communication structures and update rules for every InfoCube. These elements are part of a "ready-to-

go" strategy, which supports automatic data transfer with immediate analysis after the system has been

installed and the source system named.

� SAP BW requests the application data at regular intervals from the assigned source system (pull

mechanism). For this purpose, the back-end systems contain 'extractors' that collect data and supply it to

the SAP Business Information Warehouse.


SAP AG 1999

Sales Statistics: 2





� Customizing

(C) SAP AG IUT230 12-10

SAP AG 1999

AnalysesAnalyses

PlanningPlanning

Communication

Structures

Communication

StructuresApplicationApplication

Business Transactions

Invoicing

Invoicing Reversal

IS-U

UpdateUpdate

S440

S441

S449

Update

Rules

UpdateRules

Info StructuresInfo Structures

ISIS--UU

BillingBilling

DocumentDocument

Event

Information Flow/Concept

� For certain business transactions in IS-U (such as invoicing, invoicing reversal), an index is generated,

which specifies that the billing document is to be copied to the UIS.

� The 'VU' application is allocated to the UIS. The communication structure for IS-U is called

MCVU_ESTA.

� You use the update rules to define which fields in which information structures are to be filled with

which values.

� The LIS provides you with extensive analysis tools.

� You do not require planning within the UIS.

(C) SAP AG IUT230 12-11

SAP AG 1999

IndustryIndustry

CharacteristicsCharacteristics157 005

398

Sales

Time ReferenceTime ReferenceTime Reference

RateRateNet

Amount

NetNet

AmountAmountEnergy

Amount

EnergyEnergy

AmountAmountDemand

Amount

DemandDemand

AmountAmountBilled

Amount

BilledBilled

AmountAmount

MonthMonthMonth

19991999

Jan Feb Mar Apr MayJun Jul . . .. . .. . .

Format of Information Structures

Key FiguresKey Figures

� The information structures form the basis for the Utility Information System. They consist of special

statistics tables that contain basis data from various applications. The data is continuously collected and

updated by the system.

� 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

the UIS, 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.

(C) SAP AG IUT230 12-12

SAP AG 1999

Billing

Amount

April 1999 Bill 4711

1000 kWh

Jan Feb Mar Apr

ABAB

Jan Feb Mar Apr

BUDATBUDAT

Billing Document Invoiced

Billing

Amount

Period Determination

� The system determines the period using the source date.

� You can choose various 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 the consumption quantities are moved to the posting date.

(C) SAP AG IUT230 12-13

SAP AG 1999

10.000 20.000 >

>

2000

1000

BillingAmount

Net

Amount2.0

1.0

0.008 09 10 11 12 01 02 03 04

Billing Quantity

Net Amount

BillingAmount

Rate Categories

A B C

Correlation

ABC Analysis

Cumulative

Frequency Curve

No. ofRate Categories

Billing Document10.000 20.000 30.000 40.000 >

Classification

Billing Quantity

No. ofMonths

90.000

40.000

1 2 3 4

Dual Classification

04.1999 05.1999

8.000

4.000

12.000

10.000

E1_1

E1_2

. . . . . . . . 03.2000

. . . . . . .

. . . . . . .

20.000

5.000

Rate

Time Series

Graphics

� Additional statistics functions are available for displaying or analyzing data at every list level. For each

drilldown, all the key figures for each characteristic value are displayed. Using a cumulative frequency

curve, you can graphically display how a cumulated key figure value is distributed over the set of

existing values for characteristics. The cumulative curve is graded depending on how the underlying list

is represented, that is, either in percentage or absolute values.

� You can use a correlation curve to identify the dependencies between two or more key figures. The

system takes into account the sort sequence of the underlying list when it generates the correlation curve.

For correlation, the key figure values are scaled to a range of 0 to 1. If several key figures are being

correlated, the curves can be graded either above each other or separately.

� In an ABC analysis, the values of a characteristic (such as rate category) and a certain key figure (such

as billing quantity) are compared with the aim of creating a triple classification. The class limits can be

defined according to characteristics or key figures using various strategies. They can be defined as

percentage or absolute values. The result is a cumulative curve with an additional triple classification.

The segment sizes correspond to the presettings you made when choosing the strategy. You can display

in a list or graph how characteristics and key figures are related to individual segment levels either

absolutely per segment or cumulated for all segments. Depending on the settings you select, the results

of the ABC analysis will be displayed initially as a graphic or a list.

� You can also gain an overview of the characteristic values with reference to a certain key figure using

classification. Note that you can define up to six classes. The class limits can be individually defined.

Everything is displayed in a combination of lists and presentation graphics, where the order is

predefined.

(C) SAP AG IUT230 12-14

� In dual classification, you can classify characteristic values with reference to two key figures. Navigation

and presentation options are the same as for classification.

(C) SAP AG IUT230 12-15

SAP AG 1999

Sales Statistics: 3





� Customizing

(C) SAP AG IUT230 12-16

SAP AG 1999

BusinessInformationWarehouseServer

Administrator Workbench

OLAP ProcessorOLAP Processor

Staging EngineStaging Engine

InfoCubesInfoCubesMeta DataRepositoryMeta DataRepository

ODSODS

BusinessExplorer

WebReporting

Architecture

(C) SAP AG IUT230 12-17

SAP AG 1999

Query

Workbook

Transformation

InfoObject Regional StructureRegional StructureRegional Structure

Business PartnerBusiness Partner

InfoSource

Extractor

InfoCube

Best-Practice ModelBest-Practice Model

44 Key figures101 Characteristics

20

20 Transaction data48 Master data

38

38

20 for infoCubes48 for infoObjects

Indiv

idual

izat

ion

Standar

ds

Business Content for the Utilities Industry

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

� InfoCubes

Central objects on which analyses are based.

A self-contained dataset (for example, of a business area) that is filled and aggregated according to

defined transformation rules.

� Query

A configurable view of the data in an InfoCube.

� Workbook

A presentation layer of queries that can be stored as a self-contained dataset.

(C) SAP AG IUT230 12-18

SAP AG 1999

Time-Based!

Stock

Change in Stock

Installation Stock Statistics

� The stock statistics for an installation are one of many statistics for the IS-U data model. After the initial

stock build-up, all changes to the master data are transferred to the BW.

� Both the changes in stock and stock key figures display the changes:

Stock changes = Stock increase/decrease within a month

Stock = Number of stocks at a particular point in time

� Since stocks in the BW are kept historically, the drilldown and selection must be made according to a

particular time/period.

This enables you to evaluate the stock at any time (level of detail: month).

(C) SAP AG IUT230 12-19

SAP AG 1999

Extractors/DataSources

� Additional fields available

Check dataSources in OLTP

� Application component 0IS_UC for transaction

DataSources

Delta procedure is used for every transaction DataSource

� Application component 0IS_UC-IO for master data texts and attributes

� All IS-U-related DataSources begin with 0UCxxx

� To be able to describe the supplied BW content in more detail, you must also analyze the loaders

(extractors) with the allocated extract structures. Most of the IS-U-specific extractors can extract more

information (fields) in the BW than are actually used in the BW.

� Changes to the master data are recorded automatically and updated to the BW during the next load

process (extraction).

(C) SAP AG IUT230 12-20

SAP AG 1999

Update Mode: 1

� Update Modes

� Full Update

� Delta update, for example, initialization, Delta, and repeat of the last

Delta update (if the last one was loaded incorrectly).

� Full Update

� Transfers all the data to a specified selection, selection can be

changed.

� No two-way dependencies with other updates modes

� There are different methods of extracting data from the OLTP to the BW. A distinction is made here

between a full update and a delta update. This is specified when the data source (load program) is

defined.

� The data to be loaded is selected on the BW side.

(C) SAP AG IUT230 12-21

SAP AG 1999

Update Mode: 2

� Delta Initialization

� Consistency check of the initialization process

� Initialisation possible in the updating system?

� Extraction of all data according to the selection

� Other initializations are only used to enhance the relevant data for

the Delta upload

� Parallel initialisations boosts performance

� More selections can be made later

(C) SAP AG IUT230 12-22

SAP AG 1999

Update Mode: 3

� Delta Request

� Extraction of all data changed since the last Delta request (total

of all initial selections)

� Delta request is only possible if the initial request was

successful

� Repetition of the previous Delta request

� Necessary if the last Delta request was not carried out properly

(C) SAP AG IUT230 12-23

SAP AG 1999

Old Smith 01/01/1999 North 100

#Delta# Smith 10/15/1999 North -100

New Smith 10/15/1999 South 120

BW

BW

Transaction Data

� To ensure that updates in aggregated databases run properly, you must make a reverse posting for the old

dataset, and a 'standard' posting for the current dataset.

(C) SAP AG IUT230 12-24

SAP AG 1999

Master Data

� Changes overwrite old entries. Only the current data has to be updated.

� Some objects are critical for performance (material, business partner, ...). Therefore, only changes are updated to the BW.

(C) SAP AG IUT230 12-25

SAP AG 1999

1. Initial Request from BW

1. all the data available within the selection is extracted

2. Delta Request from BW

1. all changes since the last Delta request

Master Data Tables

Master Data Tables

1.

Delta

Queue

Delta

Queue2.

Changes to objects

Stock Statistics

(C) SAP AG IUT230 12-26

SAP AG 1999

1.

2.Process is terminated

Transaction Statistics

� Initial Request from BW

� No initial data available -> Initialization activated process entry

� Delta Request from BW

� all processes entered are extracted

Delta

Queue

Delta

Queue

(C) SAP AG IUT230 12-27

SAP AG 1999

Billing

Documents and Master Data

Billing

Documents and Master Data

2.

1.

Sales Statistics

� Initial Request from BW

� all the bills available within the selection are extracted

� Delta Request from BW

� All new and reversed bills since the last Delta request

(C) SAP AG IUT230 12-28

SAP AG 1999

Document

Document

Document

� Checklist

Initialization process finished and status OK?

Initialization process carried out with complete selection?

Delta available?

Last Delta finished without errors?

� Checklist

Initialization process finished and status OK?

Initialization process carried out with complete selection?

Delta available?

Last Delta finished without errors?

Why is Data Not Updated?

(C) SAP AG IUT230 12-29

SAP AG 1999

Sales Statistics: 4





� Customizing

(C) SAP AG IUT230 12-30

SAP AG 1999

S T A T I S T I C S G R O U P SS T A T I S T I C S G R O U P SS T A T I S T I C S G R O U P S

Statistics Groups forStatistics Groups forContractsContracts

Rate

Categories

Rate

Categories

Standard Customers

NonresidentialCustomerskunden

Division Contract Rate Cat. Update Group

01 ’ ’ ‘‘ 0101 SISU

01 0101 0101 Z00001

Residential Customers 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 "Nonresidential 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.

(C) SAP AG IUT230 12-31

SAP AG 1999

Statistics GroupStatistics Group

Update Group SISUUpdate Group SISUUpdate Group SISU

Customer

Schultz

CustomerCustomer

SchultzSchultz

Update Group ZINDUpdate Group ZINDUpdate Group ZIND

Customer

SAP

CustomerCustomer

SAPSAP

Update RulesUpdate Rules Update RulesUpdate Rules

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 Group SISU

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

(C) SAP AG IUT230 12-32

SAP AG 1999

E1 SchemaRate Var.Prog. Stats Grp Quantities

Rate 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

WWABRWWABR

WWLEIWWLEI COCO--

PAPA

WWABRWWABR

WWLEIWWLEI

Billing DocumentBilling Document CO-PA Statistical

Data

CO-PA Statistical

DataCO-PA Actual Data

(yes/no)

CO-PA Actual Data

(yes/no)

Statistics Groups: Quantities

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

(C) SAP AG IUT230 12-33

SAP AG 1999

E1 SchemaRate Var.Prog. Stats Grp: Amount

Rate 1


- Step 2 VarProg. B 000002. . .

Rate 2



NETTOBTR

St. gr. '000001'

NETTOBTR

St. gr. '000001' COCO--

PAPA

VVNETVVNET

VVARBVVARB

VVLEIVVLEI

COCO--

PAPA

VVNETVVNET

VVARBVVARB

VVLEIVVLEI

Billing DocumentBilling Document CO-PA Statistical

Data

CO-PA Statistical


(always transferred)

CO-PA Actual Data


Statistics Groups: Amounts

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

(C) SAP AG IUT230 12-34

SAP AG 1999 SAP AG

� Sales statistics data is kept in a data warehouse.

� The Utility Information System (UIS) is a component of the Logistics Information System (LIS).

� 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


SAP AG 1999

Sales Statistics: LIS (Appendix A)





� Logistics Information System (LIS)


� Information Flow

� Tools

� Standard Analyses

� Flexible Analyses

� CO-PA

� Planning/Unbilled Revenue

Reporting

Sales Statistics: Contents




� Describe the Data Warehouse concept

� Explain how the UIS is embedded in the LIS

� Describe the flow of information from the

communication to the information structures

� Recognize the difference between standard and flexible analyses

� Describe the interface with CO-PA

� Outline the concept of unbilled revenue reporting

Sales Statistics: Unit Objectives


SAP AG 1999

MaintainMaintain

BillingBilling


Use of Ratesin the

Master Data

Use of Ratesin the


BillPrintout

BillPrintout

BillingBilling











� The scenario in this unit deals with sales statistics. You will evaluate billing quantities and revenues

using the UIS (LIS).

� We will also discuss unbilled revenue reporting.


SAP AG 1999

Sales Statistics: 1





� Customizing


SAP AG 1999

EWS EWS Early Warning SystemEarly Warning System

Flexible AnalysisFlexible Analysis

Standard

Analysis

Standard Analysis

AdvancedAnalysis Techniques

Advanced

Analysis Techniques

• Selection Versions• Authorizations

• Selection Versions• Authorizations

FI

PPMMExternal

Data SD

Data Warehouse Concepts: Overview


SAP AG 1999

OnlineTransactionProcessing

DATAWARE-HOUSE

OLTP

OLAP

Analysis Tools

OnlineAnalytical

Processing

Summarized Information

Integrated Application ModulesIntegrated Application Modules

ExternalData

Sales &Distribution Finance

IS-U/CCSMaterial

Management

Data Warehouse Concepts

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


SAP AG 1999

CentralUpdating

Online/Background

Logistics DataWarehouse

Logistics DataWarehouse

PlanningCopy

Management

External DataExternal DataInternal Data

(R/2 - R/3)

Internal Data(R/2 - R/3)

StandardAnalyses

FlexibleAnalyses


� As well as automatically updating the logistics data basis based on an application, you can also collect

SAP data or data from external systems (such as SAP R/2). A range of options for regenerating statistical

data is also available to you in the various information systems. In some areas, a link between R/2 and

R/3 already exists.

� Additional information that was saved in the information structure during the planning function is also

added to the LIS data basis.

� Using the Copy Management functions, you can reorganize, extend, or further summarize information

structure data.

� When you analyze LIS information structures, flexible analyses allow you to add additional data from

the SAP system, if required.


SAP AG 1999

LISLISLIS

Information LibraryInformation Library

PP-ISPPPP--ISISSISSISSIS PURCHIS

PURCPURC

HISHISINVCOINVCOINVCO

UISUISUISQM-ISQMQM--ISIS PM-ISPMPM--ISIS WM-ISWMWM--ISIS

R1:

R4

1988

------------------

1994

------------------

Purchase

Requisition Invoice

Projects PMOrder

SDOrder

PPOrder


� A range of application-based information systems with a common user interface and similar basic

functions are provided in SAP Logistics.

Data is kept identically in all information systems in Logistics. A range of special tools and methods

underline the typical Data Warehouse character of the LIS.

� The following information systems are available in Logistics:

UIS Utility Information System

SIS Sales Information System

PURCHIS Purchasing Information System

INVCO Inventory Controlling

WMIS Warehouse Management Information System

PPIS Production Planning Information System

QMIS Quality Management Information System

PMIS Plant Maintenance Information System

RIS Retail Information System

(C) SAP AG IUT230 13-10

SAP AG 1999

Sales Statistics: 2






� Tools



� CO-PA

� Planning/Unbilled Revenue Reporting

(C) SAP AG IUT230 13-11

SAP AG 1999

AnalysesAnalyses

PlanningPlanning

Communication

Structures

Communication

StructuresApplicationApplication

Business Transactions

Invoicing

Invoicing Reversal

IS-U

UpdateUpdate

S440

S441

S449

Update

Rules

UpdateRules

Info StructuresInfo Structures

ISIS--UU

BillingBilling

DocumentDocument

Event

Information Flow/Concept

� For certain business transactions in IS-U (such as invoicing, invoicing reversal), an index is generated,

which specifies that the billing document is to be copied to the UIS.

� The 'VU' application is allocated to the UIS. The communication structure for IS-U is called

MCVU_ESTA.

� You use the update rules to define which fields in which information structures are to be filled with

which values.

� The LIS provides you with extensive analysis tools.

� You do not require planning within the UIS.

(C) SAP AG IUT230 13-12

SAP AG 1999

� Communication Structure

� Dictionary structure for transferring data from the applications to

the LIS.

� Field Catalog

� Group of fields selected from the fields of a communication

structure from a business perspective.

� Information Structure

� Data basis of the LIS. Transparent database tables constructed

using the field lists in the field catalogs.

� Update Rules

� Precise description of when and how an information structure is

supplied with data.

Elements of the LIS

(C) SAP AG IUT230 13-13

SAP AG 1999

Data RetrievalSAP (batch job)

Data RetrievalCustomer (user-exit)

Billing Documents

IS-U Database

SAP Fields Customer Fields

Communication Structure

Information Structures

UIS

Field Catalogs

Key Figures

ERCHERCH

ERCHZERCHZERCHCERCHC

Master Data

External DataExternal Data

EventEvent

Su

mm

ari

zati

on

S440S440 S441S441 S449S449

Key FiguresTime Reference

Charac-teristics

Time Reference

Charac-teristics

Information Flow / Technical View

(C) SAP AG IUT230 13-14

SAP AG 1999

IndustryIndustry

Characteristics Key FiguresCharacteristics Key FiguresKey Figures157 005

398

Sales

Time

Reference

Time Time

ReferenceReference

RateRateNet

Amount

NetNet

AmountAmountDemand

Amount

DemandDemand

AmountAmountDemand

Amount

DemandDemand

AmountAmountBilled

Amount

BilledBilled

AmountAmount

MonthMonthMonth

19991999

Jan Feb Mar Apr MayJun Jul . . .. . .. . .

Format of Information Structures

� The information structures form the basis for the Utility Information System. They consist of special

statistics tables that contain basis data from various applications. The data is continuously collected and

updated by the system.

� 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

the UIS, 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.

(C) SAP AG IUT230 13-15

SAP AG 1999

Communication StructureCommunication Structure

MCVU_ESTA

UIS Field CatalogsUIS Field CatalogsUIS Field Catalogs

-RATE _NETAMT

...- DIVISION

...- BILLQTY

...... ......

...

......

Key Figures

VUK1 Amounts MCVU_ESTA-NETTOBTR

MCVBAP-NETWR

VUM1

Name

...

Source Field

MCVU_ESTA-TARIF

Ref. Field

Characteristics

Field Catalog

Characteristics

Pick Up

Field Catalogs

� Field catalogs contain a two references for each field entry:

- A reference to source fields is created so that the information can be transferred directly from the

communication structure.

- The fixed reference fields define the technical characteristics of the following information structure

fields.

� You can also create your own field catalogs, which form the basis for creating information structures.

(C) SAP AG IUT230 13-16

SAP AG 1999

Industry Rate Division Consumption Revenue

Characteristics Key Figures

Definition of Information Structure

Field Catalogs (characteristics/key figures from the list of fields

in the communication structure MCVU_ESTA)

Name

...

...

Application

VUDescription

CharacteristicsKey Figures

Transp. Tables S440 - S449

INDUSTRY RATE DIVISIONDDICDDIC

Pick U

p

Genera

tion

Periodi-

city

?

Setting Up an Information Structure

� When you create your own information structure, you provide all the necessary information to

automatically generate a DDIC structure (database table).

� Simply copy the required characteristics and key figures from field catalogs and define the units for the

various key figures.

(C) SAP AG IUT230 13-17

SAP AG 1999

Info Structure: S440

Characteristics

DivisionRate

.

.

.

Key Figures

Invoiced amountBilling quantity

.

.

.

Definition Saved in TablesDefinition Saved in Tables

Standard Analysis

S440S440 S440ES440E

Dependent Objects:

Customer

Material

Tools

Screens

GenerationGenerationGeneration

SaveSaveSave

Generating Information Structures

� When you save an information structure, you assign a development class and a transport request to it, in

which the defining table entries are logged.

� Warning: If you create an info structure locally and do not assign a development class to it, you cannot

transport it into another system. The same applies to any updates made to that info structure.

� Once you have created an info structure, it is available in all clients of that system.

� Dependent objects, such as standard analyses, planning programs, etc. are only generated as they are

needed.

� An info structure must be assigned a name in the range from S501 toS999. The database table is

generated with the same name. This avoids conflicting names during transports.

� Info structures created in a system cannot be overwritten by an import, because the transport system does

not allow objects to be overwritten in their original system.

� Field catalogs and update rules can also be automatically transported.

(C) SAP AG IUT230 13-18

SAP AG 1999

Update for Billing QuantityUpdate for Billing QuantityUpdate for Billing Quantity

Info Structure

Update Group

Key Figures............

....

....

Rules: Key figureRules: Key figure

S440

SISU

Billing Quantity

S440S440

Key Figure

Cumulative

Invoicing

AB

I_ABRMENGE

...

...

Update Type

Event

Date Field

Source Field

Condition

Formula

Update Rules: Key Figures

� At least one update rule is constructed for each key figure in the update definition of an information

structure, unless the key figure has to be calculated dynamically in the standard analysis.

� If a source field was entered in the field catalog for this key figure, then this entry is proposed by the

system.

The key figure is automatically copied from this field in the communication structure during updating.

It is also possible to define various update types and links to transactions (events) for each key figure in

the updating module.

(C) SAP AG IUT230 13-19

SAP AG 1999

Info Structure

Update Group

Key Figures............

....

....

S440

SISU

Billing Quantity

Updating for Billing QuantityUpdating for Billing QuantityUpdating for Billing Quantity

...

Key FigureKey Figure

Characteristics

Division

Rate Category

Rate

Rules: Characteris

tic

Rules: Characteris

tic

Source Table

MCVU_ESTA

MCVU_ESTA

MCVU_ESTA

MC...

Source Field

DIVISION

RATECAT

RATENO

...

Update Rules: Characteristics

� When you are defining an update rule, it is important to define the combination of characteristics with

which the corresponding key figure is to be saved. This means that the options for fine-tuned control of

updating can vary considerably.

(C) SAP AG IUT230 13-20

SAP AG 1999

Billing

Amount

April 1999 Bill 4711

1000 kWh

Jan Feb Mar Apr

ABAB

Jan Feb Mar Apr

BUDATBUDAT

Billing Document Invoiced

Billing

Amount

Period Determination

� The system determines the period using the source date.

� You can choose various 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 the consumption quantities are moved to the posting date.

(C) SAP AG IUT230 13-21

SAP AG 1999

Update ParametersInfo Str. Description

S440 Rate statisticsS441 Industry statisticsS501 User-defined

Statistics...

S501 User-Defined Statistics

Period split

Posting period

Month

Week

Day

Updating

No update

Synchronous update

Asynchronous update

Document

Document

Document

S440S440

S441S441

S...S...

Activating Updating

� You have to activate updates to standard and user-defined information structures.

� You must define a period split and update type when you activate updates.

� By specifying a period split, you define how often the data is cumulated. As well as being cumulated on

a daily, weekly, or monthly basis, the data can also be summarized in accordance with the posting

periods that are using in financial accounting.

� You can choose to update information structures at the same time as the billing document is posted

(synchronously), or you can choose asynchronous updating. We recommend using asynchronous

updating for sales statistics, due to the large amount of data being updated.

(C) SAP AG IUT230 13-22

SAP AG 1999

S T A T I S T I C S G R O U P SS T A T I S T I C S G R O U P SS T A T I S T I C S G R O U P S

Statistics Groups forStatistics Groups for ContractsContractsRate

Categories

Rate

Categories

Standard Customers

Nonresidentialvertrags-Customers

Division Contract Rate Cat. Update Group

01 ’ ’ ‘‘ 0101 SISU

01 0101 0101 Z00001

Residential Customers

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 the second contract screen.

� The following are examples of different updates:

- Rate categories: "Residential customers" and "Nonresidential customers".

- Contracts: "Standard customers" and "Individual statistics". For certain contracts (such as large

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.

(C) SAP AG IUT230 13-23

SAP AG 1999

E1 SchemaRate Var.Prog. Stats Grp Quantities

Rate 1


- Step 2 VarProg. B 000002. . .

Rate 2



MCVU_ESTAMCVU_ESTA

Communications

Structure

I_ABRMENGEI_LEIMENGE

Communications

Structure

I_ABRMENGEI_LEIMENGE

COCO--

PAPAUISUIS

WWABRWWABR

WWLEIWWLEI COCO--

PAPA

WWABRWWABR

WWLEIWWLEI

Sales StatisticsSales Statistics CO-PA Statistical

Data

CO-PA Statistical


(yes/no)

CO-PA Actual Data

(yes/no)

Statistics Groups: Quantities

� You enter the statistics group for quantities in the billing schema for each schema step. The statistics

group makes it easier to transfer data to the UIS and CO-PA. By using statistics groups, you can in most

cases avoid using user-exits.

� SAP delivers the statistics groups 000000 to 000002 with the system as standard.

� In the statistics group, you define into which key figures in the UIS communication structure

MCVU_ESTA the quantity is copied. If you use the statistics group 000000, the system will not update

the quantity into the UIS. You can also copy the quantity to several key figures.

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

(C) SAP AG IUT230 13-24

SAP AG 1999

E1 SchemaRate Var.Prog. Stats Grp: Amount

Rate 1


- Step 2 VarProg. B 000002. . .

Rate 2



MCVU_ESTAMCVU_ESTA

Communications

Structure

NETTOBTRARBEITBTR

LEISTBTR....

Communications

Structure

NETTOBTRARBEITBTR

LEISTBTR....

COCO--

PAPAUISUIS

VVNETVVNET

VVARBVVARB

VVLEIVVLEI

COCO--

PAPA

VVNETVVNET

VVARBVVARB

VVLEIVVLEI

Sales StatisticsSales Statistics CO-PA Statistical

Data

CO-PA Statistical



CO-PA Actual Data


Statistics Groups: Amounts

� You enter the statistics group for amounts in the billing schema for each schema step. The statistics

group makes it easier to transfer data to the UIS and CO-PA. By using statistics groups, you can in most

cases avoid using user-exits.

� SAP delivers the statistics groups 000000 and 000001 with the system as standard.

� In the statistics group, you define into which key figures in the UIS communication structure

MCVU_ESTA the amount is copied. If you use the statistics group 000000, the system will not update

the amount into the UIS. You can also copy the amount to several key figures.

(C) SAP AG IUT230 13-25

SAP AG 1999

Statistics GroupStatistics Group

Update Group

SISU

Update GroupUpdate Group

SISUSISUUpdate Group

Z00001


Z00001Z00001

Customer

C

CustomerCustomer

CCCustomer

A

CustomerCustomer

AA

S501-Field 3S501-Field 3S501-Field 1S501-Field 2S501-Field 3

S501-Field 1S501-Field 2S501-Field 3S501-Field 2S501-Field 2

S501-Field 1S501-Field 3

S501-Field 1S501-Field 3

Update Group

SISU


SISUSISU

Customer

B

CustomerCustomer

BB

UpdateUpdateRulesRules



1.

2.

3.


Billing

Document

Division 01

Statistics Group ‘ ‘Contract

Statistics Group 01Rate Category

Update group SISUBilling Line Item

Overview of Updating

� During updating, the division and the statistics group contract are taken from the contract. The statistics

group rate category is taken from the rate category.

� Using this combination, the system determines the relevant update group. The update group controls

which fields in which information structures are filled with which field contents.

� The update group determined is saved in the billing document.

(C) SAP AG IUT230 13-26

SAP AG 1999

UIS Customizing : Updating - Precise DefinitionUIS Customizing : Updating - Precise Definition

EditorEditor

....................................................................

...

FORMULA_VALUE =... MCVU_ESTA-ABRMENGE* (-1)....

EditorEditor

....................................................................

IF MCVU_ESTA-MENGESTREL = ' '... RETURNCODE = 4.... ENDIF...

Relevance for statistics

Quantity * (-1)

...

900...

...

900...

� InvoicingKey Figure Formulas:

Conditions:

Formulas and Conditions

� Using formulas and conditions, you can influence how the data is updated. For example, in certain cases

you would like to have negative quantities, then you can use a formula to show the field MCVU_ESTA-

ABRMENGE as a negative value. When an invoicing process is reversed, the key figures are

automatically interpreted negatively.

� The names of formulas and conditions consist of three-digit numbers. The SAP namespace lies between

1nn and 5nn.

(C) SAP AG IUT230 13-27

SAP AG 1999

IS-U

Standard Standard

AnalysisAnalysis

Comm.StructureComm.Structure

Copy Management:

- Import External Data

- Methods of Flexible Transformation

Copy Management:

- Import External Data

- Methods of Flexible Transformation

Derive

Communication

Structures

(ESTA0001)

Authorization

Check

Authorization

CheckFormulas and

Conditions

Formulas and

Conditions

Oper.

System

Derive and

Calculate

Key Figures

Derive and

Calculate Key Figures

User Exits in UIS

Info StructureInfo Structure

� The user exit used to derive the MCVU_ESTA communication structure is called ESTA0001.

� The other user exits are functional enhancements to the standard LIS component. You will find them in

the IMG for LIS under 'Develop Functional Enhancements'.

(C) SAP AG IUT230 13-28

SAP AG 1999

Sales Statistics: 3






� Tools



� CO-PA


(C) SAP AG IUT230 13-29

SAP AG 1999

Update LogUpdate Log

Update log of the last update run:

Update simulation of a billing document:

Document

Document Update AnalysisUpdate Analysis

Update LogUpdate Log Update AnalysisUpdate Analysis

Update Log and Simulation

� An update in the UIS can be logged in the system for each user and business transaction. To set the

update log, you must set the 'MCL' parameter in the user master record. The system only saves the most

recent log of an update run. The next UIS update overwrites the previous log for the respective user. For

performance reasons, you should only set up this type of update control in the test system.

� If you wish to check updating of documents that have already been posted, for example because changes

were made to Customizing, you can generate update logs for any billing documents without the

information structures being updated. This allows you to check how a document would have been

updated to the information structures using the new Customizing settings. You can use this type of

update control in the production system.

� You can go to an update analysis from the update log. The update analysis provides additional

information on the update definition of the information structures concerned. For example, it analyses

update group determination and provides information on the formulas used.

(C) SAP AG IUT230 13-30

SAP AG 1999

Document

Document

Document

S440S440

S441S441

S...S...

� Checklist

Does the billing document contain information

relevant to statistics?

Did the system determine an update group for the

billing document?

Did the system generate the update program

without any errors?

Did you activate updating for this information structure?

� Debugger

Update Check

Update Simulation

� Checklist

Does the billing document contain information relevant to statistics?

Did the system determine an update group for the

billing document?

Did the system generate the update program

without any errors?

Did you activate updating for this information structure?

� Debugger

Update Check

Update Simulation

Why is Data Not Updated?

� If the system does not update data in your information structure, debugging tools are available in the LIS

to help you analyze the problem in detail. You will find these tools in Customizing for the LIS.

� For each document, you can check which information structures were affected by the update procedure

and which key figures were updated in what way.

(C) SAP AG IUT230 13-31

SAP AG 1999

Version & (2Version & (2

Version & (1Version & (1

Version 000

(actual data)

Version 000

(actual data)

1. Saving of actual dataRMCSISCP

2. Rebuilding of billingdocuments

REASTA02

3. Copying of rebuiltdata to actual data

RMCSISCP

Billing

documents

Billing

documents2

1

3

Rebuilding of Statistics Data

� Rebuilding the statistics data allows you to update documents that have already been posted.

� In the following situations, it is necessary to rebuild statistics data:

� Missing or incorrect Customizing (statistics and update groups)

� Information structures/updates were created or changed after production startup.

� You must start the programs for rebuilding statistics data in the background.

� If you are re-determining the update group, you must plan the order of the reports. You must save the

actual data before rebuilding the billing documents using the report REASTA02.

� The runtimes depend on general system performance and the number of billing documents.

(C) SAP AG IUT230 13-32

SAP AG 1999

Sales Statistics: 4






� Tools



� CO-PA


(C) SAP AG IUT230 13-33

SAP AG 1999

Bill

Rate Category: E1Doc. Date: 05/15/99

2000 kWh at 0.24 UNI 480

3200 kWh at 0.11 UNI 352

Info Structurein UIS

Info Structurein UIS

Rate Cat.E1E1E2

RateE1_1E1_2E2_1

Month05.9905.9905.99

Amount20003200

13000

Rate Category: E1Month: 05/99

Amount

2000

3200

Rate

E1_1

E1_2

From the Document to the Analysis

� When you start the update report, the key figures of the information structures are updated for the

corresponding combinations of characteristics

� If a data record with the corresponding combination of characteristics does not exist yet in the

information structure, the system creates a new data record and the characteristics and key figures are

entered (example: rate category E1, rate E1_1, month 05/99, billing quantity 2,000).

� If a data record with the corresponding combination of characteristics already exists in the information

structure, the key figures in the data record are increased or decreased by the corresponding value

(example: rate category E1, rate E1_1, month 05/99, old billing quantity 2,000 + billing quantity of

billing document 5,000 = new billing quantity 7,000).

� Using the analyses, you can then create lists for any combination of characteristics, based on the data in

the information structures.

(C) SAP AG IUT230 13-34

SAP AG 1999

Rate Statistics

Division BillingAmount

NetAmount

100 000

200 000

28 800

22 000

•

01

02

•


BillingClass

BillingAmount

NetAmount

60 000

40 000

14 400

4 400

0001

0002

Billing Class: 0001

Rate Cat. BillingAmount

NetAmount

20 000

25 000

48 00

60 00

•

02.1999

03.1999

•

Doubleclick

Doubleclick

Standard DrilldownDivision

Billing Class

Rate Cat.

...

Standard Drilldown

� There is a corresponding standard drilldown for each standard analysis.

� You can either set this standard drilldown generally for all users or user-specifically. To define the

drilldown, you can use all the characteristics and the periodicity of the corresponding information

structure.

� The uppermost level of the standard drilldown is always displayed initially in a standard analysis. By

double clicking on a characteristic, you display the next level for this characteristic and the result is

shown in a new list.

(C) SAP AG IUT230 13-35

SAP AG 1999


BillingClass

BillingAmount

NetAmount

60 000

40 000

14 400

4 400

0001

0002

Rate StatisticsSwitch Drilldown

Billing Class

Division

Rate

Statistical Rate

Rate Fact Group

Rate Category

Switch Drilldown

Month

Rate Fact Group: 0001

Month BillingAmount

NetAmount

20 000

25 000

4 800

6 000

•

02.1999

03.1999

•

Rate Statistics

Switch Drilldown

� Starting from any list of a standard analysis, the total values of the key figures can be differentiated

according to every possible characteristic in the standard analysis. You can achieve this by changing the

current drilldown using the 'Switch drilldown' function.

(C) SAP AG IUT230 13-36

SAP AG 1999

Rate Statistics

Rate Cat. BillingAmount

NetAmount

100 000

200 000

28 800

22 000

•

E1

E2

•

Edit.....

Comparisons.....

.....

Year/Previous Year Comparison: Billing Amount

Rate Category Prev.yr Current Difference %

..

E1E2

50 00050 000

30 00070 000

- 20 00020 000

40 %40 %

-+.. .. .. ..Key Figures Comparison: Energy Amount - Service Amount

Rate Cat. Energy amt Service amt Difference %

. . . . .

E1E2

30 00070 000

20 00070 000

- 10 0000 000

33 %0 %

-

Prev.yr/current

Two key figures

Comparisons

Edit

� At the individual drilldown levels, you have three options for comparing data:

� You can compare a key figure's current data with data from a planned version. However, this is not

supported in the UIS.

� You can compare the previous year's values for a key figure with the current data.

� You can compare the values of any two key figures.

� The system always displays the comparison data in separate windows. You can drill down the listed

characteristics further so that you have an even more precise view of the data according to different

characteristics.

(C) SAP AG IUT230 13-37

SAP AG 1999

Graphics

10.000 20.000 >

>

2000

1000

BillingAmount

Net

Amount2.0

1.0

0.008 09 10 11 12 01 02 03 04

Billing Quantity

Net Amount

BillingAmount

Rate Categories

A B C

Correlation

ABC Analysis

Cumulative

Frequency Curve

No. ofRate Categories

BillingAmount10.000 20.000 30.000 40.000 >

Classification

Billing Quantity

No. ofMonths

90.000

40.000

1 2 3 4

Dual Classification

04.1999 05.1999

8.000

4.000

12.000

10.000

E1_1

E1_2

. . . . . . . . 03.2000

. . . . . . .

. . . . . . .

20.000

5.000

Rate

Time Series

� Additional statistics functions are available for displaying or analyzing data at every list level. For each

drilldown, all the key figures for each characteristic value are displayed. Using a cumulative frequency

curve, you can graphically display how a cumulated key figure value is distributed over the set of

existing values for characteristics. The cumulative curve is graded depending on how the underlying list

is represented, that is, either in percentage or absolute values.

� You can use a correlation curve to identify the dependencies between two or more key figures. The

system takes into account the sort sequence of the underlying list when it generates the correlation curve.

For correlation, the key figure values are scaled to a range of 0 to 1. If several key figures are being

correlated, the curves can be graded either above each other or separately.

� In an ABC analysis, the values of a characteristic (such as rate category) and a certain key figure (such

as billing quantity) are compared with the aim of creating a triple classification. The class limits can be

defined according to characteristics or key figures using various strategies. They can be defined as

percentage or absolute values. The result is a cumulative curve with an additional triple classification.

The segment sizes correspond to the presettings you made when choosing the strategy. You can display

in a list or graph how characteristics and key figures are related to individual segment levels either

absolutely per segment or cumulated for all segments. Depending on the settings you select, the results

of the ABC analysis will be displayed initially as a graphic or a list.

� You can also gain an overview of the characteristic values with reference to a certain key figure using

classification. Note that you can define up to six classes. The class limits can be individually defined.

Everything is displayed in a combination of lists and presentation graphics, where the order is

predefined.

(C) SAP AG IUT230 13-38

� In dual classification, you can classify characteristic values with reference to two key figures. Navigation

and presentation options are the same as for classification.

(C) SAP AG IUT230 13-39

SAP AG 1999

Standard Drilldown1

Preselection of Key Figures

Default Value for Selection Period

2

3

4

Initial Graph: Yes/No

Drilldown Log in Page Header

Column Width for Char./Key Figure

Characteristic Display: Text/Key

User Settings per Analysis:User Settings per Analysis:

List Parameters

Settings

� You can make settings for each standard analysis that are valid for all users. In addition, you can make

user-specific settings that override the general settings.

� You can predefine the standard drilldown, a preselection of key figures, the default value for the

selection period, and various list parameters that define the list layout.

� You can later change the selection of key figures and the list layout again in the standard analyses.

(C) SAP AG IUT230 13-40

SAP AG 1999

EWS EWS Early Warning SystemEarly Warning System

SxxxSxxx

InfoStructures

Info

Structures

Purchasing ISPurchasing ISPurchasing IS

Sales ISSales ISSales IS

InventoryControlling

InventoryInventory

ControllingControlling

UISUISUIS

Production ISProduction ISProduction IS

Indicates Defined

Alarm Situation

Indicates Defined

Alarm SituationHighlights

Specific data

Highlights

Specific data

Early Warning System

� The Early Warning System allows you to search for exceptional situations and thus to detect and rectify

potential problems at an early stage.

� The LIS provides the data that the EWS analyzes. This means that the EWS can be used in any of the

logistics information systems.

� The Early Warning System is based on the information structures. Any information that is stored in the

structures can be analyzed by the EWS. This is also true for data that is updated using your own

programs, for example from external systems.

� The EWS can be used both to indicate defined alarm situations and to highlight specific data from the

rest of the data.

(C) SAP AG IUT230 13-41

SAP AG 1999

Complete list containing highlighted

exceptional situations

System-Driven

Review of data

(for example, weekly)

Event-Driven

Review of changed

data (for example, daily)

Interactive Periodic Analyses

Filter: Only exceptional

situation are displayed.

Rate StatisticsRate Cat.Amount Net

Amount

100 000230 000350 000

24 00055 20084 000

•

E1E2E3

Rate StatisticsRate Cat.Amount Net

Amount

230 000350 000

55 20084 000

E2E3

LISData

Excep

tion

Excep

tion

Fax

Mail

Workflow

Fax

Mail

Workflow

Capabilities of the Early Warning System

� The Early Warning system can be used interactively in the standard analyses or can run periodically in

the background.

� If it is used interactively, the alarm situations are highlighted in color in the standard analysis or filtered

in the exceptions analysis. This allows you to recognize alarm situations at an early stage.

� If it is run periodically, a list of exception data is automatically sent to a predefined group of recipients

by fax, mail or workflow.

(C) SAP AG IUT230 13-42

SAP AG 1999

157157005005

396396Info StructureInfo Structure

S440S440

Active for Standard AnalysisTransfer to WorkflowMailFaxTransfer to Distribution List

Characteristics

Rate Cat.RateMonth

Exception: Characteristics

Key Figures

Conditions

Amount < 200,000

Exception: Conditions

Define Conditions

Select Key FiguresExceptionException

Threshold ValueThreshold Value

TrendTrend

Planned/Actual Comp.Planned/Actual Comp.

Defining an Exception

Exception: Subsequent Processing

Select Characteristics

� When you create an exception, you need to carry out the following steps:

� As an exception is always created with reference to a particular information structure, you select the

characteristics from this information structure. The order of the characteristics defines the subsequent

standard drilldown an the level at which the condition is checked for.

� You also select the key figures from the information structure. Then you can define the exception

conditions for the selected key figures.

� In the third step, you define the subsequent processing for the exception.

(C) SAP AG IUT230 13-43

SAP AG 1999

Sales Statistics: 5






� Tools



� CO-PA


(C) SAP AG IUT230 13-44

SAP AG 1999

Database TablesDatabase TablesDatabase Tables

LIS Table DescriptionsLIS Table DescriptionsLIS Table Descriptions

ReportsReportsReports

Data Display

Data Retrieval

LogicalData View

PhysicalData Basis

EvaluationStructure

EvaluationStructure

DDIC

Tables

DDIC

TablesInfo

Structures

Info

Structures

EvaluationEvaluation

List

Flexible Analyses

� The method of flexible analysis allows you to display the contents of information structures differently

to with standard analyses. When you use the LIS flexible analyses, you partly use the functions of the

Report Writer. This is a tool for creating reports that was developed for other SAP applications, such as

general ledger accounting and cost center accounting.

� Note that you cannot use the full functions of the Report Writer in the flexible analyses. If you want to

use all the functions of the Report Writer, you have to edit the reports using the Report Writer

transactions.

(C) SAP AG IUT230 13-45

SAP AG 1999

EACTST003EACTST003

ZFST003Charact. Key Figures

..... .....

..... .....

..... .....

ZFST003ST003Charact. Key Figures

..... .....

..... .....

..... .....

XY01XY01

Charact. Key Figures..... .......... .....

Formulas

Layout

DD StructureDD Structure

Evaluation StructureEvaluation Structure

EvaluationEvaluation

Data Retrievaland Display(using Report Writerfunctions)

LogicalData View

PhysicalData Basis

Creation of New

Contracts

Flexible Analyses: Example Transaction Statistics

� To control data retrieval for evaluations, you require evaluation structures in the LIS. These describe the

possible data sources for your evaluations. The data sources can either be information structures or

normal DDIC tables.

� An evaluation structure essentially contains a list of characteristics and key figures, which can originate

from different physical database tables.

� The name of an evaluation structure must begin with 'ZF' (for example, ZFST003). The DDIC tables for

transaction statistics begin with EACT*. The DDIC tables for stock statistics begin with EMD*.

Standard analyses and info structures are not available for stock and transaction statistics. You must

create the evaluation structures and evaluations yourself.

� Evaluations are created with reference to evaluation structures. The characteristics and key figures of an

evaluation structure are possible lines or columns of your evaluation list.

� When evaluation structures and evaluations are generated, the system creates Report Writer objects in

the background; these are libraries for evaluation structures and reports for evaluations.

� At the level of data display, when the system carries out an evaluation, it displays a list of data that can

be changed and interpreted using a range of functions.

(C) SAP AG IUT230 13-46

SAP AG 1999

Sales Statistics: 6






� Tools



� CO-PA


(C) SAP AG IUT230 13-47

SAP AG 1999

Overhead CostOverhead Cost


Product CostProduct Cost


ProfitCenter

PrCtrPrCtr 11

PrCtrPrCtr 33

PrCtr 2

PrCtrPrCtr 44

PrCtrPrCtr 55Profitability Profitability

AnalysisAnalysis

Co

st

an

d R

even

ue E

lem

en

t A

cco

un

tin

gC

ost

an

d R

even

ue E

lem

en

t A

cco

un

tin

g

Profitability Segments

Cost Center Acc.

Process Cost Acc.

Bill

Cost Object

CO

Overhead

Cost Order

ProfitProfit

CenterCenter

BillBill

Business Model: Controlling

� The CO application component (Controlling) encompasses all the functions required for efficient

controlling in the SAP System. CO represents internal accounting. It provides information for people in

managerial positions, that is, information to help control and monitor company activities.

� CO covers cost and revenue controlling. In conjunction with the EC-PCA component (Profit Center

Accounting), it provides all controlling options without being bound to the legal structures that are

obligatory in financial accounting.

� CO consists of several application components which provide an ideal entry point to the various areas in

Controlling. CO provides answers to the following typical questions in the respective components:

• Which costs arise in our company? (CO-OM)

• How much does it cost to produce a certain product or provide a certain service? (CO-PC)

• In which market segments are we successful? (CO-PA)

• How profitable are our internal organizational units (profit centers)? (EC-PCA)

(C) SAP AG IUT230 13-48

SAP AG 1999

Customer

Region

Product

Market

CompanyCompany

Who are our most important and fastest-

growing customers?

How have the sales and contribution margin

of individual products developed recently?

Invoice

Typical Questions in Profitability and Sales Accounting

� The best way of explaining the aims of the Profitability Analysis in the SAP System is to list the

questions that can be answered using the Profitability Analysis.

(C) SAP AG IUT230 13-49

SAP AG 1999

Company Market

InvoicingIS-U

Profitability AnalysisCO-PA

Sales Key Figures:Revenues,

Cost of sales...

Market Segments:Customer, Rate Cat.,

Rate, Account Cat.,Division

COCO--

PAPA

ISIS--UU

The aim of CO-PA is to determine the success of market segments.

Aim of Profitability Analysis

� The business purpose of profitability analysis is to provide profitability-oriented information about a

company's market segments or distribution channels with the aim of supporting enterprise planning and

decision making, especially in the areas of sales and marketing.

� You can freely define the market segments and key figures that are to be analyzed, thus allowing

maximum flexibility in the market analysis. You define the market in the system by choosing the

characteristics to be analyzed. Key figures can either be income statement accounts or value fields that

can be freely defined.

� Market segments usually consist of a combination of customer, product, and organizational information.

Typical key figures are quantities, revenues, discounts, surcharges, product costs, contribution costs,

period costs, etc.

� Profitability is analyzed in CO-PA using multidimensional reporting that allows you to rearrange data to

represent it from various views in a single report.

(C) SAP AG IUT230 13-50

SAP AG 1999

CharacteristicsCharacteristicsCharacteristics

RE

GIO

N

S

N

W

Rate Cat. Account C

at.


Region NorthRate category E3

Rate E3_1Account cat. Res. cust.

E1

RevenuesRate Cat.

E3

RevenuesRate Cat.

E3

Consumption 1500

Revenue 800Cost of sales 450

E2 E3

Basic Concepts in CO-PA

Value Fields

� Characteristics

Answer the question: "About which topic do I want to report?"

Examples: Division, region, rate category, account category

� Characteristic Values

Answer the question: "What are the permitted values for this characteristic?"

Examples: South region, North region

� Profitability segments

Answer the question: "At which level do I want to analyze?"

Example: Combination of north region, E1 rate category, electricity division

� Value Fields

Answer the question: "Which key figures do I want to include in the database and analyze?"

Examples: Revenues, discounts, cost of sales

(C) SAP AG IUT230 13-51

SAP AG 1999

COCO--PCPC

Cost Centers

OrdersProcesses

Product

Costing

G/L Account

Posting

Invoice

FIFI

COCO--OMOM

COCO--PAPA

SDSD

Accrued

Costs

AmountAmount

RevenueRevenue

Sales DeductionsSales Deductions

Goods UsageGoods Usage

Variable Cost of Goods ManufctrdVariable Cost of Goods Manufctrd

Fixed Cost of Goods ManufacturedFixed Cost of Goods Manufactured

RebateRebate

FreightsFreights

Sales and Administration CostsSales and Administration Costs

Marketing CostsMarketing Costs

VariancesVariances

Accrued DiscountsAccrued Discounts

Accrued RebatesAccrued Rebates199319941995

ISIS--UU

InvoicingUnbilled Revenue Reporting

AmountAmount

RevenueRevenue

Origin of Value Fields

� The amounts and quantities that are to be used in reporting are stored in the value fields of the costing-

based profitability analysis. They represent the cost and revenue structures and depict the lowest level at

which the values are posted.

� A key task in Customizing for costing-based profitability analysis is to appropriately allocate costs and

revenues to the defined value fields so that the reporting tools can portray contribution margin

accounting in a way that meets the company's requirements.

(C) SAP AG IUT230 13-52

SAP AG 1999


CO-PA Characteristics

WWE01 State

WWE02 Rate cat.WWE03 Rate

WWE04 Region

IS-U Field of Origin

COUNTRY State

TARIFTYP Rate cat.TARIFNR Rate

REGION Region

Assignment Table

COCO--

PAPAISIS--UU

OperatingConcern

Active

OperatingConcern

Active

Change Contract

Contract Edit Goto Additional System Help

Contract TF0415A001

Account Assignment Data

Profitability segment assigned X

COCO--

PAPA

Integration IS-U / CO-PA: 1

� You can move consumption quantities and revenues from IS-U to CO-PA. There is an assignment table

in the FI-CA IMG for this purpose. You assign the previously defined CO-PA characteristics to IS-U

fields of origin in this table. IS-U fields of origin are defined by SAP in the EVU_COPACRIT structure.

You can extend this structure if required.

� You must also customize the CO-PA and activate the operating concern. When new contracts are

created, the system then automatically proposes the field 'profitability segment assigned'. If this field is

set, the system goes through the assignment table during billing and determines a profitability segment.

The profitability segments are saved in the billing document and are transferred to CO-PA later on

during the transfer process.

(C) SAP AG IUT230 13-53

SAP AG 1999

Billing DocumentsBilling Documents

Transfer toCO-PA

Billing DocumentsBilling DocumentsTransfer to

CO-PA

StatisticallyISIS--UU

COCO--

PAPAISIS--UU

COCO--

PAPA

Revenue and

Profitability

Bill

Unbilled Rev.

Proration

(GeneralProcedure)

Profitability

Segments

Profitability

Segments

Profitability

Segments

Profitability

Segments

Integration IS-U / CO-PA: 2

� There are two reports that you can use to transfer data to CO-PA.

� Transfer of actually billed amounts and revenues to CO-PA.

� Transfer of statistical data, so that the unbilled revenue reporting can be carried out in CO-PA. This

type of unbilled revenue reporting is a general procedure.

(C) SAP AG IUT230 13-54

SAP AG 1999 SAP AG

� Sales statistics data is kept in a data warehouse.

� The Utility Information System (UIS) is a component of the

Logistics Information System (LIS).

� The communication structure, field catalogs and information structure are part of the flow of information

from the application to the UIS.

� Certain standard analyses (rate and industry statistics) are

provided with the system as examples.

� It is also possible to carry out flexible analyses.

� You must use flexible analyses for stock and transaction

statistics.

� Unbilled revenue reporting is carried out using CO-PA.

Sales Statistics: Unit Summary

(C) SAP AG IUT230 13-55

Sales Statistics: Exercises

Unit: Sales Statistics

Topic: Sales Statistics

• Evaluate rate statistics.

• Create a customer-defined information structure.

• Define evaluation structures and evaluations.

You are familiar with the information systems. You are asked to evaluate

various data (such as rate statistics). As a customer, you have additional

requirements, so you create a customer-defined information structure.

You also perform flexible analyses.

1-1 Carry out an evaluation of the rate statistics.

1-1-1 Which menu path would you use to evaluate rate statistics?

_________________________________________________________

1-1-2 Start the procedure for evaluating rate statistics. Select according to various

characteristics. Analyze the period from January 1998 to December 1998.

1-1-3 Display the evaluation in the various possible business graphics.

1-2 Check the definition of the communication structure in the Implementation Guide.

1-2-1 Which menu path would you use to extend the communication structure?

_________________________________________________________

1-2-2 What is the communication structure for Utilities called? What is the customer-

include in the communication structure called that is used to extend the communication

structure?

_________________________________________________________


(C) SAP AG IUT230 13-56

1-3 Create a new information structure taking the following specifications into account.

You can choose a maximum of 6 characteristics.

1-3-1 Define information structure S5## using the following information:

Initial Data

Info structure S5##

Application VU

Text Info structure: Group ##

Info structure category Standard

Planning possible ‘ ‘

Data

Characteristics Any 6 characteristics

Key figures Billing quantity and net amount

1-3-2 Generate the new information structure and check the log.

1-3-3 Define the update rules for your information structure. Use the SISU update

group.

1-3-4 Activate updating for your information structure. The data is to be updated at

monthly intervals. You should also use asynchronous updating (2).

1-3-5 The information structure you have just created does

not contain any data yet. Therefore, you must recompile the statistics data for your

information structure. Only recompile the statistics data for a small amount of

documents. Start the recompilation program with the following data:

Data

Info structure to be compiled S5##

Save as version 000 (actual data)

Invoicing document 2000000500 to 2000000510

Name of run Run1

Termination time System time + 10 minutes

Confirm the warnings.

Check the recompilation by evaluating your info structure with a standard analysis.

1-4 To be able to perform additional analyses, create your own evaluation structure and

evaluation.

1-4-1 Create an evaluation structure called ZF0## with reference to your information

structure S5##. Choose the characteristics and key figures that you require.

1-4-2 Create an evaluation called Z## for your evaluation structure ZF0##. Choose

the characteristics and key figures that you require.

1-4-3 Perform the evaluation.

(C) SAP AG IUT230 13-57

Sales Statistics: Solutions

Unit: Sales Statistics

Topic: Sales Statistics

1-1 Carry out an evaluation of the rate statistics.

1-1-1 Which menu path would you use to evaluate rate statistics?

From the SAP menu, choose:

Utilities Industry →→→→ Information System →→→→ Statistics →→→→ Sales Statistics →→→→

Standard Analyses →→→→ Rate Statistics

1-1-2 Start the procedure for evaluating rate statistics. Select according to various

characteristics. Analyze the period from January 1998 to December 1998.

Enter the required characteristics.

Month: January.1998 – December 1998

Execute.


For example, choose Goto →→→→ Graphics

1-2 Check the definition of the communication structure in the Implementation Guide.

1-2-1 Which menu path would you use to extend the communication structure?

From the SAP Reference IMG, choose: Implementation Guide →→→→ Industry

Solution – Utilities Industry →→→→ Information System →→→→ Statistics →→→→ Sales

Statistics →→→→ Data Basis →→→→ Communication Structures →→→→ Extend

Communication Structure

1-2-2 What is the communication structure for Utilities called? What is the customer

include in the communication structure called that is used to extend the

communication structure?

Communication structure: MCVU_ESTA

Customer include: CI_MCESTA

1-3 Create a new information structure taking the following specifications into account.

You can choose a maximum of 6 characteristics.

1-3-1 Define information structure S5## using the following information:

From the SAP Reference IMG, choose: SAP Utilities →→→→ Information System

→→→→ Statistics →→→→ Sales Statistics →→→→ Data Basis →→→→ Information Structures →→→→

Define Information Structures →→→→ Create Information Structures.

(C) SAP AG IUT230 13-58

Confirm the message regarding the SAP development class.


Choose the required characteristics from the field catalogs.

Choose net amount and billing quantity from the catalog of key figures.

Save the information structure locally.

1-3-2 Generate the new information structure and check the log.

Generate the new information structure and check the log to see if errors

occurred during generation.

1-3-3 Define the update rules for your information structure. Use the SISU update

group.


→→→→ Statistics →→→→ Sales Statistics →→→→ Update →→→→ Define Update →→→→ Specific

Definition Using Update Rules →→→→ Define Update Rules →→→→ Create Update

Rules.

Update group: SISU

Choose the Rules for key figures function for both the billing quantity and

net amount key figures.

Choose ‘Suggest rules’ and accept the suggested rule. Repeat this step for the

other key figure.

Save the update rules.

Generate the update rules and check the log.

1-3-4 Activate the update for your information structure. The data is to be updated at

monthly intervals. You should also use asynchronous updating.


→→→→ Statistics →→→→ Sales Statistics →→→→ Update →→→→ Update Control →→→→ Activate

Update.

Double-click on your information structure to select it from the list.

In the following popup, choose month as the period split, and Asynchronous

updating (2). Press Enter.

Save.

1-3-5 The information structure you have just created does not contain any data yet.

Therefore, you must recompile the statistics data for your information structure.

Only recompile the statistics data for a small amount of documents. Start the

recompilation program with the following data:


→→→→ Statistics →→→→ Sales Statistics →→→→ Data Basis →→→→ Tools →→→→ Set Up Statistical

Data →→→→ UIS Setup.

Maintain the field contents as specified in the exercise and choose Execute.

(C) SAP AG IUT230 13-59

Check the recompiled statistics data by performing a standard analysis on

your information structure.

From the SAP menu, choose: Utilities Industry →→→→ Information System →→→→

Statistics →→→→ Sales Statistics →→→→ Standard Analyses →→→→ User-defined analysis.

Month: January 1998 – December 1998

Choose Execute.

1-4 To be able to perform additional analyses, create your own evaluation structure and

evaluation.

1-4-1 Create an evaluation structure called ZF0## with reference to your information

structure S5##. Choose the characteristics and key figures that you require.


Statistics →→→→ Sales Statistics →→→→ Flexible analyses →→→→ Evaluation structure →→→→

Create.

Enter ZF0## as the evaluation structure.

Choose Evaluation str. ref.

Choose Characteristics. To display your characteristics, double-click on your

evaluation structure. You can switch between the text and the key for the

evaluation structure by using the ‘switch display’ pushbutton. Select the

required characteristics by double clicking on them. Copy the characteristics

using the ‘Copy and close’ pushbutton. Choose Copy again.

Choose Key figures. To display your key figures, double-click on your

evaluation structure. You can switch between the text and the key for the

evaluation structure by using the ‘switch display’ pushbutton. Select the

required key figures by double clicking on them. Copy the key figures using

the ‘Copy and close’ pushbutton. Choose Copy again.

Generate the evaluation structure.

Do not include the evaluation structure in a transport request.

1-4-2 Create an evaluation called Z## for your evaluation structure ZF0##. Choose

the characteristics and key figures that you require.


Statistics →→→→ Sales Statistics →→→→ Flexible analyses →→→→ Evaluation →→→→ Create.

Enter Z## as the evaluation.

Choose Characteristics. Select the characteristics that you require in the

evaluation. Copy the characteristics using the ‘Copy and close’ pushbutton.

Choose Copy again.

Choose Key figures. Select the key figures that you require in the evaluation.

Copy the key figures using the ‘Copy and close’ pushbutton. Choose Copy

again.

Save the evaluation.

Do not include the evaluation in a transport request.

(C) SAP AG IUT230 13-60

1-4-3 Perform the evaluation.


Statistics →→→→ Sales Statistics →→→→ Flexible analyses →→→→ Evaluation →→→→ Execute.

Enter ZF0## as the evaluation structure and Z## as the evaluation.

Confirm ‘Copy current report definition from client 000’ by choosing yes.

Enter the required characteristics.

Choose Execute.

SAP AG 1999

Appendix B and C

SAP AG 2001

� Appendix B: Nonresidential Billing

� Appendix C: Recommendation for the Billing Schema


Appendix B

Nonresidential Billing

Contents

3-Peak Average with Floating Backbilling..............................................................15-3

Business Description.............................................................................................15-3

Overview ..............................................................................................................15-4

Backbilling Indicators in the Billing Schema................................................................... 15-9

Description ..................................................................................................................... 15-10

Detailed Description ...........................................................................................15-11

Operands ........................................................................................................................ 15-15

Rate - Time Period Control - Variant Control ................................................................ 15-18

Rate Category................................................................................................................. 15-24

Demand Billing – Cosine Phi – Period-End Billing...............................................15-25

Business Description...........................................................................................15-25

Overview ............................................................................................................15-26

Detailed Description ...........................................................................................15-29

Rate Category................................................................................................................. 15-34

Period-End Billing Indicator .......................................................................................... 15-35

Period-End Billing Rate ................................................................................................. 15-37

Period-End Billing Schema Header Data ....................................................................... 15-37


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.


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 P

R

Inp. Op.1 Inp. Op.2 Outp. Op.1 ExB

B

B

B

All

BB

1

Rev

BB

1

1 E7_1 QUANTI01 X EQUANT_1 EQPRICE_1 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


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 for posting

Inp. Op.1: First input operand

Inp. Op.2: Second input operand

Outp. Op.1: Output operand

ExBB: Execute backbilling indicator

BB: Execute schema step in backbilling only indicator

AllBB1: Allocate backbilling indicator

RevBB1: Reverse backbilling indicator


In demand rate E7_3, the current measured demand is transferred to the installation facts using

INFACT01. This demand is also updated to the operand planned for peak averaging and required

for the current period using DEMAND14. At this point, it only contains one demand value (if

only the peak monthly demand value is to be considered). In the next step, backbilling is triggered

with BACKBI01. In the Execute backbilling indicator column, you specify which steps are to be

carried out in backbilling. In the next step, you write the demand values for the previous periods

(adjustment periods) to the output operand for peak averaging using the same group assignment

and variant BACKBI03.

Example:

The backbilling period starts on January 1 and ends on December 31 of the same year. The current

billing month is April. 40 kW was measured in April.

The following demand values have so far been entered using INFACT01 in the installation facts

(demand values from the meter reading):

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)


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 settled. 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 settlement demand, and the current settlement 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 settled in the current billing period (April).

January February March April May

|-------------------|-------------------|-------------------|-------------------|-------------------|

Current billing

30 kW


In the next step, you use variant IF00 to check whether the current settlement demand

corresponds to the previous month's settlement 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 settlement 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 settlement demand. For this reason, the current settlement

demand is first written to the adjustment period by means of BACKBI02.


|-------------------|-------------------|-------------------|-------------------|-------------------|

< -----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 settlement demand of 20 kW.

January February March

|----------------------|----------------------|----------------------|

Adjustment periods:

< -----20 kW--- >

< -----20 kW----- >

< -----20 kW------ >


In billing for April, a new settlement demand has been calculated. After variant

BACKBI02 has been executed, the following data is available:


|-------------------|-------------------|-------------------|-------------------|-------------------|

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


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 ExB

B

B

B

AllB

B1

Rev

BB1

. . .

. . .


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


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:





(C) SAP AG IUT230 15-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.

(C) SAP AG IUT230 15-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 settings.

You carry out this variant step with the next step using the Execute backbilling indicator.

(C) SAP AG IUT230 15-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 settlement demand.

8 - INFACT01 – Writing a demand to the installation facts

In the future, this settlement 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 - Valuation of a demand with a price

The settlement demand calculated for the current month is valuated with a price. Price

prorations are taken into account. The calculated amount is updated.

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 settlement demand is compared with the settlement 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

(C) SAP AG IUT230 15-13

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.

(C) SAP AG IUT230 15-14

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 settlement demand is different from the previous month's settlement

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.


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.

(C) SAP AG IUT230 15-15

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 Value 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

(C) SAP AG IUT230 15-16

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

rate category, or installation facts.

(C) SAP AG IUT230 15-17


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.

(C) SAP AG IUT230 15-18

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


7 DEMAND01 01 02 EDEMAND5 ETPRICE_1 EAMOUNT_1

8 IF00 03 EDEMAND5 EDEMAND8

9 ELSE


11 BACKBI01 F

12 ENDIF

Section of the rate for demand calculation.

Key:

No. Current rate step number


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

(C) SAP AG IUT230 15-19

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:

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.

For values whose time slice lengths are used for calculations.

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

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

(C) SAP AG IUT230 15-20

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


2 DEMAND14 01 01 EDEMAND1 EDEMAND6

3 BACKBI01 F


5 DEMAND07 01 02 EDEMAND6 EDEMAND4 EDEMAND5


7 DEMAND01 01 02 EDEMAND5 ETPRICE_1 EAMOUNT_1

8 IF00 03 EDEMAND5 EDEMAND8

9 ELSE


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


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

(C) SAP AG IUT230 15-21

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.



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

- Info lines relating to demand(s) to be billed are written.

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

(C) SAP AG IUT230 15-22

Rate step no. 6 – INFACT01


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

settlement demand and, if necessary, backbilling is carried out.



- 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


- 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 settlement demand. Demand2 is the current

settlement demand. If this demand is the same as the previous month's settlement 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.

(C) SAP AG IUT230 15-23

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.

(C) SAP AG IUT230 15-24

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.


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

(C) SAP AG IUT230 15-25

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 invoicings

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

(C) SAP AG IUT230 15-26

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 P

R

Inp. Op.1 Inp. Op.2 Outp. Op.1 ExB

B

B

B

All

BB1

Rev

BB1

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


9 E8_3 DEMAND01 X EDEMAND1 ETPRICE_1 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


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


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

(C) SAP AG IUT230 15-27

*

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:


PR: Billing line items relevant to posting

1st Inp. Op.: First input operand

2nd

Inp. Op.: Second input operand

1st Outp. Op.: Output operand





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.

(C) SAP AG IUT230 15-28

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.

(C) SAP AG IUT230 15-29

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



different names.

4 - INFACT02 - Writing an amount to the installation facts



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.

(C) SAP AG IUT230 15-30

Active Energy Off-Peak Rate


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.


The calculated amount from the valuation of the off-peak rate is written to the installation

facts.

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.


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.

(C) SAP AG IUT230 15-31

12 - IF03 - Condition: IF factor1 >,>=,= factor2



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

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.


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

reexecuted.

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 were updated and are now

(C) SAP AG IUT230 15-32

to be added to determine whether the customer is entitled to a particular discount in period-

end billing.

(C) SAP AG IUT230 15-33


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.

21 - IF02 - Condition: IF amount1 >,>=,= amount2



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.


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.

(C) SAP AG IUT230 15-34

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


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

(C) SAP AG IUT230 15-35

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.

(C) SAP AG IUT230 15-36

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.

(C) SAP AG IUT230 15-37

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 P

R

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



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.

(C) SAP AG IUT230 15-38

Appendix C

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 are 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 overproportional (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.

(C) SAP AG IUT230 15-39

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.

iut230 billing and invoicing

Documents

billing modules

uccs billing

billing master data

billing class

billing periods

billing utility services

contract text

universal billing engine