ICL Pathway Ltd
FUJ00001567
FUJ00001567
APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 02/07/2001
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
APS Reconciliation & Incident Management
Procedure
N/A
This document outlines the end-to-end reconciliation and incident
management procedures required to investigate, report and
resolve, APS reconciliation and business incidents.
DRAFT
Richard Brunskill (MSU Manager, ICL Pathway)
ICL Pathway: Jez Murray, John Moran, Michael King, PON:
Dave Salt, Glenys Latham
ICL Pathway: Angela Shaw, Michael King, Mik Peach, Paul
Westfield
PON: Dave Salt, Glenys Latham, Ann Clarke, Rabia Cody, Mark
Reardon, Phil Norton, Paul Smith
09/07/01
Originator
Distribution: ICL Pathway Document Management
Reviewers
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page I of 23
ICL Pathway Ltd
APS Reconciliation & Incident Management
Ref:
CS/PRO/128
Version: 1.0
FUJ00001567
FUJ00001567
COMMERCIAL IN CONFIDENCE Date: 02/07/2001
0.0 Document Control
0.1 Document History
\Version No. Date [Reason for Issue (Associated
(CP/PinICL
0.1 7/02/01 Initial Draft IN/A
(0.2 1/05/01 [Second draft incorporating comments /A
0.3 23/05/01 [Third draft incorporating PON comments IN/A.
1.0 2/07/01 IFor approval
0.2 Approval Authorities
Name Position Signature Date
[Paul Westfield ICL Pathway Infrastructure
Services Manager
[Ann A Clarke IPON / TP
IRabia Cody IPON / BSM
0.3. Associated Documents
Reference \Version [Date [Title Source
1. CS/QMS/002 1.0 12/01/01 ICL CS Process Manual IPVCS
2. CS/PRO/099 1. 31/03/00 [Reporting on Non Polled Post/PVCS
Offices
3. CS/PRO/I11 1.0 16/10/00 [TPS Reconciliation & IncidentPVCS
IManagement
4. CS/TEM/022 1.0 26/01/01 [Daily End-to-End APS PVCS
[Reconciliation Template
IS. Codified 2.0 31/10/00 (Codified Agreement Sch GOI
Agreement
6. AP/IFS/048 4.0 10/04/00 IAPS Host Operational PVCS
[Reconciliation Reports for
ICSR+
© 2001 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 2 of 23
ICL Pathway Ltd
APS Reconciliation & Incident Management
Ref:
Version: 1.0
02/07/2001
COMMERCIAL IN CONFIDENCE Date:
CS/PRO/128
FUJ00001567
FUJ00001567
0.4 Abbreviations/Definitions
IAbbreviation. Definition
IAPS Automated Payment Service
IBIMS [Business Incident Management Service
IBSM. [Business Service Management (AP Service Provision Team — PON)
CTS Client Transmission Summary
IEPOSS Electronic Point of Sale Service
IHAPS [Host Automated Payment System
IHSH [Horizon Systems Helpdesk
ER (Manual Error Report
SU Management Support Unit
IPON Post Office Network
PVCS [Pathway document management system
SIL System Incident Log
SSC ‘System Support Centre
(TIP (Transaction Information Processing
(TP (Transaction Processing
(TPS (Transaction Processing Service
0.5 Changes in
this Version
ersion
(Changes
1.0
‘Composite comments and review comments included
0.6 Changes Expected
(Changes
© 2001 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE
Page 3 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 02/07/2001
0.7 Table of Contents
1.0 INTRODUCTION...
2.0 SCOPE....
3.0 APS RECONCILIATION REPORTG.......
3.1 REPORTS AVAILABLE TO PON FROM ICL PATHWAY CE!
3.1.1 APSS2133— APS Daily Account Balancing Report
3.1.2 APSS2133b — The APS Client Summary Report.
3.1.3. APSS2133c — The APS Delayed Transaction Report
3.1.4. APSS2136 — The Daily TPS / APS Transaction Summary Reconciliation Report.
3.1.5 APSS2139 - The Daily APS Office Harvesting Report...
3.2. DELIVERY TIMESCALE & MECHANISM FROM ICL PATHWAY TO 0 PON
4.0 END-TO-END APS RECONCILIATION...
4.1 DAILY END-TO-END APS RECONCILIATION REPORT .....:.:...::ssssssssssssssssssssssennssstesnseeeenss
4.1.1 End-to-End APS Reconciliation Report - APSS2141
End-to-End APS Reconciliation Summa
an Data Delivery Timescale & Mechanism
4.1.3.1 Delivery Mechanism...
5.0 RECONCILIATION & INCIDENT HANDLING.
5.1 INCIDENT CLASSIFICATION.
5.1.1 APS Business Incidents.
5.1.2. System Incidents... . z z
5.2 APS BUSINESS INCIDENT ORIGINATORS 15
53 GENERATION OF BUSINESS INCIDENTS
5.4 APS BUSINESS INCIDENTS........
5.4.1 APS Reconciliation Report Errors..
5. End-to-End APS Reconciliation Errors.
5. Delayed Transactions...
5.5 INCIDENT REPORTING.
5.5.1 BIMS Reports / MER...
5.5.1.1 Format & content of BIMS report / ME)
5.5.1.2 Clearance & Closure Criteria.
5.5.1.3 Report Distribution.
System Incident Log.
Reporting Timescales.
Widespread Errors.
5.5.5 Repairing Data..
6.0 CLIENT MIGRATION...
6.1 VARIABLE FILE TRANSFER.
6.2. RECONCILIATION IN THE EVENT OF NON DELIVERY OF THE CTS TO PON.
6.2.1 Clerical Reconciliation Example in the event of non delivery of CTS to PON.
6.3. IMPACT OF CLIENT MIGRATION ON THE RECONCILIATION PROCESS...
7.0 APPENDIX.........
1 - BIMS REPORT EXAMPLE. 23
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 4 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
1.0 Introduction
The Automated Payment Service (APS) report set produced by ICL Pathway central
systems and the End-to-End APS reconciliation prepared by ICL Pathway
Management Support Unit (MSU), have been designed to enable APS transactions
completed in the outlets to be reconciled to the outlet Cash Account and settlement to
be made with Post Office Network (PON) clients.
ICL Pathway central systems will produce a daily suite of reports, (see section 3 for a
full description of each report), which reconciles those values harvested by both the
Transaction Processing Service (TPS) and APS harvesters. End-to-End APS
reconciliation will be completed by ICL Pathway / MSU to provide a view from
harvesting, through to PON / Transaction Information Processing (TIP) processing
and PON client settlement.
In addition to those errors discovered by ICL Pathway within either the APS report set
or the End-to-End APS reconciliation, others may be discovered by PON when
reconciling data within it’s central systems or relating to queries from PON clients. To
initiate the Business Incident Management Service (BIMS) process, ICL Pathway or
PON generate APS Business Incidents for one or more errors discovered.
The incident management process is generic for both Electronic Point of Sale Service
(EPOSS) and APS incidents in the way that APS Business Incidents are raised,
documented and progressed. It should be noted however, that where an APS incident
DOES NOT affect client settlement or reconciliation within TIP, the provisions
quoted within the Codified Agreement (CA) schedule G01, in respect of charges levied
for Manual Error Reports (MER), DO NOT apply. Definition and charges for TPS
related errors, subject to the provisions of CA schedule G01, where the incident has
caused a reconciliation or settlement error within TIP are found in associated ICL
Pathway document: ‘CS/PRO/111: TPS Reconciliation & Incident Management’
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 5 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
2.0 Scope
This document sets out the reconciliation and incident management procedures to be
adopted by ICL Pathway / MSU for dealing with APS reconciliation report distribution
to PON, End-to-End APS reconciliation and with any associated APS Business
Incidents which may arise, including:
APS reconciliation report differences
End-to-End APS reconciliation differences
Delayed transactions
Software faults affecting reconciliation and settlement
PON client enquiries
TPS Output file delivery failures
eeceeee
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 6 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
3.0 APS Reconciliation Reports
3.1
3.1.1
Reports Available to PON from ICL Pathway Central
Systems
10.
APSS2133 — APS Daily Account Balancing Report
. Opening Balance — This figure identifies the APS delayed transactions that were
not cleared from the previous day. This figure should be identical to the closing
balance from the previous day’s APSS2133 report.
Pathway Harvested Transactions — This figure should be identical for both TPS
and APS harvesters and reflects the APS transactions harvested from the outlets.
Transactions Received from HAPS — This figure identifies all transactions
received by ICL Pathway FROM PON / HAPS in relation to outlets who have not
yet been migrated to the Horizon system, where transactions have been made using
pre-Horizon system processes.
Receipt Sub total — This figure should equal the Opening Balance + APS
Pathway Harvested Transactions + Transactions Received From Host
Automated Payment System (HAPS) and equates to all transactions available for
delivery today.
APS Transactions Delivered to HAPS — This figure identifies those transactions
delivered to PON / HAPS
APS Transactions Delivered to Clients — This figure identifies those transactions
delivered direct to PON / Clients
APS Transactions Delivered To Manual — This figure identifies those APS
transactions which have been harvested by the APS harvester but have not been
delivered to HAPS / Clients via the electronic stream and which PON will need to
advise / adjust with the client manually. Notification will be made to PON via the
BIMS process. Refer to APSS2133c — The APS Delayed Transaction Report.
APS Transactions delivered to TIP — This figure should be equal to TPS
Pathway Harvested Transactions.
Delivery Sub Total — This figure should equal APS Transactions delivered to
HAPS + APS Transactions Delivered To Clients + APS Transactions Delivered To
Manual.
Delayed APS Transactions — This figure identifies APS delayed transactions not
yet cleared. This figure should be identical to the opening balance on the next day’s
APSS2133 report.
. Reconciliation Error — This figure should always be zero. If this is not the case
this will form the basis of an APS Business Incident and will be investigated via
the BIMS process.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 7 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
3.1.2
3.1.3
3.1.4
APSS2133b — The APS Client Summary Report
This report is a sub-set of line 5 and 6 on report APSS2133. It identifies by client ID,
all APS transactions that are available to be delivered to HAPS and clients. NB: This
report identifies those transactions that have been harvested on this date irrespective of
the delivery requirements of the specific client. It therefore does NOT equal the
electronic Client Transaction Summary (CTS).
APSS2133c — The APS Delayed Transaction Report
. This report is a breakdown of all Delayed APS Transactions. The grand total is
equal to the Delayed APS Transactions, line 10 on report APSS2133.
. Delayed transactions may be carried over on the report until they are resent or
manually advised via the BIMS process — this involves an interaction by ICL
Pathway using the APS Workstation. Any transactions that have been resent will
appear as part of the APS Transactions delivered to HAPS / Clients, lines 5 or 6 of
report APSS2133. Any transactions that have been manually advised will appear
as part of the APS Transactions Delivered to Manual, line 7 of report APS2133.
APSS2136 -— The Daily TPS / APS Transaction Summary
Reconciliation Report
. This is a 30-day rolling report, whereby if any transactions appear on this report
they can remain for up to thirty days.
There are two difference categories described within this report:
Difference ‘1’:
Shows any difference between transactions input at the outlet counter system and
those delivered to PON / TIP or PON HAPS / Client. This difference can be
accounted for with transactions which were not harvested by the TPS harvesters
and not delivered to PON / TIP, or by the APS harvesters and not delivered to
PON HAPS / Clients.
Difference ‘2’
Shows any difference in what was delivered by ICL Pathway to PON TIP and what
was delivered by ICL Pathway to PON HAPS or Clients. This difference is always
calculated as PON TIP less PON HAPS / Clients. If the PON TIP figure is lower
than the PON HAPS / Client figure, (through harvester mismatches or harvester
exceptions) the difference will be shown as a ‘NEGATIVE’. If the PON HAPS /
Client figure is lower than the PON TIP figure, the difference will be shown as
‘POSTIVE’.
If there are no mis-balances on this report between difference ‘1’ and difference ‘2’
then no data will be shown for that transaction date.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 8 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
3.1.5 APSS2139 — The Daily APS Office Harvesting Report
This report shows the number of outlets harvested and any outlets not harvested. In
principle it is very similar to the Non Polled offices Report. (See CS/PRO/099
Reporting on Non Polled Post Offices). However, where that report shows the number
of days since the office last polled this report shows the number of working days since
the office last harvested. It therefore does not include Sundays or any other day that
the outlet was not trading. The most important check with this report is to establish
that all the offices that appear are also on the Non-polled report. NB: This report also
lists those outlets which have been closed.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 9 of 23
FU.
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
3.2
Delivery Timescale & Mechanism from ICL Pathway to
PON
The following reports are sent daily to PON / TP and PON / HAPS:
APSS2133 — The APS Daily Account Balancing Report
APSS2133b — The APS Client Summary Report
APSS2133c — The APS Delayed Transaction Report
APSS2136 — The Daily TPS / APS Transaction Reconciliation Summary Report
APSS2139 — The Daily APS Office Harvesting Report
APSS2141 - The End to End APS Reconciliation Report (PON / TP only)
awk eN
Where ICL Pathway is able to do so, as governed by e-mail availability, all reports will
be made available to PON by 08.00hrs daily, on a Monday to Friday basis only. For
example, on a Monday or the day after a bank holiday, reports will be delivered for all
days having occurred since the delivery of the last set of reports.
Reports are initially sent to PON using the ICL Pathway account within the PON
corporate mail system. Should the PON corporate mail system be unavailable to ICL
Pathway, then ICL Corporate mail is used as an alternative. NB: Due to the size of
these reports, e.g. APSS2133b is often in excess of 100 pages, ICL Pathway are
unable to resort to facsimile transmission should the corporate e mail service of
either organisation be unavailable except in situations where any failure is deemed to
be long term. In such cases, the Manager ICL Pathway /MSU will liaise with the
Manager PON / TP & PON / Outlet Systems Group (BSM) to agree a contingency
distribution.
The distribution list is considered by both ICL Pathway and PON to be of a dynamic
nature and therefore specific addressees are not covered within this document.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 10 of 23
FUJ00001567
}J00001567
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
4.0 End-to-End APS Reconciliation
4.1
Daily End-to-End APS Reconciliation Report
The End-to-End APS reconciliation has been developed to reconcile all areas within
the APS transaction process. The system derived report set produced by ICL Pathway,
serves only to identify and reconcile the values harvested by the TPS and APS
harvesters. There is no guarantee that those transactions, which were harvested, will be
processed by PON / TIP or PON / HAPS / client within the reconciliation timescale
identified within these reports. This is due to a variety of reasons, for example, TIP
rejections at transmission file level, delayed transactions, software errors causing
transaction errors after harvesting. The APS stream sent directly to HAPS or the PON
clients is not expected to cause any problems with regard to file rejection.
The End-to-End APS reconciliation has been developed jointly between ICL Pathway
and PON to ensure that a reconciliation is provided from harvesting through to
processing at PON / TIP and the eventual PON client settlement. In other words:
e Harvested transactions for APS and TPS are reconciled
e TPS harvested transactions are reconciled against transactions processed by PON /
TIP — taking into account file rejection and data repair / resends ete
e APS harvested transactions are reconciled against transactions sent to HAPS and
directly to PON clients.
In order to maintain an effective and timely End-to-End APS reconciliation, ICL
Pathway are required to provide, in addition to the system derived APS reconciliation
report set, APS transaction detail in respect of transmission and sub files rejected by
PON / TIP. A variety of queries have been developed within ICL Pathway to identify
the APS content of any files subsequently rejected and to track the re-send and repair
process completed to ensure that these transactions are correctly accounted for.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 11 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
4.1.1 End-to-End APS Reconciliation Report — APSS2141
Once all transaction rejections have been accounted for, ICL Pathway will prepare the
daily End-to-End APS reconciliation report and forward this to PON TIP / TP. This
reconciliation is completed in accordance with the following rules:
No Value No ‘alue
Section 1: APS Harvested / TPS Harvested
1. Transactions harvested by APS From APSS2133
2. Transactions harvested by TPS From APSS2133
3. APS transactions not harvested by TPS harvester_(*) Line 1 — Line 2
4. APS transactions not harvested by APS harvester (*) I Line 2 — Line 1
5. APS transactions harvested by TPS today but Previous days
harvested by APS on: dd/mm/yyyy report(s) Line 3
entries
6. APS transactions harvested by APS today but Previous days
harvested by TPS on: dd/mm/yyyy report(s) Line 4
entries
7. TOTAL No Value No Value
8. Difference
Section 2: TIP Processed / TPS Harvested
9. Transactions harvested by TPS From APSS2133
10. TIP rejections received today Calculated by ICL
Pathway
11. TIP rejections returned today Calculated by ICL
Pathwa
12. Transactions processed by TIP Calculated by TIP.
13. Transactions disregarded by TIP (*) Calculated by ICL
Pathwa
14. Transactions processed by TIP with incorrect Calculated by ICL
accounting sense __(*) Pathway
15. Transactions processed by TIP delivered on: Calculated by ICL
dd/mm/yyyy Pathway — TIP
16. TOTAL NO Value No Value
17. Difference
Section 3: APS Harvested / APS Processed
18. B/Fwd: Delayed transactions not processed From APSS2133
19. Transactions harvested by APS. From APSS2133
20. Transactions delivered to HAPS From APSS2133
21. Transactions delivered to Clients From APSS2133
22. Delayed transactions delivered to manual From APSS2133
23. C/Fwd: Delayed transactions not processed From APSS2133
24. TOTAL No Value_I No Value
25 Difference
Note:
(*) Entries on these lines will generate a BIMS report.
© 2001 ICL Pathway Ltd. = COMMERCIAL IN CONFIDENCE Page 12 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
4.1.2 End-to-End APS Reconciliation Summary
In addition to the End-to-End APS reconciliation report, ICL Pathway will provide an
ongoing daily summary showing the reconciliation status for each day, i.e. whether or
not the day reconciles in respect of PON / TIP processing.
Date Difference in I Difference in I Reconciliation I Explanation of Difference
Transaction I Transaction State
Count Value
Y/N
01/02/01 0 £0.00 Y N/A
02/02/01 50 £500.00 N Transactions not rejected
4.1.3 Data Delivery Timescale & Mechanism
In order to reconcile the TPS harvested transactions to those transactions processed by
PON / TIP, PON / TIP will provide the volume and value of transactions processed for
each day. This figure will relate to those transactions received and processed and will
ignore any specific transaction dates. If the TIP derived figures are unavailable within
the timescale defined below, ICL Pathway will delay the completion of APSS2141
until the final TIP processed figures are available.
To complete the End-to-End APS reconciliation, it is important that data is received
and input into the spreadsheet in accordance with the following timescales:
Deliverable Timescale Responsibility
IAPS system derived IHarvesting day + ICL Pathway
reports (base data) ONE
[TIP Processed figure for {Harvesting day + THREEIPON / TIP
IAPS transactions
IAPS content of TIP [Harvesting day + THREEIICL Pathway
rejected files
IAPS content of resent IHarvesting day + THREEIICL Pathway
rejections
[End-to-End APS IHarvesting day + FOUR ICL Pathway
reconciliation report
lavailable to PON
In the event that a reconciliation cannot be achieved by close of business on harvesting
day + 4, the appropriate misbalance will be shown as a difference at line 19 of
APS2141
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 13 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
4.1.3.1
Delivery Mechanism
Information flows between ICL Pathway and PON / TIP will conform to the
following:
e TIP processing information will be delivered to ICL Pathway via e-mail
e The End-to-End APS Reconciliation report and the End-to-End APS reconciliation
summary will be delivered to PON / TIP via PON corporate e-mail (ICL Pathway
account). If this is not available, standard e-mail between the two organisations will
be used as a contingency.
Reconciliation & Incident Handling
Incident Classification
APS 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.
An APS Business Incident relates to one or more of the errors reported within the APS
Report Set, the End-to-End APS reconciliation (section 4.0) or one or more of the
reconciliation or settlement errors raised in accordance with this document by PON /
TIP or TP. Refer to section 5.4 for a list of those APS Business Incident categories
currently known and for which appropriate APS Business Incident reporting processes
are set out in this document.
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 APS Report Set, where there is no associated
APS Business Incident. In addition, following the creation of an APS 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 APS Business Incidents, their
relationship can be either:
© one to one; or
* one to many, respectively.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 14 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
n
wR
5.3
APS Business Incident Originators
It is envisaged that APS Business Incidents will only be generated by the following
groups within ICL Pathway and PON:
e ICL Pathway / MSU for errors reported via the APS Report Set & End-to-End
APS reconciliation
e PON TIP / TP / Outlet Systems Group (BSM) for any other reconciliation or
settlement error discovered by PON that has not been reported by ICL Pathway
e ICL Pathway / System Support Centre (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 Horizon System
Helpdesk (HSH) will not generate APS 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 APS Business Incident status.
Generation of Business Incidents
In line with the generic incident management policy agreed between ICL Pathway and
PON, APS Business Incidents will only be recognised as such if generated by ICL
Pathway or PON as appropriate, via the HSH. This ensures that the APS Business
Incident is properly logged, enabling ICL Pathway / MSU to ensure that corrective
information can be supplied and any underlying system fault can be rectified.
It is important that PON TIP / TP / BSM supply sufficient information to the HSH
when generating an APS Business Incident to ensure the timescales for the resolution
of APS Business Incidents referred to in section 5.4 can be achieved. Achievement of
such timescales is dependent upon the following information being provided by PON
TIP / TP / BSM when generating an APS Business Incident via the HSH:
e A valid ‘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 category (see section 5.4), if one is applicable, should be quoted
together with any other relevant detail, e.g. product Id, Cash Account lines etc.
NB: Where PON TIP / TP / BSM raise an APS 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 ICL Pathway / MSU. (A current
contact list will be made available to PON).
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 15 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
5.4.2
APS Business Incidents
APS Reconciliation Report Errors
Reconciliation errors within the APS reconciliation report set should be few and far
between and, if they do occur, will be applicable to:
e APS/ TPS harvesters running out of sync
e Software errors causing transactions not be harvested
« Unidentified differences classed as ‘Reconciliation Errors’ within APSS2133.
Where such differences occur, a BIMS report will be raised for each incident and
referenced against the appropriate line within section I of APSS2141
End-to-End APS Reconciliation Errors
Reconciliation errors may occur when reconciling the TPS harvested transactions
against those transactions received and processed by PON / TIP.
Tf, after accounting for all rejected and resent transactions, section 2 of APSS2141 fails
to provided a zero difference, the process of resolution should be as follows:
e Issue an initial BIMS for the difference requesting PON / TIP verify the rejected,
resent and processed figures supplied for the day in question. NB: This may be
difficult if the rejection rate is particularly high on a given day and where there is in
excess of 10 affected transmission files, ICL Pathway MSU manager and PON /
TIP manager will discuss how to resolve the difference.
e If after verification, these figures prove to be correct, ICL Pathway / MSU will
raise a System Incident to investigate any possible software errors or transaction
discrepancies in the delivered total to PON / TIP. This will be tracked via the
BIMS and System Incident Log (SIL) process.
e If after verification, corrections are required to the report, version 2 of APS2141
will be issued by MSU.
Delayed Transactions
Where transactions have been harvested by the APS harvester and have failed to be
delivered to either HAPS or PON clients, they are referred to as Delayed Transactions.
In normal circumstances, these transactions will be input by ICL Pathway into the APS
data file via the APS secure workstation and will be received by PON / HAPS / client,
24 hours later. There may be occasions when transactions cannot be sent via the data
file process and have to be delivered to ‘Manual’. In such cases, full detail of the
transaction is supplied via the BIMS MER route which is NOT chargeable under the
provisions of CA schedule G01 as the incident refers only to the APS transaction
stream and does not affect PON / TIP.
These transactions are highlighted within section 3 of the End-to-End APS
reconciliation — APSS2141.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 16 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
5.5 Incident Reporting
5.5.1 BIMS Reports / MER
BIMS has been designed to report the progress to resolution of an APS 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.
5.5.1.1 Format & content of BIMS report / MER
A BIMS Report will be issued for each APS 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 APS Business Incident where it is necessary to do so to advising
PON / TP of the transaction detail required to enable reconciliation or settlement to
take place.
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.
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
SIL. Where a System Incident is generated to eradicate the cause of a particular
problem, and there are one or more associated APS Business Incidents, cross-
references will be supplied on the APS Business Incident BIMS Report / MER to
allow tracking of the System Incident.
5.5.1.2 Clearance & Closure Criteria
ICL Pathway anticipates that it will provide information concerning APS Business
Incidents to PON on a ‘drip feed’ basis, by issuing updated versions of the initial BIMS
Report / MER.
A BIMS Report is ‘Cleared’ when ICL Pathway has provided the information required
to be contained in the relevant BIMS Report as set out in section 5.5.1.1. The BIMS
Report is then closed following agreement between PON / TP and ICL Pathway /
MSU at the monthly Incident Management Review. Such agreement is subject only to
fulfilment of the following conditions:
e If there is no associated System Incident, the BIMS Report is closed subject to the
clearance criteria described above being met
e If there is an associated System Incident, the BIMS Report is closed subject to the
successful closure of the System Incident by ICL Pathway.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 17 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
PON will advise ICL Pathway via spreadsheet on a monthly basis at the monthly
Incident Management Review of any payments it considers are payable to PON (as
compensation for PON’s costs in dealing with MER) and / or its charges for dealing
with widespread errors. For the avoidance of doubt, NO charges are payable in respect
of MER issued for APS incidents affecting the HAPS or Client transaction stream
only.
If the parties disagree whether only the HAPS / Client transaction streams are affected,
this will be initially discussed at the monthly Incident Management Review. The
specific incidents will then be escalated via a ‘Case Law Referral’ form, to the
Contract Administration Board for a final decision to be made.
Report Distribution
ICL Pathway will distribute APS BIMS Reports / MER within PON using the PON
corporate e-mail network. In the event that this facility is temporarily unavailable,
reports will be distributed via the ICL Pathway mail system.
BIMS Reports / MER 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 1.
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 APS 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.
Reporting Timescales
ICL Pathway / MSU will use reasonable endeavours to raise an initial BIMS Report
(V1.0) relating to a new APS Business Incident within 24 hours of the notification of
the incident. This will be made available in accordance with section 5.5.1.3, to the
PON ‘Incident Manager, Transaction Processing’, on the same working day as the
APS Business Incident is generated via the HSH, or in any event on the morning of the
next working day. In the event of the APS Report Set not being available to CS / MSU
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 18 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
5.5.4
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 5.1.and is cleared within
five working days from the date the APS Business Incident was generated via the
HSH.
Where there is a need to correct APS / TPS Data Errors, (see CS/PRO/111 TPS
Reconciliation & Incident Management, for a full description), ICL Pathway will use
reasonable endeavours to deliver the corrected data file to PON TIP within five
working days from the date the APS 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.
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 System Incidents will be delivered to PON TIP / TP & PON / BSM at the end
of each week. PON may telephone ICL Pathway / 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 APS Report
set, which can alert of any likely potential or actual ‘widespread’ errors which may
occur. This is generally agreed to be the case where at least 100 outlets are affected
with the same problem. In such a case, the incident type will be closely monitored by
ICL Pathway until volumes are such that the incident will then be raised as a problem
and passed from ICL Pathway into the PON business community. This is action will be
taken when at least 1000 outlets are affected by the same incident type.
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, a recovery plan applicable to the
specific nature of the error will be agreed by both parties.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 19 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
5.5.5 Repairing Data
Data repair is not viable for PON HAPS / client stream transactions. Rejected
transactions are not expected as neither have sophisticated file / transaction validation
processes. Therefore the repair of PON / HAPS / client transactions is not discussed
within this document.
Refer to ICL Pathway document CS/PRO/111 TPS Reconciliation & Incident
Management for the repair criteria in relation to APS transactions affecting the TPS
transaction stream.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 20 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
6.0 Client Migration
6.1
6.2
Variable File Transfer
PON clients have the option of taking transaction delivery from ICL Pathway in
accordance with their own processing requirements. NB: Specific client requirements
are described elsewhere for each client — this document is not intended to describe
each in detail.
APS transactions are harvested from the outlets on a seven-day basis and all are
available for onward transmission on each day to the clients should they require it.
However, some clients only require transactions to be delivered on a five day, or one
day etc., per week basis. This has no impact upon the reconciliation between the actual
client transmission and the Client Transaction Summary (CTS).
The (CTS) accurately identifies the volume and value of the ‘normal’ transactions (not
reversed / reversing transactions) that have been delivered to the clients on a particular
day in accordance with their specific requirements. It is important to note that the
transactions actually delivered to PON clients as recorded on the CTS will differ from
the value shown on APSS2133 within the Delivery Sub Total (9). This figure
represents the values harvested from the outlets, which may, or may not yet have been
delivered to PON clients in accordance with their requirements.
Reconciliation in the event of non delivery of the CTS to
PON
PON / TP use the CTS as the basis for settlement with migrated clients. In the unlikely
event that ICL Pathway fails to deliver the CTS file to PON or PON reject the file,
PON / TP will need to use the APSS2133b to manually calculate settlements due. The
CTS only reports normal transactions whereas the APSS2133b includes reversed /
reversing transactions. Consequently PON / TP can only use the APSS2133b to
calculate the value (not the volume) of the settlements due.
Settlement is time critical and ICL Pathway will ensure all the relevant system derived
APS reconciliation reports are delivered on time to ensure that settlement can be made
between PON and it’s clients. In order to satisfy this requirement, ICL Pathway
elected to make all reconciliation reports available by 08.00hrs as stated in section 3.2,
on a daily basis.
NB. ICL Pathway is currently reviewing CTS reporting.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 21 of 23
FUJ00001567
FUJ00001567
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
6.2.1
6.3
Clerical Reconciliation Example in the event of non delivery of
CTS to PON
When using the APSS2133b report to calculate settlements due, PON / TP will need to
take account of the individual clients file delivery pattern and settlement frequency,
e.g. for clients who have elected to take five day delivery - Monday to Friday the
Monday delivery will include transactions harvested on the Friday / Saturday and
Sunday. For clients who have elected to take six day delivery - Monday to Saturday,
the Monday delivery will include transactions harvested on the Saturday and Sunday.
Impact of Client Migration on the Reconciliation Process
It is not expected that client migration will have any adverse impact upon the
established reconciliation processes now being employed by ICL Pathway.
Report APSS2133 already identifies transactions sent to both PON / HAPS and clients
as separate entries, client migration will just see transaction delivery growing in favour
of clients and reducing to HAPS.
However, the delivery of the CTS to PON is vital if settlement between PON and it’s
clients is to take place on a timely basis. Where this is not possible, contingency
procedures are being developed to use the APS reports; APSS2133 and APSS2133b
to provide a manual reconciliation to enable settlement to take place. This process has
been described within section 6.2.1 above.
© 2001 ICL Pathway Ltd. ©» COMMERCIAL IN CONFIDENCE Page 22 of 23
ICL Pathway Ltd APS Reconciliation & Incident Management Ref: CS/PRO/128
Version: 0.3
COMMERCIAL IN CONFIDENCE Date: 23 /05/ 2001
7.0 Appendix
1 - BIMS Report Example
BIMS Reference: = BE/0102010894 Final Update
Incident Type: 2 APS Version: 2 Last Updated: 06.0201 16:1559
Incident Class: 0044 Transaction(s) polled by TIP but not by HAPS
Originator: PW-MSU Transaction Date: 31-Jan01 CAP: 4600 FAD:
Status: 0 I Open Exception Value: £895.28
Other References I Transaction Liability I
PinICL Reference: Provisional: Final:
Incident Xref: Settlement Details
TIP/TP/OSG Ref: Transaction Settlement
System Incident References ‘Settled Amount:
HSH: Invoice Number:
PinICL Invoice Date:
Manual Error Report
Incident History Chargeable Errors:
Date Received: —01-Feb-Ot MER Set Amt:
Date Cleared: 02-Feb-01 MER Iny No:
Date Closed: MER Iny Date:
Actions
Actions: Date & Time 01/02/01 13:28:47 Action Type Describe Incident Analyst Mike King
The APS Daily Account Balancing Report 2133 for processing date 31/0101 shows 64 delayed
transactions that have net been deliveredto HAPS. Of these there are 26 which are being investigated
under 860101230757, BE 101261621, BEN1012907548 BED101210689. There are also 28 new
tins from FADs 152405 8 282226 and canythe error message Digtal Signature Failure.
Please see attached spreadsheet E-0101310680 for details of value, volume, client and tem ID.
Actions: Date & Time 02/02/01 11:54:09 Action Type Clear Incident Analyst Mike King
‘These transactions were successfully resent ond 1/02/01. PON needs to take no further action with
fegard tothese tins, This was cause by diffoulties in migrating APS software on seme countersat these
FADsto Cl4. 162405 8.282226 require swapping of base unts which will be carried out thé week.
Once this done there should be no further reoscurance
© 2001 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Page 23 of 23
FUJ00001567
FUJ00001567