ISU Assess Workflow to Re Estimate Previous Billed Meter Readings

1,925 views

Published on

ISU Assess Workflow to Re Estimate Previous Billed Meter Readings
http://wp.me/p1Ci5j-cK
Assessing refers to the automatic handling of meter overflows due to over-estimated previous meter readings.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,925
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
77
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ISU Assess Workflow to Re Estimate Previous Billed Meter Readings

  1. 1. ISU Assess: Workflow to Re-Estimate Previous Meter Readings Well, this post is on Assessing. Had written this long time back but had forgotten to post it. So Assessing refers to the automatic handling of meter overflows due to over-estimated previous meter readings. (SAP terminology, link can be referred here or you can copy the link from below, I am just posting the relevant content in this post) http://help.sap.com/saphelp_erp60_sp/helpdata/en/e3/2c453e659e481a88445b8bf1d5faff/content.ht m Assessing does not deal with meter overflows but with overestimated meter readings. When you have an assessing scenario Standard SAP Triggers the event ASSESSED in the Business object – ISUCONTRCT. This triggers a workflow ISU_ACCESS1. (Provided the event linkages have been set up properly for execution). This workflow reverses the billing and re-estimates the meter reading based on the actual meter reading results. It does the adjustment reversal of the billing document. (I have another long written and not posted blog on adjustment reversal, would be posting that in some time and updating the link here) There were some issues with this workflow earlier (binding issues in the container) which have been fixed now by this note. Note 1531335 - ISU_ASSESS binding definition is incorrect. Also we have an enhancement EDMASSES (IS-U: customer-specific checks for assessments (over- estimation)) to define customer-specific criteria for processing estimations. Some point I would like to make: • Assessing only works for Billing relevant meter readings and not for other type of readings like Control reading (Meter reading reason 10) or Interim reading without Billing (Meter reading reason 09). If you want assessing to work for these meter reading types too then in Customizing ‘Define Technical control Parameters for Meter reading Data Processing’ get that checked.
  2. 2. Customizing entry for Assess for non billable meter reads • Assessing only works within a contract. If there is a change in contract (move in /move out) this workflow won’t get triggered. Now how does the system realize an assessing case? 1. Determination of consumption C1, which occurs between the last actual meter reading result and the current meter reading result. The meter reading results that lie between are ignored. 2. Determination of consumption C2, which occurs between the last actual meter reading result and the last estimated meter reading result. The meter reading results that lie between are ignored. 3. If C2 > C1, an assessing case arises. Function module ISU_EVENT_ASSESSING checks whether assessing is required. Once the workflow has been triggered, the corresponding billing documents are reversed and the relevant meter reading results are re-estimated in function module ISU_ACTION_ASSESSING. I won’t be posting the workflow or the container bindings as there are standard and I haven’t changed anything in them. Let’s move on to the part on how it works. Below are 4 scenarios which I have shown. First scenario: There is an Actual Billed meter reading on 1st Feb and subsequently Estimated Billed meter reading on 1st March and 1st April.
  3. 3. Billed Estimated Reading Now we have an Actual meter reading on 1st May. It would give an error, just press 'Release without Correction' and save.
  4. 4. Actual Meter Reading on 1st May Once this is done we see that the workflow has gone to the last Actual reading on 1st Feb and all Estimated readings after this date have been re-estimated. The Meter reading type been changed to 05 from 03. Now here it re-estimated both the earlier Estimated readings because the Actual reading on 1st May was less than both the Estimated readings. Also the 'Billed' status has been changed to 'Billable'. Adjustment reversal in action.
  5. 5. Assessing done for last 2 readings Second Scenario: If the Actual reading is less than just one of the earlier Estimated readings let's see what happens. Here we have the same scenario as above only the dates have changed. Actual Billed reading on 1st May followed by Estimated Billed reading on 1st June and 1st July. Billed Estimated reading till 1st July With an Actual reading on 1st Aug,
  6. 6. Actual Reading on 1st Aug We see that only the last Estimated Billed reading has been assessed and not the earlier Estimated Billed reading on 1st June. Reason been simple the Actual reading on 1st Aug is less than the Estimated Billed reading on 1st July so only this is the only reading taken into consideration for re-estimation. Assessing done for the last estimated reading Third Scenario : Now let's do another check if the last reading is Actual meter read and the current Actual read is also Actual and less, whether the workflow still triggers or not. So below we see that all readings have been Billed (Status 7)
  7. 7. Billed reading till 1st Aug We now have an Actual Billed reading on 1st Aug at 44 units. Below we have an Actual meter read coming in on 1st Sept of 43 units. This is also released with correction and saved. Actual Meter Read on 1st Sept
  8. 8. We now check if the workflow was triggered. We see that for Actual reads, no re-estimation was done. On the contrary it triggered the case for over flow which is expected as the last Actual reading is more than the current Actual reading. Current status of meter reads Fourth Scenario: Now we have Billed reading till 1st Oct with the reading on this date as an Estimated Billed reading. Current meter reading till 1st Oct We enter an Actual reading on 1st Nov which is less than the earlier Actual Billed reading on 1st Sept.
  9. 9. Actual Meter Read on 1st Nov As expected it’s not taken as a case of assessing but as a case of overflow. Meter Overflow So I hope I was able to clarify on how the workflow is working. I had a few links to help me which I have posted earlier and some updated ones are below. Post on Adjustment reversal will be coming up soon. (Hopefully fingers crossed). If anything is wrong above or any clarifications are needed please do comment or ping me. :) http://help.sap.com/saphelp_erp60/helpdata/en/35/f5683835cfc745e10000009b38f8cf/content.htm http://scn.sap.com/thread/1500204

×