‘Q’ Project “ConQuest External User Group” Meeting No. 4 25 th May 2010

1. ‘Q’ Project “ConQuest External User Group” Meeting No. 425th May 2010

2. Welcome & Introductions • Dave Addison Project Manager • Dave Ackers Customer Data Services Manager • Emma Lyndon Customer Data Services Officer

3. AGENDA • Welcome • Project Q – Update • Technical • Existing File / Record Structures • Proposal for Input / Output • Options for Record Structures – alternative • Operational • Proposed Process Changes Explained • Communication • Stakeholder Engagement • User Awareness • AOB

4. Project Q Update

5. Phase 1 Dev’t (Apr’10 Jun’10 - Aug’10 Oct’10) Pilot (Apr’10 Jun’10) Shipper Testing (Aug’10 Oct’10) Ph 1 Implementation (Sep’10 Oct’10) Phase 2 Dev’t (Sep’10 – Jan’11) Ph 2 Implementation (Jan’11) Indicative Milestone Dates Oct’09 Mar’11 Project Start (Oct’09) Modelling & Design (Oct’09 – Apr’10 May’10) Project Completion (Mar’11)

6. Existing File / Record Structures

7. Standard ConQuest Operational FilesAs Is – I’X File File Rejection Validation Resolve Communicate Pass Pass QMP csv 7 Fail QMJ csv Accept / Fail QMR csv Weekly Report QEX csv QCL csv Key: External Stakeholder xoserve ConQuest via e-mail via I’X

8. Standard ConQuest Operational FilesAs Is – EFT via e-mail File Rejection Validation Resolve Communicate Pass Pass EFT xls Template e-mail 7 Fail QMJ csv Accept / Fail QMR csv Weekly Report QEX csv QCL csv Key: External Stakeholder xoserve ConQuest via e-mail via I’X

9. Standard ConQuest Operational FilesAs Is – Screen Entry Data Provided Validation Resolve Communicate Pass Pass 7 Fail on Screen Weekly Report QEX csv QCL csv Key: External Stakeholder xoserve ConQuest via e-mail via I’X

10. Existing Operational Input File Record Structure • EFT is xls version – although converted by Users prior to submission via e-mail • Contains circa 90 fields • QMP is csv via I’X • Contains circa 90 fields • A00 – Header • “QMP” Record • Z99 - Footer

11. Existing Operational Output File Record Structure • QMJ – provides File Level Rejection • Incorrect Format, incorrect conditionality, too many/too few fields • A00 - Header • S71 – Rejected File Name • S72 – Standard Rejection Reason Record • Z99 – Trailer • QMR – Acceptances / Record Level Rejections • Invalid details – e.g. not in Stakeholder ownership, invalid information • A00 – Header • “QMR” – Rejections - As input QMP (or EFT) with additional fields: • "QMR","AC","QMP002590079“,”QMP”… • “QMR” – Acceptances - As input QMP (or EFT) with additional fields: • "QMR","RJ","QMP“… • Z99 – Trailer • If input via screen, record from “QMP” is generated from input data • Generated daily at end of day for ALL contacts raised

12. Existing Operational Output File Record Structure • QEX – weekly report • Provides weekly update of status changes • Provided in csv format • QCL – Cleared Contacts • Sufficient input data to identify input query data • QMP reference number, Raising User, Query Text • Users will receive a QCL Records per query on Resolution • Record at Operational Closure • …And if referred for Adjustment, a further QCL upon Resolution • Record if referred for Adjustment

13. Proposal for Input / Output

14. Q Operational QueriesTo Be – I’X File File Rejection Validation Resolve Communicate Pass Pass QMP csv 7 Fail QMJ csv Accept / Fail QMR csv Weekly Report QEX csv QCL csv Key: External Stakeholder xoserve ConQuest via e-mail via I’X

15. Q Operational QueriesTo Be – Web Upload File Rejection Validation Resolve Communicate Pass Pass QMP csv Template 7 Fail QMJ csv Accept / Fail QMR csv Weekly Report QEX csv QCL csv Key: External Stakeholder xoserve ConQuest via e-mail via I’X

16. Q Operational QueriesTo Be – Screen Entry Data Provided Validation Resolve Communicate Pass Pass 7 Fail on Screen Live Update to User (TBC – August 2010) Accept / Fail QMR csv Weekly Report QEX csv QCL csv Key: External Stakeholder xoserve ConQuest via e-mail via I’X

17. Options for Record Structures Proposed

18. Proposed Input File Record Structure • EFT cannot be submitted via e-mail in future • QMP is tailored to query type • For each distinct query type provide record • Look for like query types across formats – for example: • MNC / FOM / Fast Track – Single Format • RFA / CDQ / UMA – Single Format • A00 • [Q01] – Record for MNC • [Q02] – Record for ADD • Z99 • [File Names / Records Not Registered] – subject to change

19. Proposed Input File Record Structure • Example Structure:

20. Proposed Input File Record Structure • Example Structure: • Additional Fields: • Contact Type • MPRN – if provided by Shipper will be treated as ‘Fast-track / Code 12’ • QS Reference – likely to be provided by UIPs only

21. Proposed Output Option • QMJ – provides File Level Rejection • Incorrect Format, incorrect conditionality, too many/too few fields • A00 - Header • S71 – Rejected File Name • S72 – Standard Rejection Reason Record • Z99 – Trailer • QMR – Record Level Rejections • Invalid details – e.g. not in Stakeholder ownership, invalid information • A00 – Header • [Q50] – As input CUT DOWN QMP with additional fields: • “Q50","AC","QMP025590079“,”Q01”… • Z99 – Trailer • If input via screen, record from “QMP” is generated from input data • Generated daily at end of day for ALL contacts raised – NOT RESPONSE FILE TO QMP

22. Existing Operational Output File Record Structure • QEX – weekly report • Provides weekly update of status changes • Format – TBC • Views? Retain ‘As Is’? • QCL – Cleared Contacts • Sufficient input data to identify input query data • QMP reference number, Raising User, Query Text • Resolution Text and whether referred for Adjustment

23. Options for Record Structures Alternative

24. Alternative Input File Record Structures • QMP is standard across all Operational Contact Types • There will need to be change • Additional Fields • E.g. MNC added [Service_Type] • There will be more identified • Removed Fields • Retain Field space – but blank • Utilise Obsolete Fields for new fields? • Amended Field Context • Amended Data Structures • Other Options • Views

25. Filter Failure / Consumption Adjustment Contact Codes • Input (Shipper to xoserve) • .ABU (Approved Filter Failures) • .CBU (Contacts with Cons Adjustment) • Output (xoserve to Shipper) • .APR (Rejection of whole .ABU file) • .ACF (AC/RJ response to .ABU) • .CCF (AC/RJ response to records in .CBU file) • Under investigation

26. Loading of Contacts – i/o – In Summary

27. Updates from Last Meeting • IE6 Issues • Security • Application • Progress on Resolution • User Id Format • Update following request • User Testing • User Training

28. Proposed Process Changes

29. Representation Period Table

30. Meter No Creation (MNC)

31. MNC - Responses #1 We do not have any issues with the proposed changes as such, but our IT department is keen to see the new file formats. We understand that these may not have been sent out as of yet but is there any idea when the file formats will be available? The only questions that came up are: 1) In the new system if we were to send a file over the IX with the points that you have as ‘not applicable’ would this be rejected by the system? 2) The new field ‘service type’ is this with regards to meter points? So if the site has a further two meters that we supply we would need to state this? Or would this be if there was other meter points that were possibly supplied by another supplier? • The file formats will not be ready until we have completed all of the ‘To Be’ Workshops which is • planned for end June • This depends on the data item. If we can validate it and it contradicts UK-Link then it will • reject • During validation of an MNC request we check UK link for a live MPRN already existing • for the site in question. If a live MPRN is found we either reject the query or issue a data • clarification, asking if the creation request relates to a second service. By indicating • multi or single service up front, this rejection/clarification step will be significantly reduced.

32. MNC - Responses #2 We can see only one issue with this proposed change. The Mandatory field with regards to service type. In the domestic sector we are not confident that in all cases the end user will be certain that no other service is currently in situ. This would therefore be noted as a single supply and possibly result in a rejection. Obviously this should be a rare occurrence and if this was deemed as an acceptable course of action then we will just have to accept the rejection and re-raise as appropriate. The only other option on a mandatory field would be to add an ‘Unknown’ option, that perhaps could create a data clarification instead of a rejection when duplicate meter point address data is found. All other proposed changes are welcomed. We currently use the email method and will require specific instructions for sending this via the web instead. Is it possible to get a list of the rejection codes for Conquest queries. I was unable to locate these on the website ( i thought they used to be on the conquest user guide) Prior to issuing a request for M Number Creation we would expect that you will have Interrogated IAD to ensure that a live M Number does not already exist. Therefore for domestic sites you would expect in the main to only indicate single service. There are occasions when siteworks are being completed and there is a need for the ‘old’ MPRN and the ‘new’ MPRN to appear on UK Link simultaneously until the ‘old’ is decommissioned. For this scenario Indicating multi for a domestic site will aid our validation. An ‘Unknown’ field would still require the need for a data clarification or a query to be rejected should we discover an existing MPRN.

33. MNC - Responses #3 Our system users have reviewed the proposals contained within XCE200 and are happy with the changes Thank you for your confirmation We question the introduction of a warrant as suggested in bullet point 5 and would not support the introduction of this element of the proposal. As we have an obligation to act in reasonable and prudent manner we do not see the purpose or benefit of the suggested text We agree with your feedback. This message merely serves as a reminder that only bona fide requests should be submitted, to create a record on UK-Link as it resides on a GT Network. Of the 11% of submissions currently rejected we are finding a proportion of these are due to a discovery that they are part of an iGT Network. In some cases they are not discovered until some time later.

34. MNC - Responses #4 We are generally supportive of the changes proposed and feel that they would improve the efficiency of the process. • We agree that for new connections a serial number would not need to be provided but for unregistered sites where we want you to create an MPR and there is already a meter on site a serial number should be provided – maybe change this field to CM • Service Type – for flats and other multi occupancy property the customer and therefore we would not necessarily know whether there is more than one service pipe to the property – maybe this should also be CM Thank you for the endorsement. Most creation requests that fall into the MNC Code would previously have been known to you as Code 12’s. Code 12 requests do not include meter serial number as the M Number Creation is required in order to have the meter fitted at site. At creation stage the MSN is not required. We would expect in order to continue to reduce the Unregistered pot that ownership and RGMA flows are sent in following a request to create an M Number. Each flat will typically only have one service pipe that serves that address. A good source of information is the IAD system.

35. MNC - Responses #5 We welcome the changes to this process and the associated benefits of simplifying the number of fields due to be populated and the introduction of increased validation meaning a reduced number of invalid queries resulting in the quicker resolution of M Number Creation requests. We also note there will be two new fields and a passage warranting that submitted MNC requests are bona fide. We believe that this will have no significant impact on our procedures and are happy to support the introduction of these. With regards to the overall proposal, we have one concern that we would like to raise at this time. Under the current arrangements, we provide bulk requests (via QMP file and email) but do not receive confirmation that the M Number has been created and/or the details of such MPRNs. This means that we must refer back to xoserve IAD to confirm whether the new M Number has been populated. Given that one of the key drivers behind the review was to employ a Lean Sigma style approach we believe that this continues to place additional steps on the Supplier which could be removed. We note that communication of the EFT via email will end, and will be replaced with a Web or IX medium, therefore would like to understand how xoserve plan to confirm completion of such queries. Thank you for your feedback. For each individual query raised a resolution text is generated. The MNC resolution text includes the M Number that has been created or should your query have been rejected the rejection reason. To view this resolution text you do need to log onto Conquest to view each site individually or you can upload theQCLfiles which are issued via IX at the end of each day. The same will apply with the new Q system.

36. MNC - Responses #6 QP02 MNC - Current v Future' comparison spreadsheet, on row 17 (Domestic v Industrial Indicator) it is proposed that the Meter Point AQ would be used to determine this status rather than a manual input - should this be the Supply Point (site level) AQ rather than the Meter Point AQ? Could you please confirm that when a meter exchange takes place, when is the MSN provided by Xoserve? For M Number creation we are at that point in time only considering the site at meter point level rather than site level. xoserve do not provide meter serial number detail, this information will be provided to you by your MAM. This information is transmitted from the Shipper to xoserve via the RGMA flow. Having reviewed the documents, we can see no issues with the proposal. Thank you for your confirmation

37. MNC - Responses #7 It states in the future that we won’t have to specify the meter serial number. Surely they need to know the serial number to be sure there is a meter there and to check their systems to see if there is already an MPR for this meter? Also, it says in the future an explanation will not be required. Surely they need to know if we’re requesting this as a new supply or because a previous MPR has been set to dead in error. When checking that an MPR doesn’t already exist for the site, if they come across one, will they make sure they check if it is live or dead? Most creation requests that fall into the MNC Code would previously have been known to you as Code 12’s. Code 12 requests do not include meter serial number as the M Number Creation is required in order to have the meter fitted at site. At creation stage the MSN is not required. We would expect in order to continue to reduce the Unregistered pot that ownership and RGMA flows are sent in following a request to create an M Number. Yes, part of our validation in the future includes a check that an M Number doesn’t already exist and a live/dead check will be performed.

38. Generic Operational Codes

39. These all do the same thing

41. Generic Operational CodesResponses #1 We are happy for the proposals in communication QP04 in the main, however we would like to propose the following amendments to your proposals. :- Only merge codes FLE, CNQ, NOM under code FLE as they are the same query. We would like to see the PAM code kept separate from this change (see explanation for QP05 response). In addition to this we also know of 2 other Sub and Prime queries PRS & PSA – could these be merged with PAM under a new code of PSQ or something similar to group the codes together? The commonality between FLE,CNQ,NOM and PAM is that they are all file rejections. The first three are rejections that have been transmitted back to the Shipper. The PAM code is a rejection of an RGMA file which is transmitted internally to xoserve. The transaction relates to an asset update on a prime and sub configuration. On receipt of the rejection file xoserve updates the asset detail on your behalf. Your point is a valid challenge, we are looking at the merits of this with our project team.

42. Generic Operational CodesResponses #2 I have received no operational business objections to the proposed changes, and therefore are happy to proceed with the improvements Thank you for your confirmation We are happy with the proposal Thank you for your confirmation The below has been cascaded to our organisation, and no challenges to the proposed changes have been made. Thank you for your confirmation

43. Generic Operational CodesResponses #3 • Settlements do not use these codes, but the following questions came to mind:- • If the shipper short code is no longer required, will there still be separate log-ins for different shipper short code IDs? • Mentions there will be no difference between INV and OPS - will there be no way of differentiating between these types of query? • Mentions confirmation reference would not be needed with these types of query - why not? • Mentions response channel would not be needed with these types of query - why not, how will response be received? • Mentions date sent and received would not be needed with these types of query - why not, will these be system generated as they seem useful? • Shipper short code is mandatory for all contact codes. • Subject to acceptance of the generic operational and invoicing proposals the remaining • invoicing code will be ‘INV’, therefore the separation of OPS/INV is no longer required. • Confirmation reference is not applicable for file queries as for many rejections you have • been unable to take ownership of the site e.g. nomination file failure. • Response channel was a historic communication medium. Responses will be received via • a combination of screen and file. • 5. To locate the rejected file the Response File Name is the key element.

44. Generic Invoicing Codes

45. Are these Invoice Codes Required?

46. Ten Generic Invoice Codes….. Can they become One ? Do you want …. • ADJ – a current Invoicing code Or • INV – to denote an Invoicing Query UQS ADJ RBD CSE RAC MRQ ECB NTE RAT ITR

47. Generic Invoicing CodesResponses #1 We are happy for the proposals in communication QP05 in the main, however we would like to propose the following amendments to your Instead of moving PSI from invoicing query to operational, we would propose to remove the code entirely as it relates to the same query as PAM (from communication QP04) which will prevail out of the two codes. In addition to this we also know of 2 other Sub and Prime queries PRS & PSA – could these be merged with PAM under a new code of PSQ or something similar to group the codes together? This is linked to the Generic Operational Codes also. Your point is a valid challenge, we are looking at the merits of this with our project team. We will re-visit all of the Prime & Sub Contact Codes

48. Generic Invoicing CodesResponses #2 I have received no operational business objections to the proposed changes, and therefore are happy to proceed with the improvements. Thank you for your confirmation We are happy with the proposed grouping of codes into one of INV. One question, query types such as DUP which are duplicated in invoicing and operational sets, will full functionality of this type of query still be available? Yes. The below has been cascaded to our organisation, and no challenges to the proposed changes have been made. Thank you for your confirmation

49. Generic Invoicing CodesResponses #3 • We are supportive of merging the invoicing codes – ADJ, MRQ, RAC, RBD, CSE, ITR, RAT, UQS, ECB, NTE into INV however we require some more detail: • Does each of these codes have separate SLA’s, if so how will this work once they are merged into one code? • How do we identify which type of INV query we are raising – will there be sub categories? • For the inactive codes, COR, CFQ, MRF, MTR, OWN, PPM, UNQ please can you clarify that by inactive you mean that although the codes still exist within the Conquest system that users cannot raise them. • We would like clarification that this proposal is not removing our ability to raise these codes in the future but rather that it is tiding up Conquest and we already do not have the ability to raise them. • Please can you clarify that AQQ, SOQ, SQQ will now be raised under the Operational code AQQ and that AQQ is already an operational code. The document doesn’t fully state this. • AMC – will we have to raise two queries INV (invoice query) and then RFA (Operational query) or will we only need to raise one query? If so which • Retired codes – currently we understand that you recycle codes i.e. if a new code is needed could you possibly use one of the old codes i.e. COR or CFQ?

50. Generic Invoicing CodesResponses #4 • The target for completing each of these Contact types is M+2. Instead of measuring the • performance for each of the 10 Contact Codes they will be measured as a collective set. • This will be determined by the Invoice No. that you input and Charge Type code. You will • be provided with a set of Contact Explanations (drop down list). • You have not been able to raise queries on these Codes since 2004. • 4. Yes it is a tidying up of redundant Contact Codes. • 5. The three Codes – AQQ,SOQ & SQQ will be part of the generic Operational Code. • Queries to be raised using current code AQQ. • This is dependant on the nature of your query ….Rate Queries are to be raised using INV, • data challenges should be raised using RFA. • 7. Unlike Conquestwe will have the ability to create new codes on the Q system.