RTP billing

The billing of interval-related data (profiles) is called real time pricing billing (RTP billing). RTP billing allows you to define rates and prices freely across intervals and therefore enables you to structure contracts that are required in a deregulated energy market more freely.

RTP billing is based on rate models that evaluate energy requirements over a period of time. Consumption (and demand if necessary) are measured for each interval (for example 15/30/60 minutes) or for each rate period (for example peak and off-peak). The price for kWh of consumption, or kW/kWA demand is determined for every interval. This means the price may vary for every interval.

You can use RTP billing to calculate time-of-use pricing models and RTP models. You can define prices in advance or adjust prices to the spot price defined by the energy market.

Time-of-use pricing models are time-based. This means that prices are determined based on time groups.

RTP models are quantity-based. This means that prices are determined based on agreed reference quantities.

In the RTP billing, an important aspect is data storage which is done through profile management. Unlike standard billing where the meter readings are done once in a month/2 months or quarter, in RTP billing the consumption values are updated every 15/30 or 60 minutes. So we need to store and maintain this data differently, for which sap has provided profiles management.
Let's start by creating profile type.

After creating profile type, we need to set up interval length. We can assign more than one interval length to the profile type.

For profile type 89 that we created, we have assigned 15, 30 and 60 minutes intervals.

Next step is to create profile version. This is important because after creating profiles and adding values to it, if any change has been made, then historical values are stored as versions. For example we have got 60 minutes interval values for consumption as 5 KWH. Now if the data has been corrected for an interval as 7 KWH, there is a version created automatically, enabling us to know which values were created from original which values.

And that's why we select "always create" option so the system would always create a version whenever there is change made to the values.

Using transaction eedm06, we now create profile header. As per below, profile 171 has been created.

Once the values for 60 minutes intervals are downloaded, the profile looks like this. We have selected this profile for 30 days period which means that for 30 days, every 60 minutes data is stored in this profile.

Now let's change a couple of values manually and see if profile versions are created. In this case, we changed values for 2 intervals. These values 10 and 15 are highlighted when we select version from the top menu.

This completes the data storage process using profiles.

Next let's look at how complex billing is performed.

In regular billing, we maintain certain values at the device (registers) and devices are attached to the installation and thus those values are used for billing. But for RTP billing, that is not possible because we have to maintain values in profiles. That's why RTP interface has been created.

The RTP interface is a data object that links the Energy Data Management (IS-U-EDM) and Contract Billing (IS-U-BI) components.

The RTP interface enables us to use the profiles maintained in IS-U-EDM in IS-U billing. In order to this, we allocate the RTP interface to the rate used for billing an interval meter.

In the RTP interface we can execute billing-relevant processing steps carried out based on profiles. For example, we can process billing agreements for periods as small as 15/30/60 minutes. The results from such processing steps are then transferred to the rate steps in the rate. Billing lines can then be created from the rate steps.

So in order to bill based on time intervals, let's start setting up day group and day type.

And now let's set up TOU(Time of USE) types and groups.

And created On Peak, Mid Peak and Off peak TOU types.

And defined time period for each of them. For example, on peak time is set as 8 am to 6 pm.

Next, let's create TOU group and assign all 3 TOU types that we created earlier to this group.

Next step is to define RTP component.

And assign TOU group that we created to this RTP component.

And activate this component by clicking the "generate component code" icon in the top menu.

Next step is to define RTP interface.

Now we need to update information on all 3 tabs showing on the top menu. Below is the details we need to update on HDR tab.

Now the result parameter tab.

And on the RTP component tab

And once RTP interface is defined, then enter it while creating rate using transaction EA30

Travis Thomson page

The contents on this page has been contributed by my colleague and dear friend Travis Thomson, based on his experience in working with SAP ISU billing situations. Thank you Travis!

Things that we need to check when there is CMO (Change meter order) on the account

When there is a CMO, a 21 install in read MUST be the NEXT DAY in SAP after the 22 removal out read. If the device removal is June 4th in SAP, then the new install must be June 5th in SAP. An exception around this is if the 22 out read also happens to be an 03 move out. If it is an 03 move out, then the 21 install more than 1 day later is acceptable provided it is also an 06 move in.

In the case where there is a 22 removal, and 21 install with a gap of more than 1 day (in most cases I have seen it be just a couple weeks or couple months) it must first be determined whether or not the service should continue in that customer's name. Once determined, there are two routes:

A.) Have the CMO removed completely from SAP and re-entered with the correct dates according to field and account notes

B.) If the agent has clearance to do so, simply make the CMO 22 date a move out, ending that contract for the customer and make the CMO 21 a move in, which will start a new contract for that customer. This can be done in the IC Web "front end" (CRM)in the end contracts and moves/transfer screens, and is very straight forward. Make a special note to waive the start up fee if going this route, as the customer will be charged incorrectly since it is technically not a brand new service, just a new contract number. This is the faster route which is likely more suitable for urgent escalations that require immediate resolution. I personally have not ever seen this error occur without a CMO being involved.

While processing customer accounts for TOU billing, we regularly send BQ requests to obtain valid and billable readings. Some of the scenarios that may not allow BQ requests to go through successfully are listed below.

Things to we need to check if BQ requests fail

For sent BQ requests that do not show in a BQ table there are several unique variables that come into play and in my experience, 99% of the time have to do with make up of the MROs. I will list all the common examples I have encountered to the best of my memory that causes this problem.

A.) BQ for a CMO (22) will not send -- This is because the CMO 22 is not a move out, or there are no periodic MROs listed after it. If the CMO 22 is a service termination, creating a periodic MRO after it will allow BQ to send, but will not fulfill it properly. In this case, a move out date must be applied to the CMO 22 date and then send BQ (end the contract on the same date as meter removal date). It should fulfill fine, if not data repair is needed, which is a separate issue.

B.) There are multiple MROs (multiple allocations) for one period. For example 09, 11, 16, 13, 18, etc, and 01 exists for a scheduled MR date. -- This is because in addition to periodic billing period MRO, any other allocation is there, BQ will not request and if it does, there is no status or response. It must be determined which MRO is required in importance and the other should be removed using EL37, or nullified in EL29 or EL28.

C.) There are multiple move outs and move ins on the same installation. SAP will request BQ for the newer periods, but not some of the older ones -- In this case, when requesting the BQ, change your latest date to the last date that is not sending. For example, if you are requesting from January 1st 2014 to January 1st 2015, but BQ is only sending from April 1st 2014 and skipping the earlier months, simply make your latest date April 1st when sending BQR (using transaction ZBQR) and it should send.

D.) All the dates for the MROs are there and OK, with no duplicates or visible anomalies but it still won't send -- It is very likely that this is some kind of deeper defect or there are billing/invoicing documents you have not accounted for which are blocking the BQR. In cases like this, you have not actually created the MROs, only checked them and tried to send a BQR. Reverse the documents and try again.

If it is not the documents, it may be the device install which is prompted by a clarification case typically asking for some price change MROs missing. (normally 30-04-2012)

If it is not the clarification case, it may still have to do with devices. If your CMO dates are incorrect, it will cause an error in requesting. The table may request only some dates and not others, so if there are multiple CMOs on the installation (and some a even very close together) make sure to check the 21 in and 22 out dates. You cannot have a 22 out after a 21 in unless it is 2 days later in SAP. For example, if there is a 22 meter out on May 1st, and new meter installed 21 is on May 2nd, the next plausible date for a 22 meter out has to be May 4th or later.

To summarize, when BQ request does not go through, it is mostly due to very general and very variable MRO situations where something is missing, there are two many of something, a date was requested too early (before earliest device) or too late (in the future and we haven't got there yet like requesting May 2015)