SAP for Utilities Discussions
Connect with fellow SAP users to share best practices, troubleshoot challenges, and collaborate on building a sustainable energy future. Join the discussion.
cancel
Showing results for 
Search instead for 
Did you mean: 

IS-U Billing - rounding error

yuvione
Explorer
592

When there is a price change, the entire billing quantity(129.044) is prorated based on the number of days before and after the price change. In the concerned rate we have set the price operand to end of billing period and hence the price is 0.14656 for both the time slices. This time slice of the billing quantity is being forced by SAP standard code.

A is the billing quantity column, B is the Price. C is quantity * price. The difference between F and G in the above calculation is of 1 cent which is causing us issues. Since the price is what we want to use at the end of billing period, we don't want the billing quantity to be time sliced based on the price change. Is there any way to prevent this rounding difference without having to write custom variants? Please provide us with any options to control the split of the time slice through rate configurations. Thank you in advance.

1 REPLY 1

Private_Member_7726
Active Contributor
311

Hi!

No, I believe, is the answer - but you could try to nudge SAP to consider implementing this, because it does look a bit "ridiculous" (and not particularly intelligent... ;)) on the face of it - a "technical" timeslice for the "price change", where there is no actual price value change resulting from the billing... holger.schuett, Product Owner, SAP for Utilities, is asking for feedback for the next SAP for Utilities "Customer connection" project in 2020... 🙂 I do doubt SAP will take this up, because there might be "101 technical reasons" why one can not easily (without rewriting/destabilising huge parts of the whole thing) put this kind of logic in the IS-U billing's "time-slicing machine", but it's worth a try...

Other than that, without having actually tried whether suppression of proration for Quantity alone solves this annoyance,

you don't have to write more than a mere wrapper of QUANTI01 in this case. Custom Function should contain nothing besides calling ISU_QUANTI01 and passing on one to one whole Variant Function Interface, plus handling Exceptions - in other words. It's the easiest and cleanest of the tasks in terms of the resulting code IMO, - when it comes to wading into custom Variant jungle...

Cheers,

Janis