The Definition for ‘Timestamp’ field in the Common Data Segments is incorrect. It includes a reference to
+/- BST which is not the case. The XML Schema does not need to be updated as they already reflect the
correct definition and structure
Timestamp should be
For information the ‘Interval Period Timestamp’ does include the local time offset
At present there are a number of fields on market messages which have an optionality of ‘D’ (meaning that the particular field is to be sent in certain circumstances.) The criteria for sending these fields are defined in the Message Implementation Guides
To avoid confusion, it is proposed to include these same conditions in the Market Messages Database .
Market Participant Business Ref needs to be a mandatory item on message 260 – Observation of
Problem, Damage or Tampering
Market Participant Business Ref needs to be a optional item on message 261- Resolution of Problem
Damage or Tampering and 311- Meter Problems.
Suppliers wishing to notify ESB Networks of a potential problem at an unmetered site should use the
market messages and processes as defined to support metered sites i.e. MPD 12.
Section 3.1 of this MPD should be updated as follows:
Unmetered reports of problems or damage will be identified at the Technical MPRN level for group
unmetered sites and for single point unmetered. The Technical MPRN will be used as the identifier to
track and process unmetered reports, as the MPRN would be used for a NQH or QH connection. The
same process and market message can be applied to single point and group unmetered process.
MPD 23 – Supplier Data Requests currently allows for the requesting and sending of refresh messages.
These messages are also catered for in the Market Messages database V 4.1 and the XML schema.
Following a review of the design ESB MOIP is now proposing to address the requirement to be able to
re-send market message related data to suppliers in the following manner:
Rather than having a suite of refresh messages covering a selected subset of market messages it is
proposed to provide a more general facility that will enable market participants to request the resending
of any given market message or all messages relating to a given MPRN
The requested “resend” message will be sent to the Supplier in exactly the same form as the original
message (the same transaction number and business reference number).
It is proposed to make Economic Activity Indicator mandatory on 010 message in defined circumstances
(ie sites where MIC > 30kva).
An invalid value or blank value (for sites where MIC > 30kva) on the 010 message will be rejected on
101R or 102R messages.
The Reject reason code on 101R and 102R should be ‘IEA’ – Invalid/Incomplete EAI code’
Suppliers will be allowed to make appointments for the following Call Types
• Re-Energise NPA
• Exch from D/T to S/T
• Exch from ST to D/T
• Remove NSH MT & T/S
• Install Token Meter
• Reset Token Meter
• Remove Token Meter
• Token Meter Fault/Ex (If this is a no Supply situation is should be referred to Networks as a No Supply call with
a Token Meter)
• Special test in-situ
Proposing to change the optionality of the Market Participant Business reference field on the 331
Message – QH Meter Technical Details message from mandatory to optional field
MM 111 Registration Cancellation confirms a cancellation on an MPRN to both the Old and New
This DR proposes that the existing message with all the fields populated is sent to the New Supplier but
the Old Supplier’s message would only have the following fields populated :
• Supplier ID
• Cancellation Reason
• Effective From Date
Detail of Change Request
This DR proposes to make fields on the 105 Change of Supplier Confirmation message optional so that
the proposed existing version would go to the New Supplier , but that only the following fields are
populated in the 105 message to the Old Supplier:
• Meter Point Address
• Effective From Date
Each of the market messages contains a field called Message Type in the header. Message 114
contains a second field called ‘Message Type’ (to indicate whether the message is a response or an
advice). It is proposed to rename this field to ‘Message Status’ in line with the XML schema and to avoid
confusion as these fields are used in two completely different contexts with different valid values and
Aggregation Messages – 501, 501S, 505, 505S
The first Additional Aggregation segment in messages 501, 501S, 505 and 505S should be documented as level 4.
second Additional Aggregation segment in messages 501, 501S, 505 and 505S should be documented as level 5
Message – 341
Message 341 is missing the cardinality of the Channel Level Details – Level 4. It should be 1..N
Optionality of Customer Service Special Needs and Medical Equipment Special Needs
The optionality of Customer Service Special Needs and Medical Equipment Special Needs is incorrect on messages
101, 105, 102N. These fields should be Optional not Mandatory.
Amend 501 message to include total EUF by profile and timeslot and the count of MPRNs used in
Input file for aggregation run to be available on request. Format (probably CD) to be determined at later