Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Weekly Report Template - PowerPoint

VIEWS: 287 PAGES: 58

Weekly Report Template document sample

More Info
									          „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

                  File    Pass           Pass                      Commu
QMP csv         Rejection
                              Validation        7   Resolve
                                                                    nicate

                Fail
  QMJ csv

                       Accept / Fail
  QMR csv

                                  Weekly Report
  QEX csv


  QCL csv
                                                        Key:
 External      xoserve                                    via e-
                                                                       via I‟X
 Stakeholder   ConQuest                                    mail



                                                                                 7
       Standard ConQuest Operational Files
              As Is – EFT via e-mail

 EFT xls    e-mail      File    Pass           Pass                      Commu
Template              Rejection
                                    Validation        7   Resolve
                                                                          nicate

                      Fail
  QMJ csv

                             Accept / Fail
  QMR csv

                                        Weekly Report
  QEX csv


  QCL csv
                                                              Key:
 External            xoserve                                    via e-
                                                                             via I‟X
 Stakeholder         ConQuest                                    mail



                                                                                       8
      Standard ConQuest Operational Files
              As Is – Screen Entry

                  Data Pass           Pass                      Commu
                 Provided
                           Validation        7   Resolve
                                                                 nicate
              Fail on
              Screen




                               Weekly Report
 QEX csv


 QCL csv
                                                     Key:
External      xoserve                                  via e-
                                                                    via I‟X
Stakeholder   ConQuest                                  mail



                                                                              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

                   File    Pass           Pass                      Commu
QMP csv          Rejection
                               Validation        7   Resolve
                                                                     nicate

                 Fail
  QMJ csv

                        Accept / Fail
  QMR csv

                                   Weekly Report
  QEX csv


  QCL csv
                                                         Key:
 External       xoserve                                    via e-
                                                                        via I‟X
 Stakeholder    ConQuest                                    mail



                                                                                  14
                Q Operational Queries
                 To Be – Web Upload

QMP csv             File    Pass           Pass                      Commu
Template          Rejection
                                Validation        7   Resolve
                                                                      nicate

                  Fail
   QMJ csv

                         Accept / Fail
   QMR csv

                                    Weekly Report
   QEX csv


   QCL csv
                                                          Key:
  External       xoserve                                    via e-
                                                                         via I‟X
  Stakeholder    ConQuest                                    mail



                                                                                   15
                  Q Operational Queries
                  To Be – Screen Entry

                         Data Pass           Pass                       Commu
                        Provided
                                  Validation         7   Resolve
                                                                         nicate
                    Fail on
                    Screen
              Live Update to User (TBC –
              August 2010)
                              Accept / Fail
 QMR csv

                                         Weekly Report
 QEX csv


 QCL csv
                                                             Key:
External             xoserve                                   via e-
                                                                            via I‟X
Stakeholder          ConQuest                                   mail



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




                                                                                                                              19
                 Proposed Input File Record Structure
   RT_Q01_MNC_CREATION
   Q01 MNC Creation Record
   OCCURS MAX: n/a
 Example Structure:
   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.
             Additional Fields:
   CURRENT_ADDRESS_PRINCIPAL_STREET
   CURRENT_ADDRESS_DEPENDANT_LOCALITY
                                        M
                                        M
                                              T
                                              T
                                                    35
                                                    35
                                                            0
                                                            0
   CURRENT_ADDRESS_POST_TOWN            M     T     35      0
             •      Contact Type
   CURRENT_ADDRESS_POSTCODE
   DELIVERY_POINT_ALIAS
                                        M
                                        O
                                              T
                                              T
                                                    8
                                                    50
                                                            0
                                                            0     Additional information may be provided to assist in
                                                                  identifying unique address – e.g. plot number, or
             •
   [SERVICE_TYPE]
                    MPRN – if provided by Shipper will be treated as „Fast-track
                                  M    T     [1]  0
                                                                  alternative names.
                                                                  [An identifier to denote whether multiple meter point
                    / Code 12‟                                    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.
             •      QS Reference – likely to be provided by UIPs only
   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]




                                                                                                                                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       Cleared
                                         Method           Notification

Screen             Manual Input      Immediate User   *.QCL
                   using Screens     Feedback
                                     QMR via I‟X

Web Interface      Upload csv        Visible on Screen *.QCL
(max 100-200       Format (revised   (delay)
records)           *.QMP)            QMJ via I‟X
                                     QMR via I‟X
I‟X                Revised *.QMP     Visible on Screen *.QCL
(max records TBC                     QMJ via I‟X
– 000s)                              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      Comm   Date Issued   Representation   Issued to UK-Link   Representation      Status
               No.                  Period End         Committee         Period End

 Meter No
 Creation     QP02    21st April      6th May           14th May           28th May      9 respondents
  (MNC)
 Generic                                                28th May          14th June
Operational   QP04    28th April      13th May                 or                or      5 respondents
  Codes                                                 11th   June       25th   June
  Generic                                               28th May          14th June
 Invoicing    QP05    28th April      13th May                 or                or      5 respondents
  Codes                                                 11th   June       25th   June
 Address
Amendment     QP07    12th May        26th May          11th June         25th June
  (ADD)
Daily Meter
  Query       QP10    19th May        3rd June          11th June         25th June
  (DMQ)
 Prime &
Sub Meter     QP11    19th May        3rd June          11th June         25th June
  (PRS)


                                                                                                         29
                               Meter No Creation (MNC)

Definition : A found live Supply Point                       Volume : 13.5k per annum
(not tagged) without an MPRN                                 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        The changing of the conditionality will aid validation and
 Current Principal Street,                                  improve a successful outcome
 Current Address Post Town,
 Meter Point AQ
2 Fields – Introduced to aid validation                      The judgment as to whether to create an MPRN is impeded
 Service Type (multi / single)                              by not being privy to some localised information. These 2
 Delivery Point Alias                                       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        Hopefully reduces the rejected cases and the potential for
been made to certify that the submissions should reside on   incorrectly creating records on UK-Link when they should be
UK-Link                                                      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                       Volume : 138 in 10 years
4 similar Contact Codes with low
volume of usage

                                         Proposals and Benefits
Create a single Electronic File Format that does the job of 4   Limits the selection of Contact Codes to a single „fit for
similarly fashioned set of data fields                          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       Assists the validation and ultimately improves the
the outset                                                      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        Proposal




               Challenge to the response to an IX file
    FLE                                                             32                  21/08/2008
               sent in by a Shipper




               Challenge the reason for a specific
   CNQ                                                              67                  18/06/2009
               response to a Confirmation file

                                                                                                        Merge under one
                                                                                                           contact code
   NOM
               Challenge the reason for a specific
                                                                    39                  17/04/2009             FLE
               response to a Nomination file




               Instruction to amend current meter
   PAM         details within a Prime and Sub Deduct     *2578 (logged by xoserve)      16/11/2009
               Configuration




                                                                                                                          39
                                                     Operational Codes
Contact
               Description        Total Count in Conquest      Date Last Logged               Proposal
   Code


          Incorrect AQ does not
 AQQ                                        11                    20/12/2006
          match UK Link



          Incorrect SOQ or
 SOQ                                        23                    28/02/2007
          Bottom Stop SOQ



          Billed SOQ is
 SQQ      incorrect, does not               8                     08/02/2005
          match UK Link                                                           Move to Operational Contact Codes


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

          Instruction to amend
          current meter details
 PSI      within a Prime and                13                    06/04/2005
          Sub Deduct
          Configuration




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


                                                                                                   43
                               Generic Invoicing Codes

Definition :A coined term for describing                       Volume :
similar Contact Codes with low volume                          962 in 10 years (for Codes that could be merged)
of usage (or in some instances, not                            787 in 10 years (for Codes that are duplicated or
used for 4 years or greater)                                                          redundant)

                                           Proposals and Benefits
Remove 7 Invoicing Codes :-                                    Reduces list of Contact 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
Remove 3 Invoicing Codes :-                                    Avoids confusion as to which Code to use (wrong selection
ISO / DMQ / DUP                                                currently being made)
as they have duplicated Code in the Operational set of
Contact Codes
Remove 7 Invoicing Codes :-                                    There are other Contact Codes that serve the same purpose
AMC / EXT / EUC / IRC / LIA / MFF / OVR
as they can be via the proposed generic INV Contact Code

Create a Contact Code for raising and resolving Daily          Enables you to raise this type of Query through a secure and
Metered configuration queries - DMR                            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


                   Any contact challenging two MPRN's for one service to a
    *DUP                                                                                         969                 22/01/2005
                         property and where the asset information matches

                     Challenge to the consumption billed in realtion to DM
    *DMQ                                                                                          8                  27/07/2007
                                          Datalogger Data

    *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 ?

              UQS                  ADJ
  RBD

                                                      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                                Volume : 63k per annum
enhanced or different address to the                           Rejected cases 13.9k - (22%)
one held on UK-Link

                                           Proposals and Benefits
Re-label (change) the current field description for 8 fields   Eliminates ambiguity as it suggests that this address will be
that start „Alternative Address…..‟                            an alternative to the one that UK-Link will continue to hold
Introduction of a new field :-                                 The current address format doesn‟t provide the ability to
Current Address Delivery Point Alias                           capture helpful pinpointing address details in a dedicated
                                                               field
Introduction of a new field :-                                 Expands the make-up of an address (not a postal address)
Alternative Address Delivery Point Alias                       for holding e.g „Adjacent to….‟ Or „Rear of….‟

Introduction of a new field :-                                 This will aid our validating of your ADD request as
Service Type (single or multi)                                 sometimes we will not be aware that there is more than one
                                                               service pipe at the same address
Introduction of a new field :-                                 Enables you to notify us of two addresses that have crossed
Swapped Address                                                information

Introduction of a new field :-                                 Linked to Swapped Address, the associated MPRN will
Swapped Address MPRN                                           direct us to the record that you believe is confused with
                                                               another




                                                                                                                               51
                                 Daily Meter Query (DMQ)

Definition : A request for us to                  Volume : 733 per annum
investigate DM read(s) or equipment               Rejected cases 590 - (80%)

                                       Proposals and Benefits
Introduction of a new field :-                    Validates the submission of the Contact by testing that the
From Date for DM site                             disputed period during which the fault occurred is within the
                                                  period of ownership of the site

Introduction of a new field :-                    Linked to above
To Date for DM Site


Introduction of a new field :-                    Assists the Daily meter Service provider gain access to the
Site Contact (person)                             site


Introduction of a new field :-                    Same as above
Site Tel. No.


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             Volume : 146 per annum
showing on UK-Link in relation to a                   Rejected cases 88 - (60%)
Prime and Sub configuration or a free
standing meter

                                        Proposals and Benefits
Introduction of a new field :-                        Provides a dedicated field for stating the correct link code.
MPRN Link Code Status (claimed)                       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 :-                        Assists the engineer gain access to the site
Site Contact (person)
Introduction of a new field :-                        Same as above
Site Tel. No.
Introduction of a new field :-                        Useful supporting information that will assist with access to
Availability Information (free text)                  the meter(s)

Four fields changed to Mandatory conditionality and   Will greatly improve the success rate of resolution and
Thirteen newly introduced fields                      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

								
To top