‘q’ project “conquest external user group” meeting no. 4 25 th may 2010

‘‘Q’ Project Q’ Project

“ConQuest External User Group” “ConQuest External User Group” Meeting No. 4Meeting No. 4

2525thth May 2010 May 2010

2

Dave Addison Project Manager

Dave Ackers Customer Data Services Manager

Emma Lyndon Customer Data Services Officer

Welcome & Introductions

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

Project Q UpdateProject Q Update

5

Indicative Milestone Dates

Project Start (Oct’09)

Modelling & Design (Oct’09 – Apr’10 May’10)

Phase 1 Dev’t (Apr’10 Jun’10 - Aug’10 Oct’10)

Shipper Testing (Aug’10 Oct’10)

Oct’09

Ph 1 Implementation (Sep’10 Oct’10)

Phase 2 Dev’t (Sep’10 – Jan’11)

Ph 2 Implementation (Jan’11)

Project Completion (Mar’11)

Mar’11

Pilot (Apr’10 Jun’10)

Existing File / Record StructuresExisting File / Record Structures

7

Standard ConQuest Operational FilesAs Is – I’X File

File RejectionQMP csv

External Stakeholder

xoserve ConQuest

Validation ResolveCommunicate

QMJ csv

QMR csv

QEX csv

QCL csv

Fail

Pass Pass

Weekly Report

7

via e-mail

via I’X

Key:

Accept / Fail

8

Standard ConQuest Operational FilesAs Is – EFT via e-mail

File Rejection

EFT xls Template


xoserve ConQuest


QMJ csv

QMR csv

QEX csv

QCL csv

Fail

Accept / Fail

Pass Pass

Weekly Report

7e-mail

via e-mail

via I’X

Key:

9

Standard ConQuest Operational FilesAs Is – Screen Entry

Data Provided


xoserve ConQuest


QEX csv

QCL csv

Pass Pass

Weekly Report

7

Fail on Screen

via e-mail

via I’X

Key:

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


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

Proposal for Input / OutputProposal for Input / Output

14

Q Operational QueriesTo Be – I’X File

File RejectionQMP csv


xoserve ConQuest


QMJ csv

QMR csv

QEX csv

QCL csv

Fail

Pass Pass

Weekly Report

7

Accept / Fail

via e-mail

via I’X

Key:

15

Q Operational QueriesTo Be – Web Upload

File Rejection

QMP csv Template


xoserve ConQuest


QMJ csv

QMR csv

QEX csv

QCL csv

Fail

Pass Pass

Weekly Report

7

Accept / Fail

via e-mail

via I’X

Key:

16

Q Operational QueriesTo Be – Screen Entry

Data Provided


xoserve ConQuest


QMR csv

QEX csv

QCL csv

Pass Pass

Weekly Report

7

Fail on Screen

Live Update to User (TBC – August 2010)

Accept / Fail

via e-mail

via I’X

Key:

Options for Record StructuresOptions for Record Structures

ProposedProposed

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


Example Structure: RT_Q01_MNC_CREATION Q01 MNC Creation Record OCCURS MAX: n/a RECORD/FIELD NAME OPT DOM LNG DEC DESCRIPTION TRANSACTION_TYPE M T 3 0 A record type to identify the MNC Record – e.g. Q01 ORGANISATION SHORT CODE M T [3] 0 A reference provided by the User to identify the

organisation raising the contact. E.g. Shipper Short Code USER_ID M T [20] 0 A unique User Id assigned to the User that should receive

any interim clarifications required during contact resolution.

CURRENT_ADDRESS_BUILDING_NUMBER O N 6 0 Must be populated if CURRENT_ADDRESS _BUILDING_NAME is blank.

CURRENT_ADDRESS_SUB_BUILDING_ NAME O T 30 0 CURRENT_ADDRESS _BUILDING_NAME O T 50 0 Must be populated if CURRENT_ADDRESS

_BUILDING_NUMBER is blank. CURRENT_ADDRESS_PRINCIPAL_STREET M T 35 0 CURRENT_ADDRESS_DEPENDANT_LOCALITY M T 35 0 CURRENT_ADDRESS_POST_TOWN M T 35 0 CURRENT_ADDRESS_POSTCODE M T 8 0 DELIVERY_POINT_ALIAS O T 50 0 Additional information may be provided to assist in

identifying unique address – e.g. plot number, or alternative names.

[SERVICE_TYPE] M T [1] 0 [An identifier to denote whether multiple meter point services are present at the quoted address. Allowable Values: S – Single, M – Multiple.]

METER_POINT_AQ M N 10 0 The AQ to be attributed to the Meter Point upon creation. USER_PRIORITY_FLAG O T [1] 0 [Users may use this flag to denote that this contact needs

greater priority resolution. Users have a cap of the number of contacts that may be flagged in this manner. ]

Total [287]

20


Example Structure:

RT_Q01_MNC_CREATION Q01 MNC Creation Record OCCURS MAX: n/a RECORD/FIELD NAME OPT DOM LNG DEC DESCRIPTION TRANSACTION_TYPE M T 3 0 A record type to identify the MNC Record – e.g. Q01 CONTACT_TYPE M T 3 0 Contact Type: MNC ORGANISATION SHORT CODE M T [3] 0 A reference provided by the User to identify the

organisation raising the contact. E.g. Shipper Short Code USER_ID M T [20] 0 A unique User Id assigned to the User that should receive

any interim clarifications required during contact resolution.

METER_POINT_REFERENCE_NUMBER O N 10 0 Must be provided if contact provided by [UIP]. May be provided by [Shipper] where known.

CURRENT_ADDRESS_BUILDING_NUMBER O N 6 0 Must be populated if CURRENT_ADDRESS _BUILDING_NAME is blank.

CURRENT_ADDRESS_SUB_BUILDING_ NAME O T 30 0 CURRENT_ADDRESS _BUILDING_NAME O T 50 0 Must be populated if CURRENT_ADDRESS

_BUILDING_NUMBER is blank. CURRENT_ADDRESS_PRINCIPAL_STREET M T 35 0 CURRENT_ADDRESS_DEPENDANT_LOCALITY M T 35 0 CURRENT_ADDRESS_POST_TOWN M T 35 0 CURRENT_ADDRESS_POSTCODE M T 8 0 DELIVERY_POINT_ALIAS O T 50 0 Additional information may be provided to assist in

identifying unique address – e.g. plot number, or alternative names.

[SERVICE_TYPE] M T [1] 0 [An identifier to denote whether multiple meter point services are present at the quoted address. Allowable Values: S – Single, M – Multiple.]

METER_POINT_AQ M N 10 0 The AQ to be attributed to the Meter Point upon creation. USER_PRIORITY_FLAG O T [1] 0 [Users may use this flag to denote that this contact needs

greater priority resolution. Users have a cap of the number of contacts that may be flagged in this manner. ]

QS_REFERENCE_NUMBER O [T] [20] 0 May be provided where known. Total [320]

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


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

Options for Record StructuresOptions for Record Structures

AlternativeAlternative

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

Method Input Format Acknowledgement Method

Cleared Notification

Screen Manual Input using Screens

Immediate User FeedbackQMR via I’X

*.QCL

Web Interface (max 100-200 records)

Upload csv Format (revised *.QMP)

Visible on Screen (delay)QMJ via I’XQMR via I’X

*.QCL

I’X

(max records TBC – 000s)

Revised *.QMP Visible on ScreenQMJ via I’XQMR.. etc

*.QCL

27

Updates from Last Meeting

IE6 Issues Security Application

Progress on Resolution

User Id Format Update following request

User Testing

User Training

Proposed Process ChangesProposed Process Changes

29

Representation Period Table

Process Comm No.

Date Issued Representation

Period End

Issued to UK-Link Committee

Representation Period End

Status

Meter No Creation (MNC)

QP02 21st April 6th May 14th May 28th May 9 respondents

Generic Operational

CodesQP04 28th April 13th May

28th May or

11th June

14th June or

25th June5 respondents

Generic Invoicing Codes

QP05 28th April 13th May28th May

or

11th June

14th June or

25th June5 respondents

Address Amendment

(ADD)QP07 12th May 26th May 11th June 25th June

Daily Meter Query (DMQ)

QP10 19th May 3rd June 11th June 25th June

Prime & Sub Meter

(PRS)QP11 19th May 3rd June 11th June 25th June

30

Meter No Creation (MNC)

Definition : A found live Supply Point (not tagged) without an MPRN

Volume : 13.5k per annum

Rejected cases 1.5k - (11%)

Proposals and BenefitsA reduced need to populate 14 Mandatory data fields ? The Mandatory data items is now 7 and a further 2 being

Conditional Mandatory. The 14 have been removed as they are either not necessary or data can be derived

3 Fields – Conditionality changed to become Mandatory Current Principal Street, Current Address Post Town, Meter Point AQ

The changing of the conditionality will aid validation and improve a successful outcome

2 Fields – Introduced to aid validation Service Type (multi / single) Delivery Point Alias

The judgment as to whether to create an MPRN is impeded by not being privy to some localised information. These 2 elements will assist in the decision making

Bulk upload of Contacts via Web A speedier ability to send us Contacts than the traditional single entries via a screen or email attachment

A passage that states that reasonable endeavours have been made to certify that the submissions should reside on UK-Link

Hopefully reduces the rejected cases and the potential for incorrectly creating records on UK-Link when they should be on an iGT Network database

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

1) This depends on the data item. If we can validate it and it contradicts UK-Link then it will reject

2) 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 domesticsites you would expect in the main to only indicate single service. There are occasions whensiteworks are being completed and there is a need for the ‘old’ MPRN and the ‘new’ MPRN toappear 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 youas 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 notrequired. We would expect in order to continue to reduce the Unregistered pot that ownershipand 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 the QCL files 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 levelrather 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.


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 youas 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 notrequired. We would expect in order to continue to reduce the Unregistered pot that ownershipand 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/deadcheck will be performed.

38

Generic Operational Codes

Definition : A coined term for describing 4 similar Contact Codes with low volume of usage

Volume : 138 in 10 years

Proposals and BenefitsCreate a single Electronic File Format that does the job of 4 similarly fashioned set of data fields

Limits the selection of Contact Codes to a single ‘fit for purpose’ EFT

Reduce range of Mandatory and Optional fields Hones the current set of fields from 25 down to 11

Specify the essential (Mandatory) set of data needed from the outset

Assists the validation and ultimately improves the investigation / resolution of enquiries relating to file transmission errors

39

These all do the same thing

Operational Codes

Contact Code Description Total Count in Conquest Date Last Logged Proposal

FLEChallenge to the response to an IX file sent in by a Shipper

32 21/08/2008

Merge under one contact code

FLE

CNQChallenge the reason for a specific response to a Confirmation file

67 18/06/2009

NOMChallenge the reason for a specific response to a Nomination file

39 17/04/2009

PAMInstruction to amend current meter details within a Prime and Sub Deduct Configuration

*2578 (logged by xoserve) 16/11/2009

40

Operational Codes

Contact Code

Description Total Count in Conquest Date Last Logged Proposal

AQQIncorrect AQ does not match UK Link

11 20/12/2006

Move to Operational Contact Codes

SOQIncorrect SOQ or Bottom Stop SOQ

23 28/02/2007

SQQBilled SOQ is incorrect, does not match UK Link

8 08/02/2005

DMR

Challenge to DM Sites following or prior to invoice issue (Freestanding and Prime and Sub sites).

0

PSI

Instruction to amend current meter details within a Prime and Sub Deduct Configuration

13 06/04/2005

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 isa rejection of an RGMA file which is transmitted internally to xoserve. The transaction relatesto an asset update on a prime and sub configuration. On receipt of the rejection file xoserveupdates 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


I have received no operational business objections to the proposed changes, and therefore

are happy to proceed with the improvements


We are happy with the proposal



The below has been cascaded to our organisation, and no challenges to the proposed changes have been made.

43


Settlements do not use these codes, but the following questions came to mind:-

1. If the shipper short code is no longer required, will there still be separate log-ins for different shipper short code IDs?

2. Mentions there will be no difference between INV and OPS - will there be no way of differentiating between these types of query?

3. Mentions confirmation reference would not be needed with these types of query - why not?

4. Mentions response channel would not be needed with these types of query - why not, how will response be received?

5. 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?

1. Shipper short code is mandatory for all contact codes.2. 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.3. 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.4. 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

Definition :A coined term for describing similar Contact Codes with low volume of usage (or in some instances, not used for 4 years or greater)

Volume : 962 in 10 years (for Codes that could be merged)

787 in 10 years (for Codes that are duplicated or redundant)

Proposals and BenefitsRemove 7 Invoicing Codes :-

UNQ / PPM / OWN / MTR / MRF / CFQ / COR

as they are either not fitting for current needs – they have been inactive for 6 years or longer

Reduces list of Contact Codes

Remove 3 Invoicing Codes :-

ISO / DMQ / DUP

as they have duplicated Code in the Operational set of Contact Codes

Avoids confusion as to which Code to use (wrong selection currently being made)

Remove 7 Invoicing Codes :-

AMC / EXT / EUC / IRC / LIA / MFF / OVR

as they can be via the proposed generic INV Contact Code

There are other Contact Codes that serve the same purpose

Create a Contact Code for raising and resolving Daily Metered configuration queries - DMR

Enables you to raise this type of Query through a secure and auditable system rather than present email route

45

Are these Invoice Codes Required?

Invoicing Queries

Contact Code Contact Description Total Count in Conquest Date Last Logged

*AMC Challenge to the meter asset invoice 83 27/10/2004

*DUPAny contact challenging two MPRN's for one service to a

property and where the asset information matches969 22/01/2005

*DMQChallenge to the consumption billed in realtion to DM

Datalogger Data8 27/07/2007

*EXT Challenge to the Exit Zone for an invoiced charge 3 04/10/2002

*EUC Challenge to the End User Category for an invoiced charge 1 10/01/2007

*LIA Challenge to the charges levied on the Ad-hoc invoice 9 25/10/2001

*MFF Meter read frequency used to bill this site is incorrect 0

*OVR Challenge to the validity of an overrun charge 7 21/05/2004

COR (Inactive) Challenge to NDM Corrector Queries 1 19/08/2003

CFQ (Inactive) Challenge to the correction factor 1 11/04/2003

MRF (Inactive) Incorrect Meter Read Frequency 9 05/03/2002

MTR (Inactive) Challenge to the attributes of a meter 67 03/06/2004

OWN (|nactive) Incorrect Ownership 114 08/05/2002

UNQ (Inactive) Incorrect Set Up of a Unique Site 3 01/08/2001

46

Ten Generic Invoice Codes…..

Do you want …. ADJ – a current Invoicing code Or INV – to denote an Invoicing

Query

MRQ

RBD

CSE

ADJ

RAT

RAC

ITR

UQS

ECB

NTE

Can they become One ?

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


I have received no operational business objections to the proposed changes, and therefore

are happy to proceed with the improvements.


Yes.

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?

The below has been cascaded to our organisation, and no challenges to the proposed changes have been made.


49


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:

1. Does each of these codes have separate SLA’s, if so how will this work once they are merged into one code?

2. How do we identify which type of INV query we are raising – will there be sub categories?

3. 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.

4. 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.

5. 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.

6. 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

7. 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


1. 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.

2. 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).

3. 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.

6. 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 Conquest we will have the ability to create new codes on the Q system.

51

Address Amendments (ADD)

Definition : A submission of an enhanced or different address to the one held on UK-Link

Volume : 63k per annum

Rejected cases 13.9k - (22%)

Proposals and BenefitsRe-label (change) the current field description for 8 fields that start ‘Alternative Address…..’

Eliminates ambiguity as it suggests that this address will be an alternative to the one that UK-Link will continue to hold

Introduction of a new field :-

Current Address Delivery Point Alias

The current address format doesn’t provide the ability to capture helpful pinpointing address details in a dedicated field


Alternative Address Delivery Point Alias

Expands the make-up of an address (not a postal address) for holding e.g ‘Adjacent to….’ Or ‘Rear of….’


Service Type (single or multi)

This will aid our validating of your ADD request as sometimes we will not be aware that there is more than one service pipe at the same address


Swapped Address

Enables you to notify us of two addresses that have crossed information

Introduction of a new field :-Swapped Address MPRN

Linked to Swapped Address, the associated MPRN will direct us to the record that you believe is confused with another

52

Daily Meter Query (DMQ)

Definition : A request for us to investigate DM read(s) or equipment

Volume : 733 per annum

Rejected cases 590 - (80%)

Proposals and BenefitsIntroduction of a new field :-

From Date for DM site

Validates the submission of the Contact by testing that the disputed period during which the fault occurred is within the period of ownership of the site


To Date for DM Site

Linked to above


Site Contact (person)

Assists the Daily meter Service provider gain access to the site


Site Tel. No.

Same as above

Nine of the ten fields are Mandatory Reduces the current reject rate by ensuring that all the required information is provided from the outset

53

Prime & Sub Meter (PRS)

Definition : A challenge to the link code showing on UK-Link in relation to a Prime and Sub configuration or a free standing meter

Volume : 146 per annum

Rejected cases 88 - (60%)

Proposals and BenefitsIntroduction of a new field :-

MPRN Link Code Status (claimed)

Provides a dedicated field for stating the correct link code. This will be in the form of a drop-down list. Currently this information is provided in the midst of free format text


Site Contact (person)

Assists the engineer gain access to the site


Site Tel. No.

Same as above


Availability Information (free text)

Useful supporting information that will assist with access to the meter(s)

Four fields changed to Mandatory conditionality and Thirteen newly introduced fields

Will greatly improve the success rate of resolution and decrease rejection rate

54

Coming Up…..

ISO Removing need for Confirmation Number Asking for the Address details to eradicate the need to raise data

clarification requests (DCs)

MOD517 This will be known as ECO – Erroneous Confirmation

UNC This will follow the ADD process and use the same EFT Template

FOM Fast Track This will follow the MNC process and use the same EFT Template

CommunicationCommunication

56

Communication - Stakeholder Engagement

UTILITY INFRASTRUCTURE PROVIDERS – (U.I.P.s) Spoken to 5 major Utility Infrastructure Providers – w/c 3rd May Presented the proposed approach for Meter No. Creation process (FOM) Overall, the changes proposed were accepted in principle Formal presentation to be made / Representation period to follow The remaining 31 UIPs to also be contacted

DAILY METER SERVICE PROVIDER Presented an overview of the Q Project and the potential for DMSP to

interface with Q system xoserve is presently the conduit between DMSP and Shipper for the Daily

Meter Query (DMQ) process Web link will enable DMSPs to engage directly with pertinent Shipper

57

Communication - User Awareness

Conquest system to have a banner message placed on the Log-On screen.

Draft wording as follows

NOTICE TO ALL CONQUEST USERS

CONQUEST IS TO BE REPLACED – WILL YOU BE READY?

ConQuest is due for replacement later this year. We are presently liaising with our customers on the transition programme and involving them in the

scope of changes. If you require any further information please visit

xoserve.com <link>.

58

AOB

Next Meeting Venue – Elexon ~ Wednesday 23rd |June

‘q’ project “conquest external user group” meeting no. 4 25 th may 2010

Documents