Cookbook Payment Scheme e

Cookbook

Payment Scheme Version August 2004

Page 2 of 58

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 3 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 4 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 5 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 6 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 7 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 8 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 Scheme Frequency

In this field, you enter how frequently the customer has to make payments. In the payment scheme, payments can be made weekly, fortnightly, monthly, quarterly, or yearly.

Payment Scheme Category

In this field, you can allocate a payment scheme category defined in Customizing to a payment scheme. You use the payment scheme category to define, for example, 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 9 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 10 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.

R515Manipulation der Auswahlliste offener Posten beim

Anlegen/Ändern eines Zahlungsschemas

R519Regeln zum Begin und Änderungsdatum

R520

Regeln zum Anlegestatus eines Zahlungsschemas

R510Hochrechnungsperiode für das Zahlungsschema

bestimmen

R511Ermittlung der Zahlungsschemamusterzeilen aus

dem Abrechnungsbeleg

R518Regeln zum ersten Zahltag

R528Prüfung ausgewählter Posten beim Anlegen/Ändern

eines Zahlungsschemas

R529Übersteuern der Ableseeinheit beim Anlegen und

manuellen Ändern eines Zahlungsschemas

R512

Ermittlung des Zahlungsschemabetrages

R527Betragsrundung im Zahlungsschema

R517Aktivieren eines Zahlungsschemas

R525Füllen kundeneigener Felder zum Zahlungsschema

R522

Prüfungen zum Drucken des Erstellungs- bzw. Änderungsschreibens

R524Druckfunktionalität

R523Aktivierung mitteilen

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 11 of 58

You can also use method CREATE of BOR object PAYSCHEME to create a payment scheme.

Page 12 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 13 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 14 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

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.

Payment Scheme Status

13 – Inactive and Deactivated

Payment Scheme Start Date

Next Interim Reassessment Invoicing

Based on the system date, this is the next interim billing and 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 15 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 16 of 58

Payment Scheme Category

The payment scheme category is defined in the Payment Scheme Category table and is allocated to the sample line.

Bill Portion of Payment Scheme Amount

This field displays the portion of the amount to be paid that comes from the transferred open items.

Total Items Included in Payment Scheme

This field displays the total amount of all open items included in the payment scheme for the corresponding sample line.

Total Amount from Extrapolation

This field displays the gross amount determined from extrapolation plus taxes.

Due Date of Last Request

This field displays the most recently generated payment scheme request (without taking the factory calendar into account)*

Number of Sample Line

This fields displays the consecutive internal number of the sample 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 Amount

Do not copy this field to the display as it is only relevant internally.

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

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 17 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 Number

This field displays the number of the extrapolation document that was either 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 18 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 19 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 20 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:

You create a periodic bill for a customer on 1st January. For the periodic billing period 1

st January until 31

st

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 payment date is the 20

th 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. You execute an interim billing for the customer on 1

st 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. During creation of the interim billing document, extrapolation is executed for the period January 1

st to

December 31st. 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


st to






New payment scheme amount: 15 + (450/ 6) = 90

Example 3


st to






New payment scheme amount: 15 + (150 / 6) = 40

Example 4

Page 21 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 billing document, extrapolation is executed for the period January 1

st to December 31

st. The result of this

is €750. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows:

• Extrapolation amount to be divided: 750 – (5 * 50 + 1 * 50) = 450 Even though payment has not been made for the month of June, the payment scheme amount is adjusted as if payment had been made. This is because you assume that the customer will still pay.



• 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 1

st to

December 31st. The result of this is €750. An additional credit item of €50 is added to the payment


• Extrapolation amount to be divided: 750 – (6 * 50 + 1 * 50) = 400 Since the customer has already made payment for the month of July, this month is taken into account when determining the new extrapolation amount: This has the effect that the amount for July is also deducted from the extrapolation amount. It also means that the due date for July is no longer taken into account for the payment scheme adjustment.


• 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

On March 1st the customer informs you of an increase in expected consumption, which in turn results in a

higher monthly payment scheme amount. As of March 20th the amount increases to €80 (€65 consumption

and €15 transferred items). On May 17

th the customer requests to change the payment frequency from monthly to fortnightly. This

change is to take effect on August 15th with August 18

th as the first payment date.

On June 7th the customer wants to make another change to the payment frequency. Starting from

November 1st, he wants to change the payment frequency to quarterly and have November 20

th as the first

payment day. All payment scheme requests up to and including the month of June have been paid on time. During creation of the interim billing document, extrapolation is executed for the period January 1

st to

December 31st. The result of this is €900.

No additional items should now be added to the payment scheme.

The payment scheme amount is adjusted as follows:

• Extrapolation amount to be divided: 900 – (2 * 50 + 4 * 65) = 540

Note that the extrapolation portion of the payment scheme amount was increased to €65 as of March.

• Open due dates until the end of the periodic billing period:

Page 22 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 the period July 1

st to December 31

st 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

The interim bill created on July 1st is based on an estimation. Therefore, it does not result in a change to

the payment scheme amount. On November 25

th 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, extrapolation is executed for the period January 1

st to December 31

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

• The calculated extrapolation amount (new amount plus tax) E is split into two parts, EA und E

B.

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

B is the extrapolation portion for the period from the end of the interim billing period to the end of

the current periodic billing period. The division of E into E

A and E

B takes place linearly based on the number of payment scheme due

dates within the two periods. All payment scheme requests are subtracted from extrapolation portion E

A. The same conditions

apply as with adjustment with recovery rate Completely. The resulting amount EA’ is then split into

two further parts, EA1

and EA2

. First of all the number of payment scheme due dates is determined starting from the end of the interim billing period. The relationship between E

A1 and E

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

• The sum of EB and E

A1 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:

A periodic bill is created for a customer on January 1st. For the periodic billing period 1

st January until 31

st

December, the system determines an extrapolation amount of €600. Open items to the value of €180 are included in the payment scheme.

In the payment scheme, the payment frequency is monthly and the payment date is the 20th 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.

You execute an interim billing for the customer on 1st July. The payment scheme amount is adjusted when

this billing is invoiced. ...

Example 1


st to




• The extrapolation amount is split into two parts: E

A = €300

EB = €300

• The portion of EA that the customer has not yet paid (E

A’) is EA’ = 300 – (6*50) = 0.

EA’ is split into two parts E

A1 = €0 and E

A2 = €0.

The extrapolation portion still to be divided is 300 + 0 = 300.


Page 24 of 58



Example 2


st to





A = €375

EB = €375

• The portion of EA that the customer has not yet paid (EA’) is E

A’ = 375 – (6*50) = 75


A1 = €37.5 and E

A2 = €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

The interim bill created on 1st July is based on an estimation. Therefore, it does not result in a change to

the payment scheme amount.

On November 25th the customer provides you with an actual meter reading. You carry out an unplanned


st to December 31


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 = 750 * (11/12) = €687.50

EB = 750 * (1/12) = €62.50


A’) is E

A’ = 687.5 – (11*50) = 137.5


A1 = €11.46 and E

A2 = €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 25 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.

• The calculated extrapolation amount (new amount plus tax) E is split into two parts, EA und E

B.

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 E

B is the extrapolation portion for the period from the end of the interim billing period to the end of

the current periodic billing period. The division of E into E

A and E

B takes place linearly based on the number of payment scheme due

dates within the two periods.

• The amount EB is divided evenly amongst the payment scheme due dates remaining until the end of

the current periodic billing period.

6.1.4. Adjust Payment Scheme for Interim Bill with Different Recover Rates

The following examples are based on the assumption that the recovery rates have the following values:

• For a long remaining period - Completely

• For a medium remaining period - Partially

• For a short remaining period - None

The extrapolation amount is determined as described in the previous chapters.

The following applies for all examples:

A periodic bill is created for a customer on January 1st. For the periodic billing period 1

st January until 31

st

December, the system determines an extrapolation amount of €600. Open items to the value of €180 are transferred to the payment scheme.

In the payment scheme, the payment frequency is monthly and the payment date is the 20th 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 the period January 1

st to December 31

st. 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 26 of 58

• New payment scheme amount: 15 + (600/ 9) = 81,67

Example 2

You execute an interim billing for the customer on 1st June. The payment scheme amount is adjusted

when this billing is invoiced. During creation of the interim billing document, extrapolation is executed for the period January 1

st to December 31

st. 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 = €375

EB = €375


A’) is E

A’ = 375 – (6*50) = 75


A1 = €37.50 and E

A2 = €37.50.

The extrapolation amount still to be divided is 375 +37.5 = 412.5.




Example 3

On June 1st 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.

On November 25th the customer provides you with an actual meter reading. You carry out an unplanned


st to December 31


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 = €687.50

EB = €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 27 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:

A periodic bill is created for a customer on January 1st. The payment scheme to be adjusted has a monthly

payment frequency and with the payment date on the 20th of each month.

The extrapolation for the period January 1st to December 31

st 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 28 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 29 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 30 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 31 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 32 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 33 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 34 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 35 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 36 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 Transaction

Description Comment

1053 Budget billing procedure: payment scheme

This main transaction is used to create the payment scheme requests and the corresponding payments.

Table 9.1: Example of Defining an External Main Transaction for the Payment Scheme

Example


Ext. Sub-transaction

Description Comment

1053 Budget Billing: Payment Scheme

This entry is used to define the budget billing procedure

0010 Budget Billing Payment

0110 Extrapolation Budget Billing Plan (Credit)

It is possible to use this 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 Scheme

1053 Budget Billing Procedure: Payment 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 37 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 Division

Ext. MTran.

Ext. STran.

Description Debit/Credit Indicator

0001 01 1053 0110 Extrapolation Budget Billing Plan (Credit)

H

0120 Extrapolation Budget Billing Plan (Debit)

S

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

Ext. STran.

Description Debit/Credit Indicator

R 1053 0110 Extrapolation Budget Billing Plan (Credit)

H

R 1053 0120 Extrapolation Budget Billing Plan (Debit)

S

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 Code

Division

Account Determination ID


Ext. Subtransacti

on

Account Number

0001 01 01 1053 0110 0000170060

Table 9.6: Example of Account Assignments in Posting Area R007

Page 38 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

Statistical Key


for Statistical Request

Ext. Subtransactio

n for Statistical Request

Ext. Main Transactio

n for Payment

Ext. Subtransacti

on for Payment

Clearing Restriction

Payment Lock

Reason

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 39 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 40 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 41 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 42 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 43 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 44 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 45 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 46 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 47 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 48 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 49 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 50 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 51 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 (if not maintained, then determined from contract account)

X

PSSTATUS Status of payment scheme (can also be empty if active)

X

VERTRAG Contract X

WAERS Currency X

ENDPERIODE End of payment scheme period (if empty, then the value 31.12.9999 is entered)

X

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 52 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 amount

X

PAYFREQ Payment frequency: W – Weekly F - Fortnightly M – Monthly Q – Quarterly Y - Yearly

X

PAYDATE Payment date 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.

X

PSTYPE Payment scheme category Transferred values must belong to the values that you defined in TE638.

X

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 53 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-Relevant

Data 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 54 of 58

Save CPS number for subsequent

archiving

EABP

Selection of header data for deactivated payment schemes

(CPS)

End of selection?

End analysis run

Log output

Is associated header data

from the print document archived?

nein

Yes

1

2

CPS deactivated by account

maintenance?

EABPARCH

Autom. start

of archiving program?

Start of archiving program

Yes

Yes

Yes

Yes

No

No

No

3

4

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 55 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:

Write payment scheme dateinto archive file

EABPEABPL

EABPLREQ

CPS archive file

EABPARCHSelect payment scheme

number

End of selection?

End of archiving run

Write protocol

Select payment scheme data

Autom. start ofdelete prog.

selected?

3

Read CPS data fromarchive file and delete

corresponding data fromdatabase

CPS archive file

EABPEABPL

EABPLREQ

yes

yes

no

no

Page 56 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 57 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 58 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