As the Switching Operator, the Data Communications Company (DCC), in their role as the Central Switching Service (CSS) provider, is required to provide a Service Desk to facilitate the resolution of switching data queries (as per Schedule 26 - Switching Service Management).

In the scenario where a Secured Active message is received by the Energy Retail Data Service (ERDS), they will validate the Registration Data held against the published Market Domain Data (MDD) tables which are provided by Elexon. Where invalid data or data combinations are held, the ERDS is unable to process the registration in their systems and returns an exception to CSS. This type of exception is detailed below.

Error Messages

Queries Resolution

Where the CSS provider is unable to resolve queries themselves, the tickets can be designated as second and/or third-line tickets within the Service Desk. This is as per the Central Switching Service (CSS) Service Definition document. The tickets are then passed to the relevant Switching Data Service Provider (SDSP) for them to resolve. The obligations and corresponding service levels related to the resolution of these tickets are set out in ERDS Service Definition document.

Prior to the implementation of faster switching, these types of exceptions were managed between Metering Point Registration Service (MPRS) and Suppliers directly, although they are relatively low-volume exceptions.

Frequently Asked Questions

Why is this exception required? 

Topline information (Profile Class (PC), Meter Time Switch Code (MTC) and Agent Appointment information) is provided by the Supplier to the relevant ERDS. Prior to the implementation of Faster Switching, the Supplier would register the customer providing both Topline data and details of appointed agents to ERDS. ERDS would then validate that information with the MDD and either confirm registration on that basis or provide a rejection to the Supplier. The Supplier would be required to represent the adjusted/corrected information in order to achieve a successful registration of that Metering Point.

The validation of this data is necessary to ensure that Metering Points are settled accurately and is carried out following any update to the Metering configuration. Misaligned or inaccurate data within the Topline or Agent Appointment information can cause Settlement error.

How is the exception currently communicated? 

MPRS is made aware of switching data queries which require a response in accordance with the Service Level Agreement (SLA) in two ways. Firstly, an MPRS application programming interface (API) generates errors upon receipt of CSS data validation failure notifications. Secondly, ServiceNow (SNOW) tickets, raised via the CSS service desk, are assigned to MPRS as second-line tickets. In some cases, Distribution Network Operators (DNOs) are unable to resolve these data errors themselves as further data is required from the Supplier or Metering Equipment Manager (MEM).

Data is sent via the Supplier or MEM to update MPRS which then allows the SecuredActive message to be processed.

MPRS is responsible for holding this data but is not responsible for updating and maintaining it, as only the Supplier/MEM can correct the data. The incidents must be put on hold until the DNOs/IDNOs get an answer from the owner of the data to prevent SLA breaches. As the SLA does not apply to the Supplier/MEM explicitly, there is no pressure on them to provide the data, so the incidents remain in the DNOs/IDNOs queue, with the need for them to chase every few days to prevent the incident failing SLA.

How is this exception resolved? 

Suppliers are required to resubmit corrected data to MPRS, which aligns with MDD tables and is considered valid.

How is this exception impacted by the migration to Marketwide Half Hourly Settlement (MHHS)? 

Some of the data items listed in this exception are being removed as part of the MHHS Migration. In addition to this, the number of valid combinations of these data items will be reduced significantly and this is a factor the Code Manager has considered when attempting to solve this issue.

These exceptions are not in the scope of the MHHS data cleanse activity; however, parties should prioritise this type of exception as this has a direct impact on consumers ability to switch supplier.

How can this exception be managed more effectively?

• This type of exception creates a misalignment between the CSS and the ERDS/Electricity Enquiry Service (EES). As such, this should be rectified as a priority to enable data alignment. The responsibility to resolve and resubmit correct data to resolve this type of exception sits with previous Suppliers and their appointed Agents.
• Parties should cease any raising of SNOW Tickets via the CSS Service Desk for this issue. This will reduce the number of SLA tickets being raised to DNO/IDNOs. In all cases, users should contact the relevant Supplier directly to raise an exception for this issue, requesting the site is investigated. Suppliers themselves should not seek to raise CSS Service Desk tickets for this issue.
• For tickets already raised to the Service Desk, the incidents will be passed over to the relevant Supplier, requesting that relevant data items/registration information is re-submitted to resolve the exception.
• This issue will also be raised to parties via the Balancing and Settlement Code (BSC). There are exceptions raised using the D0235/MM00134 and the D0095/MM00012 which highlight incidents of data misalignment which can create a risk to accurate Settlement.
• Finally, Suppliers should proactively encompass any exceptions of this type (that are not currently going through the Switch process) within Data Cleansing pots identified for investigation prior to MHHS Migration.