SAP IUT230_BI

IUT230 Abrechnung und FakturierungIUT230 Release463 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 BusinessScenario 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 BillingintheIS-UDataModel 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 BillingMaster 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 Useof RatesinMaster 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 Billing 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 Steps 6-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. J oint Invoicing: Master Data 6-32 ff. J oint Invoicing: Example 1 6-33 gg. J oint 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 Billing 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 Bill 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 Billing 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. J oint 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 BillingFeatures 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 SalesStatistics 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 SalesStatistics: LIS(AppendixA) 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 AppendixB 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. Al l 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 l y A r e a O r ig in a l S u p p l y 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 exerci ses 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 rel evant 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. º I nterim 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 Anal ysis 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 Devi ce Zw Rat e t ype 12345678 001 1001 12345678 002 1002 Installation Facts EREFVAL=8kW Rate category E1 Schema: E1 Rate Facts EQPRI CE1= E1_1_1. . . Rate Determ. Rat e cat . Rat e t ype Rat e E1 1001 E1_1 E1 1002 E1_2 Schema E1 . . . Rat e Var i ant Oper ands E1_1 QUANTI 01 EQUANT1 EQPRI CE1 E1_1 REFVAL01 EREFVAL ETPRI CE1 . . . Rat e Var i ant Oper ands E1_2 QUANTI 01 EQUANT2 EQPRI CE2 . . . Þ 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 enabl es 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 recei vable 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 ¤ Vari ant 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 di vision, 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 franchi se 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 divi sion (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. Þ I nstallation 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 pri ce 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 Pri ce ¤ 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 ¤ Individuall y determined symbolic name or description for the allocated values that are used as input and output parameters in vari ant programs ¤ Variable that is assigned a value at runtime, for exampl e 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 Pri cing (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 individuall y •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 Acti vities 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 Bi lled 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 ¤ Al l values are considered ¤ Value at the end of the rate period ¤ Value on the key date ¤ Value at the end of the billing period ¤ Al l 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 Al l values are considered : Al l 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 bil ling period is valid The value at the end of the bil ling 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 J une 1 J uly 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 J une 1 J uly 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 J une 1 J uly 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 J une 1 J uly 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 i nterface 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 ¤ Permi ssibility of the rate ¤ Value rel evant to billing measured by a register (register operand) ¤ Register-rel ated data ¤ RTP rate and RTP interface ¤ Calculation formulae ¤ Al location 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 •Taxdet. •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 suppl y) Recei vables 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) Sal es 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 ¤ Al ternati ve procedure possible for the following special cases: Þ Move-in Þ Move-out Þ Values added/omitted sub-periodicall y ¤ 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 di vision ¤ 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 onl y ¤ 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 enabl es 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 J anuary 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 J anuary 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 J anuary 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 J anuary 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 rul es ¤ 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 Install ation ¤ 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 onl y carri ed 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 itemfield 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 itemfield 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 i c 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 i n 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 J anuary 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 J anuary 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 J anuary 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 J anuary 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. Þ I nterim 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, monthl y 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 Bill ing Bill ing 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 - Sal es 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 joi nt 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: Þ indirectl y through the meter-reading units that are defined for the utility installation belonging to the contract Þ directl y 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 Readi ng Billi ng Meter Readi ng Billi ng Þ 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 i s 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 Acti vities Acti vities ¤ 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 l ast 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 ¤ Sel ection of checks to be carri ed 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 Acti vities Acti vities 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 Bill ing 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 accordingl y ¤ 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 J anuary 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 J anuary 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 receivabl e 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 Invoi cing ¤ 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 Bill ing Bill ing Billing Document Billing Order Implausible Meter Reading Results Plausible Meter Reading Results Bill ing 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 bi lling 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 bi ll ing 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 Invoi cing ¤ Invoice Reversal Invoicing: 2 (C) SAP AG IUT230 6-17 © SAP AG 1999 Bill 4711 Date: 01/02/00 Valuatedconsumption +_________ +_________ +_________ 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 automaticall y included and posted (onl y 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 ........... .......... .......... .......... Bi ll 4711 Date: 01/02/00 Valuatedconsumption +_________ +_________ +_________ Credit memos/backbilling +/-________ Billing amount ========= Paidbudget billingamounts -__________ Mainitems +/-________ 1. Budget billingamount +_________ 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 . Al ternati ve 1 Alternati ve 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 anal ysis 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 Invoi cing ¤ 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 Valuatedconsumption +_________ +_________ +_________ 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 Invoi cing ¤ 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 Invoi cing ¤ 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 OtherServices #3 Cable TV 180 UNI OtherServices #2 Waste water 500UNI Waste disposal200UNI Cons. Billing #1 Electricity 1000 UNI Gas 1500 UNI Water 600UNI Þ 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 Invoi cing ¤ 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 invoi cing (SAP) ¤ Define outsorting groups for invoicing ¤ Define checks for each outsorting group for invoi cing ¤ 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 Invoi cing ¤ 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 Bill ing 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 W o r k flo w W S 205 0004 5 ISUB IMRCO R02 W o r k flo w W S 205 0004 5 ISUB IMRCO R02 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 W o r k flo w W S 205 001 05 ISU_ASSESS W o r k flo w W S 205 001 05 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 I nvoicing Exercises Unit: I nvoicing Topic: I nvoicing • 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: I nvoicing 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 I nvoicing: Solutions Unit: I nvoicing Topic: I nvoicing 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: I nvoicing 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 bil li ngs 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 immediatel y 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 manuall y or automaticall y. 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 Acti vated on May 1st, 1999 Advance Payment Acti vated on May 1st, 1999 New New New New Jan. - March Apri l - 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 Bil ling ¤ 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 Monthl y 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 (bal ance 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 Edi t Goto Addi ti onal System Hel p 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 Alternati ve Alternati ve 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 Billi ng 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 Valuatedconsumption +_________ +_________ +_________ Credit memos/backbilling +/-________ Billing amount ========= PayedBudget 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 automaticall y included and posted (onl y 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, onl y 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 Recei vable Invoici ng 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 Pl an 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 bill s. ¤ 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 Archi ving 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 valueadded 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 billi ng amounts are due on the foll owi ng dates: 1.2., 1.3., 1.4., 1.5., 1.6., 1.7., Please pay a budget billi ng 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 EMAI L PRI NTER 1 1 * * 3 3 No. Tr nsm. mt hdPr i nt out s RDI Ar ch. 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 Medi um One thousand two hundred Walldor f, 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.(Ci ty Tax) 12.56 UNI Subtot.(Country Tax) 15.66 UNI 0002 000001 4712 12.45 UNI 0002 000002 4712 33.78 UNI Subtot.(Ci ty 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 Archi ving 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 Fl yer Adds Fl yer 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 Archi ving 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 archi ving 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 calcul ated 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 J anuary 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 exampl es 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). Þ I nstallation 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). Þ I nvoicing 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 ¤ J oint Invoicing ¤ CopyProrations 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 Þ I nitial 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 deregul ated contracts with the liberalization of new markets ¤ Explain how reference values and street lighting are billed ¤ Perform archi ving 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 deregul ated 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 ¤ Franchi se 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 di vision) 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 ¤ Franchi se 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 •Accordi ng to Standard Cubic Meters Gas Billing Type •Thermal •Volumetric •Accordi ng 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, defi ned VCF, VCF procedure Calorific val ue district, monthly/annual calorific val ues, cogenerators, billi ng calorific val ues, calorific val ue 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 ¤ Franchi se 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 Vari ant Programs ¤ Group Management ¤ Indi vidual 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 calcul ate 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 suppl y (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 onl y 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 ¤ Franchi se 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 Addi tional Addi tional 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 . . . . . . . . . . Usuall y joint Usuall y 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 To tal Saales Tax Subt otal SALESPERSON DATE Tot al Pr ice Descr iptio n Qty Ship ped Qty Or der ed INVOICE #: P.O. #: Customer Premise Bill Bill En e r g y En e r g y Co n t r a c t Co n t r a c t between between XXXXXXXXX XXXXXXXXX and and EVU EVU Ltd Ltd nnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnn mmmmmmmmmmmmmmmmmmm mmmmmmmmmmmmmmmmmmm kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk uuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuu zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz En e r g y Su p p ly En e r g y Su p p ly Co n t r a c t Co n t r a c t between between XXXXXXXXX XXXXXXXXX and and EVU EVU Ltd Ltd nnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnn mmmmmmmmmmmmmmmmmmm mmmmmmmmmmmmmmmmmmm kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk uuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuu zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz En e r g y s u p p ly En e r g y s u p p ly c o n t r a c t c o n t r a c t between between XXXXXXXXX XXXXXXXXX and and EVU EVU Ltd Ltd nnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnn mmmmmmmmmmmmmmmmmmm mmmmmmmmmmmmmmmmmmm kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk uuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuu zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz En e r g y En e r g y s u p p ly s u p p ly c o n t r a c t c o n tr a c t between between < Customer > < Customer > and and < utility company> < utili ty 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 To tal Saales Tax Subt otal SALESPERSON DATE Tot al Pr ice Descr iptio n Qty Ship ped Qty Or der ed INVOICE #: 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" To tal Saales Tax Subt otal SALESPERSON DATE Tot al Pr ice Descr iptio n Qty Ship ped 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 Di vision Several Di visions Single UC Several UCs Standard Billing Standard Billing Multi- Sector Billing Multi- Sector Billing Unbundled Billing Unbundled Billing Convergent Billing Convergent Billing UC: Utili ty 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 Di vision Several Di visions Single UC Several UCs Standard Billing Multi- Sector Billing Unbundled Billing Unbundled Billing Convergent Convergent Billing Billing UC: Utili ty 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 Suppl ier Suppl ier 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 billi ng-related install ation (C) SAP AG IUT230 11-37 © SAP AG 1999 Advantages of Separation Separation of Devi ce 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 ¤ Franchi se 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 " Archi ving Object" R/3 Database Archi ve 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 Archi ve File Archi ve File Archi ve File Archi ve File Step 2: Create Archive Fil e (*) • 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 Archi ve File 1 Archi ve File 1 Step 3: Execute Delete Program (1) Delete Program Delete Program R/3 Database R/3 Database Archive File 2 Archive File 2 Archi ve File 1 Archi ve 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 ¤ Archi ving 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 (Archi ve Development Kit) ¤ Archi ving 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 ¤ Anal ysis of the archi ved 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) Archi ved Tables: ¤ EABP Budget Billing Plan Header ¤ EJ VL 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 Utili ties 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 Archi ving 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 Archi ved 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 Archi ving 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 ¤ Archi ving 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 Periodi c meter-reading every 6 months En Monthly billing/invoicing on estimated consumption In Interim meter-reading with optional billing E4 Monthly billing/invoicing MR2 Periodi c 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 > |------|------|------|------|------|------| Þ Al l estimated periods and current period |----------------------------------------| Þ Al l estimated periods in one time slice |---------------------------------| Þ Al l 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 | Al l 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 ,0 0 1 0 0 0 ,0 0 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 vi ew 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 vi ew 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 i ndi vidual contract and (individual) installati on. 1:1 relationship between outline agreement and (outline) installati on. ¤ One-level outline agreements ¤ Mul ti-level outli ne 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 ... Outli ne Agreement 1 Outli ne 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 Outli ne Agreement 3 Outli ne Agreement 3 Outli ne Agreement 2 Outli ne Agreement 2 Outli ne 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 displ ayed ¤ This enables you to view the allocations outside transaction EAOUTL (C) SAP AG IUT230 11-83 © SAP AG 1999 Procedure 1 ¤ Create structures ¤ Anal yze 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 ¤ Al l 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 indi vidual 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 ¤ Sal es 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 Anal ysis Tools Online Anal ytical 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 Requisiti on In vo ice P ro jects 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 I nformation 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 Anal yses Anal yses 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 Bill ing Quantity Net Amount Billing Amount Rate Categories A B C Correlation ABC Anal ysis Cumulative Frequency Curve No. of Rate Categories Bill ing 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. Þ I nfoSource 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. Þ I nfoObjects 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. Þ I nfoCubes 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 Ti me-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 avail able × 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 ¤ Al l 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 initi alization process º Initialisation possible in the updating system? Þ Extraction of all data according to the selection Þ Other initializations are onl y 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 onl y possible if the initial request was successful ¤ Repetition of the previous Delta request Þ Necessary if the last Delta request was not carried out properl y (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. Onl y 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 Þ Al l 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 ¤ Sal es 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 directl y 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 ¤ Sal es Statistics Þ Data Warehouse Concepts Þ Logistics Information System (LIS) Þ Utility Information System (UIS) Þ Information Flow Þ Tools Þ Standard Anal yses Þ Flexible Anal yses ¤ 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 anal yses ¤ 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 Earl y Warning System Earl y Warning System Flexible Analysis Flexible Analysis Standard Anal ysis Standard Anal ysis Advanced Anal ysis Techniques Advanced Anal ysis 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 Anal ysis Tools Online Anal ytical 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 Requisiti on In vo ice P ro jects 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 Anal yses Þ Flexible Anal yses ¤ CO-PA Þ Planning/Unbilled Revenue Reporting (C) SAP AG IUT230 13-11 © SAP AG 1999 Anal yses Anal yses 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 Fiel ds 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 Anal ysis 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 Anal ysis Anal ysis 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 Anal yses Þ Flexible Anal yses ¤ 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 Anal ysis Update Anal ysis Update Log Update Log Update Anal ysis Update Anal ysis 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 Anal yses ¤ 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. Energyamt 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 Bill ing Quantity Net Amount Billing Amount Rate Categories A B C Correlation ABC Anal ysis Cumulative Frequency Curve No. of Rate Categories Bill ing 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 Earl y 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-Dri ven Review of data (for example, weekly) Event-Driven Review of changed data (for example, daily) Interactive Periodi c Anal yses 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 Val ue Threshold Val ue 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 Anal yses ¤ 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 Anal yses Þ Flexible Anal yses ¤ 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 Anal ysis Anal ysis 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 Anal ysis 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 Acti ve Operating Concern Acti ve Change Contract Contract Edi t Goto Addi ti onal System Hel p Contract TF0415A001 Account Assignment Data Profitabili ty 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 Statisticall y 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 anal yses (rate and industry statistics) are provided with the system as examples. ¤ It is also possible to carry out flexible anal yses. ¤ You must use flexible anal yses 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 J anuary 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 J anuary 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 I np. Op.1 I np. 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 I NFACT01. 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 BACKBI 01. 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 BACKBI 03. Example: The backbilling period starts on J anuary 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): J anuary 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: J anuary February March April |----------------------|----------------------|----------------------|----------------------| 40 kW (April) 30 kW (J anuary) 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 I NFACT01. 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 J anuary 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 J anuary 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). J anuary February March April May |-------------------|-------------------|-------------------|-------------------|-------------------| Current billing 30 kW (C) SAP AG IUT230 15-7 In the next step, you use variant I F00 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 BACKBI 02. J anuary February March April May |-------------------|-------------------|-------------------|-------------------|-------------------| <-----30 kW---- > Adjustment periods: <-----30 kW---- > <-----30 kW---- > <-----30 kW---- > When backbilling is triggered using BACKBI 01, 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. J anuary 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: J anuary February March April May |-------------------|-------------------|-------------------|-------------------|-------------------| <----30 kW---- > Adjustment periods: <-----30 kW---- > <-----30 kW---- > <-----30 kW---- > Backbilling is triggered using BACKBI 01. 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 I ndicators 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 - I NFACT01 - 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 - BACKBI 01 – 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 - BACKBI 03 – 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 - I NFACT01 – 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 - I F00 - Condition: I F 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 I F 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 - BACKBI 02 – 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 - BACKBI 01 – 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 - ENDI F – Ending an I F 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 – I NFACT01 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 – BACKBI 01 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 – I NFACT01 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 – I F00 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 – BACKBI 01 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. I ndicator: 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 I np. Op.1 I np. 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 (QUANTI 01), 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 (I NFACT06 for the quantities and I NFACT02 for the amounts) to the facts for the current installation. With variant QUANTI 14, 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 QUANTI 01. 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 QUANTI 13 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 I F03 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 QUANTI 09. The result is deducted from the measured reactive energy using variant QUANTI 02. With QUANTI 01, this quantity is now valuated with a price. The rate nesting is ended using ENDI F. 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 QUANTI 10, 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 QUANTI 01. 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 I F02 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 UTI LI T01. If the comparison yields a negative result, variant BACKBI 01 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 - QUANTI 01 - 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 - I NFACT06 - 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 - I NFACT02 - 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 - QUANTI 14 - 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 - QUANTI 01 - Valuating a quantity with a price An off-peak rate quantity is valuated with a price. 7 - I NFACT06 - Writing a quantity to the installation facts This quantity is also written to the installation facts. 8 - I NFACT02 - 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 - I NFACT02 - 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 - QUANTI 13 - 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 - I F03 - Condition: I F 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 - QUANTI 09 - 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 - QUANTI 02 - 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 - QUANTI 01 - Valuating a quantity with a price The calculated difference is valuated with a price. 16 - ENDI F – Ending an I F 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 - QUANTI 02 - 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 - QUANTI 01 - 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 - I F02 - Condition: I F 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 - UTI LI T01 - 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 I F variant If this is not the case, the NOT operation variants are executed. 24 - BACKBI 01 – 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 - ENDI F – Ending an I F 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 I ndicator 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 J anuary 3, 2000. This means that the earliest date on which period-end billing can take place is J anuary 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 I np. Op.1 I np. 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.