Budget Billing : Payment plan

Sofirsihsrisis .As wsosofhcohriscopidfroh p.sp.
( ikishr).Soisdofrwriigwh’s rdwri,Iwou droprsiihss.
Likohb ogishp://wp./p1Ci5j-z.
hp://h p.sp.co/rp2005_hp_07/h pd//b/263b483b4f11d35f1000c9303371/co
.h?frs=//b/263b483b4f11d35f1000c9303371/frs.hcurr_oc=//c
4/02693582f4db6010000009b38f889/p i.hod_id=78show_chi dr=f s
A i surizioo s.
1. Ihpp ,hui icopdhcusordcidhouobpidwih
chbi .
2. DpdigohsigshhvbdfidiCusoizig,ocihrr
ouforprdfidpriod(gr 12ohs)ihpp ,orcush
prviousbi soc cu vrgv uforhcurrbi .Thfirspp co
bv idforpriodof ssh12ohs.
3. Thbudgbi igouisdridivR950.SAprovidshfo owigsdrd
fuciowihfucioodu ISU_CALC_AYLAN_AMOUNT.Morohiscbrdhr.
isr ik
4. Dpdigohcgorowhichhpp b ogs,ordpdigohsigsi
hcorc,hdiffrcouisribursdorchrgdohcusorwhh
pp xpirsor,hvr s,whhcusorsovsouofh
pris.scrio
5. Cosupiobi iguskp cforvrdudofhpp .Bcusofhis,h
pp isocoprb osisic budgbi igp orpri bi ,iwhichh
r vousrchrgdibwwopriodicbi s.
6. Th ocioofbusissprropp ksp ccorc v .
7. S cbudgbi igprocdur3ihr vcorcccou.

8. Oco crpp sfrocgorBB.p sfrocgorAMBr
ocu crdburgdsviru pp sihssbsdohsr
ohor rivsrohdfidihcorc.Whhoh bi iscrd,h
pp disv uddic uddihc cu ioofhpp ou.
9. App ico vrbssigdoosubrscio.
10. Thouofpp icvrb owrhzro.Thrfor,pp
icobssigdocrdisubrscio.
11. Oco crpp forooh budgbi igdbi igcc .
sapisurdg.wordpress.com http://wp.me/p1Ci5j-ez

12. Thssusshbi ig ociodfrohschdu rcordofhporioshdu
dforhidividu pp is.Sichisddosodfihdbwhichh
cusorhsophou,hssdisp shbi oh.
13. Ifi’sdfidiCusoizighoouischrgdih sohofhpp
priod,hsscrshiwihhouzro.I’su-dib .
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 next invoicing run takes place.
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):
22.1. 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’ (it’s down below in this post) the net amount is $1260
which comes to $105 per month.

Budget bill amount can be changed for periods which have not been billed.
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.

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

Here is the last month invoice when the payment plan culminates, and a new payment plan starts.
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.
Now if we check the new payment plan we see a new amount calculated (from the past 12 month’s
consumption history) and the current difference amount set as $0.

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.

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

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 it’s 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.
23. 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.

24. Display Payment Plan: Status of Payment Plan Items
Status (traffic
light)
Meaning
Green Payment plan items that have already been included in an invoicing run.
Yellow Payment plan items with a due date that lies in the future.

Red Payment plan items with a due date that lies in the past.
Stop sign All items with a due date that lies after the move-out date (for contracts with a move-out
date).
25. 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.

26. 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. Screenshot given earlier of the invoice
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.
27. 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.
A document gets posted which is the sum total of the current differential amount ($15) and the
new difference amount that we would mention.

28. IS Migration Workbench –Migration object BBP_EXT.
29. 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

Budget Billing : Payment plan

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to Budget Billing : Payment plan

Similar to Budget Billing : Payment plan (20)

More from Rakesh Dasgupta

More from Rakesh Dasgupta (9)

Recently uploaded

Recently uploaded (20)

Budget Billing : Payment plan