POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
Document Title: Automated Payment End-to-end Reconciliation
Process For Release NR2 - Incident Management &
Resolution
Document Type: Process definition
Abstract: See page 2
Status: Version 1.0
Distribution: ICL Pathway and POCL Libraries
Authors: Bob Davis ICL Pathway Customer Service and
Bernadette O’Donnell POCL
Comments to:
Comments by:
COMMERCIAL IN CONFIDENCE Page 1 of 85
© 1999 ICL Pathway Ltd
F121
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
Abstract
This document:
e was jointly produced by ICL Pathway and POCL;
e was reviewed, validated and approved by the APS Reconciliation
Panel;
e describes the results of work carried out during the period
January 1999 to April 1999;
e focuses on:
e observed APS exceptions which could affect the accounting
processes carried out within post office outlets and POCL
central functions;
e the local resolution of exceptions;
e the raising of incidents when exceptions cannot be resolved
locally;
¢ resolution of the incidents.
Exceptions may be caused by user error, reference data error,
hardware failure, communications failure or software error.
Process definitions for EPOSS reconciliation and reference data error
management are detailed in separate documents (see associated
documents in section 0.3). This document concentrates on APS
transactions carried out at Horizon enabled post offices using
release NR2 software.
This document includes all APS reconciliation related exceptions
which have been identified to date and the planned method of
handling them. It is recognised that other incidents may arise
during live trial. If any new unexpected incidents occur in the
future they will be investigated by the appropriate authorities and
the relevant processes will be amended to accommodate the new
incident types.
Validation and reconciliation of APS data is carried out at a number
of points within the APS process chain - see appendix A for detail.
Validation and reconciliation may highlight exceptions. Exceptions
may be resolved locally within the outlet or central POCL
organisations. Exceptions which cannot be resolved locally are
raised as incidents with the appropriate helpdesk. At release NR2
Horizon enabled outlets will be supported by two help desks, i.e.
the existing ICL Pathway Horizon System Helpdesk (HSH) and the
new POCL Network Business Support Centre (NBSC). A set of
principles are included in this document which describe the scope of
each help desk and the key help desk interactions at NR2.
Within this document exceptions and incidents that are directly
related to APS accounting reconciliation are described in detail.
COMMERCIAL IN CONFIDENCE Page 2 of 85
F/12/2
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
Summary information is provided for incidents that relate to (a)
help desk advice and guidance, (b) incorrect operation of hardware,
comms. or software, (c) file transfer errors and (d) reference data
errors.
This document will be maintained under change control for the life
of release NR2 and updated when appropriate to reflect information
gained from live trial.
QO Document control
0.1 Document history
Versio IDate Reason
n
Scoping I22.3.99 ITo support the first Automated Payment Reconciliation
doc. Panel meeting scheduled for 23.3.99.
0.1 1.4.99 ITo support the second Automated Payment
Reconciliation Panel meeting scheduled for 12.4.99.
0.2 27.4.99 ISecond draft for APS Reconciliation Panel sign-off
1.0 16.6.99 I First definitive issue.
0.2 Approval authorities
Name Position Signature Date
ICL Pathway
Stephen Muchow I Director Customer
Service
POCL
Ruth Holleran
0.3 Associated documents
Reference IVer IDate Title Source
s
CS/PRD/045 I1.0 I16.6.99 IEPOSS End-to-end Reconciliation IICL
Process For Release NR2 - Pathway
Incident Management &
Resolution
COMMERCIAL IN CONFIDENCE Page 3 of 85
F/12/3
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
CS/PRD/046 Itba Itba Reference Data Error ICL
Management Pathway
CS/PRO/O58 {2.0 I15.2.99 IICL Pathway BSU Incident ICL
Reconciliation Procedures for NR2 I Pathway
CS/PRD/O59 I0.1 I29.3.99 INR2 End to End Incident ICL
Processes for TPS System Pathway
CS/PRD/O51 I0.1 I9.12.98 INR2 End to End Incident ICL
Processes for Automated Pathway
Payment Service System
CS/PRO/073 I0.8 I26.5.99 I Operational Level Agreement for IICL
Automated Payments Service Pathway
APGEN10.do APS Data Entry Validation Rules IPOCL
c
COMMERCIAL IN CONFIDENCE Page 4 of 85
F12/4
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
0.4 Abbreviations
APS Automated payment service
BES Benefit encashment service
BSU Business Support Unit (ICL Pathway)
CAP Cash account period
DSS Department of Social Security
EPOSS Electronic point of sale service
HSH Horizon System Helpdesk (ICL Pathway)
ISU Individual stock unit
NBSC Network Business Support Centre (POCL)
OBCS Order book control system
POCL Post Office Counters Limited
POITS Post Office IT Services
PW ICL Pathway Limited
RED Reconciliation exception database
SSU Shared stock unit
TP Transaction Processing
Changes in this version
BPS information removed plus cosmetic changes.
COMMERCIAL IN CONFIDENCE Page 5 of 85
F/12/5
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
0.6 Table of content
7 End-to-end Process
L INtrOCUCTION........cceescceessesseeseseeeeeeteesaseseaseseeessseeauecsaueessasesnasenseseneeeens
2 Scope...
3 Purpose
4 Approach
5 Principles for Automated Payment Reconciliation Incident
Management and ReSOIUtION..........::cccccccesssessesssseteeeseeseneeeeseserseeetenee
5.1 APS Reconciliation Process Design Principles..........ccscceeeeeees
6 Automated Payment Reconciliation Incident Management..............
6.1 Summary of Automated Payment Reconciliation Related
Exceptions Identified at Outlets...........cccceescceseseeseseesesesseeseensseeennes
6.1.1 Impacted Accounting ProceSSeS........ccccccessessseeeseeeeeeeeeeee
6.1.2 Horizon Advice & Guidance, Hardware, Communications
and Software ExCeptions.........ccccccccssseesssceeeseesseesseseeseesseessesenses
6.1.3 Reference Data Exceptions..........:ccecceeeeseseeeeereeeeenneeteeneee
6.1.4 APS Predefined Business Incidents Requiring ICL
Pathway BSU ACtiON.......ccccecscceecseneeeeeeeenereeseeneeeeesenteneeeseeeaeeeenees
6.1.5 Inappropriate Calls to either the POCL NBSC or the ICL
Pathway HSH... cece eececeeeeeeeseeesseesseeeeeesseseeeeeeseseeeseeeeeene
6.2 APS Reconciliation Related Exceptions Detected Within POCL
TRANSACTION PrOCESSING........:cccccesecceseceessceensceseeceessecsuesereessecneaeeenaes
6.2.1 Specific exceptions/iNCidents....... eee eeeeeeeeeeeeeeeeees
6.2.2 APS Predefined Business Incidents Requiring ICL
Pathway BSU Action
6.3 HAPS File Transfer Exceptions/Incidents Detected Within POCL
6.4 HAPS File Transfer Exceptions/Incidents Detected Within ICL
Pathway...
7.1 ProCeSS MOCEL........:ceeceesceseeeeseceseesseeecsueeeesesesseeeseeseeaeersaseeenaee
7.2 Process DeSCTIPtiONS...........ccceccceesceesseseseceseeeeerseeeeeeneeeeeeseseeneaee
8 Lower Level Models and Exception Handling..........::ccescssseesseeeeeeee
8.1 Complete Customer Session (Automated Payment) -
expansion of process 9 on end-to-end MOdEl........ccceceeeeeeeeeeeeeeee
8.1.1 Complete automated payment transaction using
magnetic card - expansion Of process 9.4........cecseceeeessteeeeeeeeenes
COMMERCIAL IN CONFIDENCE Page 6 of 85
F/12/6
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.1.2 Exceptions detected in process 9.4 Magnetic card
transaction.. :
8.1.3 Complete automated payment transaction using bar-
coded bill - expansion of process 9.4.0... eeeeeeeeeeeeneeeees
8.1.4 Exceptions detected in process 9.4 - Barcoded bill
EFANSACTIONS........cccsccesccessceesseeeseeeeceeseeeseesecseeenseeeesseenseeneseesaeeee®
8.1.5 Complete automated payment transaction by manual
keying - expansion Of Process 9.4... eee cece eeeeeeeeeeeeneeeee
8.1.6 Exceptions detected in process 9.4 - Manually keyed
transactions.
8.2 Reversal transactions
8.2.1 Process.
8.2.2 Exceptions detected in process 9 - Reversal transaction.
8.3 Complete Customer Session Fallback (Automated Payment) -
expansion of process 10 on end-to-end model... eee
8.3.1 Complete automated payment fallback transaction -
Expansion Of ProCceSS 10.4.......ccccccecesseeeceeeeseeeeeeseneeeeesseneeeeeeeeeeees
8.3.2 Exceptions detected in process 10.4 - Fallback
TFANSACTIONS........cccsccescceeseeenseeesseeeeceeseseeesecaeeessesessesesseetsersaneeee
8.4 Recover Fallback Transactions (Automated Payment) -
expansion of process 11 on end-to-end MoOdel.......ccceeeeeeeeeeeeeee
8.4.1 Recover automated payment fallback transaction -
expansion of process 11.. :
8.4.2 Exceptions detected in process 11 - recover transactions
accepted in fallback... .
8.5 Crash recovery - expansion of process 11
8.5.1 PLOCESS....ccceeeeceeeceeeessneeeeessseeeeesseeeeeeeeesesneeeeeeeeeeeseeesenneaes
8.5.2 Exceptions detected in process 11 - Crash recovery of
TFANSACTIONS........ccccccescceseecesseeesseeeeceeesesaeeseseeenseeeseseeeseeetseeeneree
8.6 Complete Daily and Weekly REports..........ecseeseeeeeeeeereeeeneeerees
8.6.1 Process
8.6.2 Exceptions detected in daily/weekly reporting..
8.7 Manage End of Day - Process 13 on End-to-end Model.
8.8 Maintain and Communicate EPOSS and APS Records - Process
14 on End-to-end MOdel........cccccscscsesesssseseseeeseesssessssessesesesesseesaeseees
8.9 Reconcile and Settle (POCL TP Chesterfield).............cccceeeeeeeeee
8.9.1 Expansion of process 15 - reconcile and settle
(CHEStErFICIA) oo. eeceeccecceceeceeeceeeceececeesseeescetseeessesseestseeesstseeeesees
COMMERCIAL IN CONFIDENCE Page 7 of 85
F12/7
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.9.1.3 Expansion of process 15.2 - settle with clients..............
8.10 Consolidate and Reconcile Automated Payment Records
(POCL Farnborough) - Process 16 on End-to-end model..........:::00e
8.10.1 PrOCESS......cccscsceseceseesesseesseeeseeceneecesseeeesseseeessseeeseseeeeensaee
8.10.2 Exceptions Detected by POCL Farnborough.............0
8.11 Maintain Payment Records (POCL Clients) - Process 17 on
End-to-end MOdel..........c:ccescccessccesseesneesseeeeeseeeneeeseeasesesseeeeaeseneaeeenegs
9 POCL Incident Management and Resolution Processes for
Automated Payment Related INCIGENtS...........cceeeeeeeeeseeseeeeeesneeeeeeeeeeeee
9.1 Advice for outlets on completion of key business process
while awaiting resolution Of INCIGENt........ eee eeeeeeneeeeeeeeeeeeeeeteneens
10 ICL Pathway Incident Management and Resolution Processes for
Automated Payment Related INCIGENtS...........:cccesseeeseeeseeeeeesteeeeeeeeeeeee
10.1 Key INt@rfaCeS.......eececcesteeeeseeneeeeeseneneeeeeeeeeeeeeneeeeeseeeeeeeeeneene
10.1.1 Automated Payment predefined business incidents.......
10.1.2 General Horizon system advice and guidance,
hardware, communications, software and file transfer related
INCIDENKS......eeeeceseeeeseceesseeseeeneeeeeaeeesaeseeeeeaeeeenaeseseeeneneeseeneasereas
10.1.3 Reference data CrrOrs.......cccccesesscesseeesesseeessseesenseseeeseesees
10.1.4 BSU raised system incidents..
10.2 Inappropriate calls from outlets..
10.3 Automated Payment Predefined Business Incidents
11 Appendix A - Validation and Reconciliation within the Automated
Payment Process Chain... cc ce cece eeceeseeeeeeseeeeeeeeseaeeeeeeeeenenees
COMMERCIAL IN CONFIDENCE Page 8 of 85
F/12/8
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
Introduction
This document:
e was jointly produced by ICL Pathway and POCL;
e was reviewed, validated and approved by the APS Reconciliation
Panel;
e describes the results of work carried out in the period January to
April 1999;
This document contains:
e a list of process design principles;
e a high-level end-to-end model (post office outlets to ICL Pathway
to POCL to POCL Clients);
e lower-level models which show where exceptions may be
detected;
e information on the raising and routing of incidents within POCL
and/or ICL Pathway;
¢ information on incident resolution.
Cross-references are made to:
« EPOSS end-to-end reconciliation incident management and
resolution processes;
« the Reference Data error management processes;
For the purposes of this document an APS reconciliation incident is
defined as a mismatch within the end-to-end APS process which
results in incorrect accounting records.
Validation and reconciliation of APS data is carried out at a number
of points within the APS process chain - see appendix A for detail.
Scope
The scope of this document includes:
e the APS service delivered at the post office outlet;
e the flow of automated payment information from post office
outlets to the central POCL systems and accounting functions;
e the detection of automated payment accounting reconciliation
related exceptions and the raising of automated payment
reconciliation incidents at post offices, within POCL and within
ICL Pathway;
e the resolution of automated payment reconciliation incidents;
COMMERCIAL IN CONFIDENCE Page 9 of 85
F/12/9
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
e if applicable, the assignment of liability for automated payment
reconciliation incidents using ICL Pathway/POCL agreed case law;
The scope excludes:
e detailed EPOSS reconciliation processes;
e detailed reference data error management processes;
e hardware, software, communications or operational incidents that
have no direct impact on Automated Payment accounting
records;
« supply of consumables, e.g. printer paper;
e external supplies, e.g. power;
e detailed POCL settlement processes;
e detailed POCL client processes.
3 Purpose
e To define a process framework for the:
* management of automated payment reconciliation incidents;
e resolution of automated payment reconciliation incidents.
e To support the development, enhancement and validation of local
procedures.
4 Approach
e ICL Pathway and POCL team approach to reconciliation process
definition, including joint authorship and joint
validation/approval via an APS Reconciliation Panel.
e Joint agreement of scope, purpose and approach.
e Joint development/validation/maintenance of:
© process design principles;
e high-level end-to-end process model;
e lower-level process models.
« Identification of points within POCL and ICL Pathway where APS
accounting reconciliation related exceptions may be detected.
« Capture and validation of processes for raising and routing APS
accounting reconciliation related incidents within POCL and ICL
Pathway.
COMMERCIAL IN CONFIDENCE Page 10 of 85
F/12/10
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
e Joint development/validation/maintenance of processes for
resolving APS accounting reconciliation related incidents.
e Process definitions approved signed-off by the APS Reconciliation
Panel;
Following APS Reconciliation Panel approval, process definitions
approved and signed-off by nominated ICL Pathway and POCL
senior managers;
e Following sign-off by nominated ICL Pathway and POCL senior
managers, process definitions progressed to contract controlled
status.
Principles for Automated Payment
Recon tion Incident Management and
Resolution
The following principles were used in the development of the
Release NR2 APS end-to-end reconciliation process. Changes to the
principles may necessitate the review and revision of the processes
detailed within this document.
Note 1: Within this document the term “exception” is used to
describe an exceptional situation that occurs locally within an outlet
or within the POCL TP (Transaction Processing) organisation.
Note 2: Within this document an “incident” is deemed to have
occurred when an exceptional situation is reported to and recorded
by either the ICL Pathway HSH (Horizon System Helpdesk), the
POCL NBSC (Network Business Support Centre) or the Incident
Management Point within POCL TP.
Note 3: The general principles below include the initial handling of
reference data errors because there is a significant interaction
between reference data and APS system functionality. In
exceptional circumstances an incident may be initially thought to be
a POCL reference data error but later found to be an error within the
ICL Pathway domain. It is also possible that an incident may
initially be thought to have been caused by an error within the ICL
Pathway domain but later found to be a POCL reference data error.
Both these situations require secondary routing of the initial
incident. Details of this is provided within the Reference Data Error
Management process - ref. CS/PRD/046.
5.1 APS Reconciliation Process Design Principles
P1 Outlets will, wherever possible, eliminate user errors before
raising an incident.
COMMERCIAL IN CONFIDENCE Page 11 of 85
F/12/11
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
P2 POCL TP Incident Management will, wherever possible, eliminate
human error and errors within POCL systems before raising an
incident with ICL Pathway.
P3 Wherever possible, APS related incidents that have accounting
reconciliation implications will be predefined so that they can be
easily identified and routed to the correct resolution point.
P4 For each predefined incident category there will be an agreed
“initial incident management contact point”. In the case of
outlets this will either be the ICL Pathway HSH or the POCL
NBSC. Outlets will not be advised to contact both. In the case
of POCL TP the initial contact point will be POCL TP Incident
Management.
P5 Incidents reported to the HSH that are defined as “APS
Predefined Business Incidents”, indicating that there are ICL
Pathway reconciliation implications, will be routed to the ICL
Pathway BSU (Business Support Unit). A category of “new” will
be used for unexpected incidents that are shown to have APS
reconciliation implications. Following investigation, valid new
incidents will be added to the list of APS Predefined Business
Incidents.
P6 The BSU will investigate APS predefined business incidents and
report findings on an APS RED (Reconciliation Exception
Database) Report.
P7 APS RED reports will be distributed to a defined single point
within POCL.
P8 POCL will define a single point for the receipt of APS RED
reports.
PQ Outlets will be advised to report detected Horizon system
hardware or communications incidents directly to the ICL
Pathway HSH.
P10 Outlets will be advised to report incidents that are likely to have
been caused by a Horizon system software error directly to the
ICL Pathway HSH.
P11(a) Outlets will be advised to report incidents that are likely to
have been caused by an error in the POCL reference data
(regardless of where the source of the error actually is) error
directly to the POCL NBSC.
P11(b) Outlets will be advised to report incidents that are likely to
have been caused by an error in the ICL Pathway reference data
(regardless of where the source of the error actually is) directly
to the HSH.
P12 In situations where an incident could have been caused by
either a POCL reference data error or a Horizon system software
COMMERCIAL IN CONFIDENCE Page 12 of 85
FI42/12
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
error, the incident will initially be treated as a potential POCL
reference data error, i.e. incident raised with the POCL NBSC.
P13 In situations where a key outlet business process is impacted
by an unresolved incident of any type, the outlet will be advised
to contact the POCL NBSC for advice and guidance.
P14 ICL Pathway and POCL will work together to ensure that the
advice and guidance information provided by the HSH and the
POCL NBSC is compatible with the knowledge and culture within
the outlet.
P15 Where appropriate, ICL Pathway technical domains will trigger
the raising of an APS predefined business incident, e.g. when an
ICL Pathway technical incident is shown to have caused APS
reconciliation implications.
P16 Where appropriate, the ICL Pathway BSU will trigger the raising
of a technical incident, e.g. when an APS predefined business
incident suggests that there might be an underlying ICL Pathway
software error.
P17 Both the HSH and NBSC will conform to the principles described
above. If an outlet makes a call to the HSH which relates to
P11(a) , P12 or P13, the call will be treated as inappropriate and
the outlet will be advised by the HSH to call the NBSC. If an
outlet makes a call to the NBSC which relates to P9, P10 or
P11(b), the call will be treated as inappropriate and the outlet
will be advised to call the HSH. If either help desk starts
handling a call because it initially appears to be appropriate, but
then finds that it is the responsibility of the other desk, then the
help desk handling the call will inform the outlet that they are
referring the call to the other help desk, terminate the call with
the outlet and inform the other desk. The other desk will
contact the outlet and continue advice and guidance and/or
resolution.
P18 Both the HSH and NBSC will take action to avoid outlets being
passed backwards and forwards between the two help desks. If
when calling a help desk the outlet mentions that they have
already been referred from the other help desk, then the help
desk taking the call second will take control of the call and
interact with the other desk to agree how the incident will be
progressed.
COMMERCIAL IN CONFIDENCE Page 13 of 85
F/12/13
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
6 Automated Payment Reconciliation Incident
Management
6.1 Summary of Automated Payment Reconciliation
Related Exceptions Identified at Outlets
The following provides a summary of the categories of exception
which may be detected within a post office outlet and the action
taken. Specific exceptions are discussed later in this document.
Exceptions become incidents when they are reported to and
recorded on either the POCL incident management system (TP
Incident Management at Chesterfield or NBSC at Leeds) or the ICL
Pathway HSH. The handling of APS reconciliation related incidents
within POCL and ICL Pathway is described in sections entitled POCL
Incident Management and ICL Pathway Incident Management at the
rear of this document.
6.1.1Impacted Accounting Processes
This category includes situations where a key accounting process,
performed by outlets, is impacted by an unresolved incident of any
type.
Type of I Outlet Contact ICL Contact I POCL
Exception action ICL Pathway I POCL Desk
Detected Within Pathway I Desk Name
Outlet Name
Time-critical Follow No - Yes - for I NBSC
business advice advice
process, e.g.I given by
stock unit or} POCL further
account rollover, I desk ation
impacted by an provided
unresolved in
incident of any section
type. 9.
COMMERCIAL IN CONFIDENCE Page 14 of 85
F214
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
6.1.2 Horizon Advice & Guidance, Hardware, Communications and
Software Exceptions
Type of I Outlet Contact ICL Contact I POCL
Exception action ICL Pathwa I POCL Desk
Detected Within Pathway Iy Desk Name
Outlet Name
Horizon system I Follow Yes HSH No -
advice and I advice
guidance given by
required. HSH
Horizon counter I Use Yes - for I HSH No -
system fallback advice
hardware not I procedure I and/or
working s resolution
correctly, e.g.
printer will not
work.
Horizon counter I Use Yes - for I HSH No -
system unable I fallback advice
to communicate I procedure I and/or
with central I s resolution
systems.
Horizon counter I Use Yes - for I HSH No -
system fallback advice
observed to I procedure I and/or
operate Ss resolution
incorrectly
indicating that
there may be a
software error,
e.g. error
message,
system not
responding.
COMMERCIAL IN CONFIDENCE Page 15 of 85
F215
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
6.1.3 Reference Data Exceptions
Type of I Outlet Contact I ICL Contact POCL
Exception action ICL Pathway I POCL Desk
Detected Within Pathway I Desk Name
Outlet Name
Price Eliminate I No - Yes - for I NBSC
information onI any input advice
Horizon system I errors and
incorrect, where
includes necessary
situations where resolution
scales show
correct weight
but wrong price.
Expected Eliminate I No - Yes - for I NBSC
product not I any input advice
available. errors and
where
necessary
resolution
Product Eliminate I No - Yes - for I NBSC
information any input advice
wrong, e.g. I errors and
min/max price where
or quantity necessary
incorrect. resolution
Post - No - Yes - toINBSC
office/phone resolve
number
incorrect.
Method of I Eliminate I No - Yes - for} NBSC
payment wrong. I any input advice
errors and
where
necessary
resolution
Other reference I - No - Yes NBSC
data related
exceptions - see
CS/PRD/046 for
further
information
COMMERCIAL IN CONFIDENCE Page 16 of 85
FI42/16
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
6.1.4APS Predefined Business Incidents Requiring ICL Pathway
BSU Action
APS reconciliation incidents that require ICL Pathway BSU
involvement in their resolution are known within ICL Pathway as
“APS Predefined Business Incidents”.
When appropriate these incidents are communicated by the outlet
to the ICL Pathway HSH. The handling of APS Predefined Business
Incidents within ICL Pathway is described in the section entitled ICL
Pathway Incident Management at the rear of this document.
incidents of this type are currently identified.
6.1.5 Inappropriate Calls to either the POCL NBSC or the ICL
Pathway HSH
No
If outlets make calls to the ICL Pathway HSH that relate to the
exceptions described in 6.1.1 above or reference data related
exceptions described in 6.1.3 above, the HSH advises the outlet to
contact the NBSC.
If outlets make calls to the NBSC that relate to the exceptions
described in 6.1.2 above, the NBSC advises the outlet to contact the
HSH.
6.2 APS Reconciliation Related Exceptions Detected
Within POCL Transaction Processing
6.2.1 Specific exceptions/incidents
Specific exceptions are discussed later in this document.
TP
exceptions become incidents when they are reported to and
recorded by the TP Incident Management Point. The TP Incident
Management system is linked with the NBSC at Leeds. Suspected
reference data incidents are reported by TP Incident Management to
the NBSC.
6.2.2 APS Predefined Business Incidents Requiring ICL Pathway
BSU Action
APS reconciliation incidents that require ICL Pathway BSU
involvement in their resolution are known within ICL Pathway as
“APS Predefined Business Incidents”.
When appropriate these incidents are communicated by POCL TP
Incident Management to the ICL Pathway HSH. The handling of APS
Predefined Business Incidents within ICL Pathway is described in the
section entitled ICL Pathway Incident Management at the rear of
this document.
COMMERCIAL IN CONFIDENCE Page 17 of 85
FI42/7
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
6.3 HAPS File Transfer Exceptions/Incidents Detected
Within POCL
Exceptions related to HAPS file transfer from ICL Pathway may be
detected within POCL System Support (POITS) in Farnborough or
POCL OSG. POITS will detect files not received and OSG will be
aware of error and OK files returned to ICL Pathway. During POCL
normal working hours all communications regarding incident and
file management will be between OSG and HSH. During POCL out
of hours all communications for incident and file management will
be between POITS and HSH.
6.4 HAPS File Transfer Exceptions/Incidents Detected
Within ICL Pathway
File transfer exceptions that are detected within ICL Pathway
Operations are reported to the HSH. Incidents are raised by the
HSH and routed to the appropriate expert domain for resolution.
COMMERCIAL IN CONFIDENCE Page 18 of 85
F/12/18
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
7 End-to-end Process
7.1 Process model
See next page See
NB: References 1, 2 and 3
were previously used for BPS
processes
4 - Maintain/
Communicate
Reference Data
POCL
5 - Maintain/
Communicate
Reference Data
PW
17 - Maintain next
Ona Payment Records: page
Or ®
APS A oC
Client Client
data
Data from 16 Consolidate 15 - Reconcile
manual po 5 ment Records 2™) and Settle
lets ayment Records
out (Famboroush (Chesterfield)
and APTs (Farnborough)
Al POCL Al Poct
HAPSI INTER- TIP IINTER-
FACE FACE
14 - Maintain/
Communicate
Event C - EPOSS and APS
Automatic End of Records
Day Marker Set
[pw
I See
I (A) next
6 - Maintain 7 - Control APS I I 13 - Manage End 12 - Maintain
Reference Data of Day EPOSS Records
Outlet Outlet Outlet A I Outlet
See
8 - Control OBCS (B) next
page
Counter
System Outlet
Event A -
Customer requests
service
Available 215 —Compleie
Yes I Customer Session
(OBCS, APS
and EPOSS)
Event B -
Outlet Initiates
Recovery
Outlet
Customer
(fallback)
10 - Complete
11 - Recover
Fallback
Transactions
Session-—j> Until recovery
carried out
Outlet Outlet
COMMERCIAL IN CONFIDENCE Page 19 of 85
FI12/19
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution ,
From process 12 (q
see previous page I
Event D - End 18 - Complete
of trading day Daily Cash LeiX)
Declaration
[outer]
y Daily
Event E - Daily 19-Complete I Report
despatch of produc Daily Reports
reports requir To
Outlet process
To process 17 see
12 see previous
previous page
page IE F Weekh
vent F- 20 - 1 ecklyI
IWeekly despatch We hi Repent s Report
jof product reports .
required.
Outlet
21 - Balance
§€£@————— .
Stock Unit and
Roll-over (ISU)
~ or
Event G - End 0 - Balance
of Balance Period .
for Stock Unit Stock Unit and
Roll-over (SSU)
Outlet
i<«.
Ad
23 - Balance Cash
Account and Roll-overI
Event H - End (Normal CAP)
of Cash Account jor
Period 24 - Balance Cash
Account and Roll-over
(2/3 Week CAP)
jor
Paper cash account
and supporting
© documents
To process 15
see previous page
25 - Balance Cash
Account and Roll-over
(Final CAP)
lor
126 - Balance Cash
Account and Roll-ovel
I(initial CAP)
Outlet
COMMERCIAL IN CONFIDENCE
Page 20 of 85
F/12/20
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
7.2 Process Descriptions
NB: References 1, 2 and 3 were previously used for BPS processes,
which are now no longer relevant.
Processes 4, , 5 and 6 - Reference data processes
These processes describe how product and outlet reference data is
manage - see ICL Pathway documents CS/PRD/030 (product) and
CS/PRD/050 (outlet). References data error management is
described in CS/PRD/046.
Process 7 - Control APS
Includes the APS functionality provided within the Horizon system -
see ICL Pathway document CS/PRD/044 for further information.
Process 8 - Control OBCS
Includes the OCBS functionality provided within the Horizon system.
Event A - Customer requests service
Includes requests for automated payment and/or EPOSS
transactions. Also includes enquiries relating to automated
payment and/or EPOSS transactions.
Process 9 - Complete customer session (OBCS/APS/EPOSS)
A session comprises one or more OBCS, APS or EPOSS transactions.
Included are transactions completed using the automated features
of the Horizon system, e.g. card reader, bar code reader, receipt
printer, etc.. Also included are transactions completed when
peripheral equipment is temporarily unavailable. In these
situations the outlet enters transaction details via the keyboard,
prepares manual receipts, etc.
An expanded view of the Complete Customer Session process is
provided within this document in section entitled Lower Level
Models.
Further details are available in POCL business process diagrams :
EPOSS - 17/12/8/9/10/11/60/26/27/18
APS - 1/8/16
OBCS - 10/9/11/6/4&5/1&2
Process 10 - Complete customer session (fallback)
If the Horizon system is unavailable, e.g. PC hardware failure, the
outlet reverts to manual operation. The manual receipts and
counter-foils used during fallback are used later when recovery
(process 11) is carried out.
An expanded view of the Complete Customer Process (fallback)
process is provided within this document in section entitled Lower
Level Models.
COMMERCIAL IN CONFIDENCE Page 21 of 85
F/12/21
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
Further details are available in POCL business process diagrams :
Integrated Service - 47
Event B - Outlet triggers recovery
Transactions completed in fallback need to be entered into the
Horizon system when the system returns to normal operation.
Recovery can be completed as soon as the system is available or
when the user has time to enter the transactions. However,
recovery must be completed before the end of the Cash Account
Period.
Process 11 - Recover fallback transactions
Transactions processed during fallback are entered to the system as
part of the recovery process. AP has a recovery modes for this
purpose. EPOSS transactions are entered in bulk or individually.
An expanded view of the Recover Fallback Transactions process is
provided within this document in section entitled Lower Level
Models.
Further details available in POCL business process diagrams :
Integrated Service - 48
Process 12 - Maintain EPOSS records
The system maintains a log of all the transactions performed in the
outlet which is updated as the transactions are entered to the
system. The transaction log can be accessed at any time to assist
with enquiries or to perform other activities in the stock unit, e.g.
reports, balancing, transaction reversals, etc.
Event C - Automatic end of day marker set
At the end of the trading day (either 30mins after office closing or
7pm) an accounting marker is set which indicates the end of the
trading day for the outlet - see ICL Pathway document CS/PRD/044
for further information.
Process 13 - Manage end of day
The end of day marker indicates the end of the outlet trading day.
The setting of the end of day marker prevents the reversal of
automated payment transactions performed during the day. A
manual end of day activities facility can be selected by the user.
This displays the outstanding mandatory daily activities for the
stock unit.
Further details are available in POCL business process diagrams :
Integrated Service - 49
See ICL Pathway document CS/PRD/044 for further information.
Process 14 - Maintain/communicate EPOSS and APS records
COMMERCIAL IN CONFIDENCE Page 22 of 85
F/12/22
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
This process includes the communication of transaction details from
post office outlets to the ICL Pathway correspondence servers,
onward communication to the central ICL Pathway systems and
then on to the POCL TIP and HAPS system interfaces.
An expanded view of the Maintain/Communicate EPOSS and APS
Records process is provided within this document in section entitled
Lower Level Models.
Process 15 - Reconcile and settle
This process includes the receipt of the information which makes up
the Cash Account, validation against volume/value and storage for
various purposes (e.g. RMMI (Royal Mail Management Information)).
When the full week’s data has been received it is then reported to
CBDB.
TIP receives the cash declaration from the outlets which forms part
of the snapshot balance and supports the information which
appears on the Cash Account. TIP does not receive daily/weekly
reports or stock unit balances. TIP only receives the outlet cash
account.
TIP also receives STX records which are stock holdings per item on
hand at the end of the accounting week. The information is used to
reconcile and settle with each client.
The information is received on a daily basis (between 8.00am and
15.00) by File Transfer Protocol (FTP) from the gateway PC.
An expanded view of the Reconcile and Settle process is provided
within this document in section entitled Lower Level Models.
Process 16 - Consolidate and reconcile automated payment
records
AP transactions accepted at the outlet are polled on a daily basis
after the end of day marker has been set. The information is sent
via HAPS to Farnborough who sort the data into clients. The
information is forwarded to settlements so that payment can be
made to the client.
Further details are available in POCL business process diagrams :
APS - 3
The information received from Farnborough updates APACHI and is
compared to the entry on cash account by outlet. Discrepancies
discovered are investigated and corrected within Transaction
Processing.
See ICL Pathway document CS/PRD/044 for further information.
Process 17 - Maintain automated payment records
COMMERCIAL IN CONFIDENCE Page 23 of 85
F/12/23
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
POCL clients receive automated payment transaction information
from Farnborough. Clients use this information to support
settlement processes.
Event D - End of trading day
The end of the trading day for a user/stock unit usually occurs at
completion of the daily shift.
Process 18 - Complete daily cash declaration
The cash on hand is declared to the Horizon system, on a daily
basis, for reporting purposes, at the end of the user/stock unit
trading day.
An expanded view of the Complete Daily Cash Declaration process
is provided within this document in section entitled Lower Level
Models.
Further details are available in the POCL business process
diagrams :
EPOSS - 38
Event E - Daily despatch of product reports required
Documents accepted during the trading day into the stock unit are
despatched internally within POCL and externally to POCL clients.
Process 19 - Complete daily reports
At the agreed time for the outlet, each stock unit produces the
mandatory daily reports. The user checks that the report agrees
with the actual documents, amends if necessary and despatches
the documents with the supporting report.
An expanded view of the Complete Daily Reports process is
provided within this document in section entitled Lower Level
Models.
Further details are available in the POCL business process
diagrams :
EPOSS - 35&36/56&57
Event F - Weekly despatch of product reports required
Documents which are not despatched daily are sent on a weekly
basis when the cash account has been produced.
Process 20 - Complete weekly reports
Each stock unit produces the reports to support the documents (as
process 18). Some products also require an outlet report which is a
summary of all the stock unit reports.
An expanded view of the Complete Weekly Reports process is
provided within this document in section entitled Lower Level
Models.
COMMERCIAL IN CONFIDENCE Page 24 of 85
F/12/24
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
Further details are available in the POCL business process
diagrams :
EPOSS - 35&36/54/56&57
Event G - End of balance period for stock unit
On transfer of accountability of a stock unit or at the end of the
cash account period (CAP) all stock units have to be balanced.
Process 21 and 22 - Balance stock unit and roll-over
The purpose of balancing is to assess the state of the stock unit by
confirming the entries on the Horizon system against the
documents, cash and stock on hand. Once the user confirms that
the balance is accurate the stock unit is rolled into the next BP or
CAP depending on what is required by the user/outlet. The impact
of rolling the stock unit removes the transaction information from
the stock unit, carrying forward the cash and stock on hand to the
next accounting period.
Stock units may be individual stock units or shared stock units.
An expanded view of the Balance Stock Unit and Roll-over process
is provided within this document in section entitled Lower Level
Models.
Further details are available in the POCL business process
diagrams :
EPOSS - 37/59/39/58
Event H - End of cash account period
The cash account is a summary of all the transactions performed
within the outlet during the accounting week and a declaration of
cash and stock on hand at the close of the accounting period. The
accounting period is usually one week and the account is therefore
produced weekly.
Process 23, 24, 25 and 26 - Balance cash account and roll
over
The cash account is an amalgamation of all the stock unit balances
for the outlet. When the cash account is completed and produced
the outlet moves forward to the next cash account period (CAP).
Cash accounts usually cover one week. However, by exception
cash accounts may cover two or three weeks. A final cash account
is produced when an outlet changes ownership or when an outlet is
temporarily or permanently closed. An initial cash account is used
when an outlet migrates to the Horizon system.
An expanded view of the Balance Cash Account and Roll-over
process is provided within this document in section entitled Lower
Level Models.
COMMERCIAL IN CONFIDENCE Page 25 of 85
F/12/25
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
Further details are available in the POCL business process
diagrams :
EPOSS - 40/50/51
COMMERCIAL IN CONFIDENCE Page 26 of 85
F/12/26
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8 Lower Level Models and Exception Handling
8.1 Complete Customer Session (Automated Payment) -
expansion of process 9 on end-to-end model
Event A -
Customer requests
service
To Maintain EPOSS.
9.1 - Initiate Records (process 12
Customer on end-to-end model)
Session
9.2 - Select «Complete BES Transaction” 9.9 - End
Appropriate ‘Complete BES Transaction Customer
Service on
Another A
transaction
Reference data required ?
94 - Complete ,, I 98- Seitle
Automated No I Customer
I__I s
Payment Session by
‘Transaction I Yes I_ Selecting MOP
I Printed receipts
I Reference data
I stamps
I
I I
1 i
i i
I I
COMMERCIAL IN CONFIDENCE Page 27 of 85
F/12/27
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.1.1Complete automated payment transaction using magnetic
card - expansion of process 9.4
From process 9.2 -
Select appropriate
service
94.1 -
Swipe Card
Card and
number
accepted To process 9.4.7 (key manually)
by system ? Yes
9.4.4 -
Enter Value
9.43 -
Enter MOP
Receipt (first copy)
945 - > To customer
I R ts Receipt (second coy
Sue ieee is Pt PY) Retained by outlet
Another No To process 9.8 - Settle
transaction > customer session by
required ? Yes selecting MOP
To process 9.2 - Select
Appropriate Service
COMMERCIAL IN CONFIDENCE Page 28 of 85
F/12/28
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.1.2 Exceptions detected in process 9.4 Magnetic card
transaction
Process
ref.
Exception type
Action by post office outlet
9.4.1 Card will not swipe
User keys number in manually
If the problem is repeated on several
cards the hardware problem is
reported to the HSH.
If the problem is repeated on a batch
of client cards the problem should be
reported to the NBSC who will advise
the client account manager.
9.4.3 MoP displayed does
not correspond with
users expectations
and/or customer's
payment.
User checks the acceptable MoP with
manual instructions (Counter News/
Counter Operations Manual)
If the system is correct:
e Advise the customer to tender
correct MoP
If the system is incorrect:
* Contact the NBSC - problem could
be reference data.
The user will enter the transaction
selecting the incorrect MoP as part of
the AP transaction but will settle the
customer session with the MoP
tendered by the customer.
If the NBSC prove the problem is not
with POCL Reference Data the incident
is passed to HSH.
9.4.4 Value entered by the
user is not accepted
by the system
User checks the acceptable value with
manual instructions (Counter News/
Counter Operations Manual)
If system is incorrect:
e Contact the NBSC - problem could
be reference data
The user will enter the transaction
to the system as a_ fallback
transaction while the customer is
present. As this is a different screen
to the ‘serve customer’ screen the
user may have _to_enter_two
COMMERCIAL IN CONFIDENCE
Page 29 of 85
F/12/29
ICL
Pathway
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
transactions if the customer is
purchasing other products.
If system is correct:
e Less than minimum on the system -
inform the customer and refuse
the transaction
e Multiple value not met - inform the
customer and change value to
meet the customer's
requirements
e More than the maximum on the
system - accept multiple
transactions to meet the amount
required by the customer
° 9.4.5 No receipt produced I User checks the printer to ensure that
it has sufficient paper.
If it has not :
e Replenish and reprint the receipt
(if the outlet has no supplies the
user will contact the supplier for
emergency supplies and_ transfer
the session to another node with
paper in the printer (if available) or
issue a manual receipt (no
agreement to this at present))
If it has:
* Contact HSH
(user may have to complete a
manual receipt - no agreement to
this at present)
9.4.5 Second receipt not I User checks the printer to ensure that
printed (office copy)
it has sufficient paper.
If it has not :
e Replenish and reprint the receipt
(if the outlet has no supplies the
user will contact the supplier for
emergency supplies and _ transfer
the session to another node with
paper in the printer (if available) or
issue a manual receipt (no
agreement to this at present))
COMMERCIAL IN CONFIDENCE Page 30 of 85
F/12/30
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
If it has:
e The user may have swiped another
card too quickly or selected a
function button during the
production of the receipts. The
user selects receipt (before the
end of the customer session)
which will display any
outstanding AP receipts and the
user selects the required receipt
and the system will produce the
second receipt
If the above does not solve the
problem then the user will need to :
« Contact HSH
(user may have to complete a
manual receipt - no agreement to
this at present)
COMMERCIAL IN CONFIDENCE Page 31 of 85
F/12/31
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.1.3 Complete automated payment transaction using bar-coded
bill - expansion of process 9.4
From process 9.2 - 94.6 -
Select appropriate —————3™I_ Scan Barcode
service
Barcode and
number
accepted
by system ?
To process 9.4.7 (key manually)
Is a default
amount
applicable ?
9.4.2 - System
Displays Default
Amount
Does Customer No 944-
Want to Pay Enter Value
Default Amount ? Yes
9.43 -
Enter MOP
Receipt (first copy)
945 - To customer
Issue Receipts I Receipt (second copy)
Retained by user
Another No To process 9.8 - Settle
transaction customer session by
required ? Yes selecting MOP
To process 9.2 - Select
Appropriate Service
COMMERCIAL IN CONFIDENCE Page 32 of 85
F/12/32
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.1.4 Exceptions detected in process 9.4 - Barcoded bill
transactions
Process
ref.
Exception type
Action by post office outlet
9.4.6 Barcode will not scan
User keys number in manually
If the problem is repeated on several
barcodes the hardware problem is
reported to the HSH.
If the problem is repeated on a batch
of client barcodes the problem should
be reported to the NBSC who will
advise the client account manager.
9.4.2 Default amount
displayed is incorrect
User checks the amount displayed
with the amount on the bill and
processes as normal if the amount is
correct.
If there is a discrepancy:
« User overwrites the amount with the
correct amount
* contacts the HSH - problem could be
hardware / software / reference
data.
If the problem is highlighted on
several bills of the same product the
faulty barcodes are reported to the
NBSC.
9.4.2 Default
missing
amount is
The user may not be aware that the
default amount is missing.
User enters the amount and confirms.
If the problem is highlighted on
several bills of the same product the
faulty barcodes are reported to the
NBSC.
9.4.4 Value entered by the
user is not accepted
by the system
User checks the acceptable value with
manual instructions ( Counter News /
Counters Operations Manual)
If system is incorrect:
« Contact the NBSC - problem could
be reference data
The user will enter the
transaction to the system as a
COMMERCIAL IN CONFIDENCE
Page 33 of 85
F/12/33
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
fallback transaction while the
customer is present. As this is a
different screen to the ‘serve
customer’ screen the user may
have to enter two transactions if
the customer is purchasing other
products.
If system is correct:
e Less than minimum on the system -
inform the customer and refuse
the transaction;
e Multiple value not met - inform the
customer and change value to
meet the customer's
requirements;
e More than the maximum on the
system - accept multiple
transactions to meet the amount
required by the customer.
e 9.4.3 MoP displayed does I User checks the acceptable MoP with
not correspond with I manual instructions (Counter
users expectations I News/Counters Operations Manual)
and/or customer’s I if the system is correct :
payment.
e Advise the customer to tender
correct MoP
If the system is incorrect :
e Contact the NBSC - problem could
be reference data
e The user will enter the transaction
selecting the incorrect MoP as
part of the AP transaction but will
settle the customer session with
the MoP tendered by the
customer.
e If the NBSC prove the problem is not
with POCL Reference Data the
incident is passed to HSH.
e 9.4.5 No receipt produced I User checks the printer to ensure that
it has sufficient paper
If it has not :
e Replenish and reprint the receipt
COMMERCIAL IN CONFIDENCE Page 34 of 85
F/12/34
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
e If the outlet has no supplies the
user will contact the supplier for
emergency supplies and transfer
the session to another node with
paper in the printer (if available)
or issue a manual receipt (no
agreement to this at present)
If it has:
« Contact HSH
e User may have to complete a
manual receipt (no agreement to
this at present)
° 9.4.5 Second receipt not} User checks the printer to ensure that
printed (office copy) I it has sufficient paper
If it has not :
e Replenish and reprint the receipt
e If the outlet has no supplies the
user will contact the supplier for
emergency supplies and transfer
the session to another node with
paper in the printer (if available)
or issue a manual receipt (no
agreement to this at present)
If it has:
e If the user has swiped another card
too quickly or selected a function
button during the production of
the receipts. The user selects
receipt (before the end of the
customer session) which will
display any outstanding AP
receipts and the user selects the
required receipt and the system
will produce the second receipt
If the above does not solve the
problem then the user will need to :
* Contact HSH
e User may have to complete a
manual receipt (no agreement to
this at present)
COMMERCIAL IN CONFIDENCE Page 35 of 85
F/12/35
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.1.5 Complete automated payment transaction by manual keying
- expansion of process 9.4
From process 9.4.1 (swipe 9.4.7 - Select
magnetic card) and —————>} Product (manual
process 9.4.6 (scan barcode) - AP plus MC/BC)
card or barcode cannot be read y
9.4.8 - Enter
Reference
Number
Reference 9.4.9 - Check
number ‘That Number WasI
accepted Entered Correctly
by system ?
Reference
number No ne 10-
entered Nosh
correctly ? II, Yes umber
9412-
944- 9.4.12 - Check
that the card
Enter Value «care
is valid
Is the Yes 9.4.13 - Contact
card POCL NBSC
Y valid? Yo ny
943- rad 1 - Refer
Enter MOP ustomer (0
Issuing Authority]
v
Receipt (first copy)
9.4.5 - To customer
Issue Receipts I Receipt (second copy) .
Retained by user
Another No To process 9.8 - Settle
transaction customer session by
required ? Yes selecting MOP
To process 9.2 - Select
Appropriate Service
COMMERCIAL IN CONFIDENCE Page 36 of 85
F/12/36
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.1.6 Exceptions detected in process 9.4 - Manually keyed
transactions
Process I Incident type Action by post office outlet
ref.
9.4.7 User selects incorrect I User notices :
ee ecm) ane e User reverses the transaction and
it y: Pp re-enters it correctly
User does not notice :
e This may create a customer / client
enquiry to Transaction Processing
(AP team) - existing procedure is
in place to address this.
¢ 9.4.8 Reference number I User checks the number entered on
keyed incorrectly the system against the card or bill and
re-keys (total of 3 entries) the number
if there is a discrepancy
9.4.8 Reference number I User checks that the card / barcoded
keyed correctly but is I bill is for a valid scheme from manual
not accepted by the] instructions (Counter News/Counters
system Operations Manual )
If invalid :
e Inform the customer and terminate
the transaction
If valid :
¢ Contact the NBSC - to eliminate
incorrect use of the system by the
user / reference data
« The user processes the transaction
as a fallback transaction
e If the NBSC prove the problem is not
with POCL Reference Data the
incident is passed to HSH
° 9.4.4 Value entered by the I User checks the acceptable value with
user is not accepted I manual instructions ( Counter
by the system News/Counters Operations Manual)
If system is incorrect :
¢ Contact the NBSC - problem could
be reference data
The user will enter the transaction
to the system as a_ fallback
COMMERCIAL IN CONFIDENCE
Page 37 of 85
F/12/37
ICL
Pathway
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
transaction while the customer is
present. As this is a_ different
screen to the ‘serve customer’
screen the user may have to enter
two transactions if the customer is
purchasing other products.
If system is correct :
e Less than minimum on the system -
inform the customer and refuse
the transaction
e Multiple value not met - inform the
customer and change value to
meet the customer's
requirements
More than the maximum on the
system - accept multiple
transactions to meet the amount
required by the customer
© 9.4.3
MoP displayed does
not correspond with
users expectations
and/or customer's
payment.
User checks the acceptable MoP with
manual instructions ( Counter News/
Counters Operations Manual)
If the system is correct :
e Advise the customer to tender
correct MoP
If the system is incorrect :
e Contact the NBSC - problem could
be reference data
e« The user will enter the transaction
selecting the incorrect MoP as
part of the AP transaction but will
settle the customer session with
the MoP tendered by the
customer.
e If the NBSC prove the problem is not
with POCL Reference Data the
incident is passed to HSH
° 9.4.5
No receipt produced
User checks the printer to ensure that
it has sufficient paper.
If it has not:
e Replenish and reprint the receipt
e If the outlet has no supplies the
COMMERCIAL IN CONFIDENCE Page 38 of 85
F/12/38
ICL
Pathway
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Reconciliation Process For Release Ve'sion 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
user will contact the supplier for
emergency supplies and transfer
the session to another node with
paper in the printer (if available)
or issue a manual receipt (no
agreement to this at present)
If it has:
« Contact HSH
e User may have to complete a
manual receipt (no agreement to
this at present)
© 9.4.5
Second receipt not I User checks the printer to ensure that
printed (office copy) I it has sufficient_ paper
If it has not :
e Replenish and reprint the receipt
e If the outlet has no supplies the
user will contact the supplier for
emergency supplies and _ transfer
the session to another node with
paper in the printer (if available) or
issue a manual receipt (no
agreement to this at present)
If it has:
e If the user has swiped another card
too quickly or selected a function
button during the production of
the receipts. The user selects
receipt (before the end of the
customer session) which will
display any outstanding AP
receipts and the user selects the
required receipt and the system
will produce the second receipt
If the above does not solve the
problem then the user will need to :
« Contact HSH
e User may have to complete a
manual receipt (no agreement to
this at present)
° 9.4.8
Service code not} User checks the entry to the system
accepted by the] against the card and re-keys if
system necessary
COMMERCIAL IN CONFIDENCE Page 39 of 85
F/12/39
ICL
Pathway
Automated Payment End-to-end ;
Reconciliation Process For Release Ve"sion
NR2 - Incident Management &
Resolution
POL00000776
POL00000776
Ref: CS/PRD/044
1.0
Date. 16/06/99
If the problem is not resolved :
e The user contacts the NBSC who
may be able to confirm the
correct service code
e If the service code is correct the
NBSC prove that the problem is
not with POCL Reference Data
and the incident is passed to
HSH.
The transaction will be processed as
an APS EPOSS transaction.
° 9.4.8 Out of hours trxns I The user will process the transaction
The receipt from the as an APS EPOSS transaction
transaction cannot
be entered as a
manual transaction
(reference number
recorded incorrectly
or receipt is
unreadable)
9.4.8 Out of hours trxns I Contact NBSC who will advise the user
. if they can input it as a recovery
The receipt from the I ! F
transaction cannot transaction or as an APS EPOSS
be entered as a} ‘ansaction.
manual transaction
(perameter checks
have failed)
Out of hours trxns I Contact NBSC as they may be able to
Th rvi F establish the service code, if not the
not ceric none is user will process as an APS EPOSS
has not been I transaction
captured on_ the
manual receipt
9.4.8 Out of hours trxns I Currently BT bills only
The counterfoil kept
during the fallback
barcode bill
transaction has no
barcode
e The user would process as a non-
barcded bill using the existing
methods
COMMERCIAL IN CONFIDENCE
Page 40 of 85
F/12/40
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date, 16/06/99
Resolution
8.2 Reversal transactions
8.2.1 Process
IAPS transaction
requires reversing
(customer copy 9.4.7 Disallowed on
Select AP disconnected
—— Reversal nodes
Conditions:
9.4.8 . - current stock unit
Enter Transaction - current CAP
Reference Number} _ not already reversed
- not a reversal transaction
- before end of day marker set
- transaction is flagged as reversible
9.4.9
Original
Transaction
Displayed
Correct
9.4.10 No transaction
Cancel selected ?
Yes
9.4.11
Confirm
Y One receipt retained
9.4.12 with the original
Receipts customer receipt and
Produced the other issued to
the customer
a
COMMERCIAL IN CONFIDENCE Page 41 of 85
F/12/44
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.2.2 Exceptions detected in process 9 - Reversal transaction
Process I Exception type Action by post office outlet
ref
eI System will not e User checks the customer receipt to
reverse the confirm it is the same outlet,
transaction stock unit and that the date is
because it cannot current
find the original e User checks that the number
selected is correct and re-enters if
incorrect
If this does not solve the problem :
e Contact the HSH - could be crash
recovery transaction that has not
been recovered / crash recovery
transaction but the EOD marker
has been set/ system fault /
wrong outlet / outlet opening
hours have changed and the
reference data has not been
updated and the EOD marker has
been set at the wrong time in the
outlet.
© 9.4.8 System will not I e User contacts NBSC who will
reverse the eliminate any problem with POCL
transaction because Reference Data
the product is not .
reversible e If the problem is not POCL
Reference Data the incident is
passed to HSH
«© 9.4.9 User selects the] e User checks the customer receipt to
correct number but confirm it is the same outlet and
the incorrect that the date is current
transaction is
e User checks that the number
selected is correct and re-enters if
incorrect
displayed
If this does not solve the problem :
e Contact the HSH - could be crash
recovery error / system fault /
wrong outlet / multiple use of the
transaction number on the node
° 9.4.9 User selects incorrect I e No impact at the outlet
number but a
transaction of the
same amount ___is
COMMERCIAL IN CONFIDENCE Page 42 of 85
e TP will only act if a customer/client
enquiry is received when they
F/12/42
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
displayed and user
does not notice and
would investigate and ask for
copies of the receipts from the
reverses the outlet and then resolve.
transaction
e 9.4.12 I No receipt orI « User checks the printer to ensure
insufficient receipts that it has sufficient paper.
produced
If it has not :
e Replenish and reprint the receipt
e If the outlet has no supplies the
user will contact the supplier for
emergency supplies and transfer
the session to another node with
paper in the printer (if available)
or issue a manual receipt (no
agreement to this at present)
If it has:
« Contact HSH
e User may have to complete a
manual receipt (no agreement to
this at present)
COMMERCIAL IN CONFIDENCE
Page 43 of 85
F/12/43
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.3 Complete Customer Session Fallback (Automated
Payment) - expansion of process 10 on end-to-end
model
Event A -
Customer requests
service
To Recover Fallback
Transactions (process 11
on end-to-end model)
10.1 - Initiate
Customer
Session
NB: Reference 10.3 was
1 viously used for
Until recovery
carried out
7 “Complete BES Fallback/ 9
10.2 - Establish Contingency Transaction” 10.9 - End
Appropriate Customer
Service Session
Another
Counter news plus ops. man. .
transaction
7 required ?
a eamplete No [103 - Settle
eee callbackl 7X Customer Session
‘ayment Fallbac I Manually
I Transaction I Yes 5
Manual receipt
Pa i Counter news plus
_ I ops. manual
4
COMMERCIAL IN CONFIDENCE Page 44 of 85
F/12/44
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.3.1 Complete automated payment fallback transaction -
expansion of process 10.4
Bar-coded bill
or AP card ?
From process 10.2 -
Establish appropriate >
service
Bar-coded AP
bill card
Y Y
10.4.1 - Complete 10.4.2 - Complete
Manual Checks Manual Checks
\(bar-coded bill) (AP card)
Is the No I 10.4.6 - Complete!
imprinter Manual Receipt
available ?
Yes
10.4.3 - Set
Date and Amount
Y on Imprinter
10.4.5 - Accept Y
Payment and Retain
ICounterfoil (or 10.4.4 - Imprint
Manual Receipt) [Feil Using
Card and Foil
(0 Input During
[Recovery a 9
Another
transaction
required ?
To process 10.8 - Settle
customer session
manually
To process 10.2 - Establish
Appropriate Service
8.3.2 Exceptions detected in process 10.4 - Fallback transactions
Process I Exception type Action by post office outlet
ref.
10.4.4 &]The outlet has noIe Contact the supplier emergency
10.4.6 stationery to supplies
complete the
transaction
COMMERCIAL IN CONFIDENCE Page 45 of 85
F/12/45
ICL
Pathway
Automated Payment End-to-end
Reconciliation Process For Release
NR2 - Incident Management &
Resolution
POL00000776
POL00000776
Ref: CS/PRD/044
Version 1.0
Date. 16/06/99
COMMERCIAL IN CONFIDENCE
Page 46 of 85
F/12/46
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.4 Recover Fallback Transactions (Automated Payment)
- expansion of process 11 on end-to-end model
Event C -
Outlet initiates
recovery
To Maintain EPOSS
Records (process 12
on end-to-end model)
TI.1 - Prepare
for Recivery
and Assemble
Receipts A
i NB: Reference 11.3 was
previously used for
11.2 - Select “Recover BES Fallback/ 11.9 - End
Service to be Contingency Transaction” Recovery
Recovered
Further A
recovery
Manual receipt required ?
11.4 - Recover 11.8 - Settle
No
Automated Pay- Customer
ae yee >
I ment Fallback I Session by
Transaction and
Crash Recovery
Yes [Selecting MOP
Reference data
savings stamps
COMMERCIAL IN CONFIDENCE Page 47 of 85
F/12/47
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.4.1 Recover automated payment fallback transaction -
expansion of process 11
From process 11.2 -
Select service to be }~————3>I AP Reson,
recovered [71148 - Obiain
Receipts
Accepted in
I<¢——}_ Fallback
11.4.2 - Confirm
Acceptance Date
{
11.4.3 - Enter
Type (BC/MC)
Y
11.4.4 - Enter
Ref. Number and
Service Code (if
applicable)
11.4.5 - Enter
Amount
(validation rules
relaxed)
11.4.6 - Enter
MOP
(validation rules
relaxed)
11.4.9 - Receipt
Associated with
the Manual
11.4.7- Produce I Receipt Receipt and
Receipt Retained at the
Outlet
Further No
recovery ———————j> To process
required ? Yes 11.8
To process 11.2 - Select service
to be recovered
COMMERCIAL IN CONFIDENCE Page 48 of 85
F/12/48
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.4.2 Exceptions detected in process 11 - recover transactions
accepted in fallback
Process I Exception type Action by post office outlet
ref.
11.4.2 User enters incorrect I User notices :
gravents anaem e Amends on screen if the transaction
date but allows a has not been committed
past date up toI-e Reverses the transaction and re-
1930) inputs if it has been committed
Unnoticed by the user :
e The transaction will be processed as
normal and have no impact on
the outlet.
e It will be highlighted in TP as it will
cause a contra error if the date
entered is in a different Cash
Account Period; it could be
rejected in the pre APCHI
validation checks if it is more
than 98 days old or there may be
customer/client enquiries. This
creates errors currently and there
are processes in place to address
the errors.
e 11.4.4 I The receipt from the} e Enter transaction via APS EPOSS
fallback transaction product and send the receipts to
cannot be entered in Transaction Processing on a daily
recovery( reference basis using Special Delivery
number recorded
incorrectly or receipt
is unreadable)
e 11.4.4 I The service code is] e Contact NBSC as they may be able
not in the PAN and to establish the service code if
has not been not process as an EPOSS
captured on_ the transaction (see above)
manual receipt
e 11.4.4 I The counterfoil kept I Currently BT bills only
ound the fallback * The user would process as a non-
transaction has no barcded bill using the existing
barcode
COMMERCIAL IN CONFIDENCE
Page 49 of 85
F/12/49
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.5 Crash recovery - expansion of process 11
8.5.1 Process
Ystem not 11.4.8 - Last User 11.4.9 - System 114.10 - Enter
controlled manne] Logged on to the Transaction in Hand for th
and returns System Displayed its Memory Cy au
land Confirm - Node and Confirm]
[1.4.12 - Number 114.11 = Details
f Trans. to be Displayed
Recovered Dis- [“€] and Confirm
layed and Confin
Has the user got
14.15 - the next receipt ? ; N 114.13 - Cancel
Confirm Date or Log <> Yes ? I and Log On Lt)
Enter Date A
No Does user
wish to recover ?
NB: Recovery should
be completed before
114.16 - Enter 114.14 - Select end of day
Token Type “Lost” Lp I
(MC/BC) Receipt
114.17 - Enter No
Reference Yes Any further
Number transactions to
be recovered ?
114.18 - Enter 114.19 - Enter 11.4.20 - Select 11.421 - Retain
Fei oe ws Le Mop LS} Receipt With
(Mag Card Only Original
COMMERCIAL IN CONFIDENCE Page 50 of 85
F/12/50
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.5.2 Exceptions detected in process 11 - Crash recovery of
transactions
Crash recovery transaction must be performed at the original node
Process I Exception type Action by post office outlet
ref.
Transactions entered I The system will not be aware of the AP
lon a_ disconnected I transactions that have been entered
terminal is followed] at the terminal because the
lby a hard disk crash I information was not replicated.
(two hardware
incidents that HSH
ill be aware of)
e The user would need to identify the
transactions that have been lost
from the office receipts
e The user would re-enter the
transaction on a_ connected
terminal. All the system receipts
for the transactions would be
associated. The impact is that the
customer receipt and electronic
information sent to the client
would have different transaction
numbers and will impact on
Transaction Processing if a
customer or client enquiry is
made on that transaction.
e 11.4.1 User identifies crash I EPOSS does not prevent stock unit or
3 tthe transactions to beI outlet balance when there are
recovered but does} outstanding crash recovery
Inot enter them and I transactions.
performs a stock unit The outlet would either :
balance
e Recover the transactions in another
stock unit (see incident below)
e Recover the transactions in the
correct stock unit but in the next
CAP (see incident below)
e« Recover the transactions in a
different CAP but the same SU
° [Transactions are not] The transactions would have to be
recovered and theI recovered in the next CAP and the
loutlet has rolled into I same stock unit if possible.
fhe next CAP This would create contra errors in TP
(ransaction recovery I The incident will only come to light
lis not performed by Iduring the stock unit balance (The
COMMERCIAL IN CONFIDENCE Page 51 of 85
F/12/51
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
tthe same stock unit
original stock unit will show a gain and
the recovering stock unit will show a
loss)
Options:
° Reverse transaction(s) from
incorrect stock unit and re-enter in
the correct stock unit as a fallback
transaction
(impact customer receipt / office
receipt / client information would have
different information/numbers)
e Both stock units accept the
discrepancies and they are
associated.
e The original stock unit gives the
money to recovering stock unit and
therefore both show no discrepancy
DN : Awaiting confirmation from
POCL business assurance on how
it should be handled
[The system crashes
lagain before the first
transaction(s) have
lbeen recovered (the
system only supports
lone gap per terminal)
The user would print the product
report to identify the transactions
which are not held on the system.
The original transactions are entered
as fallback transactions.
(impact customer receipt / office
receipt / client information would have
different information/numbers)
11.4.10 [User enters incorrect I Gap too big:
receie eeumber to User enters the extra receipt numbers
Weentity the gap. as lost transactions.
Gap too small :
User enters the extra transactions in
fallback and associates the two
receipts.
(impact customer receipt / office
receipt / client information would have
different information/numbers and
customers will have duplicate
transaction IDs)
11.4.15 [User selects — the} User notices :
lincorrect_date of the
COMMERCIAL IN CONFIDENCE
Page 52 of 85
F/12/52
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
transaction e Amends on screen if the transaction
has not been committed
e Reverses the transaction and re-
inputs as a recovery transaction if
it has been committed and
associates the two receipts.
Unnoticed by the user :
The transaction will be processed.
Impact :
e on customer /client enquiry
e penalty payment to the client
e transactions over 98days old will be
rejected in the pre APACHI
validation checks
° (Crashed terminal isI Options :
Inot working and stock
lunit balance and cash
laccount is required
Kmulti-terminal outlet
lonly)
e Delay balance and cash account
until terminal operational
e Input the transactions as fallback
before stock unit balance (see
previous impacts) and record the
recovery transaction(s) in the
next CAP as lost transactions.
e Balance stock unit without
recovering the transactions and
accept the discrepancy. Recover
transaction(s) in the next CAP and
show compensating discrepancy
See section 9.1 for NBSC advice
on dealing with this situation.
User enters reversal] e User's stock unit misbalances
transaction as ‘lost’
lbut fails to reverse
the transaction
e Client would receive the information
and settlement
TP would only be aware of this
incident if the outlet identified it
and brought it to their attention
. User enters the I « User’s stock unit misbalances
reversal transaction in
rash recovery e Client would receive the information
and settlement for both
transactions
COMMERCIAL IN CONFIDENCE Page 53 of 85
F/12/53
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
e TP would only be aware of this
incident if the outlet identified it
and brought it to their attention
COMMERCIAL IN CONFIDENCE Page 54 of 85
F/12/54
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.6 Complete Daily and Weekly Reports
8.6.1 Process
See EPOSS End-to-end Reconciliation Process - CS/PRD/045 for
detail.
Reports for AP are not compulsory for the user and would only be
required if the stock unit had a problem.
8.6.2 Exceptions detected in daily/weekly reporting
Process I Exception type Action by post office outlet
ref
19. I Report produced User identifies the differences :
3 does not reflect the .
receipts e recovers any fallback transactions
e reverses any duplicate transactions
( if possible)
If this does not resolve the problem :
Contact the HSH
°19 I The system report See EPOSS reconciliation document
.2 I will not print (CS/PRD/045) section 9.4.3
19. I The user has The user would reverse the incorrect
3 I processed duplicate I transaction.
transactions If the end of day marker has been
set:
Contact the NBSC who record the
information on the database which will
be available to the TP Incident
Manager (replacing the current
capture of information by
Farnborough).
COMMERCIAL IN CONFIDENCE Page 55 of 85
F/12/55
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.7 Manage End of Day - Process 13 on End-to-end Model
Outlet in operation
or
Outlet closed and all users logged off
ublished CTos
[Time is Reached
30 mins.after
[closing or 7pm
End of day The marker is only set
for outlets which have all
marker is
the nodes connected
automatically set
End of business
day - no AP trans.
can be reversed
from previous day
Outlet trading in new business day
8.8 Maintain and Communicate EPOSS and APS Records -
Process 14 on End-to-end Model
This section is included for completeness. Any exceptions that are
detected by ICL Pathway that related to the transfer of information
from outlets to ICL Pathway central systems and from ICL Pathway
central systems to the TIP and HAPS interfaces will be reported to
the HSH and routed to the relevant expert domain.
Further information is provided in ICL Pathway documents:
e« CS/PRD/O51 - NR2 End to End Incident Processes for the
Automated payment Service System;
« CS/PRD/O59 - NR2 End to End Incident processes for the TPS
System.
COMMERCIAL IN CONFIDENCE Page 56 of 85
F/12/56
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.9 Reconcile and Settle (POCL TP Chesterfield)
8.9.1Expansion of process 15 - reconcile and settle (Chesterfield)
To process I and 17
Reconciliation report from Famborough, A
shows volume and value of transactions Settlement
collected and transmitted to AP clients vy
Is source of settlement information Unprocessable and unrecoverable
15.2 - Settle data for settlement
with Clients
Al PocL
Unprocessable and
unrecoverable transactions
input to CBDB
: TS-Reconcile])
Data for Apachi Transaction 15.3 - Manage
Records Errors
A PoC A POCL
Reconciliation
reports
Electronic
cash
account
15.4 - Receive Sub-
and Validate Postmaster
TIP Data queries
Client
queries
ICL Pathway Unprocessable
data transactions from
Data Central and
unrecoverable
From process 14 transactions
Horizon Outlets
Notes:
1. Some of the information is at transaction level and some at summary level.
2. RTI - this report lists any offices where there is a discrepancy between the cash account
and supporting document amount and any differences, i.c. as PIVOT but produced daily.
COMMERCIAL IN CONFIDENCE Page 57 of 85
F/12/57
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.9.1.1 Expansion of process 15.1 reconcile transaction
records
Paper cash accounts
and supporting documents
1S11-Sort I Cash Accounts for
and Scrutinise
automated outlets
removed and filed
Opening
Team
15.1.2 - Collate
and Batch
Batching)
{feam
y
15.1.3 - Key
Information to
CDBD
DP
Unit
From process 16.2 vy
Data for 15.1.4 - File Present plus 2
‘APACHI (from Cash Accounts care stored
Farnborough) and Supporting I on-site. Others
Documents stored off-site
Filing
15.1.6 - Update Team
APACHI with Do the figures
APS information piss 7 Gash match ? Reconciled To
eee Yes transactions rocess
Account and Te P
Apachi Docs. Reconciled 7
7 5 by CBDB No
From jectronic cas!
process account CBDB
15.4 15.1.7 Update Cc
“Exceptions” stream) Error Database
input to CBDB by CLASS 3
AP Error Team
?
From process 15.3
COMMERCIAL IN CONFIDENCE
Page 58 of 85
F/12/58
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.9.1.2 Exceptions detected by POCL Transaction Processing
Apachi Pre-validation Checks
AP transactions are
received for an office
which is closed in
CBDB
Currently occurs from
a. Non Cash Account
offices sending
AP vouchers
direct to Data
Central instead
of via their
parent office.
Systems
Support will
assign txns to
the parent office
code.
b. An office is re-
graded and
allocated a new
FAD code but
transactions are
received for the
superceded
office code.
Systems
Support will
assign _txns_ to
Process I Exception type Action by POCL central business
ref. units
15.1.6 Invalid FAD Code Not expected from Horizon. If it occurs
A FAD code is it will be raised as an Incident via the
received which is not Transaction Processing incident
recognised by CBDB manager
Current! results I ° Contact the NBSC who will clear any
from mis-keying/mis. POCL Reference Data. If this does
reading of FAD code not clear the incident is passed to
at Data Central HSH
e Systems Support — will assign
transactions to the correct FAD
code using current process
e 15.1.6 I Office Closed Problems b & c could still occur under
Horizon
If either occurs it will be raised as an
Incident via the Transaction Processing
incident manager
e Contact the NBSC who will clear any
POCL Reference Data. If this does
not clear the problem the incident
is passed to HSH
e Systems Support will handle as now
COMMERCIAL IN CONFIDENCE
Page 59 of 85
F/12/59
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
the “new” FAD
code.
c.A POCL Region
fails to advise TP
that an office has
re-opened/opened.
Systems Support
will open office in
CBDB.
A NCA office is re-
graded to a cash
account office and
allocated a new
code. Systems
Support will open
office in CBDB.
e 15.1.6 I Invalid Client/Client I Could still occur under Horizon
Scheme e If problem is a disjoint between
AP transactions are HAPS/Apachi reference data
received for a Systems Support will action as
client/client scheme now
se sdnised Snot net e If problem is a disjoint between
up in Apachi) POCL/Pathway _ Transaction
Processing Incident Manager will
Occurs _ infrequently raise an incident with NBSC who
as _a_ result — of will clear POCL Reference Data
HAPS/Apachi error. If this does not clear the
reference data being problem the incident is passed to
out of step. Systems HSH.
Support, vestigate NB: invalid client IDs will have been
Procedures Team. identified by HAPS ‘and appear on
Scheme set up and the “Undeliverables” report
txns assigned to the
first day of scheme
set up - creates
contra errors
between weeks
e 15.1.6 I Invalid Start Date a - should not occur because Horizon
AP transactions are
received with a date
earlier than the
scheme start date.
Occurs now
a_lf_a_client_issues
terminal will prevent acceptance until
correct start date.
NB: Even if an office were to accept
the transactions in fallback they
would be unable to enter them into
the terminal until the due date.
COMMERCIAL IN CONFIDENCE Page 60 of 85
F/12/60
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
cards earlier than] e If problem is a disjoint between
expected. HAPS/Apachi handle as now
b HAPS/Apachi I ¢ If problem is a disjoint between
reference data is out POCL/Pathway Transaction
of step. SystemsI Processing Incident Manager will
Support change the
date to match the
Apachi start date -
creates contra errors
between weeks.
raise an incident with NBSC who will
clear POCL Reference Data error. If
this does not clear the problem the
incident is passed to HSH.
15.1.6 Old Dates Could still occur - Horizon terminal
AP transactions have currently allows entry of dates back to
a date which olderI 1930
than 98 days. Transaction Processing contact the
Occurs now outlet to confirm the correct date and
clear using the current process.
a Error resolution
team have
undertaken AP
recovery and not
advised System
Support of “old”
dates. Systems
Support relaxes the
validation check
15.1.6 Future Dates Not expected as the Horizon terminal
AP transactions are
received with a
future date
prevents entry of future dates.
If it occurs an will be raised with HSH
via the Transaction Processing Incident
Manager.
COMMERCIAL IN CONFIDENCE
Page 61 of 85
F/12/61
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
8.9.1.3 Expansion of process 15.2 - settle with clients
Settlement due ———
15.2.1 - Receive
I and Summarise
Settlement Data
!
15.2.2 -
Calculate
Settlement Data
’
15.2.3 - Prepare
Authority to
Pay
15.2.4 -
Authorise
Payment
u
15.2.5 - Send to
Finance
Cashiers
’
15.2.6 -
Settlement
Made
Settlement data
received
COMMERCIAL IN CONFIDENCE Page 62 of 85
F/12/62
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution ,
8.9.1.4 Expansion of process 15.3 - manage errors
15.3.1 - Produce
Report of Errors
Error Re-
solution
Team(ERT)I
v
15.3.2 - Check
Report for
Obvious Errors
ERT Cleared errors al
Uncleared
errors
A
153.3-
Investigate
Is34- Errors Missing documents sae.
Resolve by ERT (APS and EPOSS Resolve
Error Notice Outlet error transactions) >I
-———>II ERT
No Is the error 153.12 =
notice brought Complete QPA
to account within Form
YesI the time limits ?
ERT
BS Ri 15.3.9 - AccountedI 153.13 = Details 15.3.14-
inform Region ere Pea
to Follow-up [For by Outlet Pork ry L I ‘oduce
lon Cash Account erformance Management
Info, Team Information
[ERT [Outlet OPA OPK
Team Team
15.3.8 - Amount 153.10 Error
Carried in Received in
I Holding Account Transaction IX)
Until Cleared Processing
I ERT [ERT
COMMERCIAL IN CONFIDENCE Page 63 of 85
F/12/63
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.9.1.5 Exceptions detected by POCL Transaction Processing
Process I Exception type Action by POCL central business
ref units
15.3 Customer / client Reasons :
enquiry because the
amount credited to
customer account is
inconsistent with the
receipt
e user mis-keyed reference number
when recovering a fallback
transaction
e user selected incorrect date during
recovery
* user reverses the incorrect
transaction
* user selected the incorrect option
(MC/BC) during manual keying or
recovery of the transaction
¢ user entered a different value to the
amount the customer paid
« lost transaction - TP have no
warning of these transactions as
lost receipts are not produced by
the system - how are they handled
by TP?
e user failed to recover fallback or
crash transactions
e user fails to reverse the original
reversal transaction during crash
recovery or is unable to because
the EOD marker has been set
e duplicate transactions
TP are working on the process to
address these areas and will
identify any incidents during that
work
Transactions passed
to the client are
outside the agreed
perameters (client
enquiry to
Transaction
Processing)
Can happen during fallback when the
rules are relaxed - the clients have
been informed.
Problem with Reference Data
The current process will be followed
COMMERCIAL IN CONFIDENCE
Page 64 of 85
F/12/64
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
Receipts received in I TP will process the receipts and advise
TP as unrecoverable I the outlet and RNM.
are recoverable
COMMERCIAL IN CONFIDENCE Page 65 of 85
F/12/65
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.9.1.6 Cash Account incidents
Process I Exception type Action by POCL central business
ref units
15.3 Incorrect entry Reasons :
e SMART trxns not entered by the
user as APS EPOSS trxns
e Unrecoverable trxns not entered by
the user as APS EPOSS trxns
e Client enquiry e.g. the cash account
and supporting information
stream match but there is an
enquiry outstanding.
e Incorrect use of the APS EPOSS
product by the user
e Duplicate trxns
e Reference Data
e System error
TP are working on the process
to address these areas and will
identify any incidents during
that work
e 15.3 I Contra error Reasons :
(between cash
account weeks)
¢ Outlet fails to roll stock units into
the correct accounting week
(APACHI uses the trxn date to
allocate the trxn to the correct
CAP).
e Outlet rolls into the next CAP early
and processes AP trxns.
e Fallback trxns are recovered in the
wrong cash account week (as
above)
The exception would be resolved by
current TP processes
15.3 2/3 week accounts This will result in contra errors
(outlet has not between the weeks.
received permission I The exception would be resolved by
and the flag has not
been set in CBDB ) current TP processes
COMMERCIAL IN CONFIDENCE Page 66 of 85
F/12/66
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.9.1.7 Supporting Document errors
Process I Exception type Action by POCL central business
ref units
15.3 Supporting The user has entered an amount
documents not against an APS EPOSS transaction but
received or late no supporting documents have been
received.
Resolved using current Transaction
Processing process
15.3 Contra error Transaction Processing will enter
(between Horizon unrecoverable transactions any may
outlets) allocated them to the incorrect office.
This is a Transaction Processing
internal error that will be cleared using
the current process.
15.3 Contra error This will happen if Data Central mis-
(between a Horizon key an office code and the information
outlet and non- is allocated to a Horizon outlet.
Horizon outlet) This is a TP internal error and will be
resolved using the current process
COMMERCIAL IN CONFIDENCE
Page 67 of 85
F/12/67
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution ,
8.9.1.8 Expansion of process 15.4 - receive and validate TIP
data
From process 14
i
Gateway PC
I
Weekly Vv Daily
15.4.1 - Receive 15.4.2 - Receive
[Electronic Cash Transaction Files
Account Files From ICL
[From ICL Pathway Pathway
ITIP ITIP
v BES Reports (settlement) T 9
NB: ITIP will not do anything I 15.4.3 - Volume i © process *
with the transaction files. ITIP and Value Data _IRMMI Extract (to disc) To process ?
translates the cash account Validated by ITIP
. trad”? IFunds and Insurance Extract, 9
files into a format acceptable Land “Stored }_— > To process ?
by CBDB Cash account imp
and BES
supporting doc.
15.4.4 - Reports
Information to
CBDB
ITIP
Validated
transaction
data
Vv
To process 15.1
COMMERCIAL IN CONFIDENCE Page 68 of 85
F/12/68
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
8.10 Consolidate and Reconcile Automated Payment
Records (POCL Farnborough) - Process 16 on End-to-
end model
8.10.1 Process
To process 17
POCL
data
16.1 - Send
Automated
Payment Data
to Client
Al POcL
Consolidated
data
Data from Data for Apachi To
manual 16.2 - Consolidate] and reports
outlets, § —————>I Automated a
APTs and Payment Data ,
non-Horizon
automated POCL
offices .
Validated
transaction
data
16.3 - Receive
and Validate
HAPS Data
AY PocL
ICL Pathway
data
From process 14
COMMERCIAL IN CONFIDENCE
Page 69 of 85
F/12/69
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
8.10.2 Exceptions Detected by POCL Farnborough
Process I Exception Action by POCL central business
ref units
16.3 Transaction(s) See ICL document ‘BSU Incident
rejected by HAPS Reconciliation Procedure for NR2
because the Client ID I (CS/PRO/058)
details are
unrecognisable.
COMMERCIAL IN CONFIDENCE Page 70 of 85
F/12/70
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
8.11 Maintain Payment Records (POCL Clients) - Process
17 on End-to-end Model
This section is included for completeness. The processes used by
POCL clients are not affected by the introduction of Release NR2.
POCL clients compare transaction level information provided by
POCL with settlement information. If there are differences the POCL
client would raise a query with the POCL Error Management Team in
Chesterfield. Valid queries would trigger an adjustment to
settlement. This is shown in section 9.12.1 (expansion of process
15) where client queries are received by process 15.3 (manage
errors) and error notifications are sent to process 15.2 (settle with
clients). Valid POCL client queries would lead to an incident being
raised by POCL TP Incident Management. If the POCL investigation
showed that the incident was caused by an underlying error within
the ICL Pathway domain, then POCL TP Incident Management would
raise an incident with the ICL Pathway HSH.
In addition. a customer could raise a query with a POCL client if a
difference was observed between their personal records and the
bill/statement provided by the POCL client. If an investigation by
the POCL client indicated that the root cause was within the POCL
domain, then the POCL client would raise an incident with the POCL
Error Management Team in Chesterfield. The process would then
progress as described in the paragraph above.
COMMERCIAL IN CONFIDENCE Page 71 of 85
F/12/71
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
9 POCL Incident Management and Resolution
Processes for Automated Payment Related
Incidents
At release NR2 automated payment incidents are handled by four
organisations:
« NBSC (Leeds)
e TP Incident Management Point (Chesterfield) linked to the NBSC
e OSG (Farnborough)
« POITS (Farnborough)
The NBSC provides advice and guidance for business issues, e.g. for
situations where outlet business process are impacted by an
unresolved incident of any type. The NBSC also handles reference
data related incidents raised by outlets or POCL TP.
The TP Incident Management Point records incidents occurring
within TP and raises incidents with the ICL Pathway HSH or the
NBSC.
OSG reports incidents to HSH that have occurred during file transfer
across the HAPS interface - normal POCL hours.
POITS report incidents to HSH that have occureed during file
transfer across the HAPS interface - outside normal POCL hours.
9.1 Advice for outlets on completion of key business
process while awaiting resolution of incident
Situation Example advice given by the NBSC
User unable to input I e Process transactions manually (fallback) and
transactions to the keep on one side and input when the
system. system is available.
e User unable toIe Record details of cash on hand manually
make daily cash and input at the next log on.
declaration If the down time exceeds one day the
system provides no facility to input previous
days figures.
e In this scenario the Outlet will calculate the
value of their ONCH manually and enter
the total on the ONCH declaration, which
will be despatched as per normal
operating instructions.
e User unable to] The only reports which are dependent on the
COMMERCIAL IN CONFIDENCE Page 72 of 85
F/12/72
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
complete daily or] system are:
weekly reports At stock unit level
¢ Girobank in and outpayments
e Pension and allowances payments (OBCS
and manual)
¢ BT bills
e Green giros
At outlet level
e Saving stamp redeemed
¢ Counters revenue schedule
e¢ P 2311MA (x 2 )
Daily Summaries
When the system is down at end of day the
outlet must complete manual versions of the
required daily summaries. On resumption of
the service, the outlet must, if applicable,
recover those transactions necessary and
complete a system summary and cut off. This
system produced summary can then be
discarded.
Weekly Summaries
As part of the fallback process for Cash
Account production, the outlet in the case of
system / power failure will not be required to
complete a Cash Account until the following
week. In this Scenario, no weekly reports will
be required.
In the event of printer failure, the outlet must
preview the reports on screen until the printer
service is restored. On resumption of the
service, the outlet must select the reprint
functionality and forward the reports
immediately to TP.
User unable to} 1. In the event of printer failure, the user
complete stock unit} should preview the stock unit balance. On
balance resumption of the service, the outlet must
select the reprint functionality and retain the
report in the outlet.
2. In the event of system / power failure then
the outlet will be asked by the NBSC whether
COMMERCIAL IN CONFIDENCE Page 73 of 85
F/12/73
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Date. 16/06/99
Resolution
they have balanced sufficient SUs to operate a
service on the following day. If they have then
there is no issue. The outlet simply continues
in fallback mode, and on restoration of the
service completes fallback recovery of any
outstanding transactions. When operationally
feasible, the outlet will then balance any
outstanding SUs from the previous CAP.
If however, no SUs have been balanced then
the outlet will be instructed to suspend
balancing until the following Wednesday.
User unable
complete
account
to
cash
1. In the event of printer failure, the system
will automatically preview the final cash
account. On resumption of the service, the
outlet must select the reprint functionality and
forward the report immediately to TP.
2. In the event of system / power failure then
the outlet will be asked by the NBSC whether
they have balanced sufficient SUs to operate a
service on the following day. If they have then
there is no issue. The outlet simply continues
in fallback mode, and on restoration of the
service completes fallback recovery of any
outstanding transactions. When operationally
feasible, the outlet will then balance any
outstanding SUs and the Cash Account from
the previous week.
If however, no SUs have been balanced then
the outlet will be instructed to suspend
balancing until the following Wednesday.
COMMERCIAL IN CONFIDENCE Page 74 of 85
FI12/74
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
10 ICL Pathway Incident Management and
Resolution Processes for Automated Payment
Related Incidents
10.1Key Interfaces
Post office
outlets
POCL TP.
Incident
Management
(Chesterfield)
< POCL OSG
(Famborough)
POCL
NBSC (Leeds) [7 ~~ 7
1
i
i
or Ig — —!
ee eee ee eee ees yeI ICL Pathway Ig ——_
HSH
by y
ICL Pathway
SMC
T
an 7 UL,
ICL Pathway ICL Pathway
Technical Expert BSU [—_——_>
Domains
‘dware, comm. or software related incidents
> Horizon system advice and guidance, ha
—— Automated payment predefined business incidents
wees BSU raised system incident — — —Je Reference data error
COMMERCIAL IN CONFIDENCE Page 75 of 85
F/12/75
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution
The vast majority of automated payment related incidents handled
by ICL Pathway concern the operation of the APS service, e.g.
Horizon system advice and guidance, hardware incidents,
communications incidents, software incidents. These types of
incidents do not normally have accounting reconciliation
implications.
The main focus of this section is the management of incidents that:
e have accounting reconciliation implications;
e require ICL Pathway BSU involvement in resolution.
The preceding diagram shows four categories of incidents. Each of
these is discussed below.
10.1.1 Automated Payment predefined business incidents
Wherever possible automated payment incidents that involve
reconciliation of accounting information by the BSU are predefined
so that they can be easily separated from other incidents, clearly
labelled and routed to the BSU by the most direct route. Within ICL
Pathway, automated payment incidents that have accounting
reconciliation implications are referred to as “AP Predefined
Business Incidents”. These incidents include a category of “other”
which can be used if new unexpected incidents are encountered.
Following investigation and resolution, the new incident is added to
the list of predefined business incidents so that it can be dealt with
effectively if/when it is encountered again.
Predefined business incidents may be reported to the HSH by post
office outlets, POCL TP incident management or ICL Pathway
organisations. The HSH routes predefined business incidents to the
BSU via the SMC.
All predefined business incidents are added to the RED
(Reconciliation Exception Database) by the BSU. The BSU
investigates the incident and reports findings via a RED report.
10.1.2 General Horizon system advice and guidance,
hardware, communications, software and file transfer
related incidents
These incidents form the majority of incidents handled by the HSH.
Incidents are either resolved by the HSH during the initial call, e.g.
Horizon system advice and guidance, or routed to the appropriate
technical expert domain for resolution. The SMC filters known
errors.
Advice and guidance associated with the operation of the Horizon
system is provided by the HSH at the request to post office outlets.
Hardware, comms. and software incidents associated with the
counter systems are reported by the post office outlet directly to
the HSH.
COMMERCIAL IN CONFIDENCE Page 76 of 85
F/12/76
ICL
POL00000776
POL00000776
Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
During normal POCL hours incidents associated with the operation
of HAPS interface are reported to the HSH by POCL OSG
(Farnborough). Outside normal POCL hours incidents associated
with the HAPS interface are reported to the HSH by POITS.
10.1.3 Reference data errors
Post office outlet queries relating to prices, product information, and
other POCL reference data type information are initially handled by
the POCL NBSC. The NBSC checks reference data and resolves any
errors that have occurred within POCL domain. If POCL perceive
that the reference data error was caused by an underlying error
within the ICL Pathway domain, the NBSC raises a reference data
incident with the HSH. The HSH routes the incident to the SMC
where checks are made to see if the error was cause by a “transient
known error” e.g. late delivery of reference data or a
communications problems. If this does not explain why a reference
data incident has occurred the incident is routed to the ICL Pathway
technical domain (System Support Centre) for further investigation.
The further investigation, where appropriate, involves the ICL
Pathway Reference Data Team. A detailed description is provided in
ICL Pathway process definition document CS/PRD/046.
10.1.4 BSU raised system incidents
The BSU raise a system incident with the HSH if they perceive that
a specific system error has occurred. They raise a problem is a
trend is observed.
10.2Inappropriate calls from outlets
The HSH will consider the following calls to be inappropriate:
¢ calls relating to situations where a key outlet business processes,
e.g. cash account rollover, is impacted by an incident of any
type;
e calls relating to price, product or other POCL reference data type
queries.
The HSH will advise the outlet to contact the NBSC.
NB: If the HSH starts to provide advice and guidance to an outlet or
starts to diagnose an incident raised by an outlet, but then
discovers that it is an incident that is normally dealt with by the
NBSC, the HSH will inform the outlet that it is referring the incident
to the NBSC, terminate the call with the outlet and inform the NBSC.
COMMERCIAL IN CONFIDENCE Page 77 of 85
FI42/77
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
10.3 Automated Payment Predefined Business Incidents
Incident raised I Incident type I Incident detail
by
Post office outlet I None currently I Procedures can
identified accommodate new incident
types if any are identified
in the future.
POCL TP incident I APS Incident raised with the
management reconciliation HSH and routed to the BSU.
point related Investigated by the BSU.
incidents that} Results reported on an APS
are perceived I RED report.
by POCL TP to
have been
caused by a
error within the
ICL Pathway
domain, e.g.
duplicate
transactions,
incorrect
values, invalid
office codes,
invalid
accounting
dates, _ invalid
client services,
Client reportedI Query on a _ automated
error payment bill has been
reported to POCL and
passed on to ICL Pathway
because the error is
perceived to be within the
ICL Pathway domain.
Incident raised.
Investigated by the BSU.
Results reported on an APS
RED report.
POCL OSG HAPS Incident raised within ICL
undeliverable Pathway. Investigated by
Farnborough (client IDI the BSU. Results reported
cannot be I on an APS RED report.
read)
ICL Pathway Difference Incident raised within ICL
between TIP I Pathway. Investigated by
COMMERCIAL IN CONFIDENCE Page 78 of 85
F/12/78
ICL
Pathway
Automated Payment End-to-end
POL00000776
POL00000776
Ref: CS/PRD/044
Reconciliation Process For Release Version 1.0
NR2 - Incident Management &
Resolution
Date. 16/06/99
and HAPS data
the BSU. Results reported
streams on an APS RED report.
Incidents Confirmed exceptions on
reported by}Ithe APS — reconciliation
APS report trigger the raising
reconciliation incident. Investigated by
reports the BSU. Results reported
on an APS RED report.
Unmatched Host APS rejects a reversed
reversals transaction because it
cannot find the original.
Incident raised.
Investigated by the BSU.
Results reported on an APS
RED report.
COMMERCIAL IN CONFIDENCE
Page 79 of 85
F/12/79
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & 16/06/99
. Date:
Resolution
11 Appendix A - Validation and Reconciliation
within the Automated Payment Process Chain
The steps referred to below are detailed later in this Appendix.
Exception handling and incident management/resolution that is
triggered by validation and reconciliation handling is described in
the main part of this document.
Step I Reconciliation and Validation
Post office } 1 Validation: Data entry validated against
counter system rules.
Customer 2 Reconciliation: Comparison of bill, receipt
and cash/cheque passed to clerk.
ICL Pathway 5 Validation: Harvested data validated
against Oracle table format in ICL Pathway
host systems.
Post office I 6 Reconciliation: Stock unit balance.
counter
Post office I 7 Reconciliation: Cash account balance.
counter
ICL Pathway 9 Validation: Validity of APS transaction file
checked.
ICL Pathway 10 Reconciliation: Comparison of HAPS and
TIP data stream.
POCL 12 Validation: Validity of APS transaction file
checked.
POCL 15 Reconciliation: Comparison of AP data
received from all post offices, with AP data
sent to POCL clients, with AP data sent to
POCL TP via Apachi.
POCL 18 Reconciliation: Comparison of cash
account data with Apachi data on CBDB.
POCL client 22 Reconciliation: Comparison of POCL
settlement data with AP transaction data.
Customer 25 Reconciliation: Comparison of bill from
POCL client with customer's personal
records.
COMMERCIAL IN CONFIDENCE Page 80 of 85
F/12/80
ICL Automated Payment End-to-end
Pathway Reconciliation Process For Release
POL00000776
POL00000776
Ref: CS/PRD/044
Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution ,
Customer requests AP service
or reversal/recovery required
I. Complete AP Includes: Validation:
transaction, (a) Normal bar-coded or Validation rules for data entry
reversal or magnetic card transaction are described in POCL document
recovery (b) Reversal (possible until End = APGEN10.doc. Reflected in ICL
Outlet of Day marker set)
(©) Fallback recovery
(d) Crash recovery
2. Check bill/ A customer query may highlight
receipt against an exception at this stage.
cash/cheque paid
ICustomerI
i
3. Pass transaction]
Kdetails from
nutlet to corres
yndence server
Within 15 minutes.
PW syster
4. End of day 30 minutes after outlet normal
marker set closing time (as specified in
Reference Data) or 7 pm.
From step 8 PW systenI
on next page
3 Harvest tans: Harvesting copies information
action data (daily) from the correspondence servers
& cash account to the ICL Pathway host systems.
(weekly) from Harvesting starts after the end of
correspondence day marker is set.
server
To step 9 on page
after next
Pathway design document
BP/DES/002.
Reconciliation:
This action depends on the
customer’s attitude to checking
transactions. If checking takes place
the customer will effectively be
reconciling payment against receipt.
Validation:
An ICL Pathway system event will
occur if individual harvested
information cannot be written to the
Oracle tables within the ICL
Pathway host systems. The event
will trigger a system incident and
this will be investigated to determine
why the exception occurred. If the
investigation concludes that it will
not be possible to process some
individual transaction data, e.g.
because it has been corrupted, then
an “APS Predefined Business
Incident” will be raised and passed
to the ICL Pathway Business Support
Unit. The BSU will investigate and
issue a RED report to POCL.
COMMERCIAL IN CONFIDENCE
Page 81 of 85
F/12/81
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
Counter system]
EPOSS records
Reconciliation:
6. Perform Oceurs before the cash Stock unit balancing compares
stock unit account is balanced.
EPOSS records with cash, stamps
and stock. Any significant APS
Outlet exception within the SU (assuming
no compensating errors) would be
highlighted at this stage. Resolution
procedures within the outlet enable
any “missing transactions” to be
recovered. If any “spurious transactions”
were ever recorded within the counter
system, e.g. unexplained duplicate, then
interaction between the NBSC/
OSG Farnborough/TP Chesterfield
would, ifnecessary, correct
settlement (similar to current POCL
balance
procedures).
Y . . Reconciliation:
7. Balance Occurs prior to the rolling of Any significant APS exception
the cash the CAP. within the outlet (assuming no
account compensating errors) would be
Outlet highlighted at this stage. Resolution
procedures are the same as those
given above for stock unit
balancing.
8. Pass cash
account to
correspondence
server
PW systenI
Go to step 5 on
previous page
COMMERCIAL IN CONFIDENCE Page 82 of 85
F/12/82
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
From step 5
Validation:
Files are produced by ICL
Pathway after harvesting has
been carried out. APS summary
file uses TIP data which enables
9. Produce APS
transaction files
and APS summary}
Alt ae the APS and TIP data streams
APS to be compared (see next step
trans- below).
action
files APS
summary
file
y
10. Reconcile This is achieved by comparing
APS data stream the information contained within
with TIP data the APS transaction files with
stream an APS summary file which is
v i 'W systenI created using TIP data. Any
BSU differences are written to the
AP Reconciliation Database.
report
TI. Send APS A PC in Pathway sends the APS
transaction files transaction files to a PC in POCL.
to POCL This occurs by 3 am - see ICL
(Farnborough) Pathway document “Operational
Level Agreement for Automated
Payments Service (ref. tbe)”.
PW system
12. Receive and
validate APS
transaction files
from ICL Pathway
POCL
system
A PC in POCL (Farnborough)
receives the APS transaction
files sent by ICL Pathway.
To step 13 on
next page
The APS transaction file is tested
for integrity, i.e. file structure
correct, header and footer correct
size. This ensures that the file
is suitable for transfer to POCL.
(similar integrity checks are
carried out within POCL when the
file is received. Any exceptions are
handled via ICL Pathway operational
and incident management procedures.
Reconciliation:
Any differences between the two
data streams are reported to the
ICL Pathway Business Support
Unit the next day. Differences
may not affect the accounting
information, e.g. exceptional
timing differences which are
“self-correcting”. If this is not
the case, then the BSU raises
and progresses an “APS,
Predefined Business Incident”.
The BSU will issue a RED
report to POCL.
Validation:
The integrity of APS transaction
files is pre-validated - see step 9
above.
Validation:
The receiving PC retums OK or
error files. Error files are handled
via ICL Pathway operational and
system incident management
procedures. System incident
management and resolution
processes ensure the APS data is
correctly transferred to POCL.
Any records with incorrect client
IDs are returned in the OK files.
COMMERCIAL IN CONFIDENCE
Page 83 of 85
F/12/83
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
From step 12 on AP data from non-Horizon
previous page post offices
{ POCL (Farnborough) receives AP data (from
13. Merge AP data
rom Horizon
enabled office will
IAP data from other}
post offices
all post office), merges the AP data, communicates
the AP data to POCL TP (Chesterfield) and
POCL clients and produces the AP
Reconciliation Report.
roa 16, Send AP
system data to POCL I» To step 20
ye <licnts
POCL
14. Send AP data 15. Send AP Reconciliation:
to POCL TP reconciliation The AP reconciliation report
(Chesterfield) via report to POCL produced by POCL (Farnborough)
the Apachi system TP (Chesterfield) provides reconciliation between the
POCL POCL total of all AP data received (from all
system, post offices), data transferred to
POCL clients and data communicated
to POCL TP (Chesterfield) via
Apachi. Any differences are
. investigated and corrected.
17. Settle with Lye To step 21
7) POCL clients
Electronic
cash account POCL
via TIP A Leet]
RED reports from 19. Manage
ICL Pathway BSU reconciliation }@— From step 22 and 23
(by exception) errors
18. Reconcile
Apachi data and
cash account data
on CBDB
PC
L
Reconciliation normally
starts 10 days after
the end of the relevant CAP and is therefore
not affected by normal ti
ming differences.
Reconciliation:
POCL TP (Chesterfield) compare
data from the Apachi system (data
passed across the HAPS interface)
with cash account data received via
the TIP interface. POCL TP
have visibility of any RED reports
raised by ICL Pathway, which may
explain a difference. Where necessary
settlement adjustments are made.
COMMERCIAL IN CONFIDENCE
Page 84 of 85
POL00000776
POL00000776
ICL Automated Payment End-to-end Ref: CS/PRD/044
Pathway Reconciliation Process For Release Version 1.0
NR2 - Incident Management & Date. 16/06/99
Resolution :
From step 16 (POCL system) From step 17 (POCL)
20. Receive 21. Geveive
AP transaction settlement
data information
POCL POCL
client client
(a) (b)
22. Reconcile 23. Manage -
transaction data OCL cli customer om
with settlement POCL Client queries step 25
information records (customer)
POCL POCL
client client
To step 19 (POCL) To step 19 (POCL)
The above reflects current practice. Two. Reconciliation:
situations are considered, (a) POCL clients receive POCL clients compare settlement
AP transaction data and settlement information information with transaction data.
from POCL. Detected differences would be Perceived errors are referred to the POCL
expected to trigger a query to POCL TP (Chesterfield). Error Management Team in
(b) Customers may query a payment with a POCL Chesterfield.
client. This may lead to the POCL client querying a
payment with POCL.
Bill from POCL client
24. Receive
Bill from POCL
client
kr omer,
aa Compare f Customer’s Reconciliation:
ut with personal financial records Bill is compared with the customer’s
records
personal records.
‘Customer
To step 23 (POCL client)
The above reflects what a typical customer might be expected to do
when a difference between a bill and personal records is detected.
The customer queries the payment with the POCL client.
COMMERCIAL IN CONFIDENCE Page 85 of 85
F/12/85