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
thehelp.sapsite. The below text is just a summation of whatever you
read in thelink.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)
inContract Accounts Receivable and Payableand are therefore subject
to all dunning and payment procedures.There are 4 Budget Billing
Procedures as mentioned and explained below.1. Statistical
Procedure2. Debit Entry Procedure (Partial Bills)3. Payment Plan
Procedure4. Payment Scheme ProcedureFirst 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.InBudget 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.InAverage Monthly Billing, the
customer is charged an average amount based on billings over the
lastxmonths (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 theportionapplicable to the contract and
from theparameter 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 theBB req./part. billfield.In
the fieldMonthsinv.-1stBB, 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 fieldDays to Bud. Bill. The
system uses this number of days to calculate the other budget
billing items.
Parameter RecordIn the portion we have the following
fieldsBB/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 CyclesWhen 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 CycleWe
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.
PortionBudget Billing Amount CalculationThe 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 amountsThe 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. In the case of budget billing, one can
also perform mass changes.1. In case ofstatistical budget billing
procedure, the budget billing amounts are displayed as a
statistical posting (not a posting in general ledger) in the
account balance display.0. In case ofpartial 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 FI-CA (debit entry).
This is an actual posting with VAT.0. In thepayment 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 Plan0. Thepayment schemeis 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 isPayment Scheme. As always most of the
content here is copied from help.sap. (link ishere). 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 theconsumption billing amounts of past and
current billing periodswhich 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 Contract3. 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. Payment Scheme cannot be
used along with Collective Bills.6. Payment Scheme has to be
createdmanually either during the move-in process or via the
transaction EA61PS. BOR Object isPAYSCHEME.
Payment Scheme Creation7. In Contract Account the Budget Billing
Procedure is defined as4 Payment Scheme.
Budget Billing Procedure in Contract Account8. 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. The
value of a payment scheme item can never be lower than zero.11.
Wecannot create a payment scheme with a start date that lies in the
past.12. 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 betweentheSAPUtilities data and the contract accounts
receivable and payable data in this procedure.
Table EABPL and EABP13. The system determines the extrapolation
period in eventDefine Extrapolation Period for the Payment
Scheme(R510). In the standard logic provided bySAP, 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 Status16. Deactivation reason for Payment Scheme
can be due to the below reasons.
Deactivation Reason in Payment SchemePayment Scheme adjustment
can happen cause of Periodic Billing and Interim Billing.
Change Status of Payment SchemeHere I am talking about Periodic
Billing. For more details on this do look at thelink.So adjusting a
Payment Scheme during Creation of a Periodic Bill0. 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.1. 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.2. 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 isno longeravailable once the periodic bill has been
created. If we execute the periodic invoicingbeforethe scheduled
date, all existing future payment scheme requests that are due up
until the planned periodic invoicing date are reversedwithouta
follow-on posting.3. 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.4. 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 WORKSA
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 25thof 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 80The 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 120From
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.0. 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)1. The checks
take place atcontract levelregardless 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.2. 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 isbeforethe 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
isafterthe 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.0. In order to ensure that a payment scheme
can no longer be changed, one mustdeactivateit once it has ended.1.
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.2. 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.3. We cannot delete a payment scheme from the system, it
can be archived though.4. Migration Object for Payment Scheme is
BBP_PAYSC5. An important customizing has to be maintained for SAP
UtilitiesunderInvoicingBasic SettingsDefine Basic Settings for
Invoicing, chooseTax Determination in Billingfor the time of tax
determination.The following events are available for the budget
billing procedurePayment 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 ContractThe Estimated
Billing Document as a result of extrapolation during the creation
of Payment Scheme is shown below.
Estimated Billing Document for Payment SchemeBelow 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 SchemeThe same
is reflected in the Payment Scheme as shown below.
Display Payment SchemePayment Scheme would require the End Date
and the Deactivation reason as shown below.
Terminate Payment SchemeFor 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 ContractsOnce 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 historyThe
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 DocumentThere 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 theSAP linkwhere 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 ishere). 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 readin 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.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 Account8. 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.9. A payment plan item can only ever be assigned to one
sub transaction.10. 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 un-editable.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 Contract16. 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 PlanBudget bill amount can be changed for
periods which have not been billed.
Change amount in Payment PlanNow 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 itemsIn 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 PlanNow 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 PlanHere is the last month invoice when the
payment plan culminates, and a new payment plan starts.
New Payment Plan : BBPAs 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 createdNow 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 createdNow 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 : BBP23. 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 ContractThe 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 :AMBFor 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 daysISU_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*30If
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 works25. Display Payment Plan: Status of Payment Plan
ItemsStatus (traffic light)Meaning
GreenPayment plan items that have already been included in an
invoicing run.
YellowPayment plan items with a due date that lies in
thefuture.
RedPayment plan items with a due date that lies in thepast.
Stop signAll items with a due date that liesafterthe move-out
date (for contracts with a move-out date).
Status of Payment Plan Items26. Manual HistoryWe 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 History27. The Balance Forward AmountA 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 AmountThe 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 ManuallyThe
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 AmountA 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. EventsEvent 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 adjustedDone .:)