IUT230 Billing and Invoicing

IUT230 Abrechnung und Fakturierung
IUT230











Release 463 25.09.2003




1. IUT230 Abrechnung und Fakturierung..............................................................................................................0-1
Copyright 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
b. Billing/Invoicing: Business Scenario 3 3-3
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
b. Billing/Invoicing: Business Scenario 4 4-3
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
b. Billing/Invoicing: Business Scenario 5 5-3
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
b. Billing/Invoicing: Business Scenario 6 6-3
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
b. Billing/Invoicing: Business Scenario 7 7-3
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
b. Billing/Invoicing: Business Scenario 8 8-3
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
b. Billing/Invoicing: Business Scenario 9 9-3
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 lli ng 10-1
a. Manual Billing: Unit Objectives 10-2
b. Billing/Invoicing: Business Scenario 10 10-3


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 lli ng Features 11-1
a. Special Billing Features: Unit Objectives 11-2
b. Billing/Invoicing: Business Scenario 12 11-3
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
b. Billing/Invoicing: Business Scenario 11 12-3
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 andC 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
IUT230
IUT230



Þ 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 prior
consent 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/ Basic
Functions
IUT210 3 days
Real Time Pricing
IUT235 2 days
Energy Data
Management
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




(C) SAP AG IUT230 1-2
© 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




(C) SAP AG IUT230 1-3
© SAP AG 1999
Energy and Service Company
IDES Utilities Inc.
Telecommuni-
cations
Multimedia Electricity
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.

(C) SAP AG IUT230 1-4
© SAP AG 1999
P
o
t
e
n
t
i
a
l
S
u
p
p
l
y

A
r
e
a
P
o
t
e
n
t
i
a
l
S
u
p
p
l
y

A
r
e
a
Deregulated Utilities Industry
O
r
ig
in
a
l
S
u
p
p
ly
A
r
e
a
O
r
ig
in
a
l
S
u
p
p
ly
A
r
e
a



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

(C) SAP AG IUT230 1-5
© SAP AG 1999
Branches
Sales &
Distribution
Technical
Board of
Directors
Head Office
Market
Energy
Industry
Data Processing
Grid
Logistics
Construction
Commercial
Board of
Directors
Organizational Structure




(C) SAP AG IUT230 1-6
© 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.24
UNI 100.00
UNI 50.00
------Municipal Services New X---------




(C) SAP AG IUT230 1-7
© 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/kWh
0.11 UNI/kWh
50 UNI/year
70 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.

(C) SAP AG IUT230 1-8
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billings Budget Billings
Additional Functionality: Additional Functionality:
Discount/Surcharge Discount/Surcharge
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special 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.


(C) SAP AG IUT230 1-9
© 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




(C) SAP AG IUT230 2-1
© 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




(C) SAP AG IUT230 2-2
© SAP AG 1999
Billing in the IS-U Data Model: Unit Objectives
© SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ 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




(C) SAP AG IUT230 2-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billings Budget Billings
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 2



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


(C) SAP AG IUT230 2-4
© SAP AG 1999
Electricity
Gas
Water/
Waste water
District heating
Cable T.V.
Multimedia
Charges,
taxes
Divisions
Residential customer
Nonresidential customer
Co-generator
Business
Partner
Billing Rules, Variants
Billing Rules, Variants
Consumption
Demand
Flat Rates
Discounts,
surcharges
General
duties
Prororations Franchise
fees
Price
adjustment
. . . . . .
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

(C) SAP AG IUT230 2-5
© SAP AG 1999
SD
AM
MM
GIS,
CAD,
SCADA
GIS,
CAD,
SCADA
MM
PM/
CS
SD
FI
CO-
Sales &
Distribution
Sales &
Distribution
C
o
n
t
r
a
c
t

R
e
c
.

&

P
a
y
a
b
l
e
(
F
I
-
C
A
)
C
o
n
t
r
a
c
t

R
e
c
.

&

P
a
y
a
b
l
e
(
F
I
-
C
A
)
B
i
l
l
i
n
g
/
I
n
v
o
i
c
i
n
g
B
i
l
l
i
n
g
/
I
n
v
o
i
c
i
n
g
I
n
s
t
a
l
l
a
t
i
o
n
S
e
r
v
i
c
e
s
I
n
s
t
a
l
l
a
t
i
o
n
S
e
r
v
i
c
e
s
C
o
n
s
u
m
p
t
i
o
n
D
a
t
a

C
o
l
l
e
c
t
i
o
n
C
o
n
s
u
m
p
t
i
o
n
D
a
t
a

C
o
l
l
e
c
t
i
o
n
Third-Party
Consumption
Data Collection
Systems
Third-Party
Consumption
Data Collection
Systems
Third-Party
Sales
Systems
Third-Party
Sales
Systems
Standard SAP
Business
Partner
Customer care
and service system
IS-U
components
Standard SAP
components
External systems
Financial
Accounting
Financial
Accounting
Device
Management
Device
Management
C
U
S
TO
M
E
R
Plant Maintenance
& Customer Service
Plant Maintenance
& Customer Service
Asset and
Materials Management
Asset and
Materials Management
C
A
R
E
&
SE
R
V
I
C
E
IS-U/CCS as an
integrated component
of 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.

(C) SAP AG IUT230 2-6
© 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).



(C) SAP AG IUT230 2-7
© 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



(C) SAP AG IUT230 2-8
© SAP AG 1999
Business Objects / Utility Services
Device
Category
Device
Category
Connection
Object
Connection
Object
Connection Connection
Device
Location
Device
Location
Premise Premise
Regional
Structure
Regional
Structure
Point of
Delivery
Point of
Delivery
Contract
Account
Contract
Account
Utility
Installation
Utility
Installation
Device Device
Meter
Reading
Meter
Reading
Contract
(Supply)
Contract
(Supply)
Business
Partner
Business
Partner



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

(C) SAP AG IUT230 2-9
© 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.




(C) SAP AG IUT230 2-10
© SAP AG 1999
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/kWh
0.11 UNI/kWh
50 UNI/year
70 UNI/year
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
º Basic price rate 2
º Standard water
º Reserve water
º Extinguishing water


(C) SAP AG IUT230 2-11
© SAP AG 1999
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/kWh
0.11 UNI/kWh
50 UNI/year
70 UNI/year
Rate
category,
e.g. household
Rate Type
Rate Type
Link Between Contract Text and IS-U: 2



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

(C) SAP AG IUT230 2-12
© SAP AG 1999
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/kWh
0.11 UNI/kWh
50 UNI/year
70 UNI/year
Rate
category,
e.g. household+
Rate Type
Rate Type
Rate
Rate
Link Between Contract Text and IS-U: 3



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

(C) SAP AG IUT230 2-13
© SAP AG 1999
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/kWh
0.11 UNI/kWh
50 UNI/year
70 UNI/year
Rate
category,
e.g. household
Rate Type
Rate Type
Rate
Rate
Variant Programs
Link Between Contract Text and IS-U: 4



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


(C) SAP AG IUT230 2-14
© SAP AG 1999
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/kWh
0.11 UNI/kWh
50 UNI/year
70 UNI/year
Rate
category,
e.g. household
Rate Type
Rate Type
Rate
Rate
Variant Programs
Prices
Link Between Contract Text and IS-U: 5



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


(C) SAP AG IUT230 2-15
© SAP AG 1999
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/kWh
0.11 UNI/kWh
50 UNI/year
70 UNI/year
Rate
category,
e.g. household
Rate Type
Rate Type
Rate
Rate
Variant Programs
Prices
Schema
Link Between Contract Text and IS-U: 6



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


(C) SAP AG IUT230 2-16
© SAP AG 1999
Rate
Determ.
Rate
Determ.
Rate Data
R
a
t
e

c
a
t
e
g
o
r
y
Prices and
Rate Facts
Prices and
Rate 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
E
X
E
C
U
T
I
O
N
Contract Contract
Utility
Installation
Utility
Installation
Inst. Structure/
Rate Cat. Facts/
Install. Facts
Inst. Structure/
Rate Cat. Facts/
Install. Facts
Rate 1 Rate 1
Rate n Rate n
Generation
of Billing
Line Items
Validation
of Billing
Results
Execution
of Variant
Programs
According to
Schema
Quantity
Conversion
and
Proration
Data Entry
and
Analysis
R
a
t
e

T
y
p
e
Universal Billing Engine
Customer- and
Installation-
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

(C) SAP AG IUT230 2-17
© SAP AG 1999
QUANTITY FACTOR QUANTITY
Calculates x% of a quantity
QUANTITY FACTOR QUANTITY
Calculates x% of a quantity
. . .
. . .
. . .
. . .
NUMBER OF DEMAND PEAKS DEMAND
Calculates N peak averages
NUMBER OF DEMAND PEAKS DEMAND
Calculates N peak averages
DEMAND PRICE BILLING LINE ITEMS
Valuates demand with a price
DEMAND PRICE BILLING LINE ITEMS
Valuates demand with a price
. . .
. . .
QUANTITY QUANTITY QUANTITY
Difference of two quantities
QUANTITY QUANTITY QUANTITY
Difference of two quantities
. . .
. . .
. . .
. . .
QUANTITY PRICE BILLING LINE ITEMS
Valuates energy with a price
QUANTITY PRICE BILLING LINE ITEMS
Valuates energy with a price
ACTIVE_KWH 0.5 ACTIVE_50%
ACTIVE_KWH 0.5 ACTIVE_50%
REACT_KWH - ACT_50% BILL_REACT
REACT_KWH - ACT_50% BILL_REACT
BILL_REACT 0.06 UNI BILLING
LINE ITEMS
BILL_REACT 0.06 UNI BILLING
LINE ITEMS
Variant Pool
Variant Pool
Variant Pool
Variant Pool
Contract text:
The reactive energy that exceeds 50%
of the active energy is valuated using a
separate price.
Contract text:
The reactive energy that exceeds 50%
of the active energy is valuated using a
separate price.
*
*
*
*
*
-
Flexible Structure of Billing Rules



Þ SAP provides a pool of variant programs with the system. This pool contains many variant programs.
Þ Variant programs are contained in rates as rate steps. Variant programs are basic calculation steps (e.g.
consumption x price, determination of the basic price, or determination of the rental price).
Þ By combining variant programs, you can model certain contract texts in the system (for example,
formula for reactive current calculation).
Þ In the above example, three variant programs are required to represent the contract text. The variant
programs communicate with each other using input and output parameters. Operands are simply
variables or placeholders that are filled with actual values (such as consumption, price) at runtime.

(C) SAP AG IUT230 2-18
© 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.

(C) SAP AG IUT230 2-19
© 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:
$100
Receivables:
100 UNI
Manual Billing
Print
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)

(C) SAP AG IUT230 2-20
© 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.




(C) SAP AG IUT230 3-1
© SAP AG 1999
Billing Master Data
© SAP AG 2001
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-2
© SAP AG 1999
Billing: Unit Objectives
© SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ 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




(C) SAP AG IUT230 3-3
© SAP AG 1999
Maintain
Billing
Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billings Budget Billings Budget Billings
Additional Functionality:
Discounts/Surcharges
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 3



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


(C) SAP AG IUT230 3-4
© SAP AG 1999
Billing Master Data: 1
¤ Individual Components
¤ Modeling of the Billing Logic
¤ Facts
¤ Dynamic Rate Determination




(C) SAP AG IUT230 3-5
© SAP AG 1999
Billing Modules: 1
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-6
© SAP AG 1999
Installation
Installation
Installation
structure
Installation
structure
Rate category
Rate category
Rate type
Rate type
Rate
determination
Rate
determination
Rates
VarProg.
Rates
VarProg.
Billing schema
Billing schema
Rate 1
Step 1
Step 2
Rate n
Step 1
VarProg.
Example: Quantity x price
Comparison of 2 demands
Operand values
1000 kWh, 0.25UNI
400 kW, 300 kW
Data Model for Billing
Operands
Operands
Operand values
Operand values



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

(C) SAP AG IUT230 3-7
© SAP AG 1999
Billing Modules: 2
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-8
© 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.


(C) SAP AG IUT230 3-9
© SAP AG 1999
Utility
Installation
Utility
Installation
Rate
Rate
Portion
Portion
Billing Class
(Classification,
Validation)
Billing Class
(Classification,
Validation)
Meter
Reading Unit
Meter
Reading Unit
Rate Category
Rate Category
Rate Type
Rate Type
Billing Class: 2
Price
Price
Schema
Schema
Discount
Discount



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


(C) SAP AG IUT230 3-10
© SAP AG 1999
Billing Modules: 3
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-11
© 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.
º Reference values
- Used to model street lights, for example

(C) SAP AG IUT230 3-12
© 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
Þ Device
For example: Rental price for devices that do not have
registers relevant to billing
Þ Facts
For example: Flat rates or installation flat rates
Þ Interval meter
For example: For billing real time pricing (RTP) rates
Þ Period-end billing
For example: For determining a special fact group in the period-end billing
Þ Waste billing
For 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.





(C) SAP AG IUT230 3-13
© SAP AG 1999
Rate Type
Rate Category
Register
Device
Rate Type: 2
¤ On-peak rate active
energy
¤ Off-peak rate active
energy
¤ On-peak rate reactive
energy
¤ Off-peak rate reactive
energy
¤ Gas consumption
¤ Water consumption
¤ Interval meter
¤ Rental price (device-
related)
¤ Flat-rate
installations
¤ Additional rates
¤ Flat-rate
installations
¤ Reference values
¤ 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.



(C) SAP AG IUT230 3-14
© SAP AG 1999
Billing Modules: 4
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-15
© SAP AG 1999
Prices
Price
Key
Prices for Billing
Central
Price
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.


(C) SAP AG IUT230 3-16
© SAP AG 1999
¤ Quantity-based price
for quantities and consumption
¤ Flat rate
fixed 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 price
for 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.

(C) SAP AG IUT230 3-17
© SAP AG 1999
¤ Normal price
Price that is not based on the quantity
¤ Block price
One or more prices that are based on the
quantity
¤ Scale price
Price 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.


(C) SAP AG IUT230 3-18
© 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
Customizing
Customizing
Quantity limit
- Inclusive up to block
- Exclusive as of block
Customizing
Customizing
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.

(C) SAP AG IUT230 3-19
© 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 --> P5
Q2 --> P4
Q3 --> P3
Rest --> P2
Price Determination
Block 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.

(C) SAP AG IUT230 3-20
© SAP AG 1999
Adjusting Price Blocks to Billing Periods
Time basis: 365 days
Price block adjustment activated
Interval lower limit: 350 days
Interval upper limit: 375 days
Quantity-Based Price
Price Blocks
0 - 3000
3000 - 5000
5000 - 10000
10000 - 9999999999
Price Blocks
0 - 3000
3000 - 5000
5000 - 10000
10000 - 9999999999
Adjustment of blocks/scales to
billing period, e.g. 340 days
Price Blocks
0 - 2795
2795 - 4658
4658 - 9315
9315 - 9999999999
Price Blocks
0 - 2795
2795 - 4658
4658 - 9315
9315 - 9999999999



Þ You can adjust the blocks/scales for quantity-based prices if the billing period differs from the basic time
specified in the price key.
Þ If you want the blocks/scales to be adjusted, you have to set the Adj.PBlcks indicator (adjust price
blocks). If the adjustment is to be dependent on an interval, you must also set the interval lower and
upper limits.


(C) SAP AG IUT230 3-21
© 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.

(C) SAP AG IUT230 3-22
© SAP AG 1999
Quantity-Based Price
Quantity-
based
price
Q
u
a
n
t
i
t
y

r
e
f
.
Q
u
a
n
t
i
t
y

r
e
f
.
N
o

t
i
m
e

r
e
f
.
N
o

t
i
m
e

r
e
f
.
U
n
i
t

o
f

m
e
a
s
u
r
e
U
n
i
t

o
f

m
e
a
s
u
r
e
Q
u
a
n
t
i
t
y

b
a
s
e
Q
u
a
n
t
i
t
y

b
a
s
e



Þ 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



(C) SAP AG IUT230 3-23
© SAP AG 1999
Time-Based Price
Time-Based
Price
Q
u
a
n
t
i
t
y

R
e
f
e
r
e
n
c
e
T
i
m
e


R
e
f
e
r
e
n
c
e
T
i
m
e

B
a
s
i
s
T
i
m
e

C
a
t
e
g
o
r
y



Þ 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







(C) SAP AG IUT230 3-24
© SAP AG 1999
Flat Rate
Flat Rate
N
o

Q
u
a
n
t
i
t
y

R
e
f
e
r
e
n
c
e
N
o

Q
u
a
n
t
i
t
y

R
e
f
e
r
e
n
c
e
T
i
m
e


R
e
f
e
r
e
n
c
e
T
i
m
e


R
e
f
e
r
e
n
c
e
T
i
m
e

B
a
s
i
s
T
i
m
e

B
a
s
i
s
T
i
m
e

C
a
t
e
g
o
r
y
T
i
m
e

C
a
t
e
g
o
r
y



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


(C) SAP AG IUT230 3-25
© SAP AG 1999
Rental Price
Rental
Price
Q
u
a
n
t
i
t
y

R
e
f
e
r
e
n
c
e
Q
u
a
n
t
i
t
y

R
e
f
e
r
e
n
c
e
T
i
m
e


R
e
f
e
r
e
n
c
e
T
i
m
e


R
e
f
e
r
e
n
c
e
P
r
i
c
e

C
l
a
s
s
P
r
i
c
e

C
l
a
s
s
P
r
i
c
e

L
e
v
e
l
P
r
i
c
e

L
e
v
e
l



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



(C) SAP AG IUT230 3-26
© SAP AG 1999
Price Adjustment Clause
Company
Bill
Company
Bill x y z
Basic Price
2.00
Price
Adjustment Clause
1.50
Addition
+
Multiplication
*
Final Price
for the Customer
Final 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.



(C) SAP AG IUT230 3-27
© SAP AG 1999
Billing Master Data: 2
¤ Individual Components
¤ Modeling of the Billing Logic
¤ Facts
¤ Dynamic Rate Determination




(C) SAP AG IUT230 3-28
© SAP AG 1999
QUANTITY FACTOR QUANTITY
Calculates x% of a quantity
QUANTITY FACTOR QUANTITY
Calculates x% of a quantity
. . .
. . .
. . .
. . .
NUMBER OF DEMAND PEAKS DEMAND
Calculates N peak averages
NUMBER OF DEMAND PEAKS DEMAND
Calculates N peak averages
DEMAND PRICE BILLING LINE ITEMS
Valuates demand with a price
DEMAND PRICE BILLING LINE ITEMS
Valuates demand with a price
. . .
. . .
QUANTITY QUANTITY QUANTITY
Difference of two quantities
QUANTITY QUANTITY QUANTITY
Difference of two quantities
. . .
. . .
. . .
. . .
QUANTITY PRICE BILLING LINE ITEMS
Valuates energy with a price
QUANTITY PRICE BILLING LINE ITEMS
Valuates energy with a price
ACTIVE_KWH 0.5 ACTIVE_50%
ACTIVE_KWH 0.5 ACTIVE_50%
REACT_KWH - ACT_50% BILL_REACT
REACT_KWH - ACT_50% BILL_REACT
BILL_REACT 0.06 UNI BILLING
LINE ITEMS
BILL_REACT 0.06 UNI BILLING
LINE ITEMS
Variant Pool
Variant Pool
Variant Pool
Variant Pool
Contract text:
The reactive energy that exceeds 50%
of the active energy is valuated using a
separate price.
Contract text:
The reactive energy that exceeds 50%
of the active energy is valuated using a
separate price.
*
*
*
*
*
-
Flexible Structure of Billing Rules



Þ SAP provides a pool of variant programs with the system. This pool contains many variant programs.
Þ Variant programs are contained in rates as rate steps. Variant programs are basic calculation steps (e.g.
consumption x price, determination of the basic price, or determination of the rental price).
Þ By combining variant programs, you can model certain contract texts in the system (for example,
formula for reactive current calculation).
Þ In the above example, three variant programs are required to represent the contract text. The variant
programs communicate with each other using input and output parameters. Operands are simply
variables or placeholders that are filled with actual values (such as consumption, price) at runtime.

(C) SAP AG IUT230 3-29
© SAP AG 1999
Billing Modules: 5
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-30
© 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.

(C) SAP AG IUT230 3-31
© 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.

(C) SAP AG IUT230 3-32
© 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.

(C) SAP AG IUT230 3-33
© SAP AG 1999
Operand
categories
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

(C) SAP AG IUT230 3-34
© 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.

(C) SAP AG IUT230 3-35
© SAP AG 1999
Demands
Contractual
Activities
Billed Demands
Ordered Demand 25 kW
Minimum Demand 10 kW
Maximum Demand 32 kW
..........
..........
Operand Groups
O
p
e
r
a
n
d
s
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.

(C) SAP AG IUT230 3-36
© 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.

(C) SAP AG IUT230 3-37
© 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.

(C) SAP AG IUT230 3-38
© 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.

(C) SAP AG IUT230 3-39
© SAP AG 1999
Demand
01/03 01/28
01/29 03/08
03/09 03/14
03/15 Last
day of
month
10 kW
11 kW
12 kW
13 kW
Rate1
Rate2
01/03 02/05
02/06 03/30
01/03
03/30
Bill. Period
All values are considered :
All values are considered :
Demand
01/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.

(C) SAP AG IUT230 3-40
© SAP AG 1999
The value at the end of the billing period is valid
The value at the end of the billing period is valid
Demand
13 kW
03/30
01/03
13 kW
02/05
02/06
Access Control: Example 2
Demand
01/03 01/28
01/29 03/08
03/09 03/14
03/15
10 kW
11 kW
12 kW
13 kW
Rate1
Rate2
01/03 02/05
02/06 03/30
01/03
03/30
Bill. 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.

(C) SAP AG IUT230 3-41
© SAP AG 1999
Allocation of Operand Values: 1
Rate Category Facts
Rate Category Facts
Rate Facts and Rate Fact Group
Rate Facts and Rate Fact Group
Have precedence over
Have precedence over
H

i

e

r

a

r

c

h

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

(C) SAP AG IUT230 3-42
© SAP AG 1999
Contract-Related Operand – Not Activated
Contract
2
Contract
2
Customer
2
Customer
2
Customer
1
Customer
1
Contract
1
Contract
1
Move-out
Utility Installation
Utility 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. 1 Aug. 1
Installation facts
Installation 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.

(C) SAP AG IUT230 3-43
© SAP AG 1999
Contract-Related Operand - Activated
Utility Installation
Utility Installation
Interval 1:
04/15/97- 07/31/01
Interval 2:
08/01/01
May 1 June 1 July 1 Sep. 1 Oct. 1 Nov. 1 Aug. 1
Installation Facts
Installation Facts
Move-out
Move-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.

(C) SAP AG IUT230 3-44
© SAP AG 1999
Contract-Related Operand - Move-In
Contract
2
Contract
2
Customer
2
Customer
2
Customer
1
Customer
1
Contract
1
Contract
1
Move-out
Utility Installation
Utility 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. 1 Aug. 1
Installation Facts
Installation Facts
Facts?
Facts?
Installation Facts
Installation 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.

(C) SAP AG IUT230 3-45
© SAP AG 1999
Contract-Related Operand - Contract Change
Contract
2
Contract
2
Customer
2
Customer
2
Customer
1
Customer
1
Contract
1
Contract
1
Move-out
Utility Installation
Utility 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. 1 Aug. 1
Installation Facts
Installation Facts
Facts?
Facts?



Þ If you execute the contract change function during the move-in, the time slices that were deactivated by
the move-out are reactivated in the installation facts as of the move-in date. Note that, in this case, the
business partner is not changed. The existing contract is replaced by a new one. If the move-in is
reversed, the active time slices as of the move-in date are deactivated again.

(C) SAP AG IUT230 3-46
© SAP AG 1999
IS-U billing schema
IS-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).

(C) SAP AG IUT230 3-47
© SAP AG 1999
Billing Modules: 6
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-48
© 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.

(C) SAP AG IUT230 3-49
© 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.

(C) SAP AG IUT230 3-50
© 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)

(C) SAP AG IUT230 3-51
© SAP AG 1999
Billing Modules: 7
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-52
© 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).

(C) SAP AG IUT230 3-53
© 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.

(C) SAP AG IUT230 3-54
© 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.

(C) SAP AG IUT230 3-55
© SAP AG 1999
Transactions
• Account
determination
• 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
Main
Trans-
actions
FI-CA
IS-U
Trans-
actions
IS-U
Allocation
IS-U
Internal
Sub-Trans.
SAP
Internal
Main 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.


(C) SAP AG IUT230 3-56
© SAP AG 1999
Sub-Transactions in IS-U Billing / Invoicing
Main
Trans.
Periodic
Billing
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
Receivable
Periodic Billing
Receivable
Periodic Billing
Credit Memo
Periodic Billing
Credit Memo
Periodic 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.

(C) SAP AG IUT230 3-57
© 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 Plan
Debit
Main
Trans.
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.

(C) SAP AG IUT230 3-58
© SAP AG 1999
Account Determ.
(PosAr R000)
Company Code 0001
Division 01
Account
determination ID 01
Balance sheet
account 140500
(Receivables for
energy supply)
Receivables
Account
Account Determination: Receivables Account
Contract /
Contract Account
For example, billing:
Main trans. 0010
Business
Transaction



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


(C) SAP AG IUT230 3-59
© SAP AG 1999
For example, billing:
Main trans. 0010
Sub-trans. 0010
Business
Transaction
Contract /
Contract Account
Company Code 0001
Division 01
Account
determination ID 01
Account Determ.
(PosAr R001)
Transaction
Determination
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.


(C) SAP AG IUT230 3-60
© SAP AG 1999
IMG IMG
...........
..........
..........
..........
Customizing for
Time 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 days
º 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.


(C) SAP AG IUT230 3-61
© SAP AG 1999
Variant Control
COMPUT01
COMPUT02
COMPUT03
COMPUT04
COMPUT08
QUANTI02
QUANTI08
QUANTI09
QUANTI10
QUANTI15
COMPUT01
COMPUT02
COMPUT03
COMPUT04
COMPUT08
QUANTI02
QUANTI08
QUANTI09
QUANTI10
QUANTI15
• 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.


(C) SAP AG IUT230 3-62
© SAP AG 1999
Billing Master Data: 3
¤ Individual Components
¤ Modeling of the Billing Logic
¤ Facts
¤ Dynamic Rate Determination




(C) SAP AG IUT230 3-63
© SAP AG 1999
Billing Modules: 8
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-64
© SAP AG 1999
Fact
Group
Fact Group
Rate
Operand
Value A
Operand
Value 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.
Þ 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.


(C) SAP AG IUT230 3-65
© SAP AG 1999
Price C
0.70
Price C
0.70
Price B
0.60
Price B
0.60
Rate category
facts
Rate category Rate category
facts facts
Rate facts and rate fact group Rate facts and rate fact group Rate facts and rate fact group
Have precedence over
Have precedence over
Price A
0.55
Price A
0.55
H

i

e

r

a

r

c

h

y
Allocation 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.
Þ 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).

(C) SAP AG IUT230 3-66
© 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
Rate
Rate
Installation
Facts
Installation
Facts
Rate Facts
Rate Facts
Rate Category
Facts
Rate Category
Facts




(C) SAP AG IUT230 3-67
© SAP AG 1999
Contract Billing Modules: 9
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-68
© 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.


(C) SAP AG IUT230 3-69
© 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




(C) SAP AG IUT230 3-70
© 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 energy
º Off-peak rate active energy
º On-peak rate active power
Þ The presort key plays an important role in sorting individual billing line items for subsequent bill
printout. We will look at the function of the presort key in more detail later on.
Þ The deletion operand is required if billing line items have to be deleted while a contract is being billed,
for example, in comparisons such as best-rate billing or maximum price limitation. The billing line items
that are to be deleted must be provided with a deletion operand.

(C) SAP AG IUT230 3-71
© 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.

(C) SAP AG IUT230 3-72
© 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.



(C) SAP AG IUT230 3-73
© SAP AG 1999
Billing Modules: 10
¤ Billing Class
¤ Rate Type
¤ Price
¤ Operand
¤ Variant Program
¤ Rate
¤ Fact Group
¤ Schema
¤ Rate Category




(C) SAP AG IUT230 3-74
© 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
º Basic price rate 1
º Basic price rate 2
º Domestic water
º Reserve wasser
º Water for fire fighting
Þ Rate determination:
rate type + rate category = rate

(C) SAP AG IUT230 3-75
© SAP AG 1999
Rate
Category
Billing Class
Outsorting
Group
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).





(C) SAP AG IUT230 3-76
© SAP AG 1999
Billing Master Data: 4
¤ Individual Components
¤ Modeling of the Billing Logic
¤ Facts
¤ Dynamic Rate Determination




(C) SAP AG IUT230 3-77
© SAP AG 1999
Rate
Category
Rate
Category
Rate Type
Rate Type
Historical
Dynamic Rate Determination
Rate
Rate
Rate
Rate
Rate
Rate
Rate
Rate
Rate
Rate
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).



(C) SAP AG IUT230 3-78
© SAP AG 1999
Rate type (e.g. on-peak rate)
Rate type (e.g. ripple control receiver)
Rate category (e.g. flat-rate installation)
Billing
Master Data
Rate category (e.g. flat-rate installation)
Installation
Structure
Register
Device
Billing-Relevant
Objects
Use of Rates
Rate Category
Facts
Installation
Facts



Þ The rate is comprised of a combination of the rate type and the rate category.
Þ The rate type is generally maintained in the register. In some cases, it can be maintained at device level
or in the installation facts. In addition, the rate type can be entered in the rate category facts (for
example, if a device does not exist).
Þ A rate type for reference values can also be defined in the installation facts (for example for street
lighting, telephone booths).


(C) SAP AG IUT230 3-79
© SAP AG 1999
Initial Data Creation of a Rate
Rate Type
Rate Type
Prices (create from rate)
Prices (create from rate)
L
i
n
k

t
o
f
a
c
t

g
r
o
u
p
Determine
Variant
Programs
Variant
Programs
Determine
Rate
Sequence
Rate
Sequence
Select
Billing
Schema
Billing
Schema
Allocate
Rates
Rates
Rate
Category
Rate
Category
Rates
Rates
Billing Schema
Billing 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.

(C) SAP AG IUT230 3-80
© 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/kWh
0.11 UNI/kWh
50 UNI/year
70 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.

(C) SAP AG IUT230 3-81
© 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




(C) SAP AG IUT230 3-82
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


(C) SAP AG IUT230 3-83

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

(C) SAP AG IUT230 3-84

Subtransactions: 0011
0021
0110
0120
Variant programs: COMPUT19
LUMSUM01
REFVAL01
SETTLE01

QUANTI01
QUANTI03
QUANTI04
QUANTI05
QUANTI11
QUANTI19
QUANTI21
UTILIT02




(C) SAP AG IUT230 3-85
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?
_________________________________________________________

(C) SAP AG IUT230 3-86
Exercises


Unit: Billing Master Data
Topic: Price


• Find the price definition in the implementation guide.
• Define a new price key for an energy price.
• Adjust an existing price key.

New price keys have to be specified in the system to define the new rate.
An existing price is adjusted to accommodate a price adjustment on
January 1
st
.
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


(C) SAP AG IUT230 3-87
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 1
st
of this year.
A price for billing kilowatt-hours in the electricity sector.
Initial data
Price TE1_1_2##
Transaction currency UNI
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.
_________________________________________________________

(C) SAP AG IUT230 3-88
Exercises


Unit: Billing Master Data
Topic: Operand


• Describe the relationship between the operand category and operand.
• Display an operand.

Certain operands have to be used to define new electricity rates. Suitable
operands must be determined for variant programs.
3-1 Various discounts are needed to map the new rate.
3-1-1 Using the operand list, determine which operand categories are available in the
system for mapping discounts and surcharges.
____________________________________________________________
3-1-2 Which operands are maintained in the system for the operand category quantity
discount?
____________________________________________________________
3-2 Consumption is billed with a variant program by using the operands
EQUANT___1 and EQPRICE__1.
3-2-1 Which operand category does the operand EQPRICE__1 belong to?
____________________________________________________________
3-2-2 How is the quantity operand EQUANT___1 rounded off?
____________________________________________________________

(C) SAP AG IUT230 3-89

(C) SAP AG IUT230 3-90
Exercises


Unit: Billing Master Data
Topic: Variant Programs


• Describe the relationship between operands and variant programs.
• Find a variant program necessary for a billing step.
• The online documentation helps you to understand variant programs.

Certain variant programs must be used to define the new rates. You have
to determine suitable variant programs to calculate accordingly.
4-1 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.

(C) SAP AG IUT230 3-91

(C) SAP AG IUT230 3-92
Exercises


Unit: Billing Master Data
Topic: Rate

• Find the definition of a rate in the implementation documentation.
• Find and describe the components of a rate.
• Create a new rate.
• Create and change the facts of a rate.

The new contract contains a rate for billing an energy price according to
which 60% of the consumption is billed with one price and the other 40%
with another price.
5-1 Check the definition of the rate in the implementation guide.
5-1-1 Which menu path would you use to define a rate?
____________________________________________________________
5-2 Display the definition of rate TE1_1## in the system.
5-2-1 What do you control by using the Min.port. (minimum portion) field? Which
value is used to extrapolate consumption when meter reading results are
missing?
____________________________________________________________
5-2-2 How many and which variant programs are used in the rate? Go to the rate steps
to find out.
____________________________________________________________
5-2-3 Which output operand is used to determine the amount?
____________________________________________________________

(C) SAP AG IUT230 3-93
5-3 Create a new rate using the following.
5-3-1 A rate for billing electricity consumption.
Header data
Rate PE1_1##
Data
Division Electricity
Text Rate ##
Billing class Residential customer
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

(C) SAP AG IUT230 3-94

(C) SAP AG IUT230 3-95
Exercises


Unit: Billing Master Data
Topic: Facts

• Describe the definition of a fact group.
• Maintain the facts of a rate.
• Find the different operand values at all hierarchy levels.

The new rate is valid for two different contract forms. These differ only
in the portion of consumption quantity. In addition, special terms are
agreed for a special business partner. The standard breakdown is 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

(C) SAP AG IUT230 3-96
Exercises


Unit: Billing Master Data
Topic: Schema / Rate Category

• The online documentation helps you to understand schemas.
• Create a new schema and a new rate category.
• Determine and display the rates of a schema.

After all the necessary rates have been defined, they are brought together
to form an overall billing design. by creating a new billing schema. This
billing schema is entered in a new rate category as a standard schema.
7-1 Read the online documentation.
7-1-1 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 ##
Division Electricity
Billing class Residential customer
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?
________________________________________________________


(C) SAP AG IUT230 3-97
7-2-3 Use your new schema to define a new rate category. Take the following
information into account.
Rate category of the electricity division
Header data
Rate category PE1##
Division Electricity
Data
Text Rate category ##
Billing class Residential customer
Outsorting group Residential customer
Statistics group Residential customer
Billing schema PE1##
Backbilling No backbilling
Period-end billing No period-end billing
Facts Not required, values are taken from rates

(C) SAP AG IUT230 3-98
Billing Master Data: Solutions


Unit: Billing Master Data
Topic: Rate Type
1-1 Check the implementation guide (SAP Reference IMG) for information regarding rate
types and answer the following questions.
From the SAP menu, choose Tools ¬ ¬¬ ¬ 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

(C) SAP AG IUT230 3-99
Solutions


Unit: Billing Master Data
Topic: Price
2-1 Check the price definition in the implementation guide.
2-1-1 Which menu path would you use to define a price?
In the SAP Reference IMG, choose: SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Prices → →→ → Define Prices.
2-1-2 Which elements must you maintain before you can define a rental price?
Price classes and price levels
2-2 Enter a new price using the following data.
A price for billing kilowatt-hours in the electricity sector.
In the SAP Reference IMG, choose: SAP Utilities → →→ → Contract Billing → →→ → Billing
Master Data → →→ → Rate Structure → →→ → Prices → →→ → Define Prices → →→ → Create Prices.
Maintain the field contents in the data screen as described in the exercise and save.

(C) SAP AG IUT230 3-100
2-3 Maintain an existing price key by raising the price from January 1
st
of this year.
A price for billing kilowatt-hours in the electricity sector.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ → Billing
Master Data → →→ → Rate Structure → →→ → Prices → →→ → Define Prices → →→ → Change Prices.
In the initial screen, enter the price key TE1_1_2##.
Maintain the field contents in the data screen as described in the exercise and save.
2-4 True or false.
2-4-1 The decision as to whether the price is quantity or time-based is made using the
price type.
False
2-4-2 A time-based price depends not only on a quantity, but also on a time period.
True
2-4-3 A price adjustment clause can only be used to add changes to a base price.
False

(C) SAP AG IUT230 3-101
Solutions


Unit: Billing Master Data
Topic: Operand
3-1 Various discounts are needed to map the new rate for the electricity division.
3-1-1 Using the operand list, determine which operand categories are available in the
system for mapping discounts and surcharges.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Operands → →→ → Define Operands
→ → → → Display 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?
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.
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 SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Operands → →→ → Define Operands
→ → → → Display Operands .
In the initial screen, enter the operand EQPRICE__1.
Operand categor : QPRICE
3-2-2 How is quantity operand EQUANT___1 rounded off?
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Operands → →→ → Define Operands
→ → → → Display Operands .
In the initial screen, enter the operand EQUANT__1.
Rounding: 0 to whole numbers
Rounding cat.: X round up or down to nearest whole number

(C) SAP AG IUT230 3-103
Solutions


Unit: Billing Master Data
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.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
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 Read the online documentation.
4-2-1 Select program QUANTI03 from the variant list.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Analyze Variant Programs.
Enter the value 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


Unit: Billing Master Data
Topic: Rate
5-1 Check the definition of the rate in the implementation guide.
5-1-1 Which menu path would you use to define a rate?
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → →→ → Define Rates → →→ → Create
Rates/Change Rates/Display Rates.
5-2 Display the definition of rate TE1_1## in the system.
5-2-1 What do you control by using the Min.port. (minimum portion) field? Which
value is used for extrapolation when meter reading results are missing?
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → →→ → Define Rates → →→ → Display
Rates.
In the initial screen, enter the rate TE1_1_2##.
Register-based data, Min.port.: 60 %
This field is used to determine periods in which meter reading results must be
available for the system to be able to extrapolate. If there are no meter
reading results, the system uses the period consumption.
5-2-2 How many and which variant programs are used in the rate? Go to the rate steps
display to find out.
Select Rate Steps.
Number of variant programs: 4
Variant programs:
QUANTI01
LUMSUM01
REFVAL01
SETTLE01

(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.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → →→ → Define Rates → →→ → Create
Rates.
In the initial screen, enter the rate PE1_1##.
Maintain the field content as described in the exercise.
Select Rate Steps.
Maintain the field content in the Rate Steps as described in the exercise and
save.
Variant programs:
QUANTI05
QUANTI04
QUANTI01 ( twice )
Processes: Debit energy charge 0021
Credit energy charge 0011
Extrapolation budget billing 0120
Extrapolation budget billing 0110

(C) SAP AG IUT230 3-107
Solutions


Unit: Billing Master Data
Topic: Facts
6-1 Check the definition of the fact group in the implementation guide.
6-1-1 Which fact group is maintained in the system for residential customers?
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → → → → Define Rate Fact Groups.
Rate fact group: 0001 Residential customers
6-1-2 With which element of the rate structure is the fact group linked?
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → → → → Define Rate Fact Groups.
Highlight the menu entry. Select Documentation by clicking on the menu
entry.
Linked element: Rate type
6-2 Determine the factor for the consumption breakdown for the business partner
TF0415A0##
6-2-1 In which master data object is the factor entered?
From the SAP menu, choose: Utilities Industry → → → → Customer Service → →→ → Front
Office/Customer Interaction Center → →→ → Customer Interaction Center
Enter the business partner's number TF0415A0## in the Business partner
field group and press Enter.
In the navigation area (Environment tab page), select the installation and call
up the installation display (double-click the installation data object). Call up
the facts display.
6-2-2 Which factor is used for the business partner?
Select the operand EFACTOR__1
Operand value: EFACTOR__1 0,5

(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.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → →→ → Define Rates → →→ → Change
Rates.
Enter the rate number PE1_1## in the initial screen.
Select Facts.
Select operand EQPRICE__1. Select Create operand values. Maintain the
contents in the data screen as described in the exercise and save.

(C) SAP AG IUT230 3-109
Solutions


Unit: Billing Master Data
Topic: Schema / Rate Category
7-1 Read the online documentation.
7-1-1 Select the menu path Define schemas using the implementation guide.
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Schemas → →→ → Define Schemas.
7-1-2 Access the documentation from the menu.
Choose Define schemas.
7-1-3 Read the information regarding prerequisites.
7-2 Create a new billing schema using the following data.
7-2-1 An electricity billing schema
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Schemas → →→ → Define Schemas → →→ →
Create Schemas.
Enter the name of the schema (PE1## ) in the Billing schema field.
Maintain the contents as described in the exercise. Select the Set default
values icon.
Select Insert rate and select the rate PE1_1##.
Save.
7-2-2 Display the operand list for your schema. How many operand categories do you
use?
Select Goto → → → → 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
In the SAP Reference IMG, choose SAP Utilities → →→ → Contract Billing → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rate Categories → →→ → Define Rate
Categories → →→ → Create Rate Categories.
In the initial screen, enter the key PE1## in the Rate cat. field, and 01 in the
Division field.
Maintain the contents in the data screen as described in the exercise and
save.


(C) SAP AG IUT230 4-1
© 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




(C) SAP AG IUT230 4-2
© SAP AG 1999
At the conclusion of this unit, you will be able to:
¤ 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




(C) SAP AG IUT230 4-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billings Budget Billings Budget Billings
Additional Functionality:
Discount/Surcharge
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discount/Surcharge Discount/Surcharge
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 4



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

(C) SAP AG IUT230 4-4
© SAP AG 1999
¤ Master Data Relevant to Billing
¤ Check Functions
¤ Special Billing Models
¤ Transport of Billing Master Data
Use of Rates in Master Data: 1




(C) SAP AG IUT230 4-5
© SAP AG 1999
Contract
Rec. & Payable
Contract
Rec. & Payable
Connection Connection
Contract
(Supply)
Contract
(Supply)
Consumption
Premise
Consumption
Premise
Business
Partner
Business
Partner
Regional
Structure
Regional
Structure
Meter
Reading
Meter
Reading
Device Device
Utility
Installation
Utility
Installation
Connection
Object
Connection
Object
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.

(C) SAP AG IUT230 4-6
© SAP AG 1999
Rate Type
Rate Category
Register
Device
Utility Installation
¤ On-peak rate active
energy
¤ Off-peak rate active
energy
¤ On-peak rate reactive
energy
¤ Off-peak rate reactive
energy
¤ Gas consumption
¤ Water consumption
¤ Interval meter
¤ Flat-rate installations
¤ Reference values
¤ Fact group for period-
end billing
¤ Rental price
(device-related)
¤ Flat-rate installations
¤ Additional rates
Rate Type



Þ 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.
Þ The permissibility indicator in the rate type enables you to specify where the rate type can be allocated.



(C) SAP AG IUT230 4-7
© SAP AG 1999
Extension: EBIS0002
Extension: EBIS0002
Rate Type
Rate Type Rate Fact Group
Rate Fact Group
EXIT_SAPLE20Q_001 Search help rate type
EXIT_SAPLE20Q_002 Search help rate fact group
EXIT_SAPLE20Q_003 Checks
EXIT_SAPLE20Q_004 Proposal logic
EXIT_SAPLE20Q_001 Search help rate type
EXIT_SAPLE20Q_002 Search help rate fact group
EXIT_SAPLE20Q_003 Checks
EXIT_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.

(C) SAP AG IUT230 4-8
© SAP AG 1999
Rate
Category
Billing Class
Outsorting
Group
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).





(C) SAP AG IUT230 4-9
© SAP AG 1999
¤ Master Data Relevant to Billing
¤ Check Functions
¤ Special Billing Models
¤ Transport of Billing Master Data
Use of Rates in Master Data: 4




(C) SAP AG IUT230 4-10
© 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.


(C) SAP AG IUT230 4-11
© SAP AG 1999
Automatic billing and simulation: Initial Screen
Display document Billing reversal Invoicing simulation Display print document
Status
Log
Log
Overall check
Billing types
Simulation
Billing simulation
Billing
-
31.12.9999
Portion
Selection criteria
Contract
Installation
Contract acct.
Billing order selec.
Billing procedure
Division
Company code
End of runtime
Check runtime
Date
Time
31.12.9999
13: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.

(C) SAP AG IUT230 4-12
© SAP AG 1999
¤ Master Data Relevant to Billing
¤ Check Functions
¤ Special Billing Models
¤ Transport of Billing Master Data
Use of Rates in Master Data: 5




(C) SAP AG IUT230 4-13
© 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.



(C) SAP AG IUT230 4-14
© 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.


(C) SAP AG IUT230 4-15
© 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.


(C) SAP AG IUT230 4-16
© SAP AG 1999
Rate
Category
Rate
Category
Rate Determ.
Rate Determ.
Billing Schema
Billing Schema
Rate 1
Step 1
Step 2
Rate n
Step 1
Variant Program
e.g. Quantity x Price
Comparison of two
demands
Rate Type
Rate Type
Utility Installation
Utility Installation
Installation Structure
Installation Structure
Rates
Variant Program
Rates
Variant Program
Billing in
Advance
Control
Indicator for Billing
in Advance
Data Model for Billing in Advance




(C) SAP AG IUT230 4-17
© 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.

(C) SAP AG IUT230 4-18
© SAP AG 1999
Controlling the Gross Price in the Schema
¤ Ensures that the billing line items
contain gross prices. The tax is not
calculated.





(C) SAP AG IUT230 4-19
© SAP AG 1999
Price Definition Rate Data
Prices and
Rate Facts
Prices and
Rate 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
Billing
Line Items
Check Billing
Results
Execute
Variant in
Programs
in Acc. With
Schema
Net Price
and
Gross Price
Gross
Group
Gross
Line 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.

(C) SAP AG IUT230 4-20
© SAP AG 1999
Gross Group
Gross Line Item
Net Price
Net Price
Variant Pr. Operand Gross group Gross line item Relevant to Posting
QUANTI01 BPrice ABC X BLANK
QUANTI01 NPrice ABC BLANK X
QUANTI01 KAbgabe ABC BLANK X
Gross Price
Gross 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.

(C) SAP AG IUT230 4-21
© SAP AG 1999
¤ Master Data Relevant to Billing
¤ Check Functions
¤ Special Billing Models
¤ Transport of Billing Master Data
Use of Rates in Master Data: 6




(C) SAP AG IUT230 4-22
© SAP AG 1999
P
r
ic
e
s
O
p
e
r
a
n
d
s
R
a
t
e
s
S
c
h
e
m
a
s
R
a
t
e
C
a
t
e
g
o
r
i
e
s
R
a
t
e

D
e
t
e
r
m
in
a
t
i
o
n
s
CUST
QTST
Complete 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.

(C) SAP AG IUT230 4-23
© 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




(C) SAP AG IUT230 4-24
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 1
st
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?
____________________________________________________________


(C) SAP AG IUT230 4-25
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
Division Electricity
Text (on-peak rate) On-peak rate ##
Text (off-peak rate) Off-peak rate ##
Register operand (on-peak rate) EQUANT___1
Register operand (off-peak rate) EQUANT___2
Rate steps (on-peak rate):
1. Valuate the on-peak rate quantity with a quantity-based price (energy price)
2. Calculate a fixed demand price (basic flat-rate price)
3. Valuate the on-peak rate quantity with a quantity-based price (maximum
price).
4. Compare the amount operand from steps 1 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)


(C) SAP AG IUT230 4-26
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 1
st
of
this year as the valid date.
1-3-6 Test your rate using the data construct TF0503A0##.


(C) SAP AG IUT230 4-27
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 1
st
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

(C) SAP AG IUT230 4-28
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
Master Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Define Rate Determination.
Select the rate determination list.
Choose Execute.
Rate: E1_1
1-2-6 Which billing schema is linked to the rate category?
In the SAP Reference IMG, choose SAP Utilities ¬ ¬¬ ¬ Contract Billing ¬ ¬¬ ¬ Billing
Master Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Rate Categories ¬ ¬¬ ¬ Define Rate Categories
¬ ¬¬ ¬ Display Rate Categories.
Enter the rate category E1 in the initial screen.
Billing schema: E1
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.
Enter the installation number TF0502A0## in the initial screen.
Select the installation facts.
No facts are available. No special price is used.

(C) SAP AG IUT230 4-29
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.
In the SAP Reference IMG, choose SAP Utilities ¬ ¬¬ ¬ Contract Billing ¬ ¬¬ ¬ Billing
Master Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Rates ¬ ¬¬ ¬ Define Rates ¬ ¬¬ ¬ Create Rates.
Enter the rate PE2_1## and PE2_2## in the initial screen (execute twice).
Maintain the field content as described in the exercise.
Select Rate Steps.
Maintain the field content in the Rate Steps as described in the exercise and
save.
Variant programs: PE2_1##
QUANTI01 (energy price)
LUMSUM01 (fixed basic price)
QUANTI01 (maximum price)
UTILIT02 (maximum price limitation)
SETTLE01 (rental price)
Variant programs: PE2_2##
QUANTI01 (energy price)

1-3-2 Maintain the facts for both rates. Supply the operands with values. Use the
existing price key.
In the SAP Reference IMG, choose SAP Utilities ¬ ¬¬ ¬ Contract Billing ¬ ¬¬ ¬ Billing
Mater Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Rates ¬ ¬¬ ¬ Define Rates ¬ ¬¬ ¬ Create/Change
Rates.
You can also create and maintain facts directly from the rates transaction.
Select Facts.
Select Create Operand Values. Maintain the contents in the data screen as
described in the exercise and save.

(C) SAP AG IUT230 4-30
1-3-3 Create a new billing schema using the following data. Apply the rates you
created earlier.
In the SAP Reference IMG, choose SAP Utilities ¬ ¬¬ ¬ Contract Billing ¬ ¬¬ ¬ Billing
Master Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Schemas ¬ ¬¬ ¬ Define Schemas Create
Schemas.
Enter the name of the schema (PE2## ) in the Billing schema field.
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:
In the SAP Reference IMG, choose SAP Utilities ¬ ¬¬ ¬ Contract Billing ¬ ¬¬ ¬ Billing
Master Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Rate Categories ¬ ¬¬ ¬ Define Rate Categories
¬ ¬¬ ¬ Create Rate Categories.
In the initial screen, enter the key PE2## in the Rate cat. field, and 01 in the
Division field.
Maintain the contents in the data screen as described in the exercise and save.

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 1
st
of
this year as the valid date.
In the SAP Reference IMG, choose SAP Utilities ¬ ¬¬ ¬ Contract Billing ¬ ¬¬ ¬ Billing
Master Data ¬ ¬¬ ¬ Rate Structure ¬ ¬¬ ¬ Define Rate Determination.
Enter the rate type and rate category in the initial and data screens as described in
the exercise and save.

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


(C) SAP AG IUT230 5-1
© SAP AG 1999 © SAP AG 2001
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing
Billing




(C) SAP AG IUT230 5-2
© SAP AG 1999
Billing: Unit Objectives
© SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ 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




(C) SAP AG IUT230 5-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing
Budget Billings Budget Billings Budget Billings
Additional Functionality:
Discount/Surcharge
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discount/Surcharge Discount/Surcharge
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 5



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


(C) SAP AG IUT230 5-4
© SAP AG 1999
Billing: 1
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing




(C) SAP AG IUT230 5-5
© SAP AG 1999
MO TU WE TH FR SA SU
1
8
15
21
28
2
9
16
22
29
3
10
17
23
30
4
11
18
24
31
5
12
19
25
6
13
20
26
7
14
21
27
¤ 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:
Þ For an exact number of days
Determines the exact length of the billing period in days, for example the period between the last billed
meter reading and the current day of meter reading.
Þ Month-based
Bills a specific number of complete months. If the case of a move-in or move-out, the month-based
procedure can be billed based on the number of days.



(C) SAP AG IUT230 5-6
© 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.



(C) SAP AG IUT230 5-7
© 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).





(C) SAP AG IUT230 5-8
© SAP AG 1999
Meter
Reading
Order
Billing Order
Invoicing
Invoicing
Creation of
Meter Reading Order
Creation of
Meter Reading Order
Entry of
Meter Reading Data
Entry of
Meter Reading Data
Billing
Billing
Billing Document
Implausible Meter
Reading Results
Plausible
Meter Reading
Results
Billing Order
Correction of
Meter Reading Results
Correction of
Meter Reading Results
Print Document
Billing
Printout
Billing
Printout
The Billing Process




(C) SAP AG IUT230 5-9
© SAP AG 1999
Billing
Billing
Invoicing
Invoicing
¤ 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.


(C) SAP AG IUT230 5-10
© 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
¤ Quantity conversion
¤ Proration
¤ Execution of variant programs
¤ Creation of billing documents with billing line items
¤ The billing document forms the base for the
communication structure (UIS - Sales Statistics)




(C) SAP AG IUT230 5-11
© 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




(C) SAP AG IUT230 5-12
© 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:
$100
Receivables:
100 UNI
Manual Billing
Print
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)

(C) SAP AG IUT230 5-13
© SAP AG 1999
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing
Billing: 2




(C) SAP AG IUT230 5-14
© 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.


(C) SAP AG IUT230 5-15
© 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.


(C) SAP AG IUT230 5-16
© SAP AG 1999
Portion
P_AUG01
Portion
P_AUG01
Meter reading unit
A_AUG01
Meter reading unit
A_AUG01
P1 P1
Parameter Record Parameter Record
Schedule Master Records
A_AUG01 2001 A_AUG01 2001
A_AUG01 2000 A_AUG01 2000
A_AUG01 1999 A_AUG01 1999
Meter reading unit Meter reading unit
Schedule Records
P_AUG01 2001 P_AUG01 2001
P_AUG01 2000 P_AUG01 2000
P_AUG01 1999 P_AUG01 1999
Portion Portion
Generation
of
Schedule
Records
Generation
of
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.


(C) SAP AG IUT230 5-17
© SAP AG 1999
Scheduling: Annual Billing
2000
2000
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
2001
2001
Portion 1
07/27 07/28 07/29 07/30 07/31 08/01 08/02 08/03
Sched.
Meter
Reading
Date
Billing Period
Meter reading period for meter reading unit 1
Meter reading period for meter reading unit 2
Meter reading period for meter reading unit 3
For all meter reading units
End
of
Meter
Reading
Period
End
of
Billing
Per-
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)




(C) SAP AG IUT230 5-18
© 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.




(C) SAP AG IUT230 5-19
© 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.


(C) SAP AG IUT230 5-20
© SAP AG 1999
Billing
Order
Effect on the Billing Order
Effect on the Billing Order
Activities
Activities
¤ 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.


(C) SAP AG IUT230 5-21
© 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.


(C) SAP AG IUT230 5-22
© SAP AG 1999
Billing: 3
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing




(C) SAP AG IUT230 5-23
© SAP AG 1999
Simulation
Consumption
Extrapolation
Determination of
Rate Data
Simulation
Billing
Simulation
Types of Simulation Functions
Generation of
Billing Document
Simulation Functions
Determination of
Meter 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.



(C) SAP AG IUT230 5-24
© SAP AG 1999
Billing Simulation/Simulation
Billing Order
No billing order available!
Simulation period must be specified.
Billing Simulation
Billing Simulation
Simulation
Simulation
¤ 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.

(C) SAP AG IUT230 5-25
© SAP AG 1999
Differences Between Billing and Simulation
Simulation
Billing
Billing
Simulation
Simulation
¤ 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.


(C) SAP AG IUT230 5-26
© SAP AG 1999
Billing
Documents
Billing
Documents
Mass Simulation
Portion
Portion
Invoicing
Documents
Invoicing
Documents
Purpose
Purpose
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




(C) SAP AG IUT230 5-27
© SAP AG 1999
Billing: 4
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing




(C) SAP AG IUT230 5-28
© 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.



(C) SAP AG IUT230 5-29
© SAP AG 1999
Mass Billing and Mass Overall Check
Individual Processing
Individual Processing
Mass Processing
Mass 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.


(C) SAP AG IUT230 5-30
© SAP AG 1999
Line Item Types Relevant to Posting
Line Item Types Relevant to Posting
Information Line Items
Information 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.



(C) SAP AG IUT230 5-31
© SAP AG 1999
Line Item Types Relevant to Posting
Line Item Types Relevant to Posting
Information Line Items
Information 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.


(C) SAP AG IUT230 5-32
© 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.



(C) SAP AG IUT230 5-33
© SAP AG 1999
Billing: 5
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing




(C) SAP AG IUT230 5-34
© 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 Workflow Exception List or Workflow
not OK
Rel-
ease
Rel-
ease
Rel-
ease
Check
- standard
- company-
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.

(C) SAP AG IUT230 5-35
© SAP AG 1999
¤ Net amount checks
¤ Checks for budget billing
amounts
¤ Check for estimations
¤ Check for billing line items
Billing
Invoicing
Invoicing
Billing
Billing
¤ 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.

(C) SAP AG IUT230 5-36
© SAP AG 1999
Billing
Billing
Checks
Checks
Billings
to be checked
Release
Release
Reversal
Reversal
Invoicing
Invoicing
Automatic checks
Automatic checks
Manual outsorting
Manual outsorting
Electricity contract
manual
outsorting: 0001
Once
Electricity contract
manual
outsorting: 0001
Once
Billing
Billing
Billings
to be checked
Release
Release
Reversal
Reversal
Invoicing
Invoicing
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.


(C) SAP AG IUT230 5-37
© SAP AG 1999
Outsorting Groups:
Billing
0001 Res. customer
0002 Nonres. cust.
Outsorting Groups:
Billing
0001 Res. customer
0002 Nonres. cust.
Automatic Checks
Automatic 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 billing
02 Interim billing
03 Final billing
04 Period-end billing
05 Territory transfer
06 Manual billing
Billing Checks
Outsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1
Outsorting Group 0002 + Billing Procedure 01 = Check NO_LINES
Billing Checks
Outsorting 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.


(C) SAP AG IUT230 5-38
© SAP AG 1999
Billing Checks
¤ AMOUNT1
Amount check on net amount
¤ BBP_ABS1
Absolute deviation of budget billing
amount
¤ BBP_PERC1
Percentage 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.


(C) SAP AG IUT230 5-39
© SAP AG 1999
Customizing Functions: Billing
IMG IMG
..........
..........
..........
...........
¤ 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




(C) SAP AG IUT230 5-40
© SAP AG 1999
Billing: 6
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing




(C) SAP AG IUT230 5-41
© SAP AG 1999
Billing
doc.
100,-
Billing
doc.
100,-
Billing
doc.
.
.
.
Reversal
.
.
.
Renewed
Billing
111,-
.
.
.
Outsorting
Outsorting
Activities
Activities
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.


(C) SAP AG IUT230 5-42
© SAP AG 1999
Billing
Billing Billing
Document
Invoicing
Document
Invoicing
Invoicing
Billing
Outsorting
Billing
Outsorting
Invoicing
Outsorting
Invoicing
Outsorting
Billing
Reversal
Billing
Reversal
Invoicing
or Total
Reversal
Invoicing
or Total
Reversal
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).


(C) SAP AG IUT230 5-43
© 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




(C) SAP AG IUT230 5-44
© 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




(C) SAP AG IUT230 5-45
© SAP AG 1999
¤ Billing Process
¤ Data Elements of the Billing Process
¤ Billing Simulation
¤ Billing Documents
¤ Outsorting in Billing
¤ Billing Reversal
¤ Parallel Processing
Billing: 7




(C) SAP AG IUT230 5-46
© 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




(C) SAP AG IUT230 5-47
© SAP AG 1999
Interval
Size = 3
No. of
Intervals = 4
No. of
Intervals = 3
Interval
Size = 4
Interval_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)

(C) SAP AG IUT230 5-48
© 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




(C) SAP AG IUT230 5-49
© SAP AG 1999
m
OIs
m
OIs
m
OIs
...
Interval
1
Interval
4
Interval
9
Interval
3
Interval
6
Interval
2
Interval
10
Client A
Job 1
Client A
Job 2
...
Client X
Job n
Dispatcher for
Mass Data Program
m = block size
Parallel Processing - Realization




(C) SAP AG IUT230 5-50
© 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.




(C) SAP AG IUT230 5-51
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?
____________________________________________________________

(C) SAP AG IUT230 5-52
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?
____________________________________________________________


(C) SAP AG IUT230 5-53
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 1
st
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?
____________________________________________________________



(C) SAP AG IUT230 5-54


(C) SAP AG IUT230 5-55
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?
From the SAP menu, choose
Utilities Industry → →→ → Technical Master Data → →→ → Installation → →→ → Display.
Enter the installation number TF0601A0## in the initial screen.
Meter Reading Unit: T-C-00

1-1-2 To which portion is this meter reading unit allocated?
Mark the meter reading unit and branch to display the meter reading unit.
Portion: T-C-00

1-1-3 Which schedule records are generated for this portion?
From the SAP menu, choose
Utilities Industry → →→ → Scheduling → →→ → Schedule Record → →→ → Evaluation → →→ →
Schedule Record.
Select the Portion indicator and the time period January 1
st
1995 to
December 31
st
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.


(C) SAP AG IUT230 5-56
1-1-5 Which status does your business partner’s billing order have?
From the SAP menu, choose
Utilities Industry → →→ → Device Management → →→ → Meter reading → →→ → Monitoring → →→ →
Manual.
Choose Business partner. Enter the business partner TF0601A0## in the
Business partner field.
Choose Billing order
Execute.
Billing order status: 1

1-1-6 Which scheduled billing date does the billing order have?
Scheduled billing date: April 2
nd



(C) SAP AG IUT230 5-57
Solutions


Unit: Billing
Topic: Billing/Simulation
2-1 A meter reading order has already been created for the business partner TF0602A0##.
2-1-1 For which meter reading date is the order?
From the SAP menu, choose
Utilities Industry → →→ → Device Management → →→ → Meter reading → →→ → Monitoring → →→ →
Manual.
Choose Business partner. Enter the business partner TF0602A0## in the
Business partner field.
Select Meter reading order.
Execute.
Scheduled meter reading date: March 30
th


2-1-2 What is the meter reading order number?
From the SAP menu, choose
Utilities Industry → →→ → Device Management → →→ → Meter reading → →→ → Monitoring → →→ →
Manual.
Choose Business partner. Enter the business partner TF0602A0## in the
Business partner field.
Select Meter reading order.
Execute.
Take the number from the Entry no. field.


2-1-3 Go to the IS-U area device/meter reading and create a suitable meter reading for
your meter reading order.
From the SAP menu, choose
Utilities Industry → →→ → Device Management → →→ → Meter reading → →→ → Entry of Meter
Reading Results → →→ → Single Entry.
Enter the business partner TF0602A0## in the Business partner field and
select the meter reading reason 01.
Press Enter.
Enter a meter reading as described in the exercise and save.

(C) SAP AG IUT230 5-58
2-1-4 Carry out the billing procedure for the business partner.
Which document number does your bill have?
From the SAP menu, choose
Utilities Industry → →→ →Billing → →→ → Billing Execution → →→ → Individual Processing → →→ →
Individual Bill.
Select the selection criterion Contract and enter the contract TF0602A0##.
You can also enter meter readings directly using the individual bill
transaction.
Execute.
You will find the document number in the log following billing.

(C) SAP AG IUT230 5-59
Solutions


Unit: Billing
Topic: Simulation/Document Display
3-1 The billing simulation should be done for a period from January 1
st
of this year to
today’s date. Use the business partner TF0603A0## and the contract TF0603A0##.
3-1-1 What is the bill’s document number?
From the SAP menu, choose
Utilities Industry → →→ → Billing → →→ → Billing Execution → →→ → Individual Processing → →→ →
Individual Simulation → →→ → Billing.
Choose the simulation type Simulation. Select the time period specified in the
exercise. Select the selection criterion Contract and enter the contract
TF0603A0##.
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


(C) SAP AG IUT230 5-60
3-3 Display the current billing document for the business partner TF0605A0## and the
contract TF0605A0##.
3-3-1 How many billing line items does the document contain?
From the SAP menu, choose
Utilities Industry → →→ → Billing → →→ → Billing Execution → →→ → Display Document.
Look for the current billing document number of the business partner
TF0605A0##. Enter the business partner number in the selection data and
select Continue. Look for the current billing document for the contract above
and select it by double-clicking it.
Line item: number of document line items.

3-3-2 Which billing schema was used for billing?
Select the Int. billing data tab page.
Billing schema: E1



(C) SAP AG IUT230 6-1
© SAP AG 1999 © SAP AG 2001
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing




(C) SAP AG IUT230 6-2
© SAP AG 1999 © SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ Describe the invoicing functions
¤ Explain how items from accounts receivable and
payable are processed
¤ Explain how due dates are determined
¤ Describe credit processing
¤ Outline the concept of joint invoicing/integration
¤ Describe the outsorting concept
Invoicing: Unit Objectives




(C) SAP AG IUT230 6-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billings Budget Billings Budget Billings
Additional Functionality:
Discount/Surcharge
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discount/Surcharge Discount/Surcharge
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 6



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


(C) SAP AG IUT230 6-4
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 1




(C) SAP AG IUT230 6-5
© SAP AG 1999
Meter
Reading
Order
Invoicing
Invoicing
Creation of
Meter Reading Order
Creation of
Meter Reading Order
Entry of
Meter Reading Data
Entry of
Meter Reading Data
Billing
Billing
Billing Document Billing Order
Implausible Meter
Reading Results
Plausible
Meter Reading
Results
Billing Order
Correction of
Meter Reading Results
Correction of
Meter Reading Results
Print Document
Billing
Printout
Billing
Printout
Process of Billing/Invoicing




(C) SAP AG IUT230 6-6
© 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
¤ Quantity conversion
¤ Proration
¤ Execution of variant programs
¤ Creation of billing documents with billing line items
¤ The billing document forms the base for the communication
structure (UIS - Sales Statistics)
Billing Tasks




(C) SAP AG IUT230 6-7
© 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




(C) SAP AG IUT230 6-8
© 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:
$100
Receivables:
100 UNI
Manual Billing
Print
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)

(C) SAP AG IUT230 6-9
© SAP AG 1999
Invoicing
Budget Billing
Settlement
Settlement
1. Budget Billing
Account
Maintenance
Credit
Processing
Due Date
Determination
Budget Billing
Determination
Joint
Invoicing
Invoicing Functions
Cross-Company-
Code
Invoicing




(C) SAP AG IUT230 6-10
© SAP AG 1999
Periodic Billing
Periodic Billing
Interim Billing
Interim Billing
Final Billing
Final Billing
New budget billing
plan
01.01.2000
01.03.2000
01.05.2000
01.07.2000
......
Old budget billing
plan
01.01.1999
01.03.1999
01.05.1999
01.07.1999
......
Budget billing
plan
01.01.1999
01.03.1999
01.05.1999
01.07.1999
......
Old budget billing
plan
01.01.1999
01.03.1999
01.05.1999
01.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.

(C) SAP AG IUT230 6-11
© SAP AG 1999
Create Bill Create Bill Create Partial Bill Create Partial Bill
Document Date
Posting Date
Reconciliation Key
Document Date
Posting Date
Reconciliation Key
Simulation Simulation
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.

(C) SAP AG IUT230 6-12
© SAP AG 1999
Bill
Bill
x y z
Bill
Bill
x y z
Bill
Bill
x y z
Bill
Bill
x y z
Bill
Bill
x y z
Create
Bill
Create
Bill
End of runtime
Log
End of runtime
Log
Parallel
Processing
Parallel
Processing
Parallel
Processing
Parallel
Processing
Parallel
Processing
Parallel
Processing
Mass Processing
Create
Partial Bill
Create
Partial 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.


(C) SAP AG IUT230 6-13
© 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.

(C) SAP AG IUT230 6-14
© SAP AG 1999
Items:
03/10/99 155.43
03/10/99 0.03 -
Billing
amount
155.43 SFR
~ 155.40 SFR
Items:
03/10/99 940,145
03/10/99 145 -
Rounding Carried-Forward Rounding
Billing
amount
940,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.

(C) SAP AG IUT230 6-15
© SAP AG 1999
Additional
Functions
Additional
Functions
Event: 5010
Account
Maintenance
Event: 5010
LPC
Receivables
Event: 5010
Dunning
Event: 5010
Interest Calc.
on Cash Security
Deposits
Event: 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.


(C) SAP AG IUT230 6-16
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 2




(C) SAP AG IUT230 6-17
© 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.

(C) SAP AG IUT230 6-18
© SAP AG 1999
IMG IMG
...........
..........
..........
..........
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 +/- 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 Invoicing
Selection of items using
settlement type and category, main
and 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).

(C) SAP AG IUT230 6-19
© SAP AG 1999
Incoming Payment
Business
Transaction
Contract
Account
Clearing Entry
Selection
Restriction
Settlement Variant
Settlement Type
Settlement Category
1
-
n

S
e
t
t
l
e
m
e
n
t

S
t
e
p
s
Open Items
Settlement Control: Overview




(C) SAP AG IUT230 6-20
© 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




(C) SAP AG IUT230 6-21
© 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




(C) SAP AG IUT230 6-22
© 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.

(C) SAP AG IUT230 6-23
© SAP AG 1999
Other Bill
1000 UNI
Settlement
Open Items
900 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.

(C) SAP AG IUT230 6-24
© 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.

(C) SAP AG IUT230 6-25
© SAP AG 1999
N
e
x
t

S
e
t
t
l
e
m
e
n
t

S
t
e
p
N
e
x
t

G
r
o
u
p
Group Processing
taking the following into account:
• Sort sequence
Amount-based group rule
Dividing algorithm for
partial clearing
Customized
allocation rule
•
•
•
Form OI groups
(from specifications in grouping string)
Spec. for Subsequent Processing
• Tolerance handling
for partial clearing
Specifications about
next settlement step
Specifications about completion of
allocation
•
•
1-n Settlement
Steps
.


.


.


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

(C) SAP AG IUT230 6-26
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 3




(C) SAP AG IUT230 6-27
© SAP AG 1999
Contract Account
Term of Payment:
Contract Account
Term of Payment:
0001
Due Dates
Posting
Date
Posting
Date
Document
Date
Document
Date
System Date
System 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 Terms
of Payment:
Credit Immediately
FI Terms
of Payment:
Credit Immediately
Incoming Payments
Outgoing Payments
Incoming Payments
Outgoing 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


(C) SAP AG IUT230 6-28
© 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
Valuated consumption +_________
+_________
+_________
Credit memos/backbilling +/-________
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.


(C) SAP AG IUT230 6-29
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 4




(C) SAP AG IUT230 6-30
© SAP AG 1999
Contract Account
Outgoing Payment
Methods
P Postal transfer
C Check
Contract Account
Outgoing Payment
Methods
P Postal transfer
C Check
Posting Area
R401
P Priority 1
S Priority 2
U Priority 3
Posting Area
R401
P Priority 1
S Priority 2
U Priority 3
Determination of
Outgoing Payment
Methods
Determination of
Outgoing Payment
Methods
Amount Limit
Check
Amount Limit
Check
Checks for
Outgoing
Payment Blocks
Checks for
Outgoing
Payment Blocks
User Exit
Event R430
User Exit
Event 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.

(C) SAP AG IUT230 6-31
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 5




(C) SAP AG IUT230 6-32
© 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 TV
Installation
Meter Reading Unit:
K0001
Cable TV
Installation
Meter Reading Unit:
K0001
Contract Account
Contract Account
Joint Invoicing: Master Data



Þ Billing documents of selected contracts in a contract account are grouped to form invoicing units in
order to create a suitable bill that includes as many of the customer's contracts as possible. For this
purpose, contracts are divided into three distinctive groups:
º Contracts for which the documents must be invoiced jointly.
The billings of these contracts must always appear together on one bill (for example, a residential
customer's contracts for electricity, gas, and water). If a document has to be invoiced with other
documents, a search for the corresponding billing documents of the other contracts is carried out. If no
valid document is found, invoicing is stopped.
º Contracts for which the documents can be invoiced jointly.
The documents of these contracts are also grouped together, if possible, with the documents that must
be invoiced jointly.
º Contracts for which the documents must be invoiced separately.
Þ The billing documents that qualify for joint invoicing are transferred to FI-CA in an accounting
document. During this process, the data from the individual billing documents is summarized according
to fixed FI-CA criteria and other, company-specific controls (such as account determination and
transaction determination).



(C) SAP AG IUT230 6-33
© SAP AG 1999
Contract 1
mandatory
joint invoice
Contract 1
mandatory
joint invoice
Contract 2
mandatory
joint invoice
Contract 2
mandatory
joint invoice
Contract 3
mandatory
joint invoice
Contract 3
mandatory
joint invoice
Contract
optional
joint invoice
Contract
optional
joint invoice
Document
Optional
Document
Optional
Document 3
Mandatory
Document 3
Mandatory
Document 1
Mandatory
Document 1
Mandatory
Document
Optional
Document
Optional
Billing
Contract
exclusive invoice
Contract
exclusive invoice
Document
Exclusive
Document
Exclusive
Document
exclusive
Document
exclusive
Invoicing
Contract 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.

(C) SAP AG IUT230 6-34
© SAP AG 1999
Contract 1
mandatory
joint invoice
Contract 1
mandatory
joint invoice
Contract 2
mandatory
joint invoice
Contract 2
mandatory
joint invoice
Contract 3
mandatory
joint invoice
Contract 3
mandatory
joint invoice
Contract
optional
joint invoice
Contract
optional
joint invoice
Document
Optional
Document
Optional
Document 3
Mandatory
Document 3
Mandatory
Document 1
Mandatory
Document 1
Mandatory
Document
Document
Billing
Contract
exclusive invoice
Contract
exclusive invoice
Document
Exclusive
Document
Exclusive
Document
Exclusive
Document
Exclusive
Invoicing
Contract Account
Bill
Bill
Document 2
Mandatory
Document 2
Mandatory
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.

(C) SAP AG IUT230 6-35
© SAP AG 1999
Cons. billing
#1 Electricity 1000 UNI
Gas 1500 UNI
Water 600 UNI
Other Services #3
Cable TV 180 UNI
Misc. Services #2
Waste water 500 UNI
Waste 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 per
receivable:
Bill #1 (xy) ...
Bill #2 (zz) ...
Bill #3 (rs) ...
G/Ledger 0002
loc. auth. "zz"
G/Ledger 0001
Utility Co. xy
G/Ledger 0003
(n/a to balance sheet)
TV Co. "rs"
Rec. Electricity
Rec. Gas
Rec. Water
Rec. waste water
Rec. 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
IS IS- -U U
FI FI
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.


(C) SAP AG IUT230 6-36
© 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
Simplified
representation
without tax!
Joint Joint
Invoicing Invoicing
- - Account Account
- - Due Dates Due Dates
- - Optional Optional
Account A. Smith
Bill #4711 775 UNI
Line items per
receivable:
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.

(C) SAP AG IUT230 6-37
© SAP AG 1999
SD
Billing Doc.
SD
Billing Doc.
IS-U
Billing
IS-U
Billing
IS-U
Invoicing
Billing Documents
Billing Documents
SD Sales
PM-SMA
Installation Services
IS-U
Utility
Services
Incorporation of Additional Documents
B
i
l
l
i
n
g

R
e
q
u
e
s
t
O
p
t
i
o
n
a
l



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

(C) SAP AG IUT230 6-38
© SAP AG 1999
IS-CA
FI-AR FI-AR
SD
Billing
Doc.
IS-U
Billing
IS-U
Invoice
FI Customer FI Customer
Contract Account
Billing Request
A
c
c
o
u
n
t

G
r
o
u
p
Document Type
PosAr R400
Document Type
PosAr 1210
⇓ ⇓⇓ ⇓
SD Billing
Category
'U'
Integration of SD Billing Documents
S
D

B
i
l
l
i
n
g

T
y
p
e



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

(C) SAP AG IUT230 6-39
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 6




(C) SAP AG IUT230 6-40
© 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 Workflow Exception List or Workflow
not OK
Rel-
ease
Rel-
ease
Rel-
ease
Check
- standard
- company-
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.
Þ Outsorting can occur after billing or invoicing.

(C) SAP AG IUT230 6-41
© SAP AG 1999
¤ Net amount checks
¤ Checks for budget billing amounts
¤ Check for estimations
¤ Check for billing line items
Billing
Invoicing
Invoicing
Billing
Billing
¤ Gross amount checks
¤ Credit checks after settlement
¤ Balance forward
Times of Outsorting



Þ Outsorting can occur after billing or invoicing.
Þ Different checks can be carried out according to the time of the outsorting.
Þ On this slide, you can see the checks provided by SAP in the system.

(C) SAP AG IUT230 6-42
© SAP AG 1999
Control
Document
Control
Document
Control
Document
Control
Document
Invoicing
Invoicing
Checks
Checks
Invoices
to be checked
Release
Release
Reversal
Reversal
Billing
Printout
Billing
Printout
Automatic Checks
Automatic Checks
Manual Outsorting
Manual Outsorting
Contract Account
Manual
Outsorting: 0001
Once
Contract Account
Manual
Outsorting: 0001
Once
Invoicing
Invoicing
Invoices
to be checked
Release
Release
Reversal
Reversal
Billing
Printout
Billing
Printout
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.

(C) SAP AG IUT230 6-43
© SAP AG 1999
Outsorting Groups:
Invoicing
0001 Res. customer
0002 Nonres. cust.
Outsorting Groups:
Invoicing
0001 Res. customer
0002 Nonres. cust.
Automatic Checks
Automatic Checks
Contract Account
(individual
setting)
Contract Account
(individual
setting)
Invoicing Checks
Outsorting Group 0001 = Check AMOUNT2
Outsorting Group 0002 = Check AMOUNT3
Invoicing Checks
Outsorting 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.





(C) SAP AG IUT230 6-44
© SAP AG 1999
¤ AMOUNT2
Gross billing amount checked
against minimum and maximum
limitations
¤ AMOUNT3
Sum total checked against
minimum and maximum
limitations
¤ FORWARD1
Balance 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.


(C) SAP AG IUT230 6-45
© 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




(C) SAP AG IUT230 6-46
© SAP AG 1999
¤ Invoicing Functions
¤ Account Maintenance
¤ Due Dates
¤ Credit Processing
¤ Joint Invoicing/Integration
¤ Outsorting in Invoicing
¤ Invoice Reversal
Invoicing: 7




(C) SAP AG IUT230 6-47
© SAP AG 1999
Invoicing
Reversal
or Total
Reversal
Mark
Open Posting
Document
Create
Reversal Document
Mark
Open Billing
Document
Invoice Reversal Billing Reversal
Create
Billing Order
Invoicing Reversal Functions
Open
Old 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.


(C) SAP AG IUT230 6-48
© SAP AG 1999
-1000,-
.
.
.
Reversal
Bill
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 Order
Full Reversal
Reversal Process in Invoicing/Full Reversal
Reversed
Billing 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).

(C) SAP AG IUT230 6-49
© SAP AG 1999
I
n
v
o
i
c
i
n
g

D
o
c
u
m
e
n
t
Full bill is not to be reversed
Full bill is not to be reversed
Billing
Documents
Billing
Documents
Reversal
of a single
billing
document
Reversal
of a single
billing
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.


(C) SAP AG IUT230 6-50
© SAP AG 1999
Adjustment Reversal
Adjustment Reversal
Rebilling
Rebilling
Changes
to the
Dataset
Changes
to 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.

(C) SAP AG IUT230 6-51
© 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
ISUBIMRCOR02 Workflow
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'.

(C) SAP AG IUT230 6-52
© SAP AG 1999
Workflow WS 20500105
ISU_ASSESS
Workflow WS 20500105
ISU_ASSESS
Search for billing documents to be reversed
Adjustment reversal of billing document
New estimation of incorrect MR results
Steps in the Workflow
Workflow
starts
Overestimation
of meter reading
results
1999
1999
02/13 03/16 04/15 01/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.

(C) SAP AG IUT230 6-53
© 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




(C) SAP AG IUT230 6-54
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?
____________________________________________________________


(C) SAP AG IUT230 6-55
Exercises


Unit: Invoicing
Topic: Reversal

• Be able to trigger full reversal of billing and invoicing.
• Be able to name the differences and effects of the reversal.

A customer has received a bill and does not agree with the meter reading
billed. It is too high due to a bad reading. The bill is fully reversed and
recalculated.
2-1 The business partner’s existing bill must be checked and recalculated with the
correct meter reading.
2-1-1 Display the last billing document for the business partner TF0703A0## and the
contract TF0703A0##.

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

2-1-3 Trigger a full reversal of the bill
(invoicing and billing). Select the reconciliation key TF0703A0##.

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

2-1-5 Change the result of the meter reading. Use the correction function for meter
reading results and the installation TF0703A0##. What is the new meter
reading?
____________________________________________________________

2-1-6 Carry out the new billing and invoicing procedure with the billing order.
Which document numbers are created by the system (in billing and invoicing)?
____________________________________________________________


(C) SAP AG IUT230 6-56
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.

(C) SAP AG IUT230 6-57
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.

(C) SAP AG IUT230 6-58
Solutions


Unit: Invoicing
Topic: Reversal
2-1 The business partner’s existing bill must be checked and recalculated with the correct
meter reading.
2-1-1 Display the last billing document for the business partner TF0703A0## and the
contract TF0703A0##.

2-1-2 Use the print document display function.
From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
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##.
From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
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.

(C) SAP AG IUT230 6-59
2-1-4 Which options are available for carrying out this procedure? List the menu
paths.
From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
Processing → →→ → Individual Processing → →→ → Full Reversal.
From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
Processing → →→ → Mass Processing → →→ → Full Reversal.
Two steps for the individual reversal of billing and invoicing.
From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
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.


(C) SAP AG IUT230 6-60
2-1-6 Carry out the new billing and invoicing procedure with the billing order.
Which document numbers are created by the system (in billing and invoicing)?
From the SAP menu, choose: Utilities Industry → →→ →Billing → →→ → Billing
Execution → →→ → Individual Processing → →→ → Individual Bill.
In Level of processing, select Display bill. Choose the selection criterion
Contract and enter the contract TF0703A0## and a reconciliation key.
Execute.
You will find the document numbers in the log following billing/invoicing.



(C) SAP AG IUT230 7-1
© SAP AG 1999 © SAP AG 2001
¤ 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




(C) SAP AG IUT230 7-2
© SAP AG 1999
Budget Billing: Unit Objectives
© SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ 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




(C) SAP AG IUT230 7-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billing
Budget Billing
Additional Functionality:
Discount/Surcharge
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discount/Surcharge Discount/Surcharge
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 7



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

(C) SAP AG IUT230 7-4
© SAP AG 1999
Budget Billing: 1
¤ Budget Billing
Þ Budget Billing Functions
Þ Budget Billing Cycles
Þ Budget Billing Plan
Þ Budget Billing Due Dates
¤ Budget Billing Procedure
¤ Budget Billing Printout
¤ Budget Billing Settlement




(C) SAP AG IUT230 7-5
© 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.


(C) SAP AG IUT230 7-6
© SAP AG 1999
Budget Billing Cycle and Budget Billing Frequency
12
Period Length Months
1
2
3
4
6
12
0
No 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 Cycles Budget Billing Cycles Possible number of budget billings per budget billing period Possible number of budget billings per budget billing period
W
1
W
2
W
3
W
4
W
5
W
6
W W
1
W W
2
W W
3
W W
4
W W W
1
W W W
2
W W W
3
W W W W W
1
W W W W W
2
W W W W W
1
W W W W W W
¤ 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.

(C) SAP AG IUT230 7-7
© SAP AG 1999
Portion
Cycle: 12/01
Cycle: 6/02
Default: 01
Portion
Cycle: 12/01
Cycle: 6/02
Default: 01
Budget Billing
Plan
Cycle: 02
Budget Billing
Plan
Cycle: 02
Scheduling:
Definition of the maximum
options and the
default budget billing cycle
Contract
Cycle: 02
Contract
Cycle: 02
Contract:
Individual overrides
of the default budget billing cycle
for generating the next budget billing
plan
Budget Billing Plan:
Overriding the default
budget billing cycles immediately
affects 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).


(C) SAP AG IUT230 7-8
© 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




(C) SAP AG IUT230 7-9
© 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.



(C) SAP AG IUT230 7-10
© SAP AG 1999
2000
2000
11/01 .... .... .... .... .... .... 08/01
Billing period
2001
2001
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.


(C) SAP AG IUT230 7-11
© SAP AG 1999
Cycle: 02
Print Date/Debit Entry Date:
01/31/1999
03/31/1999
05/31/1999
07/31/1999
09/30/1999
11/30/1999
Cycle: 02
Print Date/Debit Entry Date:
01/31/1999
03/31/1999
05/31/1999
07/31/1999
09/30/1999
11/30/1999
Scheduling:
Definition of the Print Dates
for all Budget Billing Cycles
The due dates for the
budget billing plan are
determined using the
terms of payment from the
contract account.
Schedule Record Portion
Cycle: 01
Print Date/Debit Entry Date:
01/31/1999
02/28/1999
03/31/1999
04/30/1999
05/31/1999
06/30/1999
07/31/1999
08/31/1999
09/30/1999
10/31/1999
11/30/1999
12/31/1999
Cycle: 01
Print Date/Debit Entry Date:
01/31/1999
02/28/1999
03/31/1999
04/30/1999
05/31/1999
06/30/1999
07/31/1999
08/31/1999
09/30/1999
10/31/1999
11/30/1999
12/31/1999
Schedule Record Portion
Budget Billing
Plan
Default Cycle: 02
02/15/1999
04/15/1999
06/15/1999
08/15/1999
10/15/1999
12/15/1999
Budget Billing
Plan
Default Cycle: 02
02/15/1999
04/15/1999
06/15/1999
08/15/1999
10/15/1999
12/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.


(C) SAP AG IUT230 7-12
© SAP AG 1999
Water Contract
Joint
Invoice: 2
2. Budget Billing Plan
03/15/99 70 UNI
04/15/99 70 UNI
05/15/99 70 UNI
06/15/99 70 UNI
....
Electricity
Contract Joint
Invoice: 1
Gas Contract
Joint
Invoice: 1
1. Budget Billing Plan
03/15/99 150 UNI
04/15/99 150 UNI
05/15/99 150 UNI
06/15/99 150 UNI
....
Sub-Budget Billing Plan
03/15/99 50 UNI
04/15/99 50 UNI
05/15/99 50 UNI
06/15/99 50 UNI
....
Sub-Budget Billing Plan
03/15/99 100 UNI
04/15/99 100 UNI
05/15/99 100 UNI
06/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.

(C) SAP AG IUT230 7-13
© SAP AG 1999
04/01 100
07/01 100
10/01 100
01/01 100
Budget Billing Plan from
Invoicing (*):
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
New
New
New
New
Jan. - March
April - June
July - Sep.
Oct. - Dec.
Jan. - March
Consumption/Advance Payment
Consumption/Advance Payment
Jan. - March
April - June
July - Sep.
Oct. - Dec.
(*) Billing Period 1/2 - 01/01
4 Budget Billings/Year
(*) Billing Period 1/2 - 01/01
4 Budget Billings/Year
Agenda: X = Advance payment
L = Last due date for an advance payment
If necessary, a new budget billing due date at the end of the budget billing period
is 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.


(C) SAP AG IUT230 7-14
© SAP AG 1999
Automatic Manual
Percentage
- Increase
- Decrease
- Percentage
Extrapolation
Accumulated
Budget
Billings
Message
to the
Customer
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.

(C) SAP AG IUT230 7-15
© SAP AG 1999
Open
Billings
Open
Billings
Open
Invoices
Open
Invoices
List/
Budget Billing
Plan
Extension
List/
Budget Billing
Plan
Extension
Budget Billing Requests
11/15/98 150 UNI
12/15/98 150 UNI
01/15/99 150 UNI
02/15/99 150 UNI
03/15/99 150 UNI
04/15/99 150 UNI
05/15/99 150 UNI
06/15/99 150 UNI
07/15/99 150 UNI
08/15/99 150 UNI
09/15/99 150 UNI
10/15/99 150 UNI
11/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.

(C) SAP AG IUT230 7-16
© SAP AG 1999
Budget Billing: 2
¤ Budget Billing
Þ Budget Billing Functions
Þ Budget Billing Cycles
Þ Budget Billing Plan
Þ Budget Billing Due Dates
¤ Budget Billing Procedure
¤ Budget Billing Printout
¤ Budget Billing Settlement




(C) SAP AG IUT230 7-17
© 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.

(C) SAP AG IUT230 7-18
© SAP AG 1999
Budget Billing Plan
Due Date Amount
11/15/98 150 UNI
12/15/98 150 UNI
01/15/99 150 UNI
02/15/99 150 UNI
03/15/99 150 UNI
04/15/99 150 UNI
05/15/99 150 UNI
06/15/99 150 UNI
07/15/99 150 UNI
08/15/99 150 UNI
09/15/99 150 UNI
Account Balance Display
11/15/1998 150
12/15/1998 150
01/15/1999 150
02/15/1999 150
03/15/1999 150
04/15/1999 150
05/15/1999 150
06/15/1999 150
07/15/1999 150
08/15/1999 150
09/15/1999 150
1. Request Budget
Billings
2. Print Report
1. Request Budget
Billings
2. Print Report
Budget Billing
Requisition
Statistical Items
Payment
Generates 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.

(C) SAP AG IUT230 7-19
© SAP AG 1999
Budget Billing Plan
Due Date Amount
11/15/98 150 UNI
12/15/98 150 UNI
01/15/99 150 UNI
02/15/99 150 UNI
03/15/99 150 UNI
04/15/99 150 UNI
05/15/99 150 UNI
06/15/99 150 UNI
07/15/99 150 UNI
08/15/99 150 UNI
09/15/99 150 UNI
1. Create Partial Bill
2. Print Report
1. Create Partial Bill
2. Print Report
Budget
Billing
Bill
Account Balance Display
11/15/1998 150
Actual Items
Payment
Only clears the
items. VAT already
posted planned
taxation)
Budget billings are
not reposted
Create Partial Bill
Create 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.

(C) SAP AG IUT230 7-20
© 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




(C) SAP AG IUT230 7-21
© 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.

(C) SAP AG IUT230 7-22
© 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.

(C) SAP AG IUT230 7-23
© 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.

(C) SAP AG IUT230 7-24
© SAP AG 1999
Budget Billing: 3
¤ Budget Billing
Þ Budget Billing Functions
Þ Budget Billing Cycles
Þ Budget Billing Plan
Þ Budget Billing Due Dates
¤ Budget Billing Procedure
¤ Budget Billing Printout
¤ Budget Billing Settlement




(C) SAP AG IUT230 7-25
© SAP AG 1999
Print
Document
with Printed
Lines
SAP Spool
Print Report
Print Report
Request
Budget Billings
Request
Budget Billings
Create
Partial Bill
Create
Partial 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.

(C) SAP AG IUT230 7-26
© SAP AG 1999
Print Budget
Billings per Due
Date
Print all Budget
Billings with Bill
Budget Billing Bill 4711
Date: 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 is
due 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.


(C) SAP AG IUT230 7-27
© SAP AG 1999
Budget Billing: 4
¤ Budget Billing
Þ Budget Billing Functions
Þ Budget Billing Cycles
Þ Budget Billing Plan
Þ Budget Billing Due Dates
¤ Budget Billing Procedure
¤ Budget Billing Printout
¤ Budget Billing Settlement




(C) SAP AG IUT230 7-28
© SAP AG 1999
Bill 4711 Date: 01/02/99
Valuated consumption +_________
+_________
+_________
Credit memos/backbilling +/-________
Billing
amount =========
Payed Budget Billings -1,278 UNI
Main items +/-________
1. Budget billing amount +_________
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.


(C) SAP AG IUT230 7-29
© 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.

(C) SAP AG IUT230 7-30
© 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.

(C) SAP AG IUT230 7-31
© SAP AG 1999
Customizing for Budget Billing
¤ Budget Billing Procedure
¤ 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
...............
...............




(C) SAP AG IUT230 7-32
© 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.




(C) SAP AG IUT230 7-33
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?
____________________________________________________________

(C) SAP AG IUT230 7-34
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:

Business partner TF0801A0##
Selection date April 30
th
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:

Business partner TF0801A0##
Document date April 30
th
(plus year of the current budget billing plan)
Posting date April 30
th
(plus year of the current budget billing plan)
Selection date April 30
th
(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##.

(C) SAP AG IUT230 7-35
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.



(C) SAP AG IUT230 7-36
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:

Business partner TF0801A0##
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


(C) SAP AG IUT230 7-37
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:

From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
Processing → →→ → Mass Processing → →→ → Request Budget Billing Amounts.
Choose the selection criteria in the data screen as described in the exercise
and execute. The print date in the budget billing plan was set and the due
date, April 30
th
, 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:

From the SAP menu, choose: Utilities Industry → →→ → Invoicing → →→ → Invoice
Processing → →→ → Mass Processing → →→ → Create Partial Bill.
Choose the selection criteria in the data screen as described in the exercise
and execute. The print date in the budget billing plan was set and the due
date, April 30
th
, 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.
From the SAP menu, choose: Utilities Industry → →→ → Contract Accounts
Receivable and Payable → →→ → Account → →→ → Account Balance.

(C) SAP AG IUT230 7-38
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
Execution → →→ → Individual Processing → →→ → Individual Bill.
In Level of processing, select Display bill. Select the selection criterion
Contract and enter the contract TF0803A0##. Select the Enter meter reading
results check box and enter 01 in the Meter reading reason field.
Execute.
Repeat the individual bill for the month after next.

1-3-4 Check the balance forward using the account balance display.
From the SAP menu, choose: Utilities Industry → →→ → Contract Accounts
Receivable and Payable → →→ → Account → →→ → Account Balance.




(C) SAP AG IUT230 8-1
© SAP AG 1999 © SAP AG 2001
¤ Bill Printout Functions
¤ Print Action Records
¤ Raw Data Interface, Optical Archiving
Bill Printout




(C) SAP AG IUT230 8-2
© SAP AG 1999
Bill Printout: Unit Objectives
© SAP AG 2000
At the conclusion of this unit, you will be able to:
¤ Describe the concept of bill printout
¤ Explain the hierarchy for billing forms
¤ Outline the bill printout process
¤ Outline the options for sorting bill line items
¤ Describe print action records
¤ Explain the raw data interface and describe the
optical archiving options




(C) SAP AG IUT230 8-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Billing Billing
Budget Billing Budget Billing Budget Billing
Additional Functionality:
Discount/Surcharge
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discount/Surcharge Discount/Surcharge
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 8



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



(C) SAP AG IUT230 8-4
© SAP AG 1999
¤ Bill Printout Functions
¤ Print Action Records
¤ Raw Data Interface, Optical Archiving
Bill Printout: 1




(C) SAP AG IUT230 8-5
© 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 form
structure
-can be changed/extended by
users
-customer exits
Generated
Print Program
-represents the form
structure
-can be changed/extended by
users
-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.

(C) SAP AG IUT230 8-6
© SAP AG 1999
IS_U_BI_BILL
IS_U_BI_BILL
DOC_HEADER
DOC_HEADER
DOC_ITEM
DOC_ITEM
CONT_ACCT
CONT_ACCT
CONTRACT
CONTRACT
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.

(C) SAP AG IUT230 8-7
© 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
0001 Energy price G2 A1 201.50
0001 Energy price G3 A1 300.35
Subtotal value-added tax 93.80
0002 Provisioning G1 A1 203.55
0002 Provisioning G2 A1 344.01
0002 Provisioning G3 A1 470.89
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 on
the 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
S
o
r
t
O
r
d
e
r
o
f
B
illin
g

L
in
e
It
e
m
s
?
?
?
?
?
S
o
r
t
O
r
d
e
r
o
f
B
illin
g

L
in
e
It
e
m
s
?
?
?
?
?



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

(C) SAP AG IUT230 8-8
© SAP AG 1999
Print Report
Print Report
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.


(C) SAP AG IUT230 8-9
© SAP AG 1999
Navigation
Shipping Control
-->Shipping type
Shipping Control 0001
Shipping Types
1
2
EMAIL
PRINTER
1
1
*
*
3
3
No. Trnsm.mthdPrintoutsRDIArch.mod.Copy
Shipping Control BP
Shipping Control alt.BTP
Shipping Control alt.DR
Contract Account
Print Report
Print Report
FAX
Printer
E-Mail R-Mail Fax
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.

(C) SAP AG IUT230 8-10
© SAP AG 1999
Financial Accounting
Basic Settings: Financial Accounting
Correspondence
Attached Payment Medium
Country
FORM ID
Country
FORM ID
Function Module
for Formatting
the Payment
Medium
Function Module
for Formatting
the Payment
Medium
Company Code
FORM ID
Company Code
FORM ID
SAPscript
Form
SAPscript
Form
FI FI
Posting Area
R401
CoCd FORM ID
Posting Area
R401
CoCd FORM ID
1200,-
Payment Medium
One 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.

(C) SAP AG IUT230 8-11
© 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 4712
0001 IQUANT 4712
0002 000001 4712 12.45 UNI
0002 000002 4712 33.78 UNI
Electricity
Presort Line Item Type Contract Amount
0001 IDEMAN 4711
0001 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.

(C) SAP AG IUT230 8-12
© SAP AG 1999
Presort Key Function - Step 1
Electricity
Presort Line Item Type Contract Amount
0001 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 Sorted
According 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.

(C) SAP AG IUT230 8-13
© SAP AG 1999
Presort Key Function - Step 2
Electricity
Presort 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
0002 000001 4712 12.45 UNI
0002 000002 4712 33.78 UNI
Document Line Items Sorted
According to Contract
(Function Module
SU_BILL_TYPE_CONTRACT)
User-Defined => Dependent
on Presort Key
Print Document
Presort Keys:
0001 = Sort according to contract w/o subtotal
0002 = Sort according to contract with subtotal



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

(C) SAP AG IUT230 8-14
© SAP AG 1999
Presort Key Function - Step 3
Electricity
Presort 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 UNI
Subtot.(City Tax) 2.56 UNI
Subtot.(Country Tax) 5.66 UNI
Create subtotal line items when
contract changes
(see above function module)
Print Document
Presort Keys:
0001 = Sort according to contract w/o subtotal
0002 = Sort according to contract with subtotal



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

(C) SAP AG IUT230 8-15
© SAP AG 1999
Print
Document
with Printed
Lines
Print Report
Collective Bills
Print Report
Collective Bills
Invoicing
Invoicing
C. acct: 8711
Acct cat.: SR
C. acct: 4712
Acct cat.: ISU
CB acct: 8711
Form: Cover Page Form: Individual Bill
Individual
Bills
Individual
Bills
Cover Page
with Individual
Information
Cover Page
with Individual
Information
C. acct: 8711
Acct cat.: SR
Collector Ltd
Anne Miller Henry Smith Maria Bush
Acct: 4712
Acct cat.: ISU
CB acct: 8711
Acct: 4713
Acct cat.: ISU
CB acct: 8711
Acct: 4714
Acct cat.: ISU
CB 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.

(C) SAP AG IUT230 8-16
© SAP AG 1999
¤ Bill Printout Functions
¤ Print Action Records
¤ Raw Data Interface, Optical Archiving
Bill Printout: 2




(C) SAP AG IUT230 8-17
© 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.


(C) SAP AG IUT230 8-18
© SAP AG 1999
Customer
Report
for Building
Print Action
Records
Customer
Report
for Building
Print Action
Records
Function
Module
for
Writing
a Print
Action
Record
satzes
Form Class
Form Class
Print Action
Record
Print Action
Record
¤ Mass Creation of Print Action
Records
Print Action Records: 2



Þ Print action records can also be created in very large numbers (for example, information for all
customers with E1 as rate category). The customer must create a report that selects all contracts that have
E1 as their rate category. The next step is to create a print action record for each of these contracts. SAP
provides you with a function module to do this.

(C) SAP AG IUT230 8-19
© SAP AG 1999
Contract
Contract
Business
Partner
Business
Partner
Contract
Account
Contract
Account
Print Action Records: 3
Transaction for
Displaying,
Changing, and
Deleting
Print Action Records
Transaction for
Displaying,
Changing, and
Deleting
Print Action Records
Form Class
Form 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.

(C) SAP AG IUT230 8-20
© SAP AG 1999
Send rate information
Send collection authorization
Send questionnaire on gas action
Text information: meter replacement in next billing period
Text information: greeting
Text information: move-in/out
.
.
.
Valid from: Valid to:
Send x no. of times:
Form class
Send rate information
Send collection authorization
Send questionnaire on gas action
Text information: meter replacement in next billing period
Text information: greeting
Text information: move-in/out
.
.
.
Valid from: Valid to:
Send x no. of times:
Form class
Print Action Records: 4
x
x
x
01/01/1997 12/31/1997
1
IS_U_BI_BILL
Option of
Entering a User-
Defined Text
(Standard SAP
Text Module)
Option of
Entering a User-
Defined Text
(Standard SAP
Text Module)
Adds Flyer
Adds Flyer
Prints an Additional Text
Prints 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.


(C) SAP AG IUT230 8-21
© SAP AG 1999
¤ Bill Printout Functions
¤ Print Action Records
¤ Raw Data Interface, Optical Archiving
Bill Printout: 3




(C) SAP AG IUT230 8-22
© SAP AG 1999
2
2
1
1
2
2
1
1
Print
Workbench
IS-U
application
form
Print
Workbench
IS-U
application
form
SAPscript
form
(layout, text,
data)
SAPscript
form
(layout, text,
data)
Application
Application
Print
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
C
o
m
p
l
e
t
e

f
o
r
m
f
o
r

o
n
l
i
n
e

p
r
i
n
t
i
n
g
Generates
N
e
t

f
o
r
m

f
o
r
r
a
w

d
a
t
a

i
n
t
e
r
f
a
c
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.



(C) SAP AG IUT230 8-23
© SAP AG 1999
Raw Data Interface
SAPscript
Form
SAPscript
Form
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 File
Optical Archiving Systems
Raw Data Interface: 2
Header data:
Line item data:
Form window Text element Variable name Contents
-----------------------------------------------------------------------------
Window1 Element1 FKKKO-BUDAT 01/01/1997
Window1 Element2 EVER-SPARTE 01
...



Þ Bills can also be archived optically.

(C) SAP AG IUT230 8-24
© 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




(C) SAP AG IUT230 8-25
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?
____________________________________________________________



(C) SAP AG IUT230 8-26
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

(C) SAP AG IUT230 8-27
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.

(C) SAP AG IUT230 8-28
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



(C) SAP AG IUT230 9-1
© SAP AG 1999 © SAP AG 2001
¤ Discount and Surcharge Options
¤ Master Data
¤ Effects on the Rate Structure
Discounts/Surcharges




(C) SAP AG IUT230 9-2
© SAP AG 1999
Discounts/Surcharges: Unit Objectives
At the conclusion of this unit, you will be able to:
¤ Describe the discount and surcharge options
¤ Explain the general and specific master data for
discounts
¤ Explain the effect on the rate structure
© SAP AG 2001




(C) SAP AG IUT230 9-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing Bill
Printout
Bill
Printout
Billing Billing
Budget Billing Budget Billing Budget Billing
Additional Functionality:
Discounts/Surcharges
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 9



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


(C) SAP AG IUT230 9-4
© 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
Discounts/
Surcharges
Discounts/
Surcharges
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.


(C) SAP AG IUT230 9-5
© 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.


(C) SAP AG IUT230 9-6
© 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 Steps
Rate Steps
Discount
Rate Facts
Rate 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.

(C) SAP AG IUT230 9-7
© 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.




(C) SAP AG IUT230 9-8
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 1
st
of this year
Transaction currency UNI
Reference basis Price discount
Discount type Percentage
Data
Text Discount ##
Division Electricity
Billing class Residential customer
Discount category Discount
Percentage 10
1-1-2 To process the discount key you just created, you must include a new rate. Use
rate E1_1 as a template and create new rate PE3_1##. 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##.

(C) SAP AG IUT230 9-9
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 → →→ →
Billing Master Data → →→ → Rate Structure → →→ → Rates → →→ → Define Rates → →→ → Create
Rates.
In the initial screen enter rate PE3_1##, and rate E1_1 as the template.
Maintain the field content as described in the exercise.
Select Rate Steps.
Maintain the field content in the Rate Steps as described in the exercise and
save.
Variant program: DISCNT03
Note that variant programs that calculate discounts based on prices must
always be listed before the price key, to which the discount applies in the rate.
In comparison, discount variants that refer to amounts are always listed after
the amounts to which the discount applies.

(C) SAP AG IUT230 9-10
1-1-3 However, the discount is not to be valid for all customers with this rate. It is
only used 365 days after the contract first began. Include other variant programs
and operands in the rate.
In the first step, you determine the number of days since the contract began.
Use variant program COMPUT20 to do this. Create separate operands for the
variant program. You must now check the calculated days against the days
(365 here) fixed in the contract text. Use variant IF03 to do this. If the
condition has been fulfilled, use DISCNT03 to calculate the discount. If the
condition has not been fulfilled, a normal evaluation takes place with the
undiscounted quantity-based price. Here is the sequence of the necessary
variant programs:
COMPUT20
IF03
DISCNT03
ENDIF
QUANTI01
...
Include the required facts to complete your rate.
1-1-4 Once you have created the rate, you must create a new schema PE3##, a new
rate category PE3## and the rate determination.
From the SAP Reference IMG, choose: SAP Utilities → Contract Billing →
Billing Master Data → Rate Structure → Schemas → Define Schemas →
Create Schemas.
Enter the name of the schema in the Billing schema field (PE3##), and enter
the data as specified in the exercise.
1-1-5 In the next step, you want to test this discount. Therefore allocate the new rate
category to business partner TF1001A0## with installation TF1001A0##.
From the SAP menu, choose: Utilities Industry → →→ → 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.

(C) SAP AG IUT230 10-1
© SAP AG 1999 © SAP AG 2001
¤ Manual Billing Functions
¤ Examples of Use
¤ Individual Bill
¤ Joint Invoicing
Manual Billing




(C) SAP AG IUT230 10-2
© SAP AG 1999 © SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ Describe manual billing functions
¤ Provide examples of manual billing
¤ Create a manual billing
¤ Recognize the difference between an individual bill
and joint invoicing
Manual Billing: Unit Objectives




(C) SAP AG IUT230 10-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing
Bill
Printout
Bill
Printout
Billing Billing
Budget Billing Budget Billing Budget Billing
Additional Functionality:
Discounts/Surcharges
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 10



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


(C) SAP AG IUT230 10-4
© SAP AG 1999
Calculation Options Functions
Manual
Billing
Meter Reading from/to
Net Amount
Price
Determination
Billing Quantity
Rate
Determination
Status
Management
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.


(C) SAP AG IUT230 10-5
© 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).
Þ Installation structure
In manual billing, you need the installation structure for device-related credit memos or backbilling
(however, it is not needed not for flat-rate installations).
Þ Invoicing
When the manual bill is being created, a decision is made based on the entries whether to create an
individual bill or to include the billing line items in the next invoicing procedure that affects that
contract.
Þ Credit memo or backbilling
If the result (total of all billing line items) is positive, a credit memo is created; if it is negative a
backbilling is created.

(C) SAP AG IUT230 10-6
© 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.

(C) SAP AG IUT230 10-7
© SAP AG 1999
With
Reference to
Billing Order
Billing
Document
Contract
Billing Order
Release
Release
Bill
Printout
Invoicing
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.

(C) SAP AG IUT230 10-8
© SAP AG 1999
Manual
Billing
Manual
Billing
B
i
l
l
¤ Last bill not reversible
¤ Last bill not to be reversed
¤ No bill available
Examples of Manual Billing
¤ 500 kWh backbilling
due 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.


(C) SAP AG IUT230 10-9
© SAP AG 1999
Invoicing
B
ill
Manual Billing
Document
Bill Printout
Print Document
with Printed
Lines
Automatic
Billing
Document
Invoicing
B
ill
Bill Printout
Print Document
with Printed
Lines
Manual Billing
Document
Joint Invoicing
Joint 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.



(C) SAP AG IUT230 11-1
© SAP AG 1999 © SAP AG 2001
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




(C) SAP AG IUT230 11-2
© SAP AG 1999
At the conclusion of this unit, you will be able to:
¤ Describe how franchise fee procedures are supported
by the system
¤ Explain the different types of gas billing
¤ List the master data required for billing deregulated
contracts
¤ Explain the functions of reference values and street
lighting
¤ Archive billing data
¤ Describe special types of billing
© SAP AG 2001
Special Billing Features: Unit Objectives




(C) SAP AG IUT230 11-3
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing
Bill
Printout
Bill
Printout
Billing Billing
Budget Billing Budget Billing Budget Billing
Additional Functionality:
Discounts/Surcharges
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 12



Þ The scenario in this unit deals with special billing features.



(C) SAP AG IUT230 11-4
© SAP AG 1999
¤ Franchise Fee
¤ Gas Billing
¤ Reference Values/Lighting
¤ Billing Deregulated Contracts
¤ Archiving Billing Data
¤ Special Types of Billing
Special Billing Features: 1




(C) SAP AG IUT230 11-5
© 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 rate
without 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.

(C) SAP AG IUT230 11-6
© SAP AG 1999
Net Procedure Gross Procedure Max. Gross Procedure
Price incl. FF Price incl. FF Price incl. FF
Price Table
Price incl. FF
Price Table
Price incl. FF
FF
-Contract
-Amount
Amount < Max.
Max. - Amount
Franchise Fee Procedure
FF
-Contract
-Amount
-Max.
Price
Table
+
-



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

(C) SAP AG IUT230 11-7
© SAP AG 1999
Rate Steps
Franchise Fee Group
Prices
FF Contract
FF Procedure
Franchise Fee Group
FF Amounts, FF Contribution
Rate
Prices
FF 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.

(C) SAP AG IUT230 11-8
© SAP AG 1999
¤ Franchise Fee
¤ Gas Billing
¤ Reference Values/Lighting
¤ Billing Deregulated Contracts
¤ Archiving Billing Data
¤ Special Types of Billing
Special Billing Features: 2




(C) SAP AG IUT230 11-9
© 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 Procedure
Entry 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
Customizing
Customizing
Customizing
Customizing
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
Register
Register
• Calorific Value District
• Air Pressure Area
• Temperature Area
• Gas Pressure Area
Customizing
Customizing
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 Structure
Gas Procedure
Fixed Temperature
Postal
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.
Þ Installation structure
The gas procedure is defined here. It specifies how the calorific value and volume correction factor are
determined.
Þ Register description
The register description defines which factors are already taken into account for gas billing.

(C) SAP AG IUT230 11-13
© SAP AG 1999
Customizing
Customizing
Basic Functions
Master Data
Device Management
Contract Billing
Invoicing
Contract A/R & A/P
Customer Service
Work Management
Information System
Tools
Utilities Industry Utilities Industry
Special Functions
Special Functions
Gas Billing
Gas Billing
Volume Correction Factor
Volume Correction Factor
Calorific Value
Calorific Value
Gas Procedure
Gas Procedure
Allocation Data
Allocation Data
Temperature, measured pressure, monthly/annual
air 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
¤ 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
Volume Correction Factor: 2




(C) SAP AG IUT230 11-19
© SAP AG 1999
¤ Annual Air Pressure
¤ Air Pressure Measured each Month
¤ Arithmetic Average for the Billing Period
¤ Weighted Average for the Billing Period
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
Volume Correction Factor: 3




(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
¤ Arithmetic Annual Average
¤ Weighted Annual Average
¤ Arithmetic Average for the Billing Period
¤ Weighted Average for the Billing Period
Calorific Value Procedure




(C) SAP AG IUT230 11-23
© SAP AG 1999
¤ Register
Þ Fixed Temperature
Þ 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
¤ Reference Values/Lighting
¤ Billing Deregulated Contracts
¤ Archiving Billing Data
¤ Special Types of Billing
Special Billing Features: 3




(C) SAP AG IUT230 11-25
© SAP AG 1999
Street lighting is billed using reference
values from the installations facts
REFVAL04
REFVAL05
REFVAL06
REFVAL04
REFVAL05
REFVAL06
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
¤ Reference Values/Lighting
¤ Billing Deregulated Contracts
¤ Archiving Billing Data
¤ Special Types of Billing
Special Billing Features: 4




(C) SAP AG IUT230 11-29
© SAP AG 1999
Distribution
Procurement
Transmission
Distribution
Disposal
Transmission
Extraction
Procurement
Distribution
Trans-
mission
Generation
Procurement
Additional Additional
divisions divisions
Such as: Such as:
Local heating Local heating
Public transport Public transport
Cable TV Cable TV
Waste removal Waste removal
Sale of appliances Sale of appliances
. . . . . . . . . .
Usually joint Usually joint
customer service/billing customer service/billing
C o n t r o l l i n g
Internal company structure according to plants, clients, and groups
Usually
joint
meter reading
Customer
1
0
0
1
0
0
Total
Saales Tax
Subt otal
SALESPERSON DATE
Total Pr ice Descr iption Qty Shipped Qty Ordered
INVOI CE #: P. O. #:
Customer Premise
Bill Bill
Energy Energy
Contract Contract
between between
XXXXXXXXX XXXXXXXXX
and and
EVU EVU Ltd Ltd
nnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnn
mmmmmmmmmmmmmmmmmmm mmmmmmmmmmmmmmmmmmm
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
uuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuu
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Energy Supply Energy Supply
Contract Contract
between between
XXXXXXXXX XXXXXXXXX
and and
EVU EVU Ltd Ltd
nnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnn
mmmmmmmmmmmmmmmmmmm mmmmmmmmmmmmmmmmmmm
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
uuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuu
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Energy supply Energy supply
contract contract
between between
XXXXXXXXX XXXXXXXXX
and and
EVU EVU Ltd Ltd
nnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnn
mmmmmmmmmmmmmmmmmmm mmmmmmmmmmmmmmmmmmm
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
uuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuu
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Energy Energy
supply supply
contract contract
between between
< Customer > < Customer >
and and
< utility company> < utility company>
Meter reading
results
Meter reading
results
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"
A
c
t
i
v
i
t
y

a
l
l
o
c
a
t
i
o
n
H
i
g
h
l
y

r
e
g
u
l
a
t
e
d
H
i
g
h
l
y

r
e
g
u
l
a
t
e
d
R
e
g
u
l
a
t
e
d
R
e
g
u
l
a
t
e
d
C
o
m
p
e
t
i
t
i
o
n
C
o
m
p
e
t
i
t
i
o
n
D
e
r
e
g
u
l
a
t
e
d
D
e
r
e
g
u
l
a
t
e
d
E
n
e
r
g
y

t
r
a
d
i
n
g

c
o
m
p
a
n
y
/
b
r
o
k
e
r
E
n
e
r
g
y

t
r
a
d
i
n
g

c
o
m
p
a
n
y
/
b
r
o
k
e
r
Customer
1
0
0
1
0
0
Total
Saal es Tax
Subt otal
SALESPERSON DATE
Total Pr ice Descr ipti on Qty Shi pped Qty Or der ed
I NVOICE #: P. O. #:
Customer Premise
Bill Bill
Meter reading
results
Meter reading
results
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
O
r
g
a
n
i
z
a
t
i
o
n

f
o
r

I
n
t
e
r
n
a
l

A
c
t
i
v
i
t
y

A
l
l
o
c
a
t
i
o
n
1 1
4 4
3 3
2 2
5 5 6 6
7 7
7 7
7 7
7 7
H
i
g
h
l
y

R
e
g
u
l
a
t
e
d
H
i
g
h
l
y

R
e
g
u
l
a
t
e
d
R
e
g
u
l
a
t
e
d
R
e
g
u
l
a
t
e
d
D
e
r
e
g
u
l
a
t
e
d
D
e
r
e
g
u
l
a
t
e
d
C
o
m
p
e
t
i
t
i
o
n
C
o
m
p
e
t
i
t
i
o
n
E
n
e
r
g
y

T
r
a
d
i
n
g

C
o
m
p
a
n
y
/
B
r
o
k
e
r
E
n
e
r
g
y

T
r
a
d
i
n
g

C
o
m
p
a
n
y
/
B
r
o
k
e
r
1
0
0
1
0
0
"Energy One" "Energy One"
Total
Saales Tax
Subt otal
SALESPERSON DATE
Total Pr ice Descr ipti on Qty Shi pped Qty Or der ed
INVOICE #: P. O. #:
Customer Cons. Premise
Bill Bill
Meter Reading Meter Reading
Results Results
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
One
Division
Several
Divisions
Single
UC
Several
UCs
Standard
Billing
Standard
Billing
Multi-
Sector
Billing
Multi-
Sector
Billing
Unbundled
Billing
Unbundled
Billing
Convergent
Billing
Convergent
Billing
UC: Utility company
Standard Billing: Standard Billing:
Billing of one division for services rendered
by one utility company
Multi Multi- -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
One
Division
Several
Divisions
Single
UC
Several
UCs
Standard
Billing
Multi-
Sector
Billing
Unbundled
Billing
Unbundled
Billing
Convergent Convergent
Billing Billing
UC: Utility company
Example:
Home Electricity
Provider
Home Electricity
Provider
Cx/Electricity/Energy . . . . . . . UNI
C1/Electricity/Distribution. . . . . UNI
C1/Electricity/Cust. Service. . . UNI
TP/Cont. to standard assets. . . . . UNI
---------------------------------------------
Total: . . . . . . . . . . . . . . . . . . . UNI
Bill Mr. Smith/<Address>
Energy Supply Service:
Competing
Electricity
Provider
Competing
Electricity
Provider
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
Business
partner
Business
partner
Contract
A/R & A/P
Contract
A/R & A/P
Installation 1 Installation 1
Device Device
Contract 1 Contract 1
Installation 2 Installation 2
Contract 2 Contract 2
Billing-
related
installation
Billing-
related
installation
Contract 1 with home
electricity provider
Billing of transmission charges
in company code 0001
Contract 2 with suppliers
Billing of supplied energy in
company code 0002
Device
location
Device
location
Technical installation
MMM
Supplier Supplier
M MM
IDE
Intercompany
Data Exchange
Home electricity Home 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
Installation 1 Installation 1
Device Device
Contract 1 Contract 1
Point of
delivery
service
Point of
delivery
service
Billing-
related
installation
Contract, distribution
of grid usage costs to billing
Point of delivery service 'utility'
Device
location
Device
location
Business
partner
Business
partner
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 Billing
Separation 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
Equipment
Device
Equipment
Device
Material
Device
Category
Material
Device
Category
Consumption
Premise
Consumption
Premise
Regional
Structure
Regional
Structure
Installation Installation
Functional Location
Connection Object
Functional Location
Connection Object
Installation
Structure
Installation
Structure
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
¤ Reference Values/Lighting
¤ Billing Deregulated Contracts
¤ Archiving Billing Data
¤ Special Types of Billing
Special Billing Features: 5




(C) SAP AG IUT230 11-40
© SAP AG 1999
R/3 R/3 DB DB
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)
Preparation
Program
Preparation
Program
R/3
Database
R/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
Archive
File
Archive
File
Archive
File
Archive
File
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
Archiving
Program*
Archiving
Program*
R/3
Database
R/3
Database




(C) SAP AG IUT230 11-43
© SAP AG 1999
Archiving
Program*
Archiving
Program* R/3
Database
R/3
Database
Archive
File 2
Archive
File 2
Archive
File 1
Archive
File 1
Step 3: Execute Delete Program (1)
Delete
Program
Delete
Program
R/3
Database
R/3
Database
Archive
File 2
Archive
File 2
Archive
File 1
Archive
File 1
Execute Delete Program (2)
Delete
Program
Delete
Program
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_BBP
Print 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_BILL ISU_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
¤ Reference Values/Lighting
¤ Billing Deregulated Contracts
¤ Archiving Billing Data
¤ Special Types of Billing
Special Billing Features: 6




(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 real
billing document
|------|------|------|------|------|------|
|---------------------------------| all estimated billing documents in one
time slice
|------|------|------|------|------|------| all estimated billing documents in the
original 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 DYN1
2. 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 period
DPCtest | E------G | CONS | Current period
DPCtest | G------G | 0000 | Current period
DPCtest | G------G | CONS | Current period
DPCtest | G------E | 0000 | Current period
DPCtest | 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 of
subsidiary company 1
kW
Y-A
xis
X-Axis
Demand-time profile of
subsidiary company 2
kW
Y-A
xis
X-Axis
kW + + .. +
10
20
30
X axis
100
200
300
kW
Total demand of the
company
Aggregated demand-time
profile of the company
X axis
100
200
300
kW
Total demand of the
company
X axis
kW
Contractually-agreed
demand
[ ]* 5
0
,0
0
1
0
0
,0
0
1
5
0
,0
0
2
0
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
5
0
0
,00
1
0
0
0
,00
1
5
0
0
,0
0
2
0
0
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 all
intervals
Sum of all
intervals
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 in
joint 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 1
Outline 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
2
Contract 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 agreements
OA Rule group
OA1 R1
OA2 R2
… …
Individual contracts
OA IC
OA1 IC1
OA1 IC2
OA2 IC3
… …
Activities
AC
01 Completeness
02 Total consumption
03 Individual discount
… …
Allocation to rule group
RG AC
01 01
01 02
02 01
… …
Rule group
RG
01 Joint billing
02 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
Data
entry
Data
com-
pression
Complete
control
Data
exchange
Billing
Lock
Data
exchange
Unlock
SAP
Standard
Customer-
defined
Multiple-Contract Billing




(C) SAP AG IUT230 11-87
© SAP AG 1999
Billing outline
agreements
Billing
individual
contracts
Bill printout Creating
meter
reading
contract
Point 01
After the meter
reading results
have been
entered and
before the
individual
contracts have
been billed.
Point 02
After the individual
contracts have
been billed and
before the outline
agreements have
been billed.
Point 03
Discounts
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




(C) SAP AG IUT230 12-1
© SAP AG 1999 © SAP AG 2001
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Utility Information System (UIS)
Þ SAP Business Information Warehouse (BW)
Sales Statistics




(C) SAP AG IUT230 12-2
© SAP AG 1999 © SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ Describe the Data Warehouse concept
¤ Describe the information from the application to the
SAP Business Information Warehouse (BW)
Sales Statistics: Unit Objectives




(C) SAP AG IUT230 12-3
© SAP AG 1999
Maintain
Billing
Master Data
Use of Rates
in the
Master Data
Invoicing
Bill
Printout
Billing
Budget Billing Budget Billing Budget Billing
Additional Functionality:
Discounts/Surcharges
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 11



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

(C) SAP AG IUT230 12-4
© SAP AG 1999
Sales Statistics: 1
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Utility Information System (UIS)
Þ SAP Business Information Warehouse (BW)
Þ Customizing




(C) SAP AG IUT230 12-5
© SAP AG 1999
Online
Transaction
Processing
DATA
WARE-
HOUSE
OLTP
OLAP
Analysis Tools
Online
Analytical
Processing
Summarized Information
Integrated Application Modules
External
Data
Sales &
Distribution Finance
IS-U/CCS
Material
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.

(C) SAP AG IUT230 12-6
© SAP AG 1999
Central
Updating
Online/
Background
Logistics Data Logistics Data
Warehouse Warehouse
Planning
Copy
Management
External Data External Data
Internal Data Internal Data
(R/2 (R/2 - - R/3) R/3)
Standard
Analyses
Flexible
Analyses
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.

(C) SAP AG IUT230 12-7
© SAP AG 1999
LIS LIS LIS
Information Library Information Library
PP-IS PP PP- -IS IS SIS SIS SIS PURC
HIS
PURC PURC
HIS HIS
INVCO INVCO INVCO
UIS UIS UIS QM-IS QM QM- -IS IS PM-IS PM PM- -IS IS WM-IS WM WM- -IS IS
R1
:
R4
1988
------
------
------
1994
------
------
------
Purchase
Requisition In
voice
P
rojects
P
M
O
rder
S
D
O
rd
e
r
P
P
O
rd
e
r
Logistics Information System (LIS)



Þ 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 12-8
© 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.

(C) SAP AG IUT230 12-9
© SAP AG 1999
Sales Statistics: 2
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Utility Information System (UIS)
Þ SAP Business Information Warehouse (BW)
Þ Customizing




(C) SAP AG IUT230 12-10
© SAP AG 1999
Analyses
Analyses
Planning
Planning
Communication
Structures
Communication
Structures
Application
Application
Business Transactions
Invoicing
Invoicing Reversal
IS-U
Update
Update
S440
S441
S449
Update
Rules
Update
Rules
Info Structures Info Structures
IS IS- -U U
Billing Billing
Document Document
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
Industry
Industry
Characteristics
Characteristics
157 005
398
Sales
Time Reference
Time Reference Time Reference
Rate
Rate
Net
Amount
Net Net
Amount Amount
Energy
Amount
Energy Energy
Amount Amount
Demand
Amount
Demand Demand
Amount Amount
Billed
Amount
Billed Billed
Amount Amount
Month
Month Month
1999
1999
Jan Feb Mar Apr MayJun Jul
. . .
. . . . . .
Format of Information Structures
Key Figures Key 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
AB
AB
Jan Feb Mar Apr
BUDAT
BUDAT
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
Billing
Amount
Net
Amount
2.0
1.0
0.0
08 09 10 11 12 01 02 03 04
Billing Quantity
Net Amount
Billing
Amount
Rate
Categories
A B C
Correlation
ABC Analysis
Cumulative
Frequency Curve
No. of
Rate Categories
Billing
Document
10.000 20.000 30.000 40.000 >
Classification
Billing Quantity
No. of
Months
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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Utility Information System (UIS)
Þ SAP Business Information Warehouse (BW)
Þ Customizing




(C) SAP AG IUT230 12-16
© SAP AG 1999
Business
Information
Warehouse
Server
Administrator
Workbench
OLAP Processor
OLAP Processor
Staging Engine
Staging Engine
InfoCubes InfoCubes
Meta Data
Repository
Meta Data
Repository
ODS ODS
Business
Explorer
Web
Reporting
Architecture




(C) SAP AG IUT230 12-17
© SAP AG 1999
Query
Workbook
Transformation
InfoObject
Regional Structure Regional Structure Regional Structure
Business Partner
Business Partner
InfoSource
Extractor
InfoCube
Best-Practice Model
Best-Practice Model
44 Key figures
101 Characteristics
20
20 Transaction data
48 Master data
38
38
20 for infoCubes
48 for infoObjects
I
n
d
i
v
i
d
u
a
l
i
z
a
t
i
o
n
S
t
a
n
d
a
r
d
s
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
Queue
2.
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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Utility Information System (UIS)
Þ SAP Business Information Warehouse (BW)
Þ 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 S S T A T I S T I C S G R O U P S S T A T I S T I C S G R O U P S
Statistics Groups for
Statistics Groups for
Contracts
Contracts
Rate
Categories
Rate
Categories
Standard Customers
Nonresidential
Customers
kunden
Division Contract Rate Cat. Update Group
01 ’ ’ ‘ ‘ 01 01 SISU
01 01 01 01 01 Z00001
Residential Customers Individual
Statistics
Stats Group ‘ ‘ Stats Group 01 Stats 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 Group
Statistics Group
Update Group SISU Update Group SISU Update Group SISU
Customer
Schultz
Customer Customer
Schultz Schultz
Update Group ZIND Update Group ZIND Update Group ZIND
Customer
SAP
Customer Customer
SAP SAP
Update Rules Update Rules
Update Rules Update Rules
1.
1.
2.
2. 3.
3.
BW
Customer =
"Dummy"
Customer =
"Dummy"
Customer =
"SAP"
Customer =
"SAP"
if update group = SISU
then
name = "Dummy"
Why Update Groups?
Billing Document
Division 01
Statistics Group ‘ ‘
Contract
Statistics Group 01
Rate 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 Schema
Rate 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'
CO CO- -
PA PA
WWABR WWABR
WWLEI WWLEI
CO CO- -
PA PA
WWABR WWABR
WWLEI WWLEI
Billing Document
Billing Document
CO-PA Statistical
Data
CO-PA Statistical
Data
CO-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 Schema
Rate Var.Prog. Stats Grp: Amount
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
NETTOBTR
St. gr. '000001'
NETTOBTR
St. gr. '000001'
CO CO- -
PA PA
VVNET VVNET
VVARB VVARB
VVLEI VVLEI
CO CO- -
PA PA
VVNET VVNET
VVARB VVARB
VVLEI VVLEI
Billing Document
Billing Document
CO-PA Statistical
Data
CO-PA Statistical
Data
CO-PA Actual Data
(always transferred)
CO-PA Actual Data
(always transferred)
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




(C) SAP AG IUT230 13-1
© SAP AG 1999
Sales Statistics: LIS (Appendix A)




(C) SAP AG IUT230 13-2
© SAP AG 1999 © SAP AG 2001
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Logistics Information System (LIS)
Þ Utility Information System (UIS)
Þ Information Flow
Þ Tools
Þ Standard Analyses
Þ Flexible Analyses
¤ CO-PA
Þ Planning/Unbilled Revenue
Reporting
Sales Statistics: Contents




(C) SAP AG IUT230 13-3
© SAP AG 1999 © SAP AG 2001
At the conclusion of this unit, you will be able to:
¤ 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




(C) SAP AG IUT230 13-4
© SAP AG 1999
Maintain Maintain
Billing Billing
Master Data Master Data
Use of Rates
in the
Master Data
Use of Rates
in the
Master Data
Invoicing Invoicing
Bill
Printout
Bill
Printout
Billing Billing
Budget Billing Budget Billing Budget Billing
Additional Functionality:
Discounts/Surcharges
Manual Billing
Sales Statistics
Special Billing Features
Additional Functionality: Additional Functionality:
Discounts/Surcharges Discounts/Surcharges
Manual Billing Manual Billing
Sales Statistics Sales Statistics
Special Billing Features Special Billing Features
Billing/Invoicing: Business Scenario 11



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

(C) SAP AG IUT230 13-5
© SAP AG 1999
Sales Statistics: 1
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Utility Information System (UIS)
Þ SAP Business Information Warehouse (BW)
Þ Customizing




(C) SAP AG IUT230 13-6
© SAP AG 1999
EWS EWS
Early Warning System Early Warning System
Flexible Analysis Flexible Analysis
Standard
Analysis
Standard
Analysis
Advanced
Analysis Techniques
Advanced
Analysis Techniques
• Selection Versions
• Authorizations
• Selection Versions
• Authorizations
FI
PP MM
External
Data
SD
Data Warehouse Concepts: Overview




(C) SAP AG IUT230 13-7
© SAP AG 1999
Online
Transaction
Processing
DATA
WARE-
HOUSE
OLTP
OLAP
Analysis Tools
Online
Analytical
Processing
Summarized Information
Integrated Application Modules Integrated Application Modules
External
Data
Sales &
Distribution Finance
IS-U/CCS
Material
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.

(C) SAP AG IUT230 13-8
© SAP AG 1999
Central
Updating
Online/
Background
Logistics Data
Warehouse
Logistics Data
Warehouse
Planning
Copy
Management
External Data External Data
Internal Data
(R/2 - R/3)
Internal Data
(R/2 - R/3)
Standard
Analyses
Flexible
Analyses
Logistics Information System (LIS)



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

(C) SAP AG IUT230 13-9
© SAP AG 1999
LIS LIS LIS
Information Library Information Library
PP-IS PP PP- -IS IS SIS SIS SIS PURC
HIS
PURC PURC
HIS HIS
INVCO INVCO INVCO
UIS UIS UIS QM-IS QM QM- -IS IS PM-IS PM PM- -IS IS WM-IS WM WM- -IS IS
R1
:
R4
1988
------
------
------
1994
------
------
------
Purchase
Requisition Invoice
P
rojects
P
M
O
rder
S
D
O
rd
e
r
P
P
O
rd
e
r
Logistics Information System (LIS)



Þ 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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Logistics Information System (LIS)
Þ Utility Information System (UIS)
Þ Information Flow
Þ Tools
Þ Standard Analyses
Þ Flexible Analyses
¤ CO-PA
Þ Planning/Unbilled Revenue Reporting




(C) SAP AG IUT230 13-11
© SAP AG 1999
Analyses
Analyses
Planning
Planning
Communication
Structures
Communication
Structures
Application
Application
Business Transactions
Invoicing
Invoicing Reversal
IS-U
Update
Update
S440
S441
S449
Update
Rules
Update
Rules
Info Structures Info Structures
IS IS- -U U
Billing Billing
Document Document
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 Retrieval
SAP (batch job)
Data Retrieval
Customer (user-exit)
Billing Documents
IS-U Database
SAP Fields Customer Fields
Communication Structure
Information Structures
UIS
Field Catalogs
Key Figures
ERCH ERCH
ERCHZ ERCHZ
ERCHC ERCHC
Master Data
External Data External Data
E
v
e
n
t
E
v
e
n
t
S
u
m
m
a
r
i
z
a
t
i
o
n
S440 S440 S441 S441 S449 S449
Key Figures Time
Reference
Charac-
teristics
Time
Reference
Charac-
teristics
Information Flow / Technical View




(C) SAP AG IUT230 13-14
© SAP AG 1999
Industry
Industry
Characteristics Key Figures
Characteristics Key Figures Key Figures
157 005
398
Sales
Time
Reference
Time Time
Reference Reference
Rate
Rate
Net
Amount
Net Net
Amount Amount
Demand
Amount
Demand Demand
Amount Amount
Demand
Amount
Demand Demand
Amount Amount
Billed
Amount
Billed Billed
Amount Amount
Month
Month Month
1999
1999
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 Structure
Communication Structure
MCVU_ESTA
UIS Field Catalogs UIS Field Catalogs UIS 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
P
i
c
k

U
p
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
VU
Description
Characteristics
Key Figures
Transp. Tables S440 - S449
INDUSTRY RATE DIVISION
DDIC DDIC
P
i
c
k

U
p
G
e
n
e
r
a
t
i
o
n
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
Division
Rate
.
.
.
Key Figures
Invoiced amount
Billing quantity
.
.
.
Definition Saved in Tables
Definition Saved in Tables
Standard Analysis
S440 S440 S440E S440E
Dependent Objects:
Customer
Material
Tools
Screens
Generation Generation Generation
Save Save Save
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 Quantity Update for Billing Quantity Update for Billing Quantity
Info Structure
Update Group
Key Figures
....
....
....
....
....
Rules: Key figure
Rules: Key figure
S440
SISU
Billing Quantity
S440 S440
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 Quantity Updating for Billing Quantity Updating for Billing Quantity
...
Key Figure
Key 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
AB
AB
Jan Feb Mar Apr
BUDAT
BUDAT
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 Parameters
Info Str. Description
S440 Rate statistics
S441 Industry statistics
S501 User-defined
Statistics
.
.
.
S501 User-Defined Statistics
Period split
Posting period
Month
Week
Day
Updating
No update
Synchronous update
Asynchronous update
Document
Document
Document
S440 S440
S441 S441
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 S S T A T I S T I C S G R O U P S S T A T I S T I C S G R O U P S
Statistics Groups for
Statistics Groups for
Contracts
Contracts
Rate
Categories
Rate
Categories
Standard
Customers
Nonresidential
vertrags-
Customers
Division Contract Rate Cat. Update Group
01 ’ ’ ‘ ‘ 01 01 SISU
01 01 01 01 01 Z00001
Residential
Customers
Individual
Statistics
Stats Group ‘ ‘ Stats Group 01 Stats 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 Schema
Rate 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
MCVU_ESTA MCVU_ESTA
Communications
Structure
I_ABRMENGE
I_LEIMENGE
Communications
Structure
I_ABRMENGE
I_LEIMENGE
CO CO- -
PA PA
UIS UIS
WWABR WWABR
WWLEI WWLEI
CO CO- -
PA PA
WWABR WWABR
WWLEI WWLEI
Sales Statistics
Sales Statistics
CO-PA Statistical
Data
CO-PA Statistical
Data
CO-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. 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 Schema
Rate Var.Prog. Stats Grp: Amount
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
MCVU_ESTA MCVU_ESTA
Communications
Structure
NETTOBTR
ARBEITBTR
LEISTBTR
....
Communications
Structure
NETTOBTR
ARBEITBTR
LEISTBTR
....
CO CO- -
PA PA
UIS UIS
VVNET VVNET
VVARB VVARB
VVLEI VVLEI
CO CO- -
PA PA
VVNET VVNET
VVARB VVARB
VVLEI VVLEI
Sales Statistics
Sales Statistics
CO-PA Statistical
Data
CO-PA Statistical
Data
CO-PA Actual Data
(always transferred)
CO-PA Actual Data
(always transferred)
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 Group
Statistics Group
Update Group
SISU
Update Group Update Group
SISU SISU
Update Group
Z00001
Update Group Update Group
Z00001 Z00001
Customer
C
Customer Customer
C C
Customer
A
Customer Customer
A A
S501-Field 3 S501-Field 3
S501-Field 1
S501-Field 2
S501-Field 3
S501-Field 1
S501-Field 2
S501-Field 3
S501-Field 2 S501-Field 2
S501-Field 1
S501-Field 3
S501-Field 1
S501-Field 3
Update Group
SISU
Update Group Update Group
SISU SISU
Customer
B
Customer Customer
B B
Update Update
Rules Rules
Update Update
Rules Rules
Update Update
Rules Rules
1.
2.
3.
Update Update
Rules Rules
Billing
Document
Division 01
Statistics Group ‘ ‘
Contract
Statistics Group 01
Rate Category
Update group SISU
Billing 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 Definition UIS Customizing : Updating - Precise Definition
Editor Editor
....................................................................
...
FORMULA_VALUE =
... MCVU_ESTA-ABRMENGE* (-1).
...
Editor Editor
....................................................................
IF MCVU_ESTA-MENGESTREL = ' '
... RETURNCODE = 4.
... ENDIF
...
Relevance for statistics
Quantity * (-1)
...
900
...
...
900
...
¤ Invoicing
Key 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
Analysis Analysis
Comm.Structure Comm.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
Check
Formulas and
Conditions
Formulas and
Conditions
Oper.
System
Derive and
Calculate
Key Figures
Derive and
Calculate
Key Figures
User Exits in UIS
Info Structure Info 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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Logistics Information System (LIS)
Þ Utility Information System (UIS)
Þ Information Flow
Þ Tools
Þ Standard Analyses
Þ Flexible Analyses
¤ CO-PA
Þ Planning/Unbilled Revenue Reporting




(C) SAP AG IUT230 13-29
© SAP AG 1999
Update Log
Update Log
Update log of the last update run:
Update simulation of a billing document:
Document
Document
Update Analysis
Update Analysis
Update Log
Update Log
Update Analysis
Update 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
S440 S440
S441 S441
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 & (2 Version & (2
Version & (1 Version & (1
Version 000
(actual data)
Version 000
(actual data)
1. Saving of actual data
RMCSISCP
2. Rebuilding of billing
documents
REASTA02
3. Copying of rebuilt
data to actual data
RMCSISCP
Billing
documents
Billing
documents
2
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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Logistics Information System (LIS)
Þ Utility Information System (UIS)
Þ Information Flow
Þ Tools
Þ Standard Analyses
Þ Flexible Analyses
¤ CO-PA
Þ Planning/Unbilled Revenue Reporting




(C) SAP AG IUT230 13-33
© SAP AG 1999
Bill
Rate Category: E1
Doc. Date: 05/15/99
2000 kWh at 0.24 UNI 480
3200 kWh at 0.11 UNI 352
Info Structure
in UIS
Info Structure
in UIS
Rate Cat.
E1
E1
E2
Rate
E1_1
E1_2
E2_1
Month
05.99
05.99
05.99
Amount
2000
3200
13000
Rate Category:
E1
Month: 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 Billing
Amount
Net
Amount
100 000
200 000
28 800
22 000
•
01
02
•
Division: 01 Electricity
Billing
Class
Billing
Amount
Net
Amount
60 000
40 000
14 400
4 400
0001
0002
Billing Class: 0001
Rate Cat. Billing
Amount
Net
Amount
20 000
25 000
48 00
60 00
•
02.1999
03.1999
•
Double
click
Double
click
Standard
Drilldown
Division
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
Division: 01 Electricity
Billing
Class
Billing
Amount
Net
Amount
60 000
40 000
14 400
4 400
0001
0002
Rate Statistics
Switch Drilldown
Billing Class
Division
Rate
Statistical Rate
Rate Fact Group
Rate Category
Switch Drilldown
Month
Rate Fact Group: 0001
Month Billing
Amount
Net
Amount
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. Billing
Amount
Net
Amount
100 000
200 000
28 800
22 000
•
E1
E2
•
Edit
.....
Comparisons
.....
.....
Year/Previous Year Comparison: Billing Amount
Rate Category Prev.yr Current Difference %
.
.
E1
E2
50 000
50 000
30 000
70 000
- 20 000
20 000
40 %
40 %
-
+
.
.
.
.
.
.
.
.
Key Figures Comparison: Energy Amount - Service Amount
Rate Cat. Energy amt Service amt Difference %
. . . . .
E1
E2
30 000
70 000
20 000
70 000
- 10 000
0 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
Billing
Amount
Net
Amount
2.0
1.0
0.0
08 09 10 11 12 01 02 03 04
Billing Quantity
Net Amount
Billing
Amount
Rate
Categories
A B C
Correlation
ABC Analysis
Cumulative
Frequency Curve
No. of
Rate Categories
Billing
Amount
10.000 20.000 30.000 40.000 >
Classification
Billing Quantity
No. of
Months
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 Drilldown 1
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 System Early Warning System
Sxxx Sxxx
Info
Structures
Info
Structures
Purchasing IS Purchasing IS Purchasing IS
Sales IS Sales IS Sales IS
Inventory
Controlling
Inventory Inventory
Controlling Controlling
UIS UIS UIS
Production IS Production IS Production IS
Indicates Defined
Alarm Situation
Indicates Defined
Alarm Situation
Highlights
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 Statistics
Rate Cat.Amount Net
Amount
100 000
230 000
350 000
24 000
55 200
84 000
•
E1
E2
E3
Rate Statistics
Rate Cat.Amount Net
Amount
230 000
350 000
55 200
84 000
E2
E3
LIS
Data
E
x
c
e
p
t
i
o
n
E
x
c
e
p
t
i
o
n
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
157 157
005 005
396 396
Info Structure Info Structure
S440 S440
Active for Standard Analysis
Transfer to Workflow
Mail
Fax
Transfer to Distribution List
Characteristics
Rate Cat.
Rate
Month
Exception: Characteristics
Key Figures
Conditions
Amount < 200,000
Exception: Conditions
Define Conditions
Select Key Figures Exception
Exception
Threshold Value Threshold Value
Trend Trend
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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Logistics Information System (LIS)
Þ Utility Information System (UIS)
Þ Information Flow
Þ Tools
Þ Standard Analyses
Þ Flexible Analyses
¤ CO-PA
Þ Planning/Unbilled Revenue Reporting




(C) SAP AG IUT230 13-44
© SAP AG 1999
Database Tables Database Tables Database Tables
LIS Table Descriptions LIS Table Descriptions LIS Table Descriptions
Reports Reports Reports
Data Display
Data Retrieval
Logical
Data View
Physical
Data Basis
Evaluation
Structure
Evaluation
Structure
DDIC
Tables
DDIC
Tables
Info
Structures
Info
Structures
Evaluation
Evaluation
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
EACTST003
EACTST003
ZFST003
Charact. Key Figures
..... .....
..... .....
..... .....
ZFST003 ST003
Charact. Key Figures
..... .....
..... .....
..... .....
XY01 XY01
Charact. Key Figures
..... .....
..... .....
Formulas
Layout
DD Structure
DD Structure
Evaluation Structure
Evaluation Structure
Evaluation
Evaluation
Data Retrieval
and Display
(using Report Writer
functions)
Logical
Data View
Physical
Data 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
¤ Sales Statistics
Þ Data Warehouse Concepts
Þ Logistics Information System (LIS)
Þ Utility Information System (UIS)
Þ Information Flow
Þ Tools
Þ Standard Analyses
Þ Flexible Analyses
¤ CO-PA
Þ Planning/Unbilled Revenue Reporting




(C) SAP AG IUT230 13-47
© SAP AG 1999
Overhead Cost Overhead Cost
Controlling Controlling
Product Cost Product Cost
Controlling Controlling
Profit
Center
PrCtr PrCtr 1 1
PrCtr PrCtr 3 3
PrCtr 2
PrCtr PrCtr 4 4
PrCtr PrCtr 5 5
Profitability Profitability
Analysis Analysis
C
o
s
t

a
n
d

R
e
v
e
n
u
e

E
l
e
m
e
n
t

A
c
c
o
u
n
t
i
n
g
C
o
s
t

a
n
d

R
e
v
e
n
u
e

E
l
e
m
e
n
t

A
c
c
o
u
n
t
i
n
g
Profitability Segments
Cost Center Acc.
Process
Cost Acc.
Bill
Cost
Object
CO
Overhead
Cost Order
Profit Profit
Center Center
Bill Bill
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
Company
Company
4 Who are our most important and fastest-
growing customers?
4 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
Invoicing
IS-U
Profitability Analysis
CO-PA
Sales Key Figures:
Revenues,
Cost of sales...
Market Segments:
Customer, Rate Cat.,
Rate, Account Cat.,
Division
CO CO- -
PA PA
IS IS- -U U
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
Characteristics Characteristics Characteristics
R
E
G
I
O
N
S






N






W
Rate Cat.
A
c
c
o
u
n
t

C
a
t
.
Division Electricity
Region North
Rate category E3
Rate E3_1
Account cat. Res. cust.
E1
Revenues
Rate Cat.
E3
Revenues
Rate Cat.
E3
Consumption 1500
Revenue 800
Cost 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
CO CO- -PC PC
Cost Centers
Orders
Processes
Product
Costing
G/L Account
Posting
Invoice
FI FI
CO CO- -OM OM
CO CO- -PA PA
SD SD
Accrued
Costs
Amount
Amount
Revenue
Revenue
Sales Deductions
Sales Deductions
Goods Usage
Goods Usage
Variable Cost of Goods Manufctrd
Variable Cost of Goods Manufctrd
Fixed Cost of Goods Manufactured
Fixed Cost of Goods Manufactured
Rebate
Rebate
Freights
Freights
Sales and Administration Costs
Sales and Administration Costs
Marketing Costs
Marketing Costs
Variances
Variances
Accrued Discounts
Accrued Discounts
Accrued Rebates
Accrued Rebates
1993
1994
1995
IS IS- -U U
Invoicing
Unbilled Revenue Reporting
Amount
Amount
Revenue
Revenue
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
Customizing
Customizing
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
CO CO- -
PA PA
IS IS- -U U
Operating
Concern
Active
Operating
Concern
Active
Change Contract
Contract Edit Goto Additional System Help
Contract TF0415A001
Account Assignment Data
Profitability segment assigned X
CO CO- -
PA PA
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 Documents Billing Documents
Transfer to
CO-PA
Billing Documents Billing Documents
Transfer to
CO-PA
Statistically
IS IS- -U U
CO CO- -
PA PA
IS IS- -U U
CO CO- -
PA PA
Revenue and
Profitability
Bill
Unbilled Rev.
Proration
(General
Procedure)
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?
_________________________________________________________
1-2-3 Display the evaluation in the various possible business graphics.

(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.
1-1-3 Display the evaluation in the various possible business graphics.
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.
Maintain the field content as described in the exercise.
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.
From the SAP Reference IMG, choose: SAP Utilities → →→ → Information System
→ →→ → 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.
From the SAP Reference IMG, choose: SAP Utilities → →→ → Information System
→ →→ → 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:
From the SAP Reference IMG, choose: SAP Utilities → →→ → Information System
→ →→ → 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.
From the SAP menu, choose: Utilities Industry → →→ → Information System → →→ →
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.
From the SAP menu, choose: Utilities Industry → →→ → Information System → →→ →
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.
From the SAP menu, choose: Utilities Industry → →→ → Information System → →→ →
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




(C) SAP AG IUT230 15-2
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


(C) SAP AG IUT230 15-3
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.





(C) SAP AG IUT230 15-4

Overview
The following table shows a section of the schema for this billing rule. In addition to the
demand calculation (rate E7_3), the on-peak (rate E7_1) and off-peak consumption (rate
E7_2) are charged in this example.

No. Rate Variant 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
2 E7_2 QUANTI01 X EQUANT_2 EQPRICE_2 EAMOUNT_1
3 E7_3 INFACT01 EDEMAND1 EDEMAND7
4 E7_3 DEMAND14 EDEMAND1 EDEMAND6
5 E7_3 BACKBI01 0002
6 E7_3 BACKBI03 EDEMAND7 EDEMAND6 X 0002
7 E7_3 DEMAND07 EDEMAND6 EDEMAND4 EDEMAND5
8 E7_3 INFACT01 EDEMAND5 EDEMAND8
9 E7_3 DEMAND01 X EDEMAND5 ETPRICE_1 EAMOUNT_1 0003 0003
10 E7_3 IF00 EDEMAND5 EDEMAND8
11 E7_3 ELSE
12 E7_3 BACKBI02 EDEMAND5 EDEMAND5
13 E7_3 BACKBI01 0003
14 E7_3 ENDIF

Key:
Variant: Name of the variant program
PR: Billing line items relevant 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



(C) SAP AG IUT230 15-5
In demand rate E7_3, the current measured demand is transferred to the installation facts using
INFACT01. This demand is also updated to the operand planned for peak averaging and required
for the current period using DEMAND14. At this point, it only contains one demand value (if
only the peak monthly demand value is to be considered). In the next step, backbilling is triggered
with BACKBI01. In the Execute backbilling indicator column, you specify which steps are to be
carried out in backbilling. In the next step, you write the demand values for the previous periods
(adjustment periods) to the output operand for peak averaging using the same group assignment
and variant BACKBI03.
Example:
The backbilling period starts on January 1 and ends on December 31 of the same year. The current
billing month is April. 40 kW was measured in April.
The following demand values have so far been entered using INFACT01 in the installation facts
(demand values from the meter reading):

January February March
|----------------------|----------------------|----------------------|
30 kW 20 kW 10 kW

After the BACKBI03 variant has been run, the following values for calculating the 3-peak average
are available in the current billing period:

January February March April
|----------------------|----------------------|----------------------|----------------------|
40 kW (April)
30 kW (January)
20 kW (February)
10 kW (March)


(C) SAP AG IUT230 15-6
During demand preprocessing, the 3-peak average is calculated on the basis of the number
of peaks specified in the operand.
In the above example, the demand values 30 kW, 20 kW, and 40 kW are used to calculate
the 3-peak average. The result is 30 kW.
In the next step, the calculated peak average is compared with the minimum demand,
which is also entered in the facts (rate, rate category, or installation facts). For this purpose,
variant DEMAND07 writes the result to the output operand that represents the demand to
be 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


(C) SAP AG IUT230 15-7
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.

January February March April May
|-------------------|-------------------|-------------------|-------------------|-------------------|
< -----30 kW---- >
Adjustment periods:
< -----30 kW---- >
< -----30 kW---- >
< -----30 kW---- >
When backbilling is triggered using BACKBI01, the variant programs that have the same
backbilling group (here 0003) are triggered. If these steps also contain an entry in the
backbilling reversal column, schema steps marked in such a way cause the billing line
items generated in the preceding periods (adjustment periods) to be reversed.
Example:
The billings up to March have taken into account a settlement demand of 20 kW.
January February March
|----------------------|----------------------|----------------------|

Adjustment periods:
< -----20 kW--- >
< -----20 kW----- >
< -----20 kW------ >


(C) SAP AG IUT230 15-8
In billing for April, a new settlement demand has been calculated. After variant
BACKBI02 has been executed, the following data is available:
January February March April May
|-------------------|-------------------|-------------------|-------------------|-------------------|
< ----30 kW---- >
Adjustment periods:
< -----30 kW---- >
< -----30 kW---- >
< -----30 kW---- >

Backbilling is triggered using BACKBI01. By means of variant DEMAND01, which has
the Execute backbilling indicator, 30 kW are charged for the individual adjustment periods,
and (as a result of the backbilling reversal indicator) 20 kW from the individual adjustment
periods are reversed. The current billing month (in this case April) remains unaffected by
this.



(C) SAP AG IUT230 15-9
Backbilling Indicators in the Billing Schema
The following descriptions refer to the demand rate, in which the peak average is formed
and floating backbilling is carried out.

No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExB
B
B
B
AllB
B1
Rev
BB1
. . .

. . .

3 E7_3 INFACT01 EDEMAND1 EDEMAND7
4 E7_3 DEMAND14 EDEMAND1 EDEMAND6
5 E7_3 BACKBI01
0002
6 E7_3 BACKBI03 EDEMAND7 EDEMAND6
X 0002
7 E7_3 DEMAND07 EDEMAND6 EDEMAND4 EDEMAND5

8 E7_3 INFACT01 EDEMAND5 EDEMAND8

9 E7_3 DEMAND01 X EDEMAND5 ETPRICE_1 EAMOUNT_1
0003 0003
10 E7_3 IF00 EDEMAND5 EDEMAND8

11 E7_3 ELSE

12 E7_3 BACKBI02 EDEMAND5 EDEMAND5

13 E7_3 BACKBI01
0003
14 E7_3 ENDIF

Key:
ExBB: Execute backbilling indicator
BB: Execute schema step in backbilling only indicator
AllBB1: Allocate backbilling indicator
RevBB1: Reverse backbilling indicator


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

13 - BACKBI01 – Triggering backbilling
This variant triggers backbilling.
In more specific terms, the variant program steps are executed with the same backbilling
control group. The schema steps that have the same group in the backbilling reversal
indicator column are reversed.

14 - ENDIF – Ending an IF nesting level
This ends the IF nesting level you previously opened using an IF## variant.


(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

Field Name Value Note
Header Data:
Operand EDEMAND_6 Name can be freely assigned.
Operand category DEMAND
Usage Standard usage
General Data
Rounding # As required.
Rounding type # As required.
Operand group Optional See above
Access to operand 02 The value on the key date is valid. This
control function is selected depending
on the contractual conditions.
History 0 No restrictions relating to the historical
changeability are specified.
Special Control:
No. of peaks 3 During demand preprocessing, which is
activated for certain variants, this
operand contains the result of the
calculation (in this case the 3-peak
average).

During demand preprocessing, the value for the number of peaks is evaluated and the
result of the calculation entered in this operand.


(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
6 INFACT01 01 EDEMAND5 EDEMAND8
7 DEMAND01 01 02 EDEMAND5 ETPRICE_1 EAMOUNT_1
8 IF00 03 EDEMAND5 EDEMAND8
9 ELSE
10 BACKBI02 EDEMAND5 EDEMAND5
11 BACKBI01 F
12 ENDIF

Section of the rate for demand calculation.
Key:
No. Current rate step number
Variant: Name of the variant program
PC: Time period control
FT: Fine-tuned variant control

In the above example, a time period control function (entry 01 in column PC), which refers
to the process for calculating the period to an exact number of days, has been accessed in
Customizing. Customizing also provides time period control functions for taking special
situations into account, for example:
- leap years
- move-ins
- move-outs
- values added/omitted sub-periodically (for example, device installation).


(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
1 INFACT01 01 EDEMAND1 EDEMAND7
2 DEMAND14 01 01 EDEMAND1 EDEMAND6
3 BACKBI01 F
4 BACKBI03 EDEMAND7 EDEMAND6
5 DEMAND07 01 02 EDEMAND6 EDEMAND4 EDEMAND5
6 INFACT01 01 EDEMAND5 EDEMAND8
7 DEMAND01 01 02 EDEMAND5 ETPRICE_1 EAMOUNT_1
8 IF00 03 EDEMAND5 EDEMAND8
9 ELSE
10 BACKBI02 EDEMAND5 EDEMAND5
11 BACKBI01 F
12 ENDIF

Rate step no. 1 – INFACT01
The following control functions have been activated here:
- Information lines relating to demand are not written
- Update in billing period with proration
This setting was selected so that all the values within the billing period are also available.
It prevents information lines from being written, since this information is generated at a
later stage using variant DEMAND01.

Rate step no. 2 – DEMAND14
The following control functions have been activated here:
- Info lines relating to demand are not written
- Added during update
The information lines are not required here either. The control function relating to updating
is not relevant in this example, since the operand is used for the first time in this rate.

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

Rate step no. 5 – DEMAND07
The following control functions have been activated here:
- Only billing-relevant information is written
- The higher demand is determined
- Data is overwritten during updating
- Information lines relating to the demand comparison are written
Information lines relating to demand, in particular register meter readings, are written. The
level of detail can be specified as follows:
- No info lines are written.
- 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
The following control functions have been activated here:
- Info lines regarding demand are not written
- Update future demand
The required information lines are written in the next step.
The demand (in this case, the demand to be 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.

Rate step no. 7 – DEMAND01
The following control functions have been activated here:
- Only billing-relevant information is written.
To enable the information to be displayed on the bill (these information lines were
suppressed up to now), you choose this control function.

Rate step no. 8 – IF00
The following control functions have been activated here:
- Demand 1 = Demand 2
- Use current value
The relational operator between the two demands must be specified. You can basically
choose the following for this purpose:
- If Demand1 > Demand2
- If Demand1 >= Demand2
- If Demand1 = Demand2
Demand1 corresponds to the previous month's 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.

Field Name Value Note
Header Data:
Rate category E7 Name can be freely assigned.
Division
General Data
Billing class # As required.
Outsorting price group billing # As required. The outsorting checks
during billing are entered (for example,
maximum net amount) here.
Billing Schema:
Billing schema Here, you must enter all the rates for an
installation that are required for
calculation.
Backbilling:
Floating backbilling X See below
Number of periods 12 Periods for floating backbilling. With
this entry, the peak average calculation
is restarted after 12 periodic billings.

Indicator: Floating backbilling
If you set this indicator, floating backbilling can be carried out for the contracts assigned to
this rate category. In floating backbilling, backbilling is carried out within a fixed billing
period. In floating backbilling, you must specify the number of periods that backbilling
covers.
Floating backbilling can be triggered from a periodic billing (or a final billing).

(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
8 E8_2 INFACT02 EAMOUNT_2 EAMOUNT_2
9 E8_3 DEMAND01 X EDEMAND1 ETPRICE_1 EAMOUNT_3
10 E8_3 INFACT02 EAMOUNT_3 EAMOUNT_3
11 E8_4 QUANTI13 EQUANT_3 EQUANT_9 EFACTOR_3
12 E8_4 IF03 EFACTOR_4 EFACTOR_3
13 E8_4 QUANTI09 EQUANT_3 EFACTOR_2 EQUANT_10
14 E8_4 QUANTI02 EQUANT_9 EQUANT_10 EQUANT_11
15 E8_4 QUANTI01 X EQUANT_11 EQPRICE_5 EAMOUNT_1
16 E8_4 ENDIF
17 E8_E QUANTI10 EQUANT_6 EQUANT_7 EQUANT_8
18* E8_E QUANTI01 X EQUANT_8 EQPRICE_4 EAMOUNT_4
19 E8_E COMPUT02 EAMOUNT_1 EAMOUNT_2 EAMOUNT_5
20 E8_E COMPUT02 EAMOUNT_5 EAMOUNT_3 EAMOUNT_6
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:
Variant: Name of the variant program
PR: Billing line items relevant to posting
1
st
Inp. Op.: First input operand
2
nd
Inp. Op.: Second input operand
1
st
Outp. Op.: Output operand
ExBB: Execute backbilling indicator
BB: Execute schema step in backbilling only indicator
AllBB1: Allocate backbilling indicator
RevBB1: Reverse backbilling indicator

In addition to the calculation of the on-peak rate active energy (QUANTI01), the rate
components of on-peak rate E8_1 contain a time-based flat rate calculation with variant
LUMSUM01. The meter reading results and the calculated total amount are updated with
the appropriate variants (INFACT06 for the quantities and INFACT02 for the amounts) to
the facts for the current installation. With variant QUANTI14, the current meter reading
difference (which corresponds to the consumption) is transferred independently of the rate.
This step is necessary to define the demand factor (cosine phi) in rate E8_4.
The off-peak rate (E8_2) is valuated using variant QUANTI01. In this case too, the
quantity and the calculated amount is updated to the installation facts.
The demand rate only provides for the valuation of the current demand measured in the
current month. This is obtained using variant DEMAND01. The calculated amount is also
written to the installation facts.
The reactive current calculation is modeled in rate E8_4. In the first step of this rate, the
cosine phi is calculated using QUANTI13 from the on-peak rate active energy and reactive
energy. The value entered in the first operand is interpreted as active energy, and the value
entered in the second operand as reactive energy. Each of the values entered are cumulated,
that is, if more than one register is involved, the consumption values are added first. The
on-peak rate value results from rate E8_1 that transferred the consumption independently
of the rate. The IF03 now checks whether a cosine phi entered in the facts is greater than
the current demand factor calculated. If so, a n-% proportion of the on-peak rate active
energy is calculated using variant QUANTI09. The result is deducted from the measured
reactive energy using variant QUANTI02. With QUANTI01, this quantity is now valuated
with a price. The rate nesting is ended using ENDIF.
The final rate, E8_E, is only run in period-end billing. Furthermore, the header data of this
rate specifies that it may only be used in period-end billing. After the period billings, a
separate period-end billing order is created if the rate category does not provide for period
billing with integrated period-end billing.

(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
In this special case, the output operand defines the operand name that is to be used to write
to the installation facts. Input and output operands can have either the same name or
different names.
4 - INFACT02 - Writing an amount to the installation facts
In this special case, the output operand defines the operand name that is to be used to write
to the installation facts. Input and output operands can have either the same name or
different names. This amount is used in period-end billing to calculate the maximum
amount.
5 - QUANTI14 - Rate-independent transfer of register operands
The quantity represented by the input operand is updated without changes. This variant is
only expedient if the input operand is a register operand. These are only known within the
corresponding rate, but may also be needed for processing in different rates. The quantity
is required for calculating the cosine phi demand factor.

(C) SAP AG IUT230 15-30
Active Energy Off-Peak Rate
6 - QUANTI01 - Valuating a quantity with a price
An off-peak rate quantity is valuated with a price.
7 - INFACT06 - Writing a quantity to the installation facts
This quantity is also written to the installation facts.
8 - INFACT02 - Writing an amount to the installation facts
The calculated amount from the valuation of the off-peak rate is written to the installation
facts.

Demand Rate
9 - DEMAND01 - Valuating a demand with a price
A demand is valuated with a price. Price prorations are taken into account. The calculated
amount is updated. A measured demand is billed here. You can also bill a predefined
demand (in conditions, rate category, installation facts), or a demand calculated in a
previous schema step. The updated amount is used for a maximum price limitation.
10 - INFACT02 - Writing an amount to the installation facts
The calculated amount from the valuation of the demand rate is written to the installation
facts.

Reactive Energy Rate
11 - QUANTI13 - Calculating cosine phi from active energy and reactive energy
The cosine phi is calculated using the active energy and reactive energy. The value entered
in the first operand is interpreted as active energy (measured quantity of the on-peak rate
register), and the value entered in the second operand as reactive energy (measured
quantity of the reactive energy register). Each of the values entered is cumulated, that is, if
more than one register is involved, the consumption values are added first.
You must ensure that the calculation for the consumption values in question is based
exclusively on the operand name and the consumption values assigned using it. The
specifications made at the register level regarding the use of an active energy or reactive
energy register are not taken into account.
The cosine phi is calculated as follows:
CosPhi = 1 / SQRT((reactive*reactive) / (active*active) + 1)
For the following, cosine phi is calculated as:
Reactive = 0, active > 0 ==> CosPhi = 1
Reactive > 0, active = 0 ==> CosPhi = 0
Reactive = 0, active = 0 ==> CosPhi = 0
In this way, a cosine phi is calculated and updated for the entire period to be billed.

(C) SAP AG IUT230 15-31
12 - IF03 - Condition: IF factor1 >,>=,= factor2
This variant introduces an IF nesting level. All the following schema steps are only
executed if the condition is fulfilled. The condition is:
IF factor1 > (>=,=) factor2
whereby either the current or the highest values of the input operand are taken into
account. In this example, the factor1 > factor2 comparison and the analysis of the current
quantity 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.
15 - QUANTI01 - Valuating a quantity with a price
The calculated difference is valuated with a price.
16 - ENDIF – Ending an IF nesting
You use this variant to end an IF nesting level, that is, all the following variants are
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
18 - QUANTI01 - Valuating a quantity with a price
The total calculated is valuated with a defined maximum price and updated in an amount
operand.
19 and 20 - COMPUT02 - Adding two amounts (twice)
The on-peak rate amounts calculated in the period billings are added to the calculated off-
peak rate amounts. The result is then added to the calculated demand amounts.
21 - IF02 - Condition: IF amount1 >,>=,= amount2
This variant introduces an IF nesting level. All the following schema steps are only
executed if the condition is fulfilled. The condition is:
IF amount1 >= amount2
In this case, only the current input operand values are analyzed.
In this step, the total of the period billings (total of all the amounts for the rates in question)
is multiplied by the result of the valuation of the total quantity (on-peak consumption +
off-peak consumption), and compared with a defined maximum price.
22 - UTILIT01 - Deleting the billing line items
The billing line items for the amount received are deleted along with their info line items.
The billing line items can also be marked as info line items. In this way, they are not
relevant to posting or statistics, although they can be printed on the bill. The billing line
items to be deleted are identified using the deletion operand.
The schema step is only executed if the condition for variant IF02 is fulfilled. It is fulfilled
if the amount calculated using QUANTI01 in the period-end billing rate is greater than the
amount resulting from the total of the amount calculations for the rates (period billings).
23 - ELSE – Starting a NOT operation for an IF variant
If this is not the case, the NOT operation variants are executed.
24 - BACKBI01 – Triggering backbilling
This variant triggers backbilling. You can hide billing line items that are not required for
backbilling using the control function.
Backbilling is to be carried out or a credit memo issued for all the billing line items created
in previous billing periods.
The billing line items to be reversed are selected using the backbilling reversal indicator
(backbilling group).
This applies to schema steps 1 and 2 for the on-peak rate, and schema step 6 for the off-
peak rate.
25 - ENDIF – Ending an IF nesting
The nesting level opened in the schema step must be ended using this variant.

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

Field Name Value Note
Header Data:
Rate category # Name can be freely assigned.
Division #
General Data
Billing class # As required.
Outsorting price group billing # As required. The outsorting checks
during billing are entered (for example,
maximum net amount) here.
Billing Schema:
Billing schema # Here, you must enter all the rates for an
installation that are required for
calculation.
Backbilling:
No backbilling X
Number of periods 0
Period-End Billing
Separate period-end bill. X See below
PEB prio. X
Diff. in days 1
Number of periods 12




(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
3 E8_E COMPUT02 EAMOUNT_1 EAMOUNT_2 EAMOUNT_5
4 E8_E COMPUT02 EAMOUNT_5 EAMOUNT_3 EAMOUNT_6
5 E8_E IF02 EAMOUNT_4 EAMOUNT_6
6 E8_E UTILIT01 EAMOUNT_4
7 E8_E ELSE
8 E8_E BACKBI01
9 E8_E ENDIF

The rate steps for the period-end billing rate are actually only executed in period-end
billing.
Period-End Billing Schema Header Data
In the billing schema, exactly one rate can be added in the billing schema for which the
indicator 'Permissible as period-end billing rate' is set. This means that period-end billing
can be carried out with the schema. The key for this rate is displayed in the schema header.
The steps for this rate are added at the end of the schema.

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