DSC Delivery Sub-Group

1. DSC Delivery Sub-Group 1st April 2019

2. Agenda (1)

3. Agenda (2)

4. 3. Defects update • 3a. AQ Defects • 3b. Defect dashboard

5. 3a. AQ Defects The AQ Defects spreadsheet is saved in the DSG pages on xoserve.comlisted as 3a. AQ Defects

6. 3b. Defect Summary

7. Defect Summary Stats • Stats as per HPQC extract taken on Wednesday 27th March 2019.

8. R3.09 The below fixes were all deployed to production between the 1st and 8th March. The below fix was deployed as urgent. Release 3.10 is scheduled for 5th April 2019.

9. Amendment Invoice Impacting Defects

10. Amendment Invoice Impacting Defects - Closed The below defects were deployed / closed since the last slides were issued.

11. 4. Portfolio Delivery Overview POAP • 4a. The Portfolio POAP is saved in the DSG pages on xoserve.com listed as 4. Portfolio Overview POAP • 4b. Retail and Network Delivery Overview

12. R&N Timeline June-19 Sept-19 (EUC) Nov-19 Minor Release D4 CSS CC RETRO UIG Mod 678 – GB Charging Feb-20 June-20 Nov-20 • Assumes February Release continue to be documentation only release • Assumes RETRO will be Nov 2020 Major Release Delivery • Please note that this is all potential activity within UK Link over the next 24 months

13. 2019 / 2020 R&N Delivery Timeline Imp PIS Jun-19 Build Testing PIS Build Testing Imp #1 PIS Imp #2 EUC Capture Initiation UAT MT Imp PIS Design Build & UT ST SIT Reg / Pen Test Nov-19 Potential Activity MR HLD CSS CC System / Internal Acceptance / Pen Testing SIT / Reg Test MT IMP Detailed Design Retro Nov-2020 UIG 2020 Mod678 – Uk Link Impacts UKL PT ST SIT SUPT UKL RT IDR PIS UKL ST UKL AT & RT UAT UT IMP • Assumes February Release continue to be documentation only release • Assumes RETRO will be Nov 2020 Major Release Delivery • Please note that this is all potential activity within UK Link over the next 24 months

14. 2019 / 2020 R&N Governance Timeline Jun-19 BER Approval 09/01/19 Sep-19 / EUC BER Approval 09/01/19 BER Approval 10/04/19 BER Approval 10/04/18 Change Pack Issue 08/05/19 EQR Approval 06/02/19 Nov-19 MR Potential Activity ChMC Scope Approval 10/04/19 Feb-20 Potential Activity Governance Approval dates tbc RETRO Potential Activity Key Governance Approval dates tbc Complete On track At risk • Assumes February Release continue to be documentation only release • Assumes RETRO will be Nov 2020 Major Release Delivery • Please note that this is all potential activity within UK Link over the next 24 months

15. Change Index – R&N Allocated Change

16. Change Index – R&N Unallocated External Impacting Changes

17. 5. Major Release Update • 5a. Release 3 • 5b. Minor Release Drop 3 • 5c. June 2019 • 5d. EUC 2019 • 5e. November 19

18. 5a. XRN4572 UK Link Release 3

19. UK Link Release 3 - Plan Milestone date forecast to be met Milestone date forecast to be at risk Planning/Milestone date to be confirmed Milestone date forecast to be missed Milestone completed RAG Key – Milestones are end dates; *Closedown expected to finish this week** Synergised ST and AT date

20. 5b. XRN4802 – MiR Drop 3 - Status Update

21. 2018 2019 May Jun Jul Aug Sept Oct Nov Dec Jan Feb Mar Build UT Imp Testing XRN4802 – MiR Drop 3 • Minor Release Key Milestone Dates: • 22nd March – PIS completed and Handover to Xoserve Operate accepted – Project now closed Apr Feb-19 Minor Release Timeline Design Build ST & Assurance CM PT / RT IMP PIS Feb-19 Minor Release Timeline

22. 5c. XRN4732 - June 19 Release - Status Update

23. XRN4732 - June 19 Release Timelines • Key Milestone Dates: • Build and UT has completed • ST+SIT has now commenced

24. 5d. XRN4665 – EUC Release

25. XRN 4665 - EUC Release Timelines • Key Milestone Dates: • Build & UT activities tracking to plan for completion by planned milestone date • ST/SIT activities commenced as per plan and currently tracking to schedule • Internal discussions ongoing to agree PIS duration (to include first usage monitoring)

26. XRN4828 - Nov 19 Release - Status Update

27. 2019 2020 Feb Mar Apr May Jun Jul Aug Sept Oct Nov Dec d e e r g A C e Mobilisation M Build UT Imp p h o Testing C c S – 9 1 e n u J XRN4828 - Nov 19 Release Timelines • Key Milestone Dates: • Receive supplier responses – 13/02/19 • Supplier contract approval – 05/04/19 • Approve and issue EQR – 04/02/19 • Gain Business Case approval at IRC - 13/03/19 • PID approval 12/04/19 • Detailed Delivery Plan approved – 05/04/19 • BER Approval – 10/04/19 • Design Change Packs Submitted to Industry –08/05/19 • Test Plan approval – 05/04/19 Jan Nov-19 Timeline IMP (Inc IDR) PIS Design Build & UT System Test SIT UAT RT & PT Market Trials Closedown 04/02: EQR Approval 08/05: Change Pack Submission 10/04: BER Approval

28. Assurance In Place of Market Trials • Option 1 – Do Nothing • Xoserve would not look to provide any alternative to provide assurance in place of Marker Trials • Confirmation of successful Acceptance, Performance & Regression Testing would be confirmed • Option 2 – Provide Test Summary Report • Xoserve will produce a summary report at the completion of testing and ahead of Implementation providing details of successful test completion including Test Case pass rate and defect figures

29. 6. New Change ProposalsFor Ratification of the Prioritisation Scores • No agenda items for this section

30. 7. Change Proposal Initial View Representations • 7a. XRN - XRN4871 - Modification 0665 – Changes to Ratchet Regime • 7b. XRN4645 – The Rejection of Incrementing Reads Submitted for an Isolated Supply Meter Point (RGMA Flows) • 7c. XRN4780 - Inclusion of Meter Asset Provider Identity (MAP Id) in the UK Link system (CSS Consequential Change) • 7d. XRN4789 - Updating Shipper Reporting Packs and glossary

31. 7a. XRN4871 - Modification 0665 – Changes to Ratchet Regime

32. Background • Modification 0665 has been raised and seeks to amend the current Class 2 Ratchet Charging Arrangement and it allows Transporters to designate Supply Points (Network Designated) that should, in addition to existing mandatory Class 1 Supply Points, be subject to the existing Class 1 Ratchet Charging Arrangement. • This Change Proposal has been raised to deliver the system requirements set out within this modification. • Due to the proposed timescales and the requirement to implement the changes by 01 October 2019, the Change Proposal has been raised ahead of the modification being officially approved (Panel approval expected March and Ofgem decision April). • Implementation is being proposed as the July Minor Release.

33. Last DSG Meeting – 18 March 2019 • During the last meeting, we requested views from DSG on certain solution options / assumption (options/assumptions are detailed within the following slides). • DSG acknowledged that the options presented were pragmatic and agreed for an extraordinary Change Pack to be issued to solicit wider industry views. • An extraordinary Change Pack was issued on 19th March closing on 27th March. Five parties responded, three of which supported our approach and two made general comments/observations but did not raise any major concerns. • Slides 4-7 recaps the options / proposed approach and includes reference to the industry representation we received.

34. Visibility of ND Flag As part of application of Network Designation the Registered User will receive a notification to the DSC Contract Manager from the CDSP • Visibility of Network Designation to Prospective Users • As we are seeking to limit the scale of impacts to Users, and in particular Users who do not operate DM Supply Points, we are NOT proposing to make this data item available to Shipper Users in SPA files – e.g. Nomination Response (including Enquiry); Confirmation; etc. • We would suggest that if there is a requirement to make this data item available in SPA files, that this is considered within the CSS Consequential interface changes – scheduled for 2021 • If the industry believes that Prospective Users need to have visibility of the Network Designation, potential options could be: • Changes to DES • This is not recommended as the change may be precluded by the timescales. • Addition to API services • This would be the preferred option if visibility was required but would need to be assessed. Industry representation indicated that Users were comfortable with the approach to not amend file formats for this implementation and were comfortable with this being considered as part of CSS changes especially if the number of these sites were to grow significantly over time.

35. Views sought from DSG - SPA • Rejection of Nomination / Confirmation (including Reconfirmation) / Class Change • If a site is Network Designated it must be Class 1, any relevant transactions will need to be rejected, such as: • Nomination • Confirmation • Class Change • We would propose that we use the existing Rejection Code CLS00002 – “Supply meter point should be Class 1”. This code is used for the above processes already. • Shippers need to consider if this rejection will cause exceptions within their systems as the site will not meet the current Class 1 requirements. From the industry representation, Users did not flag concerns with this approach. It was suggested by one User that a new rejection code would be sensible. This will need to be considered as part of design but the majority were happy with the utilising the rejection code suggested and did not believe it would cause exceptions in User systems that could not be managed.

36. Views sought from DSG – Inflight • Outstanding Offers and Inflight Change of Shipper / Capacity Revision • The industry needs to consider where a Supply Meter Point gets set to Network Designated but has and outstanding offer or an accepted confirmation: Outstanding Offer on a Network Designated site which has a Class other than Class 1 We could: • Invalidate Offer • Reject the Confirmation where the Shipper attempts to confirm an Offer on a Network Designated Supply Meter Point • Allow Offer to continue, but oblige Shipper to reclassify the SMP Accepted Confirmation on a Network Designated site which has a Class other than Class 1 We propose to allow Confirmation to progress, but oblige Shipper to reclassify the SMP From the industry representation, Users agreed with our approach to allow the Confirmation to progress.

37. Views sought from DSG – Invoicing • New Ratchet Charging Arrangement • The current Ratchet Charge includes the ZRA – Customer Ratchet Charge and the SRA – SOQ Ratchet Charge • The new Ratchet Charge for Class 2 sites will also include the ECN – Exit Capacity LDZ Charge. This is planned to be incorporated into the ZRA Charge for Class 2 Ratchets only • This appears on the CAZ Invoice and ZCS Supporting information • The RT_I09_CAP_RATCHET_CHARGE_DETAIL record has theRATCHET_PREMIUM value which we expect will be populated differently between Class 1 and Class 2 Ratchets. This needs to be considered by Shippers. From the industry representation, Users were not concerned with the proposed changes. It was stated by one User that changes to the file structure (which is not proposed) would cause an issue and a value/rate change is manageable (which is being proposed).

38. Next Steps… • We appreciate the feedback from DSG / through the industry representation and note that the general consensus is that Users are comfortable with the options proposed and suggested implementation (July Minor Release) providing there is no change to actual structures. • Please note that the options/approach presented to date are a first draft only and this will all need to go through a thorough assessment. • We will consider the representation we have received and take the change through detailed design which is currently unconfirmed. • The outcome of the detailed design will be shared with DSG and the wider industry through the usual change process.

39. 7b. XRN4645 – The Rejection of Incrementing Reads Submitted for an Isolated Supply Meter Point (RGMA Flows) • Slides to be provided by 01/04/19

40. 7c. XRN4780 - Inclusion of Meter Asset Provider Identity (MAP Id) in the UK Link system (CSS Consequential Change)

41. Overview • XRN4780 has been raised to look at adding in MAP Identifier into UK Link • This change is a result of a requirement to pass the MAP Id to CSS so they can be informed as part of a switching event • July-19 scope includes acceptance/storing of Market Participant (ASSPR - Asset Provider) contained in submitted RGMA files within UK Link

42. RGMA Logic Overview • Where an accepted RGMA (JOB) contains a valid MAP Id • Current MAP Id is end dated and new MAP Id is populated • Where an accepted RGMA (JOB) does not contain a valid MAP Id or MAP Id is not provided • Current MAP Id is removed/end dated • Where an accepted RGMA (UPD) contains a valid MAP Id • Current MAP Id is end dated and new MAP Id is populated • Where an accepted RGMA (UPD) does not contain a valid MAP Id or MAP Id is not provided • Current MAP Id is retained

43. RGMA Logic Overview cont. • Previous slides reference ‘valid’ MAP Id • RGMA Files (JOB/UPD) contains MKPRT record containing the following… • A0177 | Record Identifier | MKPRT • A0126 | Role Code | ASSPR • A0064 | Market Participant Abbreviated Name | ### • A0064 has a length of 12 (as this record is also used for Meter Worker [MTWK] information) • MAP Id has a standard 3 character length • Validation will be carried out on inbound RGMA’s and only MAP Id’s that are referenced in our organisation table will be classed as valid and loaded

44. 7d. Reporting XRN delivery recommendations Seek agreement from DSG on how to progress reporting changes

45. Shipper Pack, PARR Reporting XRN delivery recommendation • There are currently a number of Reporting Changes being progressed through capture in the Customer Change Lifecycle Team. • These changes will predominately require resource from the same teams and the same tables within SAP BW. They will also need similar changes and testing to be carried out to deliver the changes. • The purpose of this document is to seek agreement from DSG on how to progress these changes in order to do the following: • Limit the amount of regret spend • Deliver the changes to Shippers in the optimum timeframe • Provide benefit to shippers by giving meaningful usable management information • Provide a medium term solution to reporting requirements until such times as the Reporting Review is complete. • The following options and recommendations have been made by Xoserve and we are seeking feedback on the recommendation from DSG Members to then be able to present the recommendation to Change Management Committee for ratification.

46. Shipper Pack, PARR Reporting XRN delivery recommendation Problem Statement & Objective: There are a number of outstanding change requests in progress which overlap in terms of data source and reporting purpose. The objective of this recommendation is to agree the best way to approach these XRN’s to minimise regret spend and provide value and benefit to customers as soon as possible. Description: XRN4789 has been raised to address the format of the Shipper Reporting Pack. It will look to add value by changing the glossary to make it more user friendly and also align the data reported post Nexus to product class from AQ band. It also looks to change the lay out to make the data easier to interpret by Shippers Benefits / Financial Impact: Indicative costs to change in isolation - £20k Option 1 – Progress the Shipper Pack report changes only (XRN4789): Indicative costs – £20k • Pros: Cons: • Risk: Regret spend may be incurred by shippers – due to the number of similar reporting changes code may be changed for this and then again changed soon after. • Risk: Making these changes in isolation might lead to delays in delivering the PARR Reports due to availability of resource and testing environments. • Changes will be progressed as planned and change can be assigned to delivery team as early as 3rd April. • Shipper Packs will be structured better so that the data can be divided up by departments to work. • Aligns the Shipper Packs to the changes made as part of Nexus – reporting by Product Class rather than AQ. • Shippers will be provided with some of the supporting data to review when challenged by PAC.

47. Shipper Pack, PARR Reporting XRN delivery recommendation Problem Statement & Objective: There are a number of outstanding change requests in progress which overlap in terms of data source and reporting purpose. The objective of this recommendation is to agree the best way to approach these XRN’s to minimise regret spend and provide value and benefit to customers as soon as possible. Benefits / Financial Impact: Reduce regret spend. Indicative costs to change in isolation – unknown currently pending outcome of this recommendation (to avoid regret spend). Description: XRN4864, XRN4779 and XRN4876 have been raised to provide additional data items for PAFA and the PARR Reports. This data can then assist shippers in monitoring their own performance and addressing any issues prior to them being notified by PAC. Option 2 – Progress the PARR report changes ( XRN4864, XRN4779 and XRN4876) only: Indicative costs – not currently known • Pros: Cons: • Risk : May still need to make the changes to the shipper packs should it be discovered in detailed design that the best place to display the data is in the Shipper Packs – currently reporting at AQ and not Product class. • Risk: May require additional investment for providing the data at lower level granularity due to size and transfer of data – possible will need SFTP route or secure location in the cloud to host. • Progressing these changes together will provide the majority of lower level data needed by Shippers to take corrective action should they be notified by PAC of poor performance. • Some of the additional data being delivered will also fulfil some of the UIG Taskforce recommendations and committee approved routes for delivery therefore is a strategic initiative. • Avoids making changes to the Shipper Packs which may become obsolete once the PARR Reports have more supporting information therefore minimising regret spend.

48. Shipper Pack, PARR Reporting XRN delivery recommendation Problem Statement & Objective: There are a number of outstanding change requests in progress which overlap in terms of data source and reporting purpose. The objective of this recommendation is to agree the best way to approach these XRN’s to minimise regret spend and provide value and benefit to customers as soon as possible. Description: Within XRN4789 there is a request to update the glossary to make it more relevant. As per Option two there are four PARR Reporting changes which will have similar code changes and require the same resource to develop and test. Benefits / Financial Impact: Reduce regret spend. Indicative costs to change in isolation – unknown currently pending outcome of this recommendation (to avoid regret spend). Option 3 – Progress the glossary changes for the Shipper Packs and deliver all the PARR Report XRNs together - not currently known • Pros: Cons: • Risk: May still need to make the changes to the shipper packs should it be discovered in detailed design that the best place to display the data is in the Shipper Packs – currently reporting at AQ band and not Product class. • Risk: May require additional investment for providing the data at lower level granularity due to size and transfer of data via the Shipper Pack – possible will need SFTP route or secure location in the cloud to host. • Progressing the Shipper Pack Glossary changes will provide immediate benefit to all Shippers including new entrants to the market • Progressing these changes together will provide the majority of lower level data needed by Shippers to take corrective action should they be notified by PAC of poor performance. • Some of the additional data being delivered will also fulfil some of the UIG Taskforce recommendations and committee approved routes for delivery therefore is a strategic initiative. • Avoids making changes to the Shipper Packs which may become obsolete once the PARR Reports have more supporting information therefore minimising regret spend.

49. Shipper Pack, PARR Reporting XRN delivery recommendation Q2 ‘19 Q3 ’19 (indicative) Recommended Option 3: Progress the glossary changes for the Shipper Packs and deliver all the PARR Report XRNs together • Option 3 is recommended for the following reasons: • It delivers on all changes, albeit partially for XRN4789 but the glossary changes add immediate value. • Minimises the level of regret spend – if tables in the system are being modified at the same time for all changes. development and testing can be done once rather than several times. • Delivers a strategic approach to change for customers. • Adds value for UIG by giving access to the data that impacts shippers and UIG. • Provides a mid term approach to reporting until delivery of XRN4857 (Reporting Review) and the rationalisation of all reports. Shipper Pack Glossary changes UIG Reports PARR Report Changes Shipper Pack Changes

50. 8. Undergoing Solution Options Impact Assessment Review • 8a. XRN4833 - Roll Out of Business Intelligence and Data Discovery Capability • Verbal update to be presented by Jason McLeod