IUT 230 billing and invoicing
-
Upload
sudeepksap -
Category
Documents
-
view
1.717 -
download
150
description
Transcript of IUT 230 billing and invoicing
© SAP AG 2009
IUT230 Billing and InvoicingFS310 Collections/Disbursements
THE BEST-RUN BUSINESSES RUN SAP
© SAP AG 2008
IUT230Billing and Invoicing
ERP2005 SAP for Utilities ECC 6.0
Version 92
Material number 50096723
© SAP AG 2009
Copyright 2009 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Copyright
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web
Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and
implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
© SAP AG 2006
Prerequisites
Basic knowledge of the Windows operating system environment
Basic SAP knowledge
Course IUT110: Introduction to the IS-U/CCS System
Course IUT210: Master Data and Basic Functions
© SAP AG 2008
Target Group
Participants:A project team implementing business processes with SAP Utilities
Administrators optimizing processes in the SAP Utilities environment
Consultants preparing for SAP Utilities implementation
Duration: 5 days
© SAP AG 2008
Course Objectives
This course will enable you to:
Describe the process that starts with billing and invoicing and finishes with bill printout
Obtain knowledge about all billing related master data and functions in SAP Utilities
Obtain knowledge about displaying billing rules and prices in SAP Utilities
© SAP AG 2008
Objectives
After completing this course, you will be able to:
Describe the billing master data of SAP Utilities
Perform billing and invoicing
Create the most important billing master data in the system
Make Customizing settings for billing and invoicing master data
© SAP AG 2007
© SAP AG 2008
Course Content IUT230
Unit 7 Invoicing
Unit 8 Clearing Control
Unit 9 Budget Billing Amounts
Unit 10 Bill Printout
Unit 11 Special Billing Features
Unit 1 Business Scenario
Unit 2 Billing in SAP Utilities Data Model
Unit 3 Billing Master Data
Unit 4 Discounts/Surcharges
Unit 5 Billing
Unit 6 Manual Billing
Preface
Appendices
© SAP AG IUT230 1-1
SAP AG 2006
Business Scenario
Introduction to the business scenario and the relevant components
© SAP AG IUT230 1-2
SAP AG 2008
Business Scenario: Unit Objectives
In this unit, you will learn about:
The business process used to explain billing master data and billing and invoicing with SAP Utilities
The steps required for processing the business scenario
SAP AG 2007
The main part of this course deals with mapping new billing and invoicing principles in SAP Utilities based on changed conditions. These changes can be the introduction of new divisions, the expansion of a supply area, or a change to legal conditions for example.
This provides the basis for creating billing runs and bill documents based on new billing principles and/or rate models.
© SAP AG IUT230 1-3
SAP AG 2006
Energy and Service Company
IDES Utilities Inc.
Telecommuni-cations
Telecommuni-cations
MultimediaMultimediaElectricityElectricity
GasGas
WaterWater Waste waterWaste water WasteWaste
District heatingDistrict heating
IDES Utilities Inc. is a municipal utility company that deals with the classical divisions of district heating, electricity, gas, water, and waste water. New business areas are also being developed to create additional divisions such as waste, telecommunications, and multimedia.
© SAP AG IUT230 1-4
SAP AG 2008
Potential
supply areaPotential
supply area
Deregulated Utilities Industry
Originalsupply area
Originalsupply area
As well as creating new business areas in the deregulation process, the company is aiming to acquire new customers.
To achieve this goal, the company offers attractive rates to customers situated outside the current supply area.
© SAP AG IUT230 1-5
SAP AG 2006
Rate Structure
In the deregulated market, new and
more attractive rate models are
required. Sales personnel must
map and test the rate models developed
by the marketing department in the
system.Rate calculation:
1 kWh elec. =Basic price =Rental price =
USD 0.12USD 50.00USD 25.00
----------- IDES Utilities Inc. -------------
The sales employees are constantly confronted with new challenges. On the one hand, they have to make customers attractive offers, and on the other hand they must stay within the company's cost frame.
© SAP AG IUT230 1-6
SAP AG 2006
Contract (Residential Customer - Electricity)
Customer without measured demand for annual consumption of less than 10,000 kWh/yahr
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average price limitationEnergy prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental prices
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Flat-rate demand 100 USD/year
This is a typical contract for residential customers in the electricity division.
© SAP AG IUT230 1-7
SAP AG 2006
Maintainbilling
master data
Use of ratesin the
master dataInvoicing Bill
printoutBilling
Budget Billing
Additional functions:Additional functions:Discounts/surchargesDiscounts/surchargesManual billingManual billingSales statisticsSales statisticsSpecial billing featuresSpecial billing features
Billing/Invoicing: Business Scenario
The following is involved in the billing and invoicing processes:
Modeling new rates by creating new billing master data
Using new rates in customer and installation master data
Billing simulation
Invoicing simulation
Releasing the rates to the user department, which then makes them available to the company's customers
Other billing functions are available, which are used in the billing and invoicing processes.
All these functions are required to complete the business scenario. The relevant part of the business scenario is discussed at the beginning of the respective unit.
© SAP AG IUT230 1-8
SAP AG 2006
Business Scenario: Unit Summary
The business scenario contains all the work steps required for the initial creation of billing master data
The business scenario is the basis for the practical exercises that you will be doing during the course
SAP AG
© SAP AG IUT230 2-1
SAP AG 2008
Billing in SAP Utilities Data Model
SAP AG 2007
This unit will prepare you to:
Explain the bill creation process - from meter reading to bill printout
Describe the integration of billing master data in the SAP Utilities data model
Structure the component hierarchy for billing and invoicing
Outline the billing functions and the billing master data
© SAP AG IUT230 2-2
SAP AG 2008
Objectives
SAP AG 2007
At the conclusion of this unit, you will be able to:
Identify billing tasks in SAP Utilities
Identify the master data relevant to billing
© SAP AG IUT230 2-3
SAP AG 2006
Budget Billing
Maintain billingmaster data
Use of ratesin the
master dataInvoicing Bill
printoutBilling
Additional functions:Additional functions:Discounts/surchargesDiscounts/surchargesManual billingManual billingSales statisticsSales statisticsSpecial billing featuresSpecial billing features
Billing/Invoicing: Business Scenario II
The scenario in this unit will give you an initial overview of the billing functions and billing master data.
© SAP AG IUT230 2-4
SAP AG 2006
MRorder
Billingorder
InvoicingInvoicingMeter readingorder creationMeter readingorder creation
Meter readingdata entry
Meter readingdata entry
BillingBilling
Billingdocument
Implausible MR results
Plausible MR results
Billingorder
Print document
Billprintout
Billprintout
The Bill Creation Process
Correction ofMR results
© SAP AG IUT230 2-5
SAP AG 2008
Electricity
Gas
Water/Waste water
District heating
Cable televisionMultimediaCharges,
duties
Divisions
Residential customers
Commercial & industrial customers
Co-generator
Business partner
Billing rules, variantsBilling rules, variants
ConsumptionDemandFlat rates
Discounts,surcharges
Generalduties
Prorations Franchisefees
Priceadjustment
. . . . . .
Waste
SAP Utilities: Billing I
SAP Utilities can bill commercial and industrial customers, residential customers, and co-generators in the same data structures with the same functions. Differentiation only occurs in the data. The customers are managed as business partners in the system.
You can bill the following divisions using SAP Utilities: electricity, gas, water, waste water, district heating and waste disposal. Flat-rate charges for other divisions such as cable television and multimedia can also be included. In addition, all types of charges and duties can be included.
Examples of charges and duties are:
Cable television
Local charges
Dog license fee
© SAP AG IUT230 2-6
SAP AG 2006
Billing (Utility Services)
Based on a universal billing engine
Billing of residential and commercial & industrialcustomer contracts
Supports the billing procedures of the international utilities industry, for example: periodic billing, interim billing, period-end billing, floating backbilling, final billing, budget billing, average monthly billing
Can handle new billing procedures
Convergent billing and intercompany invoicing
Thermal gas billing, billing of co-generators and flat-rate installations
The following billing procedures are supported:
Periodic billing is consumption billing carried out on a regular basis.
Floating backbilling is a form of monthly periodic billing. If necessary, values from previous months in a billing year are recalculated and backbilled using a current value.
Period-end billing is carried out separately after a billing cycle. Periodic billings can, if necessary, be recalculated and backbilled.
Interim billing is not controlled by scheduling functions and can be carried out manually at any time (upon customer request, for example).
Final billing is triggered when a customer moves out.
In the budget billing plan, an average amount is determined either by simulation or manually. The customer pays this average amount for a period of 12 months. At the end of this period, a new simulation is run for the next period.
In Average Monthly Billing/Equalized Billing, the customer is charged an average amount based on billings over the next 12 months (or less in the case of new customers).
© SAP AG IUT230 2-7
SAP AG 2006
Business Objects/Utility Services
DevicecategoryDevice
category
Connectionobject
Connectionobject
ConnectionConnectionDevicelocationDevice
location
PremisePremise
RegionalstructureRegionalstructure
PoDPoD
ContractaccountContractaccount
InstallationInstallation
DeviceDevice
RegisterRegister
Contract(supply)Contract(supply)
Businesspartner
Businesspartner
Installation structure
In billing the most important business objects are the installation (contains the rate category) and the device, in particular the installation structure (contains the rate type for each register). Additionally, some fields in the following business objects are used in billing: installation, device, installation structure, contract and contract account. These will be described later on during the course.
In invoicing the most important business object is the contract account.
© SAP AG IUT230 2-8
SAP AG 2008
Link Between Contract Text and SAP Utilities
Customer without measured demand for annual consumption of less than 10,000 kWh/year
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental Price
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Service Flat Rate 100 USD/year
Rate cat.e.g. residential
The rate category classifies the installation for billing.
The following are some examples of rate categories:
Household rate
Commercial rate
Commercial rate with demand measurement
Industrial rate
Minimal consumption rate
Basic price rate 1
Basic price rate 2
Domestic water
Reserve water
Water for fire fighting
© SAP AG IUT230 2-9
SAP AG 2008
Rate Type
Rate Type
Link Between Contract Text and SAP Utilities II
Customer without measured demand for annual consumption of less than 10,000 kWh/year
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental Price
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Service Flat Rate 100 USD/year
Rate cat.e.g. residential
The rate type classifies the register for billing. The following are some examples of rate types:
On-peak rate active energy
Off-peak rate active energy
On-peak rate reactive energy
On-peak rate active power
Gas consumption
Water consumption
The rate types are usually known at the beginning of the project and only need to be maintained once.
© SAP AG IUT230 2-10
SAP AG 2008
Rate Type
Rate Type
Link Between Contract Text and SAP Utilities III
Customer without measured demand for annual consumption of less than 10,000 kWh/year
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental Price
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Service Flat Rate 100 USD/year
Rate cat.e.g. residential
Rate
Rate
In this example, two rates are determined (on-peak household rate and off-peak household rate) with both rate types (on-peak rate and off-peak rate) in connection with the rate category (household customers without measured demand).
In this case, the energy price for the single-rate meter is identical to that of the on-peak rate meter, so the same rate can be used for both single and on-peak rates; in other words, you can use just one rate type for both single and on-peak rate. If the prices were different, then an additional rate type (single rate) and an additional rate (single household rate) would be necessary.
The rate bills the consumption from the register. It is determined in a Customizing table using the combination of rate category and rate type.
© SAP AG IUT230 2-11
SAP AG 2008
Link Between Contract Text and SAP Utilities IV
Rate Type
Rate Type
Customer without measured demand for annual consumption of less than 10,000 kWh/year
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental Price
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Service Flat Rate 100 USD/year
Rate
Variant programs
Rate cat.e.g. residential
Rate
Variant programs are contained in rates as rate steps. Variant programs are basic calculation steps (e.g. consumption x price, determination of the basic price, or determination of the rental price). In this case, the demand price (basic price flat rate) and the rental price are included in the on-peak rate as variant programs.
© SAP AG IUT230 2-12
SAP AG 2008
Link Between Contract Text and SAP Utilities V
Rate Type
Rate Type
Customer without measured demand for annual consumption of less than 10,000 kWh/year
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental Price
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Service Flat Rate 100 USD/year
Rate
Variant programs
Rate cat.e.g. residential
Rate
Prices
Facts
The prices in the system must be entered as price keys. Each application requires that different price categories are entered (e.g. quantity-based price, time-based price).
© SAP AG IUT230 2-13
SAP AG 2008
Link Between Contract Text and SAP Utilities VI
Rate Type
Rate Type
Customer without measured demand for annual consumption of less than 10,000 kWh/year
1. Consumption prices
a) Without off-peak regulation
b) With off-peak regulation- On-peak rate- Off-peak rate
2. Average Price LimitationEnergy Prices- Maximum price (on-peak rate)- Off-peak rate
4. Rental Price
- Single-rate meter- Double-rate meter
0.24 USD/kWh
0.24 USD/kWh0.11 USD/kWh
0.48 USD/kWh0.11 USD/kWh
50 USD/year70 USD/year
3. Service Flat Rate 100 USD/year
Rate
Variant programs
Rate cat.e.g. residential
Rate
Prices
Facts
Schema
All rates that can be billed together in the same contract/installation (for example, on-peak rate for household customers, off-peak rate for household customers) must be brought together in one billing schema.
The schema contains the billing logic and the processing order of the rates and rate steps (variant programs). A schema can contain one or more rates.
© SAP AG IUT230 2-14
SAP AG 2006
Generationof bill
line items
Validatonof billingresults
Executionof variantprograms
by schema
Quantityconversion
andproration
Data entryand
analysis
Universal Billing Engine
+
Ratedet.Ratedet.
Customer and inst.-related data
Rate data
Rate cat.
Prices andrate facts
Prices andrate facts
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Inst. structure/Rate category/
Inst. facts
Inst. structure/Rate category/
Inst. facts
Rate 1Rate 1
Rate nRate nRate cat.
The "billing engine" is at the core of billing.
The billing process follows a fixed procedure.
Data collection and analysis All data that is needed for billing is collected and prepared for analysis.
Proration If duties, prices, or taxes have changed during a billing period, the values relevant to billing (for example, consumption) must be prorated according to the date of the change.
Quantity conversion The quantities to be billed are determined from the meter reading results. Meter factors, PT/CT ratios, and conversions due to thermal gas billing are taken into account, for example.
Quantity valuation Quantity valuation is the actual contract billing: rates and their variant programs are processed on the basis of the billing schema.
Validation of billing results The billing results are validated after valuation.
Generation of billing line items
© SAP AG IUT230 2-15
SAP AG 2008
Invoicing
SAP AG 2007
Invoicing in SAP Utilities
Invoicing Functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 2-16
SAP AG 2008
Billing in SAP Utilities Data Model: Summary
SAP AG
Billing is the central component of SAP Utilities for calculating energy and water supplied to customers
The central billing engine enables you to model all possible combinations of billing steps
Dynamic rate determination allows for quick adjustment of entire customer groups to new rates
Invoicing is the standard SAP Utilities process that establishes the link to contract accounts receivable and payable and provides the basis for bill creation
© SAP AG IUT230 3-1
SAP AG 2006
Billing Master Data
SAP AG 2006
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-2
SAP AG 2008
Billing Master Data: Unit Objectives
SAP AG 2006
At the conclusion of this unit, you will be able to:
Identify billing master data in SAP Utilities
Describe the dependencies between the individual objects
Maintain the billing master data in the correct order
© SAP AG IUT230 3-3
SAP AG 2006
Billing Modules: 1
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-4
SAP AG 2006
Data Model for Billing – Billing Class
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecategory
Ratecategory
RatetypeRatetype
Prices Prices
SchemaFact groupFact groupFact groupFact groupFact groupFact group
RatetypeRatetype
Installationfacts
Installationfacts
Rate categoryfacts
Rate categoryfacts
© SAP AG IUT230 3-5
SAP AG 2006
Billing Class: 1
Classifies installations within a division, for example residential/C&I contract
Can be valid for multiple rate categories
Used for validation in scheduling and in the billing master data
Enables several franchise fee groups to be defined
Can be used as a statistical criterion
If you change the billing class, you must also change the rate category. You do not have to perform a final billing
The billing class classifies installations for billing.
The billing class is also used for the following purposes:
For consistency verifications between the master data and billing master data. For example, you can verify that a residential customer's installation has not been allocated to a nonresidential contract.
As a statistical criterion, for example in the sales statistics.
© SAP AG IUT230 3-6
SAP AG 2006
InstallationInstallation
RateRate
PortionPortion
Billing class
(Classification,Validation)
Billing class
(Classification,Validation) MR unitMR unit
Ratecategory
Ratecategory
Rate typeRate type
Billing Class: 2
PricePrice
SchemaSchemaDiscountDiscount
The billing class is used in the following objects:
Installation
Rate category
Rate type
Price
Rate
Schema
Portion
MR unit
You can allocate the different billing master data to different billing classes. This means that each time the billing class is used, a mutual check is carried out for permissibility and consistency. The check is performed in connection with the division.
The billing class is optional in the meter reading unit, portion, and rate type.
© SAP AG IUT230 3-7
SAP AG 2006
Billing Modules: 2
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-8
SAP AG 2006
Data Model for Billing: Rate Types
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecateogry
Ratecateogry
TarifartTarifart
Prices Prices
SchemaFact groupsFact groupsFact groupsFact groupsFact groupsFact groups
RatetypesRatetypes
Installationfacts
Installationfacts
Rate categoryfacts
Rate categoryfacts
© SAP AG IUT230 3-9
SAP AG 2006
Used to classifyRegisters
Devices
Flat-rates
Reference values
for billing
Examples: On-peak and off-peak rates for active energy; On-peak rate for reactive energy; On-peak rate for active power; gas and water consumption; flat-rate installations
The rate type is used in conjunction with the rate category to determine the rate
Definition of Rate Type
Generally, you enter the rate type in the register. Examples of rate categories are peak and off-peak rates for active energy, peak rates for reactive energy, peak rates for active power, as well as gas and water consumption.
You can also allocate the rate type to the following objects:
Device
- For devices without registers (such as ripple control receivers) you can use the rate type to find special rates. Using these, you can calculate a device-based clearing price.
Facts
- Used to determine rates that cannot be derived from registers.
- Also used to determines rates for flat rate installations without installed devices.
Reference Values
- Used to model street lights, for example
© SAP AG IUT230 3-10
SAP AG 2006
Rate Type: 1
Is valid for a particular division (obligatory) and billing class (optional)Use of the rate type can be permitted for:
RegistersMust be specified for registers relevant to billing
DevicesFor example: Rental price for devices that have no registers relevant to billing
FactsFor example: Flat-rates or installation flat-rates
Interval metersFor example: For billing real-time pricing rates
Period-end billingFor example: For determining a special fact group in the period-end billing
Waste billingFor example: For determining a special rate for waste management
You can maintain rate types in the following objects:
Register In the case of registers relevant to billing, you must specify a rate type in the installation structure. In this way, you specify that the consumption or the demand of a register is billed using the corresponding rate. Quantity determination during extrapolation (zero consumption despite contract allocation) can be influenced by an additional indicator for rate types that are permitted for registers.
Device You can specify a rate type for a device if, for example, you wish to levy a rental price at device level. This is particularly relevant if the device does not contain any registers relevant to billing.
Rate category You can specify rate types in the rate category to perform billing of values not related to registers. For example: By means of the rate type, a rate is determined that is used to bill a flat rate.
Installation If, for example, you wish to levy a flat rate for a certain installation only, you enter the rate type in the installation facts, but not in the rate category.
© SAP AG IUT230 3-11
SAP AG 2008
Rate type
Rate category
Register
Device
Installation
Rate Type: 2
On-peak rate active energyOff-peak rate active energyOn-peak rate reactive energyOff-peak rate reactive energyGas consumptionWater consumptionInterval meter
Rental price(device-related)
Flat-rate installationsAdditional ratesFlat-rate
installationsReference valuesFacts for period-end billing
Rate types are generally maintained in the register. In some cases, it can be maintained at device level or in the installation facts. The rate type can also be entered in the rate category.
© SAP AG IUT230 3-12
SAP AG 2006
Billing Modules: 3
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-13
SAP AG 2006
Data Model for Billing - Prices
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecategory
Ratecategory
RatetypeRatetype
Preise Preise
SchemaFact groupFact groupFact groupFact groupFact groupFact group
PricesPrices
Installationfacts
Installationfacts
Rate categoryfacts
Rate categoryfacts
RatetypeRatetype
© SAP AG IUT230 3-14
SAP AG 2006
Prices for Billing
Central price management
Price key
Header data- EUR- Dollar
History EUR01.01.2000 – 31.12.2005 10 €01.01.2006 – 31.12.9999 15 €
History USD01.01.2000 – 31.12.2005 19 $01.01.2006 – 31.12.9999 25 $
The price key is the name of a price; the price key is also called "price". Control data such as division, billing class, time basis, and rounding are also stored in the header data of prices.
The actual values are stored in the prices. Prorated price amounts are also managed in the prices. If the price changes, the new time slice is entered here. In this case, the header data does not change.
The price key also contains a currency key. This means that if you use different currencies for billing, you must maintain all prices in the different currencies.
You establish the currency that is valid for a particular customer in the Trans. currency field in the contract account.
© SAP AG IUT230 3-15
SAP AG 2006
Price Categories
Quantity-based price for quantities and consumption values
Flat-ratefixed amounts per time unit (consumptionflat-rates and flat-rate amounts)
Rental pricefor the use of a measuring device over a certain period of time
Time-based pricefor demand and connection values
The price categories are predefined by SAP and cannot be changed.
The price categories are used internally to control data processing. Normally, you create the prices based on the rate. In this case, the correct rate is proposed by the system.
The price category is a characteristic in the header data.
© SAP AG IUT230 3-16
SAP AG 2006
Standard price:Price not based on quantity
Zone price:One or more quantity-based prices
Scale price:Quantity-based price
Price Types
The price type specifies how the particular price is to be used.
In addition to standard single prices, you can also use scale and block prices.
Certain sequential quantity ranges (for demand and/or energy) are defined by price scaling. If one quantity range is exceeded, the price for the next quantity range applies for the entire quantity. In this way, higher consumption can be cheaper than lower consumption.
Certain sequential quantity areas (for demand and/or energy) are defined by price blocking for which certain prices apply, in other words different prices are used. This prevents higher consumption from being cheaper than lower consumption.
The price type is a characteristic in the header data.
Block and scale limits are maintained in the historical data.
© SAP AG IUT230 3-17
SAP AG 2006
Definition of Block Price and Scale Price
Z1 Z2 Z3 Z4 Z...
Block and scale prices
P1
P2
P3
P4
P5
Price type:- Block price- Scale price
Quantity limit- Inclusive up to block- Exclusive as of block
CustomizingCustomizing
Adjustment of quantity to billing periodin block price
0 500 700 1000
Zone definition
0 to 500500 to 700700 to 10001000 to 9999
Quantity
Price
Block and scale prices are defined centrally in price management. For both prices, you must define quantity limits. The price type specifies whether the price is a block or scale price.
© SAP AG IUT230 3-18
SAP AG 2006
Block price
P4
P3
P2
P1
Quantity to be billed 1200
Scale price
P4
P3
P2
P1
Quantity to be billed 1200
Price det. forscale price:
0 - 500 500 for P1500 - 700 200 for P2700 - 1000 300 for P31000 - 1200 200 for P4
Price det. forblock price:
Block and Scale Price
0 500 700 1000 0 500 700 1000
0 - 1200 1200 for P4
Quantity Quantity
PricePrice
According to the price type, the system determines different prices during billing.
For block prices, the quantity is valuated with different prices depending on the interval.
For scale prices, all quantity intervals are valuated with the price that the system determines for the total quantity to be billed.
The following is generated in the billing document:- Four billing document line items for price type Block Price- One billing document line items for price type Scale Price
© SAP AG IUT230 3-19
SAP AG 2006
Adjusting Price Blocks for Billing Periods
Time basis: 365 daysPrice block adjustment activatedInterval lower limit: 350 daysInterval upper limit: 375 days
Quantity-based price
Price blocks0 - 3000
3000 - 50005000 - 10000
10000 - 9999999999
Price blocks0 - 3000
3000 - 50005000 - 10000
10000 - 9999999999
Adjustment of blocks to thebilling period, e.g. 340 days
Price blocks0 - 2795
2795 - 46584658 - 9315
9315 - 9999999999
Price blocks0 - 2795
2795 - 46584658 - 9315
9315 - 9999999999
You can adjust the blocks/scales for quantity-based prices if the billing period differs from the basic time specified in the price key.
If you want the blocks/scales to be adjusted, you have to set the Adj.PBlcks indicator (adjust price blocks). If the adjustment is to be dependent on an interval, you must also set the interval lower and upper limits.
The block adjustment indicator is part of the header data.
A block adjustment of the amounts only takes place for block prices - not for scale prices.
© SAP AG IUT230 3-20
SAP AG 2006
Header Data for Price Key
Billing class
Division
Rounding parameters
Price adjustment clause
External price
Average price
Gross price
Block adjustment indicator
Overall, the price key is defined more precisely using the following three elements:
Price key
Price category
Price level
The price level is only used for rental prices.
Price adjustment clauses can be defined for all prices.
Defining authorization restricts the use of individual prices.
Rounding parameters are only needed in the following situations: price discount or using the price adjustment clause.
When using gross prices, you must create all the components of the gross price, such as ecological tax, franchise fee, and net price as separate prices. In the schema, you specify which prices are processed jointly in the Gross group field.
Several price contributions in different transaction currencies can be entered for one price key. The relevant transaction currency for billing is entered in the business partner's contract account.
You can historically define prices for a price key for each transaction currency.
© SAP AG IUT230 3-21
SAP AG 2006
Price Adjustment Clause
Company Bill
Company Bill x y z
Basic price2.00
Priceadjustment
clause1.50
Addition
+Multiplication
*
Final price for the customer
Final price3.50
Final price3.00
The price adjustment clause establishes the price adjustment factor by which the base price is multiplied. You enter the price adjustment clause in the price for quantity- and time-based prices, and also in the flat rates. If a price adjustment clause is allocated to a price master, the corresponding prices can be changed indirectly, that is, using the factor. In this way, the same price increase can be applied to all prices having the same price adjustment clause. This process contains components for both adding and multiplying.
The price adjustment clause is used, for example, for index-dependent billing (for example, a formula dependent on oil prices and labor costs). Only the result of the formula is stored in the price adjustment clause.
© SAP AG IUT230 3-22
SAP AG 2006
Billing Modules: 4
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-23
SAP AG 2006
Data Model for Billing - Operands
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecategory
Ratecategory
RatetypeRatetype
Prices Prices
SchemaFact groupFact groupFact groupFact groupFact groupFact groupInstallationfacts
Installationfacts
Rate categoryfacts
Rate categoryfacts
RatetypeRatetype
© SAP AG IUT230 3-24
SAP AG 2006
Operand
Individually determined name or description for the allocated values that are used as input and output parameters in variant programs
Variable that is assigned values at runtime, for example Quantity (Q) x Price (P) = Amount (A)
An operand is allocated to one operand category. Operand categories are defined by SAP and cannot be changed by the customer.
Operands, however, are defined by the customer. It is important that you think about meaningful keys before creating operands.
An operand is always allocated to only one division.
© SAP AG IUT230 3-25
SAP AG 2006
Operand category Description
AMOUNT AmountDEMAND DemandFACTOR Number with decimal placesQUANT QuantityQPRICE Quantity-based priceREFVALUE Reference valueSEASON SeasonTPRICE Time-based price
Operand Categories/Examples
USERDEF User-defined value
Operands link values to be billed and variant programs.
An operand is allocated to an operand category and a division. Operand categories determine the functions of the operands The variant program determines which operand categories can be used as input and output operands.
The system contains 20 different operand categories.
The operand categories are predefined by SAP and cannot be changed.
© SAP AG IUT230 3-26
SAP AG 2008
Operandcategories
Operands Operand values
• Predefined
• Control processing using variant programs
• Definedindividually
• Serve as theparameters forvariant programs
• Provide operandswith values
• Determine actualvalues
Rate Determination - Operands
Facts (normal operand)
Rate facts
Rate category facts
Installation facts
Facts from RTP interface
The output parameter number of the RTP interface is stored in the facts (see above)
Facts from ERCHV
Values are read from DBERCHV
Register operand
Values are determined from meter reading results
© SAP AG IUT230 3-27
SAP AG 2006
Parameters for Operands
Operand usage
Division
Operand group
Access control
History
Rounding
Weighting key
Demand control
Franchise fee control
Contract-related operand
BW relevance
ERCHV - Supply
The variants that are required within the rates will drive the types of operands that will be required to be created. Operands can be created within the rates by specifying the operand name in the field and by double-clicking on it. The system then automatically goes to the transaction for creating operands. Operands can also be created separately.
How the operand is used indicates whether it is a register operand (operand used to enter the consumption of the register in the rate), a normal operand (e.g. a price operand), or an operand used to represent a history (for example bill printout history or history of data transfer from legacy system).
Operands are generally for a specific division.
Rounding consists of two combined fields: rounding and rounding type. Rounding is controlled as follows: if you specify a positive value, numbers are rounded to that number of decimal places. If you specify a negative value, rounding is carried out to that number of pre-decimal places. The rounding type indicates the rounding principle (rounding up, down, or to the nearest whole number).
The demand control is used to define how many demand values of a register are to be taken into account during billing.
The franchise fee control specifies the type of calculation for the franchise fee.
You use this indicator to select the operands that are mainly used in the installation facts and that are to be extracted to SAP BW.
ERCHV - Supply with historical values (only for installation groups)
© SAP AG IUT230 3-28
SAP AG 2006
Demandvalues
Contractual demand
Billeddemand
Ordered demand 25 kW
Minimum demand 10 kW
Maximum demand 32 kW
..........
..........
Operand groups
Oper
ands
Demand
Con tract dema nd
Order
Min imum dema n d
Billed d eman dDemand
Operand Groups
Reference values
Using the operand groups, you can group operands in rates, rate categories, and installation facts for display purposes.
You can define a hierarchy of operand groups with three levels.
© SAP AG IUT230 3-29
SAP AG 2006
Determination of expected values (e.g. meter readings) by means of:
ConsumptionGeneralweighting
Degree daysEnergy feedingLinear
Jan Feb . . . . Nov Dec
Weighting Procedures
Linear weighting
Weighting of energy feeding
Weighting of degree days
General weighting
Customer-specific determination
The energy feeding volume per period is used 1) for weighting in the case of a time-based breakdown of consumption, and 2) in thermal gas billing for calculating a weighted average.
For weighting of degree days, you define temperature areas that have approximately the same air temperatures. You then specify the degree day coefficients for these areas and for each degree day.
You can define the general weighting as you please. You can define both the period and the weighting values.
The register operand determines the weighting of the consumption registers. As soon as a rate type is allocated to a meter, the weighting procedure is determined via Rate Type -> Rate Determination -> Rate -> Register Operand -> Weighting Key.
© SAP AG IUT230 3-30
SAP AG 2006
Consumption Total
Degree days
LinearJan Feb . . . . Nov Dec
Linear Weighting
In addition to defining a different weighting procedure, you can specify a fixed, linear portion as either an absolute value or a percentage
The portion indicated as a percentage refers to the period consumption.
You specify the fixed values for the linear or percentage portion during device installation.
© SAP AG IUT230 3-31
SAP AG 2006
Access Control for Operands
All values are considered
Value at the end of the rate period
Value on the key date
Value at the end of the billing period
All values in the month-based billing period
Value at the start of the billing period
Value for date defined by customer
Facts
There are several ways to determine certain values from the facts (rate facts, rate category facts, and installation facts). You must note that these values are not from, for example, the meter reading results. Access control only accesses values that are stored in the facts.
You specify which access control you require in the operand.
© SAP AG IUT230 3-32
SAP AG 2006
Demand01.03. 01.28.
01.29. 03.08.
03.09. 03.14.
03.15. Last day of month
10 kW
11 kW12 kW
13 kWRate1
Rate2
01.03. 02.05.
02.06. 03.30.
01.03. 03.30.Billingperiod
All values are considered:All values are considered:
Demand01.29. 02.05.
03.09. 03.14.
03.15.
10 kW
11 kW
12 kW 03.30.
01.03. 01.28.
13 kW
02.06. 03.08.11 kW
Access Control: Example 1
Facts
In this example, every demand from the installation facts is taken into consideration. In addition, proration is carried out due to the rate change.
© SAP AG IUT230 3-33
SAP AG 2006
The value at the end of the billing period is validThe value at the end of the billing period is valid
Demand 13 kW03.30.
01.03.
13 kW
02.05.
02.06.
Access Control: Example 2
Demand01.03. 01.28.
01.29. 03.08.
03.09. 03.14.
03.15.
10 kW
11 kW12 kW
13 kWRate1
Rate2
01.03. 02.05.
02.06. 03.30.
01.03. 03.30.Billingperiod
FactsLast day of month
In this example, only two time slices are created, because of the rate change. For both time slices, however, the demand value at the end of the billing period from the installation facts is used.
© SAP AG IUT230 3-34
SAP AG 2008
Allocation of Operand Values: 1
Rate category factsRate category facts
Rate facts and rate fact groupRate facts and rate fact group
Have precedence over
Have precedence overH i
e r a
r c
h y
Installation factsInstallation facts
Operand values are usually stored in the rate facts and are, therefore, valid at rate level. Cross-rate operand values can also be defined in the rate category facts and installation facts. They have priority over the rate facts.
At rate fact and rate category fact levels, you can also enter replacement values. These replacement values give you more flexibility when allocating operand values.
You can also historically overwrite operand values. In this way, a different price key can be allocated to a certain installation for only a certain period of time, for example, a month. In the other months, the values from the rate facts are used.
If no operand value can be determined during billing, the system cancels billing and outputs an error in the application log. Exception: the rate step is marked in the rate as an optional rate step.
You define general operand values that are valid for a larger group of customers in the rate and rate category facts, and you store individual values at the installation fact level (for example, installed demand, connection loads, ordered demand, number of persons, floor area).
© SAP AG IUT230 3-35
SAP AG 2006
Contract-Related Operand – Not Activated
Contract2
Contract2
Customer2
Customer2
Customer1
Customer1
Contract1
Contract1
Move-out
InstallationInstallation
08.01.2001
Interval 1:04.15.97- 07.31.01
Interval 2:08.01.01
Move-in
1st May 1st June 1st July 1st Sep. 1st Oct. 1st Nov.1st Aug.
Installation factsInstallation facts
Facts?Facts?
If you use operands that are stored in the installation facts and you have not activated the Contract-Related Operand indicator, the facts within a move-in/out are also retained for the new customer.
© SAP AG IUT230 3-36
SAP AG 2006
Contract-Related Operand - Move-In
Contract2
Contract2
Customer2
Customer2
Customer1
Customer1
Contract1
Contract1
Move-out
InstallationInstallation
08.01.2001
Interval 1:04.15.97- 07.31.01
Interval 2:08.01.01
Move-in
1st May 1st June 1st July 1st Sep 1st Oct 1st Nov1st Aug
Installation factsInstallation facts
Facts?Facts?
Installation factsInstallation facts
If you are carrying out a move-in without contract change, operand values from the period before the move-out are not copied. Note that the business partner may change. For this reason, it is not expedient to copy values from previous time slices. If the move-in is reversed, the active time slices as of the move-in date are deleted.
© SAP AG IUT230 3-37
SAP AG 2006
Contract-Related Operand - Contract Change
Contract2
Contract2
Customer1
Customer1
Customer1
Customer1
Contract1
Contract1
Move-out
InstallationInstallation
08.01.2001
Interval 1:04.15.97- 07.31.01
Interval 2:08.01.01
Move-in
1st May 1st June 1st July 1st Sep 1st Oct 1st Nov1st Aug
Installation factsInstallation facts
Facts?Facts?
If you execute the contract change function during the move-in, the time slices that were deactivated by the move-out are reactivated in the installation facts as of the move-in date. Note that, in this case, the business partner is not changed. The existing contract is replaced by a new one. If the move-in is reversed, the active time slices as of the move-in date are deactivated again.
© SAP AG IUT230 3-38
SAP AG 2006
IS-U RateIS-U Rate
y1
Result Function Oper. cat.e1 Sum QUANTe2 Average DEMANDe3 Peak DEMAND
Rate: ON_OFF_PEAK
RegOperand
RTP-Interface ON_OFF_PEAK
001 ....
... ...
007 QUANTI01 ONPEA KCON ... Pr icing for ON-peak consumption
008 QUANTI01 OFFPEAKCON ... Pr icing for OFF-peak consumption
... ...
Transfer Result to RTP Operand
RTP interfaceRTP interface
EDM profileEDM profile
The discrete RTP operand values are the result of processing within the RTP interface. The RTP interface obtains its input data from Energy Data Management repository (EDM).
© SAP AG IUT230 3-39
SAP AG 2006
Billing Modules: 5
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-40
SAP AG 2006
QUANTITY FACTOR QUANTITYCalculates x% of a quantityQUANTITY FACTOR QUANTITYCalculates x% of a quantity
. . . . . .
. . . . . .
NUMBER OF DEMAND PEAKS DEMANDCalculates N peak averagesNUMBER OF DEMAND PEAKS DEMANDCalculates N peak averages
DEMAND PRICE BILL LINE ITEMS Valuates demand with a priceDEMAND PRICE BILL LINE ITEMS Valuates demand with a price
. . . . . .
QUANTITY QUANTITY QUANTITY Difference of two quantitiesQUANTITY QUANTITY QUANTITY Difference of two quantities
. . . . . .
. . . . . .
QUANTITY PRICE BILL LINE ITEMSValuates energy with a priceQUANTITY PRICE BILL LINE ITEMSValuates energy with a price
ACTIVE_KWH 0.5 ACTIVE_50%ACTIVE_KWH 0.5 ACTIVE_50%
REACT_kVar - ACTIVE_50% BILL_REACTREACT_kVar - ACTIVE_50% BILL_REACT
BILL_REACT 0.06 USD BILL LINEITEMS
BILL_REACT 0.06 USD BILL LINEITEMS
Variant PoolVariant Pool
Variant PoolVariant Pool
Contract Text:The reactive energy that exceeds 50% of the active energy is valuated using a separate price.
Contract Text:The reactive energy that exceeds 50% of the active energy is valuated using a separate price.
*
*
**
*
-
Flexible Structure of Billing Rules
SAP provides a pool of variant programs with the system. This pool contains many variant programs.
Variant programs are contained in rates as rate steps. Variant programs are basic calculation steps (e.g. consumption x price, determination of the basic price, or determination of the rental price).
By combining variant programs, you can model certain contract texts in the system (for example, formula for reactive current calculation).
In the above example, three variant programs are required to represent the contract text. The variant programs communicate with each other using input and output parameters. Operands are simply variables or placeholders that are filled with actual values (such as consumption, price) at runtime.
© SAP AG IUT230 3-41
SAP AG 2006
Variant Programs 1
Are small, independent ABAP/4 programs
Perform elementary calculation steps
Are used in combination to model the billing rules in the rate
Variant programs are small, independent ABAP/4 programs (function modules).
Variants perform elementary calculation steps. Many variant programs calculate values relevant to billing and generate billing line items. Other variant programs convert values and, in turn, make the results available to subsequent variants.
Variant programs can be used in any combination. This allows you to model complex billing rules.
You can also create your own variant programs to represent special, non-standardized calculations.
© SAP AG IUT230 3-42
SAP AG 2006
Variant Programs 2
ABAB/4Function modules
function isu_quanti01.
Include ievarbasic.Data: ...........
If wprei-preisart = ‘2’.loop at .........endendif.ndendfunction.
Inputoperands
Outputoperands
Billline Items
In most cases, variant programs have input and output operands which represent the ingoing and outcoming parameters (variables) of the variant program. These operands belong to a particular operand category.
SAP defines which variant program needs which input and output operands (number, operand category).
In the system, the variant programs process specified tables. During data collection for billing, these tables are filled with all required data.
© SAP AG IUT230 3-43
SAP AG 2006
Characteristics of a Variant
Rate permissibility: Checks when rates are created
Block period: Controls whether block periods can be included? Selection options in schema
Bill line items relevant for posting: Controls whether fields for account determination subtransactions have to be maintained for the rate
Optional: Controls whether the user has the option of setting this indicator in the rate
Not for extrapolation: Prevents the variant from being executed during budget billing extrapolation
Type of quantity: Controls the statistics update
Operand categories of input and output operands
Document line item types
Customer variants must have the variant categories '00' (normal), '01' (IF variant) and possibly '10' (lighting variant).
Variant category '10' contains a check for the reference value type 'lighting unit'. Variant category '01' is important for correctly structuring the nestings during a schema workflow.
The indicator for posting-relevant bill line items means that a posting-relevant bill line item is written. However, this is purely for information. It does not control anything. The billing line item writing must be programmed in the variant. In addition to this, an indicator ensures that the fields for statistics control can be maintained in the schema.
The IF variants, for example, are variants that can never be set to optional. If these are not included in the schema due to missing operand values, the nesting logic will be incorrect during billing.
Preventing the execution of variants during budget billing extrapolation is normally used for variants that write in installation facts and variants for backbilling.
© SAP AG IUT230 3-44
SAP AG 2006
Examples of Variant Programs
COMPUT01 Subtraction of two amounts
DEMAND01 Valuation of a demand with a price
DISCNT01 Quantity discount, percentage or absolute amount
IF01 Condition: If Quantity1 >,>=,= Quantity2
ELSE Start of a NOT operation for an IF variant
ENDIF End of an IF nesting
INFACT01 Writing of a demand in the installation facts
QUANTI01 Valuation of a quantity with a price
QUANTI05 Writing of info lines for the quantity
SAP provides a wide range of variant programs with the system.
A simple evaluation function helps you to select the variant programs you need for the billing rule.
The keys of the variant programs have a particular semantic. For example, all variant programs that begin with QUANTI deal with consumption/quantities to be billed.
The variants are grouped as follows:
BACKBI* Variants dealing with billing nonresidential customers
COMPUT* Arithmetic operation
DEMAND* Demand valuation
DISCNT* Discounts, surcharges
INFACT* Writing of values in the installation facts
IF/ELSE/ENDIF Conditions in rate
LUMSUM* Valuation of flat rates
QUANTI* Valuation of consumption/quantities
REFVAL* Valuation of reference values
SETTLE* Calculation of rental and settlement prices
UTILIT* Special billing features (such as best-rate billing)
© SAP AG IUT230 3-45
SAP AG 2006
Doc. line item types rel. to postingDoc. line item types rel. to posting Information line itemsInformation line items
Examples of Document Line Item Types
000001 Energy price
000002 Demand price
000003 Flat rate
000004 Rental price
000005 Reference value
000006 Amount discount
IQUANT Quantities (meter readings)
IDEMAN Demand (meter readings)
IT001 Flat rate x factor
IT002 Addition of two operands
IT001 Quantity x (/) factor
IT004 Demand x (/) factor
IT005 Subtraction of amounts
IT006 Comparison of two quantities
The document line items control and analyze the billing rule.
Billing document line items are primarily required for bill printing, where the system may need to know which line item it is dealing with, for example in the billing form. For example, different information needs to be printed for energy price line items than for basic charge line items.
Line item types are stored in the rate in the rate steps and are automatically proposed by the system.
If necessary, additional document line item types can be defined in the customer namespace and be allocated to a variant program or rate.
© SAP AG IUT230 3-46
SAP AG 2006
Billing Modules: 6
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-47
SAP AG 2008
Rate Characteristics
Permissibility of the rate
Value relevant to billing measured by a register (register operand)
Register-based data
RTP rate and RTP interface
Calculation formulae
Allocation of values to operands (rate facts)
Account determination
Handling of bill line items
Header Data:
Rate Step Data:
The rate contains many fields with a controlling function. They will be described in more detail later on.
The consumption of the register is made available to billing in the register operands. The register operand is determined by choosing: Register -> Rate Type -> Rate Determination -> Rate -> Register Operand.
An RTP interface can only be assigned to rates for which interval meters are allowed (permissible).
© SAP AG IUT230 3-48
SAP AG 2006
Rate
Rate steps
Variant program
Operand
Operandcategory
Rate
The rate consists of a key, header data, and one or more rate steps. A variant program is processed for each rate step.
These are some points that the rate determines:
how the measured consumption is extrapolated or broken down for meter reading data processing and for proration
Which technical billing values are measured by a register
which reference values are billed
in which calculation formulas the values are used
Which prices are used
Which general ledger accounts the calculation (bill line items) results are posted to
How the bill line items are statistically treated
to which division and billing class the rate is allocated
© SAP AG IUT230 3-49
SAP AG 2006
Rate headerDivisionBilling classPermissibilityRegister-based dataNotes
Rate Attributes
Rate steps
Variant programsSubtransactionsOperands ---> Rate factsStatistical rateFranchise fee groupControl parameters
The register operand is entered in the header data. The consumption of the register is made available to billing in the register operands. The register operand is determined by choosing: Register -> Rate Type -> Rate Determination -> Rate -> Register Operand.
Larger rates with several rate steps can be documented using the notes.
The subtransactions control the account determination but can also be used as statistics criteria.
The statistical rate is used to distribute revenues and quantities of the individual rate steps over different rates for evaluation in the sales statistics.
The franchise fee group controls the calculation of the franchise fee.
© SAP AG IUT230 3-50
SAP AG 2008
Invoicing Transactions
In the rate, you must enter a debit and credit billing subtransaction for every rate step that creates billing line items relevant for posting. When the rate step is executed during contract billing, the plus or minus sign of the net amount determines which of these two subtransactions is used.
0023
D-ST
QUANTI01
Variant
1
CNo
011001200013
BBCSBBDSC-ST
Transactions describe the business scenario that forms the basis for posting a document line item
Normally, these billing subtransactions do not have to be so detailed for the business partner items. As a result, they are replaced by aggregated transactions in invoicing, which optimize the number of business partner items.
Note:
Budget billing subtransactions from the rate step are allocated to the budget billing extrapolation line items.
Budget billing subtransactions are only used for account determination. Receivables accounts are only found via the main transaction. Revenue and tax accounts via the debit transaction.
Budget billing amounts with different budget billing subtransactions are managed separately in the budget billing plan.
Budget billing subtransactions and billing subtransactions must be maintained separately.
© SAP AG IUT230 3-51
SAP AG 2006
Transactions
• Account det.• Tax det.
• IS-U settings• Debit/credit• Interest key• Stat./non-stat.
• Allocation tointernaltransactions • Default setting
by SAP
Sub-trans.
FI-CA
Maintrans.
FI-CA
IS-Utrans.
IS-UAllo-
cation
IS-U
InternalSubtrans.
SAP
Internalmain trans.
SAP
Transactions describe the business scenariothat forms the basis for posting a document line item
A transaction is a combination of main and sub-transactions
Texts allocated to the main and sub-transactions describe the business transaction and are made available for correspondence.
Main and sub-transactions control account determination.
They also control tax determination.
IS-U uses internal main and sub-transactions, which the system assigns to the different IS-U business processes, which they then control.
The internal transactions represent only a minimum of all transactions available in the IS-U functions. You can also maintain any number of transactions for manual postings.
You can specify transactions in IS-U by means of certain characteristics such as the debit/credit indicator, the interest key, and the statistics indicator.
© SAP AG IUT230 3-52
SAP AG 2006
Example Transactions in Invoicing
Invoicing uses the following internal posting transactions in the program:
Invoicing: Receivable from posting00200250
Invoicing: Credit from posting00100250
Manual receivable backbilling00200300
Manual credit backbilling00100300
Receivable final billing00200200
Credit final billing00100200
Receivable consumption billing00200100
Credit consumption billing00100100
DescriptionInternalsubtrans.
Internalmain trans.
The internal transactions control the invoicing program. They are allocated the external customer transactions in Customizing.
Main and subtransactions fulfill three functions:
They document the aspect of the business scenario or process, which forms the basis for posting the document item.
An explanatory text is allocated to every main and subtransaction. This text can be used for correspondence.
Main transactions and subtransactions influence automatic account determination.
© SAP AG IUT230 3-53
SAP AG 2006
Subtransactions in IS-U Billing / Invoicing
Maintransaction
Periodicbill
CreditEnergy price
CreditDemand price
.....
ReceivableDemand price
ReceivableEnergy price
..........
Freely definable / integrated in rates / acct determ. (main transaction and transaction)
Allocated to internal transactions / no account determination
ReceivablePeriodic billReceivablePeriodic bill
CreditPeriodic bill
CreditPeriodic bill
CreditProvisioning
price
ReceivableProvisioning
price
The accumulation transactions are allocated to the internal transactions, and do not have a defined account determination.
Transactions for the price components can be freely defined and are maintained in the rates. The account determination (main transaction relevancy and transaction relevancy) is defined for them.
Transactions must be defined for all main billing transactions (consumption billing / final billing / manual billing).
© SAP AG IUT230 3-54
SAP AG 2006
Subtransactions in the Statistical Budget Billing Procedure in IS-U
BB planDebit
BB pay-outTransf. posting
BB paymentTransf. posting
Budget billingpayment
Budget billingpay-out
..........
Allocation to internal transactions / No account determination
Can be freely defined (stat.) /included in rates /account determination (BB amount)
Maintransaction
BBstat. proc.
BB planCredit
The payment and transfer procedures should be allocated to the internal procedures. Account determination is not necessary.
The payment transactions must be defined as "follow-up" transactions for the extrapolation transactions.
The sub-transactions for budget billing extrapolation are maintained in the rates. They must be defined statistically (debit = "P" / credit = "Z"). Account determination must be defined for these transactions.
© SAP AG IUT230 3-55
SAP AG 2008
Accountdetermination(Posting area
R000)
Balance sheetaccount: 140500
(Receivables forenergy supply)
Receivablesaccount
Account Determination: Receivables Account
For example, billing:
Main trans. 0010
Businesstransaction
Company code 0001Division 01Account det. ID 01
Contract /contract account
The account determination ID can be found in the contract account for multiple-contract or contract-independent postings, or in the contract.
© SAP AG IUT230 3-56
SAP AG 2008
For example, billing:
Main trans. 0010Subtrans. 0010
Businesstransaction
Contract /contract accountCompany code 0001Division 01Account det. ID 01
Accountdetermination
(Postingarea R001)
Transactiondetermination
P/L account: 800010
(Revenue fromenergy price:
Electricity)
Sales revenueaccount
Transaction
0010-0010
Account Determination: Sales Revenue Account
The account determination ID can be found in the contract account for multiple-contract or contract-independent postings, or in the contract.
The subtransaction is also required for the revenue account determination
Additional account assignments (for example, cost center, plant) and the tax determination ID are also determined through sales revenue account determination.
© SAP AG IUT230 3-57
SAP AG 2006
CO Account Assignment
Profit center PC001
Cost center
Order
PSP element
Result object 4711
NoYes
Contract:Company code: 0001Company code: 0001
Business area: U001Business area: U001
CO accountassignment: V01CO accountassignment: V01
Determination of CO accountassignment
Determination of CO accountassignment
Account assignmentdetermined?
Determination of CO accountassignment
Determination of CO accountassignment
Accountdetermination:
Company code: 0001Company code: 0001
Business area: U001Business area: U001
CO accountassignment: K01CO accountassignment: K01
Account assignments are derived from account specifications in the master record of the IS-U contract, account determination (posting area R001), or from the standard values of the cost element to be posted.
The posting items from invoicing are allocated the appropriate additional account assignments from CO so that they can be forwarded to the cost accounting components.
These additional assignments were already determined in contract billing. If the billing document line item is a line item relevant for posting and is posted to a cost element, the additional account assignment from CO is determined according to the following priorities: - Direct entry of the account assignment when the billing document line item is manually entered (if you are dealing with manual billing)- Specifications in the contract - Specifications in account determination (posting area R001) - Standard account assignment of cost element (for example in transaction KA02 'change cost element')
CO account determination keys (field COKEY) are allocated to the contract master record and contract determination. The CO account determination keys encode a valid combination of the CO additional account assignments. You can maintain the CO account determination keys in Customizing under Financial Accounting -> Contract Accounts Receivable and Payable -> Basic Functions -> Postings and Documents -> Document -> Store Short Account Assignments for IS-U Contracts or for Define CO Short Account Assignments.
© SAP AG IUT230 3-58
SAP AG 2006
IMGIMG
...........
..........
..........
..........
Customizing forTime Period Control
Time Period Control
Time period procedureTo-the-day
Key date
Interval (+ enhanced interval procedure)
Alternative procedures are possible for the following special cases:
Move-in
Move-out
Values added/omitted sub-periodically
Consideration of leap years
You can control how periods are to be calculated by means of the period control in the rate steps.
The following procedures are supported:
To-the-day
for an exact number of months with a key date
For an exact number of months with intervals
The above procedures can also be dealt with differently in certain special cases (such as move-in/out).
The key date for month-related billing is entered in the meter reading unit.
The intervals for month-related billing are entered in the portion.
For calculating month-based time portions depending on an interval, additional values can be stored daily intervals using the enhanced interval procedure.
In the enhanced interval procedure: - To the month with key date refers to the calendar month - The interval procedure refers to the duration of the billing period. In the enhanced interval procedure, the limits can be specified for any period (rather than for just one month).
© SAP AG IUT230 3-59
SAP AG 2006
Variant Control
COMPUT01COMPUT02COMPUT03COMPUT04COMPUT08QUANTI02QUANTI08QUANTI09QUANTI10QUANTI15
COMPUT01COMPUT02COMPUT03COMPUT04COMPUT08QUANTI02QUANTI08QUANTI09QUANTI10QUANTI15
• Operand update - Addition• Operand update - Overwrite• Operand update - Addition• Operand update - Overwrite
Variant control
QUANTI*DEMAND*QUANTI*DEMAND* • Write info lines on quantity• Write info lines on quantity
Variant control
Using variant control, you can control the different variant programs. Control indicators are not the same for all variant programs, but depend instead on the task of each variant program.
© SAP AG IUT230 3-60
SAP AG 2006
Billing Modules: 7
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-61
SAP AG 2006
Data Model for Billing – Fact Group
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecategory
Ratecategory
RatetypeRatetype
Prices Prices
SchemaInstallation
factsInstallation
facts Fact groupFact groupFact groupFact groupFact groupFact group
Rate categoryfacts
Rate categoryfacts
RatetypeRatetype
© SAP AG IUT230 3-62
SAP AG 2006
Factgroup
A
Fact Group
Rate
Operand AValue 1
Operand AValue 2
Fact groups enabledifferent operand values to be used within onerate
Factgroup
B
Concrete values, keys that the operands have been allocated and that are valid for a particular period, are referred to as facts. Depending on the level at which the key is allocated, these are either installation, rate or rate category facts.
Using the fact group, you can assign different values to individual operands in the rate facts.
A fact group must always be entered in combination with a rate type.
At rate level or rate-category-fact level, you can enter a replacement value instead of a fixed operand value (mandatory/optional entries are required at sub-ordinate levels). These replacement values give you more flexibility when allocating operand values.
© SAP AG IUT230 3-63
SAP AG 2008
Price C0.70
Price C0.70
Price B0.60
Price B0.60Rate category factsRate category factsRate category facts
Rate facts and rate fact groupRate facts and rate fact groupRate facts and rate fact group
Have precedence over
Have precedence over
Price A0.55
Price A0.55
H i
e r a
r c
h y
Allocation of Operand Values
Installation factsInstallation facts
Operand values are usually stored in the rate facts and are, therefore, valid at rate level. Cross-rate operand values can also be defined in the rate category facts and installation facts. They have priority over the rate facts.
At rate fact and rate category fact levels, you can also enter replacement values. These replacement values give you more flexibility when allocating operand values.
You can also historically overwrite operand values. In this way, a different price key can be allocated to a certain installation for only a certain period of time, for example, a month. In the other months, the values from the rate facts are used.
If no operand value can be determined during billing, the system cancels billing and outputs an error in the application log. Exception: the rate step is marked in the rate as an optional rate step.
In the rate facts and rate category facts, you define general operand values. These apply to groups of customers. An installation fact level, you define individual values, such as connection values and number of persons.
© SAP AG IUT230 3-64
SAP AG 2006
Installation Facts
However, only rate types for which the appropriate indicator is set can be used in the facts These rate types cannot be maintained at the device or register level
You can override the data in the general rate category and in the facts to allow for customer-specific agreements
You can also specify the rate type, and therefore the rate, in the facts
Ratecategory
Ratecategory
Rate typeRate typeRateRate
Installationfacts
Installationfacts Rate factsRate facts
Rate categoryfacts
Rate categoryfacts
© SAP AG IUT230 3-65
SAP AG 2006
Extension: EBIS0002Extension: EBIS0002
Rate TypeRate Type Rate Fact GroupRate Fact Group
EXIT_SAPLE20Q_001 Search help rate typeEXIT_SAPLE20Q_002 Search help rate fact groupEXIT_SAPLE20Q_003 ChecksEXIT_SAPLE20Q_004 Proposal logic
EXIT_SAPLE20Q_001 Search help rate typeEXIT_SAPLE20Q_002 Search help rate fact groupEXIT_SAPLE20Q_003 ChecksEXIT_SAPLE20Q_004 Proposal logic
Function Exits
SAP Extension (Rate Type + Rate Fact Group)
This extension provides you with the following function exits:
EXIT_SAPLE20Q_001 Adapting the search help to the rate type
EXIT_SAPLE20Q_002 Adapting the search help to the rate fact group
EXIT_SAPLE20Q_003 Customer-specific input checks for rate type and rate fact group
EXIT_SAPLE20Q_004 Creating a proposal logic for the rate type and rate fact group.
For example, you can specify default if the corporation only uses one rate fact group It is also possible to let the rate fact group be recommended, for example, by regional factors.
© SAP AG IUT230 3-66
SAP AG 2006
Billing Modules: 8
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-67
SAP AG 2006
Data Model for Billing – Schema
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecategory
Ratecategory
RatetypeRatetype
Prices Prices
SchemaInstallation
factsInstallation
facts Fact groupsFact groupsFact groupsFact groupsFact groupsFact groups
Rate categoryfacts
Rate categoryfacts
RatetypeRatetype
© SAP AG IUT230 3-68
SAP AG 2006
Billing Schema: 1
Is valid for a certain division
Is valid for a certain billing class
Contains one or more rates
Determines the sequence of the rate steps for billing
Rates and their variant programs and operands are included in a billing schema. The following are specified in a billing schema: the rates used for billing, the schema steps used, and the sequence of the schema steps.
More than one rate can be contained in a billing schema than is necessary for the billing of a certain installation. Therefore, it is possible that a billing schema can contain two rates (on-peak household rate and off-peak household rate). Only one single-rate meter is installed in the installation. In this case only the on-peak rate is billed. The off-peak rate is simply ignored in the schema.
© SAP AG IUT230 3-69
SAP AG 2006
Billing Schema: 2
Controls how bill line items are dealt with statistically (quantity and/or amount)
Controls gross billing
Controls dynamic period control
Controls billing in advance
Is dependent on the rate category in the installation
© SAP AG IUT230 3-70
SAP AG 2006
Schema Attributes
Schema Header
DivisionBilling classBilling blockEnd of period billing/backbillingNotes
Schema Steps
RatesControl indicatorPresort keyDeletion operandGross line itemsNotes at step level
After a rate has been changed, the schema is automatically blocked, and the billing block has to be lifted by a clerk.
A schema is always allocated to a certain billing class and division. This checks the permissibility of different billing master data against each other.
A schema is made for a particular customer group. If too many schema steps are contained in the schema, which are not processed for each customer, it results in unnecessary run time.
The schema must contain all rates that can be billed together in an installation:
On-peak rate active energy
Off-peak rate active energy
On-peak rate active power
The presort key plays an important role in sorting individual billing line items for subsequent bill printout. We will look at the function of the presort key in more detail later on.
The deletion operand is required if billing line items have to be deleted while a contract is being billed, for example, in comparisons such as best-rate billing or maximum price limitation. The billing line items that are to be deleted must be provided with a deletion operand.
© SAP AG IUT230 3-71
SAP AG 2008
Installation Disconnection in Billing
Technical reasons
Customer request
Vacant status(no move-in after move-out)
FI-CA disconnectiondunning level reached
2006
01.09. .... .... .... .... .... .... 01.14.
Calculate basic price for disconnection period?Control at schema step level
Calculate basic price for disconnection period?Control at schema step level
Billing period
Disconn. period
At each schema step, you can define whether or not the charge (such as basic price, service price, rental price) is to be billed for the disconnection period.
In Customizing for disconnection/reconnection and also in the disconnection document itself, you can differentiate more precisely whether or not the control in the schema is to be taken into account.
© SAP AG IUT230 3-72
SAP AG 2008
Schema E1Rate Var.pr. Stat. Group QuantityRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002
. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002
I_ABRMENGE
St. gr. '000001'
I_ABRMENGE
St. gr. '000001'COCO--PAPA
WWABRWWABRWWLEIWWLEI
CO-PA actual data(yes/no)
CO-PA actual data(yes/no)
Statistics Groups: Quantities
Billing documentBilling document
COCO--PAPA
WWABRWWABRWWLEIWWLEI
CO-PA statisticaldata
CO-PA statisticaldata
You enter the statistics group for quantities in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the quantities (for example, on-peak/off-peak rate active energy) in the BW. This also makes it easier to transfer data to CO-PA.
SAP ships the statistics groups 000000 to 000002 with the system as standard.
You should define the statistics groups in detail to ensure that the quantity in the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously (using rules in BW).
Always include quantity and amount as key figures and include statistic groups and the amount together in one dimension!
In the statistics group, you also define into which value fields of the operating concern the quantity in a billing line item is copied. This only applies to statistical postings in CO-PA (for example for unbilled revenue reporting).
You cannot assign any update rules to a statistics group for actual postings of the value flow in CO-PA. You control these updates using the PA transfer structure. Basically, all the billing line items in a billing document for which the field 'Billing line item relevant for posting' is set are processed for actual posting in CO-PA. The amounts from the billing line items are always transferred for actual posting. You can, however, prevent the amounts from being transferred by not setting the field 'Relevant for actual posting in CO-PA' in the statistics group quantity.
© SAP AG IUT230 3-73
SAP AG 2008
Schema E1Rate Var.pr. Stat. Group: AmountRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002
. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002
NETTOBTR
Stat. group ‘000001’
NETTOBTR
Stat. group ‘000001’
VVNETVVNETVVARBVVARBVVLEIVVLEI
CO-PA Actual Data(Always Transfer)
CO-PA Actual Data(Always Transfer)
Statistics Groups: Amounts
Billing DocumentBilling Document
COCO--PAPA
COCO--PAPA
VVNETVVNETVVARBVVARBVVLEIVVLEI
CO-PA StatisticalData
CO-PA StatisticalData
You enter the statistics group for amounts in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the amounts (for example, energy and flat rate amount) in the BW. This makes it easier to transfer data to CO-PA.
SAP ships the statistics groups 000000 and 000001 with the system as standard.
You should define the statistics groups in detail to ensure that the amount in the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.
© SAP AG IUT230 3-74
SAP AG 2006
Sorting for Bill Printout
Presort keys are for sorting billing line items before printout
Billing line items with the same presort keys form a group
Billing groups are sorted in ascending order according to the presort key
Function modules are used for sorting within billing groups
Presort keys must be allocated to all document lines in the schema
The presort keys are allocated in the schema of every billing or information line item and specifies how individual billing line items are sorted for bill printout.
You have to take all schemas into consideration. If, for example, an electricity and gas bill is to be created, the presort keys in the electricity and gas schemas should be checked against each other.
We will look at the function of the presort key in more detail in the chapter on bill printout.
© SAP AG IUT230 3-75
SAP AG 2006
Contract Billing Modules: 9
Billing class
Rate type
Price
Operand
Variant program
Rate
Fact group
Schema
Rate category
© SAP AG IUT230 3-76
SAP AG 2006
Data Model for Billing – Rate Category
Ratedetermination
Ratedetermination
Customer andinstallation data
Process data
Schema IRate Var.pr. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A x3- Step 2 VarProg. C x4- Step 3 VarProg. D x5
. . .
. . .
. . .
Rate n- Step 1 VarProg. A xxx
EXECUTION
ContractContract
InstallationInstallation
Installationstructure
Installationstructure
Billing class
Ratecategory
Ratecategory
RatetypeRatetype
PricesPrices
SchemaInstallation
factsInstallation
facts Fact groupFact groupFact groupFact groupFact groupFact group
Rate categoryfacts
Rate categoryfacts
RatetypeRatetype
© SAP AG IUT230 3-77
SAP AG 2006
Rate Category I
Valid for one division only
Belongs to a single billing class
Contains one valid billing schema
Controls billing - used to determine the rate in conjunction with the rate type
Determines which outsorting checks occur during billing
Controls accompanying backbilling and period-end billing for nonresidential customers
Controls advance billing and dynamic period control
The rate category classifies the installation for billing. The rate category is used in conjunction with the rate types to determine the rate.
Rate determination: rate type + rate category = rate
© SAP AG IUT230 3-78
SAP AG 2006
Rate CategoryBilling Class
OutsortingGroup
Division
Notes BackbillingPeriod-End Billing
DynamicPeriod Control
Billing Scheme
Billing in Advance
Rate Category II
The rate category contains data that controls the processing of billing data. This includes:
Billing Scheme
Control of period-end billing and accompanying backbilling
Outsorting checks
Any other billing-relevant data is also saved in the rate category. This includes any agreed quantities, demand, prices, or flat rates. In the case of flat rate services (such as cable services and street lights), no quantities are measured. You must therefore define replacement values that the system can use for evaluation (for example number of cable connections or number of street lights with a specific connection value).
© SAP AG IUT230 3-79
SAP AG 2006
STATISTICS GROUPSSTATISTICS GROUPS
Statistics groups forStatistics groups for ContractsContractsRatecategories
Ratecategories
Standardcustomers
C&Icustomers
Division Contract Rate cat. Update group01 ’ ‘’ ‘ 0101 SISU
01 0101 0101 Z00001
Residentialcustomers
Individualstatistics
Stats. group ‘ ‘ Stats. group 01Stats. group 02 Stats. group 01
Determination of Update Group
You can group rate categories and contracts according to the statistics update procedure using statistics groups.
You find the statistics groups for rate categories on the rate category screen. The statistics group for contracts is on a contract screen.
The following are examples of different updates:
Rate categories: "Residential customers" and Commercial and industrial customers".
Contracts: "Standard customers" and "Individual statistics". For certain contracts (such as standard customers), individual statistics are stored.
The update group controls the update on a general level. It is determined by a combination of the various statistics groups and the division.
© SAP AG IUT230 3-80
SAP AG 2006
Statistics GroupStatistics Group
Update GroupSISU
Update GroupUpdate GroupSISU SISU
CustomerSchultz
CustomerCustomerSchultzSchultz
Update GroupZIND
Update GroupUpdate GroupZINDZIND
CustomerSAP
CustomerCustomerSAPSAP
UpdateUpdateRulesRules UpdateUpdate
RulesRules
1.1.
2.2. 3.3.
BW
Customer = “Dummy”
Customer = “Dummy”
Customer = “SAP”
Customer = “SAP”
If update group = SISUthenname = “Dummy”
Why Update Groups?
Billing Document
Division 01
Statistics Group ‘ ‘Contract
Statistics Group 01Rate Category
Update GroupSISU
When contracts are billed, the division and the statistics group are determined from the contract and rate category.
Using the combination of division and statistics groups, the system determines the relevant update group and saves it in the billing document for statistics-relevant line items. Only line items with an update group in which an entry has been made can be updated to the BW.
On the basis of the update group, further differentiations can be made within the BW, for example, industrial and residential customers.
© SAP AG IUT230 3-81
SAP AG 2006
Ratecategory
Ratecategory
RatetypeRatetype
Historical
Dynamic Rate Determination
TarifTarifTarifTarif
TarifTarifTarifTarif
RateRate
Several rates can be determined,for example, for best-rate billing
Several rates can be determined,for example, for best-rate billing
Rate determination: Rate type + rate category = Rate
The rate types/rate categories may not have to be changed in the master data if rates are reformed because the rate can be determined historically. It suffices to find new rates for a certain key date.
The system can also determine more than one rate per rate type and rate category. You can use this option, for example, to model best-rate billing in the system (low consumption rate, basic price rate 1, basic price rate 2).
© SAP AG IUT230 3-82
SAP AG 2006
Rate type (e.g. on-peak rate)
Rate type (e.g. ripple control receiver)
Rate type (e.g. flat-rate installation)
Installation structureRegister
Device
Billing-relevantobjects
Billingmaster data
Use of Rates
Rate categoryfacts
Installationfacts Rate type (e.g. flat-rate installation)
The rate is comprised of a combination of the rate type and the rate category.
The rate type is generally maintained in the register. In some cases, it can be maintained at device level or in the installation facts. In addition, the rate type can be entered in the rate category facts (for example, if a device does not exist).
A rate type for reference values can also be defined in the installation facts (for example for street lighting, telephone booths).
© SAP AG IUT230 3-83
SAP AG 2006
Initial Creation of a Rate Structure
Rate typeRate type
Prices (create from rate)Prices (create from rate)
Link tofact group
DetermineVariantprogramsVariantprograms
Determine Sequenceof ratesSequenceof rates
Select BillingschemaBillingschema
AllocateRatesRates
Rate categoryRate category
RatesRates
Billing schemaBilling schema
Operands (create from rate)Operands (create from rate)
Rate determinationRate determination
Individual rate components must be created and maintained in a predefined sequence.
The sequence is determined by the respective links to the individual components.
The components are maintained in the following sequence:
Rate types
Operands
Prices
Rates
Schemas
Rate categories
Rate determination
You do not normally create the operands and prices beforehand, instead you create them from the rate. To do so, you enter the new name (of the operand, for example) in the field and by double-clicking on it, the system automatically goes to the transaction for creating operands.
© SAP AG IUT230 3-84
SAP AG 2006
Determines whether the master data can be billed by checking the completeness of:
The rate determination data
The operand values
The overall check is carried outDuring billing
During move-in
Upon special request
During data migration
Overall Check
The overall check ensures that all data relevant to the billing process is complete and correct.
© SAP AG IUT230 3-85
SAP AG 2006
Automatic Billing and Simulation: Initial ScreenDisplay Document Billing Reversal Invoice Simulation Display Print Document
Status
Log
Log
Big-Check
Billing Types
SimulationBilling SimulationBilling
-31.12.9999
Portion
Selection CriteriaContractInstallationContract Account
Billing Order Selection
Billing TransactionDivisionCompany Code
End of RuntimeCheck Runtime
DateTime
31.12.999913:31:10
Overall Check
XYZ0815
U100
Execution of different billing types
For different selection criteria
Automatic Billing/Simulation Edit Goto Settings Utilities System Help
- Rate determination- Billing view of installation- Operand determination- Simulation of period-end billing/backbilling
- Rate determination- Billing view of installation- Operand determination- Simulation of period-end billing/backbilling
Billing Analysis
Using the billing analysis, you carry out a detailed check to ensure that your rate models are correct.
To do so, you can also activate the debugging function and specify an existing variant program as a break point. During the billing run, processing stops at this point. You can then display the internal field content.
The billing analysis is not designed for processing in production operation.
© SAP AG IUT230 3-86
SAP AG 2006
Contract 2 VAT Ind. A1 Amount 80 $
Contract 1 VAT Ind. A2Amount 20 $
Contract 2 VAT Ind. A1 Amount 30 $
Contract 1 VAT Ind. A2 Amount 20 $
Document Analysis
Print document
Posting document 0815
Contract 1
Billing document 4711Contract 1VAT Ind. A1 Amount 100 $
Document items for general
ledger
Contract 2Contract 2 VAT Ind. A1 Amount 50 $
Billing document 4712
Document items for subledgerContract 1 VAT Ind. A1Amount 100 $Business partner
Contract account
Contract 1
Installation 1
Contract 2
Installation 2
Billing documents and print documents can be created from the billing analysis. These must be looked at in detail after successful billing (billing document for each contract) or invoicing (print document for each contract account).
Billing can executed as simulation.
The business partner items for the contract billing documents are constructed in detail according to:
Company Code
Business area
Account determination ID
Contract
Division
Main transaction
VAT code
The general ledger items for the contract billing documents are constructed in detail according to:
VAT code
Sales revenue account
CO account determination data (for example, cost center and so on)
© SAP AG IUT230 3-87
SAP AG 2008
Billing Master Data: Summary
Billing is the central component of SAP Utilities for calculating energy and water supplied to customers.
The central billing engine enables you to model all possible combinations of different billing steps.
The consistency of all required data is checked to ensure correct billing.
Dynamic rate determination allows for quick adjustment of entire customer groups to new rates.
SAP AG
© SAP AG IUT230 3-88
© SAP AG IUT230 3-89
Exercises
Unit: Billing Master Data Topic: Rate Type
Find the rate type definition in the implementation guide.
As a member of the sales department in your company, you should understand the elements of billing master data and be able to use them to create test data.
1-1 Check the implementation guide (SAP Reference IMG) for information regarding rate types, and answer the following questions.
True or false:
1-1-1 A rate type is allocated to just one division. _________________________________________________________
1-1-2 A rate type can be allocated to a billing class. The billing class is optional. _________________________________________________________
1-1-3 The rate type classifies a register for billing. _________________________________________________________
1-2 Check the definition of the rate type in the implementation guide.
1-2-1 Which menu path would you use to define a rate type? _________________________________________________________
1-2-2 To which division is rate type 1001 allocated? _________________________________________________________
1-2-3 At what master data levels can you define the rate type? _________________________________________________________ _________________________________________________________ _________________________________________________________
1-2-4 In addition to the classification and identification of different objects (such as registers), the rate type has an additional function. What is the most important task the rate type carries out? _________________________________________________________ _________________________________________________________
© SAP AG IUT230 3-90
1-2-5 You can limit the rate type permissibility. Name the different limitation options.
Permissibility Text
Can you allocate a rate type more than once to the permissibilities mentioned above? _________________________________________________________ _________________________________________________________
1-2-6 What control is stored behind the column CA? _________________________________________________________ _________________________________________________________
© SAP AG IUT230 3-91
Exercises
Unit: Billing Master Data Topic: Price
Find the price definition in the implementation guide.
Define a new price key for an energy price.
Adjust an existing price key.
New price keys have to be specified in the system to define the new rate. An existing price is adjusted to accommodate a price adjustment on January 1st.
2-1 Check the price definition in the implementation guide.
2-1-1 Which menu path would you use to define a price? _________________________________________________________
2-1-2 Which elements must you maintain before you can define a rental price? _________________________________________________________ In which master data object can you store a default value for determining the clearing price? _________________________________________________________ Can a clearing price also be defined as a flat rate? _________________________________________________________
2-1-3 Name 4 different price categories.
Price category Text
© SAP AG IUT230 3-92
2-1-4 Where can you store the prices and which master data objects can you use for this? _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________
2-2 Enter a new price using the following data. A price for billing kilowatt-hours in the electricity sector. Selection data Price PE1_1_1## Transaction currency USD Price category Quantity-dependent price Price type Standard price Header data Price text Energy price ## Billing class Residential customer Division Electricity Unit of measurement Kilowatt-hours
Historical data (tab page history) Valid from 01/01/1997 QTY base 1 Price amt 0,24
Do not fill in the valid to date, otherwise the price cannot be used in the future. Choose Save.
2-3 Maintain an existing price key by raising the price from January 1st of this year.
A price for billing kilowatt-hours in the electricity sector.
Selection data Price TE1_1_2## Price category Quantity-dependent price Select the currency USD and choose Currency Details.
Historical data (tab page history) Valid from 01.01. of this year Qty base 1 Price amt 0.28 Select save.
© SAP AG IUT230 3-93
2-4 True or false.
2-4-1 The decision as to whether the price is quantity or time-based is made using the price type. _________________________________________________________
2-4-2 A time-based price depends not only on a quantity, but also on a time period. _________________________________________________________
2-4-3 A price adjustment clause can only be used to add changes to a base price. _________________________________________________________
2-4-4 A price can also be specially defined for a selected installation. _________________________________________________________
2-4-5 Prices that have their origin in CRM can also be maintained in IS-U. _________________________________________________________
© SAP AG IUT230 3-94
© SAP AG IUT230 3-95
Exercises
Unit: Billing Master Data Topic: Operand
Describe the relationship between the operand category and operand.
Display an operand.
Certain operands have to be used to define new electricity rates. Suitable operands must be determined for variant programs.
3-1 Various discounts are needed to map the new rate.
3-1-1 Using the operand list, determine which operand categories are available in the system for mapping discounts and surcharges. ____________________________________________________________
3-1-2 Which operands are maintained in the system for the operand category quantity discount? ____________________________________________________________
3-2 Consumption is billed with a variant program by using the operands EQUANT___1 and EQPRICE__1.
3-2-1 Which operand category does the operand EQPRICE__1 belong to? ____________________________________________________________
3-2-2 How is quantity operand EQUANT___1 rounded off? ____________________________________________________________
3-3 The operand use is specified when the operand is created.
3-3-1 What are the four different uses you can choose? ____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
© SAP AG IUT230 3-96
© SAP AG IUT230 3-97
Exercises
Unit: Billing Master Data Topic: Variant Programs
Describe the relationship between operands and variant programs.
Find a variant program necessary for a billing step.
The online documentation helps you to understand variant programs.
Certain variant programs must be used to define the new rates. You have to determine suitable variant programs to calculate accordingly.
4-1 The new rate contains the determination of an average price.
4-1-1 Determine all variant programs in the system that use the input operand from operand category QUANT and AMOUNT and that deliver the output operand with the operand category QPRICE. ___________________________________________________________
4-1-2 How is the average price determined? For information, read the documentation on the variant program. ___________________________________________________________
4-1-3 Which variant program do you generally use to allocate a price to a quantity? ___________________________________________________________
4-2 Read the online documentation.
4-2-1 Select program QUANTI04 from the variant list.
4-2-2 Call the documentation for the program and read the information on the variant program function.
4-2-3 What input and output operand categories does the variant program require?
Input operand category Output operand category
1 1
2 2
© SAP AG IUT230 3-98
4-2-4 Does the variant also write bill line items relevant for posting?
___________________________________________________________ Which document line item types does the variant program create?
Document line type Description
4-2-5 What are settings can you make with the variant control? Explain the meaning of the different control features. ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________
4-2-6 What naming conventions are the variant programs subject to? ___________________________________________________________
© SAP AG IUT230 3-99
Exercises
Unit: Billing Master Data Topic: Rate
Find the definition of a rate in the implementation documentation.
Find and describe the components of a rate.
Create a new rate.
Create and change the facts of a rate.
The new contract contains a rate for billing an energy price according to which 60% of the consumption is billed with one price and the other 40% with another price.
5-1 Check the definition of the rate in the implementation guide.
5-1-1 Which menu path would you use to define a rate? ____________________________________________________________
5-2 Display the definition of rate TE1_1## in the system.
5-2-1 What do you control by using the Min.port. (minimum portion) field? Which value is used to extrapolate consumption when meter reading results are missing? ____________________________________________________________
5-2-2 How many and which variant programs are used in the rate? Go to the rate steps display to find out. ____________________________________________________________
5-2-3 Which output operand is used to determine the amount? ____________________________________________________________ How is this output operand updated? ____________________________________________________________
© SAP AG IUT230 3-100
5-3 Create a new rate using the following data.
5-3-1 A rate for billing electricity consumption.
Header data Rate PE1_1##
Data Division Electricity Text Rate ## Billing class Residential customer Permissibility Register license Min.Portion 60 % Val. class Check for residential customers Register operand EQUANT___1
Rate steps: 1. Write the info lines for the original consumption quantity. 2. Determine the 40% and 60% portions (you first store percentages 0.4 and 0.6 for the facts in the next exercise). 3. Valuate the 40% portion with an on-peak rate price. 4. Valuate the 60 % portion with an off-peak rate price.
Use the following processes: Debit energy price Credit energy price Extrapolation budget billing (debit) Extrapolation budget billing (credit)
Use the following operands: EQUANT___1 EQUANT___4 EQUANT___5 EQPRICE__1 EQPRICE__2 EAMOUNT__1 EAMOUNT__2 EFACTOR__1
© SAP AG IUT230 3-101
Exercises
Unit: Billing Master Data Topic: Facts
Describe the definition of a fact group.
Maintain the facts of a rate.
Find the different operand values at all hierarchy levels.
The new rate is valid for two different contract forms. These differ only in the portion of consumption quantity. In addition, special terms are agreed for a special business partner. The standard breakdown is 40% on-peak rate and 60% off-peak rate. The special business partner has 50% on-peak rate and 50% off-peak rate.
6-1 Check the definition of the fact group in the implementation guide.
6-1-1 Which fact group is maintained in the system for residential customers? ____________________________________________________________
6-1-2 With which element of the rate structure is the fact group always linked? ____________________________________________________________
6-2 Determine the individual factor for business partner TF0415A0##. Use the CIC to answer the following questions (from the SAP menu, select: Utilities Industry Customer Service Front Office/Customer Interaction Center
Customer Interaction Center)
6-2-1 In which master data object is the factor entered? ____________________________________________________________
6-2-2 Which factor is used for the business partner? ____________________________________________________________
6-2-3 What rate step is influenced by this factor? ____________________________________________________________
6-3 Maintain the facts for the rate that you created earlier.
6-3-1 Maintain all operands as necessary in the rate using the following:
Factor 0.4 Price 1 E1_1_1 Price 2 E1_2_1 EQUANT___4 Determination at runtime EQUANT___5 Determination at runtime
© SAP AG IUT230 3-102
6-3-2 What other replacement values can you name? ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________
© SAP AG IUT230 3-103
Exercises
Unit: Billing Master Data Topic: Schema / Rate Category
The online documentation helps you to understand schemas.
Create a new schema and a new rate category.
Determine and display the rates of a schema.
After all the necessary rates have been defined, they are brought together to form an overall billing design. by creating a new billing schema. This billing schema is entered in a new rate category as a standard schema.
7-1 Read the online documentation.
7-1-1 Select the menu path Define schemas using the implementation guide.
7-1-2 Access the documentation from the menu.
7-1-3 Read the information regarding prerequisites.
7-2 Create a new billing schema using the following data.
7-2-1 An electricity billing schema
Header data Schema PE1## Text Billing schema ## Division Electricity Billing class Residential customers
Rate From the previous exercise PE1_1## Presort key 1 0002 Presort key 2 0002
7-2-2 Display the operand list for your schema. How many operand categories do you use? ________________________________________________________
© SAP AG IUT230 3-104
7-2-3 Use your new schema to define a new rate category. Take the following information into account.
Rate category of the electricity division
Header data Rate category PE1## Division Electricity
Data Text Rate category ## Billing class Residential customer Outsorting group Residential customer Statistics group Residential customer Billing schema PE1## Backbilling No backbilling Period-end billing No period-end billing Facts Not required, values are taken from rates
© SAP AG IUT230 3-105
Exercises
Unit: Billing Master Data Topic: Rate Determination
Create a new rate determination.
Determine the billing master data used in the master data.
Derive the billing scheme used from the individual billing master data.
All the new billing components are brought together with the rate determination mechanism to be used in the system. All billing-relevant data in the system is determined for an existing business partner, for whom the new contract components are to be tested.
8-1 True or false?
8-1-1 Different rate type and rate category combinations can result in the same rate. ____________________________________________________________
8-1-2 You can set the rate determination to change on a certain date. ____________________________________________________________
8-1-3 You can only specify the rate type at device level. ____________________________________________________________
8-2 Create a new rate determination for your rate (PE1_1##) using the combination of your rate category (PE1##) and the rate type 1001.
8-2-1 Use January 1st of this year as the valid date. ____________________________________________________________
© SAP AG IUT230 3-106
8-2-2 A business partner (TF0502A0## ) already exists in the system with a rate. Determine all important billing master data for the business partner.
What rate category is entered? ____________________________________________________________
Which rate type is entered on the register of the built in meter? ____________________________________________________________
Which rate is determined with the rate determination for billing runtime? ____________________________________________________________
Which billing schema is linked to the rate category? ____________________________________________________________
8-2-3 Are special price keys which differ from the rate used for this business partner? ____________________________________________________________
8-3 Supply the application master data (TF0501A0##) with the billing master data that you have just created. Use the rate maintenance (EC30) to do this. Go to the SAP menu and select: Utilities Industry Customer Service Process Execution Rate Data Maintain Rate Data. Alternatively, you can call the rate maintenance screen from the CIC. To do this, identify the business partner in the CIC and select the installation in the navigation area. Use the secondary mouse button to open a context menu. Select rate maintenance.
8-3-1 Test your new rate using the billing analysis and use the data for business partner TF0501A0##.
____________________________________________________________
8-3-2 What alternatives are available for rate maintenance. ____________________________________________________________ ____________________________________________________________ What are the disadvantages of selecting these alternatives? ____________________________________________________________ ____________________________________________________________
© SAP AG IUT230 3-107
Exercises
Unit: Billing Master Data Topic: Billing Master Data and Rate Determination
To completely create the billing master data, define a rate determination and to connect the billing rule with the IS-U master data.
Derive the billing scheme used from the individual billing master data.
To interpret the billing documents and check the billing master data
All the new billing components are brought together with the rate determination mechanism to be used in the system. All billing-relevant data in the system is determined for an existing business partner, for whom the new contract components are to be tested.
9-1 To clarify how all the billing master data interacts, you can do the following exercise: Create a completely new rate construct with all the required billing master data. Base your data on the contract text in Unit 3. Proceed in the same order as described in Unit 3. You do not have to create operands and prices. They exist already.
9-1-1 Create two new rates (on-peak rate and off-peak rate) using the following:
Header data Rate (on-peak rate) PE2_1## Rate (off-peak rate) PE2_2##
Data Division Electricity Text (on-peak rate) On-peak rate ## Text (off-peak rate) Off-peak rate ## Register operand (on-peak rate) EQUANT___1 Register operand (off-peak rate) EQUANT___2
Rate steps (on-peak rate): 1. Valuate the on-peak rate quantity with a quantity-based price (energy
price)
2. Calculate a fixed demand price (basic flat-rate price)
3. Valuate the on-peak rate quantity with a quantity-based price (maximum price).
4. Compare the amount operand from steps 1, 2, and 3. Set a maximum price limitation.
5. Calculate a rental price based on the size of the meter.
© SAP AG IUT230 3-108
Rate steps (off-peak rate): 1. Valuate the off-peak rate quantity with a quantity-based price (energy
price)
9-1-2 Maintain the facts for both rates. Supply the operands with values. Use the existing price key.
9-1-3 Create a new billing schema using the following data. Apply the rates you created earlier.
Header data Schema PE2## Rates PE2_1## and PE2_2##
9-1-4 Enter a new rate category using the following:
Header data Rate category PE2## Schema PE2##
9-1-5 Create a rate determination for your new rates (PE2_1## and PE2_2##) and your new rate category (PE2##) and rate types 1001 / 1002. Use January 1st of this year as the valid date.
9-1-6 Test your rate using the data construct TF0503A0##. Check also that both billing rules are used correctly (depending on consumption). Choose a simulation from 01.01.yyyy to 31.12.yyyy (yyyy = current year).
© SAP AG IUT230 3-109
Solutions
Unit: Billing Master Data Topic: Rate Type
1-1 Check the implementation guide (SAP Reference IMG) for information regarding rate types and answer the following questions. From the SAP menu, choose Tools
Customizing IMG Edit Project. Call up the SAP Reference IMG.
True or false:
1-1-1 A rate type is allocated to just one division.
True 1-1-2 A rate type can be allocated to a billing class. The billing class is optional.
True 1-1-3 The rate type classifies a register for billing.
True 1-2 Check the definition of the rate type in the implementation guide.
1-2-1 Which menu path would you use to define a rate type?
In the SAP Reference IMG, choose: SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Types.
1-2-2 To which division is rate type 1001 allocated?
Electricity 1-2-3 At what master data levels can you define the rate type?
1) Installation structure: At device or register level 2) Facts: In the installation facts rate category facts
1-2-4 In addition to the classification and identification of different objects (such as registers), the rate type has an additional function. What is the most important task the rate type carries out? In addition to the rate category, the rate type defines the billing rule (rate) that is found. This kind of indirect rate allocation using a rate type has advantages if, for example, you want to change a rate: You only have to enter a new rate category in the utility installations in question, and then expand the rate determination. You do not have to make extensive changes to the rate types of every individual register for the utility installations that are affected.
© SAP AG IUT230 3-110
1-2-5 You can limit the rate type permissibility. Name the different limitation options.
Permissibility Text
R Registers
D devices
F Facts
PIM Interval meter
PE Period-end billing
WB Waste billing
In rate determination, you can only combine rate types and rates that have the same permissibility or use. Can you allocate a rate type more than once to the permissibilities mentioned above?
No You can only select one permissibility.
1-2-6 What control is stored behind the column CA? This is the indicator: Ignore contract allocation of register during extrapolation You can only use this indicator for rate types that are permitted for registers. It influences the analysis of contract allocation when registers are extrapolated. Example: A register is installed for billing in two utility installations. Both utility installations have a rate type where the indicator is not set. One installation has been allocated a contract and the other has not. Outcome: During extrapolation, the system calculates a consumption larger than zero for the register.
© SAP AG IUT230 3-111
Solutions
Unit: Billing Master Data Topic: Price
2-1 Check the price definition in the implementation guide.
2-1-1 Which menu path would you use to define a price?
In the SAP Reference IMG, choose: SAP Utilities Contract Billing Billing Master Data Rate Structure Prices Define Prices.
2-1-2 Which elements must you maintain before you can define a rental price? Price classes and price levels
In which master data object can you store a default value for determining the clearing price? In the device category. From the SAP menu, select Utilities Industry Device Management Technology Device Category Display. Display device category TD-SRA-00. The price class is stored in the General Data group box. Can a rental price also be defined as a flat rate? Yes. In this case, however, you do not have dynamic rental price determination. Normally, this is executed automatically by the variant program SETTLE01.
2-1-3 Name 4 different price categories.
Price category Text
1 Quantity-based price
2 Flat Rate
3 Rental price
4 Time-based price
2-1-4 Where can you store the prices and which master data objects can you use for this? You can save prices in the facts. You maintain these facts at rate, rate category and/or installation level.
© SAP AG IUT230 3-112
2-2 Enter a new price using the following data.
A price for billing kilowatt-hours in the electricity sector.
In the SAP Reference IMG, choose: SAP Utilities Contract Billing Billing Master Data Rate Structure Prices Define Prices Create Prices.
Maintain the field contents in the data screen as described in the exercise and save.
2-3 Maintain an existing price key by raising the price from January 1st of this year.
A price for billing kilowatt-hours in the electricity sector.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Prices Define Prices Change Prices.
In the initial screen, enter the price key TE1_1_2##.
Maintain the field contents in the data screen as described in the exercise and save.
2-4 True or false.
2-4-1 The decision as to whether the price is quantity or time-based is made using the price type.
False 2-4-2 A time-based price depends not only on a quantity, but also on a time
period.
True 2-4-3 A price adjustment clause can only be used to add changes to a base price.
False 2-4-4 A price can also be specially defined for a selected installation.
Correct Select the tab page Header Data 2. Enter the installation number for the price. If you try and allocate this price to another installation, the process is terminated and an error message is issued.
2-4-5 Prices that have their origin in CRM can also be maintained in IS-U. False These prices come from the CRM price calculation. Prices can only be changed there and copied to the IS-U system.
© SAP AG IUT230 3-113
Solutions
Unit: Billing Master Data Topic: Operand
3-1 Various discounts are needed to map the new rate for the electricity division.
3-1-1 Using the operand list, determine which operand categories are available in the system for mapping discounts and surcharges.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands
Display Operand.
Choose the List of operands button.
Select the possible entries button for the Operand category field.
This contains the following operand categories ADISCABS ADISCPER DDISCNT PDISCNT QDISCNT
3-1-2 Which operands are maintained in the system for the operand category quantity discount?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands
Display Operand.
Choose the List of operands button.
Enter QDISCNT in the operand category field. Choose Execute.
This contains the following operands: EQDISCNT_1 GQDISCNT_1 WQDISCNT_1
© SAP AG IUT230 3-114
3-2 Consumption is billed with a variant program by using the operands EQUANT___1 and EQPRICE__1.
3-2-1 Which operand category does the operand EQPRICE__1 belong to?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands
Display Operand.
In the initial screen, enter the operand EQPRICE__1.
Operand category: QPRICE 3-2-2 How is quantity operand EQUANT___1 rounded off?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Operands Define Operands
Display Operands .
In the initial screen, enter the operand EQUANT__1.
Rounding: 0 to whole numbers Rounding type: X round up or down to nearest whole number
3-3 The operand use is specified when the operand is created.
3-3-1 What are the four different uses you can choose? The operand is supplied with values from the rate, rate category, and installation facts. The value can also be determined as a result of different calculation steps in the rate. Register: This use can only be selected for operands with the category QUANT and DEMAND. The indicator specifies how operands are used in the facts:: - In the rate header, only operands that have the indicator set can be used as register operands - In the rate steps, you can only use operands when the indicator is not set, or when the operand is identical to the register operand from the rate header. Total history These operands can only be processed by special variants. RTP operand: RTP-Operands are used in RTP rates to copy the results of the RTP interface assigned to the RTP rate.
© SAP AG IUT230 3-115
Solutions
Unit: Billing Master Data Topic: Variant Programs
4-1 The new rate contains the determination of an average price.
4-1-1 Determine all variant programs in the system that use the input operand from operand category QUANT and AMOUNT and that deliver the output operand with the operand category QPRICE.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Analyze Variant Programs.
Enter the value QUANT in the first input operand category field, AMOUNT in the second input operand category field, and QPRICE in the first output operand category field.
Choose Execute.
You find, for example, the QUANTI06 variant program 4-1-2 How is the average price determined?
The ratio from the amount and the quantity is mapped. The result is updated in the output operand.
4-1-3 Which variant program do you generally use to allocate a price to a quantity?
The QUANTI01 variant. If the second input operand (category) QPRICE is the average price, then the QUANTI06 variant (output operand) must be used in an earlier rate step to determine this operand value.
4-2 Read the online documentation.
4-2-1 Select program QUANTI04 from the variant list.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Analyze Variant Programs.
Enter the value QUANTI04 in the Variant Program field. Choose Execute. You find the list with variant program QUANTI04. Select and display the variant program.
4-2-2 Call the documentation for the program and read the information on the variant program function.
Select Documentation.
© SAP AG IUT230 3-116
4-2-3 What input and output operand categories does the variant program require?
Input operand category Output operand category
QUANT QUANT (quantity maintained based on the factor)
FACTOR QUANT (remaining quantity)
4-2-4 Does the variant also write bill line items relevant for posting?
No. In the General Data box, the field Line Item Rel. to Post. is not selected. Which document line item types does the variant program create?
Document line type Description
IQUANT Quantities (meter readings)
IT008 Breakdown of consumption values
4-2-5 What are settings can you make with the variant control? Explain the meaning of the different control features. Info lines written about quantity Info lines written on breakdown Values added during update Values overwritten during update You use the variant control to specify how much detail is in the information that you need, for example, for bill printout. If you do not include the information line item written about quantity, you cannot print the data and quantities on the bill (for example, date of old and new meter reading). The update has more meaning if you have used the output operands from the billing schema in a rate, before the variant is executed. Values in this operand are added or overwritten by the result of the calculation step.
4-2-6 What naming conventions are the variant programs subject to? All variant programs are ABAP/4 function modules, which you can process using the function builder. The naming convention is: ISU_variant program name (e.g. ISU_QUANTI04)
© SAP AG IUT230 3-117
Solutions
Unit: Billing Master Data Topic: Rate
5-1 Check the definition of the rate in the implementation guide.
5-1-1 Which menu path would you use to define a rate?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Create Rates/Change Rates/Display Rates.
5-2 Display the definition of rate TE1_1## in the system.
5-2-1 What do you control by using the Min.port. (minimum portion) field? Which value is used for extrapolation when meter reading results are missing?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Display Rates.
In the initial screen, enter the rate TE1_1_2##.
Register-based data, Min.port.: 60 %
This field is used to determine periods in which meter reading results must be available for the system to be able to extrapolate. If there are no meter reading results, the system uses the period consumption.
5-2-2 How many and which variant programs are used in the rate? Go to the rate steps display to find out.
Select Rate Steps.
Number of variant programs : 4
Variant programs: QUANTI01 LUMSUM01 REFVAL01 SETTLE01
© SAP AG IUT230 3-118
5-2-3 Which output operand is used to determine the amount?
Scroll right in the rate steps display.
Output operand 1: EAMOUNT__1
In this case, the output operand has no other function, as it is not used as an input operand for any subsequent variant programs. The output operand is automatically added during the update since an explicit variant control does not exist in any variants for updating.
5-3 Create a new rate using the following data.
5-3-1 A rate for billing electricity consumption.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Create Rates.
In the initial screen, enter the rate PE1_1##.
Maintain the field content as described in the exercise.
Select Rate Steps.
Maintain the field content in the Rate Steps as described in the exercise and save.
Variant programs: QUANTI05 QUANTI04 QUANTI01 ( twice )
Processes: Debit energy charge 0021 Credit energy charge 0011 Extrapolation budget billing 0120 Extrapolation budget billing 0110
© SAP AG IUT230 3-119
Solutions
Unit: Billing Master Data Topic: Facts
6-1 Check the definition of the fact group in the implementation guide.
6-1-1 Which fact group is maintained in the system for residential customers?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rate Fact Groups.
Rate fact group: 0001 Residential customers
6-1-2 With which element of the rate structure is the fact group linked?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rate Fact Groups.
Highlight the menu entry. Select Documentation by clicking on the menu entry.
Linked element: Rate type
6-2 Determine the factor for the consumption breakdown for the business partner TF0415A0##
6-2-1 In which master data object is the factor entered?
From the SAP menu, choose: Utilities Industry Customer Service Front Office/Customer Interaction Center Customer Interaction Center
Enter the business partner's number TF0415A0## in the Business partner field group and press Enter. In the navigation area (Environment tab page), select the installation and call up the installation display (double-click the installation data object). Call up the facts display.
6-2-2 Which factor is used for the business partner?
Select the operand EFACTOR__1 Operand value: EFACTOR__1 0,5
6-2-3 What rate step is influenced by this factor? Return to the installation display. Select Billing View. The rate found for billing the installation is displayed on the rate tab page.. Click on the rate to go to the rate display screen. Select Rate Steps. The operand EFACTOR__1 is used in the variant LUMSUM01 as a second input operand, A flat-rate price is halved.
© SAP AG IUT230 3-120
6-3 Maintain the facts for the rate that you created earlier.
6-3-1 Maintain all the necessary operands in your rate.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Change Rates.
Enter the rate number PE1_1## in the initial screen. Select Facts. Select operand EQPRICE__1. Select Create operand values. Maintain the contents in the data screen as described in the exercise and save.
6-3-2 What other replacement values can you name?
Normal operand value: If this indicator is set, a replacement value is not used for the operand. As a result, an operand value must be entered. Optional value: If you enter this replacement value for an operand, the operand is proposed for maintenance in all installations that are allocated the rate category/rate. A value must not be entered for this operand in the installation facts. Mandatory value: If you enter this replacement value for an operand, the operand is proposed for maintenance in all installations that are allocated the rate category/rate. A value must be entered for this operand in the installation facts. Runtime: This replacement value must be entered when the operand is updated in subsequent rate steps as the output operand of a rate step.
© SAP AG IUT230 3-121
Solutions
Unit: Billing Master Data Topic: Schema / Rate Category
7-1 Read the online documentation.
7-1-1 Select the menu path Define schemas using the implementation guide.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas.
7-1-2 Access the documentation from the menu.
Choose Define schemas. 7-1-3 Read the information regarding prerequisites.
7-2 Create a new billing schema using the following data.
7-2-1 An electricity billing schema
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas Create Schemas.
Enter the name of the schema (PE1## ) in the Billing schema field. Maintain the contents as described in the exercise. Select the Set default values icon. Select Insert rate and select the rate PE1_1##. Save.
7-2-2 Display the operand list for your schema. How many operand categories do you use?
Select Goto Overview List of Operands.
Operand categories : 3
Operand categories : QUANT QPRICE FACTOR
© SAP AG IUT230 3-122
7-2-3 Use your new schema to define a new rate category. Take the following information into account.
Rate category of the electricity division
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rate Categories Define Rate Categories Create Rate Categories.
In the initial screen, enter the key PE1## in the Rate cat. field, and 01 in the Division field.
Maintain the contents in the data screen as described in the exercise and save.
© SAP AG IUT230 3-123
Solutions
Unit: Use of Rates in the Master Data Topic: Rate Determination
8-1 True or false?
8-1-1 Different rate type and rate category combinations can result in the same rate.
True 8-1-2 You can set the rate determination to change on a certain date.
True 8-1-3 You can only specify the rate type at device level.
False
8-2 Create a new rate determination for your rate (PE1_1##) from the combination of your rate category (PE1##) and the rate type 1001.
8-2-1 Use January 1st of this year as the valid date.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Determination.
Enter the rate type and category as described in the exercise and save.
8-2-2 A business partner (TF0502A0## ) already exists in the system with a rate. Determine all the business partner’s billing components used in the master data.
Which rate category is entered at installation level?
From the SAP menu, choose Utilities Industry � Technical Master Data Installation Display.
Enter the installation number TF0502A0## in the initial screen.
Rate category: E1
© SAP AG IUT230 3-124
Which rate type is entered on the register of the built in meter?
Goto Device - rate data
Rate type: 1001
Which rate is determined with the rate determination for billing runtime?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Determination.
Select the rate determination list. Choose Execute.
Rate: E1_1
Which billing schema is linked to the rate category?
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rate Categories Define Rate Categories Display Rate Categories.
Enter the rate category E1 in the initial screen.
Billing schema: E1
8-2-3 Are special price keys which differ from the rate used for this business partner?
From the SAP menu, choose Utilities Industry Technical Master Data Installation Display.
Enter the installation number TF0502A0## in the initial screen.
Select the installation facts.
No facts are available. No special price is used.
8-3 Go to the SAP menu and select: Utilities Industry Customer Service Process Execution Rate Data Maintain Rate Data.
8-3-1 Test your new rate using the billing analysis and use the data for business partner TF0501A0##. Adjust the data (rate category in the installation) of business partner TF0501A0##. Note the key date (01.01.yyyy, yyyy is the current year) and select prorate. Change the rate category.
From the SAP menu, choose Utilities Industry Billing Billing Execution Billing Analysis to test your rate. Execute a simulation for your installation from 01.01.yyyy to the present day and analyze the billing document once billing has been successfully completed (green traffic light). The quantity breakdown must be calculated in connection with your factor.
© SAP AG IUT230 3-125
8-3-2 What alternatives are available for rate maintenance. You can also change the rate category using the transaction for changing the installation. Go to the SAP Menu and choose Utilities Industry Technical Master Data Installation Change. You can change the rate data of the installation structure from the SAP menu by selecting Utilities Industry Device Management Installation Installation Structure Rate Data Change. The rate maintenance (transaction EC30) enables you to maintain the installation rate category and the rate data from the installation structure in a dialog step. When you select alternatives, you can either change just the rate category (change installation – ES31) or just the installation structure data (EG70).
© SAP AG IUT230 3-126
© SAP AG IUT230 3-127
Solutions
Unit: Billing Master Data Topic: Billing Master Data and Rate Determination
9-1 To clarify how all the billing master data interacts, you can do the following exercise: Create a completely new rate construct with all the required billing master data. Base your data on the contract text in Unit 3. Proceed in the same order as described in Unit 3. You do not have to create operands and prices. They exist already.
9-1-1 Create two new rates (on-peak rate and off-peak rate) using the following.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Mater Data Rate Structure Rates Define Rates Create Rates.
Enter the rate PE2_1## and PE2_2## in the initial screen (execute twice).
Maintain the field content as described in the exercise. Select Rate Steps. Maintain the field content in the Rate Steps as described in the exercise and save.
Variant programs: PE2_1## QUANTI01 (energy price) LUMSUM01 (fixed basic price) QUANTI01 (maximum price) UTILIT02 (maximum price limitation) SETTLE01 (rental price)
Variant programs: PE2_2## QUANTI01 (energy price) 9-1-2 Maintain the facts for both rates. Supply the operands with values. Use the
existing price key.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Mater Data Rate Structure Rates Define Rates Create/Change Rates.
You can also create and maintain facts directly from the rates transaction. Select Facts. Select Create Operand Values. Maintain the contents in the data screen as described in the exercise and save.
9-1-3 Create a new billing schema using the following data. Apply the rates you created earlier.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas � Create Schemas.
Enter the name of the schema (PE2## ) in the Billing schema field.
© SAP AG IUT230 3-128
Maintain the contents as described in the exercise. Select Insert Rate (twice) and choose the rates PE2_1## and PE2_2##.
After inserting the two rates, you must maintain the deletion operands. You can let the system propose deletion operands by checking the Propose deletion operands field in the default values.
Save. 9-1-4 Enter a new rate category using the following:
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Rate Categories Define Rate Categories Create Rate Categories.
In the initial screen, enter the key PE2## in the Rate cat. field, and 01 in the Division field.
Maintain the contents in the data screen as described in the exercise and save.
9-1-5 Create a rate determination for your new rates (PE2_1## and PE2_2##) and your new rate category (PE2##) and rate types 1001 / 1002. Use January 1st of this year as the valid date.
In the SAP Reference IMG, choose SAP Utilities Contract Billing Billing Master Data Rate Structure Define Rate Determination.
Enter the rate type and rate category in the initial and data screens as described in the exercise and save.
9-1-6 Adjust the billing master data for business partner TF0503A0## using the rate maintenance transaction (EC30). Test it using billing analysis (EA00). Do not be confused if you find an installation with a single-rate meter. In this context, viewing the on-peak rate (with the highest price) is very important. If necessary, adjust the period consumption (EC30 or EL56) of your meter in order to trigger an alternative calculation. You can also use EL28 to enter a current meter reading.
© SAP AG IUT230 4-1
SAP AG 2006SAP AG 2006
Discount and Surcharge Options
Master Data
Effects on the Rate Structure
Discounts/Surcharges
© SAP AG IUT230 4-2
SAP AG 2006
Discounts/Surcharges: Unit Objectives
At the conclusion of this unit, you will be able to:
Describe the discount and surcharge options
Explain the general and specific master data for discounts
Explain the effect on the rate structure
SAP AG 2006
© SAP AG IUT230 4-3
SAP AG 2008
Reference Basis:- Amount Discount- Price Discount- Quantity Discount- Demand Discount
Reference Basis:- Amount Discount- Price Discount- Quantity Discount- Demand Discount
Discount Type:- Fixed Value- Percentage
Discount Type:- Fixed Value- Percentage
Discounts/surchargesDiscounts/surcharges
Discount and Surcharge Options in SAP Utilities
% + - exp
10% Community Discount on Final Amount
500 kWh Quantity Discount
3% Price Discount
2% Transformation Loss (Surcharge)
A discount or surcharge can refer to the following objects: amounts, prices, quantities, or demands.
A discount or surcharge can be either absolute or a percentage.
A discount or surcharge has to have a suitable operand so that this can be taken care of in the facts with the values.
A suitable variant program must exist in the rate for all discounts and surcharges, apart from the register discount.
© SAP AG IUT230 4-4
SAP AG 2006
General Data Individual Data
Discount/Surcharge
Rate Facts
Rate Category Facts
Installation Facts
Installation StructureRegister Discount
Master Data for Discounts and Surcharges
A discount/surcharge key can be stored in the master data objects above, depending upon the use of the discount/surcharge.
© SAP AG IUT230 4-5
SAP AG 2008
Entry of New Variant Programs:
DISCNT01 - Qty discount
DISCNT02 - Demand Discount
DISCNT03 - Qty-Based Price
DISCNT04 - ...
DISCNT05 - ...
DISCNT06 - ...
DISCNT07 - Amount Disc. (Perc.)
DISCNT08 - Amount Disc. (Fix.)
Rate StepsRate Steps
DiscountRate FactsRate Facts
Effects on the Rate Structure
After the discount/surcharge key has been defined, the appropriate variant programs must be entered in the rate steps.
The operands are given discount/surcharge keys in the rate facts.
Variant programs do not have to be entered for register discounts. These are the only exception.
Quantity, price, and demant discount variants must be positioned before the evaluation variants.
Amount discount variants are always used after the evaluation variants.
© SAP AG IUT230 4-6
SAP AG 2006
Discounts/Surcharges: Unit Summary
SAP AG
Discounts and surcharges can apply to prices, quantities, demands, and amounts.
Discounts/surcharges can be calculated as a fixed value or a percentage.
Discounts/surcharges can be allocated to rate facts, rate category facts, and installation facts. A register discount can also be entered in the installation structure.
The discount or surcharge variants must be included in the rate steps.
© SAP AG IUT230 4-7
Exercises
Unit: Discounts/Surcharges Topic: Discounts
Maintain a new discount/surcharge in the system.
Assign a discount to a business partner.
Your company has agreed to grant a customer a percentage discount on the energy price. The discount is entered in the customer services department and assigned to the business partner.
1-1 The business partner TF1001A0## is granted a discount on the energy price.
1-1-1 Create a new discount key in the system using the following information.
Header data Discount PE1## Valid from 1. January of this year Transaction currency USD Reference basis Price discount Discount type Percentage
Data Text Discount ## Division Electricity Billing class Residential customer Discount category Discount Percentage 10
1-1-2 To process the discount key you just created, you must include a new rate. Use rate E1_1 as a template and create new rate PE3_1##. In the first step, a discount of 10% applies to the on-peak rate energy price (quantity-based price) with this discount key in this rate. You need to include a suitable variant program in the rate.
1-1-3 However, the discount is not to be valid for all customers with this rate. It is only used 365 days after the contract first began. Include other variant programs and operands in the rate.
1-1-4 Once you have created the rate, you must create a new schema PE3##, a new rate category PE3## and the rate determination.
1-1-5 In the next step, you want to test this discount. Therefore allocate the new rate category to business partner TF1001A0## with installation TF1001A0##. Use the rate maintenance (transaction EC30) to do this.
© SAP AG IUT230 4-8
© SAP AG IUT230 4-9
Solutions
Unit: Discounts/Surcharges Topic: Discounts
1-1 The business partner TF1001A0## is granted a discount on the energy price.
1-1-1 Create a new discount key in the system using the following information.
From the SAP menu, choose: Utilities Industry Billing Master Data Define Discounts/Surcharges Create Discounts/Surcharges.
Enter your data as specified in the exercise and save. 1-1-2 In order to process the discount key that you have just created, you must
include a new rate. Use the rate E1_1 as a template and create the new rate PE3_1##. A discount of 10% applies to the on-peak rate energy price (quantity-based price) with this discount key in this rate. You need to enter a suitable variant program in the rate.
From the SAP Reference IMG, choose:
SAP Utilities Contract Billing Billing Master Data Rate Structure Rates Define Rates Create Rates.
In the initial screen enter rate PE3_1##, and rate E1_1 as the template.
Maintain the field content as described in the exercise.
Select Rate Steps.
Maintain the field content in the Rate Steps as described in the exercise and save.
Variant program: DISCNT03
Note that variant programs that calculate discounts based on prices must always be listed before the price key, to which the discount applies in the rate. In comparison, discount variants that refer to amounts are always listed after the amounts to which the discount applies.
© SAP AG IUT230 4-10
1-1-3 However, the discount is not to be valid for all customers with this rate. It is only used 365 days after the contract first began. Include other variant programs and operands in the rate.
In the first step, you determine the number of days since the contract began. Use variant program COMPUT20 to do this. Create separate operands for the variant program. You must now check the calculated days against the days (365 here) fixed in the contract text. Use variant IF03 to do this. If the condition has been fulfilled, use DISCNT03 to calculate the discount. If the condition has not been fulfilled, a normal evaluation takes place with the undiscounted quantity-based price. Here is the sequence of the necessary variant programs: COMPUT20 IF03 DISCNT03 ENDIF QUANTI01
... Include the required facts to complete your rate.
1-1-4 Once you have created the rate, you must create a new schema PE3##, a new rate category PE3## and the rate determination.
From the SAP Reference IMG, choose:
SAP Utilities Contract Billing Billing Master Data Rate Structure Schemas Define Schemas Create Schemas.
Enter the name of the schema in the Billing schema field (PE3##), and enter the data as specified in the exercise.
1-1-5 In the next step, you want to test this discount. Therefore allocate the new rate category to business partner TF1001A0## with installation TF1001A0##.
From the SAP menu, choose: Utilities Industry Customer Service Process Execution Rate Data
Maintain Rate Data. Enter installation number TF1001A0## in the initial screen and change the rate category. Note the proration date. The new rate category can only be allocated in a period that is not prorated and the allocation date should come after the validity date of your rate and rate determination. Go to the billing analysis (EA00) and test your discount.
© SAP AG IUT230 5-1
SAP AG 2008
Billing
SAP AG 2007
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
© SAP AG IUT230 5-2
SAP AG 2006
Billing: Unit Objectives
SAP AG 2006
At the conclusion of this unit, you will be able to:
Explain the data elements of the billing process
Describe billing functions
Understand the billing process
Perform a billing simulation
Understand the concept of outsorting
Perform billing reversal
Describe the concept of parallel processing
© SAP AG IUT230 5-3
SAP AG 2006
MRorder
Billingorder
InvoicingInvoicingMeter readingorder creationMeter readingorder creation
Meter readingdata entry
Meter readingdata entry
BillingBilling
Billingdocument
Implausible MR results
Plausible MR results
Billingorder
Print document
Billprintout
Billprintout
The Bill Creation Process
Correction ofMR results
© SAP AG IUT230 5-4
SAP AG 2006
Billing: 1
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
© SAP AG IUT230 5-5
SAP AG 2006
MO TU WE TH FR SA SU18
152128
29
162229
310172330
411182431
5121925
6132026
7142127
Length of period for periodic billingn days; 1, 2, 3, 4, 6, or 12 months
Length of period for period-end billingn + n days; 1, 2, 3, 4, 6, or 12 months
To-the-day billingBased on the date of the meter reading
Month-based billingDependent on key date
Month-based billingDependent on intervals
Billing Periods
The billing period for which the utility bills the customer can be determined in a number of ways. These are:
For an exact number of days Determines the exact length of the billing period in days, for example the period between the last billed meter reading and the current day of meter reading.
Month-based Bills a specific number of complete months. If the case of a move-in or move-out, the month-based procedure can be billed based on the number of days.
© SAP AG IUT230 5-6
SAP AG 2008
Schedule Master Records: Portions
PortionsGroup contracts that are to be billed together
Contain schedule master records for billing
A utility contract is allocated to a portion in one of two ways:
Indirectly via the meter reading units defined in the installation that corresponds to the contract
Directly in the contract
The portion controls billing orders.
You can bill for an entire portion, for all contracts allocated to a portion. Allocation is usually carried out with the meter reading unit in the installation. In certain cases, the portion can be overridden in the contract.
Several portions can be entered for one billing district to enable parallel background processing on different systems/computers.
© SAP AG IUT230 5-7
SAP AG 2006
Schedule Master Records: Meter Reading Units
Group utility installations that are in the same region and that should be read by a certain date
Contain all data (schedule master records) relevant to meter reading scheduling
Can only be created if a portion already exists
Several meter reading units can be allocated to the same portion
Are the basis for meter reading
Meter reading units can be seen as a day's work for a meter reader, but could also refer to a larger meter reading/work list.
© SAP AG IUT230 5-8
SAP AG 2006
PortionP_AUG01Portion
P_AUG01
MR unitA_AUG01MR unit
A_AUG01
P1P1Parameter recordParameter record
Schedule masterrecords
A_AUG01 2007A_AUG01 2007
A_AUG01 2006A_AUG01 2006
A_AUG01 2005A_AUG01 2005
MR unitMR unit
Schedulerecords
P_AUG01 2007P_AUG01 2007
P_AUG01 2006P_AUG01 2006
P_AUG01 2005P_AUG01 2005PortionPortion
Generation of
schedulerecords
Generation of
schedulerecords
Generation of Schedule Records
Schedule records can be generated for portions and meter reading units separately, or they can be generated together for all meter reading units of a portion.
When you generate the schedule records, you must specify the time period for which the dates are required.
You can easily check the generated schedule records (meter reading and billing dates, due dates, etc.) by choosing Schedule record => Analysis. This function can be performed for several portions or meter reading units at the same time.
The description of the portions and meter reading units must match the selection options.
If the dates in the schedule master records are changed, the existing schedule records can be regenerated.
© SAP AG IUT230 5-9
SAP AG 2006
Scheduling: Annual Billing
20062006Portion 127.7. 28.7. 29.7. 30.7. 31.7. 1.8. 2.8. 3.8.
Portion 127.7. 28.7. 29.7. 30.7. 31.7. 1.8. 2.8. 3.8.
20072007
Portion 127.7. 28.7. 29.7. 30.7. 31.7. 1.8. 2.8. 3.8.
Sched.MRDate
Billing period
Meter reading period for meter reading unit 1
Meter reading period for meter reading unit 2
Meter reading period for meter reading unit 3
For all meter reading units
End of MR Period
EndofBillingPeriod
Planned Billing Date
Meter ReadingBilling
Meter ReadingBilling
End of billing period: This is the date on which the portion is to be billed for the first time. This date, together with the length of the billing period (that is, the period length) determines the date of the next billing.
Scheduled billing date:
Date on which billing is to begin for the contracts that belong to a portion.
When the schedule record is generated, this date is calculated by subtracting the number of days between the end of the billing period and the scheduled billing date for the schedule master record from the end date of the billing period for the schedule record.
This takes the SAP calendar into account.
End of meter reading period: Used as the basic date for determining the schedules for the further meter reading periods. The date must not be after the end of the billing period for the item allocated.
Scheduled meter-reading date: Date on which the meter reading unit can be read for the first time (is maintained in the meter reading unit under schedule record interval: meter reading to meter reading period end)
© SAP AG IUT230 5-10
SAP AG 2006
Data for the Meter Reading Order
MR Order
Time-Dependent Data
Data Environment
• Entry number• Check number• Meter reading reason• Scheduled meter reading• Meter reader• Meter reading status• Control group• MDE number
Meter Reading Data
Entry-Specific Data
• Expected meter reading• Expected consumption• Upper limit of meter reading
• Scheduled meter reading date• Scheduled billing date
The entry number is used in fast entry to identify a meter reading order.
The check number is specified for each register and checks if the meter reading results are complete.
Meter reading status such as:
order created
billable
automatically locked
released by agent
The control group controls the meter reading order creation for time variable registers. For example, a register that is read annually but the maximum demand of which is determined monthly. When this is the case, the system prints twelve columns for the demand values. You specify control groups in Customizing.
The MDE (Mobile Data Entry) number is the number of the PC onto which the meter reading data is downloaded. This controls how the order is issued.
The expected meter reading/consumption, which can be projected from the historical values, can be downloaded onto the MDE devices where the meter reading checks can be carried out.
© SAP AG IUT230 5-11
SAP AG 2006
Billing Order
Is created in addition to the meter reading order if a meter reading is relevant to billing (periodic meter reading, for example)
Is a prerequisite for billing
Contains data for billing, for example:Scheduled billing date
Portion
Installation
The billing order is used as a billing index.
The billing order reduces the program runtime because only billing orders which are actually billable are processed.
Once the contract/installation has been successfully billed, the billing order is deleted.
© SAP AG IUT230 5-12
SAP AG 2006
Billing Order
Effects on the billing orderEffects on the billing orderActionsActions
Meter reading order creation
Entry of meter-reading results
Billing
Billing reversal
Status 1 = Cannot be billed
Status 2 = Can be billed
Billing order is deleted
Billing order is restored
Billing Order Status
The activities described in the upper left have certain effects on the billing order. The billing order is actually an index for billing. It is used for tracking the status and improving performance.
© SAP AG IUT230 5-13
SAP AG 2006
Which devices did weread last week on Schiller
Street?
Monitoring
Monitoring of:Schedule records
Meter reading orders
Billing orders
Meter reading results
Information on, for example:Meter reading
Status
Meter reading reason
Scheduled billing date, scheduled meter reading date
Monitoring enables the current meter readings and billings to be tracked. You can, for example, establish in which meter reading units the readings are not complete. Follow-up activities can be triggered, such as a mass estimation run.
Monitoring can also be used to analyze non-billable contracts.
© SAP AG IUT230 5-14
SAP AG 2006
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
Billing: 2
© SAP AG IUT230 5-15
SAP AG 2006
Billing Tasks
Standard process that processes billing orders, creates billing documents for each contract, and transfers information to invoicing
Determination of billing periods
Determination of rate data
Quantity conversion
Proration
Execution of variant programs
Creation of billing documents with billing line items
The billing document forms the base for the communication structure (UIS - Sales Statistics)
© SAP AG IUT230 5-16
SAP AG 2008
BillingBilling InvoicingInvoicing
Billing documents with billing line items
Communication structure for sales statistics
Posting documents for contract accounts receivable and payable
Print documents for bill printout
Budget billing plans
Differentiating Billing from Invoicing
In SAP Utilities, the billing process includes billing and invoicing.
In billing, a billing document is created for each contract.
The billing document also forms the basis for the communication structure. The communication structure is used for sales statistics.
In invoicing, the billing documents of a contract account are grouped together into an invoicing document. In addition, billing documents are transferred to the Contract Accounts Receivable and Payable component, and print documents are created for bill printout.
© SAP AG IUT230 5-17
SAP AG 2008
Invoicing Tasks
Standard SAP Utilities process that establishes the link to contract accounts receivable and payable, and provides the basis for bill creation
Groups billing documents of contracts from a contract account into a joint bill (invoicing unit)
Posts documents in subledger accounting
Processes budget billing plans
© SAP AG IUT230 5-18
SAP AG 2008
Billing Transactions
Periodic billingScheduled billing occurring in fixed periods
Interim billingUnscheduled billing at any time
Final billingWhen the customer moves out or when the contract is terminated
Period-end billingThirteenth billing, backbilling for a year
Manual billingPossibility of making manual corrections (e.g., corrections to bills)
Periodic billing is consumption billing carried out on a regular basis. Scheduling controls how often it takes place. Periodic billing may take place daily, annually or every 2, 3, 4, or 6 months. If necessary, a new budget billing plan is created.
Period-end billing is carried out separately after a billing cycle. The billing cycle is usually a year, but it can also be a period of 2, 3, 4 or 6 months. Periodic billings can, if necessary, be recalculated and backbilled.
Interim billing is not controlled by scheduling functions and can be carried out manually at any time (upon customer request, for example). The subsequent periodic billing starts at the time of the interim billing. In the case of floating backbilling and period-end billing, it is not possible to carry out interim billing.
Final billing is triggered when a customer moves out. Final billing is similar to periodic billing, with the exception that in final billing all open budget billing payments of the period are canceled and no new budget billing plan is created. If necessary, a period-end billing is triggered.
A clerk can trigger manual billing at any time. In most cases, manual billing is used to make corrections to invoices.
Move-in billing is a special form of billing and is used duing move-in processing
© SAP AG IUT230 5-19
SAP AG 2006
10 kW
15 kW 15 kW
20 kW 20 kW 20 kW
25 kW 25 kW 25 kW 25 kW
Month 01
Month 02
Month 03
Month 04
- 10 kW
- 2 * 15 kW
- 3 * 20 kW
Floating Backbilling / n Periods
Data: T-F-0015Schema: E7
Backbilling gives you the opportunity to correct values in periods (adjustment periods) which have already been billed:
Reverse the calculation
For this, billing line items of billing documents from the adjustment periods are added to the current billing document.
Backbilling
For this, schema steps are executed in the adjustment periods. The resulting billing line items are added to the current billing document.
In the rate category, you specify
how may periodic periods are covered by backbilling
if floating backbilling or backbilling was executed for the past n periods
Periodic or final billing triggers backbilling.
© SAP AG IUT230 5-20
SAP AG 2008
01 02 03 04 05 06 07 08 09 10 11 12 13
01 02 03 04 05 06 07 08 09 10 11 12
. . . . . . . . .
. . . . . . . . .
Separate Period-End Billing
Period-End Billing and Final Periodic Billing
Period-end billing
Data: T-F-0016Schema: E8
Period-end billing enables you to bill based on several periods (period-end billing periods) that have already been billed. You can backbill in the adjustment period of the period-end billing period.
In the rate category, you specify
how many periods are covered by period-end billing
whether integrated or separate period-end billing should be carried out
You define which schema steps are to be performed in period-end billing in the rate for period-end billing. If you specify a period-end billing in the rate category, you must use a billing schema that contains a period-end billing rate.
Period-end billing is triggered when the last periodic billing or final billing is carried out.
© SAP AG IUT230 5-21
SAP AG 2006
Month 01
Month 02
Currentbillingperiod
Next billing period
Billing in Advance
Data: T-F-0023Schema: E9
With periodic billing, you can also calculate schema steps in advance (for example, with monthly billing, the rental price is always calculated for the following period in advance).
The period for billing in advance covers the period from the end of the periodic billing period to the next scheduled meter reading date. You can use the indicator for controlling billing in advance in the billing schema to define which steps are to be carried out in the period for billing in advance.
© SAP AG IUT230 5-22
SAP AG 2008
Billing SchemeBilling Scheme
Rate 1Step 1Step 2
Rate nStep 1
Variant Programe.g. Quantity x Price
Comparison of Two Demands
Rate TypeRate Type
Utility InstallationUtility Installation
Installation StructureInstallation Structure
RatesVariant ProgramRatesVariant Program
Control of Billing in Advance
Indicator for Billing in Advance
Data Model for Billing in Advance
Rate Category
Rate Category
Rate Determination
Rate Determination
© SAP AG IUT230 5-23
SAP AG 2006
Controlling Billing in Advance in the Schema
Possible entries:
Control for billing in advance = ' ':The schema step is only carried out during the periodic billing period.
Control for billing in advance = '1':The schema step is carried out during the current periodic billing period for the advance period.
Control for billing in advance = '2':The schema step is carried out during the periodic billing period and the advance period.
The settings for controlling billing in advance determine which schema steps are billed in advance.
© SAP AG IUT230 5-24
SAP AG 2006
Billing: 3
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
© SAP AG IUT230 5-25
SAP AG 2006
Simulation
Determination ofMR
Results
Determination ofBillingPeriod
ConsumptionExtrapolation
Determination ofRate DataSimulation
BillingSimulation
Types of Simulation Functions
Generate Billing Document
Simulation Functions
Two types of simulation are available:
Simulation
Billing simulation
Billing simulation requires a billable order. Because the billing order has to be billable, meter reading results must also be available.
Simulation does not need a billing order. The clerk can enter a simulation period. The system uses existing values to project meter reading results which are not available.
© SAP AG IUT230 5-26
SAP AG 2006
Billing Simulation/Simulation
Billing OrderNo billing order available!Simulation period must be specified.
Billing SimulationBilling Simulation SimulationSimulation
Billing order must be able to be billed
Billing period is derived from billing order
Meter-reading results are used
Purpose: What will tonight's billing be like?
Billing order must be able to be billed
Billing period is derived from billing order
Meter-reading results are used
Purpose: What will tonight's billing be like?
Billing order is not required
Any billing period can be specified
Existing meter-reading results are used, otherwise data is extrapolated
Purpose: What would the billing for a certain billing period look like?
Billing order is not required
Any billing period can be specified
Existing meter-reading results are used, otherwise data is extrapolated
Purpose: What would the billing for a certain billing period look like?
Both these simulation types are based on master data that actually exists.
© SAP AG IUT230 5-27
SAP AG 2006
Differences Between Billing and Simulation
BillingBilling SimulationSimulation
Creates billing documents which are then processed by the invoicing functions
The billing order is deleted
Status of the meter-reading results is dynamically set to billed
A new time-slice is proposed for maintaining data in the historical data of the installation
Creates billing documents which are then processed by the invoicing functions
The billing order is deleted
Status of the meter-reading results is dynamically set to billed
A new time-slice is proposed for maintaining data in the historical data of the installation
Creates simulation documents which can only be processed further by the invoicing simulation functions
The billing order is not deleted
Meter reading results are not changed
The master data is not changed
Creates simulation documents which can only be processed further by the invoicing simulation functions
The billing order is not deleted
Meter reading results are not changed
The master data is not changed
Billing and simulation documents can be assigned to different document number ranges with the document type, so they can easily be differentiated from one another.
Different number ranges also make archiving easier later on.
© SAP AG IUT230 5-28
SAP AG 2006
BillingDocuments
BillingDocuments
Mass Simulation
PortionPortion
InvoicingDocumentsInvoicing
Documents
PurposePurposeMass Simulation
BillingMass Simulation
Billing
Mass SimulationInvoicing
Mass SimulationInvoicing
Simulation of rate reforms
Model bills
Effects of price changes
Simulation of rate reforms
Model bills
Effects of price changes
© SAP AG IUT230 5-29
SAP AG 2006
Billing: 4
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
© SAP AG IUT230 5-30
SAP AG 2008
Processing Level
Meter readingBillingInvoicingBill printoutBill display
Meter readingBillingInvoicing
Display Bill Invoicing
Individual Processing
When you select contracts for individual billing, you can specify the processing level.
If the Display Bill indicator is set, the contract is billed and then invoiced, the bill is then printed and finally displayed on the screen.
If the Invoicing indicator is set, the contract is billed and invoiced. However, the bill is not printed or displayed.
In individual processing, you can also capture meter reading results.
You can also simulate individual bills. In the same way as individual billing, you can select different processing levels. However, you can simulate bills per individual document or contract account. The individual document invoice simulation does not run a mandatory/optional check. The contract account simulation runs the mandatory/optional check in the same way as actual invoicing.
© SAP AG IUT230 5-31
SAP AG 2006
Mass Billing and Mass Overall Check
Individual ProcessingIndividual Processing Mass ProcessingMass Processing
Billing Analysis
Individual Overall Check
Individual Simulation
Individual Bill
Mass Overall Check
Mass Simulation
Mass Billing
Parallel Processing
Contract accountContractInstallation
Contract accountContractInstallation
PortionInstallation intervalCheck runtimeLog w/o success message
PortionInstallation intervalCheck runtimeLog w/o success message
There are two billing alternatives: individual and mass processing.
In individual processing, you can bill a contract account, a contract, or an installation.
With mass processing, you can start mass runs in the night batch job to prevent an unnecessary load to the system. This is used for billing large numbers of contracts.
The mass overall check ensures that the selected contracts are billable.
Mass processing enables you to limit the runtime by entering the check runtime indicator and the date and time fields.
You can also use parallel processing in mass processing. This means that several billing processes are run in parallel.
© SAP AG IUT230 5-32
SAP AG 2006
Document line item types relevant to posting
Document line item types relevant to posting Information line itemsInformation line items
Billing Line Item Elements
From- and to-date
Line category
Billing quantity
Price key, amount, time portion
Net amount, tax code, sub-transaction
Rate, rate category
Billing class, industry
Sort key
etc.
From- and to-date
Document line type
Billing quantity
Device
Meter reading: from - to
Rate, rate category
Billing class, industry
Sort key
etc.
The system differentiates between billing line items relevant to posting and information lines. Billing line items relevant to posting contain information for the posting, such as net amount. Information line items contain additional information that is absolutely necessary for bill printout, for example, device number, meter reading from/to.
You should always write information lines.
Tax is not calculated until invoicing.
© SAP AG IUT230 5-33
SAP AG 2006
Doc. line item types rel. to postingDoc. line item types rel. to posting Information line itemsInformation line items
Examples of Document Line Item Types
000001 Energy price
000002 Demand price
000003 Flat rate
000004 Rental price
000005 Reference value
000006 Amount discount
IQUANT Quantities (meter readings)
IDEMAN Demand (meter readings)
IT001 Flat rate x factor
IT002 Addition of two operands
IT001 Quantity x (/) factor
IT004 Demand x (/) factor
IT005 Subtraction of amounts
IT006 Comparison of two quantities
The document line items control and analyze the billing rule.
Billing document line items are primarily required for bill printing, where the system may need to know which line item it is dealing with, for example in the billing form. For example, different information needs to be printed for energy price line items than for basic charge line items.
Line item types are stored in the rate in the rate steps and are automatically proposed by the system.
If necessary, additional document line item types can be defined in the customer namespace and be allocated to a variant program or rate.
© SAP AG IUT230 5-34
SAP AG 2006
BillingDocument
Display
BillLine Items
Price Data
Rate Data
Device Data
Account Data
InternalBillingData
MR Data
Print Data
Functions of Billing Document Display
The billing document can be displayed on the screen using the billing document display. This transaction is used for example, when the billing is outsorted and the clerk has to check the billing line items.
© SAP AG IUT230 5-35
SAP AG 2006
Billing: 5
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
© SAP AG IUT230 5-36
SAP AG 2008
Check pool
Selection of checks to be carried out
Company-specific checks possible
not OK
Billing InvoicingCheck
- standard- company-specific
Invoice Printout
Reversal
OK OK
Exception List or WorkflowException List or Workflow
not OK ReleaseRelease Release
Check- standard- company-specific
Outsorting in SAP Utilities
SAP provides a predefined set of checks.
You can check for certain net amount limits, for example after billing. Then the billing document can be checked, reversed, released, or it can also be manually billed.
After invoicing, you should check for gross amount limits. Credit checks should also be carried out during the invoicing process and not before, as clearing takes place during invoicing (budget billing payments, payments on account, cash security deposits).
You can create your own outsorting checks and include them in the billing or invoicing program without modification.
Outsorting can occur after billing or invoicing.
© SAP AG IUT230 5-37
SAP AG 2006
Net amount checks
Checks for budget billing amounts
Check for estimations
Check for billing line items
Billing InvoicingInvoicingBillingBilling
Gross amount checks
Credit checks after settlement
Balance forward
Times of Outsorting
Outsorting can occur after billing or invoicing.
Different checks can be carried out according to the time of the outsorting.
On this slide, you can see the checks provided by SAP in the system.
© SAP AG IUT230 5-38
SAP AG 2006
BillingBilling
ChecksChecks
Billings to be checked
ReleaseRelease
ReversalReversal InvoicingInvoicing
Automatic ChecksAutomatic Checks Manual OutsortingManual Outsorting
Electric. contr.Manual
outsorting: 0001Once
Electric. contr.Manual
outsorting: 0001Once
BillingBilling
Billings to be checked
ReleaseRelease
ReversalReversal InvoicingInvoicing
Outsorting Options: Billing
The system supports automatic checks. The agent can also store a manual outsorting in the contract.
The agent must check the outsorted billing documents on the screen and can either reverse the billing or release it for invoicing.
The agent can use a report to display the outsorted billing documents. He/she can also process them using a workflow. To display the outsorted billing documents, two events (OUTSORTED and RELEASED) are available for the BILLDOCAUT business object. To process them, the OUTSORTDISPLAY method is available.
© SAP AG IUT230 5-39
SAP AG 2006
Outsorting groupsBilling0001 Residential cust.0002 C & I customer
Outsorting groupsBilling0001 Residential cust.0002 C & I customer
Automatic checksAutomatic checks
Rate category(Generaldefinition)
Rate category(Generaldefinition)
Contract(Individualoverrides)
Contract(Individualoverrides)
Billing procedure01 Periodic billing02 Interim billing03 Final billing04 Period-end billing05 Territory transfer06 Manual billing
Billing procedure01 Periodic billing02 Interim billing03 Final billing04 Period-end billing05 Territory transfer06 Manual billing
Billing checksOutsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1Outsorting Group 0002 + Billing Procedure 01 = Check NO_LINES
Billing checksOutsorting Group 0001 + Billing Procedure 01 = Check AMOUNT1Outsorting Group 0002 + Billing Procedure 01 = Check NO_LINES
Outsorting Group: Billing
The outsorting groups are usually stored in the rate category and can be overridden in the contract in special cases.
The actual checks are found using a customizing table from the combination of the outsorting group and the billing procedure.
© SAP AG IUT230 5-40
SAP AG 2006
Billing Checks
AMOUNT1Amount check on net amount
BBP_ABS1Absolute deviation of budget billing amount
BBP_PERC1Percentage deviation of budget billing amount
ESTIMATEEstimation
NO_LINESExisting billing line items
You can create additional outsorting checks. The check programs are small ABAP/4 function modules.
The check programs in the billing are subject to a naming convention. They start with ISU_VAL_.....
The check programs for invoicing are start with Z.
© SAP AG IUT230 5-41
SAP AG 2006
Customizing Functions: Billing
..........
..........
..........
...........
IMGIMG
Define check pool for billing (SAP)
Define outsorting groups for billing
Define checks for each outsorting group for billing
Define manual bill outsorting for billing
© SAP AG IUT230 5-42
SAP AG 2006
Billing: 6
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
© SAP AG IUT230 5-43
SAP AG 2008
Billingdocument
100,-
Billingdocument
100,-
Billingdocument.
.
. Reversal...
Renewedbill
111,-
.
.
.
OutsortingOutsorting ActionsActions
Reversal Process in Billing
Reversal
Change meter reading result
Change rate category
Change rate type
etc.
Reversal
Change meter reading result
Change rate category
Change rate type
etc.
You can reverse a billing document more than once as long as it has not been invoiced. This is the case, for example, if the billing document was outsorted in billing.
The agent can reverse the billing document and carry out additional activities such as changing the meter reading result. Then the contract can be billed again.
The reversed billing document does not affect the customer, as nothing has been posted in the contract account and a bill has not been created.
Functions were added to the reversal process specifically for processing installation groups.
© SAP AG IUT230 5-44
SAP AG 2006
BillingBilling Billing Document
Invoicing Document
InvoicingInvoicing
BillingOutsorting
BillingOutsorting
InvoicingOutsortingInvoicing
OutsortingBilling
ReversalBilling
ReversalInvoicingor TotalReversal
Invoicingor TotalReversal
Reversal Times
There are two times at which a reversal is possible in the system. Reversal can occur after billing or invoicing. There are two possibilities for a reversal after invoicing: either a reversal of invoicing, or a full reversal (reversal of invoicing and of billing).
© SAP AG IUT230 5-45
SAP AG 2006
Reversed Billing
Document
BillingReversalBilling
Reversal
Billing Order
Billing Reversal Elements
Reversed billing document is marked accordingly
Billing order is restored
© SAP AG IUT230 5-46
SAP AG 2006
Reasons for Reversal
Incorrect meter reading
Estimation
Meter is stuck
Meter is working backwards
Meter is defective
Wrong meter read
Wrong rate used
Water pipe break
Incorrect billing period
Ripple control receiver is defective
© SAP AG IUT230 5-47
SAP AG 2006
Data Elements of the Billing Process
Billing Process
Billing Simulation
Billing Documents
Outsorting in Billing
Billing Reversal
Parallel Processing
Billing: 7
© SAP AG IUT230 5-48
SAP AG 2008
Aim: Processing times can only be shortened by dividing up the processes
Parallel processing of dataset
Jobs should finish at roughly the same time
Large volume of data:
Billing
Invoicing
Bill Printout
Budget Billing Request
Creation of Partial Bills
Parallel Processing - Situation
© SAP AG IUT230 5-49
SAP AG 2006
Size of Interval = 3
No. of Intervals = 4
No. of Intervals = 3
Size of Interval = 4
Interval_1 Interval_2Interval_3
Interval_1
Interval_2
Interval_3
Interval_4
BP_1
BP_3
BP_4
BP_5
BP_9
BP_19
BP_20
BP_30
BP_21
BP_35
BP_40
BP_31
Parallel Processing: Interval Creation
Using the number of intervals parameter, you can define the number of intervals that are to be created.
You can also use the interval size parameter, which defines the number of processes per interval.
When creating intervals, you can take different objects into account (business partner, contract account, billing order). This depends on the background process that is to run, for example:
Mass billing = billing orders
Invoicing = EITR (pool of contracts that have not been invoiced yet)
Request budget billing amounts = contract accounts
Bill printout = EITERDK (pool of bills that have not been printed yet)
© SAP AG IUT230 5-50
SAP AG 2006
Parallel Processing: Problems of Portioning
ProblemsHow is the dataset to be portioned?The dataset is not distributed evenly:
Contract account numbers or business partner numbers are generally more concentrated in some number intervals than in others.
Contract accounts have varying numbers of items.
How many portions should be allocated to each process?Each processing run does not contain the same processes or number of processes:
Processes on different servers have varying degrees of "performance".
Furthermore, performance is dependent on other processes that are being carried out at the same time.
© SAP AG IUT230 5-51
SAP AG 2006
mOIs
mOIs
mOIs
...
Interval1
Interval4
Interval9
Interval3
Interval6
Interval2
Interval10
Client AJob 1
Client AJob 2
... Client XJob n
Dispatcher forMass Data Program
m = Block value
Parallel Processing: Implementation
© SAP AG IUT230 5-52
SAP AG 2008
Billing: Summary
SAP AG
Billing in SAP Utilities follows a process controlled by billing orders.
A clerk can either perform actual or simulated billing.
Extensive outsorting functions are available.
Billing can be completely reversed by a clerk.
The billing run can be processed in parallel.
© SAP AG IUT230 5-53
BillingExercises
Unit: Billing Topic: Schedule Records
Understand scheduling and be able to determine the data used in the master data.
Be able to describe and carry out the billing process in IS-U.
Understand the differences between meter reading and billing orders.
Billing in IS-U follows a specific predefined process. These processes are planned and carried out for regular billing using the scheduling function.
1-1 Check the existing scheduling to be used for the business partner (TF0601A0##).
1-1-1 Which meter reading unit is the business partner’s installation allocated to? ____________________________________________________________
1-1-2 What meter reading unit is this portion allocated to? ____________________________________________________________
1-1-3 Which schedule records are generated for this portion? ____________________________________________________________
1-1-4 Check the status of the billing process for the business partner. Select the monitoring function in Meter Reading and check the status of the billing order.
Which status does your business partner’s billing order have? ____________________________________________________________
1-1-5 Which scheduled billing date does the billing order have? ____________________________________________________________
© SAP AG IUT230 5-54
© SAP AG IUT230 5-55
Exercises
Unit: Billing Topic: Billing/Simulation
Carry through the procedure of billing a hypothetical situation.
Monitor the status of the meter reading and billing order.
Billing in IS-U follows a specific predefined process. Apart from real billing, you can also simulate billing. Both billing forms are used to test new rates.
2-1 A meter reading order has already been created for the business partner TF0602A0##.
2-1-1 For which meter reading date is the order? ___________________________________________________________
2-1-2 What is the meter reading order number? ___________________________________________________________
2-1-3 Go to the IS-U area device/meter reading and create a suitable meter reading for your meter reading order. ____________________________________________________________
2-1-4 Carry out the billing procedure for the business partner. Which document number does your bill have? ____________________________________________________________
© SAP AG IUT230 5-56
© SAP AG IUT230 5-57
Exercises
Unit: Billing Topic: Simulation/Document Display
Be able to define the differences between billing and simulation.
Be able to carry out a simulation without meter reading data.
A customer is billed according to the rate valid up to now. Before the new rate structure is introduced, the clerk checks what would be the result of a bill with the old data.
3-1 The individual billing simulation must be executed for a period from January 1st of this year to today’s date. Use the business partner TF0603A0## and the contract TF0603A0##.
3-1-1 What is the bill’s document number? ____________________________________________________________
3-2 True or false?
3-2-1 You always need a billing order for simulation. ____________________________________________________________
3-2-2 Billing simulation affects the business partner’s contract account. ____________________________________________________________
3-2-3 Billing simulation does not change the master data. ____________________________________________________________
3-3 Display the current billing document for the business partner TF0605A0## and the contract TF0605A0##.
3-3-1 How many billing line items does the document contain? ____________________________________________________________
3-3-2 Which billing schema was used for billing? ____________________________________________________________
© SAP AG IUT230 5-58
© SAP AG IUT230 5-59
Solutions
Unit: Billing Topic: Schedule Records
1-1 Check the existing scheduling to be used for the business partner (TF0601A0##).
1-1-1 To which meter reading unit is the business partner’s installation allocated?
From the SAP menu, choose Utilities Industry Technical Master Data Installation Display.
Enter the installation number TF0601A0## in the initial screen.
Meter Reading Unit: T-C-00
1-1-2 To which portion is this meter reading unit allocated?
Mark the meter reading unit and branch to display the meter reading unit.
Portion: T-C-00
1-1-3 Which schedule records are generated for this portion?
From the SAP menu, choose Utilities Industry Scheduling Schedule Record Evaluation Schedule Record.
Select the indicator Portion Choose Execute.
1-1-4 Check the status of the billing process for the business partner. Select the monitoring function in Meter Reading and check the status of the billing order.
Which status does your business partner’s billing order have?
From the SAP menu, choose Utilities Industry Device Management Meter reading Monitoring
Manual.
Choose Business partner. Enter the business partner TF0601A0## in the Business partner field. Choose Billing order Execute.
Billing order status: 1
1-1-5 Which scheduled billing date does the billing order have?
The date is stored in the field Sched. MRD.
© SAP AG IUT230 5-60
© SAP AG IUT230 5-61
Solutions
Unit: Billing Topic: Billing/Simulation
2-1 A meter reading order has already been created for the business partner TF0602A0##.
2-1-1 For which meter reading date is the order?
From the SAP menu, choose Utilities Industry Device Management Meter reading Monitoring
Manual.
Choose Business partner. Enter the business partner TF0602A0## in the Business partner field. Select Meter reading order. Choose Execute.
2-1-2 What is the meter reading order number?
From the SAP menu, choose Utilities Industry Device Management Meter reading Monitoring
Manual.
Choose Business partner. Enter the business partner TF0602A0## in the Business partner field. Select Meter reading order. Choose Execute.
Take the number from the Entry no. field.
2-1-3 Go to the IS-U area device/meter reading and create a suitable meter reading for your meter reading order.
From the SAP menu, choose Utilities Industry Device Management Meter reading Entry of Meter Reading Results Single Entry.
Enter the business partner TF0602A0## in the Business partner field and select the meter reading reason 01.
Choose Continue.
Enter a meter reading as described in the exercise and save.
© SAP AG IUT230 5-62
2-1-4 Carry out the billing procedure for the business partner.
Which document number does your bill have?
From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing
Individual Bill.
Select the selection criterion Contract and enter the contract TF0602A0##. You can also enter meter readings directly using the individual bill transaction.
Choose Execute.
You will find the document number in the log following billing.
© SAP AG IUT230 5-63
Solutions
Unit: Billing Topic: Simulation/Document Display
3-1 The individual billing simulation must be executed for a period from January 1st of this year to today’s date. Use the business partner TF0603A0## and the contract TF0603A0##.
3-1-1 What is the bill’s document number?
From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing
Individual Simulation Billing.
Choose the simulation type Simulation. Select the time period specified in the exercise. Select the selection criterion Contract and enter the contract TF0603A0##.
Choose Execute.
You will find the document number in the log following billing.
3-2 True or false?
3-2-1 You always need a billing order for simulation.
False
3-2-2 Billing simulation effects the business partner’s contract account.
False
3-2-3 Billing simulation does not change the master data.
True
3-3 Display the current billing document for the business partner TF0605A0## and the contract TF0605A0##.
3-3-1 How many billing line items does the document contain?
From the SAP menu, choose Utilities Industry Billing Billing Execution Display Document.
Look for the current billing document number of the business partner TF0605A0##. Enter the business partner number in the selection data and select Continue. Look for the current billing document for the contract above and select it by double-clicking it.
Line item: number of document line items.
© SAP AG IUT230 5-64
3-3-2 Which billing schema was used for billing?
Select the Int. billing data tab page.
Billing schema: E1
© SAP AG IUT230 6-1
SAP AG 2008
Manual Billing
SAP AG 2007
Manual Billing Functions
Examples of Use
Individual Bill
Joint Invoicing
© SAP AG IUT230 6-2
SAP AG 2006SAP AG 2006
At the conclusion of this unit, you will be able to:
Describe manual billing functions
Provide examples of manual billing
Create a manual billing
Recognize the difference between an individual bill and joint invoicing
Manual Billing: Unit Objectives
© SAP AG IUT230 6-3
SAP AG 2008
Calculation Options Functions
ManualBilling
Meter Reading from/to
Net Amount
Price Determination
Billing QuantityRate
Determination
StatusManagement
TaxDetermination
Individual Bill/Joint Invoice
Template
Manual Billing Functions
A manual billing can be created as an individual bill or be incorporated into the next bill.
Using the reference function, you can use existing billing documents/line items as a reference.
The manual billing function can be used as an alternative to reversal to correct the bill.
The customer can also be billed for additional services or additional consumption.
© SAP AG IUT230 6-4
SAP AG 2008
(Time-based)
Data Objects Invoicing
Business partner
Contract account
Contract
Installation
Installation Structure
(optional)
BillMs. Brown
....
Electricity ............. 900Discounts.................- 800
Manual credit memo -50
Amount due ........... 50
Bill Ms. Brown
Manual backbilling
Amount due ................. 50
Manual Billing
Manual creation of billing document line items
An Overview of Manual Billing
Necessary prerequisite Unlike in automatic billing, the billing line items are not automatically created based on the existing data objects. Despite this, the same data must exist for manual billing as for automatic billing. This information is required for open item accounting or for sales statistics, for example.
Contract and installation This data is kept historically. This means that it is possible to create manual bills for installations and contracts that no longer belong to the same business partner as at creation (as a result of a move-in/out, for example).
Installation structure In manual billing, you need the installation structure for device-related credit memos or backbilling (however, it is not needed not for flat-rate installations).
Invoicing When the manual bill is being created, a decision is made based on the entries whether to create an individual bill or to include the billing line items in the next invoicing procedure that affects that contract.
Credit memo or backbilling If the result (total of all billing line items) is positive, a credit memo is created, and if it is negative, a backbilling is created.
© SAP AG IUT230 6-5
SAP AG 2008
Selection of- Affected Line Items- Billing Order
Selection of- Affected Line Items- Billing Order
Print Action Record
Control DataJoint Invoicing
Copy Prorations
Initial EntryContract
Key Date
Control DataCopy of Doc. Line Items
Reversal
TemplateBilling Document
Maintenance
Basic Data
- Rate Data- Quantity Data- Line Items Control Data- Price Data- Amount Data
Device Data
- Device- Operand Data
Additional Data
- Line Category- Franchise Fee Data- Account Assignment Data
Manual Billing: Initial Entry
Initial entry Manual billing always refers to a contract. You cannot create a manual billing for several contracts and contract accounts. The key date is required for contracts and installations where the current business partner is not the business partner who is to receive the bill (this does not refer to the alternate bill recipient).
Reference If the manual billing is created with reference to an existing billing document, this data can be copied to the document line items. If there are several line items, a selection can be made.
Print action record When you create or change a manual billing you can create a print action record, which allows you to include additional detailed information in the bill when you print it.
© SAP AG IUT230 6-6
SAP AG 2006
With Reference toBilling Order
Billing Document
Contract
Billing Order
ReleaseReleaseBill
PrintoutInvoicing
Explicit Releasefor Invoicing
Open Item Accounting
Statistics
Manual Billing Process
Release Manual billing must be released explicitly for invoicing.
Billing order If a billing order exists for this contract, it can be selected. The data from the billing order is then transferred to manual billing. When the manual billing is released, the order is deleted. If the manual billing is deleted, the billing order is regenerated.
© SAP AG IUT230 6-7
SAP AG 2006
ManualBilling
ManualBilling
Bill
Last bill not reversibleLast bill not to be reversedNo bill available
Examples of Manual Billing
500 kWh backbillingdue to incorrect meter reading
40 USD credit memo due to broken water pipe (goodwill)
Bill corrected because wrong meter was read
Manual billing can be used for various purposes, for example, when a bill can no longer be reversed (because, for example, it is not the most recent bill).
Manual billing has no effect on existing billing documents. This is additional credit/backbilling line items, which can be invoiced either individually or together with the next bill.
© SAP AG IUT230 6-8
SAP AG 2008
Invoicing
Manual Billing Document
Bill PrintoutPrint Document with Print Items
Automatic Billing
Document
Invoicing Bill PrintoutPrint Document with Print Items
Manual Billing Document
Joint InvoicingJoint Invoicing
Individual Bill
Joint Invoicing/Individual Bill
Bill
Bill
When you create a manual billing document, you have to decide whether the document is to be invoiced as an individual bill, or whether the billing line items are to be included in the next invoicing run (for example in the next periodic billing).
The manual billing document no longer has to be billed, as the 'billing' took place when the clerk entered the billing line items.
© SAP AG IUT230 6-9
SAP AG 2006
Manual Billing: Unit Summary
SAP AG
In manual billing you can specify 'from' and 'to' dates, quantities, and net amounts.
The manual billing transaction can be used instead of reversal functions.
A manual billing can be sent as an individual bill or be included in the next billing.
Extensive reference functions are available to make it easier for clerks to enter billing line items.
© SAP AG IUT230 6-10
© SAP AG IUT230 6-11
Exercises
Unit: Manual Billing Topic: Manual Billing
Create a manual billing.
A customer has received a bill containing errors. As the bill is two years old, it can no longer be reversed. Therefore, you bill the customer manually.
1-1 Carry out the manual billing procedure for the business partner TF1101A0##. The incorrect billing and invoicing for this business partner can no longer be reversed.
1-1-1 Create a billing document manually for the contract TF1101A0##. Enter today’s date as the key date. The manual billing is to be invoiced as an individual bill. Therefore, you must leave the joint invoicing field blank. Use the last billing document for the contract as a reference document. Use the second line item in the last billing document as a reference. Enter a backbilling line item for 250 kWh. ________________________________________________________________________________________________________________________
1-1-2 Create a second line item. You want to use this line item to reverse the document line item, which you selected as a template. ______________________________________________________________________________________________________________________
1-1-3 What is the total amount of the line items you created? ________________________________________________________________________________________________________________________
1-1-4 Now the manual billing document has to be invoiced. You do not execute invoicing until the next unit. Release your manual billing document for invoicing. Display the (manual) billing document. What main transaction is determined for this billing document? ____________________________________________________________
© SAP AG IUT230 6-12
© SAP AG IUT230 6-13
Solutions
Unit: Manual Billing Topic: Manual Billing
1-1 Carry out the manual billing procedure for the business partner TF1101A0##. The billing and invoicing for this business partner can no longer be reversed.
1-1-1 Create a billing document manually for the contract TF1101A0##. Enter today’s date as the key date. The manual billing is to be invoiced as an individual bill. Therefore, you must leave the joint invoicing field blank. Use the last billing document for the contract as a reference document. Use the second line item in the last billing document as a reference. Enter a backbilling line item for 250 kWh.
From the SAP menu, choose: Utilities Industry � Billing � Billing Execution � Manual Billing � Create.
Key date: Current date Joint invoicing: Leave empty
This takes you to the data entry screen for the billing document line item. All fields are empty. Select the icon Transfer Line Items. Select the last billing document.
Select the second document line item and choose Transfer. This line item is used as a reference. You can now enter 250 kWh in the quantity field and backbill.
1-1-2 Create a second line item. You want to use this line item to reverse the document line item, which you selected as a template. Do not leave the transaction. Select the icon Transfer Line Items again. Enter the same billing document as you selected as the template. Activate the Reversal field. Select the second document line item and choose Transfer. This document line item is transferred along with the correct transactions for the reversal. You can no longer change the quantity.
1-1-3 What is the total amount of the line items you created? Select the icon for executing manual billing. Copy the line items. The total amount is stored on the basic data tab page in the amount data group box.
© SAP AG IUT230 6-14
1-1-4 Now the manual billing document has to be invoiced. You do not execute invoicing until the next unit. Release your manual billing document for invoicing. Display the (manual) billing document. What main transaction is determined for this billing document? Select the icon release for invoicing. The following dialog box asks you if you want to save the document and release it for invoicing. If you answer yes, you cannot make any subsequent changes to the document. If you do want to make any changes, you must first of all delete the document. From the SAP menu, choose Utilities Industry � Billing � Billing Execution � Display Document. Enter the business partner number and find your manually created billing document in the navigation area. Double-clicking on the document takes you to the detail view screen. Select the header data tab page. The entry Manual Credit Memo/Backbilling (0300) is defined as a main transaction here.
© SAP AG IUT230 7-1
SAP AG 2008
Invoicing
SAP AG 2007
Invoicing in SAP Utilities
Invoicing Functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-2
SAP AG 2006SAP AG 2006
At the conclusion of this unit, you will be able to:
Describe the invoicing functions
Explain how items from accounts receivable and payable are processed
Explain how due dates are determined
Describe payment method determination
Outline the concept of joint invoicing/integration
Describe the outsorting concept
Invoicing: Unit Objectives
© SAP AG IUT230 7-3
SAP AG 2006
Invoicing: Business Scenario 10
MaintainBillingMaster Data
Use of Ratesin the
Master DataInvoicing Bill PrintoutBilling
Budget Billing Amounts
Additional Functionality:Additional Functionality:Discounts/SurchargesDiscounts/SurchargesManual BillingManual BillingSales StatisticsSales StatisticsSpecial Billing FeaturesSpecial Billing Features
The scenario in this unit deals with test invoicing.
A customer has made a payment within the current billing period and was billed according to the corresponding rate. The customer also wishes to receive an interim bill.
Another customer receives a bill but is not in agreement with the meter reading results billed. The meter reading results are too high. Invoicing and billing are reversed (full reversal). An adjustment bill is created.
© SAP AG IUT230 7-4
SAP AG 2008
Invoicing: 1
Invoicing in SAP Utilities
Invoicing functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-5
SAP AG 2006
Meter Reading
Order
Billing Order
InvoicingInvoicingCreation ofMeter Reading Order
Creation ofMeter Reading Order
Entry ofMeter Reading Data
Entry ofMeter Reading Data
BillingBilling
Billing Document
Implausible Meter Reading Results
PlausibleMeter Reading
Results
Billing Order
Correction ofMeter Reading
Results
Correction ofMeter Reading
Results
Print Document
BillPrintout
BillPrintout
Bill Creation
© SAP AG IUT230 7-6
SAP AG 2008
Invoicing Tasks
Invoicing Tasks:Group invoicing orders and billing documents from contracts in acontract account into a joint bill*Supply print documents for bill creationPost documents in subledger accountingProcess budget billing plansClear items in contract accounts receivable and payable
Standard SAP Utilities process that establishes the link to contract accounts receivable and payable, and provides the basis for bill creation
* Bills are created per contract account and not per contract/business partner.
© SAP AG IUT230 7-7
SAP AG 2006
FI-CA Documents
Budget Billing Plans
BillingDocuments
Receivables$100
PhysicalPrintout
Invoicing- Data Entry- Validations - Processing ofFI-CA Documents
Receivables$100Receivables100 USD
Manual Billing Print Documents
Print Documents
PostingDocuments
FI-CA
PostingDocuments
FI-CA
Budget Billing Plans
Budget Billing Plans
SD Documents
Invoicing
Invoicing
Generates posting documents for bill receivables or credit memos from the billing documents
Clears the posting documents with down payments, especially budget billings (only for statistical budget billing)
Supports determination and charging of taxes, charges, and duties
Prepares data for bill printout, that is, generates print documents
Creates budget billing plans for the next budget billing period
Creates the posting documents and the budget billing plans in FI-CA
FI-CA documents can be processed in invoicing as part of clearing control (for example, settling payments on account with receivables from invoicing)
© SAP AG IUT230 7-8
SAP AG 2008
Invoicing and Master Data
Business partner
Contract
Contract account
FI-CAR/3 central functionsSAP Utilities
Invoicing document
Print document
Contract accounts receivable and
payable document
Invoicing
Reads the business partner
Uses the contract account from contract accounts receivable and payable that contains agreements for processing business transactions with the business partner. Procedures are defined in the contract account that are used for processing document items.
A business partner can have several contract accounts
A contract account can only be allocated to one business partner
Uses the SAP Utilities contract, which contains division-related agreements between the business partner and the utility company. A contract is allocated to a contract account.
Invoicing can create a bill for several contracts for an account master record
© SAP AG IUT230 7-9
SAP AG 2006
Invoicing Data General Data
ContractAccount
General Data
• Payment terms• Clearing category• Account assignment data• Payment methods• Transaction currency
Invoicing Block
Outsorting Data• Manual outsorting• Check group
General DataAdditional Functions
• Interest key• Dunning procedure• CB account
Correspondence• Bill form• Alternative Bill Recipient• Shipping control• Different indicators
Budget Billing Data• Budget billing procedure• Participation in YAP• Budget billing request cash payer
Invoicing Data from Contract Account
• Blocking reason• Block validity
The following occurs based on the contract account data (table FKKVKP):
Correspondence and bill printout are controlled
Bill outsorting is controlled
Budget billing amounts are processed
Bills are blocked
© SAP AG IUT230 7-10
SAP AG 2006
Invoicing Data General Data
Contract
General Data• Contract account• Company code• Division• Statistics group• etc.
Invoicing Data• Joint invoicing• Finally invoiced
Acct. Assignment Data
• Account determination ID• CO Account determination key• Business area
Deregulation Fields
Budget Billing Data
Invoicing Data from Contract
• Budget billing adjustment• Budget billing cycle• Payment plan data
© SAP AG IUT230 7-11
SAP AG 2006
Invoicing
Budget billingclearing
Clearing of firstbudget billing
Inclusion ofopen items
Creditprocessing
Due datedetermination
Budget billingdetermination
Jointinvoicing
Cross-company code
invoicing
Invoicing Functions
© SAP AG IUT230 7-12
SAP AG 2006
Create bill (EA10)Create partial bill (EA11)Create bill and partial bill together (EA46)Request budget billings (EA12)Create collective bill (EA10_COLL)
Individual processing that creates bills for a business partner or contract account:
Mass processing that creates bills for a business partner or contract account interval:
Create bill (EA19)
Create partial bill (EA25)
Create bill and partial bill together (EA45)
Bill Creation
Partial bills are only created when you enter Partial bill procedure for budget billing collection as the budget billing procedure.
Budget billing amounts are only requested if you enter statistical procedure for budget billing collection as the budget billing procedure.
Collective bills can only be created when the collective bill concept is used.
You can find invoicing in the SAP menu under Utilities Industry -> Invoicing -> Execute Invoicing
© SAP AG IUT230 7-13
SAP AG 2006
Data Selection
During invoicing processes, contract accounts are selected in different ways:
An invoicing order triggers:Bill creationCollective bill creationJoint bill/partial bill creation
Contract accounts to be processed are selected using the budget billing plan items in the following cases:
Budget billing requestCreation of partial billsJoint bill/partial bill creation
© SAP AG IUT230 7-14
SAP AG 2006
Create BillCreate Bill Create Partial BillCreate Partial Bill
Document Date
Posting Date
Reconciliation Key
Document Date
Posting Date
Reconciliation Key
SimulationSimulation
Individual Processing
You can bill or partially bill a contract account or business partner with the individual processing function. You must specify the following:
Document Date
Posting Date
Reconciliation Key
You can run a simulation for both processing forms with a special indicator.
© SAP AG IUT230 7-15
SAP AG 2006
ParallelProcessing
ParallelProcessing
ParallelProcessing
ParallelProcessing
BillBill x y z
RechnungRechnung x y z
RechnungRechnung x y z
RechnungRechnung x y z
BillBillx y z
CreateBill
CreateBill
CreatePartial Bill
CreatePartial Bill
RequestBudget Billing
RequestBudget Billing
End of Runtime
Log
End of Runtime
Log
ParallelProcessing
ParallelProcessing
Parallel Processing
The parallel processing function in invoicing is used to process a large number of contract accounts.
Here, you can
Create bills
Create partial bills
Request budget billing
You can also carry out the above processes in mass processing.
© SAP AG IUT230 7-16
SAP AG 2008
Invoicing: 2
Invoicing in SAP Utilities
Invoicing functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-17
SAP AG 2006
Invoicing Unit and Grouping Options
Invoicing orders or budget billing plan items are grouped into invoicing units so that they can be jointly invoiced and displayed on a bill. A unit forms the basis of invoicing processes.
A grouping proposal is automatically created
Grouping parameters in the contract and billing document control the grouping proposal
You can edit the grouping proposal inevent R403
Examples of an invoicing unit: The electricity and gas contracts of a contract account are periodically billed. A bill correction is entered in the electricity account. All three billing documents are grouped together to form an invoicing unit. A bill is created.
The budget billing items from the electricity and gas contract are requested on one bill. They are an invoicing unit.
© SAP AG IUT230 7-18
SAP AG 2006
Electric. contr.Joint invoice: 1Electric. contr.Joint invoice: 1
Gas contractJoint invoice: 1Gas contract
Joint invoice: 1Water contractJoint invoice: 1Water contractJoint invoice: 1
Cable televisioncontract
Joint invoice: 2
Cable televisioncontract
Joint invoice: 2
Electricity installation
Meter reading unit:T0001
Electricity installation
Meter reading unit:T0001
Gas installationMeter reading unit:
T0001
Gas installationMeter reading unit:
T0001
Water installationMeter reading unit:
T0002
Water installationMeter reading unit:
T0002
Cable televisioninstallation
Meter reading unit:K0001
Cable televisioninstallation
Meter reading unit:K0001
Contract Account
Contract Account
Joint Invoicing: Master Data
Billing documents of selected contracts in a contract account are grouped to form invoicing units in order to create a suitable bill that includes as many of the customer's contracts as possible. For this purpose, contracts are divided into three distinctive groups:
Contracts for which the documents must be invoiced jointly. The billings of these contracts must always appear together on one bill (for example, a residential customer's contracts for electricity, gas, and water). If a document has to be invoiced with other documents, a search for the corresponding billing documents of the other contracts is carried out. If no valid document is found, invoicing is stopped.
Contracts for which the documents can be invoiced jointly. The documents of these contracts are also grouped together, if possible, with the documents that must be invoiced jointly.
Contracts for which the documents must be invoiced separately.
The billing documents that qualify for joint invoicing are transferred to FI-CA in an accounting document. During this process, the data from the individual billing documents is summarized according to fixed FI-CA criteria and other, company-specific controls (such as account determination and transaction determination).
© SAP AG IUT230 7-19
SAP AG 2008
Contract 1Mandatoryjoint invoice
Contract 1Mandatoryjoint invoice
Contract 2Mandatoryjoint invoice
Contract 2Mandatoryjoint invoice
Contract 3Mandatoryjoint invoice
Contract 3Mandatoryjoint invoice
ContractOptional
joint invoice
ContractOptional
joint invoiceDocumentOptional
DocumentOptional
Document 3Mandatory
Document 3Mandatory
Document 1Mandatory
Document 1Mandatory
DocumentOptional
DocumentOptional
Billing
ContractExclusive invoiceContract
Exclusive invoiceDocumentExclusive
DocumentExclusive
DocumentExclusiveDocumentExclusive
InvoicingContract Account
Bill
Event: R403
Joint Invoicing: Example 1
Bill
In the first example, contracts 1, 2, and 3 must always be billed together. As contract 2 has not been billed yet, the contracts are not invoiced.
The other two contracts can be invoiced. However, the customer receives two bills, as one of the contracts can only be invoiced exclusively.
Event R403 can be used to influence how the invoicing unit is formed.
© SAP AG IUT230 7-20
SAP AG 2008
Contract 1Mandatoryjoint invoice
Contract 1Mandatoryjoint invoice
Contract 2Mandatoryjoint invoice
Contract 2Mandatoryjoint invoice
Contract 3Mandatoryjoint invoice
Contract 3Mandatoryjoint invoice
ContractOptional
joint invoice
ContractOptional
joint invoiceDocumentOptional
DocumentOptional
Document 3Mandatory
Document 3Mandatory
Document 1Mandatory
Document 1Mandatory
DocumentDocument
Billing
ContractExclusive invoiceContract
Exclusive invoiceDocumentExclusive
DocumentExclusive
DocumentExclusiveDocumentExclusive
InvoicingContract Account
Bill
Document 2Mandatory
Document 2Mandatory
Event: R403
Joint Invoicing: Example 2
Bill
In the second example, the billing documents for the contracts 1, 2, and 3 exist, which means that they can be invoiced jointly.
As there is also a billing document for the optional contract, it can also be included in the invoicing unit.
In either case, the exclusive contract has to be invoiced separately.
Event R403 can be used to influence how the invoicing unit is formed.
© SAP AG IUT230 7-21
SAP AG 2006
Contract Account
Terms of Payment:
Contract Account
Terms of Payment:
0001
Due Date
PostingDate
PostingDate
Document DateDocument Date
System DateSystem Date
Receivable/Credit
Receivable/Credit
FI-CA Termsof Payment
FI-CA Termsof Payment
FI Terms of Payment:Receivable 14 Days
FI Terms of Payment:Receivable 14 Days
FI Termsof Payment:
Credit Immediately
FI Termsof Payment:
Credit ImmediatelyIncoming PaymentsOutgoing PaymentsIncoming PaymentsOutgoing Payments
Elements of Due Date Determination
The terms of payment are also used by other standard components (e.g. FI, SD).
A predefined payment condition that refers to a term of payment is entered in the contract account.
If other payment conditions should be used for different services, several contract accounts have to be created.
The terms of payment could depend on the following data: Posting date, document date, system date.
Maintain the payment conditions and terms of payment in the Financial Accounting Customizing menu under:
Contract Accounts Receivable and Payable -> Basic Functions -> Postings and Documents -> Document -> Maintain Payment Conditions
Accounts Receivable and Accounts Payable -> Business Transactions -> Incoming Invoices/Credit Memos -> Maintain Terms of Payment
© SAP AG IUT230 7-22
SAP AG 2006
Basics of Due Date Determination
The due date of the bill is based on the general elements of due date determination
Final bill amount (credit/receivable) forms the basis for due date determination
The due date is determined in the event Document: Determine due date from payment condition (1330)
The bill due date is stored in all business partner items from the newly created posting documents and in the print document header.
For the budget billing request or partial bill creation, the due date is:
Transferred from the budget billing plan
Re-determined if the request is delayed
When a collective bill is created, the due date is copied from the individual bills
Bill due date consist of net due date, cash discount percentage rate.
When consumption billing is invoiced, the balance of evaluated consumption values incl. tax minus paid budget billing amounts is the basis for due date determination. Account maintenance and creation of sub-items take place.
You can use a different due date determination in a user-specific function module for event 1330. In the case, the SAP function module is not executed.
The day entries (date limits) must be made in ascending order and cover the whole month.
You must propose a date type (basis date). Recommendation: Document date or date of entry. When you are maintaining several date limits, you can only use one date type for each term of payment.
Cash discount:
Only single-level cash discount entry permitted
Calculated net due date cannot come before the cash discount due date
© SAP AG IUT230 7-23
SAP AG 2006
Grouping Bill Due Date and Budget Billing Amount Due Date
Only possible when invoicing consumption billingPrerequisites are:
Bill ReceivableThe BB/Bill Due Dates field (ABRABS) must be active in the portion.
1: Bill is due together with next budget billing amount2: Next budget billing amount is due together with bill
Control of billing due date (table TE501)Amount checkInterval check
Event IS-U Invoicing: Budget billing clearing (R420): Due date determination by including budget billing due dates.
Grouping bill due date and due date of the next budget billing amount
This grouping allows you to influence the bill due date for the last time in invoicing.
The following applies in the control table TE501:
The due date can be adjusted separately for direct debit payers/cash payers
Amount check: Final bill amount < upper limit
Interval check: Number of days between bill due date and budget billing due date
If the due date of the next budget billing amount and the bill are grouped together, the budget billing amount is included in the print document as a line item and, as a result, becomes relevant for the final amount. This budget billing amount can no longer be requested, or a partial bill is not created for it.
When several contracts are invoiced and each of these have a budget billing plan, the due date is only adjusted if the fixed value 2 is maintained in the field ABRABS in all portions.
© SAP AG IUT230 7-24
SAP AG 2008
Payment Method Determination: Incoming
Contract Account
Incoming payment method:E Automatic debitK Credit card
Determination of incoming payment
method
Determination of incoming payment
method
Amount limit:Lower limit
Amount limit:Lower limit
Check for incoming
payment blocks
Check for incoming
payment blocks
User exitEvent R430User exit
Event R430
Determination of incoming payment method
In invoicing, a payment method is determined based on the final bill amount according to specifications set in the contract account. The determined payment method is transferred to the print document header.
The invoicing posting documents, however, do not have a payment method so that they can be regulated together in a payment run with other open items for the contract account. The items are reinterpreted during the payment run.
If the final bill amount represents a receivable, invoicing tries to determine an incoming payment method.
In the contract account, you can enter the customers desired incoming payment method (such as automatic debit, credit card).
Amount limits in Customizing or incoming payment blocks that may have been set in the contract account, can also influence the determination of the appropriate incoming payment method.
An incoming payment block ensures that a direct debit payer is treated as a cash payer - i.e. a payment method is not determined.
© SAP AG IUT230 7-25
SAP AG 2006
Contract Account
Outgoing Payment MethodsP Postal transferC Check
Contract Account
Outgoing Payment MethodsP Postal transferC Check
Posting AreaR401
P Priority 1S Priority 2U Priority 3
Posting AreaR401
P Priority 1S Priority 2U Priority 3
Determination ofOutgoing Payment
Methods
Determination ofOutgoing Payment
Methods
Amount LimitCheck
Amount LimitCheck
Checks forOutgoing
Payment Blocks
Checks forOutgoing
Payment Blocks
User ExitEvent R430User Exit
Event R430
Payment Determination: Outgoing
Determination of the outgoing payment method depends on several factors. When the system determines remaining credit during invoicing, the invoicing process tries to enter the suitable outgoing payment method in the print document. This is necessary because information on the repayment method is required at printing time. However, payment methods are not entered in the FI-CA document. The items are reinterpreted during the payment run.
You can enter the customer's desired outgoing payment methods in the contract account (such as postal transfer, or check).
There is a posting area in Customizing for invoicing, where you can define the priorities of the outgoing payment methods to be used for each company code (for example, postal transfer has a higher priority than check or bank transfer).
Amount limits in Customizing or outgoing payment blocks, that may have been set in the contract account, can also influence the determination of the appropriate outgoing payment method.
Determination of the outgoing payment method can also be influenced by a user exit, that is, event R430.
© SAP AG IUT230 7-26
SAP AG 2006
Tax rate(s) inbillingperiod
Tax rate at time of invoicing
No proration, tax is dependent on point in time:
System date
Posting date
Document date
TaxReference Basis
(Alternative)
Account Determination
Account Determination
Proration of billing line items if tax changes (in billing)
Tax Determination
Using the settings in Customizing for FI-CA, the invoicing process determines the account (posting areas R000 and R001) and the corresponding general ledger accounts.
It also determines the value-added tax. The billing component transfers only net amounts. Value-added tax is determined using the posting area R001.
You can specify whether the tax rate is determined from the billing period or from the tax rate that is valid at the time of invoicing. If you choose to determine taxes based on the time of invoicing, you must also specify which date is to be used: the entry date, document date, or posting date.
In Italy, Spain, and Portugal, for example, the tax is determined on the basis of the billing date. In this type of tax determination, the billing line items are not prorated if there is a tax change.
The tax code for sales and purchases is defined by the tax determination code, the country (from table T001) and the date. The tax code for sales and purchases is also used by other standard components (such as FI, SD) and is defined in the Customizing menu of Financial Accounting under Financial Accounting Global Settings -> Tax on Sales and Purchases -> Calculation -> Define Tax Code for Sales and Purchases.
The tax determination code is defined in the same way as the revenue account determination (posting area R001).
© SAP AG IUT230 7-27
SAP AG 2006
Item :10.03.99 155.43
10.03.99 0.03 -
Billamount
155.43 SFR 1
~ 155.40 SFR
Currency rounding
One rounding per bill
Rounding
Item :10.03.99 155.43
10.03.99 0.03 -
Billamount
155.43 USD
~ 155.40 USD
Final amount rounding
Rounding carried forward to next bill
Rounding information is stored as print document line items in the print document and have the document line item type ROUND. You can define the rounding rules in the Financial Accounting Customizing menu under Contract Accounts Receivable and Payable -> Basic Functions -> Postings and Documents -> Basic Settings -> Define Rounding Rules for Currencies.
Currency rounding is mandatory in some countries due to the currency used in payment transactions (for example, 5 rappen rounding in Switzerland). This occurs at posting document or posting item level, is a one-off occurrence for each bill, is displayed on the bill and is executed according to rounding rules defined in contract accounts receivable and payable.
Rounding information is stored in the print document as print document line items with the document line item types ROUND (rounding amount current bill) and ROUNDO ( rounding amount from previous bill).
Activate the function in Customizing for SAP Utilities under Invoicing -> Basic Settings -> Define Basic Settings. You can define the rounding rules under Invoicing -> Invoice Processing -> Define Invoice Rounding Rules or Define Rounding Limits for Rounding Amount Carryforward.
Rounding is executed at rounding level; it is considered for the next bill (rounding amount carryforward), displayed in the account and on the bill, activated in invoicing Customizing and is executed according to predefined rounding rules. The rounding balance is cleared when a contract account is finally invoiced.
© SAP AG IUT230 7-28
SAP AG 2008
Invoicing: 3
Invoicing in SAP Utilities
Invoicing functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-29
SAP AG 2006
Bill 4711 Date: 02.01.06
Valuated consumption +_________+_________+_________
Credit memos/backbillings +/-________
Billamount =========
Budget billings paid -__________
Items above +/-________
1. Budget billing +_________Final billamount =========
Sub-items +/-________
Amount to be paid =========
Manual billings are automatically included
Paid budget billing amounts are automatically included and posted (only for statistical budget billing)
Main items (such as payment on account, statistical items) can be included and settled using the settlement control
Settlement against the first or next budget billing
Sub-items can be shown on the bill. No settlement occurs
Item Processing
Manual billings (such as corrections to bills) are automatically included in invoicing. You do not need to make additional settings in Customizing.
Paid budget billing amounts are automatically included and posted in statistical budget billing. In the debit entry procedure, the budget billing amounts remain and are not reposted.
During the invoicing process, FI-CA items can be processed using settlement control. To allow this, you have to configure settlement control accordingly in Customizing. For example, payments on account could be settled against receivables from the annual consumption billing. Cash security deposits should also be settled in a final billing.
You can also use settlement control to settle remaining credit against the first or next budget billing amount.
The due dates of outstanding receivables are not grouped with the first or next budget billing amount as there is nothing to settle (both are receivables). For this reason, the due dates are grouped in a separate Customizing table in invoicing.
Sub-items (open items in the contract account) can be displayed on the bill. However, you must note that these items are not part of the contract accounting document, and still have separate due dates. Therefore, you should check if you really want to include the items in the account balance.
© SAP AG IUT230 7-30
SAP AG 2006
AdditionalFunctionsAdditionalFunctions
Event: 5010Account
Maintenance Event: 5010
Interest Calc.Cash Security
DepositsEvent: 5010Interest Calc.Receivables
% exp % exp
Open Items:Clearing
03.10.06 150,00 150,00
03.08.06 70,00 50,00
03.22.06 200,00 - 200,00 -
03.19.06 123,00 -
Difference: 0.00
Additional Functions in Invoicing
LPCReceivables
Event: 5010Dunning
LPCInstallm. plan
Debit EntryStat. Item
You can define the following for each settlement type and category:
Account maintenance: you must activate account maintenance in invoicing if you want to use settlement control, such as settlement with the first budget billing amount, settlement of cash security deposits in the final billing, settlement of payments on account.
Interest calculation of debit items in invoicing
Interest calculation of cash security deposits in invoicing
Dunning in invoicing
Charge (LPC - late payment charge) for late items in invoicing.
Charge (LPC - late payment charge) for installment plan items in invoicing.
Debit entry for statistical items in invoicing, such as for dunning charges (only for statistics key G)
© SAP AG IUT230 7-31
SAP AG 2006
Open Items:Clearing
03.08.06 150.00 150.00
03.10.06 70.00 50.00
03.19.06 200.00 -
03.22.06 123.00 - 123.00 -
Difference: 77.00
Bill 4711 Date: 01.7.2006
Valuated consumption +_________+_________+_________
Credit memos/backbillings +/-________
Billamount =========
Open items on 06.15.06 +/-________
Amount to be paid =========
Dunning in Invoicing
In the course of invoicing the contracts of a contract account, reminders can be sent out for any business partner items which are due to the contract account.
The dunning text has to be taken into account when you create the billing form.
Dunning charges cannot be posted if the dunning is triggered during invoicing.
Dunning in invoicing is mostly used by North American customers, as meter reading and billing generally occur every month.
© SAP AG IUT230 7-32
SAP AG 2006
IMGIMG
...........
..........
..........
..........
Bill 4711 Date: 02.07.06
Valuated consumption +_________+_________+_________
Credits/backbillings +/-________
Billamount =========
Budget billings paid -__________
Items above +/-________
1. Budget billing +_________Final billamount =========
Sub-items +/- 343.58
Amount to bepaid =========
Please note that your bill of 343.58 USDfrom 05/04/2006, has not yet been paid.
Alternative 1
Alternative 2
Include sub-items (open items) in the balance
Print an informative note about sub-items (open items) on the bill
Selection of Items in InvoicingSelection of items using
clearing type and category, mainand sub-transaction, and interval
Sub-Items
Sub-items are open items that you wish to include in the printed bill. You can print the last unpaid bill on the current bill.
There are two ways of printing the sub-items on the bill:
You include the sub-items in the balance of the bill. In this case, you must make sure to print a new due date for the old open item on the bill (implies that due date is moved forward). This is not permitted in every country and should be verified. Another problem is that the changed due date is not reflected in the account. Programs such as the dunning program continue to use the old due date. Exception: credit memos can, however, be included in the bill balance as they do not have a due date (for example a payment on account).
In this case, information about the open item is printed on the bill, but the open items are not included in the bill balance.
You select the open items to be printed on the bill in the item selection procedure in invoicing.
This table also allows you to deactivate statistical items (such as dunning charges) in invoicing (for example, during final billing).
© SAP AG IUT230 7-33
SAP AG 2006
Item Selection for Invoicing (Subitems)
Calculate Interest for
Items
Calculate Interest for
Items
Defer ItemsDefer Items
Clearing Without
Subsequent Posting
Clearing Without
Subsequent Posting
TransferTransfer
Debit EntryDebit Entry
Final Bill Amount
Final Bill Amount
ItemsPrint
ItemsPrint
ActionsActions
In "Item Selection for Bill Display" you can select the open items to be printed. You can decide whether or not items are included in the final amount.
You can also trigger various actions for the individual items in invoicing:
Debit entry of statistical items: Once you have activated the debit entry in the additional functions, you can select the items here.
Transfer of items to a credit or receivable for invoicing. For example, you can transfer a cash security deposit to the final bill.
Clearing without subsequent posting: This indicator is recommended for statistical requests (for example, dunning charge or down payment requests), which are to be waived after invoicing.
Defer items: The open item contains the due date for invoicing as a deferral date.
Calculate interest for items: Once you have activated the interest calculation in the additional functions, you can select the items here.
The due date adjustment offers another option for including items in the bill. An open item with the clearing restriction 8 is included during invoicing and is given the same due date as the invoicing.
© SAP AG IUT230 7-34
SAP AG 2008
Invoicing: 4
Invoicing in SAP Utilities
Invoicing functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-35
SAP AG 2008
Invoicing of Different Services
Joint Billing #4711:Bill (#1-#5) 4375 USD- Amt paid (#1-#3) -3600 USDRemainder due: 775 USDDue on 15-Jan-06
Simplifiedrepresentation
without tax!
JointJointInvoicingInvoicing
-- AccountAccount-- Due DatesDue Dates-- OptionalOptional
Account A. SmithBill #4711 775 USDLine items for each receivable:
Bill #1 ...Bill #2 ...
................
Sale #5Radiators 350 USD
Maint. charge #4 Gas heating 45 USD
Other services #3Cable TV 180 USD
Other services #2Waste water 500 USDWaste disposal 200 USD
Cons. billing #1Electricity 1000 USDGas 1500 USDWater 600 USD
You can also include additional services in invoicing.
© SAP AG IUT230 7-36
SAP AG 2008
Incorporation of Additional Documents
SDbilling doc.
SDbilling doc.
SAP UtilitiesBilling
SAP UtilitiesBilling
SAP UtilitiesInvoicingBilling documentsBilling documents
SD Sales
PM-CSInstallation Services
IS-UUtility
Services
Invoice RequestOptional
Invoicing can process different types of documents:
The type of document that the invoicing program has to process most often is billing documents created in SAP Utilities billing.
It is possible to incorporate SD billing requests (side business, maintenance etc.) in SAP Utilities invoicing and to integrate these with the IS-U bill.
© SAP AG IUT230 7-37
SAP AG 2008
Integration: SD Billing Document
FI-CA
FI-ARFI-AR
SDbilling doc.
SAP Utilitiesbilling
IS-Ubilling doc.
FI customerFI customer
Contract acct
Billing Request
Acco
unt g
roup
Doc. typePosAr R400
Doc. typePosAr 1210
SD invoicing cat. "U"
SD b
illing
type
Event: R403
The account group of the SD customers controls whether the accounting document is posted in FI-AR or FI-CA.
If the billing category is 'U' in the SD billing type, no document is posted in the SD billing document. Instead an IS-U billing request is generated. The billing request is posted during the next invoicing run and is then billed.
The default settings mean that SD documents cannot be invoiced alone. You can, however, allow this invoicing in event R403. To do this, you must allocate a grouping key other than zero for E_GROUP to the SD documents in the table T_EITR. For further information, see SAP note 924706.
© SAP AG IUT230 7-38
SAP AG 2008
Invoicing: 5
Invoicing in SAP Utilities
Invoicing functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-39
SAP AG 2008
Check pool
Selection of checks to be carried out
Company-specific checks possible
not OK
Billing InvoicingCheck- standard- company-specific
Invoice Printout
Reversal
OK OK
Exception List or WorkflowException List or Workflow
not OK ReleaseRelease Release
Check- standard- company-specific
Outsorting in SAP Utilities
SAP provides a predefined set of checks.
You can check for certain net amount limits, for example after billing. The billing document can be checked, reversed, released, or it can also be billed manually.
After invoicing, you should check for gross amount limits. Credit checks should also be carried out during the invoicing process and not before, as clearing takes place during invoicing (budget billing payments, payments on account, cash security deposits).
The customer can create their own outsorting checks and include them in the billing or invoicing program without modification.
Outsorting can occur after billing or invoicing.
© SAP AG IUT230 7-40
SAP AG 2006
Net amount checksChecks for budget billing amountsCheck for estimationsCheck for billing line items
Billing InvoicingInvoicingBillingBilling
Gross amount checksCredit checks after settlementBalance forward
Times of Outsorting
Outsorting can occur after billing or invoicing.
Different checks can be carried out according to the time of the outsorting.
On this slide, you can see the checks provided by SAP in the system. For invoicing, these are:
AMOUNT2: Gross billing amount checked against minimum and maximum limitations
AMOUNT3: Final bill amount checked against minimum and maximum limitations
FORWARD1: Balance forward checked against maximum amount for credit memo/ receivable
The customer can also create additional outsourcing checks. The check programs are small ABAP/4 function modules. You can find the following points in the IMG:
Define check pool for invoicing (SAP)
Define outsorting groups for invoicing
Define checks for each outsorting group for invoicing
Define manual bill outsorting for invoicing
© SAP AG IUT230 7-41
SAP AG 2008
ControldocumentControldocument
ControldocumentControldocument
InvoicingInvoicing
ChecksChecks
Invoicingsto be checked
ReleaseRelease
ReversalReversal Billprintout
Billprintout
Automatic checksAutomatic checks Manual outsortingManual outsorting
Contract accountManual outsorting:
0001 Once
Contract accountManual outsorting:
0001 Once
InvoicingInvoicing
Invoicingsto be checked
ReleaseRelease
ReversalReversal Billprintout
Billprintout
Outsorting Options: Invoicing
The system supports automatic checks. In addition, the clerk can define manual outsourcing in the contract account.
The clerk has to check the outsourced invoiced/printed documents on the screen and can either reverse the invoice or release it to print the bill.
You can use a report to display the outsorted invoicing documents. Alternatively, you can process the outsorted invoicing document in a Workflow. To display the outsorted billing documents, two events (OUTSORTED and RELEASED) are available for the PRINTDOC business object. To process them, the OUTSORTDISPLAY method is available.
Note that in outsorting in invoicing, the invoicing document is a control document, which means the document is not posted in FI-CA. This is necessary because with a real posting FI-CA functions such as payment run and dunning run have access to the posting.
After the control document is released, real invoicing is carried out.
© SAP AG IUT230 7-42
SAP AG 2006
Outsorting Groups:Invoicing
0001 Res. customer0002 Nonres. cust.
Outsorting Groups:Invoicing
0001 Res. customer0002 Nonres. cust.
Automatic checksAutomatic checks
Contract Account(Individual
setting)
Contract Account(Individual
setting)
Invoicing ChecksOutsorting Group 0001 = Check AMOUNT2Outsorting Group 0002 = Check AMOUNT3
Invoicing ChecksOutsorting Group 0001 = Check AMOUNT2Outsorting Group 0002 = Check AMOUNT3
Outsorting Group: Invoicing
Outsorting groups are always stored individually in the contract account.
Checks are found using a customizing table from the the outsorting group.
Billing is based on contracts while invoicing is carried out for contract accounts. This is why the outsourcing group for invoicing can no longer be defined globally (for example in the rate type). Instead, the outsourcing group is entered in the contract account.
© SAP AG IUT230 7-43
SAP AG 2008
Invoicing: 6
Invoicing in SAP Utilities
Invoicing functions
Inclusion of Open Items
Integration
Outsorting in Invoicing
Invoice Reversal
© SAP AG IUT230 7-44
SAP AG 2006
Invoicing Reversalor TotalReversal
Open old budget
billing plan
Delete newbudget billing
plan
Indicate old posting
document
Create reversal document
Indicate old billing document
Invoice Reversal Billing Reversal
Create billing order
Invoicing Reversal Functions
The reversal has to be carried out in a certain sequence. You have to start with the latest document and work backwards to earlier documents.
© SAP AG IUT230 7-45
SAP AG 2008
-1000.-
.
.
.
Bill reversal
100.-
.
.
.
Bill
Bill
1000.-
.
.
.
Action e.g., changemeter reading result
and redo billing/invoicing
Action e.g., changemeter reading result
and redo billing/invoicing
Billing orderFull Reversal
Reversal Process in Invoicing/Full Reversal
Reversedbilling
document
There are two times at which a reversal is possible in the system. Reversal can occur after billing or invoicing. There are two possibilities for a reversal after invoicing: either a reversal of invoicing, or a full reversal (reversal of invoicing and of billing).
© SAP AG IUT230 7-46
SAP AG 2008
Invoicing Document
Full bill is not to be reversedFull bill is not to be reversed
Bill DocumentBill Document
Billing Reversal/Adjustment Reversal
Individual reversalof a billing document
Individual reversalof a billing document
In addition to full, billing and invoicing reversal, there is also an adjustment reversal function.
Adjustment reversal enables you to recalculate the time period of the adjustment reversal billing document and thus create a correction bill. It allows you to to recalculate the time period of the adjustment reversal billing document and thus create a correction bill. The billing order is reconstructed and marked with the old billing document number.
© SAP AG IUT230 7-47
SAP AG 2006
Adjustment ReversalAdjustment Reversal
RebillingRebilling
Changeto
Dataset
Changeto
Dataset
Bill 4711 Date: 06.02.2006
Bill correction
Original document - 50- 70
New document 4060
-------
Total - 20
1
2
Rebilling
When you rebill following an adjustment reversal, the billing lines of the old billing document are entered as negative along with the newly created billing lines. A differential bill is created.
The adjustment reversal can be carried out if, for example, there is only one incorrect billing document in the invoicing document. A full reversal would be unnecessary in this case.
© SAP AG IUT230 7-48
SAP AG 2006
Bill Correction
Print Document 4
Print Document 3
Print Document 2
Print Document 1
Invoicing Sequence
This document is to be reversed
Reversal Sequence
The bill correction allows you to process multiple reversals in an overview.
All reversal options are integrated:
Full Reversal
Invoicing reversal
Adjustment reversal
© SAP AG IUT230 7-49
SAP AG 2006
Select billing documents
Set billing block
Create meter reading order
Wait until meter reading document is created
Display meter reading results
Decide if correction should be made
Reverse invoicing
Reversal/adjustment reversal of billing doc.
Correct meter reading results
Steps in the WorkflowWorkflow
starts
Workflow for Bill Complaints
SAP delivers a sample workflow for bill complaints with the system (WS 20500045, ISUBIMRCOR02).
You can use this workflow as a template to create your own workflow.
This workflow is also included in the CIC configuration delivered with the system and is called 'Control reading - bill complaints'.
© SAP AG IUT230 7-50
SAP AG 2006
Search for billing documents to be reversed
Adjustment reversal of billing document
New estimation of incorrect MR results
Steps in the WorkflowWorkflow
starts
Overestimation of meter reading
results
2006200613.02. 16.03. 15.04.14.01.
Meter Readings:
500read
800estimated
750read
1. Reversal of billing document from Feb 13th2. Reestimation of overestimated meter
reading results from 800 to 625
Workflow Assessment - Meter Overflow in Estimation
SAP delivers a sample workflow for meter overflow in estimation (assessing) with the system (WS 20500105, ISU_ASSESS).
The workflow is started if the event UtilContract.Assessed is triggered (overestimation of meter reading results). The event belongs to the business object ISUCONTRCT (utility contract).
You can use this workflow as a template to create your own workflow.
© SAP AG IUT230 7-51
SAP AG 2008
Invoicing: Summary
SAP AG
Invoicing creates the link to the Contract Accounts Receivable and Payable (FI-CA) component.
All billing documents of a contract account can be grouped together in one bill (optional).
Invoicing can clear and print contract account items.
Extensive outsorting options are available.
As well as an individual reversal, invoicing and billing can be fully reversed.
© SAP AG IUT230 7-52
© SAP AG IUT230 7-53
InvoicingExercises
Unit: Invoicing Topic: Invoicing
Be able to name the differences between billing and invoicing.
Carry out the invoicing procedure.
A customer has made a payment within the current billing period and was billed according to the rate valid up until now. The customer wishes to receive an interim bill. For this, billing and invoicing are started in the system.
1-1 Bill and invoice the business partner TF0701A0## and the contract TF0701A0##.
1-1-1 Use the existing billing order. ____________________________________________________________
1-1-2 Display the print document for this process. ____________________________________________________________
1-1-3 Simulate billing in the document display. ____________________________________________________________
1-1-4 Display the postings in the account balance display. ____________________________________________________________
1-2 Invoice the business partner TF1101A0## and the contract TF1101A0##. In the previous unit, you created a manual billing document for this customer.
1-2-1 Use the existing billing document. ____________________________________________________________
1-2-2 Display the print document for this process. ____________________________________________________________
1-2-3 Simulate billing in the document display. ____________________________________________________________
1-2-4 Display the postings in the account balance display. ____________________________________________________________
© SAP AG IUT230 7-54
1-3 Check the definition of invoicing outsorting in the Implementation Guide.
1-3-1 Which menu path would you use to define outsourcing in invoicing? ____________________________________________________________
1-3-2 Which outsourcing is maintained for residential customers in the system? ____________________________________________________________
© SAP AG IUT230 7-55
Exercises
Unit: Invoicing Topic: Reversal
Be able to trigger full reversal of billing and invoicing.
Be able to name the differences and effects of the reversal.
A customer has received a bill and does not agree with the meter reading billed. It is too high due to a bad reading. The bill is fully reversed and recalculated.
2-1 The business partner’s existing bill must be checked and recalculated with the correct meter reading.
2-1-1 Display the last billing document for the business partner TF0703A0## and the contract TF0703A0##.
2-1-2 Use the print document display function. ____________________________________________________________
2-1-3 Trigger a full reversal of the bill (invoicing and billing). Select the reconciliation key TF0703A0##.
2-1-4 Which options are available for carrying out this procedure? List the menu paths. ____________________________________________________________
2-1-5 Change the result of the meter reading. Use the correction function for meter reading results and the installation TF0703A0##. What is the new meter reading? ____________________________________________________________
2-1-6 Carry out the new billing and invoicing procedure with the billing order.
Which document numbers are created by the system (in billing and invoicing)? ____________________________________________________________
© SAP AG IUT230 7-56
Invoicing
© SAP AG IUT230 7-57
Solutions
Unit: Invoicing Topic: Invoicing
1-1 Bill and invoice the business partner TF0701A0## and the contract TF0701A0##.
1-1-1 Use the existing billing order.
From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing
Individual Bill.
Do not change the document or posting date. Enter the user IUT230-## in the reconciliation key field. Select yes in the dialog box when you are asked whether you want to create a reconciliation key. In Level of processing, select Display bill. Choose the selection criterion Contract and enter the contract TF0701A0## and a reconciliation key.
Choose Execute.
You will find the document numbers in the log following billing/invoicing.
1-1-2 Display the print document for this process.
From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Display Print Document. Enter the print document number. Select the table overview. Navigate through the various screen areas.
1-1-3 Simulate billing in the document display.
Select Simulate Bill. This function does not produce an original printout. The original printout was already produced in step 1-1-1.
1-1-4 Display the postings in the account balance display.
From the SAP menu, choose Utilities Industry Contract Accounts Receivable and Payable Account
Account Balance.
Choose the selection criterion Business partner and enter the business partner TF0701A0##. Enter the All open items as the list category.
Choose Execute.
© SAP AG IUT230 7-58
1-2 Invoice the business partner TF1101A0## and the contract TF1101A0##. In the previous unit, you created a manual billing document for this customer.
1-2-1 Use the existing billing document.
From the SAP menu, choose: Utilities Industry Invoicing Execute Invoicing Individual Processing Create Bill. The invoicing process determines that an invoicing order already exists for this business partner. The billing document number is displayed in a dialog window.
1-2-2 Display the print document for this process. From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Display Print Document. Enter the print document number. Select the table overview. Navigate through the various screen areas.
1-2-3 Simulate billing in the document display. Select Simulate Bill.
1-2-4 Display the postings in the account balance display.
From the SAP menu, choose Utilities Industry � Contract Accounts Receivable and Payable � Account � Account Balance.
Choose the selection criterion Business partner and enter the business partner TF1101A0##. Enter the All open items as the list category.
Choose Execute.
1-3 Check the definition of invoicing outsorting in the Implementation Guide.
1-3-1 Which menu path would you use to define outsourcing in invoicing?
In the SAP Reference IMG, choose SAP Utilities Invoicing Invoice Processing Outsorting for Invoicing.
1-3-2 Which outsourcing is maintained for residential customers in the system?
Select checks per outsourcing group for invoicing.
Validation: AMOUNT2 = Gross billing amount with minimum and maximum limitations.
© SAP AG IUT230 7-59
Solutions
Unit: Invoicing Topic: Reversal
2-1 The business partner’s existing bill must be checked and recalculated with the correct meter reading.
2-1-1 Display the last billing document for the business partner TF0703A0## and the contract TF0703A0##.
2-1-2 Use the print document display function.
From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Display Print Document. Enter the print document number. Select the table overview.
You can also find the bill in the archive. If your local PC is configured accordingly, you can also display the bill from the archive. Another possibility is to simulate the bill. This formats the form using data from the print document.
2-1-3 Trigger a full reversal of the last bill (invoicing and billing). Select the reconciliation key TF0703A0##.
From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Individual Processing Full Reversal.
Select the reconciliation key TF0703A0##. Select the business partner’s document number TF0703A0##. Choose Execute. Also select the billing document for reversal Press Enter to carry out the complete reversal of the invoicing and billing documents.
© SAP AG IUT230 7-60
2-1-4 Which options are available for carrying out this procedure? List the menu paths.
From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Individual Processing Full Reversal.
From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Mass Processing
Full Reversal.
Two steps for the individual reversal of billing and invoicing.
From the SAP menu, choose Utilities Industry Invoicing Execute Invoicing Mass Processing
Reverse Bill.
and
From the SAP menu, choose Utilities Industry Billing Billing Execution Reversal Billing Reversal.
Another option: Adjustment Reversal
From the SAP menu, choose Utilities Industry Billing Billing Execution Reversal Adjustment Reversal.
Another option: Bill correction
From the SAP menu, choose Utilities Industry Billing Billing Execution Bill Correction.
Another option: Workflows for invoice correction and assessing
2-1-5 Change the result of the meter reading. Use the correction function for meter reading results and the installation TF0703A0##. What is the new meter reading?
From the SAP menu, choose Utilities Industry Device Management Meter reading Correction of Meter Reading Results Plausible Results.
Select the business partner TF0703A0##. Select the last reading of the device. Select the reading and choose Continue. Change and save the meter reading.
© SAP AG IUT230 7-61
2-1-6 Carry out the new billing and invoicing procedure with the billing order.
Which document numbers are created by the system (in billing and invoicing)?
From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing
Individual Bill.
In Level of processing, select Display bill. Choose the selection criterion Contract and enter the contract TF0703A0## and a reconciliation key.
Select Execute You will find the document numbers in the log following billing/invoicing.
© SAP AG IUT230 7-62
© SAP AG IUT230 8-1
SAP AG 2006
Fundamentals of clearing control in invoicing
Contents:
Clearing Control
© SAP AG IUT230 8-2
SAP AG 2006
Describe the purpose of clearing control
Explain the components of clearing control for account maintenance in invoicing
Make the necessary Customizing settings for clearing strategies in invoicing
At the end of this unit you will be able to:
Clearing Control: Objectives
© SAP AG IUT230 8-3
SAP AG 2006
You have to maintain a new clearing control in the system
This excludes a cash security payment deposit made during periodic billing
This amount has to be cleared with the final bill amount during final billing
Clearing Control: Business Scenario
© SAP AG IUT230 8-4
SAP AG 2006
Orientation
Every open item, that is every open receivable or payable, must be cleared at some point. There are different procedures that enable you to clear an item. The following are the most common:
Payment: The customer pays his/her receivable
Clearing: Receivables and credit for a contract account or business partner are cleared against each other
Since these clearing processes are normally mass processes, the system must be able to automatically determine payment usage, or automatically create the clearing proposal according to preset rules
© SAP AG IUT230 8-5
SAP AG 2006
Definition
FI-CA clearing control is a tool for configuring a company's clearing strategy.
It contains rules for an automatic clearing proposal or automatic payment assignment.
By splitting the clearing algorithm into several processing steps and combining a few basic rules, it can configure diverse clearing scenarios flexibly and based on different tables.
© SAP AG IUT230 8-6
SAP AG 2006
General Overview
Clearing VariantClearing Type Clearing Category
1-n clearing steps
Clearing Proposal
Clearing proposal:
Clearing
10.03.99 150.00 150.00
08.03.99 70.00 50.00
22.03.99 200.00 - 200.00 -
19.03.99 123.00 -
Difference: 0.00
Contract Account
4711
Business Transaction
Open Items
DFKKOP
You can configure clearing control in the Financial Accounting Customizing menu under Contract Accounts Receivable and Payable -> Basic Functions -> Open Item Management -> Clearing Control. You can also find a detailed description of clearing control here.
© SAP AG IUT230 8-7
SAP AG 2008
The clearing type represents the business transaction.
For example, payment lot, payment at cash desk, periodic invoicing (R41)
The clearing category represents the reference to the contract account. It is stored in the contract account. In this way, different customer groups can have their own clearing categories.
For example, private, commercial and industrial, collectors
The user can freely assign the category.
Basic Terms
Clearing rules are defined based on the clearing type. They can also be made dependent on the clearing category (optional).
© SAP AG IUT230 8-8
SAP AG 2006
Clearing Variant
The clearing variant is at the center of clearing control. It contains the actual clearing logic for creating a clearing proposal.
The clearing variant makes it possible to split the clearing algorithm into different clearing steps.
The individual clearing steps control:
The open items that are included in clearing
How the items are to be grouped Grouping enables you to process items that meet the same criteria together.
How items are sorted for the analysis and clearing sequence
Amount checks and tolerance analyses
The distribution algorithm within groups for partial clearing
© SAP AG IUT230 8-9
SAP AG 2008
Determination of Clearing Variants
Clearing Variant05 PY119 PY1
R41 AM1R41 + SAM AM2
Clearing TypePayment lot 05Cash desk 19Periodic invoicing R41
BusinessTransaction
Contract Account Clearing Category
Private STDC&I SONCollector SAM
0815
Optional
Clearing variants are determined depending on the clearing type of the underlying processes and, optionally, on the clearing category of the contract account.
© SAP AG IUT230 8-10
SAP AG 2006
Clearing Control and Account Maintenance
Bill 4711 Date: 02.1.1999
Valuated consumption +_________+_________+_________
Credit memos/backbillings +/-________
Billamount =========
Paid budget billings -__________=========
Remaining amount +/-_________
Account Billing
1st Budget Billing +________
Other credit/rec. +/-________
Final billamount =========
Sub-Items +/-________
Amount tobe paid =========
Please note that the bill amount for 12.16.2001...
Account maintenance: Clearing the final bill amount with next budget billing or other credit memo/receivable
Print an informative note about sub-items (open items) on the bill
IMGClearing Control
In account maintenance, document items posted during invoicing can be cleared with other open items from the contract account, for example:
Clearing using the first budget billing amount
Clearing cash security deposits in the final bill
Clearing payments on account
© SAP AG IUT230 8-11
SAP AG 2006
Clearing Control Example
Other open itemsOld bill 10,-New BB 150,-
Open itemsNext budget billing 60.-
InvoicingRec. 400.- Division 01 Cred. 200.- Division 02Cred. 300.- Division 03
Clearing
Other open itemsPayment on account 50.-Cash sec. deposit 500,-
Open itemsCredit 250.-
InvoicingReceivable 300.-
Clearing
Example 1
Example 2
Example 1: Invoicing in IS-U determines credits from consumption valuation. These are to be cleared against other receivables and the next budget billing amount of the contract account during account maintenance triggered by invoicing.
Example 2: Payments on account are to be cleared in invoicing. It should also be possible to clear any cash security deposits during final billing.
© SAP AG IUT230 8-12
SAP AG 2008
Clearing Steps
Nex
t cle
arin
g st
ep
Nex
t gro
up
Group processingtaking the following into account:
• Sort sequence• Amount-dependent group rules• Tolerance limits • Splitting algorithm for partial
clearing• Customer-specific allocation
Form OI groupsfrom specifications in grouping string
Spec. for subsequent processing• Specifications for next
clearing step• Specifications for completion
of allocation
1-n clearingsteps
. . . .
A clearing variant consists of 1-n clearing steps. The steps are normally executed in the sort sequence defined by their numbers. However, they can also be directly triggered by the clearing rules.
The individual clearing steps inherit the clearing proposal and the remaining open amount from the previous steps.
Items that are completely cleared in a clearing step are not included in subsequent steps.
Rules for the selection, grouping, sorting and amount-dependent allocation of items are stored in the individual clearing steps.
The rules are processed in the following sequence: 1. Item grouping 2. Sorting the groups and items within the groups 3. Applying amount rule to group balance 4. Applying clearing rule for clearing the items in the group ( insofar as these have qualified for clearing acc. to 3)
Items are grouped and sorted according to predefined characteristics. Grouping and sorting strings can consist of up to 5 characteristics that are linked to each other using a logical AND.
© SAP AG IUT230 8-13
SAP AG 2006
Clearing Control and Account Maintenance
During this process, a clearing document is posted.
The clearing document takes on the origin, document date and posting date from the bill.
The clearing document is entered in the print document with the document identification C (table ERDB).
Items that were already posted before invoicing and cleared are stored in the print document with the document line item ACCMNT.
They are included in the final bill amount.
The clearing document can be reversed independently of the bill reversal, using FI-CA document reversal.
Integrated account maintenance means that document items posted during invoicing can be cleared with other open items from the contract account
Account maintenance is supported in all invoicing processes, with the exception of statistical budget billing requests (clearing type R6).
© SAP AG IUT230 8-14
SAP AG 2006
Prerequisite: Item Selection
Open items are selected for clearing analysis in the table Item Selection for Account Maintenance (TE514).
Items are selected depending on the clearing type of the invoicing unit and, amongst other factors, according to the transaction and due date of the item.
This table is interpreted in the same way as the table for selecting items for bill display (TE529). You can override the proposal created via table TE514 using the customer-specific event OIs for account maintenance (R401).
Caution: Open item selection only determines whether they are included in the clearing analysis. The actual decision whether the items are (partially) cleared ismade based on the clearing variant that is allocated to the clearing type.
You maintain the Item Selection for Account Maintenance table (TE514) in Customizing for SAP Utilities under Invoicing -> Invoicing Processing -> Selection of Items in Invoicing -> Define Item Selection for Account Maintenance.
Account maintenance is activated in table TE502, Central Control of Additional Invoicing Functions, according to clearing type and category.
Caution: In contrast to item selection using table TE529, the selection specifications in table TE514 refer to document items that have already been posted as well as posting items that have recently been created in invoicing.
Recommendation: To guarantee the consistency of the bill display, the open items selected should form a partial quantity of the selected sub-items for account maintenance. This is because the items selected using TE514 are only displayed in the bill if they have already been (partially) cleared.
© SAP AG IUT230 8-15
SAP AG 2008
Item Selection
OISel Open item selection, , = all items '2' = Items of contracts to be invoiced'4' = items from completed contracts '9' = no items, and so on
Print int. Interval days for due item
00050 BB amount for stat. procedure
000020/0010 Cash security deposit payment
Table TE514: Item Selection for Account Maintenance
0010
SubTrans
14STD
9
21
IntervalOISel
0050STD
Main-Trans.
Clear. type
Application Area
Clearing Type
R - utility company
R41 - periodic billing
STD 0020
The fields clearing type, clearing category, main and subtransaction make up the key for table TE514.
The selection can be set at different levels:From the specification of the clearing category, main and subtransactions of the items to be selected, to general selection with unspecified clearing category, main and subtransactions. As a result, the control table is read repeatedly to determine the selection criteria.
The selection rule (field OISel) specifies the items to be selected. You can include a variety of different values (not mentioned here).
The print interval determines the items to be included based on whether or not they are due (based on the document date of invoicing). Caution: If you do not enter an interval, it is interpreted as 0. As a result, only items due on the invoicing document date are selected.
For a more detailed description of the individual fields, see the documentation on the IMG activity: Item Selection for Account Maintenance/Define Sub-Items.
© SAP AG IUT230 8-16
SAP AG 2008
The following applies for the clearing category STD in the periodic bill (R41):
1. Only items that are due in the next 14 days (from document date) at the latest are selected
2. The next budget billing amount (main transaction 0050) is cleared when it is due in the next 21 days.
3. The cash security deposit payment (transaction 0200 0100) is not selected
Clearing Control and Account Maintenance: Example
OISel Selection of open items‚ ‚ = all items'9' = no items
Interval Interval days for due item selection
0010
SubTrans.
14STD
9
21
IntervalOISel
0050STD
MainTrans.Clear. type
Application Area
Clearing Type
R - utility company
R41 - periodic billing
STD 0020
The table is read up to four times for each open item in order to find an entry. The following criteria is used for the search:
Access using a fully qualified key consisting of the clearing type, clearing category, main and sub-transactions.
Access using an unspecified sub-transaction
Access using an unspecified sub- and main transaction
Access using an unspecified sub-transaction, main transaction and clearing category
The entry that is found first of all is used for the selection.
Once a valid entry has been found for an open item, the system decides whether the item is included in clearing based on the selection rule and the interval days.
If the system cannot find a table entry for an item, the item is excluded from selection.
© SAP AG IUT230 8-17
SAP AG 2008
Characteristics in Clearing Control
Characteristics normally describe certain characteristics of an item (such as item is payment on account, or due) or events (such as the payment is made by entering the document number)
Characteristics do the following:
Group open items. Open items that have identical grouping characteristic values in a clearing step are regarded as a unit (for example, all items that belong to the same company code)
Specify (filter) the items that are processed in the clearing step (for example, only due items, or company code 0001)
Specifies (switch) the condition required if a clearing step is to be executed (for example, only execute the step if the payment was made by entering a document number)
Sorts open items Sorting determines the sequence in which the groups are processed and the sequence of clearings within the group.
© SAP AG IUT230 8-18
SAP AG 2006
Derivation of Characteristics I
Example: Characteristic 001 'company code'
The characteristic refers to the original field FKKOP- BUKRS. As a result, the value for this characteristic is transferred directly from the open item field BUKRS.
01.31.03
11.10.02
10.10.02
12.10.02
FAEDN
4000021
3000023
6000034
50
BETRW...
00012
BUKRSOPBEL
T_FKKCLCharacteristic 001
Direct transfer
0002
0002
0003
0001
VALUE
GROUP 3
GROUP 2
GROUP
2
3
4
1
OPBEL
For example, OI'sgrouped
characteristic 001
GROUP 1
Company Code
© SAP AG IUT230 8-19
SAP AG 2006
Derivation of Characteristics II
Example: Characteristic 010 'due date'
The characteristic refers to the original field FKKOP- FAEDN. As a result, the value for this characteristic is transferred directly from the open item field FAEDN.
01.31.2003
11.10.2002
10.10.2002
12.10.2002
FAEDN
401
303
604
50
BETRW...
2
...OPBEL
Characteristic 010
Direct transfer
2002 12 10
2002 11 10
2003 01 31
2002 10 10
VALUE
20030131
20021210
20021110
20021010
SORT
2
1
4
3
OPBEL
For example, OIsgrouped
characteristic 010
SOR
T
Due Date
© SAP AG IUT230 8-20
SAP AG 2008
Example: Account Maintenance I
Clearing all items according to due date
3011.15.02CreditBill.Elec.4711
6012.05.02DebitBBReq.Elec.4712
10
Amnt
09.15.02
Due Date
Rec.Bill.Elec.4710
SubTransMainTransDiv.Document
40
0
0
Open
30
20
10
Clearing
If no characteristics are entered in the grouping string, all items
are processed in one group
Example 1
Clearing variant V01
V01
Characteristic
Grouping string
Step 1
12...
Sort characteristic
010 due date
Sorting string
12...
Example: Since a characteristic has not been entered, the open items from documents 4710, 4711 and 4712 form a group.
Within the group, the items are sorted according their due dates.
The bill credit (30.- USD) is calculated step-by-step in the following way:
The bill receivable for 10.- USD from Sept. 15th is first of all cleared.
The remaining credit of 20.- USD is cleared against the budget billing request from December 12, 2002. The budget billing request remains open at 40.- USD.
© SAP AG IUT230 8-21
SAP AG 2008
Example: Account Maintenance II
020
900
600
6535
0
0
0
Open
30
10
25
Clearing
Example 2
2010.22.02PymntPymnton Acct
4710
3011.15.02CreditBill.Elec.4711
10011.15.02Rec.Bill.Gas4711
9012.05.02DebitBBReq.Gas4712
10,-05.12.02CreditBBReq.Gas4712
6012.05.02DebitBBReq.Elec.4712
25
Amount
09.15.02
Due Date
Rec.Bill.Elec.4709
SubTransMainTransDivisionDocu-ment
Clearing open items, which have not been grouped together correctly produces the wrong clearing results!
V01
Clearing variant V01
Characteristic
Grouping string
Step 1
1
Sort characteristic
010 due date
Sorting string
1
Example: Since a characteristic has not been entered, the open items from documents 4709, 4710, 4711 and 4712 form a group.
Within the group, the items are sorted according their due dates.
The clearing algorithm produces the following processing steps:
The payment on account of 20.- USD is cleared against the bill receivable from Sept. 15, 2002
This is completely cleared using the bill credit from November 15, 2002.
The remaining credit of 25.- USD can be used for partially clearing the bill receivable from November 15, 2002, in the division gas.
The budget billing repayment request (10 USD) is cleared against the remaining bill receivable in the gas division dated from September 15, 2002. The remaining receivable from the bill 4711 is still 65.- USD.
© SAP AG IUT230 8-22
SAP AG 2008
Example: Account Maintenance III
Example 3: Clearing in 2 steps
010
200
900
5010
7030
60
0
25
Open
30
0
0
Clear.
1005.12CreditBBReq.Gas4712
2022.10PymntPymnton Acct
4710
3015.11CreditBill.Elec.4711
10015.11Rec.Bill.Gas4711
9005.12DebitBBReq.Gas4712
6005.01DebitBBReq.Elec.4712
6005.12DebitBBReq.Elec.4712
25
Amount
15.09
Due
Rec.Bill.Elec.4709
SubTransMainTransDivisionDocu-ment
00
020
900
500
700
60
0
5
Open
0
0
20
Clear.
Step 1 Step 2
Characteristic
Grouping string
Clearing step 1
1
Sort characteristic
010 due date
Sorting string
018 doc. number
2 010 due date 21
Characteristic
Grouping string
Clearing step 2
1Sort characteristic
010 due date
Sorting string
2 2
1
Example: Clearing step 1 produces the following processing steps. Document number and due date are entered as characteristics. As a result, the following groups are created: Group 1: Open item document 4709 Group 3: Open item document 4711 Group 2: Open item document 4710 Group 4: Open item document 4712 with the due date in December 5th. Group 5: Open item document 4712 with due date January 5th The following clearing steps are executed: Clearing step 1 No clearing in groups 1, 2 and 5. In group 3, the credit of 30 USD from the division electricity is cleared against the gas receivable of 100 USD so that a receivable of 70 USD is left. In group 4, the budget billing repayment requests from December 5th are balanced so that a budget billing amount of 140 USD is due on December 5th. Clearing step 2 No further characteristics have been specified. As a result, all items still open are grouped together. The payment in account of 20 USD can still be used for clearing and is used for clearing the bill that has been open for the longest amount of time. There is still a receivable of 5 USD.
© SAP AG IUT230 8-23
SAP AG 2006
Clearing Control Strategy: Account Maintenance
Clearing :
03.10.99 150.00 150.00
03.08.99 70.00 50.00
03,22.99 200.00 - 200.00 -
03.19.99 123.00 -
Difference: 0.00
FKKKOP
All items sorted according to due date
Division 1 Division 2 Division 3
Doc. 1Due date 1
Doc. 1Due date 2
Document nDue date m
Step 1
Step 3
Step 2
Clearing strategy for account maintenance
In account maintenance, the following strategy normally applies:From the detailed to the general view. That is, the clearing variant starts with a detailed grouping in the first step, and generalizes this with each subsequent step.
In contrast to payment assignment, clearing processing in account maintenance is only done within a contract account's previously entered open items.
In account maintenance, it is, therefore, not normally a good idea to assign items according to exact amounts. Here, strategy concepts such as clearing sequence and clearing within certain groups (such as company code- or division-based) with permitted partial clearance play a more important role.
In account maintenance, the following strategy normally applies:From the detailed to the general view. The clearing variant starts with a detailed grouping in the first step that becomes more general with each subsequent step.
A clearing variant designed for payment assignment is not suitable for account maintenance.
© SAP AG IUT230 8-24
SAP AG 2008
Tips for Clearing Control
This includes a clearing variant for:
Payment allocation
Account maintenance
Clearing original items from an installment plan
Clearing original items from a collective bill
Clearing individual items from a summarization group
Each area of use has a different clearing strategy. As a result, each area of use should be given its own clearing variant.
Recommendation: As a rule, different clearing variants can be used for each clearing type and clearing category. However, it generally makes sense to use the same clearing clearing variant(s) in all clearing types of payment allocation (payment lot, cash desk...). This also applies to account maintenance clearing types.
© SAP AG IUT230 8-25
SAP AG 2006
Explain the clearing control components
Carry out the settings required for creating a completely new clearing control (with the emphasis on invoicing)
Maintain clearing control in Customizing
Notice different business processes in invoicing, and in doing so, control the processing of open items
You are now able to:
Clearing Control: Summary
© SAP AG IUT230 8-26
© SAP AG IUT230 8-27
Exercises
Unit: Clearing Control Topic: Mapping a Clearing Strategy
At the conclusion of these exercises, you will be able to:
Describe the elements of clearing control for account maintenance in invoicing
Make the appropriate settings in Customizing
Test these settings
You want to create a new clearing strategy. You want to process a partially cleared payment of a cash security deposit in different ways, based on the billing process used - Within the framework of a periodic bill, the remaining open amount has to be printed on the bill.
- When the customer moves out, the cash security deposit payment that has been made has to be cleared against the final bill amount, and the unpaid cash security deposit request has to be reversed.
1-1 Using the SAP reference IMG, find out the information you need to meet the above requirements.
In the SAP menu, choose Tools Customizing IMG Edit Project.
1-1-1 Enter the menu path for maintaining clearing control.
___________________________________________________
___________________________________________________
1-1-2 Create a new clearing category (GR##, ## is your group number) with the name: Clearing category group ##. ___________________________________________________
___________________________________________________
© SAP AG IUT230 8-28
1-1-3 What are the clearing types for Periodic Billing and Final Billing: Contract Account (move-out) for the utilities industry application area?
Appl.area
Clearing type Name
1-1-4 Determine the default clearing variant allocated to the two clearing types (invoicing specifications).
Appl.area
Clearing type Clearing Variant
1-2 Now maintain the data for item selection in invoicing.
1-2-1 Enter the menu path for maintaining item selection in invoicing.
_________________________________________________
_________________________________________________
1-2-2 In this activity, what are the two functions you can define item selection in invoicing for?
_________________________________________________
_________________________________________________
1-2-3 The selection of items to be considered depends on the clearing type. What other selection options can you use for detailed clearing selection?
_________________________________________________
_________________________________________________
_________________________________________________
© SAP AG IUT230 8-29
1-2-4 Select the activity for maintaining item selection for bill printout. You want to display all open items that are due in the next 14 days (from the document date), at the latest, in a periodic bill for the clearing category GR##. These items are not to be included in the final bill amount. - With the exception of the unpaid cash security deposit requests (transaction 0020 0020). Print these and include them in the final bill amount. - Do not print the cash security deposit payment (payment 0020 0010). Make the appropriate settings. _________________________________________________
_________________________________________________
_________________________________________________
1-2-5 Go to Item Selection for Account Maintenance. You want to do the following in a periodic bill for the clearing category GR##: - Clear all open items - Not clear the cash security deposit payments (transaction 0020 0010) Make the appropriate settings. _________________________________________________
_________________________________________________
_________________________________________________
1-2-6 Check the system settings in the Customizing menu for SAP Utilities under Invoicing Invoice Processing. You have to activate the additional invoicing function Account Maintenance for the clearing category GR##. Make the appropriate settings. _________________________________________________
_________________________________________________
_________________________________________________
1-3 Test your settings.
To do this, you must first of all allocate the new clearing category GR## to the contract account of business partner TF1401A0##.
1-3-1 Go to the SAP menu and select Utilities Industry Business Master Data Contract Account Change. In the clearing category, select the entry clearing category group ##.
_________________________________________________
_________________________________________________ Save your entries.
© SAP AG IUT230 8-30
1-3-2 Display an overview of all posted items for business partner TF1401A0##. Display all items in the account balance display of contract accounts receivable and payable. Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. What and how many items exist for the business partner?
_________________________________________________
_________________________________________________
_________________________________________________
1-3-3 Execute periodic billing and invoicing for business partner TF1401A0##. In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill.
Field Name
Bill to 01.04.2004
Document date 01.04.2004
Posting date 01.04.2004
Reconciliation key TF1401A0##
Contract account TF1401A0##
Enter billing order/ME results X
Scheduled meter reading date 19.03.2004
Meter reading reason 01
Enter Invoice as the processing level and execute individual billing. Enter and save plausible meter readings.
_________________________________________________
_________________________________________________
_________________________________________________
1-3-4 Make sure billing and invoicing were successful. Analyze and check the print document that has been created. How many individual lines does the document have? _________________________________________________
_________________________________________________
_________________________________________________
© SAP AG IUT230 8-31
1-3-5 Display the changes that have occurred after invoicing in the account balance display for contract accounts receivable and payable. Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. How many items have been added?
_________________________________________________
_________________________________________________
_________________________________________________
1-4 When the customer moves out, the cash security deposit payment has to be cleared with the final bill amount, and the unpaid cash security deposit request reversed. To do this, you have to make further entries in Customizing. Call up the SAP reference IMG in the SAP menus under Tools Customizing IMG Edit Project.
1-4-1 Select Item Selection in Bill Printout. In the final bill, you want to display all open items on the bill for the clearing category GR##. However, the following items should not be displayed in the final bill amount: - The unpaid cash security deposit requests (transaction 0020 0020) - Transfer post the cash security deposit payment (transaction 0020 0010) to a bill credit and include in the final bill amount Make the appropriate settings. _________________________________________________
_________________________________________________
_________________________________________________
1-4-2 Select the Item Selection for Account Maintenance. You want to enable all items to be cleared in a final bill for the clearing category GR##. Make the appropriate settings. _________________________________________________
_________________________________________________
_________________________________________________
1-4-3 Execute a move-out (move-out date is today’s date) for business partner
TF1401A0##. In the SAP menu, select: Utilities Industry Customer Service Process Execution Move-Out Create. Enter plausible meter readings
and save the move-out document.
_________________________________________________
_________________________________________________
_________________________________________________
© SAP AG IUT230 8-32
1-4-4 Execute final billing and invoicing for business partner TF1401A0##. In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill.
Field Name
Bill to Today’s date
Document date Today’s date
Posting date Today’s date
Reconciliation key TF1401A0##
Contract account TF1401A0##
Enter Invoice as the processing level and execute individual billing.
_________________________________________________
_________________________________________________
_________________________________________________
1-4-5 Make sure billing and invoicing were successful. Analyze and check the print document that has been created. How many individual lines does the document have? _________________________________________________
_________________________________________________
_________________________________________________
1-4-6 Display the changes that have occurred after invoicing in the account balance display for contract accounts receivable and payable. Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. How many items have been added?
_________________________________________________
_________________________________________________
_________________________________________________
What has happened to the item unpaid cash deposit request?
_________________________________________________
_________________________________________________
_________________________________________________
© SAP AG IUT230 8-33
Solutions
Unit: Clearing Control Topic: Mapping a Clearing Strategy
1-1
From the SAP menu, choose Tools Customizing IMG Edit Project.
1-1-1 In the SAP reference IMG, select Financial Accounting Contract Accounts Receivable and Payable Basic Functions Open Item Management Clearing Control
In clearing control, you map the automatic allocation and clearing strategy for your company. You can define this in different ways depending on the contract account and the clearing business process. Selection rules and clearing variants form the basis of clearing control. Selection rules define what is cleared; clearing variants define it is cleared.
1-1-2 To create a new clearing category, go to the SAP reference IMG menu and select, Financial Accounting Contract Accounts Receivable and Payable Basic Functions Open Item Management Clearing Control Define Clearing Categories Select New Entries and enter the information from the exercise. Save your entries. Clearing categories are used together with clearing types to determine clearing variants. Clearing categories are defined in the contract account. As a result, you can use the clearing category to allocate individual clearing rules to different customer groups, such as household, industry and public institutions.
1-1-3 Select the Customizing activity Define Clearing Types
Appl.area Clearing type Name
R
R41 Periodic Billing
R
R43 Final billing contract account (move-out)
The clearing type represents the business transaction in which items are allocated or grouped for clearing postings. Clearing types are structured according to their areas of use (for example, incoming payment, account maintenance).
© SAP AG IUT230 8-34
1-1-4 In order to analyze the allocated clearing variant, go to the SAP reference IMG and select Financial accounting Contract Accounts Receivable and Payable Basic Functions Open Item Management Clearing Control
Define Specifications for Clearing Types Define Specifications for Invoicing
Appl.area Clearing type Clearing Variant
R
R41 040
R
R43 040
Specifications are maintained according to areas of use for the clearing types: - Incoming payment specifications - Account maintenance specifications - Specifications for collective bills/installment plans, and so on - Invoicing specifications (IS-U).
1-2
1-2-1 To maintain the item selection in invoicing, go to the SAP reference IMG and select SAP Utilities Invoicing Invoice Processing Item Selection in Invoicing Item Selection in Account Maintenance/Define Sub-Items.
Posting documents created within the framework of the current invoicing of contract billing (minus possible budget billing repayments) are a fixed part of an invoicing/print document. In addition to this, open items that were (partially) cleared during account maintenance in invoicing are displayed in the print document. This activity determines which items are considered for clearing.
1-2-2 In this activity, you define the item selection for: 1. Account maintenance in invoicing (table TE514) 2. Bill display (sub-items, table TE529)
1-2-3 A selection can be set at different levels: From a detailed selection with the specification of clearing category, main and subtransaction of items to be selected, to a general selection with unspecified clearing category, and main and subtransactions.
© SAP AG IUT230 8-35
1-2-4 The table must contain the following settings.
Item selection for bill printout TE529
Application area: Utilities industry
Clearing type R41
Clear. Cat.
MainTrans. SubTrans. OISel PrintInt. PD Rsum Umb Kb
GR## 14 X
GR## 0020 0010 9
GR## 0020 0020 X X
1-2-5 The table must contain the following settings.
Table TE514: Item Selection for Account Maintenance
Application area: Utilities industry
Clearing type R41
Clear. Cat.
MainTrans. SubTrans. OISel Inter.Days
GR##
GR## 0020 0010 9
1-2-6 You maintain all additional functions in invoice processing in the Utilities
Customizing menu under SAP Utilities Invoicing Invoice Processing Define Control of Additional Invoicing Functions. Maintain the following entries here:
ClearType Clear.Cat. ActMain.
R41 GR## X
R43 GR## X
© SAP AG IUT230 8-36
1-3
1-3-1 Carry out the instructions set in the exercise.
1-3-2 Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance. Select the list type All Items. What and how many items exist for the business partner? The business partner has three items in their contract account: 1) Cash security deposit payment of 150.- 2) Cash security deposit request of 150.- (both items are cleared with the same document number) 3) Open cash security deposit request of 50.- Select the document number of the cash security deposit request. To display the security deposit, select Environment Document Cash Security Deposits. The current status is partially paid, and there is a requested amount of 200.-.
1-3-3 In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill. Enter the data from the exercise.
Choose Execute.
Select the register and choose estimate. Save the meter reading result.
1-3-4 Check the log after billing and invoicing. Call up the list by double-clicking on the last entry. You can find the print document number for the invoicing unit in the detailed display.
From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Display Print Document.
Enter the print document number in the print document field.
Choose single lines.
Choose the tab page Doc. Overview. The first three line items correspond to the billing document line items. The fourth line item is the VAT line added during invoicing. The fifth line item is the sub-item (unpaid cash deposit request). Note the columns BillTotal (consider items in bill sum total), LineItmTyp (document line type) and Print-rel. (bill line is relevant for printing).
1-3-5 Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance.
One item has been added. It is the line item with the transaction text receivables consumpt.
© SAP AG IUT230 8-37
1-4
1-4-1 The table must contain the following settings.
Item selection for bill printout TE529
Application area: Utilities industry
Clearing type R43
Clear. Cat.
MainTrans. SubTrans. OISel PrintInt. PD Rsum Umb Kb
GR## X
GR## 0020 0010 X X
GR## 0020 0020 X
1-4-2 The table must contain the following settings.
Table TE514: Item Selection for Account Maintenance
Application area: Utilities industry
Clearing type R43
Clear. Cat.
MainTrans. SubTrans. OISel Inter.Days
GR## 999
1-4-3 In the SAP menu, select: Utilities Industry Customer Service Process
Execution Move-Out Create. Enter the business partner number TF1401A0## in the business partner field. Select Create Move-Out. To enter the meter readings in the move-out document, select the tab page meter reading data. Select the line item and choose estimate.
Save the move-out document.
1-4-4 In the SAP menu, select: Utilities Industry Billing Billing Execution Individual Processing Individual Bill. Enter TF1401A0## in the contract account field. Select the processing level invoice. Choose Execute.
© SAP AG IUT230 8-38
1-4-5 From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Display Print Document. Enter the print document number in the print document field.
Choose single lines.
Choose the tab page Doc. Overview. The first three line items correspond to the billing document line items. The fourth line item is the VAT line added during invoicing. The next two lines display the cash security deposit payment of 150, which was cleared within the account maintenance, and the subitem (Periodic Billing Not Paid). Note the columns Items BST (consider items in bill sum total), LineItmTyp (document line type) and Print-rel. (bill line is relevant for printing).
1-4-6 Go to the SAP menu and select Utilities Industry Contract Accounts Receivable and Payable Account Account Balance.
The partially cleared ‚unpaid cash security deposit request’ has been reversed. The item for the final bill has been added and the cash deposit payment cleared.
© SAP AG IUT230 9-1
SAP AG 2008
Budget Billing Amounts
SAP AG 2007
Budget billing procedure
Budget billing amountsBudget billing functions
Budget billing plan
Budget billing cycles
Budget billing due dates
Budget billing printout
Budget billing settlement
© SAP AG IUT230 9-2
SAP AG 2006
Budget Billing: Unit Objectives
SAP AG 2006
At the conclusion of this unit, you will be able to:
Describe the different budget billing procedures
Describe the budget billing functions
Create a budget billing plan and change budget billing amounts
Explain the processes behind the budget billing printout
Describe budget billing settlements
© SAP AG IUT230 9-3
SAP AG 2006
Budget Billing/Partial Bill: Business Scenario
Maintain billingmaster data
Use of rates in master
dataInvoicing Bill printoutBilling
Budget Billings
Additional functions:Additional functions:Discounts/surchargesDiscounts/surchargesManual billingManual billingSales statisticsSales statisticsSpecial billing featuresSpecial billing features
The scenario in this unit deals with changing an existing budget billing plan.
A customer phones up to change his budget billing amount because the number of people living in the household has changed.
© SAP AG IUT230 9-4
SAP AG 2006
Budget Billing: 1
Budget billing procedure
Budget billingsBudget billing functions
Budget billing plan
Budget billing cycles
Budget billing due dates
Budget billing printout
Budget billing settlement
© SAP AG IUT230 9-5
SAP AG 2008
Statistical Budget Billing Procedure
Partial Billing Procedure
AMB - Average Monthly Billing
BBP - Budget Billing Plan
Payment Scheme
Statistical Budget Billing Procedure
Partial Billing Procedure
AMB - Average Monthly Billing
BBP - Budget Billing Plan
Payment Scheme
Budget Billing Procedure
In the statistical procedure, the budget billing amounts are not posted as debits until they are paid by the customer.
In the partial bill procedure, the individual amounts are posted directly as debits.
In the budget billing plan, an average amount is determined either by simulation or manually. The customer pays this average amount for a period of 12 months. At the end of this period, a new simulation is run for the next period. In addition, actual consumption is calculated monthly, and the results are printed on the bill. In addition, the difference between the customer's actual consumption and the average amount is calculated, updated monthly, and printed on the bill. In the last month of the billing period, the actual amount and the accumulated difference are billed.
In average monthly billing/equalized billing, the customer is charged an average amount based on billings over the last 12 months (or less in the case of new customers). In addition, actual consumption is calculated monthly, and the results are printed on the bill. The amounts due for later months are calculated using the average of the previous (maximum 11) months plus the current bill and the accumulated difference. This difference is updated monthly and is also printed on the bill. In final billing, the amount due is derived from the actual consumption and the accumulated difference.
In the payment scheme, the bill amount from the latest billing is copied to the next budget billing plan. This means that the bill amount need not be cleared through a direct payment. The budget billing amount is made up of a portion of the bill and a portion of the extrapolation for the subsequent budget billing periods.
© SAP AG IUT230 9-6
SAP AG 2006
Budget Billing PlanDue Date Amount
11.15.2006 USD 15012.15.2006 USD 15001.15.2007 USD 15002.15.2007 USD 15003.15.2007 USD 15004.15.2007 USD 15005.15.2007 USD 15006.15.2007 USD 15007.15.2007 USD 15008.15.2007 USD 15009.15.2007 USD 150
Account Balance Display
11.15.2006 15012.15.2006 15001.15.2007 15002.15.2007 15003.15.2007 15004.15.2007 15005.15.2007 15006.15.2007 15007.15.2007 15008.15.2007 15009.15.2007 150
1. Request budg. billing2. Print report1. Request budg. billing2. Print report Budget
BillingRequest
Statistical Items
PaymentGenerates actualitems and value-added tax posting(actual charges)
Transfers paid budgetbilling amounts
Invoicing
Statistical Budget Billing Procedure
Budget billing amount due dates are administered in a budget billing plan.
The budget billings can be displayed as statistical postings (that is, they are not posted to the general ledger) in the account balance display immediately (for example, after the budget billing plan has been created).
The budget billing amounts can be printed, by due date, for example. To do this, first start the budget billing request report. This report generates the print documents that form the basis for the print report. After that, start the print report, which generated the actual bills for budget billing.
When payment occurs, the budget billing amount is first posted. This includes value-added tax.
During invoicing, the budget billing plan is deactivated and the paid budget billing amounts are transferred.
© SAP AG IUT230 9-7
SAP AG 2006
1. Create Partial Bill2. Print Report1. Create Partial Bill2. Print Report Budget
BillingBill
Account Balance Display
11.15.2006 150
Actual Items
PaymentClears the itemsonly. Value addedtax already posted
Partial bills arereposted
Invoicing
Partial Bill Procedure
Budget Billing PlanDue Date Amount
11.15.2006 USD 15012.15.2006 USD 15001.15.2007 USD 15002.15.2007 USD 15003.15.2007 USD 15004.15.2007 USD 15005.15.2007 USD 15006.15.2007 USD 15007.15.2007 USD 15008.15.2007 USD 15009.15.2007 USD 150
Create Partial BillCreate Partial Bill
Budget billing amount due dates are administered in a budget billing plan.
The budget billing amounts cannot be displayed immediately (for example after you have created the budget billing plan) in the account balance display. In the partial bill procedure, the budget billing plan is administered in a shadow table, which is not used by FI-CA.
The item is not transferred in FI-CA until the Enter partial bill report is started (debit entry procedure). This is the first posting with value-added tax. This report must be scheduled periodically, even if you do not want to print any partial bills. In addition, this report generates the print documents that form the basis for the partial bill printout, should it be required.
The budget billing amounts can be printed, by due date, for example. To do this, start the print report after the Enter partial bill report has run. This generates the physical partial bill.
During payment, only open items are cleared. No changes are made to the value-added tax posting. It was already posted.
During invoicing, the budget billing plan is deactivated and the posted partial bills are transferred.
© SAP AG IUT230 9-8
SAP AG 2006
The Average Monthly Billing (AMB) and Budget Billing Plan (BBP) payment plan procedures are used mainly in the North American market for monthly meter readings/billing
Customers use these payment plans to even out the monthly payments to their utility companies
In the AMB procedure, the amount to be paid monthly is a calculated average amount. A customer using a BBP procedure pays the same monthly amount for the entire 12 months
The difference between the billing amount and the AMB/BBP amount is updated in a separate item (balance forward)
Payment Plan Procedure AMB/BBP
© SAP AG IUT230 9-9
SAP AG 2006
AMB Amount
HistoricalBilling Documents
First AverageAmount
End of period:Remaining clearing amount
Date Billamount
AMBamount
Balanceforward
01.20.2006
02.19.2006
03.21.2006
04.20.2006...
100
110
85
80...
92
95
93
91...
8
23
15
4...
Average Monthly Billing (AMB) Procedure
In an AMB procedure, the customer pays an average amount every month. The amount is calculated from the last n months (generally 12 months).
The AMB amount can differ from month to month.
The balance forward becomes smaller and smaller as the end of the period approaches. In the AMB procedure, the remaining amount to be paid at the end of the period is less than the amount in the BBP procedure.
Depending on the Customizing settings, the customer only has to pay the AMB amount or the AMB and balance forward amount at the end of the period.
© SAP AG IUT230 9-10
SAP AG 2006
BBP Amounts
AverageAmount per Month
End of period:Remaining clearing amount
Date Billamount
BBPamount
Balanceforward
01.20.2006
02.19.2006
03.21.2006
04.20.2006...
100
110
60
100...
80
80
80
80...
20
50
30
50...
HistoricalBilling Documents
Budget Billing Plan (BBP) Procedure
In a BBP procedure, the customer pays the same amount every month. The amount is calculated from the last n months (generally 11 months).
The remaining amount the customer has to pay at the end of the period (balance forward) is generally higher in BBP procedures than in AMB procedures.
At the end of the period, the customer has to pay the BBP amount and the balance forward. The settings are specified in the contract.
In a BBP procedure, the BBP amounts are managed technically in a budget billing plan. However, these amounts cannot be viewed in the account balance display, but in a shadow table. This table is also used for the partial bill procedure in budget billing.
© SAP AG IUT230 9-11
SAP AG 2006
Create
Change ContractContract Edit Goto Extras System Help
Contract TF0801A001
Payment Plan
Payment Plan Cat. 0001
Start Month 1 Alt. Start Month 3
Contract Period Amount Currency
HistoricalBilling Documents
Manual History
Change to the Contract
Initializing the Payment Plan Procedure
The payment plan procedures (AMB/BBP) are controlled in the contract using the Payment plan category, Start month and Alternative start month fields.
These fields can be entered manually in the contract. You can also enter this data using the transaction for creating a payment plan.
The main function of the payment plan category is to determine which payment plan procedure is being used. You define the payment plan category in Customizing.
When the start month has been reached, the payment plan is created in invoicing.
The system processes any changes you make in the contract fields during the next invoicing. For example, you must delete the start month in the contract if the customer wants to terminate his/her payment plan immediately. The balance forward is then settled in the next invoicing, and the customer must pay the remaining amount.
One payment plan is always maintained for each contract. However, there is now also a maintenance transaction that can be used for the maintenance of multiple payment plans for multiple contracts. For example, across different divisions.
© SAP AG IUT230 9-12
SAP AG 2006
Budget Billing: 2
Budget billing procedure
Budget billingsBudget billing functions
Budget billing plan
Budget billing cycles
Budget billing due dates
Budget billing printout
Budget billing settlement
© SAP AG IUT230 9-13
SAP AG 2006
Budgetbilling
Budgetbilling plan
Budget billingcycle
Budget billingadjustment
Budget billingprintout
Budget billingsettlement
Variousbudget billingprocedures
Budget Billing Functions
The parameters needed for budget billing are defined in the portion.
Various budget billing procedures can be used. These meet the different requirements of utility companies in Europe and North America.
© SAP AG IUT230 9-14
SAP AG 2006
Budget Billing Cycle and Budget Billing Frequency
12Period Length Months
1
2
3
4
6
12
0No budget billings
Monthly
Every 2 months
Every 3 months
Every 4 months
Every 6 months
Every 12 months
1 2 3 4 5 6 7 8 9 10 11 12
Budget billing cyclesBudget billing cycles Possible number of budget billings per budget billing periodPossible number of budget billings per budget billing period
( 1 ( 2 ( 3 ( 4 ( 5 ( 6
( ( 1 ( ( 2 ( ( 3 ( ( 4
( ( ( 1 ( ( ( 2 ( ( ( 3
( ( ( ( ( 1 ( ( ( ( ( 2
( ( ( ( ( 1 ( ( ( ( ( (
Condition:Budget Billing Cycle x No. of Budget Billings = Length of the Billing Period
When you maintain the portion you enter all permissible combinations of budget billing cycle and number of budget billings.
A permissible combination refers to any pair of numbers for the budget billing cycle and number of budget billings where the product is smaller or equal to the billing period (= period length and period category).
Example:
Period length: 12 months. Period starts: 08/01/03 Budget billing cycle 01/No. of budget billing amounts: 11 =>1st budget billing amount: 08/30/06 2nd budget billing amount: 09/30/99 11. Budget billing 06/30/07 Budget billing cycle 01/Number of budget billings 12 => 1st budget billing 08/30/06 etc. 12th budget billing 07/30/07
If no combination is entered, no budget billings are collected.
© SAP AG IUT230 9-15
SAP AG 2008
Portion
Cycle: 01/12Cycle: 02/6Default: 01
Portion
Cycle: 01/12Cycle: 02/6Default: 01
Budget billing plan
Cycle: 02
Budget billing plan
Cycle: 02
Scheduling:Definition of maximumpossibilities and thedefault budget billing cycle
Contract
Cycle: 02
Contract
Cycle: 02
Contract :Individual overridingof the default budget billing cyclefor generating the next budget billingplan
Budget billing plan:Overriding of the defaultbudget billing plan affectsthe budget billing amount due dates immediately
Defining Budget Billing Cycles
In scheduling, all possible budget billing cycles for this portion are defined. A default budget billing cycle is given in the portion and this is valid for all customers in this portion.
The budget billing cycle can be overridden in the contract (for generating the next budget billing plan) or directly in the budget billing plan itself (with immediate effect).
© SAP AG IUT230 9-16
SAP AG 2006
Forms the basis for defining budget billing plans and manages all the budget billings for a billing period of a contract
Budget Billing PIan: 1
Determines the size of the budget billing amount and the due dates for the amounts
Can be created, changed, or adjusted manually or automatically.Example: individual processing in a move-in; automatic creation in invoicing
Header data (such as start and end of budget billing period, document number)
Due dates valid for all contracts in the budget billing plan (proposal from scheduling)
Cumulated budget billing amounts and cumulated open budget billing amounts (total from all contracts of a budget billing plan)
Budget billing amounts and open budget billing amounts from the active contract
© SAP AG IUT230 9-17
SAP AG 2006
Information for calculating budget billing amounts
Manual Specification
(Move-In)
Quantity-dependent extrapolation
Standing budget billing amount
Budget billing plan
Budget Billing Plan: 2
The budget billing plan can be maintained either automatically or manually.
The quantity-based extrapolation is carried out, for example, during billing by extrapolating the demand up to the next planned meter reading date. The budget billing items created in this way are transferred to invoicing in the billing document. Invoicing accepts these amounts and distributes them to the individual budget billing due dates.
The standing budget billing amount is entered in the header data of the budget billing plan. This budget billing amount is always used when a budget billing plan is created. If an amount is not entered, the budget billing is determined using the extrapolation document.
© SAP AG IUT230 9-18
SAP AG 2006
20062006
01.11. .... .... .... .... .... .... 01.08.
Billing period20072007
01.09. .... .... .... .... .... .... 01.14.
Budget billing period
Actualmeter reading
Extrapolation of consumption using configured weighting procedure;billing simulation for this period
Next scheduledmeter reading date from scheduling
Distribution of total simulated amount over the budget billing due dates
Distribution of total simulated amount over the budget billing due dates
Quantity-Based Extrapolation
Billing calculates the consumption up until the next scheduled meter reading date. Simulated billing is carried out for the budget billing period. The budget billing items created in this way are transferred to invoicing in the billing document. Invoicing accepts these amounts and distributes them to the individual budget billing due dates.
For this reason, ensure you have generated schedule records for the next billing period before you simulate billing.
© SAP AG IUT230 9-19
SAP AG 2006
Cycle: 02Print date/debit entry date:01.31.200603.31.200605.31.200607.31.200609.31.200611.30.2006
Cycle: 02Print date/debit entry date:01.31.200603.31.200605.31.200607.31.200609.31.200611.30.2006
Scheduling:Definition of the Print Datesfor all Budget Billing Cycles
The payment condition from the contract account is used to determine the due dates for the budget billing plan
Schedule record portion
Cycle: 01Print date/debit entry date:01.31.200602.28.200603.31.200604.30.200605.31.200606.30.200607.31.200608.31.200609.30.200610.31.200611.30.200612.31.2006
Cycle: 01Print date/debit entry date:01.31.200602.28.200603.31.200604.30.200605.31.200606.30.200607.31.200608.31.200609.30.200610.31.200611.30.200612.31.2006
Schedule record portion
Budget billing planDefault cycle: 02
15.02.200615.04.200615.06.200615.08.200615.10.200615.12.2006
Budget billing planDefault cycle: 02
15.02.200615.04.200615.06.200615.08.200615.10.200615.12.2006
Budget Billing Due Dates
The planned budget billing print/due dates for each budget billing cycle are specified in the portion.
Terms of payment from the contract account are referred to to determine the actual budget billing due dates.
Under certain circumstances you should not use the terms of payment to determine the due dates for budget billings. In the Document: Determine Due Date from Payment Conditions event (1330), you can execute a due date determination that differs from the normal bills, and is specificly for budget billing dates.
© SAP AG IUT230 9-20
SAP AG 2006
Water contractJoint
invoice: 2
2. Budget billing plan03.15.06 USD 7004.15.06 USD 7005.15.06 USD 7006.15.06 USD 70....
Electric. contr.Joint
invoice: 1
Gas contractJoint
invoice: 1
1. Budget billing plan03.15.06 USD 15004.15.06 USD 15005.15.06 USD 15006.15.06 USD 150....
Sub-Budg.Bill. Plan03.15.06 USD 5004.14.06 USD 5005.15.06 USD 5006.15.06 USD 50....
Sub-Budg.Bill. Plan03.15.06 USD 10004.15.06 USD 10005.15.06 USD 10006.15.06 USD 100....
Cumulated and Sub-Budget Billing Plan
A joint budget billing plan for two or more contracts is created if these are a required group, that is, if they are always invoiced jointly. A budget billing plan such as this consists of two or more sub-budget billing plans.
A contract that does not have to be invoiced with another contract has a separate budget billing plan.
© SAP AG IUT230 9-21
SAP AG 2006
04.01. 100,--
07.01. 100,--
10.01. 100,--
01.01. 100,--
Budget Billing Planfrom Invoicing (*):
Budget Billing Plan After ActivationOf Advance Payment:
04.01. 100,--
07.01. 100,--
07.01. 100,--
10.01. 100,--
01.01. 100,--
X
X
L
Advance PaymentActivated on: 05.01.2006
Advance PaymentActivated on: 05.01.2006
NewNew
NewNew
Jan. - Mar.
April - June
July - Sept.
Oct. - Dec.
Jan. – Mar.
Consumption/Prepayment PeriodConsumption/Prepayment Period
Jan.- Mar.
April- June
July - Sept.
Oct. - Dec.
(*) Billing period 1.2. - 1.1.4 Budget Billings per Year
(*) Billing period 1.2. - 1.1.4 Budget Billings per Year
Key: X = Prepayment indicatorL = Last due date for prepayment
If necessary, a new budget billing period is generated at the end of the budget billing period
Budget Billing Advance Payments
You can define a budget billing plan to be an advance payment plan (for unreliable customers, for example). S If you do this, an additional due date is inserted into the budget billing plan. The other due dates represent advance payments for the next payment period. The final due date in the budget billing plan is the advance payment for the first payment period in the next billing or budget billing period. It is not cleared when the bill is created for the current billing period.
If a budget billing plan is defined as an advance payment plan then, during invoicing, the new budget billing plan is also created as an advance payment plan.
An advance payment plan can also be deactivated.
© SAP AG IUT230 9-22
SAP AG 2006
Automatic Manual
Percentage- Increase- Decrease- Percent. Rec.
Extrapolation
- Cumulatedbudget billings
- Budget billingper contract
- Budget billingper due date
Messageto thecustomers
Budget Billing Adjustment
The existing budget billing plans in the system can be adjusted either automatically or manually.
Manually adjusting means changing the customer's budget billing amount or due dates.
Automatic adjusting means that a selection of budget billing plans defined by selection parameters can be changed automatically. There are two different methods to choose from:
Adjusting by percentage (increasing, decreasing)
Adjusting by extrapolation
Within rate maintenance and the express transaction for budget billing maintenance, you can make adjustments either manually, or using extrapolation. In the express transaction it is also possible to execute an extrapolation with meter reading results or period consumptions that have not yet been saved.
In the case of an interim billing, you can decide when creating the meter reading order whether the budget billing plans are to be adjusted.
A letter can be sent out automatically to inform the customer of the budget billing adjustment.
© SAP AG IUT230 9-23
SAP AG 2006
OpenBillingsOpen
Billings
OpenInvoices
OpenInvoices
List /Budget Billing Plan Extension
List /Budget Billing Plan Extension
Budget Billing Requests11.15.2006 USD 15012.15.2006 USD 15001.15.2007 USD 15002.15.2007 USD 15003.15.2007 USD 15004.15.2007 USD 15005.15.2007 USD 15006.15.2007 USD 15007.15.2007 USD 15008.15.2007 USD 15009.15.2007 USD 150
10.15.2007 USD 15011.15.2007 USD 150
New Due Dates
Extending a Budget Billing Plan
You can use this report to evaluate open billings (for example, missing/implausible meter reading result) and invoices (for example, outsorted billing) according to certain criteria.
The report shows you a list of all billings and invoicings that are still open.
You can also extend the existing budget billing plan. This means that the system includes new budget billing amount due dates in the budget billing plan.
In the next periodic bills, all due dates from the extended budget billing plan are cleared, and the new budget billing plan starts subsequently.
© SAP AG IUT230 9-24
SAP AG 2006
Budget Billing: 3
Budget billing procedure
Budget billingsBudget billing functions
Budget billing plan
Budget billing cycles
Budget billing due dates
Budget billing printout
Budget billing settlement
© SAP AG IUT230 9-25
SAP AG 2006
Print Document with Print
ItemsSAP Spool
Print ReportPrint Report
Request budget billings
Request budget billings
Create partial billCreate
partial bill
CustomizingForm
CustomizingForm
ContractAccount
Form
ContractAccount
Form
Alternative
Alternative
Raw DataInterface
Budget Billing Printout/Partial Bill Printout: Process
Budget billing change doc.
Budget billing change doc.
With the statistical budget billing procedure, you must create the relevant print documents using the Request Budget Billings report.
With the partial billing procedure, you create the relevant print documents using the Create Partial Bills report. This report also performs debit entry for the documents in FI-CA
Alternatively, you can use the 'Create Budget Billing Change Document' report in the statistical procedure to generate the relevant print documents.
The generated print documents can then be processed using the print report. This report generates the physical bills.
© SAP AG IUT230 9-26
SAP AG 2006
Print budget billing amount by
due date
Print all budget billing amounts on
bill
Budget billing bill 4711Date: 01.02.1999
Budget billing: Electricity 100Budget billing: Gas 70Budget billing: Water 30
-----------Interim sum 200Value-added tax: 15% 30
-----------Final amount 230.00
The budget billing amount of 230 USD is due on 01.15.1999.
Budget Billing Form
You have several options when printing budget billings. You can specify the appropriate settings in a Customizing table.
© SAP AG IUT230 9-27
SAP AG 2006
Budget Billing: 4
Budget billing procedure
Budget billingsBudget billing functions
Budget billing plan
Budget billing cycles
Budget billing due dates
Budget billing printout
Budget billing settlement
© SAP AG IUT230 9-28
SAP AG 2006
Bill 4711 Date: 02.07.06
Valuated consumption +_________+_________+_________
Credit memos/backbillings +/-________
Billamount =========
Paid budget billings -1,278
Items above +/-________
1. Budget billing amount +_________Final bill amount =========
Sub-items +/-________
Amount topay =========
Budget Billing Settlement: Paid Budget Billing Amounts
Paid budget billing amounts are automatically included and posted (only for statistical budget billing)
Budget billing payments are settled using the billing procedure and the billing period as references.
In a move-out with final billing, all of the budget billing payments are taken into account.
In interim billing, only the budget billing amounts that were paid within the billed period are taken into account.
Budget billing plans are deactivated.
The budget billing settlement of paid budget billings in invoicing cannot be set and takes place automatically.
© SAP AG IUT230 9-29
SAP AG 2006
...............
...............
IMG
FI-CA
1. Budget Billing
100 USD
Clearing
Remaining BudgetBilling Amount
40 USD
InvoicingCredit
60 USD
Settlement Control
Example: Remaining Credit
Clearing Control
Settlement with the First/Next Budget Billing Amount: 1
In settlement control, you can settle an oustanding credit from invoicing with either the first or subsequent budget billing amount.
In the partial bill procedure, the first/next partial bill must already have been generated. This can be done within periodic invoicing. You can activate this function in Customizing, under SAP Utilities -> Invoicing -> Invoice Processing -> Define Control of Budget Billing Amounts in Invoicing.
© SAP AG IUT230 9-30
SAP AG 2006
...............
...............
IMG
Utilities Industry
1. Budget Billing
100 USD 02.01.06
No Clearing
Same Due DateBill 120 USD
BB Amount 100 USD02.01.2006
InvoicingReceivable
120 USD 01.15.06
Grouping of Due Dates
Example: Outstanding Receivable
Invoicing
Clearing Against First or Next Budget Billing Amount: 2
If there is an outstanding receivable from invoicing then you can amalgamate the due due dates of the bill, and either the first or subsequent budget billing amount. You make these settings in the IMG for invoicing, and not in clearing control. Clearing control cannot be used in this case, since nothing can be cleared.
© SAP AG IUT230 9-31
SAP AG 2008
Customizing for Budget Billing
Budget billing procedure
Control parameters for budget billing amount
Minimum/maximum budget billing amount
Rounding parameters for budget billing plan
General amount adjustment factors
Budget billing form
Payment plan type
...............
...............
IMG
...............
...............
© SAP AG IUT230 9-32
SAP AG 2008
Budget Billing Amounts: Summary
SAP AG
The SAP Utilities budget billing control supports all known budget billing procedures.
The interface with the SAP Utilities print workbench means that budget billing requests and partial bills can be generated.
The system is based on settlement control, which can be maintained in Customizing.
© SAP AG IUT230 9-33
Exercises
Unit: Budget Billing Topic: Budget Billing Plan
Process a budget billing plan.
Execute a budget billing request run, and a debit entry run.
Create a payment plan.
A customer phones up to change his budget billing amount because the number of people living in the household has changed.
1-1 Business partner TF1201A0## has made the following request.
1-1-1 Adjust the budget billing plan accordingly. Use the following information:
Business partner TF1201A0## New budget billing amount 200.-- USD
1-1-2 Determine the header data of the budget billing plan. Was the budget billing plan created manually or by invoicing? ____________________________________________________________ What is the budget billing plan for this budget billing plan? ____________________________________________________________
1-1-3 What is the tax portion in the next budget billing amount? ____________________________________________________________ How was the budget billing amount determined? ____________________________________________________________
1-1-4 From which billing portion are the original due dates and budget billing cycles generated? ____________________________________________________________ Where do you store the period text for a due date? ____________________________________________________________
© SAP AG IUT230 9-34
1-1-5 A customer always wants to pay the same amount, regardless of his/her consumption pattern. Where do you make the settings to make this possible for the customer? ____________________________________________________________ Do you have to do more than select the field Do not adjust budget billing amount automatically? ____________________________________________________________
1-2 Carry out budget billing request run for a business partner.
1-2-1 The statistical budget billing procedure features a budget billing request report. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. Execute the budget billing request report for business partner TF1201A0##. Use the following information:
Business partner TF1201A0## Selection date 30th April of this year
1-2-2 The budget billing request report creates a print document. You can display the print document from the log.
1-3 Carry out partial bill run for the business partner.
1-3-1 You can use the partial bill report (create partial bills) during the partial bill procedure. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. The report also posts the items in contract accounts receivable and payable. Execute the partial bill report for business partner TF1301A0##. Use the following information:
Business partner TF1301A0## Document date 30th April (plus year of the current budget billing plan) Posting date 30th April (plus year of the current budget billing plan) Selection date 30th April (plus year of the current budget billing plan)
1-3-2 The partial bill report creates a print document. You can display the print document from the log. To view the posting of the budget billing amount in Contract Accounts Receivable and Payable, call the account balance display.
© SAP AG IUT230 9-35
1-4 Optional. In the North American market, budget billing plans are not generally used because North American customers are billed monthly. Payment plan procedures are used instead, which even out a customer's monthly payments. Business partner TF0803A0## wants to use the BBP payment plan procedure.
1-4-1 Business partner TF0803A0## decides to use the budget billing plan procedure. The business partner wants the procedure to start next month. He/she has not yet received a monthly bill for the payment plan. Therefore, enter an amount (obtained from the customer- and in USD) for the last month in the manual history of contract TF0803A0##.
1-4-2 Call the transaction for creating a payment plan using the following data:
Initial data Contract TF08030A## Payment plan category 0001 BBP Start month Next month Save the payment plan the system has proposed.
1-4-3 To determine the balance forward, you must bill and invoice the contract for both the next month, and the month after that. To do this, use the individual bill You must also use the individual bill to enter the meter reading results.
1-4-4 Check the balance forward using the account balance display.
© SAP AG IUT230 9-36
© SAP AG IUT230 9-37
Solutions
Unit: Budget Billing Topic: Budget Billing Plan
1-1 Business partner TF1201A0## has made the following request.
1-1-1 Adjust the budget billing plan accordingly. Use the following information:
Business partner TF1201A0## New budget billing amount 200.--USD
From the SAP menu, choose Utilities Industry Invoicing Budget Billing Plan Statistical/Partial Bill Procedure Change
Select the budget billing plan of business partner TF1201A0##.
Choose Change. Change the amount as described in the exercise. Choose Save and save your changes.
1-1-2 Determine the header data of the budget billing plan. Was the budget billing plan created manually or by invoicing?
Select Header data. You can find the information you need in the BBP crtn type (creation type: budget billing plan) field. What is the budget billing plan for this budget billing plan? Select Header data. You can find the information you need in the field BB Procedure. Select F1 help for this field.
1-1-3 How much will the tax be on the next budget billing amount?
Select a line. Select Budget Billing Amount – Composition.
Use the forward navigation to access the information you need. How was the budget billing amount determined? Select Header data. You can find the information you need in the field billing document number. To display the billing document, double-click on the field. Here, you can analyze the amounts of the document line items that are highlighted in column A (bill line items from budget billing extrapolation). Multiply this amount by the current tax rate and divide this by 12 (11 budget billing amounts + the next periodic bill).
© SAP AG IUT230 9-38
1-1-4 From which billing portion are the original due dates and budget billing cycles generated?
Select Scheduling.
Portion: T-A-00 Where do you store the period text for a due date? These entries are maintained in the schedule records of the accompanying portion T-A-00.
1-1-5 A customer always wants to pay the same amount, regardless of his/her consumption pattern. Where do you make the settings to make this possible for the customer? Select Header data. Maintain data for the standing budget billing amount. Do you have to do more than select the field Do not adjust budget billing amount automatically? No. This field is only interpreted when the automatic budget billing adjustment report is executed.
1-2 Carry out a budget billing request run for the business partner.
1-2-1 The statistical budget billing procedure features a budget billing request report. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. Execute the budget billing request report for business partner TF1201A0##. Use the following information:
From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Mass Processing
Request Budget Billing Amounts.
Choose the selection criteria in the data screen as described in the exercise and execute. The print date in the budget billing plan was set and the due date, April 30 was changed to the system date.
1-2-2 The budget billing request report creates a print document. You can display the print document from the log.
Select Display document.
© SAP AG IUT230 9-39
1-3 Carry out partial bill run for the business partner.
1-3-1 You can use the partial bill report (create partial bills) during the partial bill procedure. The report creates the print documents for the budget billing amounts. This is a prerequisite for the subsequent budget billing printout. The report also posts the items in contract accounts receivable and payable. Execute the partial bill report for business partner TF1301A0##. Use the following information:
From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Mass Processing
Create Partial Bill.
Choose the selection criteria in the data screen as described in the exercise and execute. The print date in the budget billing plan was set and the due date, April 30 was changed to the system date.
1-3-2 The partial bill report creates a print document. You can display the print document from the log. To view the posting of the budget billing amount in Contract Accounts Receivable and Payable, call the account balance display.
Select Display document. From the SAP menu, choose Utilities Industry Contract Accounts Receivable and Payable Account
Account Balance.
© SAP AG IUT230 9-40
1-4 Optional. In the North American market, budget billing plans are not generally used because North American customers are billed monthly. Payment plan procedures are used instead, which even out a customer's monthly payments. Business partner TF0803A0## wants to use the BBP payment plan procedure.
1-4-1 Business partner TF0803A0## decides to use the budget billing plan procedure. The business partner wants the procedure to start next month. He/she has not had a monthly bill so far. Therefore, enter an amount (obtained from the customer- and in USD) for the last month in the manual history of contract TF0803A0##.
From the SAP menu, choose Utilities Industry Invoicing Budget Billing Plan Payment Plan Manual History.
Choose Create. Enter the amount from last month and choose USD as your currency. Save.
1-4-2 Call the transaction for creating a payment plan using the following data:
From the SAP menu, choose Utilities Industry Invoicing Budget Billing Plan Payment Plan Create
Enter your data as specified in the exercise. Save the payment plan the system has proposed.
1-4-3 To determine the balance forward, you must bill and invoice the contract for both the next month, and the month after that. To do this, use the individual bill You must also use the individual bill to enter the meter reading results.
From the SAP menu, choose Utilities Industry Billing Billing Execution Individual Processing
Individual Bill.
In Level of processing, select Display bill. Select the selection criterion Contract and enter the contract TF0803A0##. Select the Enter meter reading results check box and enter 01 in the Meter reading reason field.
Choose Execute.
Repeat the individual bill for the month after next.
1-4-4 Check the balance forward using the account balance display.
From the SAP menu, choose Utilities Industry Contract Accounts Receivable and Payable Account
Account Balance.
© SAP AG IUT230 10-1
SAP AG 2008
Bill Printout
SAP AG 2007
Bill Printout Functions
Print Action Records
Raw Data Interface, Optical Archiving
© SAP AG IUT230 10-2
SAP AG 2006
Bill Printout: Unit Objectives
SAP AG 2006
At the conclusion of this unit, you will be able to:
Describe the concept of bill printout
Explain the hierarchy for billing forms
Outline the bill printout process
Outline the options for sorting bill line items
Describe print action records
Explain the raw data interface and describe the optical archiving options
© SAP AG IUT230 10-3
SAP AG 2006
Bill Printout Functions
Print Action Records
Raw Data Interface, Optical Archiving
Bill Printout: 1
© SAP AG IUT230 10-4
SAP AG 2008
Form Hierarchy
SAPscript Form- Layout- Paragraphs- Character strings- Windows- Page windows
SAPscript Form- Layout- Paragraphs- Character strings- Windows- Page windows
Print workbenchSAP Utilities formPrint workbench
SAP Utilities form
Customer
Account
Contract
Installation
...
...GeneratedPrint Program-represents the form structure-can be changed/ extended byusers
-customer exits
GeneratedPrint Program-represents the form structure-can be changed/ extended byusers
-customer exits
SAP Standard Text- Free texts- Fields
SAP Standard Text- Free texts- Fields
A SAPscript form is allocated to the SAP Utilities form. In the SAPscript form, you determine the layout of the application form (for example, paragraphs, windows, page windows).
Standard SAP texts can be allocated to the individual hierarchy levels. Literals and variables are stored in these standard texts.
The SAP Utilities application form is used to generate an executable print program, which is called from the application.
© SAP AG IUT230 10-5
SAP AG 2006
IS_U_BI_BILLIS_U_BI_BILL
DOC_HEADERDOC_HEADER
DOC_ITEMDOC_ITEM
CONT_ACCTCONT_ACCT
CONTRACTCONTRACT
Text forDOC_HEADERText forDOC_HEADER
Text forDOC_ITEMText forDOC_ITEM
Root Level
Document Level
1:1 Level
Text Level
Form Level
1:1 Level
Text Level
Structure of the Bill Form
The document level (DOC_HEADER) and item level (DOC_ITEM) are the two most important levels in the bill form. Fields such as customer ID, bill number, and due date are available at this level. The item level is run once per billing line item (loop).
In addition to the above-mentioned levels, there are 1:1 levels. These contain additional information such as contract account data or contract data.
One or more text elements can be assigned to each level. These text elements contain user-defined texts (text literals) or fields (variables) that are filled with actual data at runtime.
© SAP AG IUT230 10-6
SAP AG 2006
Bill Form
Bill 4711 Date: 01.02.06
Group Service Device Tax Code Net Amount0001 Energy Price G1 A1 123.450001 Energy Price G2 A1 201.500001 Energy Price G3 A1 300.35Subtotal for Value Added Tax 93.80
0002 Provisioning G1 A1 203.550002 Provisioning G2 A1 344.010002 Provisioning G3 A1 470.89Subtotal for Value Added Tax 152.77
---------- ----------Bill Amount 1643.75 246.57
The final bill amount of 1890.32 USD is due on 01.15.2006.
The next budget billing amounts are due on the following dates:1.1., 3.1., 4.1., 5.1., 6.1., 7.1.,Please pay a budget billing amount of 50.00 USD by these dates.
Sort Order of Billing
Line Items ?????Sort Order of Billing
Line Items ?????
The billing form can be displayed in various ways:
Consumption and amount determination are split up
Presented without groups
Bill line items sorted according to divisions and contract number
Bill line items are sorted according to meter number
With a cover page, detailed description on the following slides
Without a cover page
The print workbench can model any of these requirements. The next few slides will describe how to sort bill line items according to certain criteria.
© SAP AG IUT230 10-7
SAP AG 2006
Print ReportPrint ReportPrint
Document with Print Items
Raw DataInterface
SAP Spool
Bill Printout Procedure
The print documents created in invoicing are then processed using a print report. The output of the print report are the printed bills.
© SAP AG IUT230 10-8
SAP AG 2006
NavigationShipping Control-->Shipping Types
Shipping Control 0001
Shipping Types
12EMAILPRINTER
11
**33
No.Trnsm.mthdPrintoutsRDIArch.Mod.Copy
Shipping Control BPShipping Control alt.BTPShipping Control alt.DR
Contract Account
Print ReportPrint Report
FAXPrinter E-mail R-MailFax
Communication Types in Business Partner
Shipping Control
Shipping control allows you to define options for sending correspondence. For example, you can specify that two copies of a document are to be printed, or that one copy is to be printed and another copy is to be sent by e-mail.
© SAP AG IUT230 10-9
SAP AG 2008
Payment Form Reference
Invoice 4711 Date: 02-Jan-06
Block Service Device Tax Code Net Amt0001 Energy price D1 A1 123.450001 Energy price D2 A1 201.500001 Energy price D3 A1 300.35Value added tax: Subtotal 93.80
0002 Provisioning D1 A1 203.550002 Provisioning D2 A1 344.010002 Provisioning D3 A1 470.89Value added tax: Subtotal 152.77
---------- ---------- Invoice amount 1643.75 246.57
The bill sum total of 1890.32 USD is due on 15-Jan-06. Please transfer the amount using the transfer slip attached.
Bill Receivable
XYZ Municipal Utility
123456 672 500 30
Bank XYZ
1890.32 USD
283764159 4711
Smith, Peter
The payment form number is an internally assigned, unique number that can be allocated to a payment form and that cash payer can use to pay the bill.
The payment form number is allocated regardless of whether a payment form is created during bill printout.
It is saved in the field NRZAS in the print document header.
The payment form number determines which open items are paid with the payment form.
You can select these open items using the payment form number, for example in the cash desk.
Invoicing allocates payment scheme numbers only for cash payers and for bill requests.
© SAP AG IUT230 10-10
SAP AG 2006
Financial Accounting
Basic Settings: Financial Accounting
Correspondence
Attached Payment Medium
CountryFORM IDCountryFORM ID
Function Modulefor Formattingthe Payment
Medium
Function Modulefor Formattingthe Payment
Medium
Company CodeFORM ID
Company CodeFORM ID
SAPscriptForm
SAPscriptForm
FIFI
Posting AreaR401
CoCd FORM ID
Posting AreaR401
CoCd FORM ID1200
Payment MediumOne thousand two hundred
Walldorf, 12/29/94
Bill
Payment Medium
IMG
Das Customizing der Zahlungsträger muss in der Komponente Finanzwesen (FI) durchgeführt werden. Sie finden die relevanten Aktivitäten unter den Grundeinstellungen Korrespondenz Anhängende Zahlungsträger.
Sie können pro Land eine FORM ID definieren. Zusätzlich wird ein Funktionsbaustein angegeben, der die Aufbereitung des Zahlungsträgers landesspezifisch vornimmt (z.B. für DE = PAYMENT_MEDIUM_DE_BANKTRANSFER).
In einer weiteren Aktivität müssen Sie zum Buchungskreis und der FORM ID ein SAPscript Formular angeben, welches für den Druck des anhängenden Zahlungsträgers verwendet wird.
Für die IS-U Fakturierung müssen Sie im Buchungsbereich R401 die zu benutzende FORM ID dem Buchungskreis zuordnen. Die Fakturierung setzt dann die FORM ID in den Belegen, wenn folgende Bedingungen erfüllt sind:
In dem relevanten Buchungskreis ist eine FORM ID hinterlegt
Es handelt sich bei dem zu fakturierenden Vertragskonto um einen Barzahler
Es handelt sich bei der Fakturierung um eine Restforderung
Nur in wenn die o.g. Bedingungen erfüllt sind, dann wird das Feld FORM ID im Druckbeleg gesetzt und der Rechnungsdruck erzeugt zusätzlich zur Rechnung einen Zahlungsträger.
Zusätzlich wird für den Zahlungsträger eine Zahlscheinnummer erzeugt. Diese Nummer kann auch auf den Verwendungszweck angegeben werden. Der Nummernkreis muss definiert sein.
© SAP AG IUT230 10-11
SAP AG 2006
Formatting Bill Printout
Billing document: 3010 - Contract: 1000
Doc. Line Type Presort.Key Tax Code Net Amnt.
IQUANT B1000001 B2 A1 295.20000003 B2 A1 300.00
Bill 4711 Date: 10.22.2006
Consumption contract 1000 11/01/2001 - 10/15/20022460 KWh
Consumption contract 2000 11/01/2001 - 10/15/20026240 KWh
Contract 1000:Energy price: 2460 KWh · 0.12 USD 295.20 USDProvisioning: 12 · 25 USD 300.00 USD Value Added Tax:
95.23 USD
Subtotal: 690.43 USD ___________
Contract 2000:Energy price: 6240 KWh · 0.12 USD 748.80 USD Provisioning: 12 · 25 USD 300.00 USD Value Added Tax:
167.81 USD___________
Subtotal: 1216.61 USD
Final bill amount 1907.04 USD
B1
B2
B2
Sort module: ISU_B
ILL_TYPE_CO
NTRACT
Billing document: 3011 - Contract: 2000
Doc. Line Type Presort.Key Tax Code Net Amnt.
IQUANT B1000001 B2 A1 748.80000003 B2 A1 300.00
Sort Order of Billing Line Items:
Sort all billing line items according to presort key (ascending)
Sort according to VAT code within a presort group (ascending)
Call each sort module in order to create blocks, for example, according to contract.
Calculation of subtotal (SUBTOTAL) according to Customizing settings
Internal workflow for bill sorting and creating subtotals: All billing line items (cross-document) are sorted according to presort key (ERCHZ line sort) and divided into groups with the same presort key. Within these groups, items are sorted again based on VAT codes (ERCHZ-MWSKZ). The resulting groups are then transferred to the separate sort modules. Items are then further sorted within the sort module according to contract, company code or customer-specific, for example. Depending to the Customizing settings, a sub total line item (SUBT) is also generated in the sort module.
© SAP AG IUT230 10-12
SAP AG 2006
Presort Key Function
Billing Document 1 Billing Document 2
Function ModuleISU_BILL_TYPE_CONTRACT
Invoicing
Presort Keys:0001 = Sort according to contract w/o subtotals0002 = Sort according to contract with subtotals
Electric.Presort. Doc.Line Type Contr. Amount0001 IDEMAN 47120001 IQUANT 47120002 000001 4712 12.45 USD 0002 000002 4712 33.78 USD
Electric.Presort. Doc.Line Type Contr. Amount 0001 IDEMAN 47110001 IQUANT 47110002 000001 4711 312.45 USD 0002 000002 4711 31.78 USD
Im vorangehenden Beispiel sind einem Vertragskonto zwei Stromverträge zugeordnet. Im Abrechnungsschema ist den Infozeilen der Vorsortierungsschlüssel 0001 zugeordnet. Den buchungsrelevanten Rechnungszeilen ist der Vorsortierungsschlüssel 0002 zugeordnet.
Im Customizing der Vorsortierungsschlüssel ist den beiden Schlüsseln 0001 und 0002 jeweils der Sortier Funktionsbaustein ISU_BILL_TYPE_CONTRACT zugeordnet. Dieser nimmt eine Sortierung der Rechnungszeilen nach der Vertragsnummer vor.
© SAP AG IUT230 10-13
SAP AG 2006
Presort Key Function - Step 1
Electric.Presort. Doc.Line Type Contr. Amount 0001 IDEMAN 47120001 IQUANT 47120001 IDEMAN 47110001 IQUANT 4711
0002 000001 4712 12.45 USD0002 000002 4712 33.78 USD0002 000001 4711 312.45 USD0002 000002 4711 31.78 USD
Document Line Items SortedAccording to Presort Key(cannot be changed by user)
Presort Keys:0001 = Sort according to contract w/o subtotal0002 = Sort according to contract with subtotal
Print Document
Im ersten Schritt werden die Rechnungszeilen nach dem Vorsortierungsschlüssel an sich sortiert. D.h. die Rechnungszeilen mit dem Vorsortierungsschlüssel 0001 kommen vor den Rechnungszeilen mit dem Vorsortierungsschlüssel 0002.
Diese Sortierung ist vom Benutzer nicht änderbar. Sie kann nur durch die Definition der geeigneten Vorsortierungsschlüssel beeinflusst werden.
© SAP AG IUT230 10-14
SAP AG 2006
Presort Key Function - Step 2
Electric.Presort. Doc.Line Type Contr. Amount 0001 IDEMAN 47110001 IQUANT 47110001 IDEMAN 47120001 IQUANT 4712
0002 000001 4711 312.45 USD0002 000002 4711 31.78 USD0002 000001 4712 12.45 USD0002 000002 4712 33.78 USD
Document Line Items SortedAccording to Contract
(Function Module SU_BILL_TYPE_CONTRACT)
User-Defined => Dependenton Presort Key
Print Document
Presort Keys:0001 = Sort according to contract w/o subtotal0002 = Sort according to contract with subtotal
Im zweiten Schritt werden die Rechnungszeilen nach der Logik im Funktionsbaustein sortiert. In diesem Fall erfolgt eine Sortierung nach der Vertragsnummer. Diese Sortierung wird durch den Funktionsbaustein ISU_BILL_TYPE_CONTRACT vorgenommen.
© SAP AG IUT230 10-15
SAP AG 2006
Presort Key Function - Step 3
Electric.Presort. Doc.Line Type Contr. Amount0001 IDEMAN 47110001 IQUANT 47110001 IDEMAN 47120001 IQUANT 4712
0002 000001 4711 312.45 USD0002 000002 4711 31.78 USD
SubTotal(City Tax) 12.56 USDSubTotal(Country Tax) 15.66 USD
0002 000001 4712 12.45 USD0002 000002 4712 33.78 USD
SubTotal(City Tax) 2.56 USDSubTotal(Country Tax) 5.66 USD
Create subtotal line items when contract changes
(see above function module)
Print Document
Presort Keys:0001 = Sort according to contract w/o subtotal0002 = Sort according to contract with subtotal
Im dritten Schritt werden Zwischensummen eingefügt. Beim Vorsortierungsschlüssel 0002 ist im Customizing angegeben, dass eine Zwischensumme erzeugt werden soll. Das System erkennt einen Gruppenwechsel für den Vertrag und fügt spezielle Zwischensummenzeilen in den Druckbeleg ein.
Pro Abrechnungsschema muss mindestens eine Rechnungszeile mit einem Vorsortierungsschlüssel versehen sein, der eine Zwischensumme erzeugt.
Ziel der Vorsortierungsschlüssel sollte es sein, dass die Rechnungszeilen genau in der zu druckenden Reihenfolge im Druckbeleg hinterlegt werden. Eine spätere Umsortierung im Rechnungsdruck ist aufwendig und evtl. sogar fehlerhaft (z.B. bei der Bildung von eigenen Zwischensummen im Rechnungsdruck).
© SAP AG IUT230 10-16
SAP AG 2006
Bill Printout Functions
Print Action Records
Raw Data Interface, Optical Archiving
Bill Printout: 2
© SAP AG IUT230 10-17
SAP AG 2006
Functions:Reproduce any texts on IS-U application forms
Determine whether additional information (such as flyers) is to be sent out with IS-U application forms
Print Action Records: 1
Druckaktionssätze werden genutzt, um dem Kunden zusätzliche Infomationen auf Schreiben (z.B. Rechnung) mitzuteilen.
Zusätzlich kann gesteuert werden, dass bestimmte Beilagen von der Poststraße dazu sortiert werden.
© SAP AG IUT230 10-18
SAP AG 2008
CustomerReportfor BuildingPrint Action Records
CustomerReportfor BuildingPrint Action Records
FunctionModule
for Writinga PrintActionRecord
Form ClassForm Class
Print ActionRecord
Print ActionRecord
Mass Creation of Print Action Records
Print Action Records: 2
Print action records can also be created in very large numbers (for example, information for all customers with E1 as rate category). The customer must create a report that selects all contracts that have E1 as their rate category. The next step is to create a print action record for each of these contracts. SAP provides you with a function module to do this.
© SAP AG IUT230 10-19
SAP AG 2008
ContractContract
BusinessPartner
BusinessPartner
ContractAccountContractAccount
Print Action Records: 3
Transaction forDisplaying,
Changing, andDeleting
Print Action Records
Transaction forDisplaying,
Changing, andDeleting
Print Action Records
Form ClassForm Class
Print ActionRecord
Print ActionRecord
Creation of One Print Action Record
A print action record always refers to a form class and a business object. By allocating it to a form class, you define on which form the text is to be printed. By allocating it to a business object, you define at which hierarchy level the text is to be printed.
© SAP AG IUT230 10-20
SAP AG 2006
Send rate informationSend collection authorizationSend questionnaire on gas actionText information: Meter replacement in next billing periodText information: GreetingText information: Move-in/out...
Valid from: Valid to:Send x No. of times:Form class:
Send rate informationSend collection authorizationSend questionnaire on gas actionText information: Meter replacement in next billing periodText information: GreetingText information: Move-in/out...
Valid from: Valid to:Send x No. of times:Form class:
Print Action Records: 4
xx
x
01.01.1997 31.12.19971IS_U_BI_BILL
Option ofEntering a User-
Defined Text(Standard SAPText Module)
Option ofEntering a User-
Defined Text(Standard SAPText Module)
Adds FlyerAdds Flyer
Prints an Additional TextPrints an Additional Text
Structure
Print action records are allocated to a certain object (e.g. contract, contract account) and an additional form class. This ensures that a certain text is only printed on the corresponding form, for example, the bill correction text should only be printed on the bill and not on other forms.
You can also save general texts that are frequently reused in a Customizing table.
© SAP AG IUT230 10-21
SAP AG 2006
Bill Printout Functions
Print Action Records
Raw Data Interface, Optical Archiving
Bill Printout: 3
© SAP AG IUT230 10-22
SAP AG 2006
22
11
22
11Print
WorkbenchIS-U
ApplicationForm
PrintWorkbench
IS-UApplication
Form
SAPscriptform
(layout, text,data)
SAPscriptform
(layout, text,data)
ApplicationApplication PrintProgram
PrintProgram
Spool file
Alternative
External systems• Mass data• Mailroom system• Postage determination• Sort• Creation of layout
External systems• Mass data• Mailroom system• Postage determination• Sort• Creation of layout
Raw data interface
Com
plete formfor online printing
Generates
Net form
for raw data interface
Concept of Raw Data Interface
An interface is available for printing mass data or for additional optimal processes, such as postage determination, sorting for delivery, and use of barcodes for mail processing. Output can be transferred to the raw data interface instead of to the SAP spool file.
SAPscript can be used in two ways to generate forms:
Online using a spool file
- for generating immediate bills
Raw data interface
- for transferring information to an external system SAP recommends this solution for mass printing.
© SAP AG IUT230 10-23
SAP AG 2008
Bill Printout: Summary
SAP AG
Integration with the SAP Utilities print workbench allows you to create bills.
The bill line items can be sorted according to individual requirements.
Using the print action records, you can include individual or standard texts on a bill.
Bill printout processes the print document and writes data to the spool file or to a raw data interface.
Bill printout provides the option of optically archiving bills.
© SAP AG IUT230 10-24
© SAP AG IUT230 10-25
Exercises
Unit: Bill Printout Topic: Bill Printout
Be able to print and reprint a bill.
Be able to create a print action record.
A customer received a bill and has mislaid it. He/she would like to have a new copy of the bill sent to him/her. You will also create a print action record for another customer.
1-1 How do you display a record in the system?
1-1-1 List the menu paths. ____________________________________________________________
1-2 Reprint the last bill for the business partner TF0701A0##. You have already performed billing and invoicing for this business partner in exercise 7-1.
1-2-1 Which menu path would you use to reprint a bill? ____________________________________________________________
1-2-2 Carry out the procedure for reprinting a bill. Use the print report. Note that you can only carry out the procedure for reprinting a bill if the original bill was already printed.
1-3 Create a print action record for a business partner. The customer is to be informed on his next bill that he is being billed with a new rate.
1-3-1 Create a print action record for the business partner TF0703A0##. Use the ISUPARTNER object type and the IS_U_BI_BILL form class. Enter your own text.
1-3-2 Which object types and form classes are supported by the print action records at present? ____________________________________________________________
© SAP AG IUT230 10-26
© SAP AG IUT230 10-27
Solutions
Unit: Bill Printout Topic: Bill Printout
1-1 How do you display a record in the system?
1-1-1 List the menu paths.
From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Display Print Document. Under this menu path there are various options: Display line items, simulate bill, display bill from optical archive.
From the SAP menu, choose Utilities Industry Customer Service Front Office/Customer Interaction Center Customer Interaction Center Customer overview. Double-click Bill or the display function from the optical archive.
1-2 Reprint the last bill for the business partner TF0701A0##. You have already performed billing and invoicing for this business partner in a previous exercise.
1-2-1 Which menu path would you use to reprint a bill?
From the SAP menu, choose Utilities Industry Invoicing Invoice Processing Mass Processing
Print out Print Document.
From the SAP menu, choose Utilities Industry Customer Service Front Office/Customer Interaction Center Customer Interaction Center Customer overview
Edit Reprint bill. This function will print the original bill if this has not already occurred. Otherwise the bill is reprinted
© SAP AG IUT230 10-28
1-2-2 Carry out the procedure for reprinting a bill. Use the print report. Note that you can only carry out the procedure for reprinting a bill if the original bill was already printed.
Enter 01 (Print consumption billing) as the creation reason. Select the posted documents. Then you can maintain the print parameters by choosing Print parameters.
Find the most recent print document for the business partner TF0701A0## using the F4 search help.
Define the print parameters.
Enter 01 as the creation reason and select the Document posted checkbox.
When reprinting bills you must enter a date in the print date field. Otherwise it is a print of the original bill. You can find the print date in the header data of the print document. You can also enter a range (print date from – to).
Choose Execute.
1-3 Create a print action record for a business partner. The customer is to be informed on his next bill that he is being billed with a new rate.
1-3-1 Create a print action record for the business partner TF0703A0##. Use the ISUPARTNER object type and the IS_U_BI_BILL form class. Enter your own text.
From the SAP menu, choose Utilities Industry Tools Print Workbench Print Action Records
Create.
Select the ISUPARTNER object type and the IS_U_BI_BILL form class. Enter the business partner number as the object key.
Press Enter.
Enter a short description of the print action record in the description field. To enter your own text, you must first save. After you save, a create icon will appear in the Individual text field. Clicking on this icon takes you to a screen where you can enter your individual text. Enter your individual text. Save the text. Go back to the print action record.
Save your entries.
© SAP AG IUT230 10-29
1-3-2 Which object types and form classes are supported by the print action records at present?
ISUACCOUNT IS_U_BI_BILL ISUACCOUNT IS_U_BI_COLLECTIVE_BILL ISUCONTRCT IS_U_BI_BILL ISUCONTRCT IS_U_BI_COLLECTIVE_BILL ISUPARTNER IS_U_BI_BILL ISUPARTNER IS_U_BI_COLLECTIVE_BILL
© SAP AG IUT230 10-30
© SAP AG IUT230 11-1
SAP AG 2008
Special Billing Features
SAP AG 2007
This unit will prepare you to:
Describe the various franchise fee procedures
Explain gas billing with SAP Utilities
List deregulated contracts with the liberalization of new markets
Explain how reference values and street lighting are billed
Perform archiving tasks
Describe special types of billing
© SAP AG IUT230 11-2
SAP AG 2006
At the conclusion of this unit, you will be able to:
Describe how franchise fee procedures are supported by the system
Explain the different types of gas billing
List the master data required for billing deregulated contracts
Explain the functions of reference values and street lighting
Archive billing data
Describe special types of billing
SAP AG 2006
Special Billing Features: Unit Objectives
© SAP AG IUT230 11-3
SAP AG 2006
Franchise Fee
Gas Billing
Reference Values/Lighting
Billing Deregulated Contracts
Archiving Billing Data
Special Types of Billing
Special Billing Features: 1
© SAP AG IUT230 11-4
SAP AG 2006
Quantity
Amount * FF Factor
FF Price
=
=
FFAmount
FF based on a quantity and an amount (electricity and gas divisions)
FF based on an amount and a percentage ratewithout price grouping
FFAmount*
Amount FF Factor =
FF based on an amount and a percentage rate (water division)with price grouping
FFAmount*
Franchise Fee Procedure in Germany/N. America
There are several franchise fee procedures:
In Germany, an amount procedure is used in the electricity division. The franchise fee is included in the price on the bill. Conversely, a percentage procedure is used in the water division. In this case, the franchise fee is also included in the price on the bill.
A percentage procedure is also used in North America but the franchise fee is listed separately on the bill.
© SAP AG IUT230 11-5
SAP AG 2006
Net Procedure Gross Procedure Max. Gross Procedure
Price incl. FF Price incl. FF Price incl. FF
Price TablePrice incl. FF
Price TablePrice incl. FF
FF-Contract-Amount
Amount < Max.
Max. - Amount
Franchise Fee Procedure
FF-Contract-Amount-Max.
PriceTable
+ -
A franchise contract establishes the duties that a utility company must pay to a particular political entity. In return, the utility company receives the right to supply energy directly to customers in the municipality and may use public traffic routes for installing and operating lines.
Three different procedures are supported in the system:
Net procedure: The prices in the price definition are net prices without a franchise fee contribution. The franchise fee contribution is determined via the franchise contract.
Gross procedure: The franchise fee contribution is included in the prices.
Maximum gross procedure: The franchise fee contribution is already included in the price. A maximum franchise fee amount is determined in the franchise contract. If a franchise fee is not charged by the municipality, the price is reduced accordingly for the customers. If municipalities receive a franchise fee from the utility company that is higher than the maximum tax contained in the price, the customer is only charged the maximum price.
© SAP AG IUT230 11-6
SAP AG 2008
Installation(FF Contract) Premise PremiseConnection
Objectconsumption
stelleRegionalStructure
Rate Steps
Franchise Fee Group
Prices
FF ContractFF Procedure
Franchise Fee GroupFF Amnts, FF Contribution
Rate
PricesFF Amounts Can
Be Overriden
Franchise Fee: Data Retention
You must create a franchise contract separately. A franchise contract always refers to the municipality with which it is agreed. It also contains the supporting procedure (net, gross, or max. gross procedure) and the franchise fee amounts or franchise fee contributions (factors).
When you create an installation, the regional structure suggests a franchise contract, which is then stored in the installation. This improves performance considerably, as the system does not have to look for the contract in the regional structure. If there is no franchise contract in the installation, the franchise fee cannot be calculated.
In the rate steps, you define whether an amount procedure (used in Germany in the electricity division for example), a percentage procedure with price grouping (Germany, water), or a percentage procedure without price grouping (USA, Canada) is used.
The franchise fee group in the rate steps is used to determine the relevant franchise fee amount or contribution in the franchise contract. Usually, you do not define a value for the franchise fee in the price keys or factors. In exceptional cases, you can define a value there, which then overrides the amounts or contributions defined in the franchise contract.
There are specific variant programs available to you (COMPUT13, 14, 15, 16, and 19), which can split up prices using a factor.
© SAP AG IUT230 11-7
SAP AG 2006
Franchise Fee
Gas Billing
Reference Values/Lighting
Billing Deregulated Contracts
Archiving Billing Data
Special Types of Billing
Special Billing Features: 2
© SAP AG IUT230 11-8
SAP AG 2008
Volumetric Gas Billing
Thermal Gas Billing
Gas Billing According to Standard Cubic Meters
Gas Procedure
In gas billing, the measured operating volume of a gas is evaluated to determine the actual billing quantity. Each register of a gas meter is assigned a gas procedure that defines how the gas volume will be evaluated. Gas billing types include:
According to standard cubic meters Operating cubic meters are converted into standard cubic meters using the gas volume correction factor.
Thermal Operating cubic meters are converted into a heat quantity using the volume correction factor and the calorific value.
Volumetric The operating cubic meters measured are billed directly.
© SAP AG IUT230 11-9
SAP AG 2006
Measured Operating Cubic Meters
*Volume Correction Factor
=Standard Cubic Meters
*Calorific Value
=Heat Quantity
Gas Procedure=
(Volume Correction Factor Procedure, Calorific Value Procedure)
Gas Procedure=
(Volume Correction Factor Procedure, Calorific Value Procedure)
Thermal Gas Billing
In thermal gas billing, the measured operating cubic meters are multiplied by the volume correction factor to determine the standard cubic meters. In turn, the standard cubic meters are multiplied by the calorific value to determine the heating quantity (such as kWh) that is to be billed.
In IS-U, the system determines the volume correction factor in the volume correction factor procedure. The calorific values are defined in the calorific value procedure. The volume correction factor procedure and the calorific value procedure combine to produce a gas procedure.
© SAP AG IUT230 11-10
SAP AG 2008
Gas Billing
Gas ProcedureEntry at Register Level
Modeling in Customizing
Calorific Value Procedure
• Defined Calorific Value• Calculation of Arithmetic Average• Calculation of Weighted Average
VCF Procedure
• Defined Volume Correction Factor• Calculated Volume Correction Factor• Special Procedure
CustomizingCustomizing CustomizingCustomizing
Calorific value procedure The following procedures are available for averaging the calorific value:
Arithmetic annual average The calorific values of the last 12 months are arithmetically averaged.
Weighted annual average The calorific values of the last 12 months are multiplied by the respective sendouts of each month. The sum of the products is divided by the total sendout during the 12 months. This results in the weighted annual average of the calorific values.
Arithmetic average of the billing period The calorific values of the months in the billing period are arithmetically averaged.
Weighted average of the billing period The calorific values of the months in the billing period are multiplied by the respective sendouts of each month. The sum of the products is divided by the total sendout during those months. This results in the weighted average of the billing period.
Volume correction factor procedure The volume correction factors (VCFs) allow you to convert volumetric gas consumption into standard cubic meters. The VCF is determined using the following components: temperature, air pressure, measured pressure, and the gas law deviation factor. In the VCF procedure, the system determines which components of the VCF play an important role in gas billing. If you choose volumetric gas billing, you do not have to maintain the components and activities of the VCFs.
© SAP AG IUT230 11-11
SAP AG 2008
PremiseConnection Object
PostalRegional Structure
RegisterRegister
• Calorific Value District• Air Pressure Area• Temperature Area• Gas Pressure Area CustomizingCustomizing
Gas Procedure
Calorific Value
Volume Correction Factor
=
+
• No Thermal Gas Factors• Temperature• Temperature and Pressure• Temperature, Pressure and
Gas Law Deviation Factor
Installation Edit Help
Time-Dependent Data- Rate Category- Temperature Area
Gas Billing Type• Thermal• Volumetric• According to Standard
Cubic Meters
Gas Billing Type• Thermal• Volumetric• According to Standard
Cubic Meters
Installation
Gas Billing: Overview
Installation StructureGas Procedure
Fixed Temperature
Postal regional structure Regional data that influences billing for thermal gas billing can be stored in the postal regional structure. This data can be individually adjusted in the installation or installation structure.
Installation The rate category defines the type of gas billing.
Installation structure The gas procedure is defined here. It specifies how the calorific value and volume correction factor are determined.
Register description The register description defines which factors are already taken into account for gas billing.
© SAP AG IUT230 11-12
SAP AG 2006
CustomizingCustomizing
Basic Functions
Master Data
Device Management
Contract Billing
Invoicing
FI-CA
Customer Service
Work Management
Information System
Tools
SAP UtilitiesSAP Utilities
Special FunctionsSpecial Functions
Gas BillingGas Billing
Volume Correction FactorVolume Correction Factor
Calorific ValueCalorific Value
Gas ProcedureGas Procedure
Allocation DataAllocation Data
Temperature, measured pressure, monthly/annualair pressure, defined VCF,VCF Procedure
Calorific value district, monthly/annualcalorific values, cogenerators,billing calorific values, calorific value procedures
Gas Billing: Customizing
Temperature The system either uses gas temperatures measured monthly or daily, or a fixed temperature.
Gas procedures The gas procedures group the volume correction factor procedure and the calorific value procedure.
Allocation data Here you can use the 'deviation' and 'default' fields to control how the gas month is to be defined. This is particularly relevant for entry of meter reading results.
© SAP AG IUT230 11-13
SAP AG 2006
Volume Correction Factor
Air Pressure
Gas Temperature
Gas Pressure
Gas Law Deviation Factor, calculated using pressure and temperature
Calorific Value
Gas Billing Components
The gas law deviation factor is a ratio of the real gas factors of the gas in operating and standard conditions. It can be determined using the following methods:
Specified for each device
Calculated using pressure and temperature
© SAP AG IUT230 11-14
SAP AG 2008
ST AP + Act.P 1VCF = ------- x ------------------- x -------
T SP GLDF
Temperature
Volume Correction Factor: 1
Standard temperature ST = 273.13 K
Standard air pressure SP = 013.25 mbar
Gas temperature T = ST + Gas temperature in °C
Air pressure AP
Actual pressure Act.P
Operating cubic meters Operating volume
Gas law deviation factor GLDF
Volume correction factor Ratio between standard and operating volume
Billing quantity Standard volume x Calorific value
© SAP AG IUT230 11-15
SAP AG 2006
The following applies:MP = Measured pressure of the meterAP = Air pressureSP = Standard air pressureGLDF = Gas law deviation factorTo = Zero degrees on the temperature scale in use (Celsius or Fahrenheit)defined in absolute units (273.15 Kelvin or 460 Rankine) ST = Standard temperature (in absolute units, that is, Kelvin or Rankine)t = Gas temperature in a non-absolute unit (Celsius or Fahrenheit)
Standard Temperature in Absolute Units Zero Temperature in Absolute Units
VCF = ST * (MP + AP) / ((To + t) * SP * GLDF)
Volume Correction Factor <--> Temperature
Volume correction factor (VCF) SP and ST refer to standard physical conditions. In the metric system, the standard conditions in example 1 usually apply; in countries with non-metric systems, the standard conditions in example 2 can also apply. The constants To and ST are used to adjust the above formula so that you can enter the gas temperature t in the units of measure used in that country (such as degrees Celsius or Fahrenheit) into the corresponding temperature tables.
Example 1 Metric system: Gas temperature in degrees Celsius. The following values apply: ST = 273,15 Kelvin and To = ST = 273,15 Kelvin. In the temperature tables, t is maintained in degrees Celsius.
Example 2 English (imperial) system: Gas temperature in degrees Fahrenheit: The following values apply: ST = 520 Rankine and To = 460 Rankine (zero on the Fahrenheit scale). In the temperature tables, t is maintained in degrees Fahrenheit.
© SAP AG IUT230 11-16
SAP AG 2006
Arithmetic Annual Average
Weighted Annual Average
Fixed Temperature
Arithmetic Average for the Billing Period
Weighted Average for the Billing Period
Arithmetic Annual Average
Weighted Annual Average
Fixed Temperature
Arithmetic Average for the Billing Period
Weighted Average for the Billing Period
Temperature Procedure
© SAP AG IUT230 11-17
SAP AG 2008
ST AP + Act.P 1VCF = ------- x ------------------ x -----
T SP C
Pressure
Volume Correction Factor: 2
© SAP AG IUT230 11-18
SAP AG 2006
Annual Air Pressure
Air Pressure Measured each Month
Arithmetic Average for the Billing Period
Weighted Average for the Billing Period
Air Pressure
© SAP AG IUT230 11-19
SAP AG 2008
ST AP + Act.P 1VCF = ------- x ------------------- x -----
T SP C
Gas Law Deviation Factor
Volume Correction Factor: 3
© SAP AG IUT230 11-20
SAP AG 2008
Gas Law Deviation Factor
At Device/Register Level
Taking Temperature and Pressure into Account
User Exit
Not Taken into Account
Not calculated explicitly in IS-U
Compressibility
Gas law deviation factor (GLDF) The following options are supported for calculating the GLDF:
per device The defined GLDF is maintained at register level.
using pressure and temperature Here, you must maintain the GLDF table with a sufficient range of values of GLDFs and their corresponding pressure and temperature values.
using a user exit A user exit is called up and is provided with all the essential parameters such as pressure and temperature. The user exit returns the compressibility. For example, this allows you to use the GERG88 or AGA-NX19 procedure in the user exit.
The GLDF not taken into account
Note that the GLDF is never calculated directly in IS-U. It must always be calculated using one of the above options.
© SAP AG IUT230 11-21
SAP AG 2006
Arithmetic Annual Average
Weighted Annual Average
Arithmetic Average for the Billing Period
Weighted Average for the Billing Period
Calorific Value Procedure
© SAP AG IUT230 11-22
SAP AG 2006
RegisterFixed Temperature
Gas Procedure
Rate CategoryType of Gas Billing (Thermal, Volumetric, According to Standard Cubic Meters)
Regional StructureDefault Value for Device Installations
Air Pressure Area
Temperature Area
Calorific Value District
Relevant Master Data
© SAP AG IUT230 11-23
SAP AG 2006
Franchise Fee
Gas Billing
Reference Values/Lighting
Billing Deregulated Contracts
Archiving Billing Data
Special Types of Billing
Special Billing Features: 3
© SAP AG IUT230 11-24
SAP AG 2006
Street lighting is billed using reference values from the installations facts
REFVAL04REFVAL05REFVAL06
REFVAL04REFVAL05REFVAL06
Variant Programs
Group ManagementIndividual ManagementDifferent Connection LoadsBilling Using Energy PricesBilling Using Demand Prices
Lighting
Group management: all lighting can be managed as one group. Lighting with specific connection loads are stored and billed together.
Individual management: in contrast to group management, each light is managed and linked to the regional structure separately.
Different connection loads: the connection loads of a light are divided into different operation modes. You can enter the following connection loads for a light:
Demand for 24 hour lighting
Demand for the whole night
Demand for half the night
Billing using energy prices: The energy consumed by the street lights can be measured or calculated. A burning hour calendar can be used for storing monthly lighting periods. Lighting duration can be subdivided according to usage type and operation type in the calendar.
Billing using demand prices: lighting demand is determined and evaluated using connection loads.
© SAP AG IUT230 11-25
SAP AG 2006
Required in order to calculate charges that are not based on measurements
Stored in the installation facts
The following types of reference value exist:General reference values, for example for energy or water supply (connection loads, no. of people, floor area)
Lighting
Heating Installations
Installation Facts: Reference Values
You can define which type of reference value is dealt with here. Different fields are available in the transaction maintenance depending on what you define here.
© SAP AG IUT230 11-26
SAP AG 2006
Lighting: The different values for operation types are used in the burning hour calendar.
Value 2 = value for billingIf you only specify value 1 (= entry value), then value 2 = value 1
Indicator: Not relevant for billing
Repetition factorFor example: Lighting of the same type
Rate type/rate fact group
Reference Values: Data Relevant to Billing
Value 1 is the entry value, or the installed value. It can be different from value 2, the value to be billed.
The repetition factor indicates how many reference values of the same type exist (such as lighting). These reference values do not have to be specified individually. However, if you wish to enter details about reference values (such as the address of the lighting), you must enter them individually. The value specified in the Value 2 field is multiplied by the repetition factor.
© SAP AG IUT230 11-27
SAP AG 2006
Franchise Fee
Gas Billing
Reference Values/Lighting
Billing Deregulated Contracts
Archiving Billing Data
Special Types of Billing
Special Billing Features: 4
© SAP AG IUT230 11-28
SAP AG 2008
Distribution
Procurement
Transmission
DistributionDisposal
Transmission
SupplyProcurement
Distribution
Trans-mission
GenerationProcurement
AdditionalAdditionalDivisionsDivisions
For example:For example:Local heatingLocal heating
Public transportPublic transportCable TVCable TV
Waste removalWaste removalSale of appliancesSale of appliances
. . . . .. . . . .
Usually jointUsually jointcustomer service/billingcustomer service/billing
C o n t r o l l i n gInternal company structure according to plants, clients, and groups
Usuallyjointmeter reading
Customer100100
T o t al
S a a le s T a x
S u b t o ta l
S A L E S P E R SO ND A T E
TotalP r ic eD e s c ri pt i onQ ty S h i pp e dQ ty Or d er e d
I N VO I C E #: P .O . #:
Kunde VbrStelleBillBill
bet weenbet weenXXXXXXXXXXXXXXXXXX
andandEVU AGEVU AG
nnnn n nn nn n nn nn n nn nn n nn n nn nnnn nn n nn nnn nn nn n nn nn n nn n nn nnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kuuuu u uu uu u uu uu u uuuu u uu u uuuu uu u uu uu u uu uu u uu uu u uu u uu
zzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzz
bet weenbet weenXXXXXXXXXXXXXXXXXX
andandEVU AGEVU AG
nn nn n nn nnn nn nn n nn nn n nn n nnnnnn nn nnn nn n nn nn n nn nn nnn n nn nnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kuu uu u uu uuu uu uu u uu uu u uu u uuuu uuu uu uu u uu uu u uu uu uuu u uu
zzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzz
bet weenbet weenXXXXXXXXXXXXXXXXXX
andEVU AGEVU AG
nn nn n nn nn n nn nn n nn nn n nn n nn nnnn nn n nn nn n nnnn n nn nn n nn n nn nnmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkkkk kkkk kkkk kkkk kkkk kkkk kkkk kuu uu u uu uu u uu uu u uu uu u uu u uuuu uu u uu uu uuu uu u uu uu u uu u uu
zzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzz zzzzzzz
betweenbetween< Customer >< Customer >
andand< Utility Company >< Utility Company >
MRresults
MRresults
Distribution
Transmission
GenerationProcurement
Structures of a Regulated Utility Company/Municipal Utility
In Germany, there are many more municipal utility companies providing various types of utilities and complementary services than in any other country. Some of them have managed to integrate as many as 7 different types of utilities and services in the one utility company.
They integrate all their services on one annual bill.
However, the liberalization of the energy market causes complex problems for these companies, as each area of the company develops differently in a deregulated market.
© SAP AG IUT230 11-29
SAP AG 2006
OneDivision
SeveralDivisions
SingleUCs
SeveralUCs
StandardBilling
StandardBilling
Multi-SectorBilling
Multi-SectorBilling
UnbundledBilling
UnbundledBilling
ConvergentBilling
ConvergentBilling
UC: Utility company
Standard Billing: Standard Billing: Billing of one division for services rendered by one utility companyMultiMulti--Division Billing:Division Billing:Billing of several divisions for services rendered by one utility company
Unbundled Billing: Unbundled Billing: Billing of basic services from one division for services rendered by several utility companies
Convergent Billing: Convergent Billing: Billing of several divisions or several basic services from one division rendered by several utility companies.
. . . . In one system, and if desired on one bill!
Billing Scenarios
Two of the billing types above have already been mentioned:
Standard billing: billing of one division for services rendered by one utility company.
Multi-division billing: billing of several divisions for services rendered by one utility company
Two more types of billing are included in the deregulated utilities industry:
Unbundled billing: billing of basic services from one division for services rendered by several utility companies
Convergent billing: billing of several divisions or several basic services from one division rendered by several utility companies
And an important condition: in one system and, if desired, on one bill!
© SAP AG IUT230 11-30
SAP AG 2006
OneDivision
SeveralDivisions
SingleUCs
SeveralUCs
StandardBilling
Multi-SectorBilling
UnbundledBilling
UnbundledBilling
ConvergentConvergentBillingBilling
UC: Utility Company
Example:
Home ElectricityProvider
Home ElectricityProvider
Cx/Electricity/Energy . . . . . . . USDC1/Electricity/Distribution. . . . USDC1/Electricity/Cust. Service. . . USDTP/Cont. to standard assets. . .USD---------------------------------------------Total: . . . . . . . . . . . . . . . . . . . USD
Bill Mr. Smith/<Address>Energy Supply Service:
CompetingElectricityProvider
CompetingElectricityProvider
C1 Cx
Billing Scenarios: Unbundled Billing
Example of unbundled billing:
Two utilities, the home utility C1 and the competing utility Cx, both provide electricity services.
Both utilities agree that C1 has lost a customer to Cx, but that C1 will remain responsible for distribution and customer service for that customer.
Example: C1 is responsible for the billing process and creates a bill.
On the bill, the green row displays energy generation by Cx.
The two blue lines display distribution and customer service by C1.
In the gray line on the bill, there is an additional charge for the customer's contribution to standard assets. This charge is processed by another company, TP.
Result: This bill contains business volume for three different companies.
© SAP AG IUT230 11-31
SAP AG 2008
BusinessPartner
BusinessPartner
ContractA/R & A/PContractA/R & A/P
Installation 1Installation 1
DeviceDevice
Contract 1Contract 1
Installation 2Installation 2
Contract 2Contract 2
BillingRelatedInstallation
BillingRelatedInstallation
Contract 1 with home electricity providerBilling of transmission charges in company code 0001
Contract 2 with SuppliersBilling of supplied energy in company code 0002
DeviceLocationDevice
LocationTechnical Installation
MMM
SupplierSupplierMMM
IDEIntercompanyData Exchange
Home ElectricityHome Electricity
Deregulation in the IS-U Data Model 1
IS-U uses separate contracts and installations to model components of a contract that apply to a single division, but belong to different companies and in turn to different company codes.
The device is installed in one installation along with its technical data.
The device is installed in an additional installation, along with its rate data with another company code.
The contracts can now be billed individually or jointly in one bill.
Using the IDE component (Intercompany Data Exchange), you can create IDocs for the supplier when certain events occur (such as bill creation, incoming payments). This component can also process IDocs coming in from the suppliers.
© SAP AG IUT230 11-32
SAP AG 2008
Installation 1Installation 1
DeviceDevice
Contract 1Contract 1 PoDService
PoDService
BillingRelatedInstallation
Contract, distributionof grid usage costs to billing
Point of delivery service 'utility'
DeviceLocationDevice
LocationTechnical Installation
BusinessPartner
BusinessPartner
ContractAccountContractAccount
PoDPoD
Distributor View
Deregulation in the IS-U Data Model 2
© SAP AG IUT230 11-33
SAP AG 2006
Separation of Device Management and BillingSeparation of Device Management and Billing
Device Info Record
Used in the billing-oriented approachContains only device data that are relevant for billing
PM functions are not available
Acts like a technically installed deviceDevice allocations and register relationships are possible
Proration in the case of final billing-related removal
Serial numbers and meter reading processing handled like normal devices
Created directly or at the time of billing-related installation
© SAP AG IUT230 11-34
SAP AG 2006
Advantages of Separation
Separation of Device Management and Billing
Reduced range of CCS functions for energy service providers
Reduced range of CCS functions for meter operators/system operators
Reduced system overhead costs and required quantity of data
Simultaneous use of different points of delivery
Sequential use of same point of delivery
High-performance IDE supports data exchange
© SAP AG IUT230 11-35
SAP AG 2008
EquipmentDevice
EquipmentDevice
MaterialDevice
Category
MaterialDevice
Category
PremisePremise
RegionalStructureRegionalStructure
InstallationInstallation Technical LocationConnection Object
Technical LocationConnection Object
Installation Structure
Installation Structure
Billing-Related Device
Installation
Device Installation: Device Information Record
In the device installation, you can automatically create the device info record using the billing-related installation. This means that a technical installation in a device location is unnecessary. Using the billing-related device installation, you can maintain rate data at installation structure level for points of delivery or devices.
© SAP AG IUT230 11-36
SAP AG 2006
Franchise Fee
Gas Billing
Reference Values/Lighting
Billing Deregulated Contracts
Archiving Billing Data
Special Types of Billing
Special Billing Features: 5
© SAP AG IUT230 11-37
SAP AG 2006
R/3 DBR/3 DB
Application Data
Archiving Session
Archiving Program of the "Archiving Object"
R/3 Database Archive Files
Offline Storage
The Archiving Process: Overview
For further information, go to the SAP Help Portal at http://help.sap.com
Generating archive files: The archiving program writes the data to be archived, which is stored in the R/3 database, to the archive files. Deleting data: The delete program imports the data from the archive file and then deletes it from the database.
When implementing an archiving strategy, you should also consider how the archive files are stored. The archive files must be stored at a secure location so that, if required, they can be accessed at any time.
© SAP AG IUT230 11-38
SAP AG 2006
Franchise Fee
Gas Billing
Reference Values/Lighting
Billing Deregulated Contracts
Archiving Billing Data
Special Types of Billing
Special Billing Features: 6
© SAP AG IUT230 11-39
SAP AG 2006
Employee Billing
Company and Plant Consumption
Small Power Producers/Cogenerators
Special Types of Billing
Employee billing Utility company employees can be billed at a discount. The discount may apply to prices, flat rates, free quantities, etc. An interface to a payroll system (such as HR) to determine the imputed income is not yet available.
Company and plant consumption The utility company's own consumption is divided into company consumption, which is the energy a utility uses for its own purposes (such as lighting an office building), and plant consumption, the energy used in the production and distribution of energy. Both types of consumption can be billed with the standard IS-U billing functions. For internal accounting purposes, the costs of company and plant consumption can be allocated to different cost centers.
Small power producers/co-generators The utility company may also be supplied with power from a number of different types of power producers, such as hydroelectric or solar power plants. These companies are called small power producers. Energy purchasing and energy supply are billed similarly in IS-U, using similar means of bill creation. The bill for energy purchasing and the bill for energy supply are created at the same time.
© SAP AG IUT230 11-40
SAP AG 2006
Controlling the Gross Price in the Schema
Ensures that the billing line items contain gross prices. The tax is not calculated.
Data: T-F-0022 Schema: E6
A billing schema contains rates, variant programs, and operands. You determine the following in a billing schema: the rates for billing, the schema steps used, and the sequence in which the schema steps are to be carried out.
A billing schema can contain more rates than are actually required to bill a certain installation. For this reason, a billing schema can, for example, contain two rates (off-peak and on-peak rate), even though the installation only has one single-rate meter. In this case, only the on-peak rate is billed. The off-peak rate specified in the schema is ignored.
© SAP AG IUT230 11-41
SAP AG 2008
Price Definition Rate Data
Prices andRate FactsPrices andRate Facts
Schema
Rate VarProg. ValuesRate 1
. . .
- Step 1 VarProg. A x1- Step 2 VarProg. B x2
. . .Rate 2
- Step 1 VarProg. A Gross Price
- Step 2 VarProg. C Gross Price
- Step 3 VarProg. A Net Price
- Step 4 VarProg. C Net PriceRate n
- Step 1 VarProg. A xxx
Price
Rate 1
Rate n
. . . . . .Generate
BillingLine Items
Check BillingResults
Execute Variant
Programs in Acc. with Schema
Net Price
and
Gross Price
GrossGroup
GrossLine It.
XZXZ
Gross Price Billing
The GROSS GROUP combines all the prices that are processed in different variants. These prices are components of gross prices. Each gross group can only have one variant for processing a gross price. For these variants, you must select the Gross line item field in the schema, and the corresponding price must be a gross price.
If you want to process the gross price, you must select the Gross line item field in the price schema.
© SAP AG IUT230 11-42
SAP AG 2006
Gross GroupGross Line Items
Net PriceNet Price
Variant Pr. Operand Gross Group Gross Line It. Relevant for PostingQUANTI01 BPreis ABC X EMPTY QUANTI01 NPreis ABC EMPTY X QUANTI01 KAbgabe ABC EMPTY X
Gross PriceGross Price
Sample Schema
The presort key stored in the billing documents (determined from the billing schema) for the printing the billing documents must refer to the function module ISU_BILL_TYPE_GROSS_PRICE_CONT (invoice category for gross prices for the billing). The billing document line items are sorted according to contracts; in other words, for each contract, one or more value-added tax line items are printed on the invoice. The No subtotal parameter is not taken into account when gross prices are processed.
You also define an account for entering gross price tolerances that may occur as a result of inconsistent gross billing documents. All the gross line items in the billing document are included in the bill sum total. They are not, however, relevant for posting. The actual posting-relevant line items in the billing document, including value-added tax, do not have to be identical with the gross price. To clear these differences, an offsetting item is posted to the open item.
The maximum permissible difference is 0.01 cent for each value-added tax item. If this is exceeded, the system stops invoicing the invoice unit.
Note that only the gross line items in the billing document are included in the print document. The individual price components cannot be printed.
© SAP AG IUT230 11-43
SAP AG 2008
Application Example RTP Interface
Billing a commercial and industrial customer using an interval readingDetermine billing-relevant data
Consumption during the on-peak rate period
Consumption during the off-peak period
Max. demand
RTP Interface
IS-U/CCSBilling
Off-peak consumptionOff-peak consumption
Max. demandMax. demand
On-peak consumptionOn-peak consumption
EDMRepository
Data: TR0101A030Schema: EDM
© SAP AG IUT230 11-44
SAP AG 2006
Example for Time-of-Use EDM
XXMax. demand
On-peak Off-peak
The RTP interface can determine values for maximum demand as well as values for on- and off-peak rate times.
© SAP AG IUT230 11-45
SAP AG 2008
Synthetic Profile
Su 03.28. Mo 03.29 Tu 03.30 We 03.31 Th 04.01 Fr 04.02 Sa 04.03 Su 04.04 Mo 04.05 Tu 04.06
Winter Summer
Working Day Working Day Working DayWeekendWeekend
Day profile 102
Day profile 101
Day profile 103
Day profile 104
Day profile 103
Installation: T-F-0011LSchema: E11
A synthetic profile represents the consumption template for a customer / customer group and is allocated to the installation A customer's individual consumption pattern is calculated using the consumption factor.
The values in synthetic profiles are determined using reference measurements or statistical methods, and saved as a day profile in the energy data repository.
The structure of the synthetic profile is determined depending on the allocation of season, day and time-of use groups.
When synthetic profiles are generated, the day profiles (standard load profiles) are determined according to the hierarchy. Profile values from the day types are then transferred to the synthetic profile according to the hierarchy specifications.
© SAP AG IUT230 11-46
SAP AG 2008
Customer consumption fromconsumption determination =
900 kWh
Th Fr Sa Su Mo Tu We Th Fr Sa 01.01.2003
Summer
Weekday
Summer
Weekday
Winter
Weekday
Winter
Weekday
Winter
Weekday
Winter
Weekday
Winter
Weekday
Summer
Weekend
Winter
Weekend
Summer
WeekendSynthetic profile for customer
group
Usage Factor
12.31.2003
Standardized to 1000 kWh p.a.
Usage factor =Customer consumption
Standardized profile consumption
= 900 kWh1,000 kWh
= 0,9
The consumption factor represents the relationship of customer consumption to the standardized consumption value of the synthetic profile.
In the example above, the synthetic profile is standardized to 1000 kWh. The actual customer consumption is 900 kWh. The consumption factor is automatically determined using the variant program QUANTI24. This is done by dividing the customer consumption by the standardized value of the synthetic profile.
Usage factor = 900 kWh / 1000 kWh = 0.9
Update the consumption factor
Usage factors are automatically calculated and updated by means of consumption quantity determination in IS-U Billing. During this process, the billing period in which the consumption occurred is included for each installation. It is possible to specify for each synthetic profile of the installation whether or not the consumption quantity determination updates the usage factor.
© SAP AG IUT230 11-47
SAP AG 2008
BusinessPartner
BusinessPartner
ContractAccountContractAccount
Installation 1Installation 1
DeviceDevice
Contract 1Contract 1
Installation 2Installation 2
Contract 2Contract 2
BillingRelatedInstallation
BillingRelatedInstallation
Water contract 1 with utility company in company code 0001
Waste water contract 2 with disposal company in company code 0002
DeviceLocationDevice
LocationTechnical Installn.
MMM
Waste waterWaste waterMMMWater utility Water utility
companycompany
Water and Waste Water Billing
Installation: T-F-0034Schema: S1
IS-U uses separate contracts and installations to model components of a contract that apply to several divisions, but belong to different companies and in turn to different company codes.
The water meter and its technical data is, therefore, installed in a (water) installation.
In addition to this, the water meter is installed for billing - this means, with rate data - in another installation with another division (waste water) and another company code.
The contracts can now be billed individually or jointly in one bill.
© SAP AG IUT230 11-48
SAP AG 2006
Consumption History
Consumption History
CIC Customer Overview
Installation: T-F-0005Schema: E5
The consumption and the amount are written directly in the consumption history using QUANTI23. This enables you, for example, to display graphic of the customer consumption pattern and the accompanying amounts in the customer overview.
The consumption history is also evaluated for the internet self service scenario.
Data is also cumulated in BW (Business Information Warehouse) according to consumption month and contract, and updated. The system calculates the previous month from the extraction date in BW up to the point when the IS-U contracts in BW are supplied with consumption values. Normally, consumption values from the table DBERCHV (consumption history) are used for the billed billing documents from selected contracts.
© SAP AG IUT230 11-49
SAP AG 2008
Prices
Operands
Rates
Schemas
Rate
Categories
Rate Determinations
CUST QTSTComplete transport of allbilling master dataorselective rate transport
Transport of Billing Master Data
All the billing master data can be transported using the report REA_BILL_MASTER_DATA_TRANSPORT.
Before transporting data, read the report documentation to familiarize yourself with the transport rules.
© SAP AG IUT230 11-50
SAP AG 2006
DPC enables you to process billing documents based on estimated consumption. You can correct all these estimated billings with real meter readings WITHOUT cancellation on ONE new billing document.
Unavailable meter reading results can be extrapolated.
These meter reading results are only required for creating billing documents and are not managed as data (saved).
Dynamic Period Control (DPC)
© SAP AG IUT230 11-51
SAP AG 2006
Monthly scheduled billing
1.1.01 7.1.01|------|------|------|------|------|------| R E E E E E R
R = Real meter readingE = Estimated meter reading
5 estimated billing documents, which are corrected using one billing document with the correct values
|------|------|------|------|------|------|
|----------------------------------------|
Example of Using DPC
© SAP AG IUT230 11-52
SAP AG 2006
You can also use the actual billing document to correct the following time slices:
|------|------|------|------|------|------|
|---------------------------------| All estimated billing documents in a time slice
|------|------|------|------|------|------| All estimated billing documents in the original time slice
Flexibility
© SAP AG IUT230 11-53
SAP AG 2006
Billing Period Categories
Determining the current period: 4 possibilitiesThe current period can lie between the real and the estimated meter readings|------| R E
The current period can lie between two estimated meter readings|------| E E
The current period can lie between the estimated and the real meter reading|------|
E R
The current period can lie between two real meter readings|------|
R R
© SAP AG IUT230 11-54
SAP AG 2006
Two options for multiple-contract billing in IS-U:
EDM (Energy Data Management)Formation of meter reading data pool before billing is carried out
Aggregation of technical data
Multiple-contract billing (as of CRM 4.0 only using the Master Agreement in CRM)
Pool formation during billing
Aggregation of business data
Multiple-Contract Billing: EDM
© SAP AG IUT230 11-55
SAP AG 2006
X axis
Demand-time profile ofsubsidiary company 1
kW
Y-Ax
is
X -A x i s
Demand-time profile ofsubsidiary company 2
kW
Y-Ax
is
X -A x is
kW+ + .. +X axis
100
200
300
kW
Total demand of thecompany
Aggregated demand-timeprofile of the company
X axis
10
20
30
100
200
300
kW
Total demand of thecompany
X axis
kW
Contractually-agreeddemand
[ ]* 50,0
0
1
00,
00
1
50,0
0
200
.00
00:00 0 2:00 0 4:0 0 0 6:0 0 08:0 0 10:0 0 12: 00 14: 00 16: 00 18: 00 20 :00 22 :00 24 :00
DM/MW
Provisional current price
500,
00
100
0,00
150
0,00
2
000
.00
00:00 0 2:00 0 4:0 0 0 6:0 0 08:0 0 10:0 0 12: 00 14: 00 16: 00 18: 00 20 :00 22 :00 24 :00
EURO
Company energy costs for additional demand
-
Sum of allintervalsSum of allintervals
Billing with EDM
© SAP AG IUT230 11-56
SAP AG 2006
Serial Switching Processing Options
The SAP IS-U system provides three methods for mapping and billing serial switchings:
The specific register relationship with the register relationship type "02" Serial Switching Relationship.
Mapping with rate average (rate solution)
Mapping using installation groups. Installation groups are available as of SAP IS-U Release 4.72.
Overview Register Relationship 02 Rate Solution Inst. Groups Only install secondary register in secondary installation - - ++ Read primary and secondary registers on different days - - ++ Independent billing cycles for primary and secondary installations ++ ++ - Only standard rates required ++ - - Dependent validations ++ + + Multiple primary registers permitted - ++ ++ Negative difference consumptions permitted - ++ ++ Bill primary installation despite missing meter reading results for secondary installation +/++ +/++ ++ Distribution of consumption values and amounts to secondary installations is possible - - ++ Multi-level serial switchings ++ + + Budget billing simulation ++ ++ -
Legend: - Not supported + Supported, but high workload ++ Is supported
© SAP AG IUT230 11-57
SAP AG 2006
Serial Switching
Primary installation
Secondary installation
SA1
Secondary installation
SA2
Secondary installation
SB2
Secondary installation
SB1
One use of the installation groups is billing serial switchings:
Define the utility installation with the primary register as the primary installation of an installation group
You define the utility installation with secondary registers as secondary installations of the installation group
You use the data exchange of secondary installations in the main installation in order to access the consumption values of the secondary installation when billing the primary installation.
If you want the difference in consumption (consumption from primary registers minus sum of consumption from secondary registers) to be distributed to the secondary installations, you can exchange data from the primary installation to the secondary installation.
© SAP AG IUT230 11-58
SAP AG 2006
Highlights of Billing Installation Groups
Installation group connects multiple installationsBilling allows the exchange of data within an installation group
Customizing controls access to secondary installation consumption valuesDistribution as BAdIConnection of billing documents
Sequence control for billingInterval checks for meter reading resultsMove meter reading resultsSimulation of missing meter reading results and correction with DPC IIReversal
Reversal of the entire installation groupIndividual reversal
OutsortingOutsorting of all documents for distribution bills
MonitoringInstallation group as a selection criteria
© SAP AG IUT230 11-59
SAP AG 2006
Consumption Distribution
Secondary Installation
SA1
Secondary Installation
SA2
Secondary Installation
SB2
SecondaryInstallation
SB1
Primary Installation MA
Data: T-F-0045 ...Schema: ISUWS002
Data: T-F-0044Schema: ISUWM002
The most important aspect of installation groups is that they support a new form of cross-installation billing. You can access data from secondary installation billing when billing primary installations. You can also access data from primary installation billing when billing secondary installations.
This is an alternative to the previous method for billing serial switchings, in which all secondary registers must be installed in both the secondary installation and the primary installation.
For a detailed description, see the Installation Groups document at http://service.sap.com/utilities -> Product Information -> IS-U/CCS -> Billing/Invoicing -> Cookbooks&Guidelines. This document explains what Customizing is necessary, how the data exchange functions, and which types of billing are supported. You also find examples of various serial switching scenarios.
© SAP AG IUT230 11-60
SAP AG 2008
Special Billing Features: Summary
SAP AG
The system supports the different franchise fee procedures.Gas billing in the SAP Utilities system represents different gas procedures.Assigning reference values enables you to bill lighting consumption. You can use the SAP Utilities data model and the universal billing engine for new types of billing in the deregulated utilities market.SAP Utilities provides archiving tools for large quantities of data. SAP Utilities provides methods for special types of billing.
© SAP AG IUT230 12-1
SAP AG 2006SAP AG 2006
Sales StatisticsData Warehouse Concept
SAP Business Information Warehouse (BW)
Sales Statistics: (Appendix A)
© SAP AG IUT230 12-2
SAP AG 2006SAP AG 2006
At the conclusion of this unit, you will be able to:
Describe the Data Warehouse concept
Describe the information from the application to the SAP Business Information Warehouse (BW)
Sales Statistics: Unit Objectives
© SAP AG IUT230 12-3
SAP AG 2006
OnlineTransactionProcessing
DATAWARE-HOUSE
OLTP
OLAP
Analysis Tools
OnlineAnalytical
Processing
Summarized Information
Integrated Application Modules
ExternalData Sales and
Distribution Finance
IS-U/CCSMaterial
Management
Data Warehouse Concept
In the implementation of more performant, integrated information systems, the newest Data Warehouse concepts are based on a three-tiered model.
The three levels subdivide the complete flow of data from capturing data in operational systems to displaying information.
Operational, integrated applications in OLTP systems form the basis for capturing information. Large amounts of master and process data are collected in these applications, which then need to be displayed in a more refined form using information systems.
The data from the applications is summarized to a subset of meaningful key figure values, and is managed separately in database tables in a Data Warehouse.
In the third level, the statistics data gathered in the Data Warehouse is available to various analysis tools for evaluation.
The analysis tools provide a large array of options for high-quality analysis and presentation of statistical data. Thus they provide modern management with a performant tool for making quick decisions.
© SAP AG IUT230 12-4
SAP AG 2006
Business Information Warehouse (BW)
Utilities
The SAP Business Information Warehouse (BW) is the mySAP.com business component that is used to extract and analyze data from operative business applications (OLTP systems). In addition to OLTP systems such as R/3 and SAP BBP (Business-to-Business Procurement: E-commerce business process used by employees to purchase goods and services directly from other suppliers), other external data sources such as databases or online services can also be integrated. OLTP stands for online transaction processing.
The SAP Business Information Warehouse supports online analytical processing (OLAP) and is designed to process large volumes of operational and historical data.
SAP BW contains all of the meta data required for common business processes. This includes InfoSources, InfoObjects, InfoCubes and standard reports, transfer structures for all releases and communication structures and update rules for each InfoCube. These elements form part of a “ready-to-go”strategy that supports automatic data transfer with immediate analysis once the system has been installed and the source system defined.
SAP BW requests application data from the source systems that have been assigned at regular intervals (pull-mechanism). Back-end systems contain extractors that collect data and transfer it to the SAP Business Information Warehouse.
© SAP AG IUT230 12-5
SAP AG 2006
Data Extraction and Transformation
BW
SE
RVE
R
Transformation rulesTransformation rulesTransformation rulesTransformation rules Update rulesUpdate rulesUpdate rulesUpdate rules
Operational datastoreOperational datastore
DataSources DataSources
Update rulesUpdate rulesUpdate rulesUpdate rules
OLAP Processor
PSA PSA
InfoSources
BEx
© SAP AG IUT230 12-6
SAP AG 2006
Query
Workbook
Transformation
InfoObject Regional StructureRegional StructureRegional StructureBusiness PartnerBusiness Partner
Extractor
InfoCube
InfoSource
Best-Practice ModelBest-Practice Model
Individualiza
tion
Standard
s
Business Content
Extractor Function model used to fill OLTP InfoObjects and InfoCubes for each infoSource.
InfoSource Structure that defines the fields (infoObjects) to be loaded in to the Business Information Warehouse (BW). An InfoSource can include extractors from different OLTP systems or dataSources.
InfoObjects Fields to be loaded into the BW (for example, billed amount, date of bill, business partner, and so on). Can be either characteristics or key figures.
Info Cubes Central objects on which analyses are based. They are closed datasets that are filled and aggregated according to their defined transformation rules.
Query Configurable view of InfoCube data.
Workbook A presentation layer of queries that can be stored as a self-contained dataset.
© SAP AG IUT230 12-7
SAP AG 2008
IndustryIndustry
AttributesAttributes157 005
398
Revenue
Time ReferenceTime ReferenceTime Reference
RateRate NetAmount
NetNetAmountAmount
EnergyAmountEnergyEnergyAmountAmount
Demand Amount
Demand Demand AmountAmount
Billed QuantityBilled Billed
QuantityQuantity
MonthMonthMonth20062006
Jan. Feb.Mar.Apr. MayJunJuly . . .. . .. . .
Structuring Statistics
Key FiguresKey Figures
There are three basic types of information in an information structure:
Characteristics are criteria that you define for collecting data on a particular subject. For example, in BW you require information about divisions, rate categories, rates, industries, and billing classes.
The period unit is another criteria used in information structures. You can collect data for a specific day, week, month, or posting period.
Key figures provide key business information with regard to a certain characteristic.
From a technical perspective, characteristics and periods are essential units for sorting data in databases.
© SAP AG IUT230 12-8
SAP AG 2006
BillingQuantity
April 2006 Bill 4711
1000 kWh
Jan Feb Mar Apr
ABAB
Jan Feb Mar Apr
BUDATBUDAT
Billing document invoiced
BillingQuantity
Period Determination
The system determines the period using the source date.
You can select different periods If you use the from-date of the billing line items, the total consumption for that billing period is divided up among the individual months using the set weighting procedure. You can also use the posting date. In this case, all consumption quantities are set to the posting date.
© SAP AG IUT230 12-9
SAP AG 2006
General LedgerContract Accounts Receivable and PayableSales & DistributionMaint. & Serv. Mgmt, Material MgmtERP Central FunctionsIS-U
PM/PM/EquipmEquipm..
TotalsTotalsdocumentdocument
FIFI--CACAdocumentdocument
General General ledgerledgerdocumentdocument
InvoiceInvoicedocumentdocument
InvoicingInvoicingrequestrequest
SD cust.SD cust.
BillingBillingdocumentdocument
BusinessBusinesspartnerpartner
ContractContractaccountaccount
ContractContract
WarehouseWarehouse PurchasePurchaserequisitionrequisition
InstallationInstallation
DeviceDevice
RegisterRegister
DeviceDevicecategorycategory
TechnicalTechnicaldevicedevice ((categorycategory) )
datadata
MRMRresultresult
MRMRorderorder
CustomerCustomercontactcontact
BillingBillingportionportion
MRMRunitunit
PremisePremise
SchedulingScheduling
ScheduleScheduledatadata
ConnectionConnectionobjectobject/FL/FL
Rates, Rates, pricespricesconditionsconditions
DevDev. . locationlocation/ FL/ FL
ISIS--U U addadd..
Service Service notificationnotification
ConnectionConnection//EquipmentEquipment
CustomerCustomerinquiryinquiry
RegionalRegionalstructurestructure
Post.Post.Pol.Pol.CompComp..
GridGrid
MM/MM/MaterialMaterial
ISIS--U U addadd..
WorkWork orderorder((externalexternal))
Work orderWork order(internal)(internal)
ContractSD
The IS-U Data Model (Simplified)
With ERP2005, the IS-U data model is almost as complete as the content in BW.
© SAP AG IUT230 12-10
SAP AG 2008
Reporting/Analysis
BW Content Transaction Data
ConsumptionRevenue
FI-CA
IS-U/CRMMaster Data
Device Management
Meter Reading
Data
KPI Process(BPEM)
© SAP AG IUT230 12-11
SAP AG 2006
IS-U/CCS Business Content (1)
Stock statistics-> History of contracts, business partners, devices, ...
Transaction statistics-> Manually executed transactions (move-in, move-out, device replacement, ...)
Sales statistics – More than just sales figures-> Invoiced quantities, net and tax amounts- Reversal rates- Error handling- Master data checks (address check in exit)
Consumption statistics-> (Billed and extrapolated quantities and amounts)Target group selection possible, based on current data and consumption values
Stock statistics map the history of the stocks. The number of contracts, for example, distributed in a region during the last 12 months lies at the center of the analysis not, for example, a list of all contracts within a region.
Transaction statistics show the number of monthly transactions and processes. Only the manual transactions are entered and registered here, as these statistics display the utilization of the employee. The difference between manual and automatic transactions is highlighted by two examples:
Move-in is performed automatically in migration and IDE scenarios. This is automatic processing and is, therefore, not included in the statistics
Mass invoicing is also not relevant for the transaction statistics, whereas manual single invoicing represents an expense with regards to these statistics.
© SAP AG IUT230 12-12
SAP AG 2006
IS-U objects (contracts, contract accounts, ...) as master data in BW-> Master data reporting (for example, list of all customers with water contract)
Unbilled revenue reporting-> Changes in the project are made using BW-BPS
Open items and cleared items-> (operational and strategic reporting)
CRM integration also in analytical areas-> For example:
- Comparison of campaigns in CRM and IS-U content- Analysis of sales figures for customers and their activities
IS-U/CCS Business Content (2)
© SAP AG IUT230 12-13
SAP AG 2006
STATISTICS GROUPSSTATISTICS GROUPS
Statistics groups forStatistics groups for ContractsContractsRatecategories
Ratecategories
Standardcustomers
C&Icustomers
Division Contract Rate cat. Update group01 ’ ‘’ ‘ 0101 SISU
01 0101 0101 Z00001
Residentialcustomers
Individualstatistics
Stats. group ‘ ‘ Stats. group 01Stats. group 02 Stats. group 01
Determination of Update Group
You can group rate categories and contracts according to the statistics update procedure using statistics groups.
You find the statistics groups for rate categories on the rate category screen. The statistics group for contracts is on a contract screen.
The following are examples of different updates:
Rate categories: "Residential customers" and Commercial and industrial customers".
Contracts: "Standard customers" and "Individual statistics". For certain contracts (such as standard customers), individual statistics are stored.
The update group controls the update on a general level. It is determined by a combination of the various statistics groups and the division.
© SAP AG IUT230 12-14
SAP AG 2006
Statistics GroupStatistics Group
Update GroupSISU
Update GroupUpdate GroupSISU SISU
CustomerSchultz
CustomerCustomerSchultzSchultz
Update GroupZIND
Update GroupUpdate GroupZINDZIND
CustomerSAP
CustomerCustomerSAPSAP
UpdateUpdateRulesRules UpdateUpdate
RulesRules
1.1.
2.2. 3.3.
BW
Customer = “Dummy”
Customer = “Dummy”
Customer = “SAP”
Customer = “SAP”
If update group = SISUthenname = “Dummy”
Why Update Groups?
Billing Document
Division 01
Statistics Group ‘ ‘Contract
Statistics Group 01Rate Category
Update GroupSISU
When contracts are billed, the division and the statistics group are determined from the contract and rate category.
Using the combination of division and statistics groups, the system determines the relevant update group and saves it in the billing document for statistics-relevant line items. Only line items with an update group in which an entry has been made can be updated to the BW.
On the basis of the update group, further differentiations can be made within the BW, for example, industrial and residential customers.
© SAP AG IUT230 12-15
SAP AG 2006
E1 SchemeRate Var.Pr. Stat. Group: QuantityRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002
. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002
I_ABRMENGE
Stat. Group ‘000001’
I_ABRMENGE
Stat. Group ‘000001’ COCO--
PAPA
WWABRWWABRWWLEIWWLEI COCO--
PAPA
WWABRWWABRWWLEIWWLEI
CO-PA Actual Data(Yes/No)
CO-PA Actual Data(Yes/No)
Statistics Groups: Quantities
CO-PA StatisticalData
CO-PA StatisticalData
Billing DocumentBilling Document
You enter the statistics group for quantities in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the quantities (for example, on-peak/off-peak rate active energy) in the BW. This makes it easier to transfer data to CO-PA.
SAP ships the statistics groups 000000 to 000002 with the system as standard.
You should define the statistics groups in detail to ensure that the quantity in the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.
In the statistics group, you also define into which value fields of the operating concern the quantity in a billing line item is copied. This only applies to statistical postings in CO-PA (for example for unbilled revenue reporting).
You cannot assign any update rules to a statistics group for actual postings of the value flow in CO-PA. You control these updates using the PA transfer structure. Basically, all the billing line items in a billing document for which the field 'Billing line item relevant for posting' is set are processed for actual posting in CO-PA. The amounts from the billing line items are always transferred for actual posting. You can, however, prevent the amounts from being transferred by not setting the field Relevant for actual posting in CO-PA in the statistics group quantity.
© SAP AG IUT230 12-16
SAP AG 2008
Schema E1Rate Var.pr. Stat. Group: AmountRate 1- Step 1 VarProg. A 000001- Step 2 VarProg. B 000002
. . .Rate 2- Step 1 VarProg. A 000001- Step 2 VarProg. C 000002- Step 3 VarProg. D 000002
NETTOBTR
Stat. group ‘000001’
NETTOBTR
Stat. group ‘000001’
VVNETVVNETVVARBVVARBVVLEIVVLEI
CO-PA Actual Data(Always Transfer)
CO-PA Actual Data(Always Transfer)
Statistics Groups: Amounts
Billing DocumentBilling Document
COCO--PAPA
COCO--PAPA
VVNETVVNETVVARBVVARBVVLEIVVLEI
CO-PA StatisticalData
CO-PA StatisticalData
You enter the statistics group for amounts in the billing schema for each schema step. In the statistics group, you can make more specific differentiations in the amounts (for example, energy and flat rate amount) in the BW. This makes it easier to transfer data to CO-PA.
SAP ships the statistics groups 000000 and 000001 with the system as standard.
You should define the statistics groups in detail to ensure that the amount in the BW can be analyzed in different ways. You can also copy the quantity to several key figures simultaneously.
© SAP AG IUT230 12-17
SAP AG 2006
Unbilled Revenue Reporting (New with BW 3.53)
URR InfoCubeURR InfoCube
URR InfoCubeURR InfoCube
Simulation IDSimulation ID
Simulation IDSimulation ID
Query1. Selection of SIM ID by user
2. Automatic derivation of print document creation date from SIM ID run date (by variable exit)
Sales statisticsSales statistics
Sales statisticsSales statistics
MultiCubeMultiCube
For performance reasons, data modeling for unbilled revenue reporting has been moved to SAP BW. Instead of storing all URR data in a Cube, the extrapolation data 0UCSA_C06 and the actual data 0UCSA_C05 is evaluated using MultiCube 0UCS_MC01
The data is identified using the simulation ID (extrapolation data) and the creation date of the print document (actual data). Therefore, the CPU date of the print doucment must be included in the SalesCube. (if necessary, include in exit BWESTA01).
The variable exit for the print document creation date is then called and filled in the query as a result of the simulation ID selection. (see standard example queries).
Before carrying out unbilled revenue reporting, you should read the Unbilled Revenue Reporting cookbook in the Service Marketplace. BW also contains Queries for MultiProvider "Simulated/Actual Sales Statistics" 0UCS_MC01, which you can use templates in BW.
Unbilled revenue reporting takes places in steps: 1. The actual data is stored in the sales statistics cube 0UCSA_C05 with the creation date for invoicing. 2. The simulted data is entered in the extrapolation cube 0UCSA_C06 with the simulation ID of the corresponding extrapolation run in IS-U. 3. The simulation ID contains the date that the extrapolation was started in IS-U. 4. All simulation data is analyzed in the MultiProvider using the simulation ID and the creation date <= start date.
© SAP AG IUT230 12-18
SAP AG 2006
BillingDocuments and Master
Data
BillingDocuments and Master
Data
1.
Sales Statistics DS 0UC_SALES_STATS_01
Only closed reconciliation key
1. Full request from BW (1)Full update is supported and must be used if the same documents are to be extracted again or the documents are to be extracted for the first time
2. Initial request from BW (2)Initial request does not supply much data; only documents that were created after the full update
3. Delta request from BW (3)All new and reversed bills since the last Delta request
2.
3.
The sales statistics are the most important IS-U statistics for energy companies. For this reason we have gone to great lengths to improve performance during extraction, and the corresponding error handling. The following are the most important points:
Index Table DBESTA_BWPROTAll reconciliations that were created when invoicing contracts are saved here. During the extraction, the system checks whether the reconciliation key is closed, and then imports and extracts all documents for this reconciliation key.
Index Table DBESTA_BWPROTEAll invoicing documents that could not be extracted due to an incorrect status or error handling in the BEWSTA01 user exit are saved here. Correct the cause of the error. During each extraction run the system attempts to reload documents from this index table. If this is not possible, then the entry remains in the table. You must read the application log for the extraction. Either in the BW monitor (a message is issued if an error has been detected in the extractor) or within the mass activity (transaction EBW_DQ_SS).
Continued on the next slide.
© SAP AG IUT230 12-19
SAP AG 2008
BillingDocuments and Master
Data
BillingDocuments and Master
Data
1.
Sales Statistics DS 0UC_SALES_STATS_02
Only closed reconciliation key
1. Full request from BW (1)Full update is supported and must be used if the same documents are to be extracted again or the documents are to be extracted for the first time
NO data is extracted; Index table DBESTA_BWPROT is stored
2. Initial request from BW (2)Initial request does NOT supply any data; only initialization takes place
3. Start mass activity in OLTP (3)All new and reversed bills since the last delta request are written in the delta queue via parallel processing
4. Delta request from BW (4)All entries in the delta queue are extracted (performance tip: Execute delta request twice)
2.
3. Delta QueueDelta
Queue4.
User Exit BWESTA01If you need to make adjustments to the sales extractor (import additional tables, change values), then you should never use the RSAP0001 generic BW exit. Instead you should use this user exit. This exit is run for each billing document. As well as the billing document, it also has many other tables in the interface (note the interface for the exit). This avoids most performance-intensive and time-consuming saving procedures. In addition, the exit also allows you to trigger an exception or error message of category 'E'. This means that the document is not extracted and written in the DBESTA_BWPROTE index table. Take advantage of the enhanced check in the exit. This has little effect on the performance, but significantly increases the time and effort required for subsequent corrections. Some cusotmers check address data here (for example, have the address codes been maintained?).
User Exit BWESTA02Normally only those documents are extracted, whose reconciliation key have been closed. This restriction is not sufficient for some customers. In order to be able to make comparisons with the general ledger, you should only process the reconciliation keys that have actually been transferred to the general ledger. For this reason you can check the reconciliation key in greater detail in this exit. However, you cannot extract an open reconciliation key.
For more information on the loading mechanism, see note 438606.
© SAP AG IUT230 12-20
SAP AG 2006SAP AG 2006
Sales statistics data is kept in a data warehouse.
The SAP Business Information Warehouse means you do not have to use the UIS.
The detailed modeling of the 'Quantity and Amount' statistics groups and their proper use in the billing schema directly influences the storage of information in the SAP BW.
Note: The BW project group must be informed of the features of and every change to the statistics groups!
Sales Statistics: Unit Summary
© SAP AG IUT230 13-1
SAP AG 2006
Contents:
Program Enhancement (Attachment B)
Technology of program enhancement
Program enhancements - billing
Program enhancements - invoicing
© SAP AG IUT230 13-2
SAP AG 2008
Technology of Program Enhancements
Yes
Yes
No
No
SAP Utilities Program(Event)
SAP Utilities Program(Continuation)
Customer-specific
Industry-specific
Standardprogram
ISprogram
Customerprogram
Flexibility without modification of SAP programs
© SAP AG IUT230 13-3
SAP AG 2008
Standard FunctionalityTFKFBMEvent
1330............
Text
Due date datedetermination
...
...
...
...
ABAP/4 module
FKK_SAMPLE_1330............
Industry FunctionalityTFKFBSEvent
R400............
Text
Clearing types............
ABAP/4 module
ISU_CLEARING_TYPE_R400............
Customer FunctionalityTFKFBCEvent
...
...R403
...
...
Text
...
...Invoicing unit
...
...
ABAP/4 module
...
...Z_USER_R403
...
...
SAPxxxxx
Program
...Event 1330
...
...Event R400
...
...Event R403
...
...
...
Technology of Program Enhancements
© SAP AG IUT230 13-4
SAP AG 2006
Program Enhancements - Billing
EBIA0001 IS-U: Maintain customer-specific fields in billing document
EBIA0002 IS-U: Proration according to customer-specific schedules
EBIA0003 IS-U: Customer-specific checks in billing and overall check
EBIA0004 IS-U: User exit external calculation of compressibility
EBIA0005 IS-U: Termination of mass runs
EBIA0006 IS-U: Period control: Determine time portions in billing
EBIA0007 IS-U: Customer-specific actions in billing reversal
EBIA0008 IS-U: Customer-specific actions in the update of billing reversal
EBIA0009 IS-U: Move-in/move-out adjustment to the day/to the month
EBIA0011 IS-U: Billing update
EBIA0012 IS-U: Maintain customer data in the billing obj. OBJ
EBIA0013 IS-U: Customer checks in the billing selection
EBIA0014 IS-U: Maintain customer-specific fields in manual billing
EBIA0015 IS-U: Backbilling user exit
EBIA0016 IS-U: Determination of billing calorific value
© SAP AG IUT230 13-5
SAP AG 2006
Program Enhancements - Billing II
EBIA0017 IS-U: Individual document display
EBIA0018 IS-U: Customer requirements during line item combination
EBIA0019 IS-U: Customer-specific bill comparison
EBIA0020 IS-U: Change current period during dynamic period control
EBIA0021 IS-U: Change current billing period during dynamic period control
EBIA0022 IS-U: Change contract sequence for billing
EBIA0023 IS-U: Fact checks
EBIA0024 IS-U: Enhancement for determining special operand value
EBIA0025 IS-U: Determine different weighting for measured quantities
EBIA0026 IS-U: Post processing of gas factors
EBIA0027 IS-U: Authority check for facts (enhancement)
EBIA0028 IS-U: Maintain/save customer facts in billing object
EBIA0029 IS-U: Permit repeated adjustment reversal
© SAP AG IUT230 13-6
SAP AG 2006
Program Enhancements - Billing III
EBIA0030 User exit for customer overview reports in the BRE
EBIC0001 IS-U: Determine evaluation group for consumption history
EBIS0001 IS-U: User exit for external prices (EBL)
EBIS0002 IS-U: Enhancement for rate type and rate fact group
EBIS0003 IS-U: Reference value - Integration of customer-specific fields
EBIS0004 IS-U: Front office output of historical consumption values
EBIS0005 User exit for transferring installation facts
EBIS0006 IS-U: Rate category - subscreen integration and field checks
EBIS0007 IS-U: User exit for price checks
EBIS0008 IS-U: User exit for checking calorific value
EBIS0009 IS-U: Enhancement for displaying currency in facts
EBIS0010 IS-U: Enhancement for customer-specific transport control
© SAP AG IUT230 13-7
SAP AG 2008
Program Enhancements: Invoicing I
R400: Determination of clearing type / change to document type
R401: Selection of items for account maintenance
R402: Enhancement of invoicing contract accounting documents
For creating business partner and general ledger items
Prevents the posting of documents with zero amounts
For creating new posting documents
R403: Customer-specific definition of invoicing units – what billing documents are invoiced together
R404: Transfer of dunning information
R405: Addition of customer-specific information from billing documents to posting items
R408: Data on revenue recognition (delayed revenue posting)
R409: Enhancement of rounding items, in which bill amount rounding has taken place
R410: Selection of items that are to be printed in the bill, or to be included in the final bill amount
Overrides the Customizing settings in “Item Selection for Bill Display (TE529)”
For further information on the program enhancements, see the documentation on each sample module.
The sample modules must have the naming convention ISU_SAMPLE_<Event>
Sample modules are stored in the function group E21U.
Create your customer-specific modules in a copy of the function group E21U.
You must save the customer-specific modules in the table TFKFBC. You maintain this in Customizing for Financial Accounting, under Contract Accounts Receivable and Payable -> Program Enhancements -> Define Customer-Specific Function Modules.
© SAP AG IUT230 13-8
SAP AG 2006
Program Enhancements - Invoicing II
R411: Document selection for due date adjustmentR412: Set permanent or temporary print blocksR413: Tax determination for billing (change tax code)R417: Override due dateR428: Maintain customer-specific fields in the invoicing order (EITR)R430: Determine payment method for business partner items and set clearing restrictions
When used in connection with the 'due date adjustment', you can make the appropriate settings so that items from the current bill are requested with the next bill.
R431: Invoicing unit is finishedR433: Print document number is assigned - update customer-specific tables etc.R434: Rollback of customer-specific enhancements for processing errors (see events R431 and R433)R436: Maintain customer-specific fields in the print document
Is connected to the Customizing include "CI_ERDZ" in the print document line items
© SAP AG IUT230 13-9
SAP AG 2006
Program Enhancements - Invoicing III
R437: Set parameter for each invoicing unit
R469: Invoice reversal: Set print block
R470: Invoice reversal: Check permissibility
R471: Reversal document number is assigned - update customer-specific tables etc.
R472: Rollback customer-specific enhancements for processing errors
R501: Determine posting date and document type
R979: Customer-specific definition of LPC amount
R983: Set payment lock for items
© SAP AG IUT230 13-10
SAP AG 2006
Program Enhancements - Budget Billing Plan 1
R923: Amount transfer in portion change
R925: Change date when adding a budget billing plan
R974: Create ABP: Amount limits per contract
R976: Amount change of budget billing amount items
R977: Amount change for several due dates
R978: Budget billing request, adjust due dates
R984: Determine extrapolation period
R985: Add contract to existing budget billing plan, change budget billing amounts
R987: Change printed or migrated items
R988: Use general ledger account as key
R989: Change creation date
R990: YAP documents when creating budget billing plan
R991: Post YAP bonus in invoicing
© SAP AG IUT230 13-11
SAP AG 2006
Program Enhancements - Budget Billing Plan II
R992: Change due date when creating budget billing plan
R469: Invoice reversal: Set print block
R994: Change budget billing amount (when creating and adjusting)
R995: Manipulate budget billing / adjust standard budget billingamount
EA610002: Correct items in a budget billing plan
EINA0001: Dynamic budget billing cycle determination
© SAP AG IUT230 13-12
© SAP AG IUT230 14-1
SAP AG 2003
Appendixes C and D
SAP AG 2001
Appendix C: Billing Commercial and Industrial Contracts
Appendix D: Recommendation for the Billing Schema
© SAP AG IUT230 14-2
© SAP AG IUT230 14-3
Appendix C Commercial and Industrial Billing 3-Peak Average with Floating Backbilling Business Description The customer is charged for the service on the basis of the active power (kW) consumed, or on the service terms agreed in the contact. In this case, the active power consumed is equal to the average demand values (rounded to full kW) measured within one billing month over a period of n minutes (for example, n=15, 30, or 60 minutes).
The demand calculation in a monthly billing is based not only on the peak demand value measured in a month, but also on the average peak demand values over n periods. In the following example, the 3-peak averages of the highest measured demands are to be calculated and provided for billing. This calculation will provide the provisional peak demand value for the year, formed from the three highest monthly peak demands during the billing year. The following example explains how the 3-peak average is calculated on the basis of a 12-month billing period. The scheduling dates (end of the billing period - start of the backbilling period) are used as a comparison period.
© SAP AG IUT230 14-4
Overview
The following table shows a section of the schema for this billing rule. In addition to the demand calculation (rate E7_3), the on-peak (rate E7_1) and off-peak consumption (rate E7_2) are charged in this example.
No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExBB BB All BB1
RevBB1
1 E7_1 QUANTI01 X EQUANT_1
EQPRICE_1
EAMOUNT_1
2 E7_2 QUANTI01 X EQUANT_2
EQPRICE_2
EAMOUNT_1
3 E7_3 INFACT01 EDEMAND1
EDEMAND7
4 E7_3 DEMAND14
EDEMAND1
EDEMAND6
5 E7_3 BACKBI01 0002
6 E7_3 BACKBI03 EDEMAND7
EDEMAND6
X 0002
7 E7_3 DEMAND07
EDEMAND6
EDEMAND4
EDEMAND5
8 E7_3 INFACT01 EDEMAND5
EDEMAND8
9 E7_3 DEMAND01
X EDEMAND5
ETPRICE_1 EAMOUNT_1
0003 0003
10 E7_3 IF00 EDEMAND5
EDEMAND8
11 E7_3 ELSE
12 E7_3 BACKBI02 EDEMAND5
EDEMAND5
13 E7_3 BACKBI01 0003
14 E7_3 ENDIF
Key:
Variant: Name of the variant program PR: Billing line items relevant to posting 1st Inp. Op.: First input operand 2nd Inp. Op.: Second input operand 1st Outp. Op.: Output operand ExBB: Execute backbilling indicator BB: Execute schema step in backbilling only indicator AllBB1: Allocate backbilling indicator RevBB1: Reverse backbilling indicator
© SAP AG IUT230 14-5
In demand rate E7_3, the current measured demand is transferred to the installation facts using INFACT01. This demand is also updated to the operand planned for peak averaging and required for the current period using DEMAND14. At this point, it only contains one demand value (if only the peak monthly demand value is to be considered). In the next step, backbilling is triggered with BACKBI01. In the Execute backbilling indicator column, you specify which steps are to be carried out in backbilling. In the next step, you write the demand values for the previous periods (adjustment periods) to the output operand for peak averaging using the same group assignment and variant BACKBI03.
Example:
The backbilling period starts on January 1 and ends on December 31 of the same year. The current billing month is April. 40 kW was measured in April.
The following demand values have so far been entered using INFACT01 in the installation facts (demand values from the meter reading):
January February March
|----------------------|----------------------|----------------------|
30 kW 20 kW 10 kW
After the BACKBI03 variant has been run, the following values for calculating the 3-peak average are available in the current billing period:
January February March April
|----------------------|----------------------|----------------------|----------------------|
40 kW (April)
30 kW (January)
20 kW (February)
10 kW (March)
© SAP AG IUT230 14-6
During demand preprocessing, the 3-peak average is calculated on the basis of the number of peaks specified in the operand.
In the above example, the demand values 30 kW, 20 kW, and 40 kW are used to calculate the 3-peak average. The result is 30 kW.
In the next step, the calculated peak average is compared with the minimum demand, which is also entered in the facts (rate, rate category, or installation facts). For this purpose, variant DEMAND07 writes the result to the output operand that represents the demand to be cleared. Depending on the fine-tuning control settings, the higher or lower value in this comparison is written to the output operand.
This information is required for the following (+ 1 month) period billing. For this reason, the next step will, in the future (depending on the fine-tuning control setting), involve updating this value with INFACT01.
The demand is valuated for the current period with DEMAND01.
Up to this point, the 3-peak average has been calculated, a comparison has been made with the previous clearing demand, and the current clearing has been valuated.
Example:
The 3-peak average (calculated from the meter reading results from January to April) is 30 kW. The minimum demand as agreed in the contract is 15 kW; in other words, in the current billing period (April), billing line items are created (DEMAND01) for the demand value of 30 kW. Using INFACT01, you update this value to the installation facts for billing in May. The following schema steps now check whether backbilling for January to March is necessary.
30 kW peak average > 15 kW minimum demand results in the demand of 30 kW, which is to be cleared in the current billing period (April).
January February March April May
|---------------------|---------------------|----------------------|----------------------|----------------|
Current billing
30 kW
© SAP AG IUT230 14-7
In the next step, you use variant IF00 to check whether the current clearing demand corresponds to the previous month's clearing demand. If so (condition fulfilled), backbilling is not carried out; in other words, billing for this installation is completed, since, in this example, no further processing steps are defined in the billing schema.
If the condition is not fulfilled (the current clearing demand is greater or smaller than that of the previous month), all the preceding periods have to be reversed and revaluated using the currently calculated clearing demand. For this reason, the current clearing demand is first written to the adjustment period by means of BACKBI02.
January February March April May
|--------------------|----------------------|----------------------|----------------------|---------------|
< -----30 kW---- >
Adjustment periods:
< ---30 KW--- >
< -----30 kW---- >
< -----30 kW---- >
When backbilling is triggered using BACKBI01, the variant programs that have the same backbilling group (here 0003) are triggered. If these steps also contain an entry in the backbilling reversal column, schema steps marked in such a way cause the billing line items generated in the preceding periods (adjustment periods) to be reversed.
Example:
The billings up to March have taken into account a clearing demand of 20 kW.
January February March
|----------------------|----------------------|----------------------|
Adjustment periods:
< -----20 kW--- >
< -----20 kW----- >
< -----20 kW------ >
© SAP AG IUT230 14-8
In billing for April, a new clearing demand has been calculated. After variant BACKBI02 has been executed, the following data is available:
January February March April May
|--------------------|----------------------|----------------------|----------------------|---------------|
< -----30 kW---- >
Adjustment periods:
< ---30 KW--- >
< -----30 kW---- >
< ----30 KW----- >
Backbilling is triggered using BACKBI01. By means of variant DEMAND01, which has the Execute backbilling indicator, 30 kW are charged for the individual adjustment periods, and (as a result of the backbilling reversal indicator) 20 kW from the individual adjustment periods are reversed. The current billing month (in this case April) remains unaffected by this.
© SAP AG IUT230 14-9
Backbilling Indicators in the Billing Schema The following descriptions refer to the demand rate, in which the peak average is formed and floating backbilling is carried out.
No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExBB BB
All BB1
RevBB1
. . .
. . .
3 E7_3 INFACT01
EDEMAND1
EDEMAND7
4 E7_3 DEMAND14
EDEMAND1
EDEMAND6
5 E7_3 BACKBI01
0002
6 E7_3 BACKBI03
EDEMAND7
EDEMAND6
X 0002
7 E7_3 DEMAND07
EDEMAND6
EDEMAND4
EDEMAND5
8 E7_3 INFACT01
EDEMAND5
EDEMAND8
9 E7_3 DEMAND01
X EDEMAND5
ETPRICE_1
EAMOUNT_1
0003 0003
10 E7_3 IF00 EDEMAND5
EDEMAND8
11 E7_3 ELSE
12 E7_3 BACKBI02
EDEMAND5
EDEMAND5
13 E7_3 BACKBI01
0003
14 E7_3 ENDIF
Key:
ExBB: Execute backbilling indicator BB: Execute schema step in backbilling only indicator AllBB1: Allocate backbilling indicator RevBB1: Reverse backbilling indicator
© SAP AG IUT230 14-10
Description The individual backbilling indicators for the BACKBI variants are defined in the billing schema. The backbilling indicators are modeled in Customizing using 'backbilling groups'. These groups are allocated in the backbilling indicators. You need these backbilling groups, for example, to carry out backbilling or period-end billing in the schema. Using these backbilling groups, you can combine rate steps for backbilling and period-end billing.
Backbilling groups can be found in the SAP Reference IMG. To access them, choose SAP Utilities Contract Billing Billing Mater Data Rate Structure Schemas Define Backbilling Groups.
Execute backbilling indicator: ExBB1
Variants of the variant type 09 (= backbilling variant) can trigger backbilling. To do so, you must enter a backbilling group in the execute backbilling indicator for each variant of this type in the schema.
Allocate backbilling indicator: AllBB1
This indicator contains a backbilling group that is assigned to a schema step. This enables the schema step to be backbilled.
Reverse backbilling indicator: RevBB1
Using this indicator, you assign the billing line items generated by this schema step to a backbilling group. The billing line items can be reversed during backbilling.
Execute schema step in backbilling: BB
If this indicator is set, the schema step is only executed in backbilling. The indicator, therefore, must only be set if at least one backbilling assignment indicator is also set.
© SAP AG IUT230 14-11
Detailed Description The following variant programs are required for the billing rule in floating backbilling with 3-peak averages. These are listed in the same order they appear in the sample billing schema (see above).
3 - INFACT01 - Writing a demand to the installation facts
In this special case, the output operand defines the operand name that is to be used to write to the installation facts. Input and output operands can have either the same name or different names. In the application itself, the value obtained from the meter reading (register operand) is updated to the output operand for the demand values measured on a monthly basis. If this output operand does not exist, it is created automatically in the installation facts.
4 - DEMAND14 - Rate-independent transfer of register operands
The demand represented by the input operand is updated without changes. This variant is only expedient if the input operand is a register operand. These are only known within the corresponding rate, but may also be needed for processing in the same or different rates.
This step transfers the demand value from the meter reading (register operand) to the output operand planned for the peak average. In its demand description, the operand has the value 3 for calculating the 3-peak average.
5 - BACKBI01 – Triggering backbilling
This variant triggers backbilling. You can hide billing line items that are not required for backbilling using the control function.
You carry out this variant step with the next step using the Execute backbilling indicator.
© SAP AG IUT230 14-12
6 - BACKBI03 – Update demand from the adjustment period
This variant is only required in backbilling or period-end billing.
In backbilling, demands from the adjustment periods are updated to schema steps in the periodic billing period (current billing period).
In period-end billing, demands from the adjustment periods are updated to the schema steps in the rate for period-end billing.
In this variant, the Execute schema step in backbilling only indicator must be set. This indicator is set automatically when this variant is used, and it cannot be changed at a later stage.
The recorded monthly demand values are now exported from the installation facts and written to the output operand. In this way, the adjustment period values are also available for the current billing period in the billing schema. With this variant, the 3-peak average is calculated during demand preprocessing (output operand with no. of peaks = 3).
7 - DEMAND07 – Comparison of two demands
This step involves calculating the higher or lower demands from two alternatives.
The result of peak averaging is then compared with the minimum demand agreed in the contract. The higher demand value is updated to the output operand that represents the current clearing demand.
8 - INFACT01 – Writing a demand to the installation facts
In the future, this clearing demand will be updated to the installation facts as a demand for the previous month so that it is available for subsequent period billings. This demand value is essential for backbilling and reversing the demand values that have already been charged (adjustment periods).
9 - DEMAND01 - Valuating a demand with a price
The clearing demand calculated for the current month is valuated with a price. Price prorations are taken into account. The calculated amount is updated.
© SAP AG IUT230 14-13
10 - IF00 - Condition: IF demand1 >,>=,= demand2
This variant introduces an IF nesting level. All the following schema steps are only executed if the condition is fulfilled. The condition is:
IF demand1 > (>=,=) demand2
whereby either the current or the highest values of the input operand are taken into account. The IF variant must be ended using an ENDIF variant. You can also use an ELSE variant.
In this step, the clearing demand is compared with the clearing demand from the previous month. If the demand values are the same, the variant programs after the IF variant are executed. Since no variants are listed here, the variants after the ENDIF variant are called up. If the demand values are different, backbilling must be carried out. This means that all the billing line items for the adjustment period are reversed and recalculated.
11 - ELSE – Start of a NOT operation for an IF variant
This variant introduces the ELSE part of an IF nesting level, that is, the following variants are only executed if the IF variant condition is not fulfilled.
Since the current clearing demand is different from the previous month's clearing demand, backbilling is to be carried out. This would, for example, be the case if the n-peak average had either increased or decreased.
12 - BACKBI02 – Update demand to the adjustment periods
This variant is only required in backbilling or period-end billing. If you use the variant in periodic billing with backbilling, the most recent demand value in the periodic billing period is updated to the adjustment periods. If you use the variant in a rate for period-end billing with backbilling, the most recent demand value in the period-end billing period is updated to the adjustment periods.
In this way, the current demand value is updated to the adjustment periods.
13 - BACKBI01 – Triggering backbilling
This variant triggers backbilling.
In more specific terms, the variant program steps are executed with the same backbilling control group. The schema steps that have the same group in the backbilling reversal indicator column are reversed.
14 - ENDIF – Ending an IF nesting level
This ends the IF nesting level you previously opened using an IF## variant.
© SAP AG IUT230 14-14
Operands Register operand EDEMAND__1 for the month's measured demand
Operands of the type DEMAND and QUANT can be defined as register operands. The indicator defines the use of operands in the rate.
In the rate header, only operands whose indicator has also been set accordingly can be used as register operands. In the rate steps, operands can only be used if the indicator is not set, or if the operand is the same as the register operand in the rate header. Furthermore, register operands of the type DEMAND must not be used to create facts in the rate, rate category, or installation. If an operand has already been defined once as a register operand or standard operand, you cannot reverse this, since this may result in inconsistencies. For this reason, you can only make changes by deleting or recreating the operand.
Field Name Name Note
Header Data:
Operand EDEMAND_1 Name can be freely assigned.
Operand category DEMAND
Usage Register operand At the time of billing, the current recorded demand values are stored.
General Data
Rounding # As required.
Rounding type # As required.
Operand group Optional By assigning the operand group to an operand, you specify that the operand is always to be displayed in the fact hierarchy with reference to this operand group.
Access to operand 00 All values are considered.
History 0 No restrictions relating to the historical changeability are specified.
Special Control:
No. of peaks 1
In the specific example, the above-mentioned operand was defined as a register operand. In this way, the current value is exported from the meter reading results via the installation structure at billing runtime.
Operand EDEMAND__6 for the calculated 3-peak average
This operand is created for standard use. The operand is supplied with values from the rate, rate category, or installation facts.
© SAP AG IUT230 14-15
Field Name Name Note
Header Data:
Operand EDEMAND_6 Name can be freely assigned.
Operand category DEMAND
Usage Standard usage
General Data
Rounding # As required.
Rounding type # As required.
Operand group Optional See above
Access to operand 02 The value on the key date is valid. This control function is selected depending on the contractual conditions.
History 0 No restrictions relating to the historical changeability are specified.
Special Control:
No. of peaks 3 During demand preprocessing, which is activated for certain variants, this operand contains the result of the calculation (in this case the 3-peak average).
During demand preprocessing, the value for the number of peaks is evaluated and the result of the calculation entered in this operand.
© SAP AG IUT230 14-16
Rate - Time Period Control - Variant Control Rate models do not contain any special control features for floating backbilling or period-end billing. The time period control and variant fine-tuning control settings are, however, defined in the rate models.
No. Variant PC FT Inp. Op.1 Inp. Op.2 Outp. Op.1
1 INFACT01 01 EDEMAND1
EDEMAND7
2 DEMAND14
01 01 EDEMAND1
EDEMAND6
3 BACKBI01
F
4 BACKBI03
EDEMAND7
EDEMAND6
5 DEMAND07
01 02 EDEMAND6
EDEMAND4
EDEMAND5
6 INFACT01 01 EDEMAND5
EDEMAND8
7 DEMAND01
01 02 EDEMAND5
ETPRICE_1 EAMOUNT_1
8 IF00 03 EDEMAND5
EDEMAND8
9 ELSE
10 BACKBI02
EDEMAND5
EDEMAND5
11 BACKBI01
F
12 ENDIF
Section of the rate for demand calculation.
Key:
No. Current rate step number Variant: Name of the variant program PC: Time period control FT: Fine-tuned variant control
In the above example, a time period control function (entry 01 in column PC), which refers to the process for calculating the period to an exact number of days, has been accessed in Customizing. Customizing also provides time period control functions for taking special situations into account, for example:
- leap years
- move-ins
- move-outs
- values added/omitted sub-periodically (for example, device installation).
© SAP AG IUT230 14-17
Period Control - PC
Using the period control function, you calculate the length of the billing-relevant periods. This length is also referred to as a proportion of a time slice.
Period control is specified in the rate for every rate step, in which a time-dependent calculation is carried out. Using table TE432, the period control function refers to one of three basic processes for calculating time periods (see below).
The time period is required in three cases:
1. For values valuated with time-dependent prices. In this case, the length of each time slice must be calculated, since it is used to valuate the price. Example for billing a demand to an exact number of days.
2. For values whose time slice lengths are used for calculations. Example for extrapolating a time-dependent amount on a monthly basis.
3. For prices whose blocks/scales are to be adjusted to the length of their time slices.
Explanations of the different basic procedures
Basic procedure 01: For an exact number of days
When the time period is calculated for an exact number of days, the difference in the number of days between the time slices is used as a time period.
Basic procedure 02: On a monthly basis with taking key date into account
In this procedure, the time period is calculated in whole months. The number of months is calculated depending on the key date. The advantage of this procedure, for example, is that exactly one month is billed if the billing period covers the key date, but not the whole month. The key date is maintained in the meter reading unit.
Basic procedure 03: On a monthly basis depending on interval
In this procedure, the time period is calculated in months. If the number of days in the billing period is within the interval days specified in the portion, the months in the planned billing period from the portion are used as a time period. If the days in the billing period are not within the interval, the time periods are calculated for exact days. The time portion in days can either be scaled to the standard month (30 days) or to the standard year (365 days).
© SAP AG IUT230 14-18
Variant Control
Using the variant control, you can control the different variant programs. Control indicators are not the same for all variant programs, but depend instead on the task of each variant program.
No. Variant PC FT Inp. Op.1 Inp. Op.2 Outp. Op.1
1 INFACT01 01 EDEMAND1
EDEMAND7
2 DEMAND14
01 01 EDEMAND1
EDEMAND6
3 BACKBI01
F
4 BACKBI03
EDEMAND7
EDEMAND6
5 DEMAND07
01 02 EDEMAND6
EDEMAND4
EDEMAND5
6 INFACT01 01 EDEMAND5
EDEMAND8
7 DEMAND01
01 02 EDEMAND5
ETPRICE_1 EAMOUNT_1
8 IF00 03 EDEMAND5
EDEMAND8
9 ELSE
10 BACKBI02
EDEMAND5
EDEMAND5
11 BACKBI01
F
12 ENDIF
Rate step no. 1 – INFACT01
The following control functions have been activated here:
- Information lines relating to demand are not written - Update in billing period with proration
This setting was selected so that all the values within the billing period are also available. It prevents information lines from being written, since this information is generated at a later stage using variant DEMAND01.
Rate step no. 2 – DEMAND14
The following control functions have been activated here:
- Info lines relating to demand are not written - Added during update
The information lines are not required here either. The control function relating to updating is not relevant in this example, since the operand is used for the first time in this rate.
© SAP AG IUT230 14-19
Rate step no. 3 – BACKBI01
The indicator for deleting the backbilling line items that are not required is not activated.
This indicator is not used in this example, since, for example, the maximum price in backbilling is not calculated, and line items that are not required may have to be deleted.
Rate step no. 5 – DEMAND07
The following control functions have been activated here:
- Only billing-relevant information is written - The higher demand is determined - Data is overwritten during updating - Information lines relating to the demand comparison are written
Information lines relating to demand, in particular register meter readings, are written. The level of detail can be specified as follows: - No info lines are written. - Infolines are written on the service(s) to be billed. - Info lines relating to both the method for calculating the relevant demand and the meter readings not included in the calculation are written.
Information on the calculation method is provided with all the billing line items, which include additional information, rather than in separate info lines. The following fields are maintained: ZAHL1 = First demand MASS1 = Dimension of the first demand ZAHL2 = Second demand MASS2 = Dimension of the second demand ZAHL3 = Greater/smaller than the two demands
You can also use the control function to prevent info lines from being written.
The control function specifies the two comparison options: - Calculation of the greater of the two demands - Calculation of the smaller of the two demands
Using the control function, you must also define the type of operand update procedure. Since the output operand is only being used for the first time in this example too, the control function is not required.
Example:
The calculated 3-peak average is compared with a predefined minimum demand in the contract (rate, rate category, or installation facts). The greater of the two demands is billed.
© SAP AG IUT230 14-20
Rate step no. 6 – INFACT01
The following control functions have been activated here:
- Info lines regarding demand are not written - Update future demand
The required information lines are written in the next step.
The demand (in this case, the demand to be cleared) must be updated for the future to ensure that this demand value is available for the next period billing. This value is written on a proration basis to the installation facts for the installation to be billed. If the operand is not available in the facts, it is created. In rate step 8, the value is compared with the new clearing demand and, if necessary, backbilling is carried out.
Rate step no. 7 – DEMAND01
The following control functions have been activated here:
- Only billing-relevant information is written.
To enable the information to be displayed on the bill (these information lines were suppressed up to now), you choose this control function.
Rate step no. 8 – IF00
The following control functions have been activated here:
- Demand 1 = Demand 2 - Use current value
The relational operator between the two demands must be specified. You can basically choose the following for this purpose:
- If Demand1 > Demand2 - If Demand1 >= Demand2 - If Demand1 = Demand2
Demand1 corresponds to the previous month's clearing demand. Demand2 is the current clearing demand. If this demand is the same as the previous month's clearing demand, backbilling is not carried out. If these values are different (demand 2 is greater or less than demand 1), the previous month must be backbilled.
The billing period may contain several different values, for example, due to prorations. For this reason, you must specify the value to be used. For this setting, the value that is valid at the end of the billing period is used.
© SAP AG IUT230 14-21
Rate step no. 11 – BACKBI01
Not activated.
With this control function, billing line items for backbilling that are not required are not suppressed, since, in this case, they are not part of the contract.
Example of when this control function is activated:
Backbilling for calculating demand with a maximum price in previous billing periods is to be started to determine the maximum amount in each of the periods. If the total of the maximum amounts is greater than the total of all the energy and service amounts, the result from calculating the highest amount is to be reversed. If the control function for deleting backbilling line items that are not needed is selected, the billing line items for the maximum amount are deleted, otherwise the maximum amounts are set as negative values.
© SAP AG IUT230 14-22
Rate category The rate category is entered in the utility installation. It determines the criteria for the billing rates, for example, the backbilling and/or period-end billing control function. When the rate category in the installation is changed, the periods in billing are analyzed separately.
During backbilling or period-end billing, you must not change the rate category within the backbilling period or period-end billing period.
Field Name Name Note
Header Data:
Rate category E7 Name can be freely assigned.
Division
General Data
Billing class # As required.
Outsorting price group billing # As required. The outsorting checks during billing are entered (for example, maximum net amount) here.
Billing schema:
Billing schema Here, you must enter all the rates for an installation that are required for calculation.
Backbilling:
Floating backbilling X See below
Number of periods 12 Periods for floating backbilling. With this entry, the peak average calculation is restarted after 12 periodic billings.
Indicator: Floating backbilling
If you set this indicator, floating backbilling can be carried out for the contracts assigned to this rate category. In floating backbilling, backbilling is carried out within a fixed billing period. In floating backbilling, you must specify the number of periods that backbilling covers.
Floating backbilling can be triggered from a periodic billing (or a final billing).
© SAP AG IUT230 14-23
Demand Billing – Cosine Phi – Period-End Billing Business Description
Instead of charging the customer for the demand, the active energy during the on-peak rate period, active energy during the off-peak rate period, and basic price flat rates, you calculate a charge by multiplying the price limit by the minimum energy. The minimum energy in kWh is calculated from the sum of the active energy during the on-peak rate period and the active energy during the off-peak rate period used during the calendar year (period billing).
The bill is created either in a separate bill (period-end billing), or included with the last period billing.
In this period-end billing, the active energy consumed during the on-peak rate period and off-peak rate period (which is updated in the individual period billings) is added. This amount is valuated using a defined maximum price. The result of this calculation is compared with the sum of the amounts from the individual rates in the period billings. The amounts are updated for each rate in the period billings.
If you establish during period-end billing that the period billings during the calendar year were more favorable for the customer, no further billing is carried out. If the comparison yields a negative result, that is, during period-end billing, you establish that the bills created in the adjustment periods (period billings) are not in the customer's favor, the individual adjustment periods are credited, and the valuation from period-end billing is charged to the customer.
This example takes into account the following special features in period-end billing.
It is assumed that the customer uses electricity with a defined cosine phi. Overcompensation above this agreed value is billed at a special price.
The percentage ratio for the normal-rate reactive energy and the normal-rate active energy is used to calculate the current demand factor (cosine phi).
© SAP AG IUT230 14-24
Overview The following table shows an extract of the schema for this billing rule. In addition to the demand calculation (rate E8_3), on-peak (rate E8_1) and off-peak consumption (rate E8_2) are charged in this example. Overcompensation for the reactive current rate is calculated using a separate rate (rate E8_4).
No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1 ExBB BB
All BB1
RevBB1
1 E8_1 QUANTI01
X EQUANT_1
EQPRICE_1
EAMOUNT_1
0004
2 E8_1 LUMSUM01
X ELPRICE_1 EFACTOR_1
EAMOUNT_1
0004
3 E8_1 INFACT06 EQUANT_1
EQUANT_6
4 E8_1 INFACT02 EAMOUNT_1
EAMOUNT_1
5 E8_1 QUANTI14
EQUANT_1
EQUANT_3
6 E8_2 QUANTI01
X EQUANT_2
EQPRICE_2
EAMOUNT_2
0004
7 E8_2 INFACT06 EQUANT_2
EQUANT_7
8 E8_2 INFACT02 EAMOUNT_2
EAMOUNT_2
9 E8_3 DEMAND01
X EDEMAND1
ETPRICE_1 EAMOUNT_3
10 E8_3 INFACT02 EAMOUNT_3
EAMOUNT_3
11 E8_4 QUANTI13
EQUANT_3
EQUANT_9
EFACTOR_3
12 E8_4 IF03 EFACTOR_4
EFACTOR_3
13 E8_4 QUANTI09
EQUANT_3
EFACTOR_2
EQUANT_10
14 E8_4 QUANTI02
EQUANT_9
EQUANT_10
EQUANT_11
15 E8_4 QUANTI01
X EQUANT_11
EQPRICE_5
EAMOUNT_1
16 E8_4 ENDIF
17 E8_E QUANTI10
EQUANT_6
EQUANT_7
EQUANT_8
18* E8_E QUANTI01
X EQUANT_8
EQPRICE_4
EAMOUNT_4
19 E8_E COMPUT02
EAMOUNT_1
EAMOUNT_2
EAMOUNT_5
20 E8_E COMPUT02
EAMOUNT_5
EAMOUNT_3
EAMOUNT_6
© SAP AG IUT230 14-25
21 E8_E IF02 EAMOUNT_4
EAMOUNT_6
22 E8_E UTILIT01 EAMOUNT_4
23 E8_E ELSE
24 E8_E BACKBI01
0004
25 E8_E ENDIF
In addition, deletion operand EAMOUNT_4 must be defined for schema step 18 to create a reference to the UTILIT01 variant in schema step 22.
Key:
Variant: Name of the variant program PR: Billing line items relevant to posting 1st Inp. Op.: First input operand 2nd Inp. Op.: Second input operand 1st Outp. Op.: Output operand ExBB: Execute backbilling indicator BB: Execute schema step in backbilling only indicator AllBB1: Allocate backbilling indicator RevBB1: Reverse backbilling indicator
In addition to the calculation of the on-peak rate active energy (QUANTI01), the rate components of on-peak rate E8_1 contain a time-based flat rate calculation with variant LUMSUM01. The meter reading results and the calculated total amount are updated with the appropriate variants (INFACT06 for the quantities and INFACT02 for the amounts) to the facts for the current installation. With variant QUANTI14, the current meter reading difference (which corresponds to the consumption) is transferred independently of the rate. This step is necessary to define the demand factor (cosine phi) in rate E8_4.
The off-peak rate (E8_2) is valuated using variant QUANTI01. In this case too, the quantity and the calculated amount is updated to the installation facts.
The demand rate only provides for the valuation of the current demand measured in the current month. This is obtained using variant DEMAND01. The calculated amount is also written to the installation facts.
The reactive current calculation is modeled in rate E8_4. In the first step of this rate, the cosine phi is calculated using QUANTI13 from the on-peak rate active energy and reactive energy. The value entered in the first operand is interpreted as active energy, and the value entered in the second operand as reactive energy. Each of the values entered are cumulated, that is, if more than one register is involved, the consumption values are added first. The on-peak rate value results from rate E8_1 that transferred the consumption independently of the rate. The IF03 now checks whether a cosine phi entered in the facts is greater than the current demand factor calculated. If so, a n-% proportion of the on-peak rate active energy is calculated using variant QUANTI09. The result is deducted from the measured reactive energy using variant QUANTI02. With QUANTI01, this quantity is now valuated with a price. The rate nesting is ended using ENDIF.
The final rate, E8_E, is only run in period-end billing. Furthermore, the header data of this rate specifies that it may only be used in period-end billing. After the period billings, a separate period-end billing order is created if the rate category does not provide for period billing with integrated period-end billing.
© SAP AG IUT230 14-26
With variant QUANTI10, the on-peak and off-peak rate quantities cumulated from the period billings are added. This result is valuated with the maximum price with variant QUANTI01. To be able to compare the amounts from the period billings with the amount just calculated, the cumulated on-peak and off-peak rate amounts from the period billings must first be added using variant COMPUT02. In the second step, the total is added to the amount for the demand rate from the period billings. Variant IF02 now compares these amounts. If the calculation in the period billing is more favorable for the customer, the billing line item generated during period-end billing is deleted using UTILIT01. If the comparison yields a negative result, variant BACKBI01 is used to reverse the billing line items (variants) for which the backbilling reversal group is set. The billing line items generated during period-end billing are charged to the customer.
© SAP AG IUT230 14-27
Detailed Description The following variant programs are required for the existing billing rule. These are listed in the same order they appear in the sample billing schema.
Active Energy On-Peak Rate
1 - QUANTI01 - Valuating a quantity with a price
A quantity is valuated with a price. Price prorations are taken into account. If several registers are included in the quantity to be billed, the total consumption of the registers is used when you determine the amount; in other words, the registers are not valuated individually. The calculated amount is updated. The updated amount is used for a maximum price limitation in period-end billing.
2 - LUMSUM01 - Billing a flat rate taking one factor into account
Calculating a flat rate in accordance with a price table. This factor is multiplied with a factor. Prorations of the flat rate prices and the factor are taken into account. The calculated amount is updated and added to the amount calculated in step 1.
3 - INFACT06 - Writing a quantity to the installation facts
In this special case, the output operand defines the operand name that is to be used to write to the installation facts. Input and output operands can have either the same name or different names.
4 - INFACT02 - Writing an amount to the installation facts
In this special case, the output operand defines the operand name that is to be used to write to the installation facts. Input and output operands can have either the same name or different names. This amount is used in period-end billing to calculate the maximum amount.
5 - QUANTI14 - Rate-independent transfer of register operands
The quantity represented by the input operand is updated without changes. This variant is only expedient if the input operand is a register operand. These are only known within the corresponding rate, but may also be needed for processing in different rates. The quantity is required for calculating the cosine phi demand factor.
Active Energy Off-Peak Rate
6 - QUANTI01 - Valuating a quantity with a price
An off-peak rate quantity is valuated with a price.
7 - INFACT06 - Writing a quantity to the installation facts
This quantity is also written to the installation facts.
8 - INFACT02 - Writing an amount to the installation facts
The calculated amount from the valuation of the off-peak rate is written to the installation facts.
© SAP AG IUT230 14-28
Demand Rate 9 - DEMAND01 - Valuating a demand with a price
A demand is valuated with a price. Price prorations are taken into account. The calculated amount is updated. A measured demand is billed here. You can also bill a predefined demand (in conditions, rate category, installation facts), or a demand calculated in a previous schema step. The updated amount is used for a maximum price limitation.
10 - INFACT02 - Writing an amount to the installation facts
The calculated amount from the valuation of the demand rate is written to the installation facts.
Reactive Energy Rate
11 - QUANTI13 - Calculating cosine phi from active energy and reactive energy
The cosine phi is calculated using the active energy and reactive energy. The value entered in the first operand is interpreted as active energy (measured quantity of the on-peak rate register), and the value entered in the second operand as reactive energy (measured quantity of the reactive energy register). Each of the values entered is cumulated, that is, if more than one register is involved, the consumption values are added first.
You must ensure that the calculation for the consumption values in question is based exclusively on the operand name and the consumption values assigned using it. The specifications made at the register level regarding the use of an active energy or reactive energy register are not taken into account.
The cosine phi is calculated as follows:
CosPhi = 1 / SQRT((reactive*reactive) / (active*active) + 1)
For the following, cosine phi is calculated as:
Reactive = 0, active > 0 ==> CosPhi = 1 Reactive > 0, active = 0 ==> CosPhi = 0 Reactive = 0, active = 0 ==> CosPhi = 0
In this way, a cosine phi is calculated and updated for the entire period to be billed.
12 - IF03 - Condition: IF factor1 >,>=,= factor2
This variant introduces an IF nesting level. All the following schema steps are only executed if the condition is fulfilled. The condition is:
IF factor1 > (>=,=) factor2
whereby either the current or the highest values of the input operand are taken into account. In this example, the factor1 > factor2 comparison and the analysis of the current quantity are chosen. Factor1 contains the calculated cosine phi, while factor2 receives the value from the facts.
The IF variant must be ended using an ENDIF variant. You can also use an ELSE variant. If the demand factors are identical, this query generates an additional billing line item for overcompensation.
© SAP AG IUT230 14-29
13 - QUANTI09 - Multiplying a quantity
A quantity is multiplied by a factor, and the result updated. The calculation is made taking into account prorations of the factor. In this example, the measured on-peak rate quantity is multiplied by a factor (n % of the on-peak rate consumption). The percentage is entered in the rate, rate category, or installation facts. The quantity has been transferred in the on-peak rate (E8_1) independently of the rate.
14 - QUANTI02 - Subtracting two quantities
The quantities represented by both input operands are subtracted, and the result updated. If negative results are permitted (see control options), prorations are not relevant. If, however, because of the control setting, you have to know whether this yields a negative result, the time slices resulting from prorations must be analyzed individually.
The n % on-peak rate quantity calculated in the previous step is now subtracted from the measured reactive energy consumption.
15 - QUANTI01 - Valuating a quantity with a price
The calculated difference is valuated with a price.
16 - ENDIF – Ending an IF nesting
You use this variant to end an IF nesting level, that is, all the following variants are executed again.
Period-End Billing Rate
The following steps are only taken in period-end billing.
17 - QUANTI02 - Adding two quantities
The quantities represented by both input operands are added, and the result updated. If historical quantities exist in the period to be billed, these are all added. The origin of the quantities is not relevant, that is, the quantities could be both current meter reading results or values from the installation facts. Info lines relating to the quantity or consumption are written. You can use the control function to define how the operands are to be updated. In period-end billing, the on-peak and off-peak rate consumption values were updated and are now to be added to determine whether the customer is entitled to a particular discount in period-end billing.
18 - QUANTI01 - Valuating a quantity with a price
The total calculated is valuated with a defined maximum price and updated in an amount operand.
19 and 20 - COMPUT02 - Adding two amounts (twice)
The on-peak rate amounts calculated in the period billings are added to the calculated off-peak rate amounts. The result is then added to the calculated demand amounts.
© SAP AG IUT230 14-30
21 - IF02 - Condition: IF amount1 >,>=,= amount2
This variant introduces an IF nesting level. All the following schema steps are only executed if the condition is fulfilled. The condition is:
IF amount1 >= amount2
In this case, only the current input operand values are analyzed.
In this step, the total of the period billings (total of all the amounts for the rates in question) is multiplied by the result of the valuation of the total quantity (on-peak consumption + off-peak consumption), and compared with a defined maximum price.
22 - UTILIT01 - Deleting the billing line items
The billing line items for the amount received are deleted along with their info line items. The billing line items can also be marked as info line items. In this way, they are not relevant to posting or statistics, although they can be printed on the bill. The billing line items to be deleted are identified using the deletion operand.
The schema step is only executed if the condition for variant IF02 is fulfilled. It is fulfilled if the amount calculated using QUANTI01 in the period-end billing rate is greater than the amount resulting from the total of the amount calculations for the rates (period billings).
23 - ELSE – Starting a NOT operation for an IF variant
If this is not the case, the NOT operation variants are executed.
24 - BACKBI01 – Triggering backbilling
This variant triggers backbilling. You can hide billing line items that are not required for backbilling using the control function.
Backbilling is to be carried out or a credit memo issued for all the billing line items created in previous billing periods.
The billing line items to be reversed are selected using the backbilling reversal indicator (backbilling group).
This applies to schema steps 1 and 2 for the on-peak rate, and schema step 6 for the off-peak rate.
25 - ENDIF – Ending an IF nesting
The nesting level opened in the schema step must be ended using this variant.
© SAP AG IUT230 14-31
Rate category The rate category is entered in the utility installation, and controls the following:
monthly billing
period-end billing and floating backbilling
the outsorting check
other billing-relevant data (for example, agreed quantities, demands, prices, or flat rates).
Field Name Name Note
Header Data:
Rate category # Name can be freely assigned.
Division #
General Data
Billing class # As required.
Outsorting price group billing # As required. The outsorting checks during billing are entered (for example, maximum net amount) here.
Billing schema:
Billing schema # Here, you must enter all the rates for an installation that are required for calculation.
Backbilling:
No backbilling X
Number of periods 0
Period-End Billing
Separate period-end bill. X See below
PEB prio. X
Diff. in days 1
Number of periods 12
© SAP AG IUT230 14-32
Period-End Billing Indicator There are essentially three control options for period-end billing:
- No period-end billing
- Integrated period-end billing
- Separate period-end billing
The above example uses the 'separate period-end billing' process.
No period-end billing:
Billing does not provide for any billing rule relating to period-end billing.
Period-end billing with last billing
If this indicator is set, integrated period-end billing is carried out for the contracts assigned to this rate category. In integrated period-end billing, period-end billing is carried out along with the last periodic billing for the period-end billing period (or final billing).
The billing line items resulting from period-end billing are added to the billing document (billing that triggers period-end billing). A separate period-end billing document is not created. In period-end billing, the number of periods covered by period-end billing must be entered.
Separate period-end billing
If this indicator is set, separate period-end billing is carried out for the contracts assigned to this rate category. For this purpose, a period-end billing order is created when the last periodic billing for the period-end billing period (or final billing) is carried out. Period-end billing is executed when the period-end billing order is billed. To do so, you can determine whether period-end billing has to be executed before the next periodic billing.
You can also determine the minimum number of days after the last periodic billing that period-end billing can be carried out. Billing the period-end billing order results in a separate billing document (period-end billing document). In period-end billing, the number of periods covered by period-end billing must be entered.
© SAP AG IUT230 14-33
Period-end billing prioritization
If a period-end billing order is generated when a contract is billed, the value of the field is transferred from the corresponding rate category to the period-end billing order.
It has the following role here:
When this indicator is set, a period-end billing order has priority over another order. If there is another billing order with a different billing procedure for the same contract (periodic, interim billing, etc), this must not be billed until the period-end billing order has been billed.
If this indicator is not set, the period-end billing order does not have a priority. A periodic order for the same contract can be billed before the period-end billing order. This ensures that the next periodic billing is not missed because period-end billing is delayed. This indicator is only relevant for rate categories with period-end billing, and must be set so that the results of period-end billing are used in the next periodic billing.
Example: when the period-end billing rate is executed, values are written to the installation facts and are used in the next periodic billing. The indicator must be set for this procedure.
Difference days: Bill Period-end billing
This field is only relevant in the event of a separate period-end billing. Here, you determine the number of days between the last periodic billing of a period-end billing period (or final billing) and the billing of the period-end billing order.
Period-end billing cannot be carried out before the specified number of days has passed.
Example: The difference specified is 5 days. The last periodic billing was executed on January 3, 2000. This means that the earliest date on which period-end billing can take place is January 8, 2000.
Period lengths in period-end billing
Here, you determine the number of periods covered by the period-end billing period in period-end billing.
© SAP AG IUT230 14-34
Period-End Billing Rate
In the header data for the period-end billing rate, you must set the usage indicator (permissibility) "Period-end billing permitted".
Rate Header Data
Permissibility: Period-end billing permitted
Rate Steps
No. Rate Variant PR Inp. Op.1 Inp. Op.2 Outp. Op.1
1 E8_E QUANTI10
EQUANT_6
EQUANT_7
EQUANT_8
2 E8_E QUANTI01
X EQUANT_8
EQPRICE_4
EAMOUNT_4
3 E8_E COMPUT02
EAMOUNT_1
EAMOUNT_2
EAMOUNT_5
4 E8_E COMPUT02
EAMOUNT_5
EAMOUNT_3
EAMOUNT_6
5 E8_E IF02 EAMOUNT_4
EAMOUNT_6
6 E8_E UTILIT01 EAMOUNT_4
7 E8_E ELSE
8 E8_E BACKBI01
9 E8_E ENDIF
The rate steps for the period-end billing rate are actually only executed in period-end billing.
Period-End Billing Schema Header Data In the billing schema, exactly one rate can be added in the billing schema for which the indicator 'Permissible as period-end billing rate' is set. This means that period-end billing can be carried out with the schema. The key for this rate is displayed in the schema header. The steps for this rate are added at the end of the schema.
© SAP AG IUT230 14-35
Appendix D Recommendation for the Billing Schema
There is no limit to the number of steps you can include in a billing schema. In principle you can create a billing schema with any number of steps. Very large billing schemas are firstly difficult to maintain, and secondly have a negative influence on the performance of billing.
Maintenance: In principle, you can include all the rates for a joint division and billing class in the same schema. However, SAP recommends that you create billing schemas with a maximum of a few hundred steps. Smaller schemas are easier to maintain and analyze. There is a limit as to how small a billing schema may be; all rates that are found using a rate category must exist in the associated billing schema.
Performance: The performance of the billing program is dependent on the number of steps to be executed. If billing involves many schema steps, the runtime can be very long. You should note this when designing billing schemas.
The number of schema steps that are executed internally is also vital for performance. Example:
A billing schema contains steps for the rates T1, T2 .... T10
When you bill a contract, the system only finds rate T1.
The runtime of the billing is therefore dependent on the number of schema steps that belong to rate T1. The number of schema steps for rates T2 to T10 is of no importance in this case.
Some schema steps are executed more than once for schemas with backbilling or dynamic period control. If, for example, a backbilling takes place for the past 10 months, there are schema steps that are executed 10 times internally in the billing. Billing schemas with many steps affect the runtime accordingly when you perform a backbilling.
There is no simple answer to explain how the number of schema steps influences the runtime of the billing program. It is due to the fact that runtimes of some program components (such as database accesses) are dependent on the length of the schema. The runtime of other program components is to a certain extent proportional (for example, analysis of operand values). There are also program components whose runtime is over proportional (analysis of dependencies between the schema steps. The analysis is required for the update).
Experience shows that the runtime is greatly independent of the schema layout when billing residential customers with simple rates. Billing an contract with 15 schema steps requires little more time than a contract with 8 steps.
This does not apply for very large billing schemas. The analysis of billing schemas and dependencies between the schema steps influences the total runtime. SAP highly recommends the following:
Try to enter as few schema steps in the schema layout as possible.
Test the runtime at an early stage using test cases.
Avoid a large number of schema steps if the schema is to be used for many contracts.
Experience shows that persons who are proficient in designing schemas find it easier to map complex requests using few schema steps. If you want to create very complex schemas, it may be appropriate to allow an experienced specialist to check the concept at an early stage.
© SAP AG IUT230 14-36
© SAP AG IUT230 15-1
SAP AG 2006
Master Data for Collective Bill
Collective Bill Documents
Collective Bill Process
Contents:
Collective Bill (Appendix E)
© SAP AG IUT230 15-2
SAP AG 2006
Master Data
C Acct.: 8711Acct cat.: 02
Acct.: 4712Acct cat.: 01CB acct.: 8711
Collector Inc. Anne Miller John Smith Mary Meier
Contract account cat."Collective Bill"
"Normal contract account type" withreference to collective bill account
Acct.: 4713Acct cat.: 01CB acct.: 8711
Acct.: 4714Acct cat.: 01CB acct.: 8711
The collective bill guarantees that contract accounts are processed together in bill creation and other business processes from contract accounts receivable and payable.
The collective bill concept is used in the following areas:
Property management
Housing company
Branch-central office relationships
Example: Tenants in a housing company are supplied by a utility company. The housing company carries out the payment transactions (payments, dunning, returns, correspondence) with the utility company and bills the tenants separately. The bills are paid by the housing company.
The individual contract accounts are allocated to the collective bill contract account (CB account). The CB account is classified by a special contract account category. The individual contract accounts (individual accounts) are allocated to the CB account. You can allocate these in the utilities menu under Business Master Data -> Contract Account -> Create/Change. In the Bill Creation group box, enter the CB account in the field Coll.bill acct. The individual accounts are allocated to contract partners.
Changes to master data will be included in future bill creation. They do not affect existing transaction data.
© SAP AG IUT230 15-3
SAP AG 2006
Posting Document - Contract Accounts Receivable and Payable
Collector Inc. Anne Miller
Business partneritem 116 USD
General ledger item100.00 USD16.00 USD
Doc. 471200
CB document 4711
Business partneritem 116 USD
Doc. 4711
Stat. key: SStat. key: S
When posting documents are created for individual accounts, a statistical posting document is automatically created for the CB account (CB document).
The amount is calculated from the total amounts of the accompanying individual documents.
Posting relevant to the general ledger - if at all necessary - always takes place at individual account level.
In transactions from contract accounts receivable and payable that automatically create a statistical CB document, there is a 1:1 relationship between the individual documents and the CB document. These transactions include:
Post document (FPE1)
Create security deposit (FPSEC1)
Calculate interest individually (FPI1)
Interest run (FPINTM1)
© SAP AG IUT230 15-4
SAP AG 2006
Posting Document - Invoicing
Collector Inc. Anne Miller John Smith
Business partneritem 116 USD
General ledger item100.00 USD16.00 USD
Doc. 471200
CB document 4711
Business partneritem 232.00 USD
General ledger item200.00 USD32.00 USD
Doc. 471300
CB document 4711
Business partneritem 348.00 USD
Doc. 4711
Stat. key: SStat. key: S
When contracts that are allocated to an individual account of a CB construct are invoiced, statistical CB (total) documents are automatically created in the CB account.
When contracts that are allocated to an individual account of a CB construct are invoiced, statistical CB (total) documents are automatically created in the CB account.
For invoicing transactions, several individual documents are grouped together to form a CB document. This means that when these individual accounts are invoiced, a statistical CB document is gradually created according to the structure of the individual documents.
Example: The two individual documents 471200 and 471300 are posted to the contract accounts of contract holders Anne Miller and Henry Smith. These documents can be created by invoicing, a budget billing request or a partial bill. Since the joint CB account 8711 is entered in both contract accounts, the two individual documents are consolidate into one joint CB document; This means that they are allocated to the same CB document 4711. This CB document refers to the business partner Collector Ltd and the CB account 8711. The amount in the CB document is the total amount from the individual contracts.
© SAP AG IUT230 15-5
SAP AG 2006
Posting Document - Budget Billing Amount Request
Collector Inc. Anne Miller John Smith
02.01. 116.00 USD02.02. 116.00 USD02.03. 116.00 USD
Doc. 4711
Business partneritem 348.00 USD
Stat. key: S
BB amount 0815 BB amount 0816
Budget billing request for MM.DD.YYYY creates the statistical collective bill request in the collective bill account.
Collective bill4711
02.01. 232.00 USD02.02. 232.00 USD02.03. 232.00 USD
Request by 01/02Request by 01/02
When the budget billing plan is being created, the system checks whether an individual account is allocated to a CB account. If it is, the CB account is stored in the BB plan and displayed during budget billing plan processing. For regulation purposes, the budget billing items are given the clearing restriction Collective Bill: Refer to Collective Bill Account (6). They can only be paid using a CB document.
During statistical budget billing procedure, posting items from a budget billing plan represent an exception with regards to the time that a collective bill is created. The items are first of all posted without a reference to a collective bill document. The collective bill document is created separately in the budget billing request process.
If you reverse the allocation of a contract account to a collective bill account, clearing restriction 6 is deleted from the budget billing items that have not yet been entered in a budget billing collective bill.
© SAP AG IUT230 15-6
SAP AG 2006
Print Document
Collector Inc. Anne Miller
Bill amount 116.00 USDDue on 05/15
Bill 3334
CB document 4711
John Smith
Bill amount 232.00 USDDue on 05/15
CB document 4711
Cover sheet bill
Bill total 406.00 USD
Due on 05/15
Bill 1018
When a collective bill is created, a collective bill print document is also created. This print document forms the basis of the collective bill cover sheet.
When a collective bill is created, a collective bill print document is also created. This print document forms the basis of the collective bill cover sheet.
Invoicing order 4711Document line item type Z
Bill 3335 Budget billingrequest re58.00 USDDue on 05/15
Bill 2221
CB document 4712
Mary Meier
Invoicing order 4712 Document line item type Z
Collective bill print documents are used for joint bill creation and for correspondence with the collective bill contract partner.
They are created using the collective bill transaction.
In order to create a collective bill print document, an invoicing order (EITR with document line item type Z) is created for each statistical item in the transaction Create Collective Bill. Individual bills cannot be printed at this time.
They can only be printed after the transaction Create Collective Bill has been executed.
For example: Individual bills 3334 and 3335, and individual documents 471200 and 471300 (see previous slide) have been created for the contract accounts belonging to Anne Miller and Henry Smith. Contract account owner Maria Bush receives the budget billing request 2221. Since the joint CB account 8711 has been entered in all contract accounts, the two individual bills have been grouped together as the joint CB document 4711 and the invoicing order 4711 created. This in turn enables the creation of a collective bill print document. During the creation of the budget billing request, CB document 4712 and invoicing order 4712 were created. These invoicing orders refer to the business partner Collector Ltd and the CB account 8711, and are included in a joint collective bill print document.
© SAP AG IUT230 15-7
SAP AG 2008
Processes at Individual and CB Account Level
Billing• Billing document
• Invoicing index
BillClearing type R41, R42, R43Creation reason 01
CB InvoicingClearing type R4ZCreation reason 05
• CB print document
• Print index
• Collective billClearing restriction 7 has beendeleted
• CB invoicing orderis deleted
Budget billingrequestClearing type R6Creation reason 02
Partial BillClearing type R5Creation reason 03
Level ofindividual accounts
CB - Printout
Level of CB
account
• Individual print document- Representative Doc.
ABWBL = 8711
• No print index
• Collective bill- FI-CA document- Document number
OPBEL = 8711- Clearing restriction
AUGRS = 7
• CB invoicing order- Document No. BELNR = 8711- Document type BEL_ART = Z
During the invoicing of individual accounts, print documents are created as the basis of individual bills.
Individual bills cannot be printed at this time.
Statistical CB posting items created during the invoicing of individual accounts are given the clearing restriction Collective Bill: Only Regulate After Collective Invoicing (7) As a result, the CB posting items and accompanying individual documents are blocked for payment and clearing regulation. This prevents them from being (partially) cleared before the collective bill print document has been constructed. They are released by the subsequent transaction Create Collective Bill.
In order to create a collective bill print document, an invoicing order (EITR with document line item type Z) is created for each statistical item in the transaction Create Collective Bill.
Individual bills can only be printed and regulated after the transaction Create Collective Bill has been executed.
© SAP AG IUT230 15-8
SAP AG 2008
Processes at Individual and CB Account Level
• CB reversal print document
• Print index
• Collective billClearing restriction 7 is set
• CB invoicing indexis restructured
Level of individual accounts
CB printoutCB reversal (EA15)Clearing type R4Z
Creation reason 04
Reversal of collective bill does not automatically lead to reversal of individual bills
Level of CB account
You can reverse a collective bill using the transaction Bill Reversal (Mass Reversal) (EA15). This reverses the CB print document as well as the posting documents (interest documents, account maintenance documents) created when the CB print document was created . The individual account bills grouped together in the print document are not automatically reversed.
When a CB print document is reversed, the statistical CB posting items created during the invoicing of individual accounts are given a clearing restriction again, and are blocked for payment. After the reversal, a new CB print document can be created for the CB account. This document can group together the individual invoicing documents that were contained in the original CB print document.
If you want to reverse an individual bill, you do not have to reverse the accompanying CB document. Exception: If the individual bill has was (partially) cleared when the CB was created within the framework of integrated account maintenance. Note: If you want to display the reversal document for the individual bill in the printout, you must reverse the CB print document.
Individual bills and reversal bills that were reversed before before being entered in a CB are not included in a CB.
© SAP AG IUT230 15-9
SAP AG 2006
Basic Functions
When a collective bill is created, the clearing type Create Collective Bill (R4Z) is used as standard.
Transaction and account determination, as well as tax determination do not take place at CB level.
When a collective bill is created, a new due date is notdetermined.
All statistical CB items processed in the CB print document have the original due date they were given when the individual accounts were invoiced. This is also transferred to the CB print document at individual document level.
Note: At the start of the transaction Create Collective Bill (EA10_Coll), set the date in the net due date field (group frame General Selections) so far in the future that the payment date is not changed.
Note: Because CB documents that have the same due dates can be grouped together to form a CB print document, you can minimize the volume of correspondence for each CB account by using a payment condition that determines fixed days in a month as payment targets (for example, due on the 15th of the following month instead of due in 14 days). This means the CB recipient only receives a CB bill once a month.
© SAP AG IUT230 15-10