WHOLESALE-RETAIL CODE CHANGE PROPOSAL/ CHARGING CHANGE PROPOSAL ICP Form version 2 For use by the Interim Code Panel Change Proposal Reference (To be completed by the Interim Code Panel Secretary) ICP/WRC016 Submission: Change Proposal/ Charging Change Proposal Change Proposal Title: of Change Proposal/Charging Change Proposal Data Catalogue Updates – SPID Format Version No 1 General Details of the Proposer Name of Proposer Kulwinder Johal Capacity (for Change Proposals – on behalf of a Party, as an Interim Code Panel member, as the customer representative or on behalf of MOSL or the Authority; for Charging Change Proposals – on behalf of a Wholesaler). Market Design Lead MOSL Contact Email; Tel/Mob. kulwinder.johal@mosl.co.uk Authorised signature Related Documents Reference of any associated Interim Code Panel Change Proposal/ Charging Change Proposal Not applicable Documents Accompanying Form CSD030, Appendix A indicating changes required Proposed Urgency Urgent/Non-Urgent: URGENT Reasons for urgency in relation to the pre-Go Live period The proposed changes set out in this change proposal are required to finalise the design of the CMOS and to be specified consistently in the CSDs and the subsidiary interface design documentation which will be used both by MOSL to build the CMOS and the Trading Parties to build their own systems. Version ICP Data Updates ICP/WRC016 Page 1 of 7 The Interim Code Panel will review this information and make a decision as to whether to take this Change Proposal/Charging Change Proposal forward as urgent in relation to the milestones relevant to the pre-go live period. Change Proposal/ Charging Change Proposal Details Description of (i) The enhancement, issue or defect which this Change Proposal seeks to address, or (ii) the modified or new charging method or charging structure required pursuant to this Charging Change Proposal, as required under the Draft Market Arrangements Code Section 6.2.1(b). Appendix A of the post-Vendor version of CSD 0301 (Data Catalogue) provides broad details of the SPID format to be used, but notes that the detail of the SPID format is subject to the final design of the Central Systems. This proposal builds upon the outline design of the SPID format, and provides further details in respect of: The length of the character strings which form the SPID; The details of the character set which forms the SPID; and The details of the check digit algorithm. The Supply Point ID as defined in CSD 0301 consists of several sections: SPID Core; Service Category; Version; Check Code. The detailed enhancements are: 1. The SPID Core uniquely identifies Eligible Premises at which there may be either one or two Supply Points (a Water Services Supply Point and/or a Sewerage Services Supply Point). It is proposed that the SPID Core is further split into a a. Core serial part; and b. Core check digit The inclusion of core check digit within the core, will ensure that whenever the core is used on its own, the core check digit enables error detection. The core check digit is an integral part of the core, and must always be used. For the avoidance of doubt, the inclusion of the core check digit is in addition to the SPID check digit and not instead of the SPID check digit. 2. A full and detailed description is provided for: a. The length of the relevant strings making up the SPID; b. The check digit algorithms; and c. The details of the relevant character sets. For the avoidance of doubt, Data items D2001 (SPID) and D2002 (Service Category) remain unchanged. Version ICP Data Updates ICP/WRC016 Page 2 of 7 Description of the Change Proposal/ Charging Change Proposal, its nature and purpose and (for Change Proposals only) how it is consistent with the Principles and falls within the Objectives noted below, as required under the Draft Market Arrangements Code Section 6.2.1(c). General Description This issue, whilst minor, must be resolved to facilitate the detailed design of the CMOS and the development of the interface documentation such that both the design and the documentation are consistent. The design and the documentation will allow MOSL to build the CMOS and allow Trading Parties to build and develop their own systems in a manner which will allow full interoperability between them. The following changes are proposed to complete the description of the SPID format: 1. Update the SPID Format in Appendix A, Figure 1 2. Update the description for SPID Core to detail that it has two sub-parts to it and to include descriptions of each of the two sub-parts. . a. The Core Serial Part; and b. The Core Check Code 3. Update the description of the Version 4. Update the description of the SPID check code 5. Include the description of the full SPID format, and how SPID Cores will be allocated 6. Include the description of the check code algorithm which is used for both the core check code and the SPID check code. Revised drafting as below: A A.1 Appendix A –SPID format A.1.1 A SPID is composed of four (4) parts concatenated into a single, unique, thirteen (13) character string. Figure 1 below illustrates the component parts. The SPID Core is further divided into two (2) sub-parts. SPID format Version ICP Data Updates ICP/WRC016 Page 3 of 7 Figure 1 – SPID where each part of a SPID is as follows (a) SPID Core This is comprised of two sub-parts: (i) SPID Core Serial Part This is the serial number generated upon adding a Supply Point to the Supply Point Register and identifies a Supply Point without making a distinction between Water or Sewerage Services – the SPID Core is thus unique to each Eligible Premises. This serial number is an nine (9) digit integer.(ii) Core Check Code This check code enables error detection for the SPID Core and must always be used. The check code is a single character and may either be an integer (0 – 9) or the letter “X”. (b) Category This identifies the Service Category of the SPID W for Water and S for Sewerage. (c) Version This identifies the version of the SPID, allowing Deregistered SPIDs to be Registered again with the version number incremented. The version will be a single integer. The first version of a SPID will be “1”. If, exceptionally, over nine versions of a Supply Point are required – then the Supply Point (and its paired Supply Points) will need to be deregistered, and new Supply Points with new SPIDs created. (d) Check code The check code enables error detection and is an intrinsic part of the SPID. The check code must always be used. The check code is a single character and may either be an integer (0 – 9) or the letter “X”. The SPID will therefore have a total length of thirteen (13) characters, and be comprised of the integers (0-9) and the letters “W”, “S” and “X”. SPID Cores (and SPIDs) which are created by data upload before the Go Active Date will start with the integer “1”. SPID Cores which are created by data transaction after the Go Active Date will start with the integer “2”. For the avoidance of doubt, SPIDs which are created by data transaction after the Go Active Date and which are paired to a SPID created by data upload before the Go Active Date will start with the integer “1”. A.2 Check code algorithm A.2.1 The same “modulo 11” check digit algorithm is used for both the Core check code and the SPID check code. Version ICP Data Updates ICP/WRC016 Page 4 of 7 A.2.2 A.2.3 A.2.4 For the purposes of the check digit algorithm, the letter “W” is treated as if it were the integer 1, and the letter “S” is treated as if it were the integer 2. If the algorithm produces the result ten (10), it shall be shown as the letter “X”. Conversely, if the letter “X” has to be encoded in the algorithm, it shall be treated as if it has the value ten (10). If the SPID Core including both the serial part and the core check is represented as the string: (a) d10d9d8d7d6d5d4d3d2d1 Then the core check code shall be chosen such that: (10×d10+9×d9+8×d8 +7×d7+6×d6+ 5×d5+4×d4+3×d3+2×d2+d1) mod 11 = 0 A.2.5 If the Core check code, the Category, the Version and the SPID check are represented by the four character string: (a) d4d3d2d1 Then the SPID check code shall be chosen such that: (4×d4 + 3×d3 + 2×d2 + d1) mod 11 = 0 Principles and Objectives Principles Affected (Y/N) Description Efficiency Y The changes will support efficiency of market implementation by reducing the potential for error, and hence cost, in relation to the structure and usage of transactions between MO and TPs Proportionality N Transparency N Simplicity, cost-effectiveness and security Y Barriers to entry N Non- discrimination N Customer participation N Customer contact N Version ICP Data Updates ICP/WRC016 The changes will support cost - effectiveness of market implementation by reducing the potential for error, in relation to the structure and usage of transactions between MO and TPs Page 5 of 7 Seamless markets N No limit on upstream competition N Business Terms Objectives N Operational Terms Objectives N Market Terms Objectives Y Removal of errors in the transactions will help ensure that the market functions as intended. Description of the impact of the Change Proposal/ Charging Change Proposal on the following items, as required under the Draft Market Arrangements Code Sections 6.2.1(e), (f) and (g). Configured Item Impacted (Y/N) Wholesale-Retail Code, Part 1 (Objectives, Definitions and Principles) N Wholesale-Retail Code, Part 2 (Business Terms) N Wholesale-Retail Code, Part 3 (Operational Terms) N Wholesale-Retail Code, Part 4 (Market Terms) N Wholesale-Retail Code, Part 5 (CSDs) Y Wholesale-Retail Code, Part 6 (Operational Forms) N Appointment N Licence N Any other industry code, agreement or document (e.g. the Wholesale Contract or the MOSL Articles) (please specify) N CMOS Y Version ICP Data Updates ICP/WRC016 Description Amend CSD 0301, Appendix A to reflect changes outlined in ‘General description’ above. Required format to be incorporated into CMOS design, and reflected in the Page 6 of 7 External Interface Specification and XML Schema Definitions. Trading Party systems which interface with CMOS and other relevant Trading Party systems/ business processes. Y Scottish Core Industry Documents N The changes will enable Trading Parties correctly to design and construct their own systems Impact Assessment The changes envisaged by this Code Change Proposal impact the design of the CMOS system and in particular they impact the design of interfaces between the CMOS systems General Comment and the participants’ own systems. External Interface Specifications and XSD Schema Definitions have recently Pre-go live, consideration of been published which are in line with the current version of the timing of adoption and implementation of the change the Wholesale Retail Code and the Data Catalogue included within it and do not include the proposed SPID format. To may be relevant. avoid uncertainty regarding the detailed designs, early publication and agreement of these changes would be desirable. Cost/Benefit Estimate There is no estimate and the system is currently being based on this design to enable correct validation. Financial Benefit Estimate (Low: < £10K, Medium: £10K To £100K, High : > £100K) There has been no estimate made of the potential net financial benefit to Trading Parties. However, it is expected that such benefits would be in the form of avoided costs of: - resolving issues which arise because TP’s own data records are out of line with the market data set - making system design changes later in the system build process Description of any discussions on the topic of the Change Proposal/ Charging Change Proposal at the User Forum (as relevant) or otherwise relevant discussions with parties, as required under the Market Arrangements Code Section 6.2.1(h). None Further Comments Version ICP Data Updates ICP/WRC016 Page 7 of 7