Cookbook Payment Scheme e

Cookbook
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 following scenarios exist for mandatory contracts:

...
• 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.
3.2.1. Including Open Items in the Payment Scheme

If open items exist for a contract, you can select them to be transferred to the payment scheme. You will
receive a list of all items that have not yet been cleared or that have only been partially cleared, and that
are allocated to the relevant contract. In event Selection of Open Items When Creating a Payment
Scheme (R515), you can exclude certain items from being transferred to a payment scheme.
The items selected for a payment scheme are first checked in event Deactivate Selection of Open Items
(R528). If you selected this setting previously, the system can check the selection of open items again in
this event. This allows you to ensure that the total sum of all the items transferred to the payment scheme
does not exceed a certain limit, for example.
You can only transfer items to a payment scheme if they are allocated to the contract, for which the
payment scheme is being created. It is not possible to select items that are only allocated to the contract
account.
3.2.2. Determining Amounts for the Payment Scheme

The system determines the following periods based on the creation date:
• Current periodic billing period
• Extrapolation period (period for which extrapolation takes place to determine the payment scheme
amount).
The extrapolation period is determined in event Determine Extrapolation Period for Payment
Scheme (R510). In the standard logic provided by SAP, the start date of the extrapolation period
is either set to the start date of the current periodic billing period, or to the move-in date if this lies
within the current billing period. The end date is the same as the end date of the current billing
period.
The system uses this data to carry out extrapolation for the contract. The extrapolation result is evaluated
in event Determination of Payment Scheme Sample Lines from Billing Document (R511). In the standard
logic provided by SAP, the net amounts of all extrapolation document lines that are relevant to budget
billing and posting are added together for each contract. If these lines have different debit subtransactions,
the system uses the first subtransaction it finds as the valid transaction for all further processing. A
message will inform you of this. The same procedure applies if the lines have different tax determination
codes. If individual extrapolation lines have a credit subtransaction, the extrapolation amount is reduced. A
special sample line is not created.
The system uses the data from event R511 to create a payment scheme sample line in event Determine
Budget Billing Amount for Payment Scheme (R512). In the standard logic provided by SAP for this event,
the system first determines the payment scheme amount for each due date item. The extrapolation
amount determined in event R511 and the amount from the open items that was transferred to the
payment scheme are added together. This sum is divided by the number of payment scheme requests
remaining in the billing period. The number of payment scheme requests depends on the start date of the
payment scheme, the payment frequency, and the end of date of the billing period.
For customers that pay by direct debit or standing order, the system checks the standard logic of the event
to ensure that the number of days between the creation date and the first due date of a payment scheme
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.
3.2.3. The Structure of a Payment Scheme

In figure 3.1. Sequence of Events During Creation of a Payment Scheme, you can find an overview of all
the events that are executed when a payment scheme is created. You do not need to change any of the
events listed. The fact that there are many events gives you the option to access the creation process at
various different points if the standard logic is not adequate.
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
Figure 3.1: Sequence of Events During Creation of a Payment Scheme
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:
Direct Changes in a Sample Line*

Start Date The change in the sample line is effective as of this date.
Amount In this field, enter a new payment scheme amount to be valid as of the start date of
the change. This is a gross amount. The tax amount is calculated from this gross
amount and the tax determination code when the payment scheme requests are
created.
The amount cannot be lower than the amount required to clear the items
transferred to the payment scheme. Also, the amount cannot be a negative value.
In table Percentage Limits for Manual Payment Scheme Changes (TE560), you can
define upper and lower limits (percentage and absolute) for the permitted manual
changes to the amount. The agent is informed if the lower limit is not reached or if
the upper limit is exceeded. However, the agent has the option to ignore the
message. In this case, the system executes event Amount Limit Warning Ignored
(R526), in which you can react to this unexpected amount change by starting a
workflow, for example. You can only prevent the change from being transferred by
completely stopping the transaction.
Changability Status In this field, you define whether to adjust sample lines when an interim or a periodic
bill is created. You can enter the following values:
„ „: Adjust for Interim and Periodic Bills
01: Do Not Adjust for Interim and Periodic Bills
02: Do Not Adjust for Interim Bill
Changes Using Pushbuttons
Basic Data The basic data of a payment scheme comprises all data that has to be
changed at the same time within a mandatory group for all payment schemes.
If the basic data in a payment scheme is changed, all payment schemes in the
same mandatory group are adjusted automatically.
You make the changes in the sample lines of the payment scheme. If an
active sample line is changed, it is prorated and a new line is created with the
new basic data.
Basic data includes the following:
Change Effective From: This is the date as of when the change to the basic
data takes effect.
The system chooses the earliest possible date based on the system date. The
system ensures that no paid payment scheme requests exist after the change
date.
Payment day
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:
Field Name Description

Start Date Defines as of when a sample line is valid.
End Date Defines until when a sample line is valid. As long as a payment scheme is not
cancelled or deactivated, there is always a sample line with the end date
31.12.9999.
Amount The gross amount that the customer has to pay.
Currency
Payment Frequency In this field, you enter how frequently the customer has to make payments.
You can choose the following frequencies:
W – Weekly
F - Fortnightly
M – Monthly
Q – Quarterly
Y - Yearly
Change Status Determines whether or not the sample lines are adjusted when an interim or
periodic bill is created.
„ „ – Adjust for Interim and Periodic Bills
01 – Do Not Adjust for Interim and Periodic Bills
02 – Do Not Adjust for Interim Bill
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. All subsequent due dates are
determined based on this date and the payment frequency.
For weekly and fortnightly payment frequencies, this date is the day of the
week on which the payments are to be made. Saturdays and Sundays cannot
be used as payment days. For monthly, quarterly, and yearly payment
frequencies, this field is used directly to define the date on which payment is to
be made.
Status of Sample Line „ „ – Active
01 – Adjusted During Periodic Bill
02 – Adjusted During Interim Bill
03 – Inactive
04 – Print Document Reversed
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.
6.1. Adjusting a Payment Scheme During Creation of an

Interim Bill
The system can automatically adjust a payment scheme during creation of an interim bill (Meter Reading
Reason 02 – Interim Meter Reading with Billing). When you create the meter reading order, you must
specify that the budget billing amount is to be adjusted. Alternatively, you can specify this when defining
interim meter readings in the meter reading unit. In both cases, the system executes a budget billing
extrapolation, which is used as the basis for adjusting the payment scheme amount. The extrapolation
period is either identical to that of the most recent periodic bill, or it is the same as the extrapolation period
that was used when the payment scheme was created.
The system can adjust the extrapolation portion of sample lines from a payment scheme in a number of
dífferent ways. In all cases, seasonal weighting factors are taken into account in billing. You can, however,
influence to what extent the underconsumption or excess consumption within the interim billing period is
taken into account when the adjustments are made. You do this in table Define Control Parameters for
Payment Scheme (TE558).
Depending on the length of the period between the end of the interim billing period and the planned end of
the periodic billing period, one of three three recovery rates is used. These recovery rates allow you to
specify to what extent the excess consumption or underconsumption determined during interim billing is
taken into account when adjusting the extrapolation portion of the payment scheme sample lines. The
following period lengths can be used with the recovery rates. The due date percentages are not freely
configurable values.
...
• Recovery rate for a long remaining period

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 for a medium remaining period
You use this recovery rate if more than 37.5 percent and not 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.
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
During creation of the interim billing document, extrapolation is executed for the period January 1st to
st
scheme.
New payment scheme amount: 15 + (450/ 6) = 90
Example 3
st
st
scheme.
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.
• 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.
• 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.
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.
• 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.
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
st
December 31 . The result of this is €900.
No additional items should now be added to the payment scheme.
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.
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
st
st
• 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.
Page 23 of 58
Example 2
st
st
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.
• 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
st st
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.
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
• 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
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
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.
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.
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.
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
st st
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.
A
E = €687.50
B
E = €62.50
• The extrapolation amount still to be divided is €62.50
6.2. Adjusting a Payment Scheme During Creation of a

Periodic Bill
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.
6.3. Amount/Percentage Limit Check for Payment Scheme

Adjustment
Once a payment scheme has been adjusted, the system carries out an amount/percentage limit check of
the changed payment scheme sample lines before the changes are written to the database.
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.
7. Generating Statistical Payment Scheme Requests

In the Utilities Industry menu under Invoicing → Budget Billing Plan → Payment Scheme → Create
Payment Scheme Request (transaction EA65PS) you start a program to create the necessary statistical
requests in contract accounting for payment schemes. Without these requests, the payments of a cash
payer cannot be allocated to a payment scheme. Also the relevant amounts cannot be collected from
customers who pay by direct debit.
You can make the following entries in transaction EA65PS:
• Contract Account (From/To): In this field you enter the contract account area for the payment
schemes for which you want to create the statistical requests. If you do not make any entries,
statistical requests are created for the payment schemes of all contract accounts.
• Create Before: In this field you enter the date before which you want the requests to be created.
The due date is used as the comparison date of the request without taking the factory calendar into
account.
• Runtime Restriction (End Date, End Time, Check Runtime):
You can use these fields to restrict the runtime for transaction EA65PS. The program then ends
when the end date and end time is reached, regardless of whether there are still contract accounts
to be processed.
Transaction EA65PS is used to create statistical requests for each payment scheme that belongs to one
of the selected contract accounts and that meets the following conditions:
• The payment scheme must be active at the time of selection.
• When the selection is made the end date of the payment scheme must come after the system date.
• The payment scheme must have the status Active and not the status Inactive.
• On the selection date, the payment scheme must have at least one sample line with an end date
that comes after the selection date. The sample line must be active and also have at least one due
date within the validity period.
If a payment scheme meets these conditions, a statistical FI-CA document is created, containing a
separate open item for each due date.
The type of the document is determined from posting area R300 (Maintain Settings for Budget Billing
Plan). The source of the document is RO (IS-U PS Request).
The individual open items of the document are formed based on the valid payment scheme sample lines
for each due date. The start date for creating the sample lines is always the same as the system date. The
system checks whether requests for the payment schemes already exist after this date. The start date is
changed if necessary.
The following section describes the most important fields and how the field values are determined for an
open item:
• Due Date
The due date is determined from the first due date and the payment frequency. You define the first
due date in the sample lines for which you create the requests. If a different first payment date is
defined in the sample line, this date is used.
Page 28 of 58
If you have defined a correction for non-working days using the factory calendar in the period
characteristics of the portion master data for the contract, this is taken into account when the due
date is determined.
If the due date (not using the factory calendar) lies after the Create Before date, processing of the
payment scheme is terminated and no open item is created for this due date.
• Business Partner, Contract Account, Contract, Main Transaction, Subtransaction, Currency:
This data is copied from the sample lines to the open items.
• General Ledger Account
The general ledger account is determined dynamically from posting area R007 during runtime.
• Amount and Tax Amount
The amount of the open item is copied from the relevant sample line. Since this is a gross amount,
the tax amount is calculated based on the tax determination code taken from the extrapolation
document and defined in the sample line during creation of the statistical request. Any tax changes
that occur between the creation of the payment scheme or creation of the last periodic/interval bill
and the creation of the statistical payment scheme requests are taken into account. However, the
gross amount remains unchanged.
There is also a mass activity for creating payment scheme requests. You can find this in the Utilities
Industry menu under Invoicing → Budget Billing Plan → Payment Scheme → Create Mass Activities for
Payment Scheme Requests (transaction EA66PS).
If certain settings are made in the Payment Scheme Category table (TE638), you cannot use EA65PS or
EA66PS to create statistical requests for certain payment schemes. For these payment schemes, the
requests are created automatically when the periodic/interval bill is created.
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. .
9.1.1. Budget Billing Procedure

Before you can use the budget billing procedure Payment Scheme in a company code group, you have to
define which budget billing procedures are permitted in which company code groups. You do this in
Customizing for SAP Utilities under Invoicing → Budget Billing Plan → Basic Settings. You must enter
budget billing procedure 4 (Payment Scheme) in at least one company code group.
9.1.2. Define Control Parameters for Payment Scheme

Defining the control parameters for the payment scheme (table TE637) is split into the following sections:
• General Control Parameters
Minimum number of days between creation date and due date (Min. No. Days):
In this field, you enter the minimum number of days that must come between the
creation/change date of a payment scheme and the first due date if the customer pays by
direct debit or standing order.
If the number of days is less than this number, the first due date of the payment scheme is
postponed accordingly.
Take Factory Calendar into Account for Advance Notice (Incl. FactCaldr):
If you set this indicator, the system checks whether the date (creation/change date plus Min.
No. Days) falls on a working day according to the settings in the factory calendar. If it does
not, the date is moved according to the settings you made in the Correct Non-Work Day
(Correct non-WD) field. The next due date is checked using this new date.
Correct non-WD: See Incl. FactCaldr.
Minimum Number of Days between Creation Date and Next Bill Daate (Min.No.DaysBill):
In this field, you enter the minimum number of days that must come between the start date of
a payment scheme and the next planned billing date for the corresponding contract. If the
number of days is less than the number entered here, you cannot create the payment
scheme.
Do Not Round:
If you set this indicator, the event Amount Rounding in Payment Scheme (R527) is not
called.
• Adjust Payment Scheme
In this area you determine what share of an interim bill with budget billing adjustment is divided
amongst the due dates remaining until the next periodic bill. This applies to receivables as well as to
credit items. You can choose one of various settings depending on the amount of time until the next
planned periodic billing date. The following periods exist:
Recovery Rate (Long Remaining Period) Rec.Rate (L):
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.
9.1.3. Payment Scheme Category

Under Define Payment Scheme Category, you can define your own payment scheme categories (table
TE638) and assign them values in the following fields:
• Generate Requests Before Next Invoicing Run (Req. Inv.):
If you set this indicator, all statistical request lines with a due date that comes after the current date
and before the date of the next planned interim or periodic billing are generated when an interim or
periodic billing is invoiced.
If the payment scheme was adjusted during interim or periodic invoicing, the request lines are
created with the new payment scheme amount. If the adjustment cannot be made as a result of the
amount limit checks, the system creates the request lines with the old payment scheme amount.
• Do Not Generate Requests Online (NoReq.Onl.):
If you set this indicator, you cannot create statistical request lines using transaction EA65PS and
EA66PS. You must always create the request lines during invoicing. You can only set this indicator
if you also set the Req. Inv. Indicator.
If you set this indicator, you can only make restricted changes to the payment schemes allocated to
this payment scheme category. You can only make changes to the payment scheme sample lines
after the earliest due date of the statistical payment scheme requests that were generated in
invoicing. If you want to make the change immediately, you must first reverse the invoicing
document for which the request lines were created.
• Payment Scheme Category Cannot Be Changed (No PSCatCh):
If you set this indicator, you can no longer change the payment scheme category to which a
payment scheme is allocated.
• Adjust Due Date (Adj.DDate):
You can only set this indicator if you have also set the indicator for creating the statistical requests
in invoicing.
If the indicator is set, the due dates of all statistical requests that were created during invoicing and
that have due dates before that of the bill created in invoicing are changed to the same due date as
the bill.
• No Adjustment During Interim Billing (NoAdjustmt):
If you set this indicator, none of the payment scheme sample lines allocated to this payment
scheme category are adjusted when an interim bill is invoiced. This applies regardless of the
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.
9.1.4. Define Deactivation Reason
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.
9.1.5. Number Ranges and Payment Schemes
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.
9.1.6. Rounding Parameters
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
9.1.7. Define Amount/Percentage Limits for Automatic Payment

Scheme Adjustment
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:
...
• Minimum Percentage Limit for Amount Increase

• Maximum Percentage Limit for Amount Increase
• Minimum Percentage Limit for Amount Decrease
• Maximum Percentage Limit for Amount Decrease
• Minimum Amount Limit for Amount Increase
• Maximum Amount Limit for Amount Increase
• Minimum Amount Limit for Amount Decrease
• Maximum Amount Limit for Amount Decrease
In the standard logic for event Check Amount/Percentage Limits for Automatic Payment Scheme
Adjustment (R514), the minimum percentage and amount limits must be exceeded and the maximum
limits must not be exceeded when a payment scheme amount is increased or decreased.
9.1.8. Amount/Percentage Limits for Manual Payment Scheme

Adjustment
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).
9.1.9. Customizing for Invoicing

Make the following settings in Customizing for Invoicing:
Basic Settings
• → Define Basic Settings for Invoicing
Under Time of Tax Determination choose Tax Determination in Billing.
• → Define Basic Settings for Reversal
Set the Document Sort Order Check During Invoicing Reversal flag.
9.2. Customizing in FI-CA

Customizing in FI-CA is split into several steps, which are described in detail in this section.
...
1. Define External Main Transactions and Subtransactions

In the first step you define the main transactions and the subtransactions fot the payment scheme.
Page 35 of 58
The tables FI-CA Main Transactions and FI-CA Subtransactions are available for this purpose. You
can find these tables in Customizing for Financial Accounting under Contract Accounts Receivable
and Payable → Basic Functions → Postings and Documents → Document → Maintain Document
Assignments → Maintain Main Transactions or Maintain Subtransactions.
Example
Ext. Main Description Comment
Transaction
1053 Budget billing procedure: This main transaction is used to create the
payment scheme payment scheme requests and the corresponding
payments.
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.2: Example of Defining External Subtransactions for Payment Schemes
2. Allocate external transactions to internal transactions

Before you can use the external main transactions and sub transactions defined in step 1, you have
to allocate them to the internal transactions defined by SAP. To do this, choose the following in
Customizing: Financial Accounting → Contract Accounting → Basic Functions → Postings and
Documents → Document → Maintain Document Assignments → Maintain Transactions for IS-U →
Maintain Transactions for Budget Billing.
Example
Internal Transactions External Transactions
MTran. STran. Description MTran. STran. Description
0053 Budget Billing: Payment 1053 Budget Billing Procedure: Payment
Scheme Scheme
0010 Budget Billing Payment 0010 Budget Billing Payment
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)
4. Accounts for received budget billing amounts

You maintain the accounts for received budget billing amounts in posting area R007 using
transaction FQC0 or in Customizing for Financial Accounting under Contract Accounts Receivable
and Payable → Basic Functions → Postings and Documents → Document → Maintain Account
Assignments for Automatic Postings → Automatic G/L Account Determination → Define Accounts
for Budget Billing Down Payments.
These accounts are entered as G/L accounts during creation of the payment scheme requests
(transactions EA65PS and EA66PS).
You do not have to make any entries for credit subtransactions as the payment scheme does not
support these subtransactions.
Example
Company Divisio Account Ext. Main Ext. Account
Code n Determination ID Transaction Subtransacti Number
on
0001 01 01 1053 0110 0000170060
Table 9.6: Example of Account Assignments in Posting Area R007

Page 37 of 58
5. Allocate payments to payment scheme requests
You allocate payment scheme payments to statisitcal payment scheme requests in posting area
R007 using transaction FQC0 or in Customizing for Financial Accounting under Contract Accounts
Receivable and Payable → Basic Functions → Posting and Documents → Define Account
Assignments for Automatic Postings → Define Account Assignments for Down Payments and
Charges.
For each budget billing request transaction, define a corresponding payment transaction and the
clearing restriction R (items relevant for payment scheme).
You only have to create entries for debit subtransactions as the payment scheme does not support
credit subtransactions.
As the payment scheme standard also only supports debit subtransactions, the table should only
contain one entry that is relevant to the payment scheme.
Set the statistical key to “A” and the clearing restriciton to “R”.
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
Table 9.7: Example of Payment Allocation in Posting Area 1010
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.
10.1. Determining the Extrapolation Period for the Payment

Scheme (R510)
You use event R510 to determine the start and end date of the extrapolation period for creating the
payment scheme.
The system uses parameter X_OBJ-EP_PERIOD to determine the process from which the budget billing
extrapolation is called:
• M – Manual creation of payment scheme(EA61PS)
• E – Move-in
The standard function module for this event is Determine Extrapolation Period for Payment Scheme
(ISU_GET_EXTRAPOLAT_PERIOD_R510). In this function module, the start date is always set to the
start date of the billing period for which the payment scheme is created.
Exception: If the move-in date comes after the start date of the billing period. In this case, the start date of
the extrapolation period is set to the same as the move-in date.
The end date of the extrapolation period is always the same as the end date of the billing period.
If you define your own extrapolation period in this event, it does not have any effect on the billing period.
This means that if you change the extrapolation period to a full year, for example, the resulting amount is
still only divided amongst the payment scheme requests remaining in the current billing period.
Page 39 of 58
10.2. Determine Payment Scheme Lines from Billing
Document (R511)
In event R511, the payment scheme amount is determined from the extrapolation document for billing. In
function module Determine Payment Scheme Lines from Billing Document
(ISU_DETERMINE_BILL_AMOUNT_R511) the event has the following program logic:
For each contract, the net amounts of all extrapolation document lines relevant to budget billing or posting
are added together to create one value. If these lines have different debit subtransactions, the system
uses the first subtransaction it finds as the valid subtransaction for all further processing. A warning
message will inform you of this.
The same procedure applies if the lines have different tax determination codes. If a line has a credit
subtransaction, the net amount of the line is subtracted from the total budget billing amount. A special
sample line is not created.
If you want to override the standard way of determining the payment scheme sample lines, you can use
the following data:
• X_OBJ: Data for payment scheme and various check parameters
• X_BILL_DOC: Extrapolation document
• X_EVER: Data for the contract, for which the amount is to be determined
In return parameter YT_AMOUNT, enter the amounts for each subtransaction and tax determination code
for which the sample lines are to be created in the payment scheme. If you want to use multiple
subtransactions for each contract, you have to adjust events Determine Budget Billing Amount for
Payment Schemes (R512) and Adjust Payment Schemes for Periodic/Interim Billing (R513) accordingly.
Always contact SAP before you do this.
10.3. Determine Budget Billing Amount for Payment Schemes

(R512)
In this event, the new sample lines are created and the amount determined in event R511 is copied to
these lines when a new payment scheme is created.
The standars function module (ISU_GET_PAYSCHEME_AMOUNT_R512) for this event has the following
program logic:
• The payment scheme amount is determined for every item. The sum is determined from the bill
amount transferred to the payment scheme and the extrapolation amount determined for the billing
period. This sum is divided by the number of items remaining for the billing period.
• For customers that pay by direct debit or standing order, the event checks whether the number of
days between the creation/change date and the first due date of a payment scheme request is at
least as high as the number of days predefined in Customizing. If the number is lower, an
alternative first payment date is determined and returned to the program.
• If you have created more than one amount line per contract in event Determine Payment Scheme
Lines from Billing Document (R511), the bill amount transferred to the payment scheme is only
transferred to the first amount line.
If you want to define your own program logic for event R512, read the documentation for function module
Determine Budget Billing Amount for Payment Scheme (ISU_GET_PAYSCHEME_AMOUNT_R512),
which describes the individual transfer parameters in detail.
10.4. Adjust Payment Scheme for Periodic/Interim Bill (R513)

Page 40 of 58
In this event, the payment scheme is adjusted during creation of a periodic or interim bill. The event is
called during the invoicing run:
• For each optional contract - Individually
• For each mandatory contract – For all payment schemes together
If you have defined event Determine Payment Scheme Sample Lines from Billing Document (R511) so
that more than one active sample line can be created for each payment scheme, you have to adjust event
R513 accordingly as the flow logic is based on the assumption that only one active sampleline exists.
The standard function module for this event is Adjust Payment Scheme for Periodic/Interim Billing
(ISU_ADJUST_PAYMENTSCHEME_R513). The following processing steps are carried out:
• Joint processing for adjustments during interim and periodic billing
The date on which the adjustment to the payment scheme sample line is to take place is transferred
to the event. The transfer parameter is X_CHG_DATE. If the customer, for whom the payment
schemes are being adjusted pays by direct debit or standing order, the minimum number of days
defined in Customizing must come between the adjustment date and the next payment date. If the
number of days is lower than this number, the payment scheme is adjustment on the day after the
payment date. No such check is made if the customer pays by cash.
• Adjustment for interim bill
First the system checks whether the payment scheme needs to be adjusted.
If the interim billing is scheduled, set the corresponding indicator in the meter reading unit. If it is not
scheduled, specify this when you create the meter reading order.
The sample line that is valid on the adjustment date is prorated. This means that its end date is the
same as the adjustment date plus one day.
A new sample line is created with a start date that is the same as the adjustment date. The
extrapolation portion of the new sample line amount is adjusted according to the new extrapolation
amount determined in billing. If payments were made for due dates in the extrapolation period using
the old payment scheme amount, this is taken into account when determining the new amount. The
system subtracts the sum of the paid due dates from the extrapolation amount and then divides the
resulting amount by the number of remaining due dates.
If sample lines that are not yet valid exist for a payment scheme, they are also adjusted. Proration is
not necessary. All newly created, prorated, and changed sample lines are stored temporarily in an
internal table. This table contains the following data:
EABP: Payment scheme header data
ABRVORG: Time of adjustment (01 = Periodic Bill, 02 = Interim Bill)
EABPLS_DB: All active payment scheme sample lines as they currently exist in the
database
EABPLS_CRT: All new sample lines created during adjustment. These lines also contain the
value RC (line created during adjustment) in the POTYP field
EABPLS_CHG: All changed sample lines created during adjustement. These lines also
contain the value RU (line changed during adjustment) in the POTYP field
Before event Check Amount/Percentage Limits for Payment Scheme Adjustement (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 are removed from
tables ..._CRT and ..._CHG.
The contents of the internal table are copied to transfer parameter YT_PS_ADJUST.
• Adjustment for periodic bill
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.
10.5. Check Amount/Percentage Limits for Payment Scheme

Adjustment (R514)
In this event, the system checks the payment schemes adjusted during creation of an interim/periodic bill
against the amount and percentage limits defined in table Amount Limits for Adjustment of Payment
Schemes (TE558).
The following standard logic is defined for this event in function module Check Amount/Percentage Limits
for Payment Scheme Adjustment (ISU_CHECK_PS_ADJUST_R514):
The adjustment limit checks take place at contract level, even for groups of mandatory contracts. If there
is no entry in table TE558 for the selection criteria billing class, division, type of bill creation (01 = Periodic
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).
10.6. Selection of Open Items when Creating a Payment

Scheme (R515)
In event R515, you can preselect open items that you want to take into account when a payment scheme
is created or changed.
Table TY_R515_FKKCL contains all open items (credit items and receivables) that can be transferred to
the payment scheme. If you want to exclude one of these items, reset parameter XMARK_415 in this table
to its initial value. The remaining items are available for selection.
If the payment scheme is created in the background, the preselection is valid and all open items, for which
parameter XMARK_415 is not reset to its initial value, are taken into account in the payment scheme.
You can also call this event if you subsequently want to include open items in the payment scheme or
remove items from the payment scheme. The event is run via a method in dialog mode as well as if
changes are made in the background.
Indicator X_ROLLIN determines whether to add the open items that were transferred to the function
module to the payment scheme, or whether items need to be removed from the payment scheme. In the
latter case, the indicator is set to SPACE.
10.7. End Payment Scheme (R516)

In event R516, you can define individual checks that are executed when a payment scheme is ended
using transaction (E61PSD) or the appropriate method.
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.
10.9. Customer-Specific Checks for First Payment Date (R518)

In event R518, you can define your own checks to determine the first payment date when you create or
change a payment scheme. In addition to rejecting the payment date entered by the user, you can also
propose an alternative payment date.
10.10. Customer-Specific Checks for Start Date and Change

Date
In event R519, you can execute a check on the date on which a payment scheme is to be created or
changed. For example, you can always reject the creation of a payment scheme if its start date lies more
than 50 days in the future.
10.11. Customer-Specific Checks for Creation Status (R520)

In event R520, you can define rules based on payment method data, contract data, contract account data,
payment frequency, and creation status (active, inactive) to determine whether a payment scheme can be
created.
The standard logic for this event is defined in function module Check Inactive Payment Schemes and
Payment Frequency (ISU_PENDING_PAYFREQ_R520) and does not allow a payment scheme to be
created if one of the following conditions apply:
• The customer pays by direct debit and the payment frequency is weekly or fortnightly
• The customer pays by standing order and the payment frequency is weekly or fortnightly
• The customer pays by direct debit, no automatic debit information is available, and the payment
scheme was not created with the status inactive
• The payment scheme was created with the status inactive and the customer pays weekly or
fortnightly
10.12. Checks for Retaining Payment Periods (R512)

Event R521 is always called when the basic data (Payment Date, Payment Frequency, and Payment
Scheme Category) of a payment scheme is changed. You can reject changes to the basic data if they
result in a payment period being shortened incorrectly, if payments are missed, or if payments are added.
Standard checks for this event are provided in function module Only Allow New Sample Lines at End of
Period (ISU_PERIOD_PRESERVE_R521). These checks prevent payment schemes with longer payment
frequencies from being unneccesarily shortened and also ensure that no payments are missed. For
example, if a payment scheme has a yearly payment frequency, you can only make changes within 45
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.
10.13. Define Printing Rules for Change/Creation Documents

(R522)
Event R522 runs when a payment scheme is created or changed. It allows you to check the payment
scheme and all changes before you save the data. If you find an inconsistent data constellation, you can
use this event to reject the creation of the payment scheme or the changes made to it.
You can also use this event to decide whether or not to print out the changes.
In the standard logic for this event, which is defined in function module Print Change/Creation Documents
(ISU_PS_PRINT_REQUEST_R522), the agent must decided whether or not to print out a change
document when the payment scheme is created or changed.
If the payment scheme is created or changed in the background using the relevant method, the print
indicator is set as standard.
10.14. Notify Activation of Payment Scheme (R523)

A payment scheme can be created with the status active or inactive. Only payment schemes created with
the status active are transferred to event R523. This allows actions to be triggerred that are only required
for these payment schemes.
Event ACTIVATED of BOR object PAYSCHEME is triggered in the standard logic for this event, which is
defined in function module Notify Activation of Payment Scheme (ISU_PS_RAISE_ACTIVE_R523).
10.15. Print Change/Creation Documents (R524)

In event R524, you can define your own print function which you can use to notify customers if a payment
scheme is created or changed.
The standard logic for this event is defined in function module Print Payment Scheme Changes
(ISU_PS_PRINT_R524).
10.16. Adjust Customer-Specific Fields for Payment Scheme

(R525)
In the tables for the payment scheme header data (EABP) and the paymnt scheme sample lines (EABPL),
you can include your own fields using the include structures CI_EABP and CI_EABPL. You can adjust
these fields using this event.
The event is called when a payment scheme is created or changed, before the header data and line data
is saved.
10.17. Amount Limit Warning Ignored (R526)

In table Percentage Limits for Manual Payment Scheme Changes (TE560), you can define upper and
lower limits (percentage and absolute) for the permitted manual changes to the payment scheme
amounts. If these limits are not adhered to during manual changes, the agent is notified. However, the
agent has the option to ignore the message. In this case, event R526 is executed, which allows you to
react to unexpected changes by triggering a workflow, for example.
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).
10.19. Override Selection of Open Items (R528)

Event R528 is executed when a payment scheme is created or changed, after the agent has selected
open items for transfer to the payment scheme. This event allows you to check the suitability of the items
once more before they are transferred. For example, you can exclude bill items from being transferred if
the open amount is higher than the limit value
10.20. Change Meter Reading Unit During Creation/Change of

Payment Scheme (R529)
With event R529, you can override the meter reading unit determined by the system for each contract
when you create or change a payment scheme. You must take the following into account:
• The change that you made to the meter reading unit is not saved in the database. This means that:
Between the time you create a payment scheme and the first change you make to it, you
have to copy the meter reading unit determined in event R529 to the installation.
When you change a payment scheme, you have to change the meter reading unit again in
event R529 following the same rules you used when creating it.
If you do not do this, inconsistencies may occur, especially when changes are made to the payment
scheme amount.
• Before you execute the first interim billing with payment scheme adjustment or the first periodic
billing, you must copy the meter reading unit determined in R529 and used to create/change a
payment scheme to the installation data. If you do not, problems may occur during determination of
the payment scheme amount. Event R529 is not executed when an interim/periodic bill is created
and the payment scheme is adjusted. This means that you cannot change the meter reading unit
determined by the program.
• When you change the meter reading unit in event R529, you must ensure that, if a group of
mandatory contracts exists, the same portion is allocated to all contracts via the changed meter
reading unit.
10.21. Execute Amount Checks (R530)

Event R530 is executed in the methods Validation of Amount Change of a Sample Line
(SingleLineValidation) and Check Payment Scheme Adjustment with Open Items
(CompleteReassessValidation), which are part of BOR object PAYSCHEME. When the methods are
called, you can specify whether to carry out a standard check or whether to use event R530.
The standard check determines whether the amount change to a single payment scheme sample line or
the addition/removal of a credit or receivable item to or from a payment scheme lies within certain limits.
You define these limits in tables Amount/Percentage Limits for Payment Scheme Adjustment in Invoicing
(TE558) and Percentage Limits for Manual Payment Scheme Changes (TE560).
Page 46 of 58
If you want to use event R530, you have to define your own check logic.
10.22. Automatic Account Maintenance when Payment

Scheme is Ended (R531)
With this event, you can decide whether automatic account maintenance takes place when a payment
scheme is ended.
If a payment scheme is ended on the current date, automatic account maintenance is carried out for this
payment scheme as standard. In the process, all budget billing payments mae between the last
interim/periodic bill and the current date are cleared against the bills transferred to the payment scheme.
10.23. Determine Deactivation Reason for Payment Scheme

(R532)
In this event, you can define the deactivation reason of a payment scheme regardless of the calling
process. The following parameters are available:
• XWA_OBJ: Object data for the deactivated payment scheme. This parameter contains the contact
data and contract account data as well as the header data and line data of the payment scheme
that is to be deactivated.
• X_CALL_ID: Indicator that identifies the calling process. Currently the event is called by the
following processes:
A: Move-out
B: Move-out reversal
You return the deactivation reason to the calling program in parameter Y_TERMREASON. If this
parameter does not contain a value, either no deactivation reason is entered in the payment scheme
header data or a reason that is entered in the header data is deleted.
10.24. Divide Bill End Amount (R533)

In this event, you can define the period to use to divide an old bill and the receivable/credit items
transferred to the payment scheme amongst the payment scheme due dates. To do this, choose a date in
the event to return to the calling program. The system determines the number of due dates between the
current date and the date you specified and divides the amounts from the old bill and the transferred
receivable/credit items accordingly.
10.25. Adjust Customer-Specific Tables (R534)

When you create or change a payment scheme, you can adjust data in your own tables. You do this using
this event. All changes to the payment scheme have already been made and have been flagged to be
changed in the database. Therefore, no more changes can be made to the payment scheme or to the
sample lines at this point.
This event is called after event Adjust Customer-Specific Fields for Payment Scheme (R525). It has the
same interfaces but you cannot make any changes to the payment scheme.
10.26. Select Contact Accounting Items for Payment Scheme

(R415)
Page 47 of 58
In event R415, you determine which items to transfer to the payment scheme during an invoicing run. You
can remove items that the system has proposed for transfer.
If you do not use this event, items that result from the following processes and that are part of the current
invoicing run are transferred to the payment scheme as standard:
• Interim bill:
Account maintenance
Transfer posting
Request with invoicing
• Periodic bill
Current consumption billing
Account maintenance
Transfer posting
Request with invoicing
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
Table 11.1: Methods for BOR Object PAYSCHEME
The BOR object provides the methods listed in table 13.1.

You execute the Display and Edit methods in the Display (EA62PS) and Change (EA63PS) transactions.
The Create and Terminate methods can run in the background, as well as in transactions EA61PS and
E61PSD.
The Create method is instance-independent. It requires the following transfer parameters:
• Number of the contract, for which a payment scheme is to be created
• Desired start date
• First payment date
• Payment frequency
• Indicator, to show whether or not the payment scheme is to be created as active
If you start the Create method in the background, you can no longer access the creation process.
Therefore, if the system cannot create a payment scheme using the transfer data supplied, it terminates
the method immediately and issues an error message. This can be the case if a new payment scheme is
to be created for an existing mandatory group, and the basic data transferred for Payment Date and
Payment Frequency is no longer consistent with that of the existing payment scheme in the mandatory
group.
The remaining methods are instance-dependent. This means that an instance of the object PayScheme
must exist with correctly maintained key fields. You can only call the Activate, SampleLineChange,
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)
Table 12.1: Payment Scheme Header Data to be Transferred
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:
Field Name Explanation Mandatory Optional

VERTRAG Contract X
TVORG Subtransaction X
GRBBP VAT determination indicator X
BEGDAT Start date of sample line X
BETRWBILL Consumption billing portion of payment scheme X
amount
PAYFREQ Payment frequency: X
W – Weekly
F - Fortnightly
M – Monthly
Q – Quarterly
Y - Yearly
PAYDATE Payment date X
Caution:
If you have entered the value “X” for a certain
payment scheme category in the field Do Not
Generate Requests in Dialog (NOLINONL) in the
TE638 table, note the following:
- If the current billing period is no longer to be
requested, you must set the payment date to the first
day of the next billing period.
- If the current billing period is still to be requested,
you must set the payment date to the first day of the
current billing period.
PSTYPE Payment scheme category X
Transferred values must belong to the values that
you defined in TE638.
ENDDAT End date of sample line
If you do not enter an end date, the system internally
sets the value to 31.12.9999.
Caution: For each payment scheme, you can only
transfer one line with an initial end date.
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:
Table Name Description Archiving- Data

Relevant Component
EABP Header data for budget billing plan Yes IS-U
EABPL Line data for payment scheme Yes IS-U
EABPLREQ Internal table for generation of payment scheme requests Yes IS-U
DFKKKO Header data for payment scheme requests Yes FI-CA
DFKKOP Line data for payment scheme requests Yes FI-CA
Table 13.1: Database Tables for Payment Scheme
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
Start of archiving program
Figure 13.1: Payment Scheme Archiving – Analysis Run
Explanations for analysis run:

a. Selection of header data for deactivated payment schemes
You can only deactivate a payment scheme if it is no longer used productively (it has been
deactivated). This happens within the following processes:
A payment scheme is stopped, and is then deactivated within a periodic bill / interim
bill
A payment scheme is stopped using automatic account maintenance
A payment scheme is stopped due to a move-out, and deactivated during creation of
the final bill
b. Is associated header data from the print document archived?
If you have deactivated a payment scheme within a periodic / interim bill or final bill, you can
only archive it if the corresponding header data from the print document (archiving object
ISU_PRDOCH) has been archived. This is necessary because the print document can still
be cancelled until it is completely archived. Because reversing the print document also
results in the payment scheme being reactivated, you cannot yet archive the payment
scheme.
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:
Select payment scheme

number EABPARCH
EABP
Select payment scheme data EABPL
EABPLREQ
Write payment scheme date

into archive file CPS archive file
no End of
selection?
yes
3
no Autom. start of
delete prog.
selected?
CPS archive file

yes
Read CPS data from

archive file and delete
corresponding data from
EABP
database EABPL
EABPLREQ
Write protocol
End of
archiving run
Page 55 of 58
Figure 13.2: Payment Scheme Archiving – Archiving Run
Explanations for archiving run:

The deletion program is either started automatically after the generation of the archive file, or
manually, depending on the settings made in Customizing for the ISU_BBP archiving object. In the
first case, this can mean that the deletion program for a closed archive file runs parallel to an
archiving run in which more than one archive file is generated.
3. Deleting archived data
Only those data records that have been successfully written in an archive file are deleted from the
corresponding database tables. The system ensures that no data is deleted, that has not yet been
written in an archive file, but that has the appropriate status.
4. Reloading an archive run
You can only reload complete data from an archive run. You cannot reload individual data records.
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.
13.2. Parallel Processing

A parallel processing object is available for archiving payment schemes. You can start this object from the
area menu for the utilities industry, under Tools → Data Archiving → Parallel Processing → Invoicing, or
directly using the EABBP transaction.
With the parallel processing object, you can automatically create several parallel archiving jobs, which
makes archiving faster.
Each job processes a range of contract accounts that are assigned to it. The system structures the range
before scheduling the archiving run.
The payment schemes found for the respective range are analyzed to see whether they can be archived,
and the archiving is executed. You cannot separate analysis runs and archiving runs, as is possible with
manual processing using the SARA transaction. If the settings in Customizing for archiving specify that the
deletion program is to be started automatically, then this also applies to parallel processing.
13.3. Simulation Documents

You can use the Delete Simulated Billing and Print Documents transaction (ESIMD) to delete simulated
billing and print documents. You can also delete these documents through the area menu for the utilities
industry, under Tools → Delete → Billing/Invoicing. This also covers simulation documents for budget
billing extrapolation.
To adjust payment schemes, you must access the preceding document(s) when creating a new
extrapolation document. For this reason, the following check has been added to the program for
transaction ESIMD.
If an active payment scheme exists for a contract, for which you want to delete an extrapolation document,
you can only delete the extrapolation document if the end of the extrapolation period for this document lies
at least one year in the past.
13.4. Displaying Archived Payment Schemes
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
14.2. Relevant Tables

EABP Payment scheme header data
EABPL Sample lines for payment scheme
TE558 Amount/percentage limits for payment scheme adjustment during invoicing
TE560 Amount/percentage limits for manual payment scheme adjustment
TE561 Deactivation reason for payment scheme
TE637 Control parameters for payment scheme
TE638 Payment scheme category
Page 58 of 58

Cookbook Payment Scheme e

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cookbook Payment Scheme e

Uploaded by

Copyright:

Available Formats

Cookbook

The following scenarios exist for mandatory contracts:

3.2.1. Including Open Items in the Payment Scheme

3.2.2. Determining Amounts for the Payment Scheme

3.2.3. The Structure of a Payment Scheme

Figure 3.1: Sequence of Events During Creation of a Payment Scheme

Direct Changes in a Sample Line*

Field Name Description

6.1. Adjusting a Payment Scheme During Creation of an

• Recovery rate for a long remaining period

6.2. Adjusting a Payment Scheme During Creation of a

6.3. Amount/Percentage Limit Check for Payment Scheme

7. Generating Statistical Payment Scheme Requests

9.1.1. Budget Billing Procedure

9.1.2. Define Control Parameters for Payment Scheme

9.1.3. Payment Scheme Category

9.1.4. Define Deactivation Reason

9.1.5. Number Ranges and Payment Schemes

9.1.6. Rounding Parameters

9.1.7. Define Amount/Percentage Limits for Automatic Payment

• Minimum Percentage Limit for Amount Increase

9.1.8. Amount/Percentage Limits for Manual Payment Scheme

9.1.9. Customizing for Invoicing

9.2. Customizing in FI-CA

1. Define External Main Transactions and Subtransactions

Table 9.2: Example of Defining External Subtransactions for Payment Schemes

2. Allocate external transactions to internal transactions

4. Accounts for received budget billing amounts

Table 9.6: Example of Account Assignments in Posting Area R007

Table 9.7: Example of Payment Allocation in Posting Area 1010

10.1. Determining the Extrapolation Period for the Payment

10.3. Determine Budget Billing Amount for Payment Schemes

10.4. Adjust Payment Scheme for Periodic/Interim Bill (R513)

10.5. Check Amount/Percentage Limits for Payment Scheme

10.6. Selection of Open Items when Creating a Payment

10.7. End Payment Scheme (R516)

10.9. Customer-Specific Checks for First Payment Date (R518)

10.10. Customer-Specific Checks for Start Date and Change

10.11. Customer-Specific Checks for Creation Status (R520)

10.12. Checks for Retaining Payment Periods (R512)

10.13. Define Printing Rules for Change/Creation Documents

10.14. Notify Activation of Payment Scheme (R523)

10.15. Print Change/Creation Documents (R524)

10.16. Adjust Customer-Specific Fields for Payment Scheme

10.17. Amount Limit Warning Ignored (R526)

10.19. Override Selection of Open Items (R528)

10.20. Change Meter Reading Unit During Creation/Change of

10.21. Execute Amount Checks (R530)

10.22. Automatic Account Maintenance when Payment

10.23. Determine Deactivation Reason for Payment Scheme

10.24. Divide Bill End Amount (R533)

10.25. Adjust Customer-Specific Tables (R534)

10.26. Select Contact Accounting Items for Payment Scheme

Table 11.1: Methods for BOR Object PAYSCHEME

The BOR object provides the methods listed in table 13.1.

Table 12.1: Payment Scheme Header Data to be Transferred

Field Name Explanation Mandatory Optional

Table Name Description Archiving- Data

Table 13.1: Database Tables for Payment Scheme

Start of archiving program

Figure 13.1: Payment Scheme Archiving – Analysis Run

Explanations for analysis run:

Select payment scheme