This is one topic which cannot be summed up in a single post.

So this post is kind of

abstract post which would talk about the general terminology. Subsequent post shall
take up each topic and possibly showcase a demo. Nothing more can supplement
the help.sap site. The below text is just a summation of whatever you read in the link.
A utility company usually bills its services at the end of a supply period. This can be
periodic billing or even annual billing. With the high utility bills customer can generate
even paying the periodic bills takes time for the customers, causing the execution run
of dunning and installment plans. But the utility firm needs cash to maintain its current
business so it can switch to Budget Billing amounts instead of the amount the
customer is expected to owe, so that the utilitys liquidity is maintained. The basis of
Budget Billing is the Budget Billing plan which sets the due dates and the Budget
Billing amounts.

The system can automatically create Budget Billing plans during invoicing or
move-in processing. However, one can create them manually too.

Contracts that have to be invoiced together (joint invoicing) are assigned a

common Budget Billing plan. All other contracts in the contract account can have
their own separate Budget Billing plan. Budget billing amounts can be stored either
as down payments (statistical receivables) or as partial bills (debit entries)
in Contract Accounts Receivable and Payable and are therefore subject to all
dunning and payment procedures.

There are 4 Budget Billing Procedures as mentioned and explained below.

1.
Statistical Procedure
2.

Debit Entry Procedure (Partial Bills)

3.

Payment Plan Procedure

4.

Payment Scheme Procedure

First a bit on the categories of Budget Billing. IS-U/CCS supports Average Monthly
Billing (AMB) and Budget Billing Procedure (BBP) as special budget billing categories
applicable to North America.
In Budget Billing, an average amount is determined either through simulation or
manually. The customer pays that average amount for a period of 12 months. At the
same time, the customers actual consumption is billed, and the results are printed on
the bill. In addition, the difference between the customers actual consumption and the
average amount is calculated, updated monthly, and printed on the bill. In the last
month of the meter reading period, the actual amount and the accumulated difference
are billed.

In Average Monthly Billing, the customer is charged an average amount based on

billings over the last x months (we can define the number of months, including
minimum and maximum number of months, in Customizing). In addition, the
customers actual consumption is billed, and the results are printed on the bill. The
amounts due for later months are calculated using the average of the previous monthly
bills, the current bill and the accumulated difference. That difference is updated
monthly and is printed on the bill.
Parameter Records have a special role to play as they along with the portion which
decides on the BB cycle and the due dates. The due dates for the budget billing
amounts are calculated directly from the portion applicable to the contract and from
the parameter record.
The following data is defined:

The length of the budget billing period (a number of months or a year)

The budget billing cycle, meaning the equal distribution of dates over the period
(one or more months)

However, one can override the preset values from the portion either in the budget
billing plan itself or in a contract. While changes made in the budget billing plan take
effect immediately, entries made in the contract do not take effect until the budget
billing plan is created again.
Every parameter record can contain up to 5 budget billing cycles. One can select the
following values:

00: No budget billing amounts are levied

01: Budget billing amounts are levied every month

02: Budget billing amounts are levied every 2 months

03: Budget billing amounts are levied every 3 months

04: Budget billing amounts are levied every 4 months

06: Budget billing amounts are levied every 6 months

12: Annual payer; one budget billing amount is levied.

When we define a budget billing cycle, we must enter the budget billing cycle as well
as the scheduled print date of the budget billing request or the creation of the partial
bill in the BB req./part. bill field.
In the field Months inv.-1st BB, we define the time between the end of the last billing
period and point when the first budget billing amount is levied.
If we want to use the parameter record to create portions with a duration of days, we
need to enter the number of days after the start of this period that we want the first

budget billing item to be calculated in the field Days to Bud. Bill. The system uses this
number of days to calculate the other budget billing items.

Parameter Record

In the portion we have the following fields

BB/Bill Dates (Group Due Date of Budget Billing Items and Bill)
Here, you can define whether you want to group the due date together with the next
budget billing amount or with the next bill.
Dun Due Date (Dun the Last Due Date of a Budget Billing Plan)
This indicator is only used for the statistical budget billing plan procedure. When it is
set, the Cannot Be Dunned in BB Plan field is not set.
Define Budget Billing Cycles
When we select the budget billing cycle, we can specify the number of budget billing
amounts that are charged. If we want to levy budget billing amounts, at least one
permitted budget billing cycle must be set with the number of budget billing amounts.
Budget Billing Cycle
We can define a cycle in the portion as a standard cycle. We can only use budget
billing cycles that are defined in the allocated parameter record. If we do not levy
budget billing amounts, no data is saved in the budget billing data table TE423 (Budget
Billing Dates) when the schedule records of the portion are generated.
If we define more than one cycle, the entries for every cycle are saved in the table
TE423.

Portion

Budget Billing Amount Calculation

The system calculates the budget billing amount on the basis of the expected meter
reading results (Extrapolation). Extrapolation can be based on the following
information: Amounts from the last bill. The extrapolation lines for the budget billing
amounts are generated automatically during periodic billing.

Periodic consumption

Reference value in the rate

Manual specification of the budget billing amounts

The following functions are also available for calculating the budget billing amount:

In the case of an interim billing, one can specify whether the remaining budget
billing amounts are to be adjusted.

1.

In the case of budget billing, one can also perform mass changes.
In case of statistical budget billing procedure, the budget billing amounts are
displayed as a statistical posting (not a posting in general ledger) in the account
balance display.
2. In case of partial bill procedure, the individual amounts are entered as a
receivable on the debit side after the completed partial bill run. The budget
billing amounts are not displayed in the account balance display immediately
after the budget billing plan has been created unlike statistical budget billing.
The budget billing plan is managed for the partial bill procedure in a shadow
table (DFKKMOP and DFKKMOPW). This is not used by FI-CA. After the report
Create Partial Bill (transaction EA11) has been started, the item is posted in FICA (debit entry). This is an actual posting with VAT.

3. In the payment plan, the utility company and the customer decide on the
amount to be paid with each bill. So instead of paying the actual bill amount,
which varies according to season, the customer pays the payment plan amount.
The utility company records the difference between the payment plan amount
and the actual bill amount and charges it at a later date. Depending on the
category to which the payment plan belongs, or depending on the settings in
the contract, the difference amount is reimbursed or charged to the customer
when the payment plan expires or, at the very latest, when the customers
moves out of the premise. Consumption billing must take place for every due
date of the payment plan. Because of this, the payment plan is not comparable
to a statistical budget billing plan or a partial bill, in which the relevant amounts
are charged in between two periodic bills. Also we can only create payment
plans from category BBP. Payment plans from category AMB are not actually
created but are managed as virtual payment plans in the system based on the
start month or alternative start month defined in the contract. When the monthly
bill is created, the payment plan data is evaluated and included in the
calculation of the payment plan amount.

Payment Plan

4. The payment scheme is a statistical budget billing procedure. In this

procedure, the system determines the budget billing amounts to be paid based
on the consumption billing amounts of past and current billing periods, and
distributes these evenly across the next billing period. The system calculates
the budget billing amount from an extrapolated portion, which reflects the
expected consumption for the current billing period, and a known portion from
the copied consumption billing. Point to note is that we can only use the
payment scheme procedure with the Customizing setting Tax Determination in
Billing. We cannot use the payment scheme procedure in combination with
multi-level tax determination (for example, Tax Jurisdication Code). The amount

of a payment scheme item can never be smaller than zero. Therefore, a

payment scheme cannot have a credit subtransaction.
I think this is enough context for subsequent posts on Budget Billing. Coming up would
be posts on each of the Budget Billing procedures. I would be updating the links on
each post as they come up. Also I have missed marking out the
enhancements/Function modules here so would be updating them in the individual
posts as they come up.
Thats it. Enjoy.
So second in the series is Payment Scheme. As always most of the content here is
copied from help.sap. (link is here). So instead of rewriting whats already written, I
would try to present it in the system (maybe).
A little summation on Payment Schemes.
1.
The payment scheme is a statistical budget billing procedure i.e. The amount to
be paid is based on the consumption billing amounts of past and current billing
periods which is prorated across the next billing period.
2.
Payment scheme allows payments in intervals/frequency like Weekly, Monthly,
Quarterly etc. Here the screenshot shows the Frequency as Monthly.

Open Items for Selected Contract

3.

Payment Scheme period is not limited. When a periodic bill is created, the
system does not end the payment scheme but adjusts it. Therefore, if a periodic bill
is late, we can at least charge the customer for the previous budget billing amount.

4.

In addition to consumption billing, we can include/exclude all other credit and

receivables items from the same contract in the payment scheme.

5.
6.

Payment Scheme cannot be used along with Collective Bills.

Payment Scheme has to be created manually either during the move-in
process or via the transaction EA61PS. BOR Object is PAYSCHEME.

Payment Scheme Creation

7.

In Contract Account the Budget Billing Procedure is defined as 4 Payment

Scheme.

Budget Billing Procedure in Contract Account

8.

As with Payment Plan, Payment Schemes can be assigned to one sub

transaction.

9.

Payment Scheme cannot be used in conjunction with Tax Jurisdiction Code as it

doesnt work with multi-level tax determination.

10.
11.
12.

The value of a payment scheme item can never be lower than zero.
We cannot create a payment scheme with a start date that lies in the past.
When a payment scheme is created, a sample line (in tableEABPL) is created
for each contract in addition to the header data (in tableEABP). This line contains
all data relevant to the payment scheme such as amount, payment frequency, first
payment date, and so on. This request data is also determined from the payment
scheme sample lines. They represent the most important connection
betweentheSAP Utilities data and the contract accounts receivable and payable
data in this procedure.

Table EABPL and EABP

13.

The system determines the extrapolation period in eventDefine Extrapolation

Period for the Payment Scheme (R510). In the standard logic provided by SAP, the
system sets the start date of the extrapolation period to the start date of the current
periodic billing period. If the move-in date is within the current billing period, the
system chooses this date. The end date is the same as the end date of the current
billing period. The system uses this data to carry out extrapolation for the contract.

14.

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.
15.
The Payment scheme would be having one of the below status at any point of
time in the system.

Payment Scheme Status

16.

Deactivation reason for Payment Scheme can be due to the below reasons.

Deactivation Reason in Payment Scheme

Payment Scheme adjustment can happen cause of Periodic Billing and Interim Billing.

Change Status of Payment Scheme

Here I am talking about Periodic Billing. For more details on this do look at the link.

So adjusting a Payment Scheme during Creation of a Periodic Bill

17. During creation of the Periodic 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.
17. As part of this adjustment, one can add the receivables and the credit items from
the current consumption billing, as well as other open items that are part of the
current consumption billing, to the payment scheme.
17. With a periodic bill, 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 once the periodic
bill has been created. If we execute the periodic invoicing before the scheduled
date, all existing future payment scheme requests that are due up until the planned
periodic invoicing date are reversed without a follow-on posting.
17. If the customer has already paid budget billing requests with due dates 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.
17. The system marks open items for transfer to the payment scheme and transfers
them to eventTransfer of Open Items during Invoicing (R415). We can also use this
event to exclude certain items from being transferred.

HOW THE EXTRAPOLATION WORKS

A periodic bill is created for a customer on January 1. The payment scheme to be
adjusted has a monthly payment frequency and with the payment date on the 25 th of
each month.
Say the extrapolation for the period January 1 to December 31 results in a gross
amount of EUR 1200.
The following items are transferred to the payment scheme:

Additional payment of current periodic bill: EUR 120

Account maintenance: EUR 40

Request with Invoicing: EUR 80

The full amount transferred to the payment scheme is EUR 240.

Number of open payment scheme requests until the end of the new periodic bill: 12
(from the extrapolation period of 12 months)
After the payment scheme has been adjusted, the new amount is (1200 + 240) / 12 =
EUR 120
From EUR 120, this consists of an extrapolation amount of EUR 100 and open items
transferred to the payment scheme to the value of EUR 20.
22. Once a payment scheme has been adjusted, the system carries out an amount
and percentage limit check of the changed payment scheme sample lines
before the changes are written to the database. This setting is done in
customizing (Table is TE558)
22. The checks take place at contract level regardless of whether the contract is
optional or mandatory. 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.
22. For terminating a Payment Scheme, enter the End date and the Deactivation
reason. Once the end date has been given, the system checks whether payment
scheme requests that have already been paid exist after the end date. If this is the
case, the end date is set to the next due date plus one day. Depending on the
sequence of the end date and the first payment date of the payment scheme, the
system proceeds as follows:
> If the end date is before the first payment date of the payment scheme, the payment
scheme is deleted from the database. If statistical requests for this payment scheme
are already created, they are cleared.
> If the end date is after the first payment date of the payment scheme, the system
executes the following actions:

The payment scheme sample line that is active on the end date is prorated so
that its end date is the same as the end date of the payment scheme. A new
sample line is created for the part of the sample line that comes after the end date.

All payment scheme sample lines with a start date that comes after the end
date are deactivated.

The end date and, if necessary, the deactivation reason are entered in the
payment scheme header data.

All statistical requests with due dates that lie after the end date are cleared.

25. In order to ensure that a payment scheme can no longer be changed, one
must deactivate it once it has ended.

25. Requests with due dates that come after the most recent interim or periodic bill and
that have already been paid are settled against the current consumption billing
when the bill is created.
25. If the interim/periodic bill is reversed, the entire process is cancelled. This means
that the clearing of the paid requests against the transferred items and the current
consumption billing is also reversed.
25. We cannot delete a payment scheme from the system, it can be archived though.
25. Migration Object for Payment Scheme is BBP_PAYSC
25. An important customizing has to be maintained for SAP
Utilities under Invoicing Basic Settings Define Basic Settings for Invoicing,
choose Tax Determination in Billing for the time of tax determination.
The following events are available for the budget billing procedure Payment Scheme.

List of Events in Payment Scheme

Determining the Extrapolation Period for the Payment Scheme (R510)

Determine Payment Scheme Lines from Billing Document (R511)

Determine Budget Billing Amount for Payment Schemes (R512)

Adjust Payment Scheme for Periodic/Interim Bill (R513)

Check Amount/Percentage Limits for Payment Scheme Adjustment (R514)

Selection of Open Items when Creating a Payment Scheme (R515)

End Payment Scheme (R516)

Activate Payment Scheme (R517)

Customer-Specific Checks for First Payment Date (R518)

Customer-Specific Checks for Start Date and Change Date (R519)

Customer-Specific Checks for Creation Status (R520)

Checks for Retaining Payment Periods (R521)

Define Printing Rules for Change/Creation Documents (R522)

Notify Activation of Payment Scheme (R523)

Print Change/Creation Documents (R524)

Adjust Customer-Specific Fields for Payment Scheme (R525)

Amount Limit Warning Ignored (R526)

Customer-Specific Rules for Amount Rounding in the Payment Scheme (R527)

Override Selection of Open Items (R528)

Change Meter Reading Unit During Creation/Change of Payment

Scheme (R529)

Execute Amount Checks (R530)

Automatic Account Maintenance when Payment Scheme is Ended (R531)

Determine Deactivation Reason for Payment Scheme (R532)

Divide Bill End Amount (R533)

Adjust Customer-Specific Tables (R534)

Determine Minimum Number of Days Between Creation Date and Due

Date (R535).

Adjust New Lines (R536)

Suppress Interval Adjustment During Generation of New Lines (R537)

Display and Change Customer-Specific Fields(R538)

Enhancing Display Structures (R539)

Determine Billing Transaction and Document Types of Included Items (R540)

Select Contract Accounting Items for Payment Scheme (R415)

Incl. Items w. Different Tax Codes (R543)

Determination of Tax Code for Requests (R544)

Reactivation of Payment Scheme on Move-Out Reversal (R572)

Below are some screenshots of how the Payment Scheme works in the system. For
now this Contract doesnt have any previous billing history maintained in the system.
So on the date of move-in the Payment Scheme has been activated. For the current

Billing Period extrapolation is done and an Estimated amount of EUR 1 is written down
as shown.

Payment Scheme Created for Selected Contract

The Estimated Billing Document as a result of extrapolation during the creation of

Payment Scheme is shown below.

Estimated Billing Document for Payment Scheme

Below are the screenshots of the Billing line items which show the actual consumption
amount for the current period and the prorated consumption amount for the next billing
period which has the Budget Billing Item checked.

Actual Consumption Billing documents with Payment Scheme

The same is reflected in the Payment Scheme as shown below.

Display Payment Scheme

Payment Scheme would require the End Date and the Deactivation reason as shown
below.

Terminate Payment Scheme

For now this Contract has previous billing history maintained in the system. So when
the Payment Scheme is activated it asks for importing the open items from the
contracts.

Open Items for Selected Contracts

Once Payment Scheme is created the amount is extrapolated for the current period as
well as for the future period.

Payment Scheme for Contract having consumption history

The Estimated Billing document created by the Payment Scheme is shown below and
the subsequent actual consumption Billing Document too.

Estimated billing Document

Actual Consumption Billing Document

There are many scenarios which I have not talked about as they would require more
time to explain, ( but anyways probably later some day) , these can be found out in
the SAP link where they are described in detail.
So first in the series is Payment Plan. As always most of the content here is copied
from help.sap. (link is here). So instead of rewriting whats already written, I would try
to present it in the system.
A little summation on Payment Plans.

1.

In the payment plan, the utility company and the customer decide the amount to
be paid with each bill.

2.

Depending on the settings that have been defined in Customizing, one can
either enter an amount for a predefined period (generally 12 months) in the
payment plan, or can use the previous bills to calculate an average value for the
current bill. The first payment plan can only be valid for a period of less than 12
months.

3.

The budget billing amount is determined in event R950. SAP provides the
following standard function with function module ISU_CALC_PAYPLAN_AMOUNT.
More on this can be read in the documentation of the event.

4.

Depending on the category to which the payment plan belongs, or depending

on the settings in the contract, the difference amount is reimbursed or charged to
the customer when the payment plan expires or, at the very latest, when the
customers moves out of the premise.<scenario>

5.

Consumption billing must take place for every due date of the payment plan.
Because of this, the payment plan is not comparable to a statistical budget billing
plan or a partial bill, in which the relevant amounts are charged in between two
periodic bills.

6.

The allocation of a business partner to a payment plan takes place at contract

level.

7.

Select budget billing procedure 3 in the relevant contract account.

BB Procedure in Contract Account

8.

9.
10.

One can only create payment plans from category BBP. Payment plans from
category AMB are not actually created but are managed as virtual payment plans
in the system based on the start month or alternative start month defined in the
contract. When the monthly bill is created, the payment plan data is evaluated and
included in the calculation of the payment plan amount.
A payment plan item can only ever be assigned to one sub transaction.
The amount of a payment plan item can never be lower than zero. Therefore, a
payment plan item cannot be assigned to a credit sub transaction.

11.

One can only create a payment plan for one monthly budget billing and billing
cycle.

12.

The system uses the billing allocation date from the schedule record of the
portion as the due date for the individual payment plan items. Since this date does
not define the date by which the customer has to pay the amount, the system
displays the bill month.

13.

If its defined in Customizing that no amount is charged in the last month of the
payment plan period, the system creates the item with the amount zero. Its uneditable.

14.

If joint display of payment plans is requested then in the contract that the
payment plan belongs to, the Joint Invoicing indicator must be set to value 1
Contract must be invoiced with other contracts and also the payment plans that you
want to display together must have the same start date.

15.

If we delete the start month from a contract, an existing payment plan for that
contract is ended when the nextinvoicing run takes place.

Payment Plan in Contract

16.

If the invoicing document, in which the payment plan was ended, is reversed,
the end date of the payment plan period is restored to its previous value.

17.

The budget billing-relevant data does not have to be maintained in the

parameter record.

18.

In order to create a payment plan for a contract, the meter reading unit that
belongs to the contract must be allocated to a portion with a monthly billing period.
The payment plan procedure does not work with other billing periods.

19.

Since the payment plan procedure only supports a monthly billing cycle, the
Permitted Budget Billing Date and Budget Billing Cycle fields in the portion are
obsolete and therefore do not need to be maintained.

20.

The fields Combine Due Date of Budget Billing Item and Bill, Type of
Extrapolation for Waste Disposal, and Dun Last Due Date fields are not relevant for
the payment plan procedure and therefore do not need to be maintained.

21.

For a payment plan, the due dates of the individual payment plan items
correspond to the allocation dates of the monthly billings that occur in the payment
plan period. The due date in the payment plan item is only used to allocate the
individual items to their corresponding monthly bills.

22. The following payment plan categories exist (already discussed in a previous post):

Budget billing plan (BBP): As we can see below the Budget Billing Amount is
calculated by the system for the starting payment plan as $105. If this is a new
customer then we need to maintain manual history to define the pattern of
consumption. As shown in the below under Manual History (its down below in this
post) the net amount is $1260 which comes to $105 per month.

Initial Payment Plan

Budget bill amount can be changed for periods which have not been billed.

Change amount in Payment Plan

Now I have executed Invoicing and as we can see in the line items, we habe the actual
consumption amount as $100, the payment plan amount as $105 and the difference
amount as $5. These have different line item types as shown.

Payment plan : BBP line items

In the payment plan display we get the below display after the first invoicing run. The
status becomes green and also we can see the Current difference amount as $5.

First Payment in Initial Payment Plan

Now here we have invoiced for the whole year,as we see all the status has changed to
green, and the Current difference amount is also put back as $0 and put into the
invoice.

Second Payment Plan

Here is the last month invoice when the payment plan culminates, and a new payment
plan starts.

New Payment Plan : BBP

As we see here the new payment plan start and end dates. Once the 2012 payment
plan ends the new one gets created automatically for 2013 when the invoice for
December is executed.

Payment plan created

Now if we check the new payment plan we see a new amount calculated (from the past
12 months consumption history) and the current difference amount set as $0.

New Payment Plan created

Now as has been mentioned in point 17,to end a payment plan we just need to remove
the start month from Contract. Here that was done and we see that the payment plan

has a different end period and the invoice line items just show the consumption
amount.

Ending Payment Plan : BBP

23. Average monthly billing (AMB): In this case we cannot create a payment plan but
can use the transaction to check what the amount is been charged as budget bill
(screenshot below). The changes needed in contract are shown below which is just the
change in payment plan type.

Payment Plan :AMB in Contract

The payment plan mentioned in the contract gets first priority when creating payment
plan, if there is different one used for creation it asks for confirmation. Now $105 is the
amount to be charged in AMB as shown and calculated by the system.

First month payment : AMB

Second Month Payment :AMB

For the next month the amount calculated is $145.

The FM ISU_PAYPLAN_SIMULATE determines the payment plan amount. First the
simulation period is calculated which is defined as the old bill end period and the
number of active bill days.
In this case its (last day of the first period) 01312012 + 30 days = 31 days
ISU_CALC_PAYPLAN_AMOUNT is called. The actual consumption for the first month
is $150.
Minimum days is calculated as 1*30 and maximum days is calculated as 12*30
If simulated days calculated is less than minimum days (30) then error message of
check if enough history is available is given. Here its sufficient. After this the amount is

calculated as actual total amount * min days / simulation days. Its 150*30/31 which
comes to 145.16 after rounding becomes 145.
If data for Payment Plan is already maintained in Contract then that precedes the data
given for creating a payment plan.
24. We use the Adjust Payment Plans Automatically transaction (transaction code
EK93M) to adjust active payment plans that belong to category BBP. We can make a
percentage increase or decrease to payment plan item amounts. However, any items
that have already been requested in a monthly bill, or items whose due date lies after a
move-out date are not adjusted. Event R954 to prevent the adjustment of individual
payment plans can be used.

Adjust Balance Forward Amount

How it works

25. Display Payment Plan: Status of Payment Plan Items

Status (traffic
light)
Meaning

Green
Yellow
Red
Stop sign

Payment plan items that have already been included in an invoicing run.
Payment plan items with a due date that lies in the future.
Payment plan items with a due date that lies in the past.
All items with a due date that lies after the move-out date (for contracts with
a move-out date).

Status of Payment Plan Items

26. Manual History

We use the Manual History transaction (transaction code EK95) to create the manual
history.
When calculating payment plan amounts in the standard version of event R950, the
system only interprets the amount history. If we create a consumption history, it is
necessary to define own functionality for event R950 and, if necessary, event R955.

Maintain Manual History

Manual History

27. The Balance Forward Amount

A utility customer participating in a payment plan procedure does not pay the actual
amount stated in the monthly bill but pays a payment plan amount. This either remains
constant for a one year period (payment plan category BBP), or it varies from month to
month (payment plan category AMB). The difference between the payment plan
amount and the actual bill amount is written to a balance forward amount.
Payment Plan Amount and Balance Forward Amount
The separation of the payment plan amount and balance forward amount to be
requested occurs at document line item level. At this level, the bill line items from the
billing document have been created but not yet posted.
To ensure that the balance forward lines are not prematurely dunned or cleared by a
payment, they are assigned a special clearing restriction (3), a dunning lock, and the
due date 31.12.9999.
28. Adjusting the Balance Forward Amount Manually

The balance forward amount consists of the accumulated difference between the
actual billed amount and the amount defined in the payment plan. This difference can
be positive or negative and can be any value. Therefore, it may necessary to adjust it
under certain circumstances. .
In the Adjust Balance Forward Amount transaction, we can select a contract and enter
a new balance forward amount. We can also enter posting parameters such as posting
date, document type, and reconciliation key.

Depending on whether the new balance forward amount is higher or lower than
the current amount, either the credit items or the receivable items are allocated
clearing restriction 3.

Adjust Balance Forward Amount

A document gets posted which is the sum total of the current differential amount ($15)
and the new difference amount that we would mention.
29. IS Migration Workbench Migration object BBP_EXT.
30. Events
Event R940/End Payment Plan? (ISU_SAMPLE_R940)
Event R951: Check Payment Plan Amount for Current Bill, if Nec. Change or End Pymt
Plan (ISU_SAMPLE_R951)
Event R953: Determine Whether the Payment Plan Amount is Checked
(ISU_SAMPLE_R953)

Event R955: Verify Whether the Payment Plan Amount is to be adjusted

Done . :)