Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Payment Scheme
Version August 2004
Table of Contents
1. Glossary...................................................................................................................................... 4
2. Introduction ................................................................................................................................. 6
3. Creating a Payment Scheme ....................................................................................................... 7
3.1. General ................................................................................................................................... 7
3.2. Creating a Payment Scheme - Transaction EA61PS................................................................ 8
3.2.1. Including Open Items in the Payment Scheme .................................................................... 9
3.2.2. Determining Amounts for the Payment Scheme................................................................... 9
3.2.3. The Structure of a Payment Scheme ................................................................................. 10
4. Changing a Payment Scheme Manually .................................................................................... 12
5. Displaying a Payment Scheme .................................................................................................. 14
6. Adjusting a Payment Scheme During Creation of a Periodic/Interim Bill ..................................... 18
6.1. Adjusting a Payment Scheme During Creation of an Interim Bill............................................. 18
6.1.1. Adjusting the Payment Scheme for Interim Bill with Recover Rate Completely................... 19
6.1.2. Adjusting the Payment Scheme for Interim Bill with Recover Rate Partially........................ 22
6.1.3. Adjust Payment Scheme for Interim Bill with No Recover Rate .......................................... 24
6.1.4. Adjust Payment Scheme for Interim Bill with Different Recover Rates................................ 25
6.2. Adjusting a Payment Scheme During Creation of a Periodic Bill............................................. 26
6.3. Amount/Percentage Limit Check for Payment Scheme Adjustment........................................ 27
7. Generating Statistical Payment Scheme Requests .................................................................... 28
8. Ending a Payment Scheme ....................................................................................................... 30
9. Customizing .............................................................................................................................. 32
9.1. Customizing in IS-U............................................................................................................... 32
9.1.1. Budget Billing Procedure ................................................................................................... 32
9.1.2. Define Control Parameters for Payment Scheme............................................................... 32
9.1.3. Payment Scheme Category............................................................................................... 33
9.1.4. Define Deactivation Reason .............................................................................................. 34
9.1.5. Number Ranges and Payment Schemes ........................................................................... 34
9.1.6. Rounding Parameters ....................................................................................................... 34
9.1.7. Define Amount/Percentage Limits for Automatic Payment Scheme Adjustment ................. 34
9.1.8. Amount/Percentage Limits for Manual Payment Scheme Adjustment ................................ 35
9.1.9. Customizing for Invoicing .................................................................................................. 35
9.2. Customizing in FI-CA ............................................................................................................ 35
10. Events for Payment Schemes.................................................................................................... 39
10.1. Determining the Extrapolation Period for the Payment Scheme (R510).................................. 39
Page 2 of 58
10.2. Determine Payment Scheme Lines from Billing Document (R511) ......................................... 40
10.3. Determine Budget Billing Amount for Payment Schemes (R512) ........................................... 40
10.4. Adjust Payment Scheme for Periodic/Interim Bill (R513) ........................................................ 40
10.5. Check Amount/Percentage Limits for Payment Scheme Adjustment (R514) .......................... 42
10.6. Selection of Open Items when Creating a Payment Scheme (R515) ...................................... 43
10.7. End Payment Scheme (R516) ............................................................................................... 43
10.8. Activate Payment Scheme (R517) ......................................................................................... 44
10.9. Customer-Specific Checks for First Payment Date (R518) ..................................................... 44
10.10. Customer-Specific Checks for Start Date and Change Date .............................................. 44
10.11. Customer-Specific Checks for Creation Status (R520)....................................................... 44
10.12. Checks for Retaining Payment Periods (R512) .................................................................. 44
10.13. Define Printing Rules for Change/Creation Documents (R522) .......................................... 45
10.14. Notify Activation of Payment Scheme (R523) .................................................................... 45
10.15. Print Change/Creation Documents (R524)......................................................................... 45
10.16. Adjust Customer-Specific Fields for Payment Scheme (R525) ........................................... 45
10.17. Amount Limit Warning Ignored (R526)............................................................................... 45
10.18. Customer-Specific Rules for Amount Rounding in the Payment Scheme (R527)................ 46
10.19. Override Selection of Open Items (R528) .......................................................................... 46
10.20. Change Meter Reading Unit During Creation/Change of Payment Scheme (R529) ............ 46
10.21. Execute Amount Checks (R530)........................................................................................ 46
10.22. Automatic Account Maintenance when Payment Scheme is Ended (R531)........................ 47
10.23. Determine Deactivation Reason for Payment Scheme (R532) ........................................... 47
10.24. Divide Bill End Amount (R533) .......................................................................................... 47
10.25. Adjust Customer-Specific Tables (R534) ........................................................................... 47
10.26. Select Contact Accounting Items for Payment Scheme (R415) .......................................... 47
11. BOR Object PAYSCHEME ........................................................................................................ 49
12. Migrating Payment Schemes ..................................................................................................... 51
13. Archiving and Deleting Payment Schemes................................................................................. 53
13.1. Archiving ............................................................................................................................... 53
13.2. Parallel Processing................................................................................................................ 56
13.3. Simulation Documents........................................................................................................... 56
13.4. Displaying Archived Payment Schemes................................................................................. 56
14. Appendix ................................................................................................................................... 58
14.1. Relevant Transactions........................................................................................................... 58
14.2. Relevant Tables .................................................................................................................... 58
Page 3 of 58
1. Glossary
ADK The archive development kit (ADK) is a tool for developing archiving solutions. At
the same time, it prepares the runtime environment for archiving. It is an
intermediate layer between the application program and the archive, that provides
all the functions required for archiving.
Archive Information Structure
A central element of the archive information system. It enables you to find and
display archived data using selectable data fields.
Archiving object The archiving object is central to the mySAP Technology Data Archiving concept.
This is where you define exactly what to archive and how. The archiving object
describes which data objects must be grouped together to create an object that can
be interpreted for archiving without taking the technical details such as release and
hardware status into account.
Attribute (BOR) An attribute describes the accessible data of a business object.
Clearing restriction A key that determines which business cases can be used to clear open items.
For payment schemes, the clearing restriction “R” is of particular interest. All FI-CA
documents that are included in a payment scheme and all payments in payment
scheme requests are given this clearing restriction. This ensures that these items
can only be processed as part of invoicing or account maintenance.
BOR object An object of the business object repository. It represents a set of facts in the SAP
R/3 system. It contains the function (in the form of methods) as well as the data (in
the form of attributes) for these facts. The implementation details of the business
object are hidden from the user and access is gained by means of defined functions
(methods).
The business object encapsulates business data and functions and makes them
available via interfaces.
CPS/PSC Abbreviation of Customer Payment Scheme or Payment Scheme.
Event (BOR) An object can communicate a change in status by means of an event. Events are
system-wide notifications regarding an object’s status, for example, Payment
Scheme Created or Payment Scheme Ended.
The Business Object Repository is currently limited to the definition and
documentation of events that can be triggered by the objects of an object category.
First payment date Defines the first payment date of a sample line.
If the payment frequency is weekly or fortnightly (2-weekly), the first payment date
is always a week day (Monday to Friday).
For all other payment frequencies (monthly, quarterly, yearly), the first payment
date is a specfic day of the month on which payment must take place.
Field catalog Field catalogs are allocated to archiving objects. They contain fields from the
archiving object tables. These fields can be copied during creation or maintenance
of archive information structures.
FI-CA document type The document type classifies the documents from contract accounts receivable and
payable. They are saved in the document header data when a document is posted.
Each document type is allocated a number range for the creation of individual
documents. The number range determines which values are entered in the
Document Number field. Additional number ranges can also be allocated for the
automatic generation of a large number of documents in (parallel) mass processing.
Additional number ranges are not required if an external number range is allocated
to the document type.
Page 4 of 58
Method (BOR) An object encapsulates its internal status so that the outside world is not dependent
on the implementation. The object provides operations (methods) so that it can be
worked with. These methods are accessible from outside.
Sample line The sample line of a payment scheme contains all time-dependent data such as the
amount to be paid, the first due date, payment frequency, and so on. In the
payment scheme, you create the individual payment scheme requests along with
the sample lines so that the customer can make the payments.
Payment frequency The frequency with which the customer makes payments for a payment scheme.
The following payment frequencies can be used:
W - Weekly
F - Fortnightly
M - Monthly
Q - Quarterly
Y - Yearly
PS Payment scheme
PS request A statistical FI-CA document that is created from the payment scheme sample lines
and that represents the individual payment scheme due dates. The customer
cannot make any payments without this document. The payment scheme requests
can be displayed and changed in the standard FI-CA transactions.
Page 5 of 58
2. Introduction
The payment scheme is a statistical budget billing procedure. Consumption billing amounts from previous
and current billing periods are copied to the payment scheme and distributed evenly over the next billing
period. The budget billing amount is determined partially from an extrapolation portion that reflects the
expected consumption for the current billing period and partially from the copied consumption billings. It is
not necessary to copy consumption billings to the payment scheme in order to use this procedure. If you
do copy them, the bills are not paid directly by the customer but during the next billing period when the
payment scheme requests are paid.
The payment scheme allows payments to be made in weekly, fortnightly, monthly, quarterly, and yearly
cycles.
The validity period of a payment scheme is unrestricted. This means that a payment scheme is not ended
and another created when you create a periodic bill. Instead, the existing payment scheme is adjusted. As
a result, you can charge the customer at least the previous budget billing amount if the periodic bill is late,
for example.
In addition to consumption billings, you can include all other credit and receivables items from the same
contract in the payment scheme.
You can also remove credit and receivables items that you copied to payment scheme if they have not yet
been cleared.
Page 6 of 58
3. Creating a Payment Scheme
3.1. General
You must take the following points into account when creating a payment scheme:
• You always create payment schemes manually. You do this in the Utilities Industry menu under
Invoicing → Budget Billing Plan → Payment Scheme → Create (transaction EA61PS). You can also
use method Create of BOR object PAYSCHEME to create a payment scheme.
• In the standard variant provided by SAP, you can always create a payment scheme for a
subtransaction. If the extrapolation document used as the basis for determining the payment
scheme amount contains more than one subtransaction, the system uses the first debit
subtransaction from the billing document to create the payment scheme. A message will inform you
of this.
• In the standard variant provided by SAP, a payment scheme can only process one tax
determination code in the extrapolation document. If the extrapolation document contains more
than one tax determination code, the system uses the first one to create the payment scheme. A
message will inform you of this.
• You can only use the payment scheme procedure with the Customizing setting Tax Determination
in Billing.
You cannot use the payment scheme procedure in combination with multi-level tax determination
(for example, Tax Jurisdication Code).
• The amount of a payment scheme item can never be smaller than zero. Therefore, a payment
scheme cannot have a credit subtransaction.
• The system creates a separate payment scheme for every mandatory contract (Indicator: Joint
Invoicing in Contract). The following scenarios exist:
There is no other mandatory contract for the contract account:
The system creates the payment scheme without performing specific checks regarding the
mandatory contract.
There is at least one other mandatory contract, for which no payment scheme yet exists:
The system creates a payment scheme for each contract, whereby the payment frequency
and the payment days must be identical in all payment schemes and must be copied to the
payment schemes of the other mandatory contracts.
There is at least one other mandatory contract, for which a payment scheme already exists:
The system compares the payment frequency and payment day values from the new
payment scheme with the data from the existing payment scheme. If the data does not
match, the system proposes an adjustment. You can only create a payment scheme for the
second mandatory contract if you accept this proposal. If you do not accept the proposal but
still want to create a payment scheme for this contract, change the Joint Invoicing in Contract
indicator to Contract Can be Invoiced with Other Contracts or Contract Can Never Be
Invoiced with Other Contracts.
• You can not create a payment scheme with a start date that has already past.
• When you create a payment scheme, a sample line (table EABPL) is created for each contract in
addition to the header data (table EABP). This line contains all data relevant to the payment
scheme such as amount, payment frequency, first payment date, and so on. Before the customer
can make the relevant payments in a payment scheme, you must create statistical requests in
contract accounts receivable and payable. This request data is also determined from the payment
scheme sample lines. They represent the most important connection between the IS-U data and the
contract accounts receivable and payable data in this procedure. Without the sample lines, it is not
possible to create data for the payment scheme in contract accounts receivable and payable.
Page 7 of 58
3.2. Creating a Payment Scheme - Transaction EA61PS
Before you can create a payment scheme, you must define the following data in IS-U/CCS:
• Business partner
• Contract account
• Contract
• Installation
You allocate a business partner to a payment scheme at contract level. You must enter budget billing
procedure 4 (Payment Scheme) in the relevant contract account.
In the initial screen of transaction EA61PS, enter either a business partner, a contract account, or a
contract, for which you want to create a payment scheme. You must also specify the start date of the
payment scheme. This date cannot have already past.
If more than one contract matches your entries, you will be prompted to choose one of them. You must
then provide the following data:
Start Date Here you have the option to change the payment scheme start date that you entered in
the initial screen.
First Due Date This date is the first payment date of a payment scheme. If the payment frequency is
weekly or fortnightly, a week day (Monday to Friday) is used as the payment day. For
all other payment frequencies (monthly, quarterly, annually), the first due date is a
specfic day of the month on which payment must take place.
Payment In this field, you enter how frequently the customer has to make payments. In the
Scheme payment scheme, payments can be made weekly, fortnightly, monthly, quarterly, or
Frequency yearly.
Payment In this field, you can allocate a payment scheme category defined in Customizing to a
Scheme payment scheme. You use the payment scheme category to define, for example,
Category whether it is possible to modify the payment scheme when creating an interim bill, and
whether it is permitted to generate the statistical payment scheme requests in dialog
mode.
PS Inactive If you set this flag, the payment scheme is created with the status Inactive. You can
change an inactive payment scheme in the same way as an active one. The difference
is that you cannot generate payment scheme reuqests for an inactive payment
scheme.
• The contract account does not have any other mandatory contracts, or mandatory contracts exist
for which payment schemes have not yet been created:
In this case, the system creates a payment scheme for each contract. The following data must be
the same in each payment scheme:
Payment day
Payment frequency
Payment scheme category
Payment scheme active/inactive
• The contract account has at least one other mandatory contract, for which a payment scheme
already exists:
Page 8 of 58
The system creates a separate payment scheme for the contract. The following data must be the
same as in the other payment schemes:
Payment frequency
Payment day
Payment scheme category
If the contract account has mandatory contracts with no payment schemes, as well as at least one
contract with a payment scheme, create a new payment scheme for every contract that does not
already have one. Ensure that the above data is the same in all payment schemes.
Page 9 of 58
request is at least as high as the number of days defined in the Define Control Parameters for Payment
Scheme table. If the number of days is lower, the system determines an alternative first payment date and
copies it to the payment scheme.
After event R512, the event Customer-Specific Rules for Rounding Amounts in the Payment Scheme
(R527) is called, in which the payment scheme amount is rounded according to the rules defined in the
Rounding Parameters table.
R515
Manipulation der Auswahlliste offener Posten beim
Anlegen/Ändern eines Zahlungsschemas R512
Ermittlung des Zahlungsschemabetrages
R520
Regeln zum Anlegestatus eines Zahlungsschemas R527
Betragsrundung im Zahlungsschema
R519
Regeln zum Begin und Änderungsdatum
R517
Aktivieren eines Zahlungsschemas
R518
Regeln zum ersten Zahltag
R525
Füllen kundeneigener Felder zum Zahlungsschema
R528
Prüfung ausgewählter Posten beim Anlegen/Ändern
eines Zahlungsschemas
R522
Prüfungen zum Drucken des Erstellungs- bzw.
Änderungsschreibens
R529
Übersteuern der Ableseeinheit beim Anlegen und
manuellen Ändern eines Zahlungsschemas
R524
Druckfunktionalität
R510
Hochrechnungsperiode für das Zahlungsschema
bestimmen
R523
Aktivierung mitteilen
R511
Ermittlung der Zahlungsschemamusterzeilen aus
dem Abrechnungsbeleg
If the contract for which you want to create the payment scheme is a mandatory contract and another
mandatory contract with a payment scheme already exists, the system copies changes made to the
existing payment scheme to the new payment scheme. This means that when the new payment scheme
is created, it can already have several sample lines.
In the Create Payment Scheme transaction (EA61PS), you can make further changes to the new payment
scheme, such as the payment scheme amount or the payment frequency.
When you save the payment scheme, the system first calls the event Fill In User-Defined Fields for
Payment Scheme (R525). In this event, you can define your own fields in the tables Budget Billing Plan
Header Data (EABP) and Budget Billing Sample Lines (EABPL).
The event Print Modification/Creation Documents (R522) then runs. This allows you to check the
consistency of the payment scheme using your own rules. If there are any inconsistencies, you can
prevent the payment scheme from being created at this point.
The system then calls event Print Function (R524) to print out the payment scheme.
Note
Page 10 of 58
You can also use method CREATE of BOR object PAYSCHEME to create a payment scheme.
Page 11 of 58
4. Changing a Payment Scheme Manually
You can change the data of a payment scheme in the Change Payment Scheme transaction (EA62PS),
which you can find in the Utilities Industry menu under Invoicing → Budget Billing Plan → Payment
Scheme → Change.
In the initial screen, enter either a business partner, a contract account, or a contract. Alternatively, you
can enter a payment scheme number directly. If the system finds more than one payment scheme that
matches the input parameters, you have to select one of them from a list. If the payment scheme that you
select belongs to a mandatory contract, and other mandatory contracts with payment schemes exist for
the same contract account, the other payment schemes are also displayed in the selection list.
You can make changes to the payment scheme by entering data directly in the sample lines or by using
the various pushbuttons. You can make changes to the following data:
Page 12 of 58
New payment scheme frequency
Payment scheme category: You can change the payment scheme category
here.
Include Items You can transfer additional open items to a payment scheme. Once you have
selected the open items, the system sends them to event Selection of Open
Items When Selecting a Payment Scheme (R515). You can still restrict the list
of items in the event.
Select the open item that you want to transfer to the payment scheme. Specify
the date as of when you want the items to be taken into account in the
payment scheme. The sample lines are adjusted as of this date. The date
cannot lie before the date proposed by the system or after the date of the next
planned periodic bill. If either of the above cases occur, you will receive an
error message.
Save the data. The items to be transferred are given the clearing restriction
“R”. The amount from the active sample lines that have a start date after the
transport date is adjusted. To determine the new payment scheme amount, all
still open due date items that lie between the transfer date and the planned
end date of the periodic billing period are determined (irrespective of the
change status of the sample lines). The sum of the amounts is divided evenly
amongst the due date items and the sample lines are adjusted accordingly.
The system carries out the same checks as when you enter a new amount
directly in a sample line.
Exclude Items You can also remove items that you have transferred to the payment scheme.
This is the same process as transferring open items. The clearing restriction
“R” is removed from the excluded items.
*If you call a payment scheme using the change transaction, the valid sample line is displayed in a version
that is not ready for input, as well as in a version that is ready for input. The latter version contains the
earliest possible change date for this line as the start date. When determining the date, the system checks
whether the date lies in the past and also whether payment scheme requests that have already been paid
exist after the change date.
If you make a change in the sample line that is ready for input, the line that is not ready for input is
prorated so that its end date is set to the start date of the change minus one day. At the same time, a new
line that is not ready for input is created. This is a copy of the line that you changed.
To transfer a change to the payment scheme, you have to choose Transfer Change.
Note
You can also use various methods of BOR object PAYSCHEME to change a payment scheme.
Page 13 of 58
5. Displaying a Payment Scheme
You can display the data of a payment scheme in the Display Payment Scheme transaction (EA63PS),
which you can find in the Utilities Industry menu under Invoicing → Budget Billing Plan → Payment
Scheme → Display).
On the initial screen, proceed as described in unit 4 (Changing a Payment Scheme Manually).
The display screen is split into three main areas, namely general data, contract data, and sample lines:
• General data: The number of the business partner, the contract account, and the contract
• Contract data: All contract-related payment scheme data:
Field Name Description
Payment Scheme Number
First Due Date The date on which the customer has to pay the payment scheme
amount for the current sample line for the first time. The current sample
line is determined using the system date. The start date of the sample
line lies before the system date and the end date lies after the system
date.
Next Due Date
Payment Scheme Status 00 – Active
01 – Inactive The payment scheme was set to inactive
when it was created and has not yet been
activated. No statistical requests are
generated when the payment scheme has
this status.
02 – Cancelled The payment scheme was ended without
automatic account maintenance and no
interim or periodic bill has been created with
an end date that lies within the billing period.
12 – Inactive and
Cancelled
03 – Deactivated The payment scheme was either ended with
automatic account maintenance, or an
interim/periodic bill with an end date within
the billing period was created for a cancelled
payment scheme.
13 – Inactive and
Deactivated
Payment Scheme Start Date
Next Interim Reassessment Based on the system date, this is the next interim billing and invoicing
Invoicing date. It is irrelevant whether or not the interim billing/invoicing has
already been created.
Division
Alternative Payment Date If the Minimum Number of Days Between Creation/Change Date and
First Payment Date defined in the Define Control Parameters for
Payment Scheme table (TE637) is exceeded when a payment scheme
is created or changed, an alternative first due date is determined for the
relevant sample line.
Page 14 of 58
Next Changeable Due Date Date as of when the changes to the amount or the changeability status
of a sample line become effective. As a rule, this is the next due date of
the payment scheme.
Final Amount of Next Due Date The final amount that the customer must pay on the next due date. It is
determined from extrapolation and from the transferred items.
Next Periodic Invoicing The date of the next planned interim billing and invoicing run. It is
irrelevant whether or not the interim billing/invoicing has already been
created.
• Sample lines
This area contains the data of the individual sample lines, listed according to their start date.
You can change the structure of the lines to meet your own requirements. You can hide individual
fields and change the order of fields.
The area contains the following fields:
Page 15 of 58
Payment Scheme The payment scheme category is defined in the Payment Scheme Category
Category table and is allocated to the sample line.
Bill Portion of Payment This field displays the portion of the amount to be paid that comes from the
Scheme Amount transferred open items.
Total Items Included in This field displays the total amount of all open items included in the payment
Payment Scheme scheme for the corresponding sample line.
Total Amount from This field displays the gross amount determined from extrapolation plus taxes.
Extrapolation
Due Date of Last This field displays the most recently generated payment scheme request
Request (without taking the factory calendar into account)*
Number of Sample This fields displays the consecutive internal number of the sample line.*
Line
Document Number This field displays the document number of the most recently generated
payment scheme request.*
Main Transaction This field displays the FI-CA main transaction of the payment scheme
requests.*
Subtransaction This field displays the FI-CA subtransaction of the payment scheme requests.*
Changed On This field displays the most recent change to the sample line.^^
By This field displays the name of the person that last changed the sample line.
Created On The field displays the creation date of the sample line.
Created By This field displays the name of the person who created the sample line.
Budget Billing Plan This field displays the payment scheme number.*
Contract*
Company Code This field displays the company code for which the payment scheme was
created.*
Contract Account*
Current Remaining Bill Do not copy this field to the display as it is only relevant internally.
Amount
Portion of Open Items This field displays the portion of the total bill amount that was determined for
the selected sample line.*
GK This field displays the grouping key for the tax determination code for budget
billing plans.*
Alternative Payment If the Minimum Number of Days Between Creation/Change Date and First
Date Payment Date defined in the Define Control Parameters for Payment Scheme
table (TE637) is exceeded when a payment scheme is created or changed, an
alternative first due date is determined for the relevant sample line.
Deactivation Status This field displays the reason for deactivating a sample line:
“ „ – Deactivation Due to Manual Change (Only valid for inactive lines)
1 – Deactivation Due to Move-Out
2 – Deactivation Due to Reversal of Move-Out
3 – Deactivation Due to Basic Data Changes
4 – Deactivation Due to Amount Change
Page 16 of 58
5 – Deactivation Due to Termination of Payment Scheme
No.Prev.SL This field displays the number of the previous sample line.*
Billing Document This field displays the number of the extrapolation document that was either
Number generated when the payment scheme was created or for an interim/periodic
bill. This document is the basis for making adjustments to the payment
scheme.*
Print Document This field displays the number of invoicing document that triggerred the
adjustments to the sample line.
FI Document Number This field displays the number of the FI-CA document used (when a move-out
is created and the payment scheme is simultaneously terminated) to clear
open payment scheme requests that have due dates after the move-out date.
Creation Reason This field displays the reason for creating the FI-CA document. At the moment,
this field can only have the value 1 – Move-Out.*
Deactivation Doc. This field displays the number of the print document that caused the full
deactivation of a sample line when is was created.*
* - It is not necessary to include these fields in the display. Keep the display screen as consice as
possible.
Choose Payment Details to display the payment data, the first due date, the payment frequency, and the
amount to be paid.
Choose Payment History to display an overview of the total amount to be paid. Changes to individual
sample lines are included in the display.
Page 17 of 58
6. Adjusting a Payment Scheme During Creation of a
Periodic/Interim Bill
A payment scheme does not end when a periodic bill is created, rather it is adjusted on the basis of a new
extrapolation. In this way, if a periodic bill is created late, for example, you can still demand at least the
previous payment scheme amount from the customer. When a periodic bill is executed, the system takes
these additional payments into account when adjusting the payment scheme.
A payment scheme may also need to be adjusted when you create an interim bill. However, for this to take
place, you must have set the flag for adjusting budget billing amounts (for unscheduled interim bills), or
the flag in the schedule master record for the meter reading unit (for scheduled interim bills) when you
created the meter reading order.
The payment scheme is not adjusted during execution of the periodic/interim bill. Based on the settings in
Clearing Control, the payment scheme payments are cleared against the current bill and/or the open items
that were transferred to the payment scheme. The details of this clearing process are determined by the
settings that you made in Customizing for Clearing Control. We recommend you make the settings in
Clearing Control so that payments from the payment scheme requests (identified by clearing restriction
‘R’) are first cleared against the items posted to the payment scheme (identified by clearing restriction ‘R’)
and then against the new interim or interval bill.
You can transfer additional open items to a payment scheme when you create a periodic or interim bill.
This is taken into account when adjusting the payment scheme amount.
Page 18 of 58
• Recovery rate for a short remaining period
You use this recovery rate if no more than 37.5 percent of all due dates in the billing period lie
between the start of the adjustment and the planned end of the current billing date.
You can choose between the following values for each of the recovery rates:
• Completely
• Partially
• None
In addition to the payment scheme amount being adjusted due to a changed extrapolation amount, it can
also change during creation of an interim bill. This is because of the open items that are transferred to the
payment scheme:
• All open items that are the result of account maintenance, transfer posting, and requests with
invoicing, and that are processed in invoicing are transferred by the system to event Transfer of
Open Items During Invoicing (R415). You can use this event to exclude certain items from being
transferred. As default, all items are transferred to the payment scheme.
• The system does not transfer open items from the recently generated consumption billing to event
R415.
• The system divides the sum of all the selected items evenly amongst the payment scheme requests
remaining in the periodic billing period.
After an interim billing with a budget billing amount adjustment, the payment scheme amount is made up
of the following components:
• The portion of the bill consisting of credit and receivables items that were transferred to the
payment scheme for the most recent periodic bill.
• The portion of the bill consisting of credit and receivables items that were newly transferred to the
payment scheme for the current interim bill.
• The new extrapolation amount.
The first two bill portions are always listed together in the payment scheme.
6.1.1. Adjusting the Payment Scheme for Interim Bill with Recover
Rate Completely
The system adjusts the payment scheme sample lines so that excess consumption or underconsumption
from the interim billing period as against the consumption from the original extrapolation is completely
divided amongst the remaining payment scheme due dates (until the next planned interim billing period).
The following basic rules apply:
• The extrapolation period in the interim billing document must correspond exactly to the extrapolation
period of the most recent interim bill or the period used for extrapolation when the payment scheme
was created. This ensures that any seasonal rate variations are taken into account.
• All payments that are to be made within the current interim billing period are subtracted from the
extrapolation amount (net amount plus VAT). It does not matter whether the payments have actually
been made, or whether the payment scheme requests are still unpaid. Payment scheme requests
are only taken into account if the due date lies within the billing period.
The portion used for clearing transferred open items is not taken into account when subtracting the
payments.
• The portion remaining from the extrapolation amount is divided evenly amongst the payment
scheme due dates remaining until the end of the current periodic billing period.
Page 19 of 58
The following examples are based on the assumption the all Recovery Rates are assigned the value
Completely. The following applies for all examples:
st st st
You create a periodic bill for a customer on 1 January. For the periodic billing period 1 January until 31
December, the system determines an extrapolation amount of €600. You also transfer open items to the
value of €180 to the payment scheme. In the payment scheme, the payment frequency is monthly and the
th
payment date is the 20 of each month. The system determines the payment scheme amount to be €65.
This includes an extrapolation portion of €50 and a clearing portion of €15 for the transferred items.
st
You execute an interim billing for the customer on 1 July. The payment scheme amount is adjusted when
this billing is invoiced.
Example 1
The customer has paid all payment scheme requests on time up to and including the month of June.
st
During creation of the interim billing document, extrapolation is executed for the period January 1 to
st
December 31 . The result of this is €600. No additional items should now be added to the payment
scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 600 – (6 * 50) = 300
• Open due dates until the end of the periodic billing period: 6
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
New payment scheme amount: 15 + (300 / 6) = 65
Example 2
The customer has paid all payment scheme requests on time up to and including the month of June.
During creation of the interim billing document, extrapolation is executed for the period January 1st to
st
December 31 . The result of this is €750. No additional items should now be added to the payment
scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 750 – (6 * 50) = 450
• Open due dates until the end of the periodic billing period: 6
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
New payment scheme amount: 15 + (450/ 6) = 90
Example 3
The customer has paid all payment scheme requests on time up to and including the month of June.
st
During creation of the interim billing document, extrapolation is executed for the period January 1 to
st
December 31 . The result of this is €450. No additional items should now be added to the payment
scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 450 – (6 * 50) = 150
• Open due dates until the end of the periodic billing period: 6
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
New payment scheme amount: 15 + (150 / 6) = 40
Example 4
Page 20 of 58
The customer has paid all payment scheme requests on time up to and including the month of May.
Payment for the month of June has not yet been made (payment overdue). During creation of the interim
st st
billing document, extrapolation is executed for the period January 1 to December 31 . The result of this
is €750. No additional items should now be added to the payment scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 750 – (5 * 50 + 1 * 50) = 450
Even though payment has not been made for the month of June, the payment scheme amount is
adjusted as if payment had been made. This is because you assume that the customer will still pay.
• Open due dates until the end of the periodic billing period: 6
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (450 / 6) = 90
Example 5
The customer has paid all payment scheme requests on time up to and including the month of June. He
has also paid the payment scheme request for the month of July as he will be on vacation at that time.
During creation of the interim billing document, extrapolation is executed for the period January 1st to
st
December 31 . The result of this is €750. An additional credit item of €50 is added to the payment
scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 750 – (6 * 50 + 1 * 50) = 400
Since the customer has already made payment for the month of July, this month is taken into
account when determining the new extrapolation amount: This has the effect that the amount for
July is also deducted from the extrapolation amount. It also means that the due date for July is no
longer taken into account for the payment scheme adjustment.
• Open due dates until the end of the periodic billing period: 5
• Since an additional credit item of €50 is added to the payment scheme, the bill portion of the
payment scheme amount changes to 15 + (-50/5) = 5.
• New payment scheme amount: 5 + (400 / 5) = 85
Example 6
st
On March 1 the customer informs you of an increase in expected consumption, which in turn results in a
th
higher monthly payment scheme amount. As of March 20 the amount increases to €80 (€65 consumption
and €15 transferred items).
th
On May 17 the customer requests to change the payment frequency from monthly to fortnightly. This
th th
change is to take effect on August 15 with August 18 as the first payment date.
th
On June 7 the customer wants to make another change to the payment frequency. Starting from
st th
November 1 , he wants to change the payment frequency to quarterly and have November 20 as the first
payment day.
All payment scheme requests up to and including the month of June have been paid on time.
st
During creation of the interim billing document, extrapolation is executed for the period January 1 to
st
December 31 . The result of this is €900.
No additional items should now be added to the payment scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 900 – (2 * 50 + 4 * 65) = 540
Note that the extrapolation portion of the payment scheme amount was increased to €65 as of
March.
• Open due dates until the end of the periodic billing period:
Page 21 of 58
1 with monthly payment frequency
6 with fortnightly payment frequency
1 with quarterly payment frequency
• Since no additional open items are added to the payment scheme, the bill amount to be divided for
st st
the period July 1 to December 31 remains at €90.
• Therefore, the full amount to be divided amongst the remaining payment scheme requests is 540 +
90 = 630
In order to be able to divide this amount between the remaining due dates, the dates are first
converted so they all have the same payment frequency (weekly, for example). This results in the
following:
Monthly – 4,3 weeks (52 / 12)
Fortnightly – 2 weeks
Quarterly - 13 weeks (52 / 4)
If you add together all the end values you get a period of 29.3 weeks over which to divide the
amount of €630. This results in a weekly amount of €21.50. Using the number of weeks for
each payment frequency, the following payment scheme amounts can be determined for the
different payment frequencies:
Monthly - 4.3 * 21.5 = 92.45
Fortnightly - 2 * 21.5 = 43.00
Quarterly - 13 * 21.5 = 279.55
Example 7
st
The interim bill created on July 1 is based on an estimation. Therefore, it does not result in a change to
the payment scheme amount.
th
On November 25 the customer provides you with an actual meter reading. You carry out an unplanned
interim billing with adjustment to the payment scheme amount. During creation of the billing document,
st st
extrapolation is executed for the period January 1 to December 31 . The result of this is an extrapolation
amount of €750.
All payment scheme requests up to and including the month of November have been paid on time.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 750 – (11 * 50) = 200
• Open due dates until the end of the periodic billing period: 1
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (200 / 1) = 215
Caution
The payment scheme amount has more than trebled. Therefore, you must define
amount/percentage limits for the payment scheme amount adjustment.
6.1.2. Adjusting the Payment Scheme for Interim Bill with Recover
Rate Partially
Page 22 of 58
With recovery rate Partially, the excess consumption and underconsumption from the interim billing period
are only partially divided amongst the remaining payment scheme due dates. The extrapolation amount is
divided using the following basic rules:
• The extrapolation period in the interim billing document corresponds exactly to the extrapolation
period used for the most recent interim bill or that was used for extrapolation when the payment
scheme was created. This ensures that any seasonal variations in the rate are also taken into
account for extrapolation in the interim bill.
A B
• The calculated extrapolation amount (new amount plus tax) E is split into two parts, E und E .
EA is the extrapolation portion for the period from the end of the billing period of the most recent
periodic bill to the end of the interim billing period.
B
E is the extrapolation portion for the period from the end of the interim billing period to the end of
the current periodic billing period.
A B
The division of E into E and E takes place linearly based on the number of payment scheme due
dates within the two periods.
A
All payment scheme requests are subtracted from extrapolation portion E . The same conditions
A
apply as with adjustment with recovery rate Completely. The resulting amount E ’ is then split into
A1 A2
two further parts, E and E . First of all the number of payment scheme due dates is determined
A1 A
starting from the end of the interim billing period. The relationship between E and E ’ corresponds
to the relationship between the number of payment scheme due dates between the end of the
interim billing period and the and of the current periodic billing period and the total number of
payment scheme due dates in one year. In order for any changes in the payment frequency to be
taken into account, all of the payment scheme’s frequencies are converted into one weekly
frequency according to a specific key.
B A1
• The sum of E and E is then divided evenly amongst the payment scheme due dates remaining
until the end of the current periodic billing period.
The following examples are based on the assumption the all recovery rates are assigned the value
Partially. The following applies for all examples:
st st st
A periodic bill is created for a customer on January 1 . For the periodic billing period 1 January until 31
December, the system determines an extrapolation amount of €600. Open items to the value of €180 are
included in the payment scheme.
th
In the payment scheme, the payment frequency is monthly and the payment date is the 20 of each
month. The payment scheme amount is €65. This includes an extrapolation portion of €50 and a clearing
portion of €15 for the transferred items.
st
You execute an interim billing for the customer on 1 July. The payment scheme amount is adjusted when
this billing is invoiced.
...
Example 1
The customer has paid all payment scheme requests on time up to and including the month of June.
st
During creation of the interim billing document, extrapolation is executed for the period January 1 to
st
December 31 . The result of this is €600.
No additional items should now be added to the payment scheme.
The payment scheme amount is adjusted as follows:
• The extrapolation amount is split into two parts:
A
E = €300
B
E = €300
A A
• The portion of E that the customer has not yet paid (E ’) is EA’ = 300 – (6*50) = 0.
A A1 A2
E ’ is split into two parts E = €0 and E = €0.
The extrapolation portion still to be divided is 300 + 0 = 300.
• Open due dates until the end of the periodic billing period: 6
Page 23 of 58
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (300 / 6) = 65
Example 2
The customer has paid all payment scheme requests on time up to and including the month of June.
st
During creation of the interim billing document, extrapolation is executed for the period January 1 to
st
December 31 . The result of this is €750.
No additional items should now be added to the payment scheme.
The payment scheme amount is adjusted as follows:
• The extrapolation amount is split into two parts:
A
E = €375
B
E = €375
A A
• The portion of E that the customer has not yet paid (EA’) is E ’ = 375 – (6*50) = 75
A A1 A2
E ’ is split into two parts E = €37.5 and E = €37.5.
The extrapolation amount still to be divided is 375 +37.5 = 412.5.
• Open due dates until the end of the periodic billing period: 6
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (412,5 / 6) = 83,75
Example 3
st
The interim bill created on 1 July is based on an estimation. Therefore, it does not result in a change to
the payment scheme amount.
th
On November 25 the customer provides you with an actual meter reading. You carry out an unplanned
interim billing with adjustment to the payment scheme amount. During creation of the billing document,
st st
extrapolation is executed for the period January 1 to December 31 . The result of this is an extrapolation
amount of €750.
The customer has paid all payment scheme requests on time up to and including the month of June. No
additional items should now be added to the payment scheme.
The payment scheme amount is adjusted as follows:
• The extrapolation amount is split into two parts:
A
E = 750 * (11/12) = €687.50
B
E = 750 * (1/12) = €62.50
A A A
• The portion of E that the customer has not yet paid (E ’) is E ’ = 687.5 – (11*50) = 137.5
EA’ is split into two parts EA1 = €11.46 and EA2 = €126.04
The extrapolation amount still to be divided is 62.50 + 11.46 = 73.96
• Open due dates until the end of the periodic billing period: 1
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (73.96 / 1) = 88.96
6.1.3. Adjust Payment Scheme for Interim Bill with No Recover Rate
Page 24 of 58
Excess consumption or underconsumption within the interim billing period is not taken into account. When
dividing the extrapolation amount (net amount plus tax), the system uses the following basic rules:
• The extrapolation period in the interim billing document must correspond exactly to the extrapolation
period used for the most recent interim bill or that was used for extrapolation when the payment
scheme was created. This ensures that any seasonal rate variations are also taken into account for
extrapolation in the interim bill.
A B
• The calculated extrapolation amount (new amount plus tax) E is split into two parts, E und E .
EA is the extrapolation portion for the period from the end of the billing period of the most recent
periodic bill to the end of the interim billing period
B
E is the extrapolation portion for the period from the end of the interim billing period to the end of
the current periodic billing period.
A B
The division of E into E and E takes place linearly based on the number of payment scheme due
dates within the two periods.
B
• The amount E is divided evenly amongst the payment scheme due dates remaining until the end of
the current periodic billing period.
6.1.4. Adjust Payment Scheme for Interim Bill with Different Recover
Rates
The following examples are based on the assumption that the recovery rates have the following values:
• For a long remaining period - Completely
• For a medium remaining period - Partially
• For a short remaining period - None
The extrapolation amount is determined as described in the previous chapters.
The following applies for all examples:
st st st
A periodic bill is created for a customer on January 1 . For the periodic billing period 1 January until 31
December, the system determines an extrapolation amount of €600. Open items to the value of €180 are
transferred to the payment scheme.
th
In the payment scheme, the payment frequency is monthly and the payment date is the 20 of each
month. The payment scheme amount is €65. This includes an extrapolation portion of €50 and a clearing
portion of €15 for the transferred items.
Example 1
You execute an interim billing for the customer on 1st April. The payment scheme amount is adjusted
when this billing is invoiced. During creation of the interim billing document, extrapolation is executed for
st st
the period January 1 to December 31 . The result of this is €750. The customer has paid all payment
scheme requests on time up to and including the month of June. No additional items should now be added
to the payment scheme.
Since more than 75 percent of the payment scheme due dates from the current periodic billing period are
in the future, the recovery rate for a long remaining period (Completely) is used to adjust the payment
scheme.
The payment scheme amount is adjusted as follows:
• Extrapolation amount to be divided: 750 – (3 * 50) = 600
• Open due dates until the end of the periodic billing period: 9
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
Page 25 of 58
• New payment scheme amount: 15 + (600/ 9) = 81,67
Example 2
st
You execute an interim billing for the customer on 1 June. The payment scheme amount is adjusted
when this billing is invoiced. During creation of the interim billing document, extrapolation is executed for
st st
the period January 1 to December 31 . The result of this is €750. The customer has paid all payment
scheme requests on time up to and including the month of June. No additional items should now be added
to the payment scheme.
Since 50 percent of the payment scheme due dates from the current periodic billing period are in the
future, the recovery rate for a medium remaining period (Partially) is used to adjust the payment scheme.
The payment scheme amount is adjusted as follows:
• The extrapolation amount is split into two parts:
A
E = €375
B
E = €375
A A A
• The portion of E that the customer has not yet paid (E ’) is E ’ = 375 – (6*50) = 75
A A1 A2
E ’ is split into two parts E = €37.50 and E = €37.50.
The extrapolation amount still to be divided is 375 +37.5 = 412.5.
• Open due dates until the end of the periodic billing period: 6
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (412.5 / 6) = 83.75
Example 3
st
On June 1 you execute an interim billing for the customer based on an estimated meter reading result.
This does not result in an adjustment to the payment scheme.
th
On November 25 the customer provides you with an actual meter reading. You carry out an unplanned
interim billing with adjustment to the payment scheme amount. During creation of the billing document,
st st
extrapolation is executed for the period January 1 to December 31 . The result of this is an extrapolation
amount of €750. The customer has paid all payment scheme requests on time up to and including the
month of November. No additional items should now be added to the payment scheme.
Since less than 37.5 percent of the payment scheme due dates from the current periodic billing period are
in the future, the recovery rate for a short remaining period (None) is used to adjust the payment scheme.
The payment scheme amount is adjusted as follows:
• The extrapolation amount is split into two parts:
A
E = €687.50
B
E = €62.50
• The extrapolation amount still to be divided is €62.50
• Open due dates until the end of the periodic billing period: 1
• Since no additional open items are added to the payment scheme, the bill portion of the payment
scheme amount remains unchanged at €15.
• New payment scheme amount: 15 + (62.5 / 1) = 77.5
Page 26 of 58
The payment scheme amount is generally adjusted when a periodic bill is created.
During creation of the billing document, the system carries out an extrapolation for the subsequent
periodic billing period. This can result in an adjustment to the payment scheme amount.
You can add the receivables and the credit items as well as other open items from the current
consumption billing to the payment scheme.
Since a periodic bill is a type of restart for a payment scheme, any unpaid payment scheme requests that
have a due date within the billing period become invalid. If these requests have already been included in a
dunning run, the information is no longer available to you once the periodic bill has been created.
If the customer has already paid budget billing requests with due dates that lie after the end of the billing
period, these payments are taken into account when the extrapolation portion of the payment scheme
amount is adjusted. This means that the newly determined extrapolation amount is reduced by the value
of the requests that have already been paid. The remaining amount is divided amongst the remaining
payment scheme due dates.
You can add additional open items to a payment scheme when you create a periodic bill. You can select
items from the current consumption billing that are the result of account maintenance, transfer posting,
requests with invoicing, and that are processed in invoicing
The system marks these items for transfer to the payment scheme and transfers them to event Transfer of
Open Items During Invoicing (R415). You can also use this event to exclude certain items from being
transferred.
If you want to transfer additional items that are not a result of the processes mentioned previously, you
must select them so that they are taken into account during account maintenance or as a transfer
document when the periodic bill is invoiced. Make the necessary settings in Customizing for SAP Utilities
under Invoicing → Invoice Processing → Item Selection in Invoicing → Item Selection for Account
Maintenance/Define Sub-Items.
Example
Adjusting a payment scheme during creation of a periodic bill:
st
A periodic bill is created for a customer on January 1 . The payment scheme to be adjusted has a monthly
th
payment frequency and with the payment date on the 20 of each month.
st st
The extrapolation for the period January 1 to December 31 results in a gross amount of €600.
The following items are transferred to the payment scheme:
• Additional payment of current periodic bill: €90
• Account maintenance €30
• Request with invoicing: €100
- €40
The full amount transferred to the payment scheme is €180.
There are 12 open payment scheme requests until the end of the new periodic bill.
After the payment scheme has been adjusted, the new amount is (600 + 180) / 12 = 65
This consists of an extrapolation amount of €50 and open items transferred to the payment scheme to the
value of €15.
Page 27 of 58
You define the adjustment limits in table Amount/Percentage Limits for Payment Scheme Adjustment in
Invoicing (TE558), where you can make entries for interim and periodic bills for each billing class, division,
payment frequency, currency, and payment scheme category.
The checks take place at contract level regardless of whether the contract is optional or mandatory.
If then system cannot find any entries in this table, the change in question is accepted.
The system carries out the check in event Check Amount/Percentage Limits for Automatic Payment
Scheme Adjustment (R514), for which SAP provides a standard logic.
Page 29 of 58
8. Ending a Payment Scheme
You use transaction E61PSD or method TERMINATE of BOR object PAYSCHEME to end a payment
scheme.
Select a payment scheme that you want to end and enter the end date. If you have maintained table
Payment Scheme Deactivation Reason (TE561), enter a deactivation reason as well. This has no effect
on the deactivation process and is not analyzed by the system. However, you can use it at a later point in
time to analyze the deactivated payment schemes.
Once you have entered the end date, the system checks whether payment scheme requests that have
already been paid exist after the end date. If this is the case, the end date is set to the next due date plus
one day.
Depending on the sequence of the end date and the first payment date of the payment scheme, the
system proceeds as follows:
• If the end date lies before the first payment date of the payment scheme, the payment scheme is
deleted from the database. If you have already created statistical requests for this payment scheme,
they are cleared.
• If the end date lies after the first payment date of the payment scheme, the system executes the
following actions:
a. The payment scheme sample line that is active on the end date is prorated so that its end
date is the same as the end date of the payment scheme. A new sample line is created for
the part of the sample line that comes after the end date.
b. All payment scheme sample lines with a start date that comes after the end date are
deactivated.
c. The end date and, if necessary, the deactivation reason are entered in the payment scheme
header data.
d. All statistical requests with due dates that lie after the end date are cleared.
Payment schemes that are ended this way remain active until the end date. You can either change
the payment scheme manually or during creation of an interim or periodic bill. You can also create
statistical requests for this payment scheme. You can change the end date again as long as the
new date comes before the end date that was entered previously.
In order to ensure that a payment scheme can no longer be changed, you must deactivate it once it
has ended. You do this by creating an interim or periodic bill with a billing period that contains the
end date of the payment scheme. During creation of this bill, all payment scheme requests that
have not yet been paid are cleared. Requests with due dates that come after the most recent
interim or periodic bill and that have already been paid are settled against the current consumption
billing when the bill is created. Any overpayments can be refunded at a later point in time. The
system removes the clearing restriction “R” from all items that were transferred to the payment
scheme that have not yet been paid.
If the interim/periodic bill is reversed, the entire process is cancelled. This means that the clearing of
the paid requests against the transferred items and the current consumption billing is also reversed.
All items that had the clearing restriction “R” before the bill was created are assigned it again.
• If you enter the current date as the end date, the system may react differently to the above
description. This happens when event Automatic Account Maintenance When Payment Scheme is
Ended (R531) returns parameter X_NO_ACC_MAIN (No Automatic Account Maintenance When PS
is Ended) with the value " ". When the payment scheme is ended, the system carries out integrated
automatic account maintenance. In account maintenance, all payment scheme requests that were
paid after the last interim/periodic bill are settled against all the open items that were transferred to
the payment scheme. If the payments are not enough to clear the items, the clearing restriction “R”
is removed from the remaining open items. If the amount paid is too high, the clearing restriction “R”
is removed from the payment scheme request payments that are not required for account
Page 30 of 58
maintenance. You can either refund the customer directly or settle the excess payment in the next
consumption billing.
Note
When a payment scheme is ended, automatic account maintenance only takes place if the end date
is the same as the current date. You cannot cancel this process.
Page 31 of 58
9. Customizing
9.1. Customizing in IS-U
The following sections describe the individual tables available in Customizing: Unless specifically
mentioned, you can find the tables in Customizing for SAP Utilities under Invoicing → Budget Billing Plan
→ Payment Scheme. .
Page 32 of 58
You use this recovery rate if more than 62.5 percent of all due dates in the billing period lie
between the start of the adjustment and the planned end of the current billing date.
Recovery Rate (Medium Remaining Period) Rec.Rate (M):
You use this recovery rate if more than 37.5 percent and no more than 62.5 percent of all
due dates in the billing period lie between the start of the adjustment and the planned end of
the current billing date.
Recovery Rate (Short Remaining Period) Rec.Rate (S):
You use this recovery rate if no more than 37.5 percent of all due dates in the billing period
lie between the start of the adjustment and the planned end of the current billing date.
For each of these periods, you can specify whether the full amount, part of the interim bill amount,
or no amount is taken into account when the payment scheme is adjusted for the interim bill.
• Print Payment Scheme
In this area, you can define a form for each of the processes Create Payment Scheme and Change
Payment Scheme.
Page 33 of 58
settings you made in the meter reading unit and regardless of whether you specified in the meter
reading order that existing payment schemes are to be adjusted.
Under basic Settings → Define Deactivation Reason (table TE561), you can define deactivation reasons,
which you can then use when ending a payment scheme.
As well as the three-figure code for the deactivation reason, you can also enter a descriptive text.
Under Basic Settings → Define Number Range for Payment Scheme, enter a number range interval for
the number range object IS-U Budget Billing Plan, from which the system can determine the number of the
payment scheme. You allocate the interval to the number range object ISU_EABP under Allocate Number
Range of Number Range Object to Payment Scheme.
Under Amount Determination and Change of Amount → Define Rounding Parameters (table TE211),
determine the rounding parameters to be used in the standard logic of event Amount Rounding in
Payment Scheme (R527) to round up payment scheme amounts when a payment scheme is created or
changed.
Caution
If you do not want to use this table, modify event R527 accordingly.
For each billing Class/Currency/Sequence Number, determine how the payment scheme amount should
be rounded. You can define multiple intervals so that it is possible to determine different rounding rules
according to the budget billing amount.
The following rounding parameters are available:
• -3: Round to the nearest thousand
• -2: Round to the nearest hundred
• -1: Round to the nearest ten
• 0: Round to the nearest whole number
• 1: Round to first decimal place
• 2: Round to second decimal place
• 3: Round to third decimal place
Under Amount Determination → Define Amount/Percentage Limits for Payment Scheme Modification in
Invoicing (table TE558), define the amount and percentage limits for adjusting payment schemes during
creation of an interim or periodic bill.
The following key fields are available:
...
• Billing Class
• Division
Page 34 of 58
• Billing Transaction (Interim Bill, Periodic Bill)
• Payment Frequency (Annually, Quarterly, Monthly, Every 2 Weeks, Weekly)
• Currency
• Payment Scheme Category
You can define the following for each combination of key fields:
...
Under Amount Determination and Change of Amount → Define Percentage Limits for Manual Payment
Scheme Requests (table TE560), define the amount and percentage limits for changing payment schemes
manually.
For the fields Billing Class, Division, Payment Frequency, Currency, and Payment Scheme Category, you
have the same input options as in Customizing for Amount/Percentage Limits for Automatic Payment
Scheme Adjustment.
The settings that you make here are evaluated in the standard logic for event Check Amount/Percentage
Limits for Manual Payment Scheme Adjustment (R526).
Table 9.1: Example of Defining an External Main Transaction for the Payment Scheme
Example
Ext. Main Ext. Sub- Description Comment
Transaction transaction
1053 Budget Billing: Payment This entry is used to define the
Scheme budget billing procedure
0010 Budget Billing Payment
0110 Extrapolation Budget Billing It is possible to use this
Plan (Credit) subtransaction for extrapolation in
a rate, however, the extrapolation
amount must always have a
minimum value of zero. The
payment scheme will not accept a
negative extrapolation amount.
0120 Extrapolation Budget Billing
Plan (Debit)
Table 9.3: Example of Allocating External Main and Subtransactions to Internal Tranactions
When you allocate the external transactions to the internal main and subtransactions, make sure
that the external subtransactions for Extrapolation Budget Billing Plan Credit and Debit (1053/0110
und 1053/0120 in the example) are not allocated to internal transactions.
Page 36 of 58
3. Maintaining the transaction attributes
For all posting transactions, you must maintain the transaction attributes (credit/debit indicator) in
table Transactions for Company Code and Division (TE305) for every division and every company
code. You do this in Customizing for Financial Accounting under Contract Accouns Receivable and
Payable → Basic Functions → Postings and Documents → Document → Maintain Document
Assignments → Maintain Transactions for Industry-Specific Component Utilities → Maintain
Transactions for Budget Billing.
Example
Co.Code Divisio Ext. Ext. Description Debit/Credit
n MTran. STran. Indicator
0001 01 1053 0110 Extrapolation Budget H
Billing Plan (Credit)
0120 Extrapolation Budget S
Billing Plan (Debit)
Table 9.4: Example of Transaction Attributes for a Combination or Company Code and
Division (TE305)
In Customizing under Contract Accounts Receivable and Payable → Basic Functions → Postings
and Documents → Document → Maintain Document Assignments → Manintain Transactions for
Industry-Specific Component Utilities → Maintain Subtransactions for Budget Billings, you must also
determine for each subtransaction used for extrapolation in the payment scheme whether it is a
credit or a debit subtransaction (table Define Debit/Credit Indicator for Budget Billing
Subtransactions / TEABSTOVR). These entries must correspond to the entries in table TE305.
Example
Application Area Ext. Ext. Description Debit/Credit
MTran. STran. Indicator
R 1053 0110 Extrapolation Budget H
Billing Plan (Credit)
R 1053 0120 Extrapolation Budget S
Billing Plan (Debit)
Table 9.5: Example for Transaction Attributes in Table Subtransactions for Budget Billings
(TEABSTVOR)
Example
Company Divisio Account Ext. Main Ext. Account
Code n Determination ID Transaction Subtransacti Number
on
0001 01 01 1053 0110 0000170060
Example
Statistica Ext. Main Ext. Ext. Main Ext. Clearing Payment
l Key Transaction Subtransactio Transactio Subtransacti Restriction Lock
for Statistical n for n for on for Reason
Request Statistical Payment Payment
Request
A 1053 0120 1053 0010 R
6. Maintain a document type for the external main transaction for the payment scheme. In this case for
main transaction 1053. Youdo this in positng area R300 in Customizing for Financial Accounting
under Contract Accounts Receivable and Payable → Basic Functions → Postings and Documents
→ Document → Maintain Document Assignments → Document Types → Maintain Default
Document Types for Budget Billing. If you do not do this, you cannot create any statistical payment
scheme requests.
Page 38 of 58
10. Events for Payment Schemes
The are many events available for the budget billing procedure Payment Scheme. You can use them to
define your own checks and influence processes related to the payment scheme. You can find and edit
these events in the Management of Events transaction (FQEVENTS).
To define an event individually, proceed as follows:
...
1. Copy the sample function module provided by SAP for the event in question.
All events provided by SAP follow the naming convention
ISU_SAMPLE_<Number of Event>.
If a function module is available for this event as standard, it is mentioned in the documentation for
the sample function module. Your function module always overrides the standard.
2. Enter the necessary coding in your function module.
3. In table Installation-Specific Function Modules (TFKFBC), create a new entry with the following
values:
Application Area: R
- Event: <Number of Event>
- No.: Sequence number starting with 0
- Active Module: Name of copied function module
In order to avoid inconsistencies in the system, you cannot use the following language elements in the
events:
• COMMIT WORK
• ROLLBACK WORK
• CALL FUNCTION 'DEQUEUE ALL’
• Deletion of locks that you did not set yourself
Before you create an event with its own program logic, read the documentation for the sample function
module. This contains important information on parameters and possible standards for the event.
Page 41 of 58
For a periodic bill, the sample line that is valid on the adjustment date is prorated. This is because a
new bill amount is used in the new billing period. As a result, the consumption bill portion of the total
amount always changes, even if the total amount is not adjusted due to limits not being reached or
being exceeded.
The extrapolation portion of the payment scheme amount is determined using the same method as
for adjustment for the interim bill. However, the bill portion is also added to the resulting amount.
This portion is determined from the bill amount transferred to the new billing period. The amount is
divided by the number of remaining due dates.
In addition to the payment scheme amount, the fields BETRWBILLTOT and BETRWBILLACT are
also updated in the new sample line. The system enters the bill amount transferred to the new
billing period in both of these fields. If sample lines that are not yet valid exist for a payment
scheme, the are also adjusted. Proration is not necessary.
All newly created, prorated, and changed sample lines are stored temporarily in an internal table.
This table has the same structure as described above. However, the POTYP field contains the
following indicators:
Newly Created Lines
RC: Line created during adjustment
MC: Line needs to be adjusted, as the bill portion of the due amount is higher than the
previous total due amount. This is a result of the consumption bill that was transferred to the
billing period. However, it was specified in the corresponding sample line that this due date
should not be adjusted for adjustment for interim/periodic bills. Therefore, the total amount is
increased to the amount of the bill portion so that at least the bill amount is cleared with this
sample line.
Changed Lines
RU: Line changed during adjustment
MU: Same meaning as MC
Before event R514 is called, all entries from EABPLS_CRT and EABPLS_CHG are copied to
structure EABPLS_ADJ for each payment scheme. This is because you only make changes to this
structure in event R514. Also read the documentation for event R514.
All lines that are not adjusted as a result of the checks executed in event R514 remain unchanged
in that the total amount of the payment scheme due date does not change. However, it is possible
that the bill portion of this amount is adjusted.
For lines that are not adjusted and that have a bill portion of the total amount that is higher than the
total amount itself, the bill portion amount is changed to the same as the total amount.
This means that these lines no longer have an extrapolation portion.
• The contents of the internal table are copied to transfer parameter YT_PS_ADJUST.
If you want to define your own program logic for event R512, see the documentation for function module
Adjust Payment Scheme for Periodic/Interim Billing (ISU_ADJUST_PAYMENTSCHEME_R513), which
describes the individual transfer parameters in detail.
Page 42 of 58
Bill, 02 = Interim Bill), currency, payment frequency, and payment scheme category, the new sample line
amount is accepted.
The check takes place for the payment scheme lines in transfer parameter XYT_PS_ADJUST-
EABPLS_ADJ that were transferred to the event. The following comparisons are made depending on the
values in field EABPLS_ADJ-POTYP:
• POTYP = "RC" or "MC": A new sample line
The amount is compared with the direct predecessor. It is determined using the end date, which is
one day before the start date of the new sample line. MC means that the sample line is new and
that it was created during creation of a periodic bill. This line needs to be adjusted, as the bill portion
of the due amount is higher than the previous total due amount. This is a result of the consumption
bill that was transferred to the billing period. However, it was specified in the corresponding sample
line that this due date should not be adjusted for adjustment for interim/periodic bills. Therefore, the
total amount was increased to the amount of the bill portion so that at least the bill amount is
cleared with this sample line. These lines are treated as adjustment lines as standard. You can
however define your own program logic so that these lines are handled differently.
• POTYP = "RU" or "MU": An updated sample line
The amount of the changed sample line is compared with the amount before the change took place.
You can find the amount before the change in table EABPLS_DB. The system checks the new and
adjusted sample lines to determine whether the change lies within the percentage limits defined in
table TE558. If it does lie within these limits, the system then checks the amount limits. In lines for
which these checks are unsuccessful, the field EABPLS_ADJ-POTYP is reset to its initial value.
If you defined event R513 yourself, but you do not want to make any changes in event R514, you must
take this processing logic into account in your programming.
Before you define your own program logic for event R514, read the documentation for function module
Amount/Percentage Limits for Payment Scheme Adjustment (ISU_CHECK_PS_ADJUST_R514).
Page 43 of 58
10.8. Activate Payment Scheme (R517)
In event R517, you can define your own checks that are executed when an inactive payment scheme is
activated.
The standard logic for this event is defined in function module Activate Payment Scheme
(ISU_SAMPLE_R517) and does not carry out checks but allows unrestricted activation. Note that for
mandatory groups, it is only possible to activate all inactive payment schemes in the group. It is not
possible to activate individual payment schemes.
Page 44 of 58
days before or after the end of the period. If a payment scheme has a quarterly payment frequency, this
limit is 30 days. For a monthly payment frequency the limit is 16 days.
Page 45 of 58
10.18. Customer-Specific Rules for Amount Rounding in the
Payment Scheme (R527)
In event R527, you can define your own rules for rounding amounts in payment schemes.
In the standard logic for this event, which is defined in function module Rules for Amount Rounding in the
Payment Scheme (ISU_PS_ROUND_AMOUNT_R527), the payment scheme amount is rounded
according to the settings in table Budget Billing, Rounding Parameters (TE211).
Page 46 of 58
If you want to use event R530, you have to define your own check logic.
Page 48 of 58
11. BOR Object PAYSCHEME
The BOR object PAYSCHEME was created for processing payment schemes within workflows or external
processes.
The object can uniquely identify the following key fields:
• PaymentScheme.BudgetBillingPlan – PaymentScheme
• PaymentScheme.Contract - Contract
Method Description
Find Find object
ExistenceCheck Existence of object
Create Payment scheme: Create
Display Payment scheme: Display
Edit Payment scheme: Change
Terminate Payment scheme: End
Activate Payment scheme: Activate
SampleLineChange Payment scheme: Change sample lines
BasicDataChange Payment scheme: Change basic data
OpenItemRollinOut Payment scheme: Include open items
SingleLineValidation Payment scheme: Validate change to sample line
CompleteReassesValidation Payment scheme: Validate payment scheme adjustment
Page 49 of 58
BasicDataChange, OpenItemRollinOut, SingleLineValidation and CompleteReassessValidation methods
within a background process.
The Activate method activates a specified payment scheme on a particular payment date.
You can use the SampleLineChange method to change the amount due and the change status of a single
sample line as of a certain time (until the end of the line).
The BasicDataChange method changes the basic data (payment date, payment frequency and payment
scheme category) for a payment scheme, as of a certain date. A change of this type affects both the
whole mandatory group of the selected payment scheme, and all sample lines as of the selected change
date.
You can use OpenItemRollinOut to select qualified, open receivable items or credit items, and to distribute
these over the open due dates for the current period.
The SingleLineValidation and CompleteReassessValidation methods control the changes made. You can
use SingleLineValidation to check whether the change to an amount for a single sample line lies within the
predefined limit values. The CompleteReassesValidation method executes these checks for a complete
payment scheme, with all its sample lines. You can use tables TE558 or TE560 to determine the permitted
limit values.
The following events are available for the PayScheme BOR object:
• PaymentScheme.CREATED Payment scheme created
• PaymentScheme.CHANGED Payment scheme changed
• PaymentScheme.TERMINATED Payment scheme ended
• PaymentScheme.ACTIVATED Payment scheme was activated
• PaymentScheme.REASSESSFAILED Amount limits were not adhered to during adjustment
Page 50 of 58
12. Migrating Payment Schemes
You use the IS Migration Workbench (EMIGALL) transaction with the BBP_PAYSC migration object to
migrate payment schemes.
To migrate payment schemes into the IS-U system, you require a complete, billable customer construct for
each payment scheme. Prerequisite for this is the successful import of at least the following migration
objects (flat-rate installations without meters):
• Migration object PARTNER: Business partner
• Migration object ACCOUNT: Contract account
• Migration object MOVE_IN: Move-in / contract
• Migration object INSTLN: Installation
• Migration object PREMISE: Premise
• Migration object CONNOBJ: Connection object
You must also import the following migration objects for measured contracts (installations with metering
devices):
• Migration object DEVLOC: Device location
• Migration object INSTALL: Device installation
• Migration object DEVICE: Device
When migrating payment schemes, all contracts from a mandatory group (contracts for a contract account
with the indicator Joint Invoicing = 1) must be transferred together to the migration object. If this is not the
case, we cannot guarantee an error-free migration of payment schemes.
You must transfer the data listed in the tables to the corresponding structures of the migration object.
The header data here is the EABP structure, for which the fields to be transferred are listed in the
following table:
Field Name Explanation Mandatory Optional
GPART Business partner number X
VKONTO Contract account number X
BEGPERIODE Start of payment scheme period X
KZABSVER Budget billing procedure X
(if not maintained, then determined from
contract account)
PSSTATUS Status of payment scheme X
(can also be empty if active)
VERTRAG Contract X
WAERS Currency X
ENDPERIODE End of payment scheme period X
(if empty, then the value 31.12.9999 is
entered)
In the EABPLS structure, the individual data from the payment scheme sample lines is transferred to
the BBP_PAYSC migration object. You must enter at least one data record for each contract in the
structure. If you want to transfer data for more than one sample line, you must ensure that the start
date and end date for the sample lines must follow one another directly.
Page 51 of 58
Example
• Sample line 1
BEGDAT 01.01.2001
ENDDAT 31.01.2001
• Sample line 2
BEGDAT 01.01.2002
ENDDAT 31.12.9999
The following table gives you an overview of the individual fields, which you must maintain for the
sample lines:
Table 12.2: Data to be Migrated from Sample Lines for a Payment Scheme
Page 52 of 58
13. Archiving and Deleting Payment Schemes
You cannot delete a payment scheme. The only exception is a special case when ending a payment
scheme. This case is explained in greater detail in the section Ending a Payment Scheme.
Therefore, to remove a payment scheme from the database, you must archive it.
Payment scheme data is saved in the following tables:
You use the FI-CA archiving object FI_MKKDOC to archive payment scheme requests. The event
Document Archiving: Check Header Data (0500) ensures that a minimum retention period of 6 months is
adhered to. This guarantees that it is possible to reverse the corresponding payment document in a
certain period.
The IS-U object data is archived using the IS-U archiving object for budget billing plans (ISU_BBP),
according to the rules implemented there. This is explained in greater detail in the Archiving section.
You use the Archive Administration transaction (SARA) to execute archiving. You can use transaction
ESARA04 to call this transaction directly for the ISU_BBP archiving object.
You can find the archiving of budget billing plans in the area menu for the utilities industry, under Tools →
Data Archiving → Invoicing.
13.1. Archiving
Budget billing plan archiving consists of the following steps:
...
1. Analysis Run
The following figure, and the accompanying explanations, describe the process flow of the analysis
run.
Page 53 of 58
1
Selection of header data for
deactivated payment schemes
(CPS) EABP
Is associated 2
nein header data
from the print
document
archived?
3
CPS Yes
deactivated Yes
by account
maintenance
?
No Save CPS
number for
EABPARCH
subsequent
archiving
Yes
No End of
selection?
Yes
Log output
4
No Autom. start
of archiving program?
Yes
End analysis run
Page 54 of 58
c. CPS deactivated by account maintenance
You can also deactivate a payment scheme by executing an automatic account maintenance
when stopping the payment scheme. In this case, you can archive the payment scheme
immediately, as it is no longer possible to use a cancellation to reactivate the payment
scheme.
d. Automatic start of archiving run
When starting the analysis run, you can determine whether the archiving run is to be started
immediately after the analysis run. You determine this in the selection screen for the
corresponding program. When using the SARA transaction to schedule the corresponding
job you must proceed as follows:
When creating the variant of the analysis program, set the indicator Start Archiving
Automatically in the selection screen of the analysis program.
Create a variant for the archiving program with the same name as for the analysis
program.
Caution: You must define the same selection conditions for document number and
contract account for both variants.
Schedule the job for the archiving program with the start date After Event.
Enter “SAP_ISU_ARC_BBP_ANALYSE_END” as the event. The event parameter is
the variant name, with which the corresponding analysis program is started.
Caution: Write the variant name in upper case.
2. Archiving
The following process flow diagram displays the process flow for the archiving run:
EABP
Select payment scheme data EABPL
EABPLREQ
no End of
selection?
yes
3
no Autom. start of
delete prog.
selected?
Write protocol
End of
archiving run
Page 55 of 58
Figure 13.2: Payment Scheme Archiving – Archiving Run
Caution
Only use the Reload function if an archiving run / deletion run has been executed with the wrong
parameters, thus meaning that incorrect data has been archived / deleted. Under no circumstances
should the Reload function be a component of a business process.
Page 56 of 58
You can also use transaction EA63PS to display archived payment schemes:
• In the initial screen for the transaction, you can use Budget Billing Plan from Archive to go to the
selection screen of the archive information structure for the ISU_BBP archiving object.
The information structure SAP_ISU_BBP is delivered as default for the ISU_BBP archiving object.
• You can enter the desired selection parameters, such as the contract account, in the selection
screen.
• The system displays a list with all payment schemes that correspond to the selection criteria and
exist in the information structure. Double-click on a payment scheme to display this payment
scheme in transaction EA63PS.
Caution
To use transaction EA63PS, the following conditions must have been met:
• The archiving development kit (ADK) must have access to the appropriate archive files.
• At least one information structure must be active for the SAP_ISU_BBP catalog supplied by SAP.
The SAP_ISU_BBP structure is delivered as default. You can activate this structure in Customizing
for SAP Utilities, under Tools → Archiving → Activate Info Structures for Archiving.
Page 57 of 58
14. Appendix
14.1. Relevant Transactions
EA61PS Create payment scheme
EA62PS Change payment scheme
EA63PS Display payment scheme
E61PSD End payment scheme
EA65PS Create payment scheme requests
EA66PS Mass activity for creating payment scheme requests
Page 58 of 58