POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
Document Title:
Document Type:
Abstract:
Document Status:
Author:
Reviewed By:
Comments By:
Comments To:
Distribution:
TPS Reconciliation & Incident Management
Procedure
This document outlines the reconciliation and incident
management procedures required to investigate, report
and resolve TPS reconciliation and business incidents.
Definitive V 1.0
Richard Brunskill (MSU Manager, ICL Pathway)
PON:
Lynn Kelly,
Julie Dart,
Liz J Tuddenham,
Keith F Baines.
ICL Pathway:
John C.C. Dicks,
John Pope
28/09/00
Author
Reviewers, plus:
Evandro Manolas (ICL Pathway Process Consultant),
ICL Pathway CS/MSU
Library
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION Page: 1 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: — 16/10/00
0.0 Document Control
0.1 Document History
Version No. Date IReason for Issue Associated
(CP/PinICL No.
(0.1 22/11/99 (First draft for review.
(0.2 (03/12/99 ISecond issue for review following TIP
orkshop 01/12/99
(0.3 20/12/99 _‘IThird issue following review incorporating
lagreed changes
(0.4 14/01/00‘ IFourth issue following review and
contractual changes
(0.5 27/01/00 _ Fifth issue following review and further
contractual changes
(0.6 18/02/00 {Sixth issue following review and comments
(0.7 08/06/00 [Seventh issue following final PON review
(0.8 14/09/00 _IEighth issue following for PON review
1.0 16/10/00 [Final issue following PON review
0.2. Approval Authorities
[Name Position Signature Date
John C.C. Dicks ICL Pathway
Director Customer
Requirements
Lynn Kelly PON
0.3 Associated Documents
Reference Version (Date \Title Source
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 2 of 29
Printed On: 16/10/00
ICL Pathway
0.4 Abbreviations
Abbreviation Explanation
IAPS Automated Payment Service
BIMS Business Incident Management System - (ICL Pathway)
ICA (Cash Account
ICAP Cash Account Period
ICS/MSU Customer Service / Management Support Unit — (ICL Pathway)
IEPOSS Electronic Point of Sale Service
IHSH [Horizon System Help Desk
IMER [Manual Error Report
IPON Post Office Network
IPON TIP [Transaction Information Processing
IPON TP. [Transaction Processing
IRED Reconciliation Exception Database
ISIL System Incident Log
ISSC. System Support Centre
[TPS [Transaction Processing Service
0.5 Definitions
(Term
[Explanation
[TPS Report Set
IThe six exception reports and one Non Polled Outle!
report described in section 3
Business Incident
here this term is used within this document it is mean
las described in section 4.1.1
System Incident
here this term is used within this document it is mean
las described in section 4.1.2
[Data Error
here this term is used within this document it is mean
las described within the ‘CA Sch. G01 para 3.6.1.1
INot Data Error
here this term is used within this document it is mean
las described within CA Sch. G01 para 3.6.1.1
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION Page: 3 of 29
Printed On: 16/10/00
POL00393950
POL00393950
TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
(Cash Account Period or CAPIWhere this term is used within this document it refers to,
leach period (normally of seven days ending at 20.00hrsI
lon a Wednesday), to which PON shall have allocated,
lor shall subsequently allocate, a Cash Account Period
Number and of which it shall have informed, or shall
inform, the Contractor through the Operational Business,
(Change Process.
(Taken from the ‘CA Sch. G01 para 3.6.1.1 & 3.6.1.3)
CA Sch. G01 para...... ,
Refers to the Codified Agreement, dated 28" July 1999)
Schedule G01, as amended by Schedule 5 of the Third)
Supplemental Agreement (dated 19" January 2000) and)
ithe appropriate paragraph number to which the tex
ithin this document refers.
(Cash Account or CA
[The electronic Cash Account committed at the outlet
[Data Error Counting Period
IA Data Error Counting Period means:
[Each Cash Account Period which is of a duration of
iseven days or less and
In respect of Cash Account Periods of greater than)
iseven days duration each proportion of any such Cash)
‘Account Period derived by dividing such Cash Account
Period into two or more Data Error Counting Periods)
such that the first such Data Error Counting Period isI
between one and seven days duration and each
subsequent Data Error Counting Period during thai
(Cash Account Period is exactly seven days in duration,
(CA Sch. G01 para 3.6.1.1)
IBIMS Report
(The reports described in section 4.5.1.1
shall bear the same meaning:
lIn addition to the words and expressions identified above as being defined in CAI
Sch. GO1 para 3.6, all other words and expressions defined in CA Sch. G01 para 3.6
is when used in this document.
0.6 Changes in this Version
Version (Changes
1.0 Consolidated PON comments received and incorporated.
Reference to CS/POL/001 & CS/PRD/063 has been removed as thes
have now been withdrawn.
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION Page: 4 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
0.7. Changes Expected
(Changes
lerger of APS and TPS Reconciliation & Incident Management procedures at CSR+
document issue.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 5 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
0.8 Table of Contents
1 INTRODUCTION.
2 SCOPE
3 TPS RECONCILIATION REPORTS...
4 RECONCILIATION AND INCIDENT HANDLING
41 Incident Classification
4.1.1 Business Incidents. 9
4.1.2 System Incidents 9
42 Incident Originators.
4.3 Generation of Business Incidents...
44 Business Incident Categories.
44.1 Data Errors & Not Data Error:
44.2 Business Incident Matrix.
4.5 Incident Reporting...
4.5.1 BIMS Reports / MER
4.5.2 System Incident Log..
4.53 Reporting Timescales.
45.4 Widespread Errors..
4.5.5 Repairing Data...
4.6 Incident Management Process. esssenesnsessensenssunssnssssenssnssscensenssassansensesssnssnceen
4.6.1 MSU Raised Business Incident - BIMS / MER Issued — (Records not repaired).
4.6.2 MSU Raised Business Incident - BIMS / MER Issued (Repaired Records)...
4.6.3 PON TIP Raised Business Incident - BIMS / MER Issued... we 21
4.6.4 System Incident with Business Implications - BIMS / MER Issued — (Repaired / Not repaired
records)... ceeteeee weve sees 22
47 Links to Problem Management.........sssssssesssseesseessneesenseeseensseensscensncensnceesnseeees
4.8 Appendix 1; ‘System Incident Log’
49 Appendix 2: Business Rules for Data Errors & Not Data Errors...
49 Appendix 3: BIMS Report / MER Format...
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 6 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
11
Introduction
The TPS Report Set has been designed to enable the transactions carried
out in outlets using the Electronic Point of Sale Service (EPOSS), to be
reconciled with the transaction data which is transmitted to PON Transaction
Information Processing (TIP), and also to reconcile the daily transaction data
with the Cash Account (CA) data at the end of the Cash Account Period
(CAP). The TPS Report Set identifies errors which occur within counter
transactions or during the harvesting process. In addition to errors highlighted
by ICL Pathway within the TPS Report Set, errors may also be discovered by
PON when reconciling data within its central systems or which relate to
enquiries from PON clients. To initiate the BIMS procedure, ICL Pathway and
PON generate Business Incidents for one or more errors discovered.
NB: Acceptance of this document will not indicate acceptance of a specific
Horizon / TIP Interface solution. Those solutions should be identified within the
relevant AIS or contractual document.
Scope
This document sets out the reconciliation and incident management
procedures to be adopted by the Management Support Unit (CS / MSU), for
dealing with Business Incidents relating to the TPS Report Set errors and
PON generated Business Incidents. This includes reconciling the data
contained in the TPS Report Set and raising Horizon System Help Desk
(HSH) Business Incidents, Business Incident Management System (BIMS)
Reports and Manual Error Reports (MER) where necessary.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 7 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
TPS Reconciliation Reports
ICL Pathway currently generate six daily TPS exception reports (from the host
and counter reconciliation software), and one Non Polled Outlet report from
the host, which are described briefly below for information purposes:
1. Host Detected Transaction Control Errors:
Shows detail for any outlet where the control totals for the transactions output
by the host to PON TIP do not match the daily transaction totals calculated by
the counters.
2. TPS Harvester Errors:
Lists error conditions detected by the Harvester when failing to process one
of the messages in the message store
3. Host Detected Cash Account Control Errors:
Shows detail for any outlet where the control totals for the number of entries
on the Cash Account output by the host to PON TIP do not match the control
totals calculated by the counters
4. Counter Detected Reconciliation Errors:
Shows details for any outlets where the accumulated daily transaction control
totals for the Cash Account Period do not match the totals on the Cash
Account produced by the counters.
5. Counter Transaction Errors:
Lists error conditions detected by the counter when failing to process one of
the messages in the message store.
6. Receipts not Equal to Payments:
Identifies where the Cash Account ‘Payment’ table total does not equal the
Cash Account ‘Receipts’ table total.
7. Non Polled Outlets:
Identifies all outlets, which have not been polled and have therefore not
transmitted any transactions to PON TIP.
NB: It is not intended that this document discuss the format or content of the
individual reconciliation reports
All seven reports will be routed to ICL Pathway CS / MSU, on a daily basis by
09.00hrs, where they will be checked for completeness and accuracy of
content. In the event that the reports do not arrive, or after checking appear to
be incorrect, in the sense that the reporting process in itself has failed, CS/
MSU will raise a System Incident via the HSH.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 8 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
It is not intended that CS / MSU will deliver any of the TPS Report Set to PON
as a matter of course, other than the Non Polled Outlet report. An extract from
the TPS Report Set may however be delivered as ‘evidence’ as an
attachment to the BIMS Report / MER if it is considered by ICL Pathway that
this would aid the reconciliation or settlement process within PON
3 Reconciliation and Incident Handling
3.1 Incident Classification
3.1.1. Business Incidents
Relate to the ‘Symptom’ of an underlying cause — e.g. the effect of the system
fault on the resulting reconciliation or settlement information sent to PON.
« A Business Incident relates to one or more of the errors reported within
the TPS Report Set, or one or more of the reconciliation or settlement
errors raised in accordance with this document by PON TIP or TP. Each
error is categorised as a Data Error or a Not Data Error in accordance
with section 4.4.1.
Refer to the ‘Business Incident Matrix’ section 4.4.2 for a list of those
Business Incident classes currently known and for which appropriate error
reporting processes are set out in this document.
3.1.2 System Incidents
Relate to the underlying ‘Cause’
System Incidents may be raised by ICL Pathway to cover file rejections, non-
delivery of files, or failures in the delivery of the TPS Report Set, where there
is no associated Business Incident. In addition, following the creation of a
Business Incident, ICL Pathway may raise an associated System Incident.
System Incidents will be routed to the appropriate group within ICL Pathway,
for investigation and resolution.
Where there are associated System Incidents and Business Incidents, their
relationship can be either:
* one to one; or
*® one to many, respectively.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 9 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.2
3.3
Incident Originators
It is envisaged that Business Incidents will only be generated by the following
groups within ICL Pathway and PON:
« CS/MSU for errors reported via the TPS Report Set
e PON TIP / TP for any other reconciliation or settlement error discovered
by PON that has not been reported by ICL Pathway
e ICL Pathway SSC for any system fault or data ‘surgery’ which is
considered by ICL Pathway to have a reconciliation or settlement
implication within PON.
Subject to agreement by the parties to the contrary, outlet calls to the HSH
will not generate Business Incidents. However calls from outlets will be
monitored and if it is considered necessary by ICL Pathway, difficulties
reported to the HSH will be elevated to Business Incident status.
Generation of Business Incidents
In line with the generic incident management policy agreed between ICL
Pathway and PON, Business Incidents will only be recognised as such if
generated by ICL Pathway or PON, as appropriate, via the HSH. This
ensures that the Business Incident is properly logged, enabling CS / MSU to
ensure that corrective information can be supplied and any underlying system
fault can be rectified.
It is important that PON TIP / TP supply sufficient information to the HSH
when generating a Business Incident to ensure the timescales for the
resolution of Business Incidents referred to in section 4.5.3 can be achieved.
Achievement of such timescales is dependent upon the following information
being provided by PON TIP / TP when generating a Business Incident via the
HSH:
e Avalid ‘PATH’ code must be quoted, e.g. ‘PATH040’ etc.
e Prefix all narrative with ‘THIS IS A BUSINESS INCIDENT FOR MSU’
e The valid incident class (from the ‘Business Incident Matrix’, section
4.4.2), if one is applicable, should be quoted together with any other
relevant detail, e.g. product Id, CA lines etc.
NB: Where PON TIP / TP raise a Business Incident which may require a large
amount of supporting information, summary detail only may be given to the
HSH and the additional information sent via e-mail to CS / MSU. (A current
contact list will be made available to PON).
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 10 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.4
3.4.1
Business Incident Categories
Data Errors & Not Data Errors
The action to be taken by ICL Pathway in respect of an error which gives rise
to a Business Incident, and whether or not ICL Pathway has to pay a charge
to PON in relation to such an error, depends, amongst other things, on
whether the error is a Not Data Error or a Data Error, as defined in CA Sch.
G01 para 3.6.1.1. The following explanations are provided to assist ICL
Pathway and PON when classifying errors and do not modify, in any way, CA
Sch. G01 para 3.6.
Having determined the classification of an error, the appropriate action to be
taken by ICL Pathway is summarised in Appendix 2.
If, following discovery of an error, there is insufficient information available to
ICL Pathway to determine whether that error is a Data Error or a Not Data
Error, then for the purpose only of deciding the action to be taken in
accordance with Appendix 2, the error shall be treated as a Data Error.
3.4.1.1 Not Data Errors - categories
A. The following errors, whether they are related to a transaction or a Cash
Account are always Not Data Errors:
(i) an error caused by invalid data input by users in outlets (except where
the input of data puts a previously balanced Cash Account into a state
of imbalance);
(ii) I an error caused by the input of erroneous data by a user during
migration of PON data to any outlet (i.e. during data migration), except
where data migration tools provided by ICL Pathway are supposed to
detect such an error; the migration tool is properly used but the error is
not detected;
(iii) I an error caused by PON reference data, provided that ICL Pathway
has properly applied that reference data; and
(iv) an error which falls within a Business Incident classified in the table
under section 4.4.2 as “F” or “G’.
B. Inaccurate Cash Account (Not Data Error)
In addition to the above, an inaccurate Cash Account is a Not Data Error if
the Cash Account was committed at the outlet, even though a warning was
given to the outlet (in the form of “receipts not equal to payments” or such
other warning as the parties may agree) that the inaccuracy existed, and
either;
(i) the inaccuracy was not_caused primarily by:
(a) inaccurate ICL Pathway reference data:
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 11 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
(b) ICL Pathway incorrectly applying PON reference data; or
(c) an ICL Pathway generated software error; or
(ii) the inaccuracy was caused by one of the causes listed in (i), but it
could have been corrected by a user in the outlet, if that user had
applied a “work around” previously agreed by ICL Pathway and PON to
deal with such inaccuracies.
3.4.1.2 Data Errors — Categories
Inaccurate Cash Account (Data Error)
An inaccurate Cash Account is known as an Inaccurate Cash Account (Data
Error) and is treated as a Data Error unless it is a Not Data Error because:
(i) the inaccuracy is defined as a Not Data Error by reason of section
4.4.1.1 (A): or
(ii) the Cash Account is an Inaccurate Cash Account (Not Data Error)
because of section 4.4.1.1 (B).
Cash Account Error
If the electronic Cash Account committed at the outlet is not the same as that
which TMS presents at the TIP interface e.g. because the Cash Account has
been corrupted in some way, this is known as a Cash Account Error. This is
a Data Error unless the error which results in the Cash Account Error falls
within section 4.4.1.1.(A) above.
Transaction Errors
An error in one or more data fields in the electronic record of a transaction, or
a missing, duplicate or spurious additional transaction record is known as a
Transaction Error. A Transaction Error is a Data Error, unless it falls within
section 4.4.1.1(A) above.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 12 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.4.2 Business Incident Matrix
The Business Incident Matrix identifies known classes of Business Incidents . This
3.5
3.5.1
list is based on the list of incidents provisionally agreed between ICL Pathway
and PON at the joint workshop held on 02/11/99 for EPOSS / TPS related
Business Incidents. The list also includes those additional Business Incident
types documented within the ‘CA Sch. G01 Error Matrix, Annex 1'. As such
the list is an initial attempt to identify all currently understood Business
Incident classes but it may not be exhaustive. The current Business Incident
Matrix is held within the BIMS database and an extract can be provided to
PON at any time for audit and checking.
Incident Reporting
BIMS Reports / MER
BIMS has been designed to report the progress to resolution of a Business
Incident to allow PON to complete an accurate reconciliation (within PON
central systems) or settlement with their clients. For ease of identification and
association with the corresponding HSH call, BIMS Report references will
mimic the HSH reference. However they will be prefixed with a letter ‘B’, e.g.
HSH ref.: E9912120011 = BIMS ref.: BE9912120011.
3.5.1.1 Format and Content of BIMS Report / MER
A BIMS Report will be issued for each Business Incident generated via the
HSH. As part of that BIMS report, ICL Pathway will issue a MER for each
error associated with the relevant Business Incident where it is necessary to
do so to comply with CA Sch. G01 para 3.6.
BIMS Reports / MER are designed to notify PON of the detail required to
assist in the reconciliation or settlement process within PON. They
communicate information concerning the resolution of the symptom of an
underlying cause, not the cause itself. Business Incident reporting to PON
TIP / TP will fall into one of the following categories:
. BIMS Report for a Not Data Error
This will be the standard BIMS report as shown in Appendix 3 without the
‘Transaction Details’ section completed. It will provide PON TIP / TP with a
brief description of each error to the extent that each error can be identified.
2. BIMS Report for a repaired Data Error
This will be the standard BIMS Report as shown in Appendix 3. However, the
‘Transaction Details’ section may be completed if considered necessary by
ICL Pathway. Full details of the repaired transaction ‘File’ will be documented
providing an explanation of each correction made.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 13 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3. BIMS Report and MER
This will be the standard BIMS report as shown in Appendix 3. However, the
‘Transaction Details’ section will be completed as a MER to describe each
Data Error associated with the Business Incident, and specifying in a format
(suitable for PON TIP to key into a PON TIP data input facility):
ein the case of a Data Error resulting in an Inaccurate Cash Account (Data
Error) or a Cash Account Error, each of the line items in the relevant Cash
Account which need to be replaced in order to correct the Data Error in
question; and
e in the case of a Data Error which is a Transaction Error, the relevant
transaction record as it would have appeared but for the Data Error.
NB: A BIMS report may contain more than one MER.
Appendix 2 describes in tabular form the different error criteria for Data Errors
and Not Data Errors and the business rules surrounding the transmission of
data from ICL Pathway to PON and the production of MERs where necessary.
BIMS Reports / MER will not advise any detail as to the underlying ‘Cause’ of
the problem if this is a result of a software error etc. This information is
supplied via the System Incident Log, (SIL). Where a System Incident is
generated to eradicate the cause of a particular problem, and there are one
or more associated Business Incidents, cross-references will be supplied on
the Business Incident BIMS Report / MER to allow tracking of the System
Incident.
3.5.1.2 Clearance / Closure Criteria & Charges Applicable to MERs
ICL Pathway anticipates that it will provide information concerning Business
Incidents to PON on a ‘drip feed’ basis, by issuing updated versions of the
initial BIMS Report / MER.
A BIMS Report is ‘Cleared’ (for the purpose of determining whether the
timescales as quoted within section 4.5.3 have been met), when ICL Pathway
has provided the information required to be contained in the relevant BIMS
Report as set out in section 4.5.1.1. The BIMS Report is then closed following
agreement between PON and ICL Pathway at the monthly Incident
Management Review. Such agreement is subject only to fulfilment of the
following conditions:
1. If there is no associated System Incident, the BIMS Report is closed
subject to the clearance criteria described above being met
2. If there is an associated System Incident, the BIMS Report is closed
subject to the successful closure of the System Incident by ICL Pathway.
PON will advise ICL Pathway on a monthly basis via spreadsheet of any
payments it considers are payable to PON (as compensation for PON’s costs
in dealing with MERs) and / or its charges for dealing with widespread errors,
at the monthly Incident Management Review. For the avoidance of doubt, if
an error, treated as a Data Error due to a lack of information in accordance
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 14 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
with section 4.4.1 is subsequently found to be a Not Data Error, then no
payment will be made in respect of a MER which may have been issued in
respect of that error. If the parties disagree whether the error is a Data Error
or Not Data Error, this will be initially discussed at the monthly Incident
Management Review and then escalated via a ‘Case Law Referral’ form, to
the Contract Administration Board for a final decision to be made.
Full details of the charges applicable in respect of MERs are set out in
Appendix 2.
3.5.1.3 Notification of Anticipated Errors
There may be certain instances where an error identified in ‘Week 1’ will have
an equal and opposite error generated in ‘Week 2’. For example, if there is a
difference in the derived transaction total transmitted to PON TIP when
compared to the actual totals populated to the Cash Account line, probably
due to a stock unit rolling over more than one CAP, an equal and opposite
error will occur the following week. In such cases only one BIMS Report and
MER if appropriate, will be issued following the notification of the error within
Week 1.
3.5.1.4 Report Distribution
3.5.2
3.5.3
ICL Pathway will distribute BIMS Reports / MER’s and the Non Polled Outlet
report within PON using the PON mail network accessed via ‘Lotus Notes’. In
the event that this facility is temporarily unavailable, reports will be distributed
via the ICL Pathway mail system.
BIMS Reports / MERs distributed in accordance with this section will be
deemed to have been issued to PON, and / or PON given notice of any
errors described therein, at the time of transmission by mail.
An example of a BIMS Report / MER is shown in Appendix 3.
System Incident Log
The SIL is intended to track the progress to resolution of a System Incident
generated to eradicate an underlying system fault. In practice, one system
fault
could lead to a number of symptoms generating Business Incidents. The SIL
has been developed to remove the need to annotate each BIMS Report /
MER associated with a particular system fault, with the detail required to
ensure PON are fully advised as to the nature of this fault and how and when
it is to be rectified. This information will be contained in the SIL.
An example of a completed SIL is shown in Appendix 1.
Reporting Timescales
CS / MSU will use reasonable endeavours to raise an initial BIMS Report
(V1.0) relating to a new Business Incident. This will be made available in
accordance with section 4.5.1.4, to the PON ‘Incident Manager, Transaction
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 15 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.5.4
Processing’, on the same working day as the Business Incident is generated
via the HSH, or in any event on the morning of the next working day. In the
event of the TPS Report Set not being available to CS / MSU in time to
enable any errors to be notified within this timescale, CS / MSU will contact
the PON ‘Incident Manager Transaction Processing’ to agree a temporary
extension to the timescale. This initial, incomplete, BIMS Report will serve to
notify PON that a Business Incident has occurred and that the completed
BIMS Report will be provided to PON within the agreed timescales.
ICL Pathway will use reasonable endeavours to ensure the final completed
BIMS Report / MER, is made available in accordance with section 4.5.1.4 and
is cleared within five working days from the date the Business Incident was
generated via the HSH.
Where there is a need to correct Data Errors (see appendix 2), ICL Pathway
will use reasonable endeavours to deliver the corrected data file to PON TIP
within five working days from the date the Business Incident was generated
via the HSH. This may however, not always be practical due to the
technicalities of creating a corrected data file if there is a high volume of data.
lf the BIMS Report / MER is not cleared (in accordance with section 4.5.1.2)
or ICL Pathway think it is unlikely to be cleared within five working days, ICL
Pathway shall immediately notify PON’s Incident Manager Transaction
Processing and shall procure that ICL Pathway’s Management Support Unit
Manager (or in his absence, his deputy) is made available to meet with PON’s
Incident Manager Transaction Processing, (or his delegate), to discuss the
delay within two working days of such notification.
There is no strict timescale for the resolution of a System Incident as the time
taken to develop a fix or correct erroneous reference data cannot be
determined. Obviously however, ICL Pathway will give every System Incident
the priority it deserves taking into account PON’s requirement and would aim
to deliver an initial analysis of the root cause within 5 working days and a
final analysis and evidence of remedial action, within 10 working days. A
System Incident will be closed by ICL Pathway once the relevant fix has been
developed and tested, or a correction to the relevant erroneous reference
data has been authorised or approved for release through the appropriate
agreed procedures between ICL Pathway and PON. The SIL, advising the
current status of SystemIncidents will be delivered to PON TIP / TP at the end
of each week. PON may telephone CS / MSU at any time to receive an
update as to the status of any System Incident documented on the SIL.
Widespread Errors
ICL Pathway will monitor ‘trigger points’, for example HSH calls and the TPS
Report Set, which can alert of any likely potential or actual ‘widespread’
errors which are those Data Errors or Not Data Errors affecting Cash
Accounts in a Cash Account Period at more than 100 outlets. (This includes
the notification of Cash Account files not sent to TIP and whether or not ICL
Pathway is in a position to recover any missing data files)
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 16 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.5.5
3.6
e Should this scenario occur, ICL Pathway Business Continuity Manager
shall immediately notify PON Business Continuity Manager of the
widespread error. Upon giving such notice the provisions of this document
(other than this section) shall cease to apply to that particular widespread
error. Instead alternative joint action will be agreed between ICL Pathway
and PON in accordance with the business continuity policy.
The charges for widespread errors shall be as set out in CA Sch.G01 paras
3.6.4.3 & 3.6.4.4.
Repairing Data
Where ICL Pathway corrects Data Errors, ONE Business Incident will be
raised to cover each error, which has been corrected (or group of errors if
they are related to each other or if they relate to one Cash Account). A BIMS
report containing appropriate information (in accordance with section 4.5.1.1)
will be issued relating to that error or group of errors.
Where there is a need to correct Data Errors, ICL Pathway may make
corrective assumptions, based upon the format and content of previous valid
records of the same type, if no other detail is available. For example, where a
transaction mode is unknown, the mode used may be obtained from a
previous transaction of the same type. In such cases, CS / MSU will promptly
inform PON ‘Incident Manager Transaction Processing’ of the assumption,
and anticipates that this will be by fax normally within the working day that the
assumption has been made. PON may wish to review and validate these
assumptions on a case by case basis and it should be noted that any
assumptions made would not necessarily set a precedent.
Where PON agrees that a Cash Account transmitted to PON TIP shall be
repaired rather than require a MER, then ICL Pathway’s obligation to transmit
a repaired Cash Account may be satisfied by transmitting such part of the
repaired Cash Account as is necessary to correct the Data Error concerned,
provided that such transmission complies with the requirements of the CCD
entitled: ‘ICL Pathway to TIP Application Interface Specification’.
Appendix 2 sets out the rules surrounding the decision to repair data or
advise corrections via MER.
Incident Management Process
The following flowcharts have been prepared to describe the usual processes
required to bring each Business Incident and System Incident to a successful
conclusion within ICL Pathway and PON and are for information only. They
do not attempt to describe any low-level ICL Pathway procedures.
The individual cases where ICL Pathway will elect to repair or not to repair
data are not included within these flowcharts.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 17 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.6.1 MSU Raised Business Incident - BIMS / MER Issued — (Records not
repaired)
2 3
Exception Investigate Repair data
START report exception electronically?
incident IMsu}
5
Route Raise bus. incident
incident to MSU }e@—4 for each exception
incident stack with the HSH
[HSH] IMsU]
8 Annotate
Log incident exception
details into L-Bl report with
BIMS/MER BIMSIMER ref.
[Msu} [Msu}
1 10 9
Update ‘aati
it Investigation to
BIMSIMER with lee] provide settiem't File report
investigat’n results 7
Trecon.tn detail IMsU]
IMsu] TSU!
Underlying
already raised? system fault?
“update syst ¥p r Despatch *
late system aise system Jespatc!
Pe H Close HSH
incident record incident BIMSIMER = LB
with new details with HSH report to PON puss
IMsU] IMsu} IMsu}
18 a syste 19 20
system
Lg incident refs to PON agree Until agreement
BIMS/MER report reached
[MSU] aM
Yes
23 24
Until system
incident Cereus /<——
resolved IMsU}
24 25
Agree charges for Close BIMS/
MER at monthly
incident review
[MSUIPON]
i__y]
>}
MER at monthly
incident review
IMSU/PON]
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION
Page: 18 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.6.2 MSU Raised Business Incident - BIMS / MER Issued (Repaired Records)
27 28 29
Raise one Route Log incident
©, bus. incident [yp] incident to MSU details into
on the HSH incident stack BIMSIMER
IMsU} [HSH] [Msu]
30 Annotate
exception
report with j_g@_—_
BIMS/MER ref.
IMsU]
¥ 32 Forward
sad Bus. Incident to
SSC with instructions
rimwsuy [FP] tocreate a correction
file & send to TIP
IMsu]
38 “
Update system Create Update incident
incident record Raise system conection file L-3p] with correction
with new deals ineldent wt and send to MP Me detals
[MSU] [ssc] [SSC]
40 35
inetd system Return incident
Lg incident refs to tease
BIMS/MER report esc}
IMSU]
36 Update
Despatch BIMS/MER
Pet simsimeR feg@§ with correction
report to PON file details
IMsU] IMsU]
42 “3 44
Close HSH PON agree Untit agreement
business incident to clear reached
IMsU] BIMS?,
Yes
45
Clear
sinsmeR [€————
IMsu]
* close BINS! Taree charges t “
lose \gree charges for Unti syst
MER at monthly f@@—{ MER atmonthly fg ——J Onn iyetm
incident review incident review fesolved
[MSU/PON] [MSU/PON]
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 19 of 29
Printed On: 16/10/00
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.6.3. PON TIP Raised Business Incident - BIMS / MER Issued
50
START
61 82, 0 58 out 55
aise business joute Ne
TIP business incident incident to MSU ~ Attach details to
incident ‘on the HSH incident stack exis MSU). ient
[TP] [HSH] IMsu]
Yes. y
60 56
Log Update BIMS/
incident details MER report &
into BIMS/MER ‘send to PON
IMsu] IMsu]
61 57
Investigation to Seek closure of
provide settlement duplicate incident
or recon.tn detail from PON
[MSU] [MSU]
65 62 58
Update
Update system Close
incident record Underiying , BIMSIMER with duplicate incident
with new details system fault? investigat'n results On PON behalf
[MSU] [MsU}
74
Until system
incident
resolved
66 Pn
Raise system Despatch
i i BIMS/MER
incident with HSH
[MSU] report to PON
IMsU]
67
Add system
\cident ref.s to
BIMS/MER report
IMsu]
PON agree
toclear
BIMS?,
[MSU]
Yes
72 ”
Close HSH Clear
business incident [(€— —_BIMSIMER
[su] IMsu]
75 76
Agree charges for Close BIMSIMER 7
MER at monthly at monthly END
incident review incident review
[MSUIPON] IMSU/PON]
Until agreement
reached
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION
Page: 20 of 29
Printed On: 16/10/00
POL00393950
POL00393950
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
79 80 Raise
78 Business bus. incident
START incident on HSH & link to
identified system incident
by SSC [Ssc]
81 83
Route
incident to MSU
incident stack
Attach details to
existing incident
IMsu}
[HSH]
89 88 Log 84
Investigation to incident details Update BIMS/
provide settlement kJ into BIMS/MER. MER report
or recon.tn detail ‘Add system ref.s & send to PON
IMsu] [MSU] [MSU]
90 85
Update BIMS/ Seek closure of
MER with duplicate incident
investigat’n results from PON
[Msu] [MSU]
1 86
Despatch Close
BIMS/MER duplicate incident
report to PON on PONs behalf
IMsU] IMsu]
87
Until agreement PON agree
reached to clear END
BIMS?
94 95 Close HSH 96
Clear bus. incident on Until system
——>I_—simsimer >) ssc benat [PI incident
IMsU] [MSU] resolved
98 97
Close BIMS/MER Agree charges for
at monthly MER at monthly
incident review incident review
IMSU/PON] IMSU/PON]
3.6.5 System Incident with Business Implications - BIMS / MER Issued —
(Repaired / Not repaired records)
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION
Page: 21 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.7
Links to Problem Management
The processes highlighted within this document are not intended to replace
the current agreed Problem Management procedures, which will run side by
side with the incident management process, as has always been the case.
By way of example, “problems” may be raised by ICL Pathway or PON in the
following scenarios:
« Where there is a trend of similar Business Incidents where there is no
identifiable cause. This may include the scenario where the number of
Data Errors discovered after transmission to PON TIP exceeds 20 within
the relevant Data Error Counting Period. (CA Sch. G01 para 3.6.6.2)
« Where a System Incident has been raised and the cause is unknown. (A
problem may not necessarily be raised for every System Incident).
Problem management expands the scope of the incident management
process described in this document to include any wider issues, which must
be dealt with in order to rectify problems and to ensure that the associated
Business and / or System Incidents are not repeated.
A System Incident is generated by ICL Pathway to ensure the relevant code
or fix etc. is developed, tested and delivered to the live estate. However,
resolution of problems which arise as a result of that System Incident will
cover any additional requirements of both parties e.g. Counter News updates,
briefings etc. and in many cases the authority from PON to proceed with a
relevant fix.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 22 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.8 Appendix 1: ‘System Incident Log’
‘System Incident References Associated Business Incident Resolution Detail
Date Raised HSH Ref. PiniCL (1) I PinICL (2) BIMS / HSH Ref. TIP Ref. Cause / Rectification of Error Fix Detail Problem Mgt Closure Date
Ref.
13/11/99 IE9911030813 32733 IN/A IBE9911020258 p99 Narrative text P1234 29/11 [34567 13/12/99
13/11/99 IE9911030845 32675, [32688 IBE9911020259 N/A Narrative text 4666
Description of Fields
System Incident References
e Date Raised: The date the System Incident was raised by CS / MSU
e HSH Ref.: The System Incident HSH reference
e PinICL (1): The initial System Incident PinICL
e PinlCL (2): Any subsequent System Incident PinICLs raised for the same Business Incident
Associated Business Incident
e BIMS/ HSH ref.: The HSH and BIMS references which are identical but for the ‘B’ prefixing the BIMS reference
e TIP Ref.: Any TIP reference quoted against a TIP / TP raised Business Incident
Resolution Details
e Cause Rectification of Error: A non technical description of the fault and the solution to rectify
e Fix Detail: The Work Package (WP) detail and associated dates of any fix delivered to the estate
e Problem Mat Ref.: The associated Problem Management Database reference
e Closure Date: The date the System Incident was closed following successful delivery of fix detail or reference data changes.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 23 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
3.9 Appendix 2: Business Rules for Data Errors & Not Data Errors
Data Errors Discovered Before Transmission to PON TIP
Action by ICL Pathway
Data Error Criteria Para (inRetain [Transmit (Correct theCorrect theMER MER (NojSend Report =Charge to
(CA = Sch Original (Original [Data Error [Data Error if(Subject tolLimit) (Corrected {Explain ICL
IG01) [Record [Record PON Agree [50 Limit) Record (Correction IPathway
Note 3 (Amt. Per
MER)
(Transaction Error 8.6.5.1 Iv Iv iv v N/A
\Transaction Error — MERS.6.5.4 \~ Note 1 iv v £100
option
Inaccurate Cash Accounti3.6.5.2 (a) iv iv iv iv N/A
(Data Error) - Corrected
Inaccurate Cash Account/3.6.5.2 (b) iv iv Vv £100
(Data Error) - Not Corrected
(Cash Account Error 3.6.5.3 Iv Iv iv lv N/A
(Cash Account Error — MER3.6.5.4 lv Note 4 iv v £100
(Option
Note 1: ICL Pathway will usually retain the original record but is not obliged to do so if a MER is issued.
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION
Page: 24 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
Data Errors Discovered After Transmission to PON TIP
Action by ICL Pathway
Data Error Criteria Para (injRetain Transmit (Correct theCorrect theMER MER (NoSend Report “Charge to
(CA = Sch,Original (Original [Data Error [Data Error if(Subject toLimit) (Corrected (Explain ICL
IG01) [Record Record IPON Agree [50 Limit) [Record Correction [Pathway
Note 3 (Amt. Per
MER)
\Transaction Error 3.6.6.1 (a) IN/A N/A v iv Iv N/A
(Corrected
[Transaction Error — Not3.6.6.1 (b) N/A IN/A Vv Note 2 iv £150
(Corrected
Inaccurate Cash Account}3.6.5.2 (a) IN/A N/A iv iv iv N/A
(Data Error) - Corrected
Inaccurate Cash Account3.6.5.2 (b) IN/A IN/A Iv Vv £100
(Data Error) - Not Corrected
(Cash Account Error -3.6.6.1 (a) IN/A N/A iv iv Iv N/A
(Corrected
(Cash Account Error — Noti3.6.6.1 (b) IN/A IN/A Vv Note 2 v £100
(Corrected
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION
Page: 25 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
Note 2: the ‘50 limit’ only applies if the Data Error is discovered after transmission to TIP, but before the conclusion of the Data
Error Counting Period. If discovered after the end of the Data Error Counting Period, the ‘50 limit’ does not apply in respect of
MERs required to be issued, (see CA Sch. G01 para 3.6.6.3)
Note 3: Instead of retaining and repairing Data Errors, ICL Pathway is entitled to issue MERs for up to a total of 50 Data Errors (or
such higher limit as the parties may agree) relating to any Data Error Counting Period.
For the purposes of this ‘50 limit’, a Data Error relates to a Data Error Counting Period if;
a) itis a Transaction Error in a transaction carried out during that Data Error Counting Period; or
b) it is a Cash Account Error or an Inaccurate Cash Account (Data Error) for the Cash Account Period (if any) which is co-
terminus with that Data Error Counting Period.
For the purposes of the definitions Data Error Counting Period, a day shall mean a period of 24 hours ending at 20.00hrs. (CA
Sch. G01 paras 3.6.1.2 & 3.6.1.3). ICL Pathway and PON may agree that the ‘50 limit’ may be increased if felt operationally
viable.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 26 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
Version: 1.0
SECURITY CLASSIFICATION Date: 16/10/00
Not Data Errors Discovered Before or After Transmission to PON TIP
Action by ICL Pathway
Data Error Criteria Para (injRetain (Correct theCorrect theBIMS To the extent that is reasonable, ICLICharge _ to
(CA = Sch Original [Data Error [Data Error ifReport (No Pathway to Assist PON to: ICL
IG01) Record [Record PON Agree MER) Pathway
(Amt. Per
MER)
Not Data Error 3.6.7 iv iv la) investigate and seek to prevent thelN/A
recurrence of such Not Data Erroi
and;
lb) prevent the production of Cash
Accounts which are incorrect as al
result of such Not Data Error
© 2000 ICL Pathway Limited
SECURITY CLASSIFICATION
Page: 27 of 29
Printed On: 16/10/00
POL00393950
POL00393950
ICL Pathway TPS Reconciliation & Incident Management Ref: CS/PRO/111
SECURITY CLASSIFICATION bate 16/10/00
Appendix 3: BIMS Report / MER Format
BIMS Reference: BE/9912240077
Incident Type: Version: Last Updated:
Incident Class Originator:
Transaction Date: CAP: FAD:
Status: Error Value: £
OTHER REFERENCES [TRANSACTION LIABILITY
PinICL reference: Provisional:
Incident ‘xref’ : Final:
TIP / TP ref:
System Incident References Settlement Details
HSH: Transaction Settlement
PinICL: Settled Amount:
Invoice Number:
Invoice Date:
IMER Charge
No of Chargeable MER
MER Settlement Amount:
MER Invoice Number
MER Invoice Date
INCIDENT HISTORY
Date Received
Date Cleared
Date Closed
ACTIONS
(Action Date / Time: Action Type: Analyst:
[Text description]
TRANSACTION / CASH ACCOUNT DETAIL MANUAL ERROR REPORT: Y/N
20 Fields available for insertion of Transaction or Cash Account detail in content
iand format agreed with PON TIP.
© 2000 ICL Pathway Limited SECURITY CLASSIFICATION Page: 28 of 29
Printed On: 16/10/00