Relevant Charging Statement – Version Control

If amendments are made to a DNOs Charging Statement between releases e.g. Indicative Prices and Final Prices, (even if the change is correcting a typo) – if the amendment is not clearly highlighted in the new Statement, we (as an IDNO mirroring the host’s tariffs) could be working on incorrect figures. As a result, we could unintentionally charge more than if the customer was connected to the host DNO, and therefore be in breach of our Charging Methodology and our Licence. This issue would also impact Suppliers and their own tariff calculations.

As an example, in the latest release (EFD 1st October 2010), a DNO published as follows:

• Indicative Prices released 30th June 2010.
• Final prices released 20th August (with indicator that ‘nothing had changed since indicative’ – this
  was actually very helpful)
• Updated Final Charging Statement (where the time zones were altered) released 30th September
  2010 – but with no comment as to whether or not anything had changed.

As that release was silent on any changes that had been made, the time zones changes were missed by ourselves. Also both the 30th June and 30th September releases were recorded as Version 1.0. When we saw that the version number was the same, we did a couple of spot checks on prices and were happy that nothing had changed. It wasn’t until a Supplier phoned us and pointed out that our Charging Statement was not mirroring the DNOs that the changes were identified.

If one of the proposed solutions is not used (or an alternative more effective solution proposed), then it means that each time a DNO releases a Statement, we have to check every page, word by word, figure by figure, to ensure all the details are the same as previously. 14 times for each release potentially. An administrative burden that could easily be rectified with some form of version control.