RMDS
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
TUP Market Communications Plan
Click here for the TUP Market Communications Plan.
FAQ’s for Schema MCRs
Questions
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. |
|
| 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? |
| 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.
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.
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.
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.
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 |
TIBCO/Schema Programme – Assurance
Both Regulatory Authorities (RA) mandate the need for Assurance. The assurance process provides an assessment based on an agreed set of criteria and enables the RA’s to make a decision regarding Project “Go Live” based on a full risk assessment.
Both RA’s will be required to sign off and approve the assurance report in order to give the go ahead for cutover.
Go LIve Approval Requirement
Assurance Plan Dates
| Assurance Milestone | TIBCO / Schema Programme |
| Participant Questionnaire issued | 7 July 2015 |
| Participant Questionnaire returned | 7 August 2015 |
| Site Visit to ESBN and NIE | During July – September 2015 |
| Inter-Participant Testing window | 28 September – 30 October 2015 |
| Assurance Report to RAs | 5 November 2015 |
| RAs Go / No-go decision | 13 November 2015 |
| Cutover | 20 – 22 November 2015 |
Planning
2016 Schema Release Planning information will appear here.
2016 Schema Release – Prioritisation
The first step of the process is to prioritise the package for delivery in 2016.
Please find link below:
Schema Release-2016 MCRS for Prioritisation v1.1
Prioritisation Results
Click on the link below for the results of the Prioritisation exercise.
Reference Material
| Title | Date |
|---|---|
| Email sent to Suppliers for Prioritisation | 26.08.2016 |
| Schema Release 2016 – List of MCRs for prioritisation | 26.08.2016 |
Hypercare FAQs
| Question | Response |
| Q1 | A1 |
| Q2 | A2 |
| Q3 | A3 |
Hypercare Daily Reports
TIBCO Upgrade Project Current Status 30082016 Ver 1 0
Reference Material
Non-Schema 2015 – Lessons Learnedq
These will be posted here post implementation.
