£215 per month direct debit?!!

Terrylw1

victor2 wrote: »

Thanks!
Clearly a complex process.
Still would like to think that suppliers use a customer's actual history to forecast usage. Maybe some do even if our friends at EDF don't...

Historically you will find that suppliers ignored this industry data and just used their own systems and your readings to do everything. This is largely due to deregulation introducing new procedures and from my experience suppliers were not prepared for such changes. A lot of this prior to then was managed by the meter reader side of the business and the supplier was more an office of admin staff.

Its true in the cases I know of, suppliers would use your readings but not pass them on to their Data Collector, hence supply staff would often believe their consumption to be more accurate. However, it doesn't have the weather calculation outside of seasonal, whereas the industry one is using weather stations.

But...there has been a shift. Over the past 6-7 years, Elexon have been kicking suppliers about this lack of coherence with the industry bill. It should after all match. This industry billing is after all far more advanced and regulated. Supplier systems are up to them.

This difference between what you pay and what they are settling on has been sizeable. You're talking in the hundreds of millions range!

So, when you upgrade from a 30 year old system to a new language like SAP, do you replicate the old basic system...or do you try and close this gap by "bolting on" to the industry process. I can only speak from experience but I know the industry data is being incorporated and it comes with risks. Sometimes you get something called a "Large EAC" or "Large AA" and these values are massive. You have to be careful to error them out or your bill could easily be x100 what it should be. Some of these can make a domestic site look like it is/will use 10,000,000kwh a year! These have to be backed out by new values

So, industry data is a very complex area. You will find that its reserved for the most advanced specialists on the supplier end. The Data Collectors work with it more hence more of their staff work with it.

Terrylw1

jalexa wrote: »

Well that's clear, thanks. Moving on....

From your link found a possibly useful document about EAC/AA. Help it's 73 pages. I may be gone some time:D.

http://www.elexon.co.uk/wp-content/uploads/2011/10/eac_aa_urs_v11.0.pdf

A few simple questions. If a customer submits Customer Own Reads to a supplier (hey, now I'm speaking the lingo:)), is it optional or mandatory for the supplier to validate the readings? Are validated CORs recorded by the industry system as if they were data collector readings? How often and in what circumstances does the supplier receive an updated EAC?

You'll be setting up your own consultancy soon!...;):D

The first thing to remember is that industry validation is only performed by the Data Collector as they are the only party that creates the EAC/AA data & transmits it. The supplier only validates it to decide if they want to use it for billing. The supplier then sends it onto their Data Collector, who performs validation against current EAC/AA data, and sends the reading back plus an additional data flow with the EAC/AA data.

So, the key steps are 1) the suppliers sends it to the DC and 2) the DC validates it thus producing a copy showing as V for validated and the seperate EAC/AA data. Now, the DC could fail it hence the supplier gets a copy of the reading back marked as F for failed. At this point the supplier should go back to them to get it set to V. Only a V triggers the replacement of EAC/AA data in the DC system and the resulting data sent to the required parties (supplier and the Data Aggregator). Since suppliers cared less or misunderstood the importance of keeping what the customer pays inline with what the supplier pays, it was common for a supplier to ignore this validation with a COR and only care that they have produced their bill. Now Elexon are setting industry standards, suppliers are understanding how much they have been losing by not keeping the DC inline with supplier consumption.

So, if its validated to V by the DC, it created an AA thus adjusting the EAC and a copy of this sent to the supplier to ensure they understand it, and a copy sent to the Data Aggregator. The DA is another agent performing tolerance & data matching checks to flag missing consumption periods, high or negative consumption as set down in the Large EAC/AA policy by Elexon, ensures the DC matches to the distributors data on the meter set up, etc.

Terrylw1

jalexa wrote: »

Well that's clear, thanks. Moving on....

From your link found a possibly useful document about EAC/AA. Help it's 73 pages. I may be gone some time:D.

http://www.elexon.co.uk/wp-content/uploads/2011/10/eac_aa_urs_v11.0.pdf

A few simple questions. If a customer submits Customer Own Reads to a supplier (hey, now I'm speaking the lingo:)), is it optional or mandatory for the supplier to validate the readings? Are validated CORs recorded by the industry system as if they were data collector readings? How often and in what circumstances does the supplier receive an updated EAC?

EAC's are produced to cover the forward period and must always be in place. The Data Aggregator flags any period not covered by the EAC to the supplier to contact the Data Collector to get one generated. AA's of course occur between reads so do not always cover the period an EAC does. The DA uses the AA data in producing the data to the distributor to allow them to create Distribution Use of System (DUoS) charges, what the supplier pays. The EAC is used to cover periods where there is no AA (e.g. after the last firm reading getting V validated) and for future forecasting of settling values.

Scenarios then:

- Change of Supply (CoS) = a switch
- Change of Agent (CoA) = where you are supplied and the supplier contracts a new Data Collector which causes the same process as a CoS in terms of agent processes, except there is no supplier & distributor comms other than to update the distributor with a record of the new DC id. So, you don't see any of this
- a meter change where the timings change e.g. standard to E7. However, its actually when your Standard Settlement Code (SSC) changes which can occur on recertification if the Meter Operator prefers a certain SSC. So, you can't see this easily without checking the SSC unless you went through a change in meter timings. It can also occur on a meter payment type change e.g. PPM to credit, because not all meters support these changes without selecting a new SSC. The supplier sends the EAC to the DC who passes it into the DA plus back to the supplier
- new connections for conversions and new builds. Again, the supplier provides the EAC
- Change of Measurement Class (CoMC) which is a change from non half hourly metering to half hourly or vice versa. This is for large business users though. This process is similar to the Logical disconnection process mentioned below since a new MPAN is created and the old one becomes Logically disconnected
- Change of Profile Class (CoPC) which is more business market where their Maximum Demand changes. For domestics, it only ever happens where a customer changes from E7 to standard without a physical meter change, as long as its available to do this change in Elexon's Market Domain Data (MDD), but some suppliers don't understand this complex area. The supplier provides an initial EAC
- data corrections cause EAC/AA's to be recalculated e.g. the EAC was too high. This area is slightly more complicated since you can only do this in the live non crystallised period of 14 months. After this data is "settled" hence paid to the distributor and you have to send a "negative AA" in the current 14 month period for the adjustment - effectively a credit. So these negatives back to be kept out of current EAC/AA calculations for obvious reasons, but they have industry standard complex software for this...suppliers don't! Data corrections just mean sending new values with dates that overlap the dates of the errors
- energisation changes = removing or refitting the meter fuse. Not to be confused with a meter change though which is a more complex event in terms of data. With these an old EAC may overlap into a period of deenergisation (no meter fuse) but energisation, just like all, the other events above, create an AA as a reading is needed
- long term vacant site where no reading advance on 2 calls by the meter reader. In this case the supplier sends a zero EAC value to the the DC, who creates the official EAC of zero from it since the DA needs to pass it to the distributor. This process is to save suppliers paying estimates on vacant sites
- any event involving a reading, so all of the above plus COR's, readings collected via PPMIP (PPM payments management agent' reading taken off the key/card whenever a payment is made), manually created or amended readings by Meter Operator or DC to fix a data problem. I think the PPM readings only need to be sent monthly due to the volume hence restricting the EAC/AA calculation as only one reading of X number are sent to the DC
- no reading received from any source within 720 days. The DC creates a reading at 12 months back thus creating an EAC update. This reading would only be based on previous data though

Full disconnection also creates an AA as a final meter reading is required since the meter has been removed, but MPAN disconnection whether Physical (service removed) or Logical (spare, spurious, no longer required, etc - so no site work by the distributor) is a final action since the distributor confirms the MPAN ended.

There are probably more subtleties, plus the Large EAC/AA process Elexon control corrects large errors as mentioned in another post but these can be fixed without readings sin e they can just be caused by internal system errors, again they can be very complicated.

Where the supplier sends the EAC (except the long term vacant one which is always set to zero), they use a value out of a standard list. You find the region, then find the Standard Settlement Code (SSC) and pick the relevant EAC for the start date (since they get updated from time to time and you have to use the one relevant to the date of the change) which is a researched one used as a default for that type of meters settings in its region, this then gets changed as readers are taken.

That doc you found is Elexon's standards. You want to look for the latest version of BSCP504 which explains processing of EAC/AA's in situations like the above, especially CoS as there are strict timescales for customer readings...but suppliers get their DC's to replace readings in the EAC/AA system to match your bills in late cases.

In terms of profiling and use of weather e.g. NET's, this doc is the full Monty version! It also shows the expected customer usage curve through the months. Just select the .pdf's in the Related Content section.

http://www.elexon.co.uk/reference/technical-operations/profiling/

victor2

Think I need a glossary of acronyms to even attempt to understand that lot!
Interesting stuff though, if only to drive home the point that it's a very complex business, going far beyond just charging customers for what they consume.

jalexa

victor2 wrote: »

Interesting stuff though, if only to drive home the point that it's a very complex business, going far beyond just charging customers for what they consume.

Well yes, but it is laid on a plate for the suppliers. All they need to do is work the data flows.

The lack of transparency in "suppliers" projected consumption is a disgrace if available system figures are not used in every payment calculation. Which IMO is required by the relevant SLC which says this "... based on the best and most current information available (or which reasonably ought to be available) to the licensee, including information as to the quantity of gas which the licensee reasonably estimates has been or will be supplied..."

Exactly what the system can provide.

victor2

jalexa wrote: »

The lack of transparency in "suppliers" projected consumption is a disgrace if available system figures are not used in every payment calculation. Which IMO is required by the relevant SLC which says this "... based on the best and most current information available (or which reasonably ought to be available) to the licensee, including information as to the quantity of gas which the licensee reasonably estimates has been or will be supplied..."

Absolutely.
No excuse for those suppliers that fail to even explain what they are doing. Sort of job that is ideally suited to computerisation, as there is a mass of data available to analyse....

Terrylw1

jalexa wrote: »

Well yes, but it is laid on a plate for the suppliers. All they need to do is work the data flows.

The lack of transparency in "suppliers" projected consumption is a disgrace if available system figures are not used in every payment calculation. Which IMO is required by the relevant SLC which says this "... based on the best and most current information available (or which reasonably ought to be available) to the licensee, including information as to the quantity of gas which the licensee reasonably estimates has been or will be supplied..."

Exactly what the system can provide.

I think you can also add SLC31A to this for the >12 month periods as well. In 2 places that SLC states that the supplier should detail the quantity supplied to the domestic premises, not what has been billed. So, this clearly means an EAC/AA set of data since thats the industry measure of supply in elec.

It also talks about telling customers about any estimates used in the calculation...which a supplier can't easily see since its in the Data Collectors systems.

Now, I very much doubt a supplier would have displayed EAC/AA style data but if they are utilising this data in their new SAP billing systems, who's to say they don't use it for this SLC? This is also means that your actual bill for 12 previous months may not even match the projection.

So, its a minefield.

Add to this the fact that SAP isn't always bespoke, some of its "off the peg" from Australia & India, and we don't know how far these goes into each supplier.

Terrylw1

victor2 wrote: »

Absolutely.
No excuse for those suppliers that fail to even explain what they are doing. Sort of job that is ideally suited to computerisation, as there is a mass of data available to analyse....

That's kind of the problem, there are so many variables, many of which are in an agents seperate system, its impossible to fully design and it requires rejection reports for someone to investigate.

One of the big issues has always been the quality of data suppliers get from their agents. Its well known that agents have caused lots of data problems in the industry, just like suppliers, so automation only goes so far. A lot of this comes from privatisation of the agent market because you no longer have the regional custodians as you did before deregulation.

Savannah31

I've had a similar issue.ive paid them £131 a month, only been with them since December and they say my outstanding balance is £600 despite me paying each month. I feel I made the wrong decision leaving Eon.