Professional Documents
Culture Documents
Cookbook PaymentScheme e
Cookbook PaymentScheme e
Table of Contents
1. 2. 3. 3.1. 3.2. 3.2.1. 3.2.2. 3.2.3. 4. 5. 6. 6.1. 6.1.1. 6.1.2. 6.1.3. 6.1.4. 6.2. 6.3. 7. 8. 9. 9.1. 9.1.1. 9.1.2. 9.1.3. 9.1.4. 9.1.5. 9.1.6. 9.1.7. 9.1.8. 9.1.9. 9.2. 10. 10.1. Glossary...................................................................................................................................... 4 Introduction ................................................................................................................................. 6 Creating a Payment Scheme ....................................................................................................... 7 General ................................................................................................................................... 7 Creating a Payment Scheme - Transaction EA61PS................................................................ 8 Including Open Items in the Payment Scheme .................................................................... 9 Determining Amounts for the Payment Scheme................................................................... 9 The Structure of a Payment Scheme ................................................................................. 10
Changing a Payment Scheme Manually .................................................................................... 12 Displaying a Payment Scheme .................................................................................................. 14 Adjusting a Payment Scheme During Creation of a Periodic/Interim Bill ..................................... 18 Adjusting a Payment Scheme During Creation of an Interim Bill............................................. 18 Adjusting the Payment Scheme for Interim Bill with Recover Rate Completely ................... 19 Adjusting the Payment Scheme for Interim Bill with Recover Rate Partially ........................ 22 Adjust Payment Scheme for Interim Bill with No Recover Rate .......................................... 24 Adjust Payment Scheme for Interim Bill with Different Recover Rates................................ 25 Adjusting a Payment Scheme During Creation of a Periodic Bill............................................. 26 Amount/Percentage Limit Check for Payment Scheme Adjustment........................................ 27 Generating Statistical Payment Scheme Requests .................................................................... 28 Ending a Payment Scheme ....................................................................................................... 30 Customizing .............................................................................................................................. 32 Customizing in IS-U............................................................................................................... 32 Budget Billing Procedure ................................................................................................... 32 Define Control Parameters for Payment Scheme............................................................... 32 Payment Scheme Category............................................................................................... 33 Define Deactivation Reason .............................................................................................. 34 Number Ranges and Payment Schemes ........................................................................... 34 Rounding Parameters ....................................................................................................... 34 Define Amount/Percentage Limits for Automatic Payment Scheme Adjustment ................. 34 Amount/Percentage Limits for Manual Payment Scheme Adjustment ................................ 35 Customizing for Invoicing .................................................................................................. 35 Customizing in FI-CA ............................................................................................................ 35 Events for Payment Schemes.................................................................................................... 39 Determining the Extrapolation Period for the Payment Scheme (R510).................................. 39 Page 2 of 58
10.2. 10.3. 10.4. 10.5. 10.6. 10.7. 10.8. 10.9. 10.10. 10.11. 10.12. 10.13. 10.14. 10.15. 10.16. 10.17. 10.18. 10.19. 10.20. 10.21. 10.22. 10.23. 10.24. 10.25. 10.26. 11. 12. 13. 13.1. 13.2. 13.3. 13.4. 14. 14.1. 14.2.
Determine Payment Scheme Lines from Billing Document (R511) ......................................... 40 Determine Budget Billing Amount for Payment Schemes (R512) ........................................... 40 Adjust Payment Scheme for Periodic/Interim Bill (R513) ........................................................ 40 Check Amount/Percentage Limits for Payment Scheme Adjustment (R514) .......................... 42 Selection of Open Items when Creating a Payment Scheme (R515) ...................................... 43 End Payment Scheme (R516) ............................................................................................... 43 Activate Payment Scheme (R517) ......................................................................................... 44 Customer-Specific Checks for First Payment Date (R518) ..................................................... 44 Customer-Specific Checks for Start Date and Change Date .............................................. 44 Customer-Specific Checks for Creation Status (R520)....................................................... 44 Checks for Retaining Payment Periods (R512) .................................................................. 44 Define Printing Rules for Change/Creation Documents (R522) .......................................... 45 Notify Activation of Payment Scheme (R523) .................................................................... 45 Print Change/Creation Documents (R524)......................................................................... 45 Adjust Customer-Specific Fields for Payment Scheme (R525) ........................................... 45 Amount Limit Warning Ignored (R526)............................................................................... 45 Customer-Specific Rules for Amount Rounding in the Payment Scheme (R527)................ 46 Override Selection of Open Items (R528) .......................................................................... 46 Change Meter Reading Unit During Creation/Change of Payment Scheme (R529) ............ 46 Execute Amount Checks (R530)........................................................................................ 46 Automatic Account Maintenance when Payment Scheme is Ended (R531)........................ 47 Determine Deactivation Reason for Payment Scheme (R532) ........................................... 47 Divide Bill End Amount (R533) .......................................................................................... 47 Adjust Customer-Specific Tables (R534) ........................................................................... 47 Select Contact Accounting Items for Payment Scheme (R415) .......................................... 47
BOR Object PAYSCHEME ........................................................................................................ 49 Migrating Payment Schemes ..................................................................................................... 51 Archiving and Deleting Payment Schemes................................................................................. 53 Archiving ............................................................................................................................... 53 Parallel Processing................................................................................................................ 56 Simulation Documents........................................................................................................... 56 Displaying Archived Payment Schemes................................................................................. 56 Appendix ................................................................................................................................... 58 Relevant Transactions........................................................................................................... 58 Relevant Tables .................................................................................................................... 58
Page 3 of 58
1. Glossary
ADK The archive development kit (ADK) is a tool for developing archiving solutions. At the same time, it prepares the runtime environment for archiving. It is an intermediate layer between the application program and the archive, that provides all the functions required for archiving.
Archive Information Structure A central element of the archive information system. It enables you to find and display archived data using selectable data fields. Archiving object The archiving object is central to the mySAP Technology Data Archiving concept. This is where you define exactly what to archive and how. The archiving object describes which data objects must be grouped together to create an object that can be interpreted for archiving without taking the technical details such as release and hardware status into account. An attribute describes the accessible data of a business object. 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. 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. Abbreviation of Customer Payment Scheme or Payment Scheme. An object can communicate a change in status by means of an event. Events are system-wide notifications regarding an objects 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. 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 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.
BOR object
Field catalog
FI-CA document type The document type classifies the documents from contract accounts receivable and payable. They are saved in the document header data when a document is posted. Each document type is allocated a number range for the creation of individual documents. The number range determines which values are entered in the Document Number field. Additional number ranges can also be allocated for the automatic generation of a large number of documents in (parallel) mass processing. Additional number ranges are not required if an external number range is allocated to the document type.
Page 4 of 58
Method (BOR)
An object encapsulates its internal status so that the outside world is not dependent on the implementation. The object provides operations (methods) so that it can be worked with. These methods are accessible from outside. 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. 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 Payment scheme 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.
Sample line
Payment frequency
PS PS request
Page 5 of 58
2. Introduction
The payment scheme is a statistical budget billing procedure. Consumption billing amounts from previous and current billing periods are copied to the payment scheme and distributed evenly over the next billing period. The budget billing amount is determined partially from an extrapolation portion that reflects the expected consumption for the current billing period and partially from the copied consumption billings. It is not necessary to copy consumption billings to the payment scheme in order to use this procedure. If you do copy them, the bills are not paid directly by the customer but during the next billing period when the payment scheme requests are paid. The payment scheme allows payments to be made in weekly, fortnightly, monthly, quarterly, and yearly cycles. The validity period of a payment scheme is unrestricted. This means that a payment scheme is not ended and another created when you create a periodic bill. Instead, the existing payment scheme is adjusted. As a result, you can charge the customer at least the previous budget billing amount if the periodic bill is late, for example. In addition to consumption billings, you can include all other credit and receivables items from the same contract in the payment scheme. You can also remove credit and receivables items that you copied to payment scheme if they have not yet been cleared.
Page 6 of 58
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 First Due Date Here you have the option to change the payment scheme start date that you entered in the initial screen. 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. 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. 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. 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.
PS Inactive
The contract account does not have any other mandatory contracts, or mandatory contracts exist for which payment schemes have not yet been created: In this case, the system creates a payment scheme for each contract. The following data must be the same in each payment scheme: Payment day Payment frequency Payment scheme category Payment scheme active/inactive
The contract account has at least one other mandatory contract, for which a payment scheme already exists:
Page 8 of 58
The system creates a separate payment scheme for the contract. The following data must be the same as in the other payment schemes: Payment frequency Payment day Payment scheme category If the contract account has mandatory contracts with no payment schemes, as well as at least one contract with a payment scheme, create a new payment scheme for every contract that does not already have one. Ensure that the above data is the same in all payment schemes.
The system uses this data to carry out extrapolation for the contract. The extrapolation result is evaluated in event Determination of Payment Scheme Sample Lines from Billing Document (R511). In the standard logic provided by SAP, the net amounts of all extrapolation document lines that are relevant to budget billing and posting are added together for each contract. If these lines have different debit subtransactions, the system uses the first subtransaction it finds as the valid transaction for all further processing. A message will inform you of this. The same procedure applies if the lines have different tax determination codes. If individual extrapolation lines have a credit subtransaction, the extrapolation amount is reduced. A special sample line is not created. The system uses the data from event R511 to create a payment scheme sample line in event Determine Budget Billing Amount for Payment Scheme (R512). In the standard logic provided by SAP for this event, the system first determines the payment scheme amount for each due date item. The extrapolation amount determined in event R511 and the amount from the open items that was transferred to the payment scheme are added together. This sum is divided by the number of payment scheme requests remaining in the billing period. The number of payment scheme requests depends on the start date of the payment scheme, the payment frequency, and the end of date of the billing period. For customers that pay by direct debit or standing order, the system checks the standard logic of the event to ensure that the number of days between the creation date and the first due date of a payment scheme Page 9 of 58
request is at least as high as the number of days defined in the Define Control Parameters for Payment Scheme table. If the number of days is lower, the system determines an alternative first payment date and copies it to the payment scheme. After event R512, the event Customer-Specific Rules for Rounding Amounts in the Payment Scheme (R527) is called, in which the payment scheme amount is rounded according to the rules defined in the Rounding Parameters table.
R519 Regeln zum Begin und nderungsdatum R517 Aktivieren eines Zahlungsschemas R518 Regeln zum ersten Zahltag R525 Fllen kundeneigener Felder zum Zahlungsschema R528 Prfung ausgewhlter Posten beim Anlegen/ndern eines Zahlungsschemas
R529 bersteuern der Ableseeinheit beim Anlegen und manuellen ndern eines Zahlungsschemas R524 Druckfunktionalitt R510 Hochrechnungsperiode fr das Zahlungsschema bestimmen R523 Aktivierung mitteilen R511 Ermittlung der Zahlungsschemamusterzeilen aus dem Abrechnungsbeleg
Figure 3.1: Sequence of Events During Creation of a Payment Scheme If the contract for which you want to create the payment scheme is a mandatory contract and another mandatory contract with a payment scheme already exists, the system copies changes made to the existing payment scheme to the new payment scheme. This means that when the new payment scheme is created, it can already have several sample lines. In the Create Payment Scheme transaction (EA61PS), you can make further changes to the new payment scheme, such as the payment scheme amount or the payment frequency. When you save the payment scheme, the system first calls the event Fill In User-Defined Fields for Payment Scheme (R525). In this event, you can define your own fields in the tables Budget Billing Plan Header Data (EABP) and Budget Billing Sample Lines (EABPL). The event Print Modification/Creation Documents (R522) then runs. This allows you to check the consistency of the payment scheme using your own rules. If there are any inconsistencies, you can prevent the payment scheme from being created at this point. The system then calls event Print Function (R524) to print out the payment scheme. Note Page 10 of 58
You can also use method CREATE of BOR object PAYSCHEME to create a payment scheme.
Page 11 of 58
Direct Changes in a Sample Line* Start Date Amount The change in the sample line is effective as of this date. 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. In this field, you define whether to adjust sample lines when an interim or a periodic bill is created. You can enter the following values: : Adjust for Interim and Periodic Bills 01: Do Not Adjust for Interim and Periodic Bills 02: Do Not Adjust for Interim Bill Changes Using Pushbuttons Basic Data The basic data of a payment scheme comprises all data that has to be changed at the same time within a mandatory group for all payment schemes. If the basic data in a payment scheme is changed, all payment schemes in the same mandatory group are adjusted automatically. You make the changes in the sample lines of the payment scheme. If an active sample line is changed, it is prorated and a new line is created with the new basic data. Basic data includes the following: Change Effective From: This is the date as of when the change to the basic data takes effect. The system chooses the earliest possible date based on the system date. The system ensures that no paid payment scheme requests exist after the change date. Payment day Page 12 of 58
Changability Status
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. 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.
Exclude Items
*If you call a payment scheme using the change transaction, the valid sample line is displayed in a version that is not ready for input, as well as in a version that is ready for input. The latter version contains the earliest possible change date for this line as the start date. When determining the date, the system checks whether the date lies in the past and also whether payment scheme requests that have already been paid exist after the change date. If you make a change in the sample line that is ready for input, the line that is not ready for input is prorated so that its end date is set to the start date of the change minus one day. At the same time, a new line that is not ready for input is created. This is a copy of the line that you changed. To transfer a change to the payment scheme, you have to choose Transfer Change. Note You can also use various methods of BOR object PAYSCHEME to change a payment scheme.
Page 13 of 58
The date on which the customer has to pay the payment scheme amount for the current sample line for the first time. The current sample line is determined using the system date. The start date of the sample line lies before the system date and the end date lies after the system date.
Next Due Date Payment Scheme Status 00 Active 01 Inactive The payment scheme was set to inactive when it was created and has not yet been activated. No statistical requests are generated when the payment scheme has this status. 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.
02 Cancelled
12 Inactive and Cancelled 03 Deactivated The payment scheme was either ended with automatic account maintenance, or an interim/periodic bill with an end date within the billing period was created for a cancelled payment scheme.
13 Inactive and Deactivated Payment Scheme Start Date Next Interim Reassessment Invoicing Division Alternative Payment Date If the Minimum Number of Days Between Creation/Change Date and First Payment Date defined in the Define Control Parameters for Payment Scheme table (TE637) is exceeded when a payment scheme is created or changed, an alternative first due date is determined for the relevant sample line. Page 14 of 58 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.
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. The final amount that the customer must pay on the next due date. It is determined from extrapolation and from the transferred items. 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:
Description Defines as of when a sample line is valid. 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. The gross amount that the customer has to pay.
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 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 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. Active 01 Adjusted During Periodic Bill 02 Adjusted During Interim Bill 03 Inactive 04 Print Document Reversed Page 15 of 58
Change Status
The payment scheme category is defined in the Payment Scheme Category table and is allocated to the sample line.
This field displays the portion of the amount to be paid that comes from the transferred open items.
Total Items Included in Payment Scheme Total Amount from Extrapolation Due Date of Last Request Number of Sample Line Document Number Main Transaction Subtransaction Changed On By Created On Created By Budget Billing Plan Contract* Company Code Contract Account* Current Remaining Bill Amount Portion of Open Items GK Alternative Payment Date
This field displays the total amount of all open items included in the payment scheme for the corresponding sample line. This field displays the gross amount determined from extrapolation plus taxes. This field displays the most recently generated payment scheme request (without taking the factory calendar into account)* This fields displays the consecutive internal number of the sample line.* This field displays the document number of the most recently generated payment scheme request.* This field displays the FI-CA main transaction of the payment scheme requests.* This field displays the FI-CA subtransaction of the payment scheme requests.* This field displays the most recent change to the sample line.^^ This field displays the name of the person that last changed the sample line. The field displays the creation date of the sample line. This field displays the name of the person who created the sample line. This field displays the payment scheme number.*
This field displays the company code for which the payment scheme was created.*
Do not copy this field to the display as it is only relevant internally. This field displays the portion of the total bill amount that was determined for the selected sample line.* This field displays the grouping key for the tax determination code for budget billing plans.* 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. This field displays the reason for deactivating a sample line: Deactivation Due to Manual Change (Only valid for inactive lines) 1 Deactivation Due to Move-Out 2 Deactivation Due to Reversal of Move-Out 3 Deactivation Due to Basic Data Changes 4 Deactivation Due to Amount Change Page 16 of 58
Deactivation Status
5 Deactivation Due to Termination of Payment Scheme No.Prev.SL Billing Document Number This field displays the number of the previous sample line.* 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.* This field displays the number of invoicing document that triggerred the adjustments to the sample line. 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. This field displays the reason for creating the FI-CA document. At the moment, this field can only have the value 1 Move-Out.* This field displays the number of the print document that caused the full deactivation of a sample line when is was created.*
* - It is not necessary to include these fields in the display. Keep the display screen as consice as possible. Choose Payment Details to display the payment data, the first due date, the payment frequency, and the amount to be paid. Choose Payment History to display an overview of the total amount to be paid. Changes to individual sample lines are included in the display.
Page 17 of 58
Recovery rate for a long remaining period You use this recovery rate if more than 62.5 percent of all due dates in the billing period lie between the start of the adjustment and the planned end of the current billing date.
Recovery rate for a medium remaining period You use this recovery rate if more than 37.5 percent and not more than 62.5 percent of all due dates in the billing period lie between the start of the adjustment and the planned end of the current billing date. Page 18 of 58
Recovery rate for a short remaining period You use this recovery rate if no more than 37.5 percent of all due dates in the billing period lie between the start of the adjustment and the planned end of the current billing date.
You can choose between the following values for each of the recovery rates: Completely Partially None
In addition to the payment scheme amount being adjusted due to a changed extrapolation amount, it can also change during creation of an interim bill. This is because of the open items that are transferred to the payment scheme: All open items that are the result of account maintenance, transfer posting, and requests with invoicing, and that are processed in invoicing are transferred by the system to event Transfer of Open Items During Invoicing (R415). You can use this event to exclude certain items from being transferred. As default, all items are transferred to the payment scheme. The system does not transfer open items from the recently generated consumption billing to event R415. The system divides the sum of all the selected items evenly amongst the payment scheme requests remaining in the periodic billing period.
After an interim billing with a budget billing amount adjustment, the payment scheme amount is made up of the following components: The portion of the bill consisting of credit and receivables items that were transferred to the payment scheme for the most recent periodic bill. The portion of the bill consisting of credit and receivables items that were newly transferred to the payment scheme for the current interim bill. The new extrapolation amount.
The first two bill portions are always listed together in the payment scheme.
6.1.1. Adjusting the Payment Scheme for Interim Bill with Recover Rate Completely
The system adjusts the payment scheme sample lines so that excess consumption or underconsumption from the interim billing period as against the consumption from the original extrapolation is completely divided amongst the remaining payment scheme due dates (until the next planned interim billing period). The following basic rules apply: The extrapolation period in the interim billing document must correspond exactly to the extrapolation period of the most recent interim bill or the period used for extrapolation when the payment scheme was created. This ensures that any seasonal rate variations are taken into account. All payments that are to be made within the current interim billing period are subtracted from the extrapolation amount (net amount plus VAT). It does not matter whether the payments have actually been made, or whether the payment scheme requests are still unpaid. Payment scheme requests are only taken into account if the due date lies within the billing period. The portion used for clearing transferred open items is not taken into account when subtracting the payments. The portion remaining from the extrapolation amount is divided evenly amongst the payment scheme due dates remaining until the end of the current periodic billing period.
Page 19 of 58
The following examples are based on the assumption the all Recovery Rates are assigned the value Completely. The following applies for all examples: You create a periodic bill for a customer on 1 January. For the periodic billing period 1 January until 31 December, the system determines an extrapolation amount of 600. You also transfer open items to the value of 180 to the payment scheme. In the payment scheme, the payment frequency is monthly and the th payment date is the 20 of each month. The system determines the payment scheme amount to be 65. This includes an extrapolation portion of 50 and a clearing portion of 15 for the transferred items. st You execute an interim billing for the customer on 1 July. The payment scheme amount is adjusted when this billing is invoiced. Example 1 The customer has paid all payment scheme requests on time up to and including the month of June. st During creation of the interim billing document, extrapolation is executed for the period January 1 to st December 31 . The result of this is 600. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 600 (6 * 50) = 300
st st st
Open due dates until the end of the periodic billing period: 6 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15.
New payment scheme amount: 15 + (300 / 6) = 65 Example 2 The customer has paid all payment scheme requests on time up to and including the month of June. During creation of the interim billing document, extrapolation is executed for the period January 1st to st December 31 . The result of this is 750. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 750 (6 * 50) = 450
Open due dates until the end of the periodic billing period: 6 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15.
New payment scheme amount: 15 + (450/ 6) = 90 Example 3 The customer has paid all payment scheme requests on time up to and including the month of June. st During creation of the interim billing document, extrapolation is executed for the period January 1 to st December 31 . The result of this is 450. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 450 (6 * 50) = 150
Open due dates until the end of the periodic billing period: 6 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15.
Page 20 of 58
The customer has paid all payment scheme requests on time up to and including the month of May. Payment for the month of June has not yet been made (payment overdue). During creation of the interim st st billing document, extrapolation is executed for the period January 1 to December 31 . The result of this is 750. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 750 (5 * 50 + 1 * 50) = 450 Even though payment has not been made for the month of June, the payment scheme amount is adjusted as if payment had been made. This is because you assume that the customer will still pay. Open due dates until the end of the periodic billing period: 6 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (450 / 6) = 90 Example 5 The customer has paid all payment scheme requests on time up to and including the month of June. He has also paid the payment scheme request for the month of July as he will be on vacation at that time. During creation of the interim billing document, extrapolation is executed for the period January 1st to st December 31 . The result of this is 750. An additional credit item of 50 is added to the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 750 (6 * 50 + 1 * 50) = 400 Since the customer has already made payment for the month of July, this month is taken into account when determining the new extrapolation amount: This has the effect that the amount for July is also deducted from the extrapolation amount. It also means that the due date for July is no longer taken into account for the payment scheme adjustment. Open due dates until the end of the periodic billing period: 5 Since an additional credit item of 50 is added to the payment scheme, the bill portion of the payment scheme amount changes to 15 + (-50/5) = 5. New payment scheme amount: 5 + (400 / 5) = 85
Example 6 On March 1 the customer informs you of an increase in expected consumption, which in turn results in a th higher monthly payment scheme amount. As of March 20 the amount increases to 80 (65 consumption and 15 transferred items). th On May 17 the customer requests to change the payment frequency from monthly to fortnightly. This th th change is to take effect on August 15 with August 18 as the first payment date. th On June 7 the customer wants to make another change to the payment frequency. Starting from st th November 1 , he wants to change the payment frequency to quarterly and have November 20 as the first payment day. All payment scheme requests up to and including the month of June have been paid on time. st During creation of the interim billing document, extrapolation is executed for the period January 1 to st December 31 . The result of this is 900. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 900 (2 * 50 + 4 * 65) = 540
st
Note that the extrapolation portion of the payment scheme amount was increased to 65 as of March. Open due dates until the end of the periodic billing period: Page 21 of 58
1 with monthly payment frequency 6 with fortnightly payment frequency 1 with quarterly payment frequency Since no additional open items are added to the payment scheme, the bill amount to be divided for st st the period July 1 to December 31 remains at 90. Therefore, the full amount to be divided amongst the remaining payment scheme requests is 540 + 90 = 630 In order to be able to divide this amount between the remaining due dates, the dates are first converted so they all have the same payment frequency (weekly, for example). This results in the following: Monthly 4,3 weeks (52 / 12) Fortnightly 2 weeks Quarterly - 13 weeks (52 / 4) If you add together all the end values you get a period of 29.3 weeks over which to divide the amount of 630. This results in a weekly amount of 21.50. Using the number of weeks for each payment frequency, the following payment scheme amounts can be determined for the different payment frequencies: Monthly - 4.3 * 21.5 = 92.45 Fortnightly - 2 * 21.5 = 43.00 Quarterly - 13 * 21.5 = 279.55 Example 7 The interim bill created on July 1 is based on an estimation. Therefore, it does not result in a change to the payment scheme amount. th On November 25 the customer provides you with an actual meter reading. You carry out an unplanned interim billing with adjustment to the payment scheme amount. During creation of the billing document, st st extrapolation is executed for the period January 1 to December 31 . The result of this is an extrapolation amount of 750. All payment scheme requests up to and including the month of November have been paid on time. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 750 (11 * 50) = 200
st
Open due dates until the end of the periodic billing period: 1 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (200 / 1) = 215 Caution The payment scheme amount has more than trebled. Therefore, you must define amount/percentage limits for the payment scheme amount adjustment.
6.1.2. Adjusting the Payment Scheme for Interim Bill with Recover Rate Partially
Page 22 of 58
With recovery rate Partially, the excess consumption and underconsumption from the interim billing period are only partially divided amongst the remaining payment scheme due dates. The extrapolation amount is divided using the following basic rules: The extrapolation period in the interim billing document corresponds exactly to the extrapolation period used for the most recent interim bill or that was used for extrapolation when the payment scheme was created. This ensures that any seasonal variations in the rate are also taken into account for extrapolation in the interim bill. The calculated extrapolation amount (new amount plus tax) E is split into two parts, E und E . EA is the extrapolation portion for the period from the end of the billing period of the most recent periodic bill to the end of the interim billing period. B E is the extrapolation portion for the period from the end of the interim billing period to the end of the current periodic billing period. A B The division of E into E and E takes place linearly based on the number of payment scheme due dates within the two periods. A All payment scheme requests are subtracted from extrapolation portion E . The same conditions A apply as with adjustment with recovery rate Completely. The resulting amount E is then split into A1 A2 two further parts, E and E . First of all the number of payment scheme due dates is determined A1 A starting from the end of the interim billing period. The relationship between E and E corresponds to the relationship between the number of payment scheme due dates between the end of the interim billing period and the and of the current periodic billing period and the total number of payment scheme due dates in one year. In order for any changes in the payment frequency to be taken into account, all of the payment schemes frequencies are converted into one weekly frequency according to a specific key. The sum of E and E is then divided evenly amongst the payment scheme due dates remaining until the end of the current periodic billing period.
B A1 A B
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 1 . For the periodic billing period 1 January until 31 December, the system determines an extrapolation amount of 600. Open items to the value of 180 are included in the payment scheme. In the payment scheme, the payment frequency is monthly and the payment date is the 20 of each month. The payment scheme amount is 65. This includes an extrapolation portion of 50 and a clearing portion of 15 for the transferred items. You execute an interim billing for the customer on 1 July. The payment scheme amount is adjusted when this billing is invoiced.
...
st
st
st
th
st
Example 1 The customer has paid all payment scheme requests on time up to and including the month of June. st During creation of the interim billing document, extrapolation is executed for the period January 1 to st December 31 . The result of this is 600. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: The extrapolation amount is split into two parts: A E = 300 B E = 300 The portion of E that the customer has not yet paid (E ) is EA = 300 (6*50) = 0. A A1 A2 E is split into two parts E = 0 and E = 0. The extrapolation portion still to be divided is 300 + 0 = 300. Open due dates until the end of the periodic billing period: 6 Page 23 of 58
A A
Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (300 / 6) = 65 Example 2
The customer has paid all payment scheme requests on time up to and including the month of June. st During creation of the interim billing document, extrapolation is executed for the period January 1 to st December 31 . The result of this is 750. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: The extrapolation amount is split into two parts: A E = 375 B E = 375 The portion of E that the customer has not yet paid (EA) is E = 375 (6*50) = 75 A A1 A2 E is split into two parts E = 37.5 and E = 37.5. The extrapolation amount still to be divided is 375 +37.5 = 412.5. Open due dates until the end of the periodic billing period: 6 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (412,5 / 6) = 83,75 Example 3 The interim bill created on 1 July is based on an estimation. Therefore, it does not result in a change to the payment scheme amount. On November 25 the customer provides you with an actual meter reading. You carry out an unplanned interim billing with adjustment to the payment scheme amount. During creation of the billing document, st st extrapolation is executed for the period January 1 to December 31 . The result of this is an extrapolation amount of 750. The customer has paid all payment scheme requests on time up to and including the month of June. No additional items should now be added to the payment scheme. The payment scheme amount is adjusted as follows: The extrapolation amount is split into two parts: A E = 750 * (11/12) = 687.50 B E = 750 * (1/12) = 62.50 The portion of E that the customer has not yet paid (E ) is E = 687.5 (11*50) = 137.5 EA is split into two parts EA1 = 11.46 and EA2 = 126.04 The extrapolation amount still to be divided is 62.50 + 11.46 = 73.96 Open due dates until the end of the periodic billing period: 1 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (73.96 / 1) = 88.96
A A A th st A A
6.1.3. Adjust Payment Scheme for Interim Bill with No Recover Rate
Page 24 of 58
Excess consumption or underconsumption within the interim billing period is not taken into account. When dividing the extrapolation amount (net amount plus tax), the system uses the following basic rules: The extrapolation period in the interim billing document must correspond exactly to the extrapolation period used for the most recent interim bill or that was used for extrapolation when the payment scheme was created. This ensures that any seasonal rate variations are also taken into account for extrapolation in the interim bill. The calculated extrapolation amount (new amount plus tax) E is split into two parts, E und E . EA is the extrapolation portion for the period from the end of the billing period of the most recent periodic bill to the end of the interim billing period B E is the extrapolation portion for the period from the end of the interim billing period to the end of the current periodic billing period. A B The division of E into E and E takes place linearly based on the number of payment scheme due dates within the two periods. The amount E is divided evenly amongst the payment scheme due dates remaining until the end of the current periodic billing period.
B A B
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 1 . For the periodic billing period 1 January until 31 December, the system determines an extrapolation amount of 600. Open items to the value of 180 are transferred to the payment scheme. In the payment scheme, the payment frequency is monthly and the payment date is the 20 of each month. The payment scheme amount is 65. This includes an extrapolation portion of 50 and a clearing portion of 15 for the transferred items. Example 1 You execute an interim billing for the customer on 1st April. The payment scheme amount is adjusted when this billing is invoiced. During creation of the interim billing document, extrapolation is executed for st st the period January 1 to December 31 . The result of this is 750. The customer has paid all payment scheme requests on time up to and including the month of June. No additional items should now be added to the payment scheme. Since more than 75 percent of the payment scheme due dates from the current periodic billing period are in the future, the recovery rate for a long remaining period (Completely) is used to adjust the payment scheme. The payment scheme amount is adjusted as follows: Extrapolation amount to be divided: 750 (3 * 50) = 600
th st st st
Open due dates until the end of the periodic billing period: 9 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. Page 25 of 58
You execute an interim billing for the customer on 1 June. The payment scheme amount is adjusted when this billing is invoiced. During creation of the interim billing document, extrapolation is executed for st st the period January 1 to December 31 . The result of this is 750. The customer has paid all payment scheme requests on time up to and including the month of June. No additional items should now be added to the payment scheme. Since 50 percent of the payment scheme due dates from the current periodic billing period are in the future, the recovery rate for a medium remaining period (Partially) is used to adjust the payment scheme. The payment scheme amount is adjusted as follows: The extrapolation amount is split into two parts: A E = 375 B E = 375 The portion of E that the customer has not yet paid (E ) is E = 375 (6*50) = 75 A A1 A2 E is split into two parts E = 37.50 and E = 37.50. The extrapolation amount still to be divided is 375 +37.5 = 412.5. Open due dates until the end of the periodic billing period: 6 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (412.5 / 6) = 83.75 Example 3 On June 1 you execute an interim billing for the customer based on an estimated meter reading result. This does not result in an adjustment to the payment scheme. On November 25 the customer provides you with an actual meter reading. You carry out an unplanned interim billing with adjustment to the payment scheme amount. During creation of the billing document, st st extrapolation is executed for the period January 1 to December 31 . The result of this is an extrapolation amount of 750. The customer has paid all payment scheme requests on time up to and including the month of November. No additional items should now be added to the payment scheme. Since less than 37.5 percent of the payment scheme due dates from the current periodic billing period are in the future, the recovery rate for a short remaining period (None) is used to adjust the payment scheme. The payment scheme amount is adjusted as follows: The extrapolation amount is split into two parts: A E = 687.50 B E = 62.50 The extrapolation amount still to be divided is 62.50 Open due dates until the end of the periodic billing period: 1 Since no additional open items are added to the payment scheme, the bill portion of the payment scheme amount remains unchanged at 15. New payment scheme amount: 15 + (62.5 / 1) = 77.5
th st A A A
st
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 1 . The payment scheme to be adjusted has a monthly th payment frequency and with the payment date on the 20 of each month. The extrapolation for the period January 1 to December 31 results in a gross amount of 600. The following items are transferred to the payment scheme: Additional payment of current periodic bill: 90 Account maintenance 30 Request with invoicing: 100 - 40 The full amount transferred to the payment scheme is 180.
st st st
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.
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.
Transaction EA65PS is used to create statistical requests for each payment scheme that belongs to one of the selected contract accounts and that meets the following conditions: The payment scheme must be active at the time of selection. When the selection is made the end date of the payment scheme must come after the system date. The payment scheme must have the status Active and not the status Inactive. On the selection date, the payment scheme must have at least one sample line with an end date that comes after the selection date. The sample line must be active and also have at least one due date within the validity period.
If a payment scheme meets these conditions, a statistical FI-CA document is created, containing a separate open item for each due date. The type of the document is determined from posting area R300 (Maintain Settings for Budget Billing Plan). The source of the document is RO (IS-U PS Request). The individual open items of the document are formed based on the valid payment scheme sample lines for each due date. The start date for creating the sample lines is always the same as the system date. The system checks whether requests for the payment schemes already exist after this date. The start date is changed if necessary. The following section describes the most important fields and how the field values are determined for an open item: Due Date The due date is determined from the first due date and the payment frequency. You define the first due date in the sample lines for which you create the requests. If a different first payment date is defined in the sample line, this date is used. Page 28 of 58
If you have defined a correction for non-working days using the factory calendar in the period characteristics of the portion master data for the contract, this is taken into account when the due date is determined. If the due date (not using the factory calendar) lies after the Create Before date, processing of the payment scheme is terminated and no open item is created for this due date. Business Partner, Contract Account, Contract, Main Transaction, Subtransaction, Currency: This data is copied from the sample lines to the open items. General Ledger Account The general ledger account is determined dynamically from posting area R007 during runtime. Amount and Tax Amount The amount of the open item is copied from the relevant sample line. Since this is a gross amount, the tax amount is calculated based on the tax determination code taken from the extrapolation document and defined in the sample line during creation of the statistical request. Any tax changes that occur between the creation of the payment scheme or creation of the last periodic/interval bill and the creation of the statistical payment scheme requests are taken into account. However, the gross amount remains unchanged. There is also a mass activity for creating payment scheme requests. You can find this in the Utilities Industry menu under Invoicing Budget Billing Plan Payment Scheme Create Mass Activities for Payment Scheme Requests (transaction EA66PS). If certain settings are made in the Payment Scheme Category table (TE638), you cannot use EA65PS or EA66PS to create statistical requests for certain payment schemes. For these payment schemes, the requests are created automatically when the periodic/interval bill is created.
Page 29 of 58
maintenance. You can either refund the customer directly or settle the excess payment in the next consumption billing. Note When a payment scheme is ended, automatic account maintenance only takes place if the end date is the same as the current date. You cannot cancel this process.
Page 31 of 58
9. Customizing
9.1. Customizing in IS-U
The following sections describe the individual tables available in Customizing: Unless specifically mentioned, you can find the tables in Customizing for SAP Utilities under Invoicing Budget Billing Plan Payment Scheme. .
Page 32 of 58
You use this recovery rate if more than 62.5 percent of all due dates in the billing period lie between the start of the adjustment and the planned end of the current billing date. Recovery Rate (Medium Remaining Period) Rec.Rate (M): You use this recovery rate if more than 37.5 percent and no more than 62.5 percent of all due dates in the billing period lie between the start of the adjustment and the planned end of the current billing date. Recovery Rate (Short Remaining Period) Rec.Rate (S): You use this recovery rate if no more than 37.5 percent of all due dates in the billing period lie between the start of the adjustment and the planned end of the current billing date. For each of these periods, you can specify whether the full amount, part of the interim bill amount, or no amount is taken into account when the payment scheme is adjusted for the interim bill. Print Payment Scheme In this area, you can define a form for each of the processes Create Payment Scheme and Change Payment Scheme.
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.
...
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.
1. Define External Main Transactions and Subtransactions In the first step you define the main transactions and the subtransactions fot the payment scheme. Page 35 of 58
The tables FI-CA Main Transactions and FI-CA Subtransactions are available for this purpose. You can find these tables in Customizing for Financial Accounting under Contract Accounts Receivable and Payable Basic Functions Postings and Documents Document Maintain Document Assignments Maintain Main Transactions or Maintain Subtransactions. Example
Ext. Main Transaction 1053 Description Budget billing procedure: payment scheme Comment 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. Main Transaction 1053 0010 0110 Ext. Subtransaction Description Budget Billing: Payment Scheme Budget Billing Payment 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. Comment This entry is used to define the budget billing procedure
0120
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 MTran. 0053 0010 STran. Description Budget Billing: Payment Scheme Budget Billing Payment MTran. 1053 0010 External Transactions STran. Description Budget Billing Procedure: Payment Scheme Budget Billing Payment
Table 9.3: Example of Allocating External Main and Subtransactions to Internal Tranactions When you allocate the external transactions to the internal main and subtransactions, make sure that the external subtransactions for Extrapolation Budget Billing Plan Credit and Debit (1053/0110 und 1053/0120 in the example) are not allocated to internal transactions.
Page 36 of 58
3. Maintaining the transaction attributes For all posting transactions, you must maintain the transaction attributes (credit/debit indicator) in table Transactions for Company Code and Division (TE305) for every division and every company code. You do this in Customizing for Financial Accounting under Contract Accouns Receivable and Payable Basic Functions Postings and Documents Document Maintain Document Assignments Maintain Transactions for Industry-Specific Component Utilities Maintain Transactions for Budget Billing. Example
Co.Code 0001 Divisio n 01 Ext. MTran. 1053 Ext. STran. 0110 0120 Description Extrapolation Budget Billing Plan (Credit) Extrapolation Budget Billing Plan (Debit) Debit/Credit Indicator H 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 R R Ext. MTran. 1053 1053 Ext. STran. 0110 0120 Description Extrapolation Budget Billing Plan (Credit) Extrapolation Budget Billing Plan (Debit) Debit/Credit Indicator H 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 0001 Divisio n 01 Account Determination ID 01 Ext. Main Transaction 1053 Ext. Subtransacti on 0110 Account Number 0000170060
5. Allocate payments to payment scheme requests You allocate payment scheme payments to statisitcal payment scheme requests in posting area R007 using transaction FQC0 or in Customizing for Financial Accounting under Contract Accounts Receivable and Payable Basic Functions Posting and Documents Define Account Assignments for Automatic Postings Define Account Assignments for Down Payments and Charges. For each budget billing request transaction, define a corresponding payment transaction and the clearing restriction R (items relevant for payment scheme). You only have to create entries for debit subtransactions as the payment scheme does not support credit subtransactions. As the payment scheme standard also only supports debit subtransactions, the table should only contain one entry that is relevant to the payment scheme. Set the statistical key to A and the clearing restriciton to R. Example
Statistica l Key Ext. Main Transaction for Statistical Request 1053 Ext. Subtransactio n for Statistical Request 0120 Ext. Main Transactio n for Payment 1053 Ext. Subtransacti on for Payment 0010 Clearing Restriction Payment Lock Reason
6. Maintain a document type for the external main transaction for the payment scheme. In this case for main transaction 1053. Youdo this in positng area R300 in Customizing for Financial Accounting under Contract Accounts Receivable and Payable Basic Functions Postings and Documents Document Maintain Document Assignments Document Types Maintain Default Document Types for Budget Billing. If you do not do this, you cannot create any statistical payment scheme requests.
Page 38 of 58
1. Copy the sample function module provided by SAP for the event in question. All events provided by SAP follow the naming convention ISU_SAMPLE_<Number of Event>. If a function module is available for this event as standard, it is mentioned in the documentation for the sample function module. Your function module always overrides the standard. 2. Enter the necessary coding in your function module. 3. In table Installation-Specific Function Modules (TFKFBC), create a new entry with the following values: Application Area: R - Event: <Number of Event> - No.: Sequence number starting with 0 - Active Module: Name of copied function module In order to avoid inconsistencies in the system, you cannot use the following language elements in the events: COMMIT WORK ROLLBACK WORK CALL FUNCTION 'DEQUEUE ALL Deletion of locks that you did not set yourself
Before you create an event with its own program logic, read the documentation for the sample function module. This contains important information on parameters and possible standards for the event.
10.1. Determining the Extrapolation Period for the Payment Scheme (R510)
You use event R510 to determine the start and end date of the extrapolation period for creating the payment scheme. The system uses parameter X_OBJ-EP_PERIOD to determine the process from which the budget billing extrapolation is called: M Manual creation of payment scheme(EA61PS) E Move-in
The standard function module for this event is Determine Extrapolation Period for Payment Scheme (ISU_GET_EXTRAPOLAT_PERIOD_R510). In this function module, the start date is always set to the start date of the billing period for which the payment scheme is created. Exception: If the move-in date comes after the start date of the billing period. In this case, the start date of the extrapolation period is set to the same as the move-in date. The end date of the extrapolation period is always the same as the end date of the billing period. If you define your own extrapolation period in this event, it does not have any effect on the billing period. This means that if you change the extrapolation period to a full year, for example, the resulting amount is still only divided amongst the payment scheme requests remaining in the current billing period. Page 39 of 58
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.
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.
In this event, the payment scheme is adjusted during creation of a periodic or interim bill. The event is called during the invoicing run: For each optional contract - Individually For each mandatory contract For all payment schemes together
If you have defined event Determine Payment Scheme Sample Lines from Billing Document (R511) so that more than one active sample line can be created for each payment scheme, you have to adjust event R513 accordingly as the flow logic is based on the assumption that only one active sampleline exists. The standard function module for this event is Adjust Payment Scheme for Periodic/Interim Billing (ISU_ADJUST_PAYMENTSCHEME_R513). The following processing steps are carried out: Joint processing for adjustments during interim and periodic billing The date on which the adjustment to the payment scheme sample line is to take place is transferred to the event. The transfer parameter is X_CHG_DATE. If the customer, for whom the payment schemes are being adjusted pays by direct debit or standing order, the minimum number of days defined in Customizing must come between the adjustment date and the next payment date. If the number of days is lower than this number, the payment scheme is adjustment on the day after the payment date. No such check is made if the customer pays by cash. Adjustment for interim bill First the system checks whether the payment scheme needs to be adjusted. If the interim billing is scheduled, set the corresponding indicator in the meter reading unit. If it is not scheduled, specify this when you create the meter reading order. The sample line that is valid on the adjustment date is prorated. This means that its end date is the same as the adjustment date plus one day. A new sample line is created with a start date that is the same as the adjustment date. The extrapolation portion of the new sample line amount is adjusted according to the new extrapolation amount determined in billing. If payments were made for due dates in the extrapolation period using the old payment scheme amount, this is taken into account when determining the new amount. The system subtracts the sum of the paid due dates from the extrapolation amount and then divides the resulting amount by the number of remaining due dates. If sample lines that are not yet valid exist for a payment scheme, they are also adjusted. Proration is not necessary. All newly created, prorated, and changed sample lines are stored temporarily in an internal table. This table contains the following data: EABP: Payment scheme header data ABRVORG: Time of adjustment (01 = Periodic Bill, 02 = Interim Bill) EABPLS_DB: All active payment scheme sample lines as they currently exist in the database EABPLS_CRT: All new sample lines created during adjustment. These lines also contain the value RC (line created during adjustment) in the POTYP field EABPLS_CHG: All changed sample lines created during adjustement. These lines also contain the value RU (line changed during adjustment) in the POTYP field Before event Check Amount/Percentage Limits for Payment Scheme Adjustement (R514) is called, all entries from EABPLS_CRT and EABPLS_CHG are copied to structure EABPLS_ADJ for each payment scheme. This is because you only make changes to this structure in event R514. Also read the documentation for event R514. All lines that are not adjusted as a result of the checks executed in event R514 are removed from tables ..._CRT and ..._CHG. The contents of the internal table are copied to transfer parameter YT_PS_ADJUST. Adjustment for periodic bill
Page 41 of 58
For a periodic bill, the sample line that is valid on the adjustment date is prorated. This is because a new bill amount is used in the new billing period. As a result, the consumption bill portion of the total amount always changes, even if the total amount is not adjusted due to limits not being reached or being exceeded. The extrapolation portion of the payment scheme amount is determined using the same method as for adjustment for the interim bill. However, the bill portion is also added to the resulting amount. This portion is determined from the bill amount transferred to the new billing period. The amount is divided by the number of remaining due dates. In addition to the payment scheme amount, the fields BETRWBILLTOT and BETRWBILLACT are also updated in the new sample line. The system enters the bill amount transferred to the new billing period in both of these fields. If sample lines that are not yet valid exist for a payment scheme, the are also adjusted. Proration is not necessary. All newly created, prorated, and changed sample lines are stored temporarily in an internal table. This table has the same structure as described above. However, the POTYP field contains the following indicators: Newly Created Lines RC: Line created during adjustment MC: Line needs to be adjusted, as the bill portion of the due amount is higher than the previous total due amount. This is a result of the consumption bill that was transferred to the billing period. However, it was specified in the corresponding sample line that this due date should not be adjusted for adjustment for interim/periodic bills. Therefore, the total amount is increased to the amount of the bill portion so that at least the bill amount is cleared with this sample line. Changed Lines RU: Line changed during adjustment MU: Same meaning as MC Before event R514 is called, all entries from EABPLS_CRT and EABPLS_CHG are copied to structure EABPLS_ADJ for each payment scheme. This is because you only make changes to this structure in event R514. Also read the documentation for event R514. All lines that are not adjusted as a result of the checks executed in event R514 remain unchanged in that the total amount of the payment scheme due date does not change. However, it is possible that the bill portion of this amount is adjusted. For lines that are not adjusted and that have a bill portion of the total amount that is higher than the total amount itself, the bill portion amount is changed to the same as the total amount. This means that these lines no longer have an extrapolation portion. The contents of the internal table are copied to transfer parameter YT_PS_ADJUST.
If you want to define your own program logic for event R512, see the documentation for function module Adjust Payment Scheme for Periodic/Interim Billing (ISU_ADJUST_PAYMENTSCHEME_R513), which describes the individual transfer parameters in detail.
Page 42 of 58
Bill, 02 = Interim Bill), currency, payment frequency, and payment scheme category, the new sample line amount is accepted. The check takes place for the payment scheme lines in transfer parameter XYT_PS_ADJUSTEABPLS_ADJ that were transferred to the event. The following comparisons are made depending on the values in field EABPLS_ADJ-POTYP: POTYP = "RC" or "MC": A new sample line The amount is compared with the direct predecessor. It is determined using the end date, which is one day before the start date of the new sample line. MC means that the sample line is new and that it was created during creation of a periodic bill. This line needs to be adjusted, as the bill portion of the due amount is higher than the previous total due amount. This is a result of the consumption bill that was transferred to the billing period. However, it was specified in the corresponding sample line that this due date should not be adjusted for adjustment for interim/periodic bills. Therefore, the total amount was increased to the amount of the bill portion so that at least the bill amount is cleared with this sample line. These lines are treated as adjustment lines as standard. You can however define your own program logic so that these lines are handled differently. POTYP = "RU" or "MU": An updated sample line The amount of the changed sample line is compared with the amount before the change took place. You can find the amount before the change in table EABPLS_DB. The system checks the new and adjusted sample lines to determine whether the change lies within the percentage limits defined in table TE558. If it does lie within these limits, the system then checks the amount limits. In lines for which these checks are unsuccessful, the field EABPLS_ADJ-POTYP is reset to its initial value. If you defined event R513 yourself, but you do not want to make any changes in event R514, you must take this processing logic into account in your programming. Before you define your own program logic for event R514, read the documentation for function module Amount/Percentage Limits for Payment Scheme Adjustment (ISU_CHECK_PS_ADJUST_R514).
Page 43 of 58
Page 44 of 58
days before or after the end of the period. If a payment scheme has a quarterly payment frequency, this limit is 30 days. For a monthly payment frequency the limit is 16 days.
10.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.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.
If you want to use event R530, you have to define your own check logic.
In event R415, you determine which items to transfer to the payment scheme during an invoicing run. You can remove items that the system has proposed for transfer. If you do not use this event, items that result from the following processes and that are part of the current invoicing run are transferred to the payment scheme as standard: Interim bill: Account maintenance Transfer posting Request with invoicing Periodic bill Current consumption billing Account maintenance Transfer posting Request with invoicing
Page 48 of 58
Method Find ExistenceCheck Create Display Edit Terminate Activate SampleLineChange BasicDataChange OpenItemRollinOut SingleLineValidation CompleteReassesValidation Find object Existence of object
Description
Payment scheme: Create Payment scheme: Display Payment scheme: Change Payment scheme: End Payment scheme: Activate Payment scheme: Change sample lines Payment scheme: Change basic data Payment scheme: Include open items Payment scheme: Validate change to sample line Payment scheme: Validate payment scheme adjustment
Table 11.1: Methods for BOR Object PAYSCHEME The BOR object provides the methods listed in table 13.1. You execute the Display and Edit methods in the Display (EA62PS) and Change (EA63PS) transactions. The Create and Terminate methods can run in the background, as well as in transactions EA61PS and E61PSD. The Create method is instance-independent. It requires the following transfer parameters: Number of the contract, for which a payment scheme is to be created Desired start date First payment date Payment frequency Indicator, to show whether or not the payment scheme is to be created as active
If you start the Create method in the background, you can no longer access the creation process. Therefore, if the system cannot create a payment scheme using the transfer data supplied, it terminates the method immediately and issues an error message. This can be the case if a new payment scheme is to be created for an existing mandatory group, and the basic data transferred for Payment Date and Payment Frequency is no longer consistent with that of the existing payment scheme in the mandatory group. The remaining methods are instance-dependent. This means that an instance of the object PayScheme must exist with correctly maintained key fields. You can only call the Activate, SampleLineChange, Page 49 of 58
BasicDataChange, OpenItemRollinOut, SingleLineValidation and CompleteReassessValidation methods within a background process. The Activate method activates a specified payment scheme on a particular payment date. You can use the SampleLineChange method to change the amount due and the change status of a single sample line as of a certain time (until the end of the line). The BasicDataChange method changes the basic data (payment date, payment frequency and payment scheme category) for a payment scheme, as of a certain date. A change of this type affects both the whole mandatory group of the selected payment scheme, and all sample lines as of the selected change date. You can use OpenItemRollinOut to select qualified, open receivable items or credit items, and to distribute these over the open due dates for the current period. The SingleLineValidation and CompleteReassessValidation methods control the changes made. You can use SingleLineValidation to check whether the change to an amount for a single sample line lies within the predefined limit values. The CompleteReassesValidation method executes these checks for a complete payment scheme, with all its sample lines. You can use tables TE558 or TE560 to determine the permitted limit values. The following events are available for the PayScheme BOR object: PaymentScheme.CREATED PaymentScheme.CHANGED PaymentScheme.TERMINATED PaymentScheme.ACTIVATED PaymentScheme.REASSESSFAILED Payment scheme created Payment scheme changed Payment scheme ended Payment scheme was activated Amount limits were not adhered to during adjustment
Page 50 of 58
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 VKONTO BEGPERIODE KZABSVER Business partner number Contract account number Start of payment scheme period Budget billing procedure (if not maintained, then determined from contract account) Status of payment scheme (can also be empty if active) Contract Currency End of payment scheme period (if empty, then the value 31.12.9999 is entered) X X X X
X X X 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 51 of 58
Example Sample line 1 BEGDAT 01.01.2001 ENDDAT 31.01.2001 Sample line 2 BEGDAT 01.01.2002 ENDDAT 31.12.9999
The following table gives you an overview of the individual fields, which you must maintain for the sample lines: Field Name VERTRAG TVORG GRBBP BEGDAT BETRWBILL PAYFREQ Explanation Contract Subtransaction VAT determination indicator Start date of sample line Consumption billing portion of payment scheme amount Payment frequency: W Weekly F - Fortnightly M Monthly Q Quarterly Y - Yearly 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. Payment scheme category Transferred values must belong to the values that you defined in TE638. 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. Mandatory X X X X X X Optional
PAYDATE
PSTYPE
ENDDAT
Table 12.2: Data to be Migrated from Sample Lines for a Payment Scheme
Page 52 of 58
Description Header data for budget billing plan Line data for payment scheme Internal table for generation of payment scheme requests Header data for payment scheme requests Line data for payment scheme requests
Table 13.1: Database Tables for Payment Scheme You use the FI-CA archiving object FI_MKKDOC to archive payment scheme requests. The event Document Archiving: Check Header Data (0500) ensures that a minimum retention period of 6 months is adhered to. This guarantees that it is possible to reverse the corresponding payment document in a certain period. The IS-U object data is archived using the IS-U archiving object for budget billing plans (ISU_BBP), according to the rules implemented there. This is explained in greater detail in the Archiving section. You use the Archive Administration transaction (SARA) to execute archiving. You can use transaction ESARA04 to call this transaction directly for the ISU_BBP archiving object. You can find the archiving of budget billing plans in the area menu for the utilities industry, under Tools Data Archiving Invoicing.
13.1. Archiving
Budget billing plan archiving consists of the following steps:
...
1. Analysis Run The following figure, and the accompanying explanations, describe the process flow of the analysis run.
Page 53 of 58
1
Selection of header data for deactivated payment schemes (CPS)
EABP
nein
3
CPS deactivated by account maintenance ? No Yes
Yes
EABPARCH
No
Log output
4
No Autom. start of archiving program?
Figure 13.1: Payment Scheme Archiving Analysis Run Explanations for analysis run: a. Selection of header data for deactivated payment schemes You can only deactivate a payment scheme if it is no longer used productively (it has been deactivated). This happens within the following processes: A payment scheme is stopped, and is then deactivated within a periodic bill / interim bill A payment scheme is stopped using automatic account maintenance A payment scheme is stopped due to a move-out, and deactivated during creation of the final bill b. Is associated header data from the print document archived? If you have deactivated a payment scheme within a periodic / interim bill or final bill, you can only archive it if the corresponding header data from the print document (archiving object ISU_PRDOCH) has been archived. This is necessary because the print document can still be cancelled until it is completely archived. Because reversing the print document also results in the payment scheme being reactivated, you cannot yet archive the payment scheme.
Page 54 of 58
c. CPS deactivated by account maintenance You can also deactivate a payment scheme by executing an automatic account maintenance when stopping the payment scheme. In this case, you can archive the payment scheme immediately, as it is no longer possible to use a cancellation to reactivate the payment scheme. d. Automatic start of archiving run When starting the analysis run, you can determine whether the archiving run is to be started immediately after the analysis run. You determine this in the selection screen for the corresponding program. When using the SARA transaction to schedule the corresponding job you must proceed as follows: When creating the variant of the analysis program, set the indicator Start Archiving Automatically in the selection screen of the analysis program. Create a variant for the archiving program with the same name as for the analysis program. Caution: You must define the same selection conditions for document number and contract account for both variants. Schedule the job for the archiving program with the start date After Event. Enter SAP_ISU_ARC_BBP_ANALYSE_END as the event. The event parameter is the variant name, with which the corresponding analysis program is started. Caution: Write the variant name in upper case. 2. Archiving The following process flow diagram displays the process flow for the archiving run:
EABPARCH
no
3
no Autom. start of delete prog. selected? yes
CPS archive file
Read CPS data from archive file and delete corresponding data from database
Write protocol
Page 55 of 58
Figure 13.2: Payment Scheme Archiving Archiving Run Explanations for archiving run: The deletion program is either started automatically after the generation of the archive file, or manually, depending on the settings made in Customizing for the ISU_BBP archiving object. In the first case, this can mean that the deletion program for a closed archive file runs parallel to an archiving run in which more than one archive file is generated. 3. Deleting archived data Only those data records that have been successfully written in an archive file are deleted from the corresponding database tables. The system ensures that no data is deleted, that has not yet been written in an archive file, but that has the appropriate status. 4. Reloading an archive run You can only reload complete data from an archive run. You cannot reload individual data records. Caution Only use the Reload function if an archiving run / deletion run has been executed with the wrong parameters, thus meaning that incorrect data has been archived / deleted. Under no circumstances should the Reload function be a component of a business process.
You can also use transaction EA63PS to display archived payment schemes: In the initial screen for the transaction, you can use Budget Billing Plan from Archive to go to the selection screen of the archive information structure for the ISU_BBP archiving object. The information structure SAP_ISU_BBP is delivered as default for the ISU_BBP archiving object. You can enter the desired selection parameters, such as the contract account, in the selection screen. The system displays a list with all payment schemes that correspond to the selection criteria and exist in the information structure. Double-click on a payment scheme to display this payment scheme in transaction EA63PS. Caution To use transaction EA63PS, the following conditions must have been met: The archiving development kit (ADK) must have access to the appropriate archive files. At least one information structure must be active for the SAP_ISU_BBP catalog supplied by SAP. The SAP_ISU_BBP structure is delivered as default. You can activate this structure in Customizing for SAP Utilities, under Tools Archiving Activate Info Structures for Archiving.
Page 57 of 58
14. Appendix
14.1. Relevant Transactions
EA61PS Create payment scheme EA62PS Change payment scheme EA63PS Display payment scheme E61PSD End payment scheme EA65PS Create payment scheme requests EA66PS Mass activity for creating payment scheme requests
Page 58 of 58