RMDS

IGG Conference Call 03.10.2018

Event Name IGG Conference Call
Date 03.10.2018
Time 15:00 – 16:00
Location N/A
Description Regular IGG Conference Call

Reference Material

Title Date
Request for CER Approval Non Schema Changes 04.02.2014
Apr Aug 2014 MDR Assurance Approach v1.0 Issued 04.03.2014
MCR 1137 Participant Questionnaire 05.03.2014
Non Schema Release 2014 – Participant Questionnaire for MCR 1137 07.03.2014
CER decision on MCR 1137 31.03.2014
Contacts for Non Schema Release 2014 05.03.2014

Lessons Learned

These will be posted here post implementation.

MCR 1033 – September 2013

MCR 1033 involves populating the Market Participant Business Reference on a number of 300 series Market Messages thereby facilitating the identification of readings and the events that triggered them.

Currently the Market Participant Business Reference is available but not populated. ESB Networks assessed the changes required to Central Market Systems to support this MCR as of high complexity.

The following table will display a status of the MCR delivery process.

Event Date Status
Participant Questionnaire issued 30th June 2014
Participant Questionnaire returned 21st July 2014
ESBN complete development TBD
Site visit to ESB Networks During period 21st July – 1st August 2014
Inter-Participant Testing Window 5th – 22nd August 2014
Gemserv Report to CER 29th August 2014
CER Go/No-Go Decision 5th September 2014
Cut Over 17th September 2014

MCR 1137 – April 2014

MCR 1137 introduces a change to the contents of the Downloadable Meter Points Data file whereby only billable meters will be shown.

At present non-billable meters are shown as well as billable meters. ESB Networks assessed the changes required to the Central Market Systems to support this MCR as of low complexity.

The following table will display a status of the MCR delivery process.

Event Date Status
Participant Questionnaire issued 7th March 2014 Complete
Participant Questionnaire returned 14th March 2014 Complete
ESBN complete development TBD
Requestors of MCR to validate file contents TBD
Gemserv Report to CER 19th March 2014 Complete
CER Go/No-Go Decision 25th March 2014 Complete
Cut Over 10th April 2014

Market Release Assurance – 2014 Non Schema Release

Gemserv drafted the Assurance strategy for the Non Schema Release 2014. This can be accessed here.

The following table displays all relevant Assurance dates for both MCRs.

MCR1033 MCR1137
Participant Questionnaire issued 30th June, 2014 7th March, 2014
Participant Questionnaire returned 21st July, 2014 14th March, 2014
Site visit to ESB Networks During period 21st July – 1st august, 2014 N/A
Inter-Participant Testing Window 5th – 22nd August, 2014 N/A
Gemserv report to CER 29th August, 2014 19th March, 2014
CER Go / No-Go decision 5th September, 2014 25th March, 2014
Cut-Over Wednesday 17th September, 2014 10th April, 2014

The assurance applicable to the different Market Participant types are displayed in the following table.

Participant
type
ESB Networks Supplier Small
Supplier
Self-Supplier TSO
(EirGrid)
Self
Assessment
MCR1033
& MCR1137
MCR1033
& MCR1137
MCR1033
& MCR1137
No No
Formal
Assessment
MCR1033 only
(Changes to Central System population of MPBR on MM300, MM300S, MM300W Cut-over plan)
No No No No
IPT MCR1033 only MCR1033 only
Requestors plus volunteers
MCR1033 only
Requestors plus volunteers
No No
Other MCR1137 only
Provide updated DMPD
MCR1137 only
Requestors to validate content of DMPD
No

Planning – 2014 Non Schema Release

The CER approved the introduction of the Non Schema Release 2014 on the 06 February 2014. RMDS will co-ordinate the release between ESBN, ROI Market Participants, Gemserv and CER. There will be an update on the Non Schema Release at each IGG until the final cutover in September 2014.

The cutover dates for the two MCRs are as follows:

  • MCR 1137 – Downloadable Meter Point Files to show only Billable meters
  • MCR 1033 – Add MP Business Reference to response Market Messages

ESB Networks is planning delivery of a few Market Facing defects as part of the overall Non Schema release 2014. These include:

  • Actual reads not being used in 016MM when timeslot not provided – Estimated delivery date 17th September 2014 with MCR1033
  • 017 R/E message resulted in a D/E order being created – Estimated delivery date June 2014
  • 2 reads in one message – Estimated delivery date March 2015

DR1193 – Tibco Reconciliation file to include list of TxRefNums

When there is a discrepancy in the reconciliation process the solution to identify the missing message(s) is quite cumbersome. Currently the 602 MM provides the type and count of messages sent/received between 03:00 am yesterday to 03:00 am today but no further details of the unique messages sent / received.

A list of all TrxRefNums inbound and outbound for each Supplier with the status of “completed” on the Central Hub for the same time period as the 602MM i.e. 03:00:00 to 02:59:59 will be created on the Central Hub.

The delivery method will be the creation of a daily file via email.  The use of the 602 message is not recommended as due to the potential size of these daily lists in particular for larger Suppliers.

Click here to read document

MCR1190 – Procedure for Supplier initiated transfer of MPRNs from one Supplier ID to another

A new Working Practice has been created to set out the steps which a Supplier must complete in circumstances where supplier initiated transfer of MPRNs from one Supplier ID to another is proposed.

The Working Practice sets out a four stage approach with requirements outlined for each stage.

Stage 1 – Regulatory Engagement with CRU

Stage 2 – Engagement with MRSO

Stage 3 – Customer Engagement

Stage 4 – Migration of MPRNs

Click here to read document

MCR1184 – Cooling off for CoS

The customers’ right to the cooling off period is detailed in Directive 2011/83/EU, which was transposed into Irish legislations through the Statutory Instrument S.I. No. 484 of 2013.

It provides, inter alia, for the right of a customer to change their mind and cancel a registration with a Supplier. Suppliers must adhere to the provisions of these laws.

The following MCR outlines how this would work in the Retail Market

Click here to read document

TUP Market Communications Plan

Click here for the TUP Market Communications Plan.

FAQ’s for Schema MCRs

Questions

MCR 1111 MCR 1122

MCR 1111
1 How will the network decide if it is CoLE or not? What are the exceptions for Cole?
2 FWP & SWP – 48 hours window compulsory? Will FWP or SWP set to 0 hr if msg is rejected?
3 Is it mandatory to automate the process of Debt flag, especially for commercial customers?
4 What if we do not automate? Is there a way we could still run via the manual process?
5 The MCR (1111)quotes the decision by the CER/ 11/106 in June 2011 which affects customer bad debt in Electricity and Gas markets. Will the Gas messages be changing under this MCR ? Will they need to be tested as part of supplier or market testing ?
6 N/A
7 Will the current manual Secure file transfer process remain for some debt objections following go live? For example will it remain only for unmetered GMPRN manual debt objections as WP 23 suggests?
8 If we were to send a debt objection via the secure file transfer process post go-live which should have been sent via 012 market message, would the business be notified via email to resend?
9 Should 112R contain the new code “DCN” where used to Reject an 012MM submitted for with “DCN”?
10 It has been queried in regards to how to handle 012MMs for debt flagging when submitted on a non working day?
11 The 110 is proposed to be amended to indicate where there is a COLE either explicit or inferred. How will this be displayed on the 110 message?
MCR 1122
1 Essential Plant flagging will be done by networks via 17 messages. This could be an issue for Supplier’s Credit control as they will not be able to de-energise them. Can the flagging be done before registration so as to put in place certain deposits in case the customer defaults?
2 Precise definition of Essential Plant. What premises comprises of being Essential Plant. How do they decide if EP. Is it based on info provided by customers?
3 Will the Gas messages be changing under this MCR (1122)? Will they need to be tested as part of supplier or market testing ?
4 MCR (1122) refers to a new schema name “essentialplantflag” Is this the extent of the schema changes ? Can more detail be provided on the structure of the schema change in advance of the 21/08?
5 Will sample market messages be provided for testing purposes for internal testing ?
6 What group of customers is this MCR applicable for (MCR1122)?
7 If MCR 1122 Essential Plant is an ROI Commercial only change or can it apply to domestic sites also? The definition below taken from WP 22 suggests it can apply to both types of property, can you confirm?Essential Plant (EP) includes:
− Water pumping/treatment systems,
− Fire Fighting Equipment incl. Alarms, Pumps, Access gates for Fire Brigade etc.
− Sewage systems,
− Lighting/lifts in indoor/outdoor common areas of apartment blocks/private developments
8 Would it be possible for Essential Plant to be a DG1 or DG2 (Residential) (maybe in the case of a Water Pump/ Landlord Supply at a block of apartments etc) reading the MCR – the change will only affect DG5 + ..is this correct ?
9 Will Connection Agreements for these installations need to be changed ?
10 The Essential Plant CR impacts 17 messages in total, the ones in question here are the 301, 331, 332 messages. Could site works carried out on site change the flag on a MPRN i.e. if a meter was exchanged or MP chars changed, at the same time the Essential Plant flag was applied or removed?i.e. when a supplier takes on a MPRN at that point the flag will noted for the duration of that MPRN with the supplier, but could a supplier take on a MPRN and then later on while registered, the flag could be changed?
11 Could a W message ever be used to withdraw the Essential Plant flag if it was incorrectly applied in the first instance. i.e. the meter details and read are unchanged only the flag changes?
12 To confirm, there are 3 scenarios for the details carried on the xml message?o The message tag =1 -> essential plant is present
o The message tag =0 -> essential plant is not present any more
o No message tag present -> essential was never present
13 Is the status of a MPRN being flagged as essential plant in any way impacted if the MPRN is d/e or r/e by the supplier i.e. both statuses are totally separate?
14 Under “Market Messages” – “With regard to Unmetered Change of Supplier Confirmation, for Grouped Unmetered the 700MM is the relevant message whereas for Single Point Unmetered it is the 105MM, as is the
current market design”. When I look at MPD33 it shows both 105mm AND 700MM being sent to the New Supplier. Can you clarify, please?
15 Under “Data Definition” – “This flag will be a new Boolean Flag. Where the flag appears with a value of 1 it will mean that there is essential plant at this MPRN, and in the exceptional case where this flag appears with a value of 0 this would means that there is not essential plant at this MPRN”.In what circumstances would the flag appear with value 0?
16 Could a Re-energisation occur concurrently with reclassification from No Essential Plant to Essential Plant and, if it did, would a 301MM be sent to the Supplier as well as the usual Re-energisation messages?
17 Will TSO ever receive the Essential Plant Flag on any MMs?

Answers

MCR 1111
Q1 How will the network decide if it is CoLE or not? What are the exceptions for Cole? Back to top
A1 There is no change in MCR1111 to the way MRSO determine if there is a COLE with the COS and so this will continue to operate as-is.
Q2 FWP & SWP – 48 hours window compulsory? Will FWP or SWP set to 0 hr if msg is rejected? Back to top
A2 MCR1111 is an approved Market Change Request and describes the new wait periods that will become automated.The FWP and SWP are as described in MCR1111, there will be no reset of any wait period in cases where a Supplier sends in an invalid market message.
Q3 Is it mandatory to automate the process of Debt flag, especially for commercial customers? Back to top
A3 MCR1111 is an approved Market Change Request and covers the automation of Debt Flagging for all relevant metered sites and single point unmetered sites as determined by CER.Debt Flagging will be automated as described in MCR1111 for all relevant metered sites and single point unmetered sites as determined by CER, and there are no exceptions.
Q4 What if we do not automate? Is there a way we could still run via the manual process? Back to top
A4 MCR1111 is an approved Market Change Request and describes the automation of Debt Flagging.Debt Flagging will be automated as described in MCR1111 for all relevant metered sites and single point unmetered sites as determined by CER, and there are no exceptions.
Q5 The MCR (1111)quotes the decision by the CER/ 11/106 in June 2011 which affects customer bad debt in Electricity and Gas markets. Will the Gas messages be changing under this MCR ? Will they need to be tested as part of supplier or market testing ? Back to top
A5 The scope of MCR1111 is for the automation of Debt Flagging for the Electricity Retail Market in RoI for all relevant metered sites and single point unmetered sites as determined by CER.
Q6 N/A Back to top
A6 N/A
Q7 Will the current manual Secure file transfer process remain for some debt objections following go live? For example will it remain only for unmetered GMPRN manual debt objections as WP 23 suggests? Back to top
A7 Debt Flagging will be automated as described in MCR1111 for all relevant metered sites and single point unmetered sites as determined by CER, and for those there are no exceptions.There will be a manual SFTS solution for Grouped Unmetered as per MCR1133.
Q8 If we were to send a debt objection via the secure file transfer process post go-live which should have been sent via 012 market message, would the business be notified via email to resend? Back to top
A8 When MCR1111 is introduced MRSO will not manually handle Debt Flagging for any metered or single point unmetered sites which will then be automated.
Q9 Should 112R contain the new code “DCN” where used to Reject an 012MM submitted for with “DCN”? Back to top
A9 The Objection Reason Code with a value ’DCN’ is sent by the losing Supplier on a MM012 to notify that a debt flag is being raised for the MPRN.The Objection Reason Code with a value ’DCN’ is sent to the gaining Supplier on a MM112 to notify that a debt flag has been raised by the losing Suppler , and that it has been successfully validated for the MPRN.MM112R is the Notification of Objection Rejection Message
• MM112R will never contain a Reject Reason Code ‘DCN’• The existing logic that triggers a MM112R, on foot of a MM012 , is being changed to take account of scenarios where a DCN will come in on a MM012, for these three Reject Reason Codes viz IRC,QHM, TIM .
These three Reject Reason Codes can currently issue on a MM112R, although not for Debt Flagging reasons. (extracts from MCR1111 are in italics below)
Changes to existing reject reason code usage for RoI 112R Notification of Objection Rejection are proposed as followsIRC – The Objection Reason Code is invalid (not for Erroneous Transfer) will be changed to allow for an 012MM to be submitted with a ‘DCN’ Debt contact notification objection reason code – ie ‘DCN’ will become a valid Objection Reason Code on MM012
QHM – An objection is not valid for an Interval Meter Point will be changed to allow for an 012MM to be submitted for an Interval Meter Point with a ‘DCN’ Debt contact notification objection reason code .
Note QHM will remain as a valid objection reject code eg should ‘ ET’ be submitted for QH site
TIM – The objection has been received more than 60 days after effective date of Change of Supplier will be changed to allow for a check against the new automated timelines where an 012MM is submitted with a ‘DCN’ objection reason code, such that ‘TIM’ will be sent on a 112R to the Old Supplier where the 012MM is received from the Old Supplier after the expiry of the FWP .
In other words, the present timeline that suspends the Change of Supplier process for a period of 10 working days as a result of an ‘ET’ Erroneous Transfer code will not apply in Debt Flagging Cases as identified by an 012MM with a DCN objection reason code
– an 012MM with a DCN objection reason code that is received by the CMS any time after the expiry of the FWP will be ‘late’, and is proposed to be rejected on a 112R with a reject reason code ‘TIM’
MCR1111 will introduce two Reject Reason Codes which already exist in the COBL and Schema but which currently do not issue on a MM112R , viz COL and IID . This will be done by adding logic that will trigger a MM112R on foot of a MM012 where it has been sent by a Supplier with Objection Reason Code value ’DCN’ and for the scenarios that will give rise to a COL or and IID: (extracts from MCR1111 are in italics below)Existing Rejection Reason Codes will become valid in RoI for use on the 112R Notification of Objection Rejection following validation of an 012MM Notification of Objection with ‘DCN’ Debt contact notification
– COL where there is a COLE with the COS [COL rejection reason ‘Change of Legal Entity in progress’]
– IID Rejection Reason ‘Invalid/Incomplete data’ will apply where the DUoS Group is invalid
MM112R currently could contain Reject Reason Code AMM, IMP, SNR , IA, and the logic around these will not be changed by MCR1111.(extracts from MCR1111 are in italics below)Existing reject reason codes will continue to be used as normal for non-debt flagging reasons on the 112RExisting rejection reason codes that are valid for RoI on the 112R and which will be valid as a result of a ‘DCN’ Debt contact notification objection reason code being sent on an 012MM are :AMM – The Meter Point Address on the message does not match that held by DSO for the MPRNIMP – The MPRN does not exist or is for a Grouped Un-metered site (either at GMPRN or TMPRN level) or is not valid for this jurisdiction

SNR – The Supplier submitting the objection is not registered to this MPRN and is not the Old Supplier for this MPRN

IA – The 012 received was a duplicate request. MRSO Already have a valid, open objection for this MPRN

Note on IA: this means that the receipt in MRSO of an 012MM which has either the same or a different objection reason code than a concurrent open012 MM is not valid and will be rejected.
In other words an 012MM with an objection reason code of ET cannot be in train at the same time as an 012MM with an objection reason code of DCN .Neither can there be a duplicate 012MM with the same objection reason codes.

Q10 It has been queried in regards to how to handle 012MMs for debt flagging when submitted on a non working day? Back to top
A10 Clarification : We will start the wait period from the start (00:00:00) of the next working day.
Q11 The 110 is proposed to be amended to indicate where there is a COLE either explicit or inferred. How will this be displayed on the 110 message? Back to top
A11 There is an existing field on MM110 which will be utilised to indicate where a COS has been identified as having a COLE , whenever this is explicit or inferredThis field has the data definition name Change of Tenant Legal Entity and the schema name ‘COT_LE_Flag’ .This currently exists as a required field on the MM110 and it is a ‘Boolean flag’. The change from MCR1111 will be that where a COS has been identified as having a COLE – either explicit or inferred – then the ‘COT_LE_Flag’ will be populated on MM110 with a value of 1, otherwise where a COS has been identified as having no COLE then the ‘COT_LE_Flag’ will be populated on MM110 with a value of 0

This is a change to how things currently work i.e. before MCR1111 is implemented the value of the ‘COT_LE_Flag’ on the 110 message mirrors the value of the ‘COT_LE_Flag’ populated by the Supplier on the MM010, regardless of whether or not MRSO infer that a CoLE has taken place.

MCR 1122
Q1 Essential Plant flagging will be done by networks via 17 messages. This could be an issue for Supplier’s Credit control as they will not be able to de-energise them. Can the flagging be done before registration so as to put in place certain deposits in case the customer defaults? Back to top
A1 The intention is for Essential Plant to be flagged for New Connections before registration and to appear on the Extranet as per MCR1122Please note that Essential Plant is currently in operation, see WP0022And that the Registered Suppliers of sites which are Essential Plant are routinely sent a list of these sites from ESB Networks.
Q2 Precise definition of Essential Plant. What premises comprises of being Essential Plant. How do they decide if EP. Is it based on info provided by customers? Back to top
A2 Please note that Essential Plant is currently in operation, see WP0022 as well as MCR1122
Q3 Will the Gas messages be changing under this MCR (1122)? Will they need to be tested as part of supplier or market testing ? Back to top
A3 The scope of MCR1122 is for the introduction of the Essential Plant Flag for the Electricity Retail Market in RoI.
Q4 MCR (1122) refers to a new schema name “essentialplantflag” Is this the extent of the schema changes ? Can more detail be provided on the structure of the schema change in advance of the 21/08? Back to top
A4 The amended schema will be implemented as Version 11.00.00MCR1122
Market Message ChangesA new optional EssentialPlantFlag field will be added to the following 17 Market Messages viz: 101 New Connection Registration Acceptance ,101P New Connection Provisional Acceptance, 102 Change of Supply Registration Acceptance ,102P Change of Supplier Provisional Acceptance, 105 Change of Supplier Confirmation301 Meter Point Characteristics ,106D Meter Point Status Confirmation DeEnergisation, 106E Meter Point Status Confirmation Energisation ,306 306W Meter Point Status Change Confirmation DeEnergisation, and Withdrawal, 307, 307W Meter Point Status Change Confirmation Energisation and Withdrawal, 331 Interval Meter Technical Details, 332 332W Non Interval Meter Technical Details, and Withdrawal
700 700W Unmetered Characteristics and WithdrawalThis field will be populated only where it has been determined that there is essential plant at the MPRN.The EssentialPlantFlag will be at MPRN level within the messages.MCR1122
Harmonised Data Changes
A new flag will be added to the Harmonised Data Definitions with the name Essential Plant Flag and schema name EssentialPlantFlag. The Harmonised Data Definition for Essential Plant Flag is “As and where an MPRN is determined to be Essential Plant, or where Essential Plant flag has been removed, then this flag will be highlighted.” This flag will be a new Boolean Flag. Where the flag appears with a value of 1 it will mean that there is essential plant at this MPRN, and in the exceptional case where this flag appears with a value of 0 this would mean that there was previously – but there is not now – essential plant at this MPRN.
Q5 Will sample market messages be provided for testing purposes for internal testing ? Back to top
A5 The intention is to fabricate , and have anonymous data so that it is not specific to any Supplier or Customer , one each of the 17 market messages that are being changed for MCR1122 ,and to issue them to all Retail Market Participants in RoI. This would happen in tandem with the project timeline for the amended schema ver 11.00.00.
Q6 What group of customers is this MCR applicable for (MCR1122)? Back to top
A6 Please note that Essential Plant is currently in operation, see WP0022 as well as MCR1122And that the Registered Suppliers of sites which are Essential Plant are routinely sent a list of these sites from ESB Networks.
Q7 If MCR 1122 Essential Plant is an ROI Commercial only change or can it apply to domestic sites also? The definition below taken from WP 22 suggests it can apply to both types of property, can you confirm?Essential Plant (EP) includes:
− Water pumping/treatment systems,
− Fire Fighting Equipment incl. Alarms, Pumps, Access gates for Fire Brigade etc.
− Sewage systems,
− Lighting/lifts in indoor/outdoor common areas of apartment blocks/private developments
Back to top
A7 Please note this text from MCR1122 viz ‘This flag is valid for relevant Unmetered DG3/DG4 at a TMPRN level and Business DG5 and higher’
Q8 Would it be possible for Essential Plant to be a DG1 or DG2 (Residential) (maybe in the case of a Water Pump/ Landlord Supply at a block of apartments etc) reading the MCR – the change will only affect DG5 + ..is this correct ? Back to top
A8 The Essential Plant Flag is valid for relevant Unmetered DG3/DG4 at a TMPRN level and Business DG5 and higher, and not DG1 or DG2.Where we come across a site that is DG1/DG2 and it is a landlord supply, we will advise the Supplier to issue a M013 to change the site to DG5. All Landlord Supplies should be DG5.
Q9 Will Connection Agreements for these installations need to be changed ? Back to top
A9 Connection Agreements are not being altered by MCR1122.
Q10 The Essential Plant CR impacts 17 messages in total, the ones in question here are the 301, 331, 332 messages. Could site works carried out on site change the flag on a MPRN i.e. if a meter was exchanged or MP chars changed, at the same time the Essential Plant flag was applied or removed?i.e. when a supplier takes on a MPRN at that point the flag will noted for the duration of that MPRN with the supplier, but could a supplier take on a MPRN and then later on while registered, the flag could be changed? Back to top
A10 From MCR1122: Where ESB Networks determine that there is a change at an MPRN which affects the value of the Essential Plant Flag, then this will be notified on the 301MM.This means that the Essential Plant Flag could be added or removed from an MPRN , where necessary, at any stage.
Q11 Culd a W message ever be used to withdraw the Essential Plant flag if it was incorrectly applied in the first instance. i.e. the meter details and read are unchanged only the flag changes? Back to top
A11 From MCR1122: Where ESB Networks determine that there is a change at an MPRN which affects the value of the Essential Plant Flag, then this will be notified on the 301MM.This means that the 301MM will be the vehicle to advise the registered Supplier of a change in the Essential Plant Flag status, and not a ‘W’ withdrawal message.
Q12 To confirm, there are 3 scenarios for the details carried on the xml message?o The message tag =1 -> essential plant is present
o The message tag =0 -> essential plant is not present any more
o No message tag present -> essential was never present
Back to top
A12 From MCR1122: A new flag is proposed to be added to the Harmonised Data Definitions with the name Essential Plant Flag and schema name EssentialPlantFlag. The Harmonised Data Definition for Essential Plant Flag is “As and where an MPRN is determined to be Essential Plant, or where Essential Plant flag has been removed, then this flag will be highlighted.” This flag will be a new Boolean Flag. Where the flag appears with a value of 1 it will mean that there is essential plant at this MPRN, and in the exceptional case where this flag appears with a value of 0 this would means that there is not essential plant at this MPRN.From 10.04.2013 IGG Clarification on MCR1122:
Under “Data Definition” – “This flag will be a new Boolean Flag. Where the flag appears with a value of 1 it will mean that there is essential plant at this MPRN, and in the exceptional case where this flag appears with a value of 0 this would means that there is not essential plant at this MPRN”.In what circumstances would the flag appear with value 0?

Clarification: A value of 0 will only appear on the 301MM, 700MM and 700W MM when an MPRN that was Essential plant has been updated and the flag removed i.e. it was originally created as an Essential plant and a value of 1 had been sent to suppliers on the original 301MM or 700MM. ESB Networks wish to advise the suppliers that it is no longer an Essential Plant and as part of this the flag will be removed from the MPRN on the Central Market system and this removal will be sent to the supplier in the form of a 0 in the field Essential Plant.

If a site was never an Essential Plant then the Essential Plant field will never be populated i.e. a blank value. ESBN Update July 2015: for the avoidance of doubt, this means that the essential plant flag will not be present in the market message.

Q13 Is the status of a MPRN being flagged as essential plant in any way impacted if the MPRN is d/e or r/e by the supplier i.e. both statuses are totally separate? Back to top
A13 Where there is no re-classification of the Essential Plant status, then a De-Energisation or a Re-energisation of a site will not impact on the Essential Plant Flag value.However, where there is a re-classification of the Essential Plant Flag status, please see the clarification given to the IGG on 10.04.2013 and published on the RMDS Calendar for that date viz:From 10.04.2013 IGG Clarification on MCR1122:

3. Could a Re-energisation occur concurrently with reclassification from No Essential Plant to Essential Plant and, if it did would a 301MM be sent to the Supplier as well as the usual Re-energisation messages?

Clarification: Yes, a re-energisation and reclassification from No Essential Plant to Essential Plant and Essential Plant to No Essential plant can occur. In this case a 301MM and the relevant re-energisation messages would be sent out.

4. Similarly for De-en when going from Essential Plant to No Essential Plant.

Q14 Under “Market Messages” – “With regard to Unmetered Change of Supplier Confirmation, for Grouped unmetered the 700MM is the relevant message whereas for Single Point Unmetered it is the 105MM, as is the current market design”.When I look at MPD33 it shows both 105mm AND 700MM being sent to the New Supplier. Can you clarify, please? Back to top
A14 Clarification: A differentiation was made in relation to the Grouped Unmetered and the Single Point Unmetered in regards the messages that are sent due to the manual nature of Grouped UnmeteredThe point in the MCR relates to the fact that the initial notification of the Essential Plant will be on the 700MM for Grouped Unmetered as there is no 105MM sent in this case.For Single Point Unmetered, the 105MM will be sent as normal and this will contain the field Essential Plant at this time.This is the same as metered sites. Subsequently a 700MM will be sent containing the details of the Essential Plant field as per normal market operations
Q15 Under “Data Definition” – “This flag will be a new Boolean Flag. Where the flag appears with a value of 1 it will mean that there is essential plant at this MPRN, and in the exceptional case where this flag appears with a value of 0 this would means that there is not essential plant at this MPRN”.In what circumstances would the flag appear with value 0? Back to top
A15 Clarification: A value of 0 will only appear on the 301MM, 700MM and 700W MM when an MPRN that was Essential plant has been updated and the flag removed i.e. it was originally created as an Essential plant and a value of 1 had been sent to suppliers on the original 301MM or 700MM. ESB Networks wish to advise the suppliers that it is no longer an Essential Plant and as part of this the flag will be removed from the MPRN on the Central Market system and this removal will be sent to the supplier in the form of a 0 in the field Essential Plant.If a site was never an Essential Plant then the Essential Plant field will never be populated i.e. a blank value. ESBN Update July 2015: for the avoidance of doubt, this means that the essential plant flag will not be present in the market message.
Q16 Could a Re-energisation occur concurrently with reclassification from No Essential Plant to Essential Plant and, if it did would a 301MM be sent to the Supplier as well as the usual Re-energisation messages? Back to top
A16 Clarification: Yes, a re-energisation and reclassification from No Essential Plant to Essential Plant and Essential Plant to No Essential plant can occur. In this case a 301MM and the relevant re-energisation messages would be sent out.Similarly for De-en when going from Essential Plant to No Essential Plant.
Q17 Will TSO ever receive the Essential Plant Flag on any MMs? Back to top
A17 Yes, should there be an MCR1122 essential plant flag implication for any MPRN for which a relevant market message is being sent to TSO. This applies to Market Messages
• 101 – New Connection Registration Acceptance
• 105 – Change of Supplier Confirmation
• 301 – Meter Point Characteristics
• 106D – Meter Point Status Confirmation – De-Energisation
• 106E – Meter Point Status Confirmation – Energisation
• 331 – Interval Meter Technical Details

FAQs for TIBCO Upgrade Project

Questions

Digital Certs EMMA Performance Testing Test and Cutover Webforms SMART Metering Licences

Digital Certs
1 Each market participant is responsible for purchasing of digital certs “as per guidelines provided” – how/when will these guidelines be provided?
EMMA
1 Where will the EMMA Installation & Deployment workshops be held? How long will each workshop last? Do attendees need to be present in person or will there be a Webex option?
2 What is included in the EMMA code release, does this include Webforms?
3 Will there be any changes to the underlying (Oracle) database schema for the supplier TIBCO (EMMA)? And what impact will this have on any reports running off it currently?
4 In the “New EMMA configs” (large option) there is one server in the DMZ and one interior server. So in this setup will the DMZ server be the file server (folder structure) and the internal one the application server?
5 What is the advantage and purpose of having a DMZ server in the set up?
6 Will the Oracle Software be provided?
7 What is the preferred Remote Access Client?
8 Can you explain the requirement for 7 user licences to the Oracle machine?
9 With regards to the requirement for the 4 static external IP address:
a. Can you explain why 2 IP’s are required for each environment?
b. Is there any possibility that rather than IP based these could become DNS based?
10 There will be 2 EMMA’s running on parallel, one for performance testing and another for IPT. Which of the two EMMA’s is envisaged to become the suppliers new production EMMA or is that left to the supplier to decide?
11 On the install of the EMMA’s by Capita, for a suppliers DR EMMA’s, will they be included in the installs to be carried out by Capita, putting any testing aside for the moment?
12 Who “owns” the EMMA server (and is responsible for the software licences)?
13 Can you tell me the purpose of the database component of the EMMA configuration?
14 Port Numbers. In relation to the list of port numbers and associated parameters what significance do these have?
15 IP Addresses. Can the existing static IP addresses be used within the new Setup?
16 In the new TIBCO solution at what stage, and in what circumstances, will the 601MM and 602MM be generated?
Performance Testing
1 Who will be required to participate in the Performance Testing exercise scheduled to run 21/9/2015 to 9/10/2015?
2 What level of resource would you expect might be required from a market participant during Performance Testing ?
3 Are you bundling the EMMA performance testing with current volumes with the Smart volumes testing together, or allowing suppliers to only opt for the performance testing on the current volumes?
Test & Cutover Preparation Workshop
1 Where will the Test & Cutover workshop be held? How long will the workshop last? Do attendees need to be present in person or will there be a Webex option?
Webforms
1 Where will the Webforms Functional training be held? How long will the training last? Do attendees need to be present in person or will there be a Webex option?
SMART Metering
1 What part will Suppliers have in Smart Metering Testing?
Licences
1 Do Suppliers have to purchase TIBCO software licences?

Answers

Digital Certs
Q1 Each market participant is responsible for purchasing of digital certs “as per guidelines provided” – how/when will these guidelines be provided? Back to top
A1 These guidelines will be provided w/ending 3rd July.
EMMA
Q1 Where will the EMMA Installation & Deployment workshops be held? How long will each workshop last? Do attendees need to be present in person or will there be a Webex option? Back to top
A1 It is expected that these workshops will be held in the City North Hotel (M1) and each one will last approximately half a day. A Webex session will be set up.
Q2 What is included in the EMMA code release, does this include Webforms? Back to top
A2 The EMMA Code Release includes TIBCO and Webforms code and configuration as required.
Q3 Will there be any changes to the underlying (Oracle) database schema for the supplier TIBCO (EMMA)? And what impact will this have on any reports running off it currently? Back to top
A3 Yes, the underlying Oracle schema will change and there are no similarities with the current schema so existing reports will need to be updated. However, we can share the DDL files at a later stage after some test phases have been completed.
Q4 In the “New EMMA configs” (large option) there is one server in the DMZ and one interior server. So in this setup will the DMZ server be the file server (folder structure) and the internal one the application server? Back to top
A4 In the new EMMA configuration for Suppliers with larger message volumes it is proposed that the interior server will act as the XML file store and the DMZ server will act simply as a gateway server to the EMMA application. This would be regarded as a more secure approach.
Q5 What is the advantage and purpose of having a DMZ server in the set up? Back to top
A5 The main advantages of splitting the DMZ and TIBCO App components as suggested are:
a) It would be considered a more secure approach (generally speaking) to store the market messages on the internal network.
b) It provides a more flexible solution for scaling – the gateway (DMZ) server is quite a lightweight component that is unlikely to outgrow itself whereas, in the event of a Supplier having to scale to meet increased message volumes/sizes, having the App server separated from the DMZ component would allow the Supplier to scale this component either vertically – more CPU, RAM – or horizontally by adding another App server.
Q6 Will the Oracle Software be provided? Back to top
A6 The purchase/provision of Oracle software is the responsibility of the Supplier, as is currently the case. The Oracle database scripts will be provided by the project.
Q7 What is the preferred Remote Access Client? Back to top
A7 As per the current preference – suggested options here are WebEx, Lync or TeamViewer.
Q8 Can you explain the requirement for 7 user licences to the Oracle machine? Back to top
A8 There are a number of built-in user licenses required by the EMMA TIBCO and Webforms applications themselves, i.e. to allow them connect to the database and there is also provision (out of 7) for an additional 2 Webforms users. Oracle licensing is complicated but one condition is that any individual user of the system (i.e. Webforms) will require a Named User License. This would be the case currently too.
Q9 With regards to the requirement for the 4 static external IP address:
a. Can you explain why 2 IP’s are required for each environment?
b. Is there any possibility that rather than IP based these could become DNS based?
Back to top
A9 The large EMMA must expose a Gateway server URL which contains a static external IP address. As there are PROD and TEST environments, this means a total of 2 IP addresses for the external Gateway Service. The second IP address per environment is a spare and is not mandatory. DNS hostnames cannot be used as the HUB does not have access to an external DNS service.
Q10 There will be 2 EMMA’s running on parallel, one for performance testing and another for IPT. Which of the two EMMA’s is envisaged to become the suppliers new production EMMA or is that left to the supplier to decide? Back to top
A10 The EMMA being used for IPT will become the production EMMA for Suppliers. There will be a clean down activity that will be executed by Capita during the period after IPT and prior to Cutover.
Q11 On the install of the EMMA’s by Capita, for a suppliers DR EMMA’s, will they be included in the installs to be carried out by Capita, putting any testing aside for the moment? Back to top
A11 No, the install process will only setup the suppliers production and test EMMA.
Q12 Who “owns” the EMMA server (and is responsible for the software licences)? Back to top
A12 The EMMA server is owned and managed by the Supplier, as per the current solution, licensing of all non TIBCO components is the responsibility of the supplier.
Q13 Can you tell me the purpose of the database component of the EMMA configuration? Back to top
A13 The underlying (TIBCO) technology utilised in the EMMA solution requires the ability to hold and store information as part of its capacity to process market messages, as such this requires the use of a database. The database will be used to store the information during transit back and forth to the Hub and additionally will be used to record its transient status during this process.

In other words the current EMMA solution uses a database which keeps the records of all inbound and outbound processing of the market messages. From the user perspective, database may not be visible, as file transfers are done via Windows Explorer, however it is crucial to have a database in the EMMA solution. The new solution will also need a database for the same purpose.

Q14 Port Numbers. In relation to the list of port numbers and associated parameters what significance do these have? Back to top
A14 The port number provided will be needed by the EMMA sserver, and those ports need to be kept open as part of the server build/commissioning activitytest.
Q15 IP Addresses. Can the existing static IP addresses be used within the new Setup? Back to top
A15 No the existing IP address cannot be used as part of the new solution. There will be a period of time when the new solution needs to be in place and the current solution will still be in operation. Once the current solution is no longer in use that IP address will be avaiable for the market Participant to use elsewhere.
Q16 IP Addresses. Can the existing static IP addresses be used within the new Setup? Back to top
A16 601 Messages & Outbound Message Validation

In the new TIBCO solution, a 601 message will be generated for any message from EMMA to HUB that fails validation. Validation is performed at two locations:

(A) At the EMMA itself, basic validation is applied before sending the message to Hub – this is the precheck

(B) At the HUB, full schema validation of the message is applied.

In both scenarios outlined, a 601 message will be generated.

Scenario A

When the message is picked up from the Outbound folder for processing, a small number of precheck validations are execute – these relate primarily to routing and to confirmation the header is properly constructed and includes MPRN and MpBusRef (where mandatory) ) In the event of a precheck failure in the EMMA, the EMMA creates a 601 file in the INBOUND and ARCHIVE folders. It also moves the original MM file from OUTBOUND folder to INVALID folder.

The 601 MESSAGE details are saved in the database. Both MM and 601 messages are viewable through the search functionality. Note these messages never reach the Hub. The 601 is generated in real time so the Market Participant will have visibility of the error almost immediately.

Scenario B

The new process with central validation at the Hub means the a 601 will be issued from Hub to EMMA should the message fail validation. This is where full schema validation takes place. Note that detailed error messages explaining the field which caused validation to fail will be included in these 601s in the error description.

The 601 message will be generated and automatically sent to a Market Participant should their message fail validation at the Hub. This message will arrive to the Inbound folder as per any message from Hub to EMMA and is viewable through the Search functionality (and message details are saved to the database and the payload will exist as a file on the file system). It also moves MM file from OUTBOUND to INVALID folder.

Messages sent from EMMA to HUB will be marked with a status of PENDING at send time. Once the message has been processed at the HUB it will generate a response to EMMA, and EMMA will update the message from PENDING to the appropriate status. If it passed validation it will be updated to COMPLETED. If it failed validation and a 601 was issued, the original message will be updated to a status of 601_COMPLETED.

RECEIVED –> PROCESSED –> PENDING –> INVALID –> RECEIVED –> 601_COMPLETED

The 601 is generated in real time so the Market Participant will have visibility of the error very soon after sending.

Market Participants may want to consider an adjustment to their ‘failed validation’ processes to handle this approach for example automated processing of 601 messages received.

602 Messages

The 602 is a daily summary of all messages and is a market message that will be created every morning and will accurately reflect the total number of messages that were sent/received to/from each Market Participant from 03:00:00 am to 02:59:59 am on that day. This message will arrive to the Inbound folder as per any message from Hub to EMMA and is viewable through the Search functionality (and message details are saved to the database and the payload will exist as a file on the file system). Functionally, this process has not changed. It will only include successful messages and hence anything generating a 601 will not appear on the report. Market Participants may want to consider an adjustment to their ‘602 reconciliation’ processes based on the state model outlined above

Performance Testing
Q1 Who will be required to participate in the Performance Testing exercise scheduled to run 21/9/2015 to 9/10/2015 Back to top
A1 A number of larger suppliers will be invited to Participate in Performance testing
Q2 What level of resource would you expect might be required from a market participant during Performance Testing ? Back to top
A2 If you are invited and agree to take part the involvement for the Supplier is expected to be for a 1-2 week period during the Performance Testing window. The project will aim to minimise the impact on Suppliers.
Q3 Are you bundling the EMMA performance testing with current volumes with the Smart volumes testing together, or allowing suppliers to only opt for the performance testing on the current volumes? Back to top
A3 Smart Meter Messages will be sent from HUB to Suppliers as part of the overall project testing (including performance). However there is no expectation for Suppliers to send any Smart Meter Messages (or responses to these messages) back to HUB or process the Smart Meter messages. At this time (due in part to the planned commencement date of Smart Metering) the EMMA Specs provided are not designed to meet the processing requirements of Smart Meter message volumes (both to and from the Hub). However to reflect the expected increased volume of messages such as 017 and 010 in the Smart meter market, Suppliers can choose to put additional volumes of inbound messages, and we can consider those as part of stress testing.
Test & Cutover Preparation Workshop
Q1 Where will the Test & Cutover workshop be held? How long will the workshop last? Do attendees need to be present in person or will there be a Webex option? Back to top
A1 It is expected that these workshops will be held in the City North Hotel (M1) and each one will last approximately half a day. A Webex session will be set up.
Webforms
Q1 Where will the Webforms Functional training be held? How long will the training last? Do attendees need to be present in person or will there be a Webex option? Back to top
A1 It is expected that these workshops will be held in the City North Hotel (M1) and each one will last approximately half a day. A Webex session will be set up.
SMART Metering
Q1 What part will Suppliers have in Smart Metering Testing? Back to top
A1 As part of Performance Testing where we hope to involve only the larget Suppliers in the market(s) in terms of message volumes, we will generate test Smart Metering messages and pass them between the new Hub and Large Suppliers’ new test EMMAs to check what impact their might be on the Comms links and the new EMMA specs. We aim to automate this testing and it’s scope will be contained to only the TIBCO elements (i.e. not Suppliers’ back-end systems) and so their will be minimal input from Suppliers required. We will be contacting those Suppliers separately on this point.
Licences
Q1 Do Suppliers have to purchase TIBCO software licences? Back to top
A1 No, the project will provide Suppliers with licenced copies of the required TIBCO software and new IBM Webforms software. The TIBCO and IBM EMMA software will be made available to download in advance of Capita performing the EMMA installations.

TIBCO/Schema Programme – Participant Questionnaire

The Participant Questionnaire (PQ) is to assess the extent to which Market Participants are aware of both the coordinated TIBCO Hub Project changes and Schema changes, the details of their approach and their readiness for the changes to go live.

All Market Participants are asked to complete the PQ’s within the required timescales.

PQ Timeline 6-7-15

Where a MP exists in both jurisdictions, they are required to respond to the PQ’s for each instance of market operations in each jurisdiction.

Download the PQ for TIBCO Upgrade here.

Download the PQ for Schema MCRs here.

TIBCO/Schema Programme – Strategy

The Regularity Authority’s (RA) require an assurance strategy to give them the confidence that the programme is being delivered with a mitigated risk to the co-ordinated markets, delivery is in compliance with the technical and timescale requirements and that all Market Participants are properly prepared for cut-over.

co-ordinated-assurance-strategy


The assurance strategy has been jointly prepared by the assurance bodies (Gemsev in ROI & Neueda in NI) under the Retail Markets Co-ordination Working Group. The Assurance Strategy Document was approved by the ReMCoSG on the 24th June 2015.

Addendum Assurance Plan

This Addendum Assurance Plan is supplementary to, and should be read in conjunction with, the assurance strategy agreed on June 2015.

The Addendum Assurance Plan that will be employed by Gemserv and Neueda (the assurance bodies) is tailored to the specific requirements of Issue 24 and describes the additional actions to be taken, to provide assurance to the areas of risk which were identified in Issue 24.

Addendum Assurance Plan

Assurance Strategy Milestones

Event

Date

Status

Assurance Strategy Document issued to Market Participants

12th June 2014

Complete

ReMCoWG approval – extraordinary Con – Call

23rd June 2014

Complete

ReMCoSG approval – meeting

24th June 2014

Complete