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