‘Q’ Project
“ConQuest External User Group”
Meeting No. 4
25th May 2010
Welcome & Introductions
 Dave Addison
Project Manager
 Dave Ackers
Customer Data Services Manager
 Emma Lyndon
Customer Data Services Officer
2
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
3
Project Q Update
Indicative Milestone Dates
Oct’09
Mar’11
Project Start (Oct’09)
Modelling & Design (Oct’09 – Apr’10 May’10)
Pilot (Apr’10 Jun’10)
Phase 1 Dev’t (Apr’10 Jun’10 - Aug’10 Oct’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)
Project Completion (Mar’11)
5
Existing File / Record Structures
Standard ConQuest Operational Files
As Is – I’X File
QMP csv
QMJ csv
QMR csv
Pass
Pass
File
Validation
Rejection
7
Resolve
Commu
nicate
Fail
Accept / Fail
Weekly Report
QEX csv
QCL csv
Key:
External
Stakeholder
xoserve
ConQuest
via email
via I’X
7
Standard ConQuest Operational Files
As Is – EFT via e-mail
EFT xls
Template
e-mail
QMJ csv
QMR csv
Pass
Pass
File
Validation
Rejection
7
Resolve
Commu
nicate
Fail
Accept / Fail
Weekly Report
QEX csv
QCL csv
Key:
External
Stakeholder
xoserve
ConQuest
via email
via I’X
8
Standard ConQuest Operational Files
As Is – Screen Entry
Pass
Data Pass
Validation
Provided
7
Resolve
Commu
nicate
Fail on
Screen
Weekly Report
QEX csv
QCL csv
Key:
External
Stakeholder
xoserve
ConQuest
via email
via I’X
9
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
10
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
11
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
12
Proposal for Input / Output
Q Operational Queries
To Be – I’X File
QMP csv
QMJ csv
QMR csv
Pass
Pass
File
Validation
Rejection
7
Resolve
Commu
nicate
Fail
Accept / Fail
Weekly Report
QEX csv
QCL csv
Key:
External
Stakeholder
xoserve
ConQuest
via email
via I’X
14
Q Operational Queries
To Be – Web Upload
QMP csv
Template
QMJ csv
QMR csv
Pass
Pass
File
Validation
Rejection
7
Resolve
Commu
nicate
Fail
Accept / Fail
Weekly Report
QEX csv
QCL csv
Key:
External
Stakeholder
xoserve
ConQuest
via email
via I’X
15
Q Operational Queries
To Be – Screen Entry
Pass
Data Pass
Validation
Provided
QMR csv
7
Resolve
Commu
nicate
Fail on
Screen
Live Update to User (TBC –
August 2010)
Accept / Fail
Weekly Report
QEX csv
QCL csv
Key:
External
Stakeholder
xoserve
ConQuest
via email
via I’X
16
Options for Record Structures
Proposed
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
18
Proposed Input File Record Structure
 Example Structure:
RT_Q01_MNC_CREATION
Q01 MNC Creation Record
OCCURS MAX: n/a
RECORD/FIELD NAME
TRANSACTION_TYPE
ORGANISATION SHORT CODE
OPT
M
M
DOM
T
T
LNG
3
[3]
DEC
0
0
USER_ID
M
T
[20]
0
CURRENT_ADDRESS_BUILDING_NUMBER
O
N
6
0
CURRENT_ADDRESS_SUB_BUILDING_ NAME
CURRENT_ADDRESS _BUILDING_NAME
O
O
T
T
30
50
0
0
CURRENT_ADDRESS_PRINCIPAL_STREET
CURRENT_ADDRESS_DEPENDANT_LOCALITY
CURRENT_ADDRESS_POST_TOWN
CURRENT_ADDRESS_POSTCODE
DELIVERY_POINT_ALIAS
M
M
M
M
O
T
T
T
T
T
35
35
35
8
50
0
0
0
0
0
[SERVICE_TYPE]
M
T
[1]
0
METER_POINT_AQ
USER_PRIORITY_FLAG
M
O
N
T
10
[1]
0
0
Total
DESCRIPTION
A record type to identify the MNC Record – e.g. Q01
A reference provided by the User to identify the
organisation raising the contact. E.g. Shipper Short Code
A unique User Id assigned to the User that should receive
any interim clarifications required during contact
resolution.
Must be populated if CURRENT_ADDRESS
_BUILDING_NAME is blank.
Must be populated if CURRENT_ADDRESS
_BUILDING_NUMBER is blank.
Additional information may be provided to assist in
identifying unique address – e.g. plot number, or
alternative names.
[An identifier to denote whether multiple meter point
services are present at the quoted address. Allowable
Values: S – Single, M – Multiple.]
The AQ to be attributed to the Meter Point upon creation.
[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. ]
[287]
19
Proposed Input File Record Structure
RT_Q01_MNC_CREATION
Q01 MNC Creation Record
OCCURS MAX: n/a
RECORD/FIELD NAME
TRANSACTION_TYPE
CONTACT_TYPE
ORGANISATION SHORT CODE
OPT
M
M
M
DOM
T
T
T
LNG
3
3
[3]
DEC
0
0
0
USER_ID
M
T
[20]
0
METER_POINT_REFERENCE_NUMBER
O
N
10
0
CURRENT_ADDRESS_BUILDING_NUMBER
O
N
6
0
CURRENT_ADDRESS_SUB_BUILDING_ NAME
CURRENT_ADDRESS _BUILDING_NAME
O
O
T
T
30
50
0
0
M
M
M
M
O
T
T
T
T
T
35
35
35
8
50
0
0
0
0
0
 Example Structure:
Additional Fields:
CURRENT_ADDRESS_PRINCIPAL_STREET
CURRENT_ADDRESS_DEPENDANT_LOCALITY
CURRENT_ADDRESS_POST_TOWN
CURRENT_ADDRESS_POSTCODE
DELIVERY_POINT_ALIAS
DESCRIPTION
A record type to identify the MNC Record – e.g. Q01
Contact Type: MNC
A reference provided by the User to identify the
organisation raising the contact. E.g. Shipper Short Code
A unique User Id assigned to the User that should receive
any interim clarifications required during contact
resolution.
Must be provided if contact provided by [UIP]. May be
provided by [Shipper] where known.
Must be populated if CURRENT_ADDRESS
_BUILDING_NAME is blank.
Must be populated if CURRENT_ADDRESS
_BUILDING_NUMBER is blank.
•
Contact Type
•
MPRN – if provided
by
Shipper
will
be treated as ‘Fast-track
M
T
[1]
0
/ Code 12’
[SERVICE_TYPE]
METER_POINT_AQ
USER_PRIORITY_FLAG
M
N
10
0
QS_REFERENCE_NUMBER
Total
O
[T]
[20]
[320]
0
•
Additional information may be provided to assist in
identifying unique address – e.g. plot number, or
alternative names.
[An identifier to denote whether multiple meter point
services are present at the quoted address. Allowable
Values: S – Single, M – Multiple.]
The AQ to be attributed to the Meter Point upon creation.
[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. ]
May be provided where known.
0
QS Reference –O likelyT to be[1]provided
by UIPs only
20
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
21
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
22
Options for Record Structures
Alternative
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
24
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
25
Loading of Contacts – i/o – In Summary
Method
Input Format
Acknowledgement
Method
Cleared
Notification
Screen
Manual Input
using Screens
Immediate User
Feedback
QMR via I’X
*.QCL
Web Interface
(max 100-200
records)
Upload csv
Format (revised
*.QMP)
Visible on Screen *.QCL
(delay)
QMJ via I’X
QMR via I’X
I’X
(max records TBC
– 000s)
Revised *.QMP
Visible on Screen *.QCL
QMJ via I’X
QMR.. etc
26
Updates from Last Meeting
 IE6 Issues
 Security
 Application
 Progress on Resolution
 User Id Format
 Update following request
 User Testing
 User Training
27
Proposed Process Changes
Representation Period Table
Process
Meter No
Creation
(MNC)
Generic
Operational
Codes
Comm
No.
Date Issued
Representation
Period End
Issued to UK-Link
Committee
Representation
Period End
Status
QP02
21st April
6th May
14th May
28th May
9 respondents
28th May
14th June
or
or
QP04
28th April
13th May
11th
June
25th
June
28th May
14th June
or
or
Generic
Invoicing
Codes
QP05
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
28th April
13th May
11th
June
25th
5 respondents
5 respondents
June
29
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 Benefits
A 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
30
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.
31
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.
32
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.
33
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.
34
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.
35
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
36
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.
37
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 Benefits
Create 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
38
These all do the same thing
Operational Codes
Contact Code
Description
Total Count in Conquest
Date Last Logged
FLE
Challenge to the response to an IX file
sent in by a Shipper
32
21/08/2008
CNQ
Challenge the reason for a specific
response to a Confirmation file
67
18/06/2009
NOM
Challenge the reason for a specific
response to a Nomination file
PAM
Instruction to amend current meter
details within a Prime and Sub Deduct
Configuration
39
17/04/2009
*2578 (logged by xoserve)
16/11/2009
Proposal
Merge under one
contact code
FLE
39
Operational Codes
Contact
Code
Description
Total Count in Conquest
Date Last Logged
AQQ
Incorrect AQ does not
match UK Link
11
20/12/2006
SOQ
Incorrect SOQ or
Bottom Stop SOQ
23
28/02/2007
SQQ
Billed SOQ is
incorrect, does not
match UK Link
8
08/02/2005
Challenge to DM Sites
following or prior to
invoice issue
(Freestanding and
Prime and Sub sites).
0
Instruction to amend
current meter details
within a Prime and
Sub Deduct
Configuration
13
DMR
PSI
Proposal
Move to Operational Contact Codes
06/04/2005
40
Generic Operational Codes
Responses #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.
41
Generic Operational Codes
Responses #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
42
Generic Operational Codes
Responses #3
Settlements do not use these codes, but the following questions came to mind:-
1.
2.
3.
4.
5.
1.
2.
3.
4.
5.
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.
To locate the rejected file the Response File Name is the key element.
43
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
787 in 10 years
(for Codes that could be merged)
(for Codes that are duplicated or
redundant)
Proposals and Benefits
Remove 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
44
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
*DUP
Any contact challenging two MPRN's for one service to a
property and where the asset information matches
969
22/01/2005
*DMQ
Challenge to the consumption billed in realtion to DM
Datalogger Data
8
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
45
Ten Generic Invoice Codes…..
Can they become One ?
RBD
UQS
ADJ
CSE
RAC
Do you want ….
 ADJ – a current Invoicing code
Or
 INV – to denote an Invoicing
Query
MRQ
ECB
NTE
ITR
RAT
46
Generic Invoicing Codes
Responses #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
47
Generic Invoicing Codes
Responses #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
48
Generic Invoicing Codes
Responses #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:
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?
49
Generic Invoicing Codes
Responses #4
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.
50
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 Benefits
Re-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
Introduction of a new 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….’
Introduction of a new field :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
Introduction of a new field :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
51
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 Benefits
Introduction 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
Introduction of a new field :To Date for DM Site
Linked to above
Introduction of a new field :Site Contact (person)
Assists the Daily meter Service provider gain access to the
site
Introduction of a new field :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
52
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 Benefits
Introduction 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
Introduction of a new field :Site Contact (person)
Assists the engineer gain access to the site
Introduction of a new field :Site Tel. No.
Same as above
Introduction of a new field :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
53
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
54
Communication
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
56
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>.
57
AOB
 Next Meeting
 Venue – Elexon ~ Wednesday 23rd |June
58