POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
Document Title: EPOSS 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
F/13/1
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
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 EPOSS
Reconciliation Panel;
e describes the results of work that was carried out during the
period December 1998 to April 1999;
e focuses on:
e observed EPOSS 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 automated payment reconciliation and
reference data error management are detailed in separate
documents (see associated documents in section 0.3). This
document concentrates on EPOSS products, stock unit balancing
and cash account production at Horizon enabled offices using
release NR2 software. For completeness some information is
provided for OBCS.
In most situations the ability to reverse transactions facilitates
the resolution of accounting exceptions at the outlet.
This document includes all EPOSS 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.
Stock unit and cash account balancing at the outlet provides an
opportunity to reconcile cash, stock and receipts with the Horizon
system (electronic) view of the outlet’s financial accounts.
Wherever possible exceptions relating to differences between the
electronic records held within the Horizon system and the
supporting documentation are resolved locally at the outlet. This
action is expected to eliminate the vast majority of identified
exceptions.
COMMERCIAL IN CONFIDENCE Page 2 of 85
F/13/2
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
Reconciliation also occurs within POCL Transaction Processing
when the electronic cash account information is compared with
supporting documentation.
Other levels of reconciliation exist, e.g.:
e within POCL Client organisations - comparisons between
settlement information provided by POCL and information held
within the client organisation;
e by customers of POCL clients - observed missing payment on bill.
The existence of the POCL client and customer “reconciliation”
processes is recognised within this document, in so far as calls
made by POCL Clients to the Transaction Processing Error Team.
However, no detail is provided on the POCL Client internal
processes.
Exceptions which cannot be resolved locally within outlets are
raised as incidents with the appropriate helpdesk. At release NR2
Horizon enabled outlets will be supported by 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 the reconciliation of accounting information are described
in detail. 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.
COMMERCIAL IN CONFIDENCE Page 3 of 85
F/13/3
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
0 Document control
0.1 Document history
Versio IDate Reason
n
Scoping I 8.12.98 I To support the first EPOSS Reconciliation Panel
doc. meeting scheduled for 17.12.98.
Working I 26.1.99 I To support the second EPOSS Reconciliation Panel
doc. meeting on 27.1.99.
Working I15.2.99 ITo support the third EPOSS Reconciliation Panel
doc meeting on 17.2.99
Working I3.3.99 I To support meeting with POCL Service Management
doc on 4.3.99.
Working I9.3.99 ITo support the forth EPOSS Reconciliation Panel
doc. meeting on 11.3.99.
0.1 1.4.99 I First draft - to support the fifth EPOSS Reconciliation
Panel meeting on 7.4.99 and register in ICL Pathway
and POCL libraries.
0.2 16.4.99 I Second draft for EPOSS Reconciliation Panel sign-off.
1.0 16.6.99 I First definitive issue.
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
COMMERCIAL IN CONFIDENCE Page 4 of 85
F/13/4
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
CS/PRD/044 I1.0 I16.6.99 IAutomated Payment End-to-end IICL
Reconciliation Process For Pathway
Release NR2 - Incident
Management & Resolution
CS/PRD/046 I0.2 I16.4.99 IReference Data Error ICL
Management 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
POCL Business Process POCL
Diagrams
TI/IFS/001 5.3 I11.5.98 I Pathway to TIP Application ICL
Interface Specification Pathway
COMMERCIAL IN CONFIDENCE Page 5 of 85
F/13/5
ICL
Pathway
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
0.4 Abbreviations
APS
BES
BSU
CAP
pss
EPOSS
HSH
ISU
NBSC
OBCS
PCS
POCL
Pw
RED
SsU
TP
Automated payment service
Benefit encashment service
Business Support Unit (ICL Pathway)
Cash account period
Department of Social Security
Electronic point of sale service
Horizon System Helpdesk (ICL Pathway)
Individual stock unit
Network Business Support Centre (POCL)
Order book control system
Pathway Central Systems
Post Office Counters Limited
ICL Pathway Limited
Reconciliation exception database
Shared stock unit
Transaction Processing
Changes in this version
BPS information removed plus cosmetic changes. Scope modified
to make it clear that detailed POCL settlement processes and
detailed POCL client processes are excluded from this document.
Audit trail for changes to principles removed because the principles
are now stable.
COMMERCIAL IN CONFIDENCE Page 6 of 85
F/13/6
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
0.6 Table of content
3 PULPOSC.....eeeecececceeeeeeeeeeeeeeeeeeeeeeeeeeeesteeeneencnneneenecnneaeaeaaaeeeeeeeeeeeseeaa
A APPrOACh ya... eeeesceceseeneeeesseneeeecsenseeeeeeseeeeeeeeseeesessseneeeesseeteesereeeeenneeee
5 Principles for EPOSS Reconciliation Incident Management and
Resolution
5.1 EPOSS Reconciliation Process Design Principle
6 OBCS Incident Management
7 EPOSS Reconciliation Incident Management SummMary............:00ee
7.1 EPOSS Reconciliation Related Exceptions Detected Within
Post Office OUtIets........ccccccccescesecssceeeeeeseeceeseeeseeaeeeseeseeeseeseeeesseeneeens
7.1.1 Impacted Accounting ProC@SS@S........cscccsssssceeeeeeeeeeeeeeeeenee
7.1.2 Horizon Advice & Guidance, Hardware, Communications
and Software ExCeptions.........:sesceesseeseeeeeeeeseeeeseeeeesseeeeeteeseeenaes
7.1.3 Reference Data ExCeptions.......cccccccccscsssssseseceeeeseeseeeseeenens
7.1.4 EPOSS Predefined Business Incidents Requiring ICL
Pathway BSU ACtiON......cceececeeecssneeeeeeesneeeseseneeeesestnaeeeseesaterseeee
7.1.5 Inappropriate Calls to either the POCL NBSC or the ICL
Pathway HSH........c:ccccccssssneeeeeseeeeeecesneeeececeeeeeeeeeeeeeneeeeeeeeeeeeeeenes
7.2 EPOSS Reconciliation Related Exceptions Detected Within
POCL Transaction ProceSSing.......s:cesscessecsesesessecssseesseeseneseesneesseeseees
7.2.1 Specific exceptions/incidents......... eee eeeeeseeeeesseeeereeeeeeereee
7.2.2 EPOSS Predefined Business Incidents Requiring ICL
Pathway BSU ACtiOn.........ccscccesscessssceeesesseesaeensaeeeesesseseransenaeeenes
7.3 Interim TIP File Transfer Exceptions/Incidents Detected Within
7.4 Interim TIP File Transfer Exceptions/Incidents Detected
Within ICL Pathway
8 End-to-end Process..
8.1 Process model..
8.2 Process Descriptions.
9 Lower Level Models and Exception Handling.........c:cccesssesseeseeseeees
9.1 Complete Customer SeSSION..........ccccceseessseeeeeeeeseseeseeseeeesaeeeees
9.1.1 Expansion of process 9 - complete customer session
(NOPMAl) cee eeeeeeeeceeceeseeeseeeeeeeeeeneeeceseeeseessaeeseseeseeeesseneeeeereneee
COMMERCIAL IN CONFIDENCE Page 7 of 85
F13/7
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
9.1.2 Expansion of process 10 - complete customer session
(FAIDACK)........cccceceeseeseessssessssssssesneseseeeesaeseeeseeceeeeeeseeeueaeesseceneeees
9.1.3 Exceptions that may be detected in processes 9 and 10..
9.2 Recover Fallback Transactions. :
9.2.1 Expansion of process 11 - recover fallback transaction....
9.2.2 Exceptions that may be detected in process 11...............
9.3 Complete Daily Cash Declaration..........eeseseeeseeeeeeeeeseeneeeee
9.3.1 Expansion of process 18 - complete daily cash
C0 el 1g a 0) § Bn
9.3.2 Exceptions that may be detected in process 18
9.4 Complete Daily and Weekly Reports
9.4.1 Expansion of process 19 - complete daily reports
9.4.2 Expansion of process 20 - complete weekly reports.........
9.4.3 Exceptions that may be detected in processes 19 or 20..
9.4.4 Complete Reversal Transaction - expansion of process
19.4 (also applies to process 20.4)... eceee eee e tees eee eeeeeeeeee
9.4.5 Exceptions that may be detected in processes 19.4.........
9.5 Balance Stock Unit and Roll-over - INDIVIDUAL STOCK UNIT....
9.5.1 Expansion of process 21 - balance stock unit and roll-
over (individual stock unit) .
9.5.2 Exceptions that may be detected in processes 21 :
9.6 Balance Stock Unit and Roll-over - SHARED STOCK UNIT.........
9.6.1 Expansion of process 22 - balance stock unit and roll-
over (Shared Stock UMit)......... cece ec cece ee ceeeeeeeeeeeeeeeeaeaeeeeeeeeeeeeeee
9.6.2 Exceptions that may be detected in processes 22............
9.7 Balance Cash Account and Roll-over - NORMAL CASH
ACCOUNT PERIOD.......cecsessceesesneeeeeeeeeeeeeeeeesseneeeseeeeeeeeeeeeenneeaes
9.7.1 Expansion Of PrOC@SS 23........:cccccceseeseseseesseeeeeesesseneseesseenes
9.7.2 Exceptions that may be detected in processes 23............
9.8 Balance Cash Account and Roll-over - 2/3 WEEK CASH
ACCOUNT PERIOD
9.8.1 Expansion of process 24..
9.8.2 Exceptions that may be detected in processes 24
9.9 Balance Cash Account and Roll-over - TRANSFER OF
OWNERSHIP OR CLOSURE OF OUTLET - FINAL ACCOUNT...............
9.9.1 Expansion Of ProceSs 25.......:cesccseseesesesesseeeseeseseseeerseeeeeens
9.9.2 Exceptions that may be detected in processes 25.........0..
COMMERCIAL IN CONFIDENCE Page 8 of 85
F/13/8
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.10 Balance Cash Account and Roll-over - INITIAL ACCOUNT
9.10.1 Expansion of process 26 .
9.10.2 Exceptions that may be detected in processes 26..........
9.11 Maintain/Communicate EPOSS and APS Records - Process 14
ON End-to-end MOdEl.........ceecsseeseeseeessecesescseeeeeeeseesaeeneseeesseersnseeeess
9.12 Reconcile and Settle (Chesterfield).............cccccsssessessteeeeeeseeees
9.12.1 Expansion of process 15 - reconcile and settle
(CHEStErFICIA) oo. eeeccccccececeeceeeceeeceececeeeseeesceeseeesseeseestseeseetseeseree
9.12.2 Expansion of process 15.3 - Manage EFTOFS............seeeeeee
9.13 Maintain Payment Records (POCL Client) - Process 17 on
End-to-End MOEl.........cccccesseccssecssseessesessesesseessesenseeseseseesseaseensaesenges
10 POCL Incident Management and Resolution Processes for EPOSS
Related INCIDENtS.........:cscccesseceseseeseeseeeeeeeecesesecsesensaeeeeeeeeseesusereneeseegs
10.1 Advice for outlets on completion of key business process
while awaiting resolution of iNCIdENt........ eee ee eeeeeeeeeeeeeeeeeeeeteenees
11 ICL Pathway Incident Management and Resolution Processes for
EPOSS Related INCIGeNts.............cccescsesceseeeeseseeseceseesseeesesessaseeeteseeeneeenes
11.1 Key INterfaces........ccccccesceeeeesseeeseessseseeeeesecsseseesssseeeneaneesenneaee
11.1.1 EPOSS predefined business incidents..........cccceeeeeeeeeeees
11.1.2. General Horizon system advice and guidance,
hardware, communications, software and file transfer related
INCIDENTS... ceeesceceseeesseseceeeeseseeeesecsesseeseeessesasssesnasessseseeeneeeesnensees
11.1.3 Reference data C©rOrs.......ceccceccesseeesseeerseeesseeeseseeeeeeeenees
11.1.4 BSU raised system incidents..
11.2 Inappropriate calls from outlets
COMMERCIAL IN CONFIDENCE Page 9 of 85
F/13/9
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
1 ‘Introduction
This document:
was jointly produced by ICL Pathway and POCL;
was reviewed, validated and approved by the EPOSS
Reconciliation Panel;
describes the results of work that was carried out during the
period December 1998 to April 1999.
This document contains:
a list of process design principles;
a high-level end-to-end model (post office outlets to ICL Pathway
to POCL to POCL Clients);
lower-level models which show where exceptions may be
detected;
information on the raising and routing of incidents within POCL
and/or ICL Pathway;
information on incident resolution.
Cross-references are made to:
APS end-to-end reconciliation incident management and
resolution processes;
the Reference Data error management processes;
ICL Pathway TIP incident management processes;
POCL Business Process Models
For the purposes of this document:
an EPOSS reconciliation incident is defined as a mismatch within
the end-to-end EPOSS process which results in incorrect
accounting records;
an OBCS business incident is defined as an error in an OBCS
transaction at a post office, which has an impact on OBCS
accounting records.
COMMERCIAL IN CONFIDENCE Page 10 of 85
F/13/10
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
2 Scope
The scope of this document includes:
e all services that are delivered at the post office outlet and
reflected in the cash account;
e the flow of accounting information from post office outlets to the
central POCL accounting functions;
e the detection of EPOSS reconciliation related exceptions and the
raising of EPOSS reconciliation incidents at post offices, within
POCL and within ICL Pathway;
« the resolution of EPOSS reconciliation incidents;
e if applicable, assignment of liability for EPOSS reconciliation
incidents using ICL Pathway/POCL agreed case law;
« the detection and resolution of OBCS business incidents that
affect settlement with clients.
The scope excludes:
e detailed APS reconciliation processes;
e detailed reference data error management processes;
e hardware, software, communications or operational incidents that
have no direct impact on EPOSS accounting records;
« supply of consumables, e.g. printer paper;
e external supplies, e.g. power;
e detailed POCL settlement processes;
« detailed POCL client processes.
3 Purpose
« To define a process framework for the:
e management of EPOSS reconciliation incidents;
« management of OBCS business incidents;
e resolution of EPOSS reconciliation incidents.
e To support the development, enhancement and validation of local
procedures.
COMMERCIAL IN CONFIDENCE Page 11 of 85
F/13/11
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
4
Approach
e ICL Pathway and POCL team approach to reconciliation process
definition, including joint authorship and joint
validation/approval via an EPOSS 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.
e Identification of points within POCL and ICL Pathway where EPOSS
or OBCS reconciliation related exceptions may be detected.
e Capture and validation of processes for raising and routing
accounting reconciliation related incidents within POCL and ICL
Pathway.
e Joint development/validation/maintenance of processes for
resolving EPOSS and OBCS accounting reconciliation related
incidents.
e Process definitions approved and signed-off by the EPOSS
Reconciliation Panel;
e Following EPOSS 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.
COMMERCIAL IN CONFIDENCE Page 12 of 85
FI43/12
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
5 Principles for EPOSS Reconciliation Incident
Management and Resolution
The following principles were used in the development of the
Release NR2 EPOSS 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 EPOSS 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 EPOSS Reconciliation Process Design Principles
P1 Outlets will, wherever possible, eliminate user errors before
raising an incident.
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, EPOSS related incidents that have accounting
reconciliation implications or an impact on the outlet business
processes 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.
COMMERCIAL IN CONFIDENCE Page 13 of 85
F/13/13
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
P5 Incidents reported to the HSH that are defined as “EPOSS
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 EPOSS
reconciliation implications. Following investigation, valid new
incidents will be added to the list of EPOSS Predefined Business
Incidents. NB: There are currently no EPOSS Predefined
Business Incidents identified. However, if any are identified
during live trial they will be investigated and if valid added to
the list of predefined business incidents. This principle and
principles P6, P7 and P8 will then apply.
P6 The BSU will investigate EPOSS predefined business incidents
and report findings on an EPOSS RED (Reconciliation Exception
Database) Report (see NB in P5).
P7 EPOSS RED reports will be distributed to a defined single point
within POCL (see NB in P5).
P8 POCL will define a single point for the receipt of EPOSS RED
reports (see NB in P5).
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) 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
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.
COMMERCIAL IN CONFIDENCE Page 14 of 85
FI13/14
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
P15 Where appropriate, ICL Pathway technical domains will trigger
the raising of an EPOSS predefined business incident, e.g. when
an ICL Pathway technical incident is shown to have caused
EPOSS reconciliation implications.
P16 Where appropriate, the ICL Pathway BSU will trigger the raising
of a technical incident, e.g. when an EPOSS 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.
OBCS Incident Management
Some information on OBCS is included in this document because:
¢ OBCS is accounted for within EPOSS;
e information on OBCS is not included in any other reconciliation
related documentation.
Incidents related to OBCS have been included in this document
where they are detected by the user. OBCS related incidents are
present in section 9.1.3.
COMMERCIAL IN CONFIDENCE Page 15 of 85
FI43/15
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
7 EPOSS Reconciliation Incident Management
Summary
7.1 EPOSS Reconciliation Related Exceptions Detected
Within Post Office 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 EPOSS 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.
7.1.LImpacted 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 orI POCL further
inform-
account rollover, I desk ation
impacted by an provided
unresolved in
incident of any section
type. 10.
COMMERCIAL IN CONFIDENCE Page 16 of 85
FI13/16
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
7.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} HSH No -
system fallback advice
hardware not I procedure I and/or
working Ss 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 s resolution
incorrectly
indicating that
there may be a
software — error,
e.g. error
message,
system not
responding.
7.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} NBSC
information onI any input advice
Horizon system I errors and
incorrect, where
COMMERCIAL IN CONFIDENCE Page 17 of 85
FI43/17
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
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} NBSC
information any input advice
wrong, e.g. I errors and
min/max _ price where
or quantity necessary
incorrect. resolution
Post 7 No - Yes - to}NBSC
office/phone resolve
number
incorrect.
Method of I Eliminate I No - Yes - for I NBSC
payment wrong. I any input advice
errors and
where
necessary
resolution
7.1.4EPOSS Predefined Business Incidents Requiring ICL Pathway
BSU Action
EPOSS reconciliation incidents that require ICL Pathway BSU
involvement in their resolution are known within ICL Pathway as
“EPOSS Predefined Business Incidents”.
When appropriate these incidents are communicated by the outlet
to the ICL Pathway HSH. The handling of EPOSS Predefined
Business Incidents within ICL Pathway is described in the section
entitled ICL Pathway Incident Management at the rear of this
document. No incidents of this type are currently identified.
7.1.5 Inappropriate Calls to either the POCL NBSC or the ICL
Pathway HSH
If outlets make calls to the ICL Pathway HSH that relate to the
general exceptions described in 7.1.1 above or reference data
related exceptions described in 7.1.3 above, the HSH advises the
outlet to contact the NBSC.
COMMERCIAL IN CONFIDENCE Page 18 of 85
F/13/18
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
If outlets make calls to the NBSC that relate to the exceptions
described in 7.1.2 above, the NBSC advises the outlet to contact the
HSH.
7.2 EPOSS Reconciliation Related Exceptions Detected
Within POCL Transaction Processing
7.2.1Specific 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 to the NBSC.
7.2.2 EPOSS Predefined Business Incidents Requiring ICL Pathway
BSU Action
EPOSS reconciliation incidents that require ICL Pathway BSU
involvement in their resolution are known within ICL Pathway as
“EPOSS Predefined Business Incidents”.
When appropriate these incidents are communicated by POCL TP
Incident Management to the ICL Pathway HSH. The handling of
EPOSS Predefined Business Incidents within ICL Pathway is
described in the section entitled ICL Pathway Incident Management
at the rear of this document. No incidents of this type are currently
identified.
7.3 Interim TIP File Transfer Exceptions/Incidents
Detected Within POCL
Exceptions related to file transfer from ICL Pathway are detected by
POCL System Support in Chesterfield. Incidents are raised with TP
Incident Management. If the incident is perceived to be caused by
an error within the ICL Pathway domain, then the TP Incident
Manager raises an incident with the ICL Pathway HSH.
7.4 Interim TIP 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 19 of 85
FI13/19
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
8 End-to-end Process
8.1 Process model
See next page See
NB: References 1, 2. and 3 17 - Maintain next
were previously used for BPS One Payment Records page
processes
FOC ®)
APS AY Po
Client I UCHent
data
4- Maintain’ Data from 16 Consolidate 15 - Reconcile
Communicate manual pe} . Le! and Settle
Reference Data outlets Payment Records (Chesterfield)
and APTs <Farnborough)
POCL Al PoC Al Poct
HAPSI INTER- TIPIINTER-
FACE FACE
5 - Maintain/
Communicate
Reference Data
Event
PW
Automatic End of
Day Marker Set
c-
14 - Maintain/
Communicate
EPOSS and APS
Records
next
6 - Maintain 7 - Control APS 13 - Manage End 12 - Maintain
Reference Data of Day EPOSS Records
Outlet Outlet Outlet [ Outlet
See
8 - Control OBCS, next
i page
Counter
System Outlet
Available ?15—Compleie ee
Event A - .
Customer requests Yes I Customer Session Een B
“ustomer requ (OBCS, APS vent Oe
service and EPOSS) Outlet Initiates
I Outlet Recovery
10 - Complete . 11 - Recover
Customer Session} > Until recovery Fallback
(fallback) carried out Transactions
Outlet Outlet
COMMERCIAL IN CONFIDENCE
Page 20 of 85
F/13/20
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
From process 12. (q
see previous page I
Event D - End 18 - Complete
of trading day Daily Cash LIX)
Declaration
Outlet
Y
Daily
Event E - Daily 19- Complete I Report
despatch of produc Daily Reports
reports requir To
process
12 see previous
previous page
page Event F Week
vent F= 20 - Compl ceklyI
2 plete
IWeekly despatch Report
jof product reports Weekly Reports
required
Outlet
21 - Balance
> SE .
Stock Unit and
Roll-over (ISU)
~ or
Event G - End 22 - Balance
of Balance Period ae
for Stock Unit Stock Unit and
Roll-over (SSU)
Outlet
le.
v
23 - Balance Cash
Account and Roll-overI
Event H - End (Normal CAP)
of Cash Account or
Period 24 - Balance Cash
Account and Roll-over}
(2/3 Week CAP)
jor
To process 15
see previous page
Paper cash account
and supporting
documents
©
25 - Balance Cash
Account and Roll-overI
(Final CAP)
jor
26 - Balance Cash
Account and Roll-overI
(Initial CAP)
Outlet
COMMERCIAL IN CONFIDENCE
Page 21 of 85
F/13/21
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
8.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 22 of 85
F/13/22
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
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 23 of 85
F/13/23
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
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
POCL clients receive automated payment transaction information
from Farnborough. Clients use this information to support
settlement processes.
COMMERCIAL IN CONFIDENCE Page 24 of 85
F/13/24
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
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.
Further details are available in the POCL business process
diagrams :
EPOSS - 35&36/54/56&57
COMMERCIAL IN CONFIDENCE Page 25 of 85
F/13/25
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
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.
Further details are available in the POCL business process
diagrams :
EPOSS - 40/50/51
COMMERCIAL IN CONFIDENCE Page 26 of 85
F/13/26
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9 Lower Level Models and Exception Handling
9.1 Complete Customer Session
9.1.1Expansion of process 9 - complete customer session
(normal)
Event A -
Customer requests
service
To Maintain EPOSS.
9.1 - Initiate Records (process 12
Customer on end-to-end model)
Session
5 Selo NB: Reference 9.3 was 99 -End
previously used for Customer
Appropriate “Complete BPS Session
Service Transaction” oe
Another A
transaction
Reference data required 2
9.4 - Complete No I 28> Settle
I Ars Customer
Tra Session by
Yes I_Selecting MOP
Printed receipt
Electronic stop list Reference data
stops re. MOP
9.5 - Complete
yI BCS I_I
Transaction
Counterfoil
Reference data
9.6 - Complete
EPOSS Trans.
(Receipted/
Payment Items)
-—I
Receipt/payment counterfoi
Reference data and scales
9-7 = Complete
EPOSS Trans.
(Stock Items)
COMMERCIAL IN CONFIDENCE Page 27 of 85
F/13/27
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.1.2 Expansion of process 10 - complete customer session
(fallback)
Event A -
To Recover Fallback
Customer requests
service Transactions (process 11
on end-to-end model)
10.1 - Initiate
Customer
Session
=
Until recovery
carried out
NB: Reference 10.3 was -,
- i . 0.9 -
en Establish — previously used for eon
oppropmiate “Complete BPS Fallback/ Session
ervice Contingency Transaction”
Another
transaction
Counter news plus ops. man. required ?
A
10.4 - Complete No I 10.8 - Settle
I__ypl_ aps Faltback > Customer Session
Transacion Manually
Yes
Manual receipt
Counter news plus
Printed stop list
ops. manual
10.5 - Complete
ye} OBCS Fallback I_I
Transaction
Counterfoil
Counter news plus ops. man.
10.6 - Complete
EPOSS Fallback
[I Trans. Receipted/ I]
Payment Items)
Receipt/payment counterfoil
Counter news plus ops. man,
10.7 - Complete
EPOSS Fallback
Trans. (Stock = [—
Items)
COMMERCIAL IN CONFIDENCE Page 28 of 85
F/13/28
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.1.3 Exceptions that may be detected in processes 9 and 10
Process I Exception Action by post office outlet
ref.
9.4 and I Customer queries I See ICL Pathway document
10.4 APS transaction. CS/PRD/044.
9.5 and I Customer queries I Refer to a DSS or ES office - Existing
10.5 why OBCS payment I working practice.
has been stopped or
queries the amount
given in the book.
10.5 Outlet has not I Users refers to the most recent stoplist
printed a stop list, I that is available in the outlet.
i.e. the user does not
have a stop list to
refer to.
9.6 and I Customer queries I The outlet firstly eliminates
9.7 EPOSS _ transaction I misunderstanding or input error
(receipted/ payment I by using information from the screen,
items or stock} session receipt (if available) or
items), i.e. I transaction log to check:
transaction _ details
do not match what
the customer is
expecting.
Or
Transaction value or
volume does not
correspond to the
user’s expectations.
¢ product selected;
e input details entered.
If the above does not resolve the
incident the outlet eliminates a
reference data error by:
e checking the transaction with
manual documents (i.e. Counter
News).
The outlet then:
e« completes the transaction manually
(fallback) using the correct
monetary values, voiding or
reversing the transaction on the
system if required and_ if
possible);
NB: If a manual receipt is used in
fallback for a_ receipted or
payment item the system records
will be aligned when recovery is
carried out (see process 10). If
the transaction related to a stock
item, the system records will be
aligned when the user adjusts or
COMMERCIAL IN CONFIDENCE
Page 29 of 85
F/13/29
ICL
Pathway
EPOSS End-to-end Reconciliation ;
Process For Release NR2 - Incident Version
Management & Resolution
POL00000758
POL00000758
Ref: CS/PRD/045
1.0
Date. 16/06/99
declares the stock or when the
stock unit is balanced (see
process 21/22).
* contacts the NBSC to report the
incident.
NB: The NBSC eliminates or
progresses correction of reference
data. If POCL reference data OK
the NBSC raises an incident with
the HSH.
User unable to enter
transaction to the
system.
e Contacts NBSC for advice and
guidance.
NB: The NBSC_ eliminates or
progresses correction of reference
data. If POCL reference data OK the
NBSC raises an incident with the
HSH.
ey
No
and
Customer queries
EPOSS __ transaction
that was input in a
previous CAP.
The user establishes all the facts,
investigates the error and eliminates
any customer misunderstanding
Stock item or cash discrepancy :
The user establishes the state of the
stock unit at the close of the relevant
CAP using the system log if it is within
35 days or the stock unit balance if it
is more than 35 days. With the
agreement of the outlet manager the
user issues or refuses the difference to
the customer which will create a
discrepancy in the current CAP.
Other transaction discrepancy :
The user investigates the transaction
on the transaction log to eliminate any
customer error within 35 days.
After 35 days the outlet manages the
query using the historical manual
information available at the outlet.
If an error is discovered the outlet
corrects any monetary difference with
the customer and takes advice from
Transaction Processing via the NBSC
on how to enter it to the system.
At end of session
(normal_ or fallback)
Outlet resolves incident using normal
COMMERCIAL IN CONFIDENCE
Page 30 of 85
F/13/30
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
customer queries I procedures.
amount handed out
by outlet or change
given by outlet.
9.9 The customer I User notices:
change figure I the user confirms the transactions
displayed by _ the I entered on the stack to ensure that all
system Is incorrect. the transactions have been entered
and/or selected correctly. If the entries
are incorrect the user ‘undoes’ the
incorrect transactions and re-enters
correctly. If the entries are correct the
user issues the customer with the
correct change and reports an incident
to the HSH.
NB: The HSH routes the incident to
the relevant technical expert domain.
This type of incident is not classed as
an EPOSS reconciliation incident at
this stage because the exception has
been handled by the post office outlet.
Unnoticed by the user :
The user will pay or take in the
amount displayed on screen but the
stock unit may highlight a discrepancy
when it is balanced.
9.9 The customer receipt I The user checks the transaction
produced does not] entered to the system using the
reflect the I transaction log to eliminate any
transaction entered I misunderstanding.
by the user. If the user had made an error the user
reverses the transaction and re-enters
it correctly issuing the customer with a
new / correct receipt.
If there was no user error the user
issues a manual receipt to the
customer and reports an incident to
the HSH.
NB: The HSH routes the incident to
the relevant technical expert domain.
This type of incident is not classed as
an EPOSS reconciliation incident at this
stage because the exception has been
handled by the post office outlet.
COMMERCIAL IN CONFIDENCE Page 31 of 85
F/13/31
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.2 Recover Fallback Transactions
9.2.1 Expansion of process 11 - recover fallback transaction
Event B -
Outlet initiates
recovery
To Maintain EPOSS
Tic Propare
MT «Prepare Records (process
for Recovery
5 on end-to-end model)
and Assemble
= A
NB: Reference 11.3 was
11.2 - Select previously used for 11.9 - End
Service to be “Recover BES Fallback/ Recovery
Recovered Contingency Transaction”
Further A
. recovery
Manual receipt required ?
11.4- Recover No [11.8 - Settle
I ___ypI_ APS Fallback ~O> Customer
Transacion ‘SS
Counterfoil Reference data
7 re. MOP
Recover
IIback I_I
‘Transaction
Receipt/payment counterfoil
T1.6- Recover
EPOSS Fallback
[I Trans. Receipted/I]
Payment Items)
TI.7- Recover
Stock Items
Optional at this [—
point)
Normally carried out
at stock unit balance
COMMERCIAL IN CONFIDENCE Page 32 of 85
F/13/32
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.2.2 Exceptions that may be detected in process 11
Process I Exception Action by post office outlet
ref.
11.6 System will not allow I The outlet firstly eliminates an input
recovery of an EPOSS I error by checking:
transaction
(receipted/ payment
item) carried out] input details entered.
during fallback. If the above does not resolve the
incident the outlet eliminates a
reference data error by:
¢ product selected;
e checking the transaction with
manual documents (i.e. Counter
News);
« Contacts the NBSC.
NB: POCL eliminates or progresses
correction of reference data. If POCL
reference data OK POCL raises a
system incident with the HSH.
COMMERCIAL IN CONFIDENCE Page 33 of 85
F/13/33
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.3 Complete Daily Cash Declaration
9.3.1Expansion of process 18 - complete daily cash declaration
Event D - En 18.1 - Select
of trading day for Daily Cash
stock unit or Declarations
User
18.2 - Count Cash
at SU Level for
ISU and Till
Level for SSU
y
18.3 - Input
Value by
Denomination
Within
acceptable
limits ?
Within No 18.4 - Attempt to Yes
acceptable resolve within
limits ? post office
Yes
a 18.5 - Accecpt
Discrepancy
COMMERCIAL IN CONFIDENCE Page 34 of 85
F/13/34
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.3.2 Exceptions that may be detected in process 18
Process I Exception Action by post office outlet
ref.
18.4 Declared cash onIThe outlet eliminates a declaration
hand has I error by:
discrepancies which
are not within
acceptable limits toIe re-checking the entry to the system
the user. of the denominational amounts on
the print of the declaration (if it
ee only tee facility res been produced) otherwise
to check declared e user will need to re-declare
against derived the cash to the system.
figures) If the above does not resolve the
incident the outlet eliminates non-
recovery of fallback transactions
by:
recovering outstanding
transactions;
e re-counting cash in stock;
re-declaring cash on hand.
If the above does not resolve the
incident the outlet eliminates input
errors on other transactions by::
e producing product reports and
checking against supporting
dockets;
e physically checking stock against
the system view.
If the above does not resolve the
incident the outlet accepts the
discrepancy.
NB: Although it is not planned for
outlets to raise an incident for a cash
discrepancy, the outlet might contact
either the HSH or NBSC for advice and
guidance.
COMMERCIAL IN CONFIDENCE Page 35 of 85
F/13/35
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.4 Complete Daily and Weekly Reports
9.4.1 Expansion of process 19 - complete daily reports
Event E - 19.1 - Select
Daily despatch Client Reports
of reports (at Stock Unit
Level
y
19.2 - Produce
Client Reports «ag
(PrinvPreview)
y
19.3 - Compare 11 - Recover
Report to Physical Fallback Trans.
Documents (sce end-to-end
model)
Do reports Yes 194 - Correct,
and physical No No (ie. Reverse/
documents PI Input/Reverse
agree ? Yes Are there and Re-input)
transactions to
v be recovered ?
19.5 - Select
“Cut-off”
'
19.6 - Prepare
Documents for
Despatch
Y
19.7 - Despatch
to Clien/TP
COMMERCIAL IN CONFIDENCE
Page 36 of 85
F/13/36
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.4.2 Expansion of process 20 - complete weekly reports
20.1 - Select
Client Reports
(at Stock Unit
Level
Event F -
Weekly despatch
of reports
y
20.2 - Produce
Client Reports
(Prin/Preview)
y
20.3 - Compare 11 - Recover
Report to Physical} Fallback
Documents Transactions
Do reports Yes 20.4 - Correct,
and physical No No p>! &.8: Reverse!
documents Input/Reverse
agree ? Yes Are there and Re-input
transactions to
y be recovered ?
20.5 - “Cut-off”
Selected
Automatically
1
20.6 - Prepare
Documents for
Despatch
Y
20.7 - Despatch
to Clien/TP
COMMERCIAL IN CONFIDENCE Page 37 of 85
F/13/37
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.4.3 Exceptions that may be detected in processes 19 or 20
Process I Exception Action by post office outlet
ref.
19.3 and I Comparison of report I The outlet eliminates non-recovery
20.3 to dockets do not] of fallback transactions by
match. recovering outstanding transactions.
If errors are discovered the offending
transactions are corrected, e.g.
reversed, input or reversed/re-input or
create supporting dockets.
If the above does not resolve the
incident the outlet eliminates input
errors by:
e checking the entries made to the
system via the transaction log.
If it is suspected that the Horizon
system has not been used correctly,
the outlet contacts the HSH for advice
and guidance on how to use the
system functionality.
If it is suspected that a system error
is the cause and the outlet reports an
incident to the HSH.
If a system error is suspected the
outlet completes a manual report and
dispatches the daily/weekly reports.
19.2 andIThe system will not] If necessary the user fills the printer
20.2 print the report. with paper.
If the printer is not empty the user
raises and incident with HSH.
COMMERCIAL IN CONFIDENCE Page 38 of 85
F/13/38
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.4.4 Complete Reversal Transaction - expansion of process 19.4
(also applies to process 20.4)
EPOSS Trans-
action requires
reversing
19.4.1 - Select
Reversal Mode
Is a new or
19.4.7 - Select Existing existing reversal
ad Existing required ?
Reversal
New
19.4.10 - Estab- No Is the transaction
lish the Number reference
From the nember known ?
Transaction Log Yes 19.4.2 - Select
or Product v New Reversal
Report
19.4.8 - Enter }
Transaction
Number
19.4.3 - Enter
Quantity (if
Vv applicable)
19.4.9 - System
Displays Original
Transaction 19.4.4 - Select
Product
19.4.1] - Select No sit the y
Undo transaction ?
Yes 19.4.5 - Enter
Value (if
applicable)
19.4.6 - Select
{toy} Finish and
Settlement (if
applicable)
Transaction reversed
COMMERCIAL IN CONFIDENCE Page 39 of 85
F/13/39
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.4.5 Exceptions that may be detected in processes 19.4
Process I Exception Action by post office outlet
ref.
19.4.1 User is entering I This incident may not be identified
customer sessions inI until the user completes the
reversal mode. transaction summaries.
e User would need to produce a
transaction log to identify all the
transactions entered as a reversal
and reverse them as well as
entering them in the serve
customer mode.
e 19.4.2 IUser attempts to} The outlet will use the existing
reverse a transaction] reversal facility to reverse the
using new reversal I transaction.
but ent” the weer e If the system prevents the user from
aid this this then the outlet will report the
. incident to the NBSC.
NB: POCL eliminates or progresses
correction of reference data. If
POCL reference data OK POCL raises
an incident with the HSH.
e 19.4.9 IUser enters the] The outlet will use the existing
correct transaction} reversal facility to reverse the
reference number I transaction.
ae la the digarcnt « If the system prevents the user from
traneetion this then the outlet will report the
. incident to the HSH.
e 19.4.9 I Using existing I This incident may be identified by the
reversals the user I user:
pelects 2 ransaceen e When the reversal transaction is
same smount but completed and the user would
not the correct reverse the reversal by re-
transaction. inputting the transaction;
e When the product summary is
produced and the user would
reverse the reversal by re-inputting
the transaction and perform the
correct reversal and reproduce the
product summary.
The outlet may not discover the error
and it may come to light within
Transaction Processing or the client.
COMMERCIAL IN CONFIDENCE
Page 40 of 85
F/13/40
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
19.4.10 User cannot establish I Refer to the instructions in the user
the transaction I guide.
number. If this does not solve the users
problem they can phone the HSH for A
& G. If the HSH discover a fault with
the system an incident is raised.
COMMERCIAL IN CONFIDENCE Page 41 of 85
F/13/44
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.5 Balance Stock Unit and Roll-over - INDIVIDUAL STOCK
UNIT
9.5.1Expansion of process 21 - balance stock unit and roll-over
(individual stock unit)
Event G -
End of balancing 21.8 - Physical
period for stock Count of Stock
INDIVIDUAL v
STOCK UNIT
21.1 - Select 21.9 - Compare
Stamps With System
Declaration View
21.2 - Physical Yes
Count of Stamps Correct ?
on Hand No
21.3 - Enter by 21.10 - Recheck
21.6 - Re-declare I joj Volume Stock and
System View
21.4 = Select coprect ? Yes
C Correct ?
‘omplete
No
Are there No
diserepancies ?N“,. '
21.5 - Re-check 21.11 - Adjust
Stamps and System Figure to
Entry to System Match Physical
Yes Errors
Identified ?
No
21.7 - Accept 21.12 - Select
Discrepancies “Enter Cash on Iag——____
Hand”
See next page
COMMERCIAL IN CONFIDENCE Page 42 of 85
F/13/42
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
INDIVIDUAL From previous page
STOCK UNIT @)
21.13 - Physical
Count of Cash
21.14 - Enter
Value by jf 121.17 - Re-declareI
Denomination
21.15 - Select
Complete
- 3L.16- User Yes
G 1? No Re-checks Cash Errors
correct ¢ and Entry to Identified ?
Yes System No
21.18 - Accept
Discrepancy
21.19 - Print
Balance Report
21.20 - Confirm
Entries on
Balance Report
21.21 - Roll
Balance Period
or Cash Account
Period
9.5.2 Exceptions that may be detected in processes 21
[Process I Exception [ Action by post office outlet I
COMMERCIAL IN CONFIDENCE Page 43 of 85
F/13/43
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
ref.
21.6 The user re-declaresI The user resolves user error by
the error but creates I making a new declaration for all
discrepancies on I products which overwrites all previous
every other product. I declarations.
21.11 The user adjusts the I The user resolves user error by re-
stock on hand I adjusting the stock correctly.
incorrectly.
21.17 The user re-declaresI The user resolves user error by
the error but creates I making a new declaration for all
discrepancies on I products which overwrites all previous
every other product. I declarations.
21.19 System will not print I The user first checks consumables and
the stock unit I printer is operational. If this does not
balance. resolve the problem the user transfers
to another node (if available),
otherwise the user works with
information from the screen. The
outlet then raises an incident with the
HSH.
21.19 The revaluation I Revaluation amount entered by the
checks fails = and I user is incorrect
ay Continuing with * User reverses the transactions and
the stock unit re-enters the transaction correctly
balance. The stock holding for the product
was incorrect on the day of
revaluation
e User raises incident with NBSC who
advise the user to reverse the
transaction and re-enter the
amount that corresponds with the
stock holdings on the day of
revaluation. The user will have to
accept the discrepancy that it
creates.
TP have visibility of the error via the
TP incident manager.
e 21.20 Stock unit carry] The user resolves any user error by
forward figure is I confirming ending figures with the last
incorrect. CAP/BP stock unit balance report. If
there is a difference the outlet raises a
system incident with the HSH.
21.20 Cash/stock on hand IThe user resolves any user error by
figures are incorrect. I confirming declaration/adjustment
COMMERCIAL IN CONFIDENCE
Page 44 of 85
F/13/44
ICL
Pathway
EPOSS End-to-end Reconciliation Ref:
Process For Release NR2 - Incident Version 1.0
Management & Resolution
POL00000758
POL00000758
CS/PRD/045
Date. 16/06/99
figures made (from the reports - if
taken and event/transaction log). If
there is a difference the outlet raises a
system incident with the HSH.
21.20 Product figures are IThe user resolves any user error by:
incorrect (receipt and . _ . .
4 confirming figures from all the daily
payment entries) e.g and weekly reports for the
product mapping to roduct:
the incorrect line. p ’
e confirming correct use of the system
from the event/transaction logs.
lf an error is discovered follow
processes 19 and 20.
If no error discovered the outlet raises
an incident with the NBSC.
NB: The NBSC_ eliminates — or
progresses correction of reference
data. If POCL reference data OK the
NBSC raises an incident with HSH.
21.20 Receipts and I The outlet raises an incident with the
payment tables I HSH.
totals are not equal.
21.21 User selects BP I User resolves user error by repeating
instead of CAP. process 21 and CAP selected at the
rollover stage. Where necessary outlet
contacts NBSC for advice.
21.21 User selects the CAP I User resolves user error as follows.
instead of the BP.
Advise not to use stock unit until the
start of the next CAP.
If the stock unit is used before the
start of the next CAP the user will be
warned but not prevented.
If the user ignores the warning then
transactions will be entered in the
wrong CAP and will impact on the
stock unit reports, balancing and the
cash account.
If the operational needs prevent the
stock from remaining dormant then a
new stock unit will need to be created
which would be in the same CAP as the
outlet and used until the next CAP.
Although the use would be limited
because the stock unit would contain
COMMERCIAL IN CONFIDENCE
Page 45 of 85
F/13/45
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
no stock or cash.
If the stock unit is used in the incorrect
CAP the outlet should contact the
NBSC for advice. The NBSC will notify
TP and any errors created will be
resolved via the normal resolution
process (64 action).
COMMERCIAL IN CONFIDENCE Page 46 of 85
F/13/46
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.6 Balance Stock Unit and Roll-over - SHARED STOCK
UNIT
9.6.1Expansion of process 22 - balance stock unit and roll-over
(shared stock unit)
Event G =
End of balancing
period for stock
i
ni
SHARED v
STOCK UNIT
22.1 - Select 22.2 - Physical 22.3 - Enter by
-——} Stamps te! Count of Items /——p>} Volume .
Declaration on Hand
22.6 - Physical 22.5 - Select 22.4-
Count of Items }«——} Stock <— Complete
on Hand Declaration Declaration
G)
Y
22.7 - Enter by Eg. 22.9 - Select
Value or Volume} Complete I_I Cash
Declaration Declaration
@
Y
22.11 - Enter by 22.10 - Physical
§—— Denomination /<'— Count of Cash
22.12 -
Complete
Declaration
All declarations
No made for Shared
Stock Unit ?
Yes
©
See next page
COMMERCIAL IN CONFIDENCE Page 47 of 85
F/13/47
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
SHARED
STOCK UNIT
See previous page From previous page
22.15 - Redeclare 22.13 - Select
Cash/Stamps and/ Discrepancies
or Adjust Stock
Yes
Discrepancies 22.14 - Re-check Yes Discrepancies
identified ? j Items Against identified ?
the Declarations .
No I No
22.16 - Accept 22.17 - Print
Discrepancy [I Balance Report
y
22.18 - Confirm
Entries on
Report
22.19 - Roll
Balance Period
or Cash Account
Period
COMMERCIAL IN CONFIDENCE Page 48 of 85
F/13/48
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.6.2 Exceptions that may be detected in processes 22
Process I Exception Action by post office outlet
ref.
22.1 and I The user re-declares I The user resolves the user error by
22.5 the error but creates} making a new declaration which
discrepancies on I overwrites the previous declaration.
every other product.
22.1 and I The user has I The user resolves any user error by
22.5 declared the same] checking event / transaction log and
value as the system} stock on hand report to confirm
held view but aj] correct figures and correct use of the
discrepancy is I system
highlighted. If correct the outlet raises a system
incident with the HSH.
22.15 The user makes] The user resolves any user error by
compensating checking event / transaction log and
adjustments and the} stock on hand report to confirm
system displays a] correct figures and correct use of the
discrepancy. system
If correct the outlet raises a system
incident with the HSH.
22.15 The user adjusts the I The user resolves the user error by
stock on hand I re-adjusting the stock correctly.
incorrectly.
22.8 and I The users have I The user resolves any user error by
22.12 declared the same] checking event / transaction log and
value as the system I declaration report to confirm the
held view but aj] figures are correct and correct use of
discrepancy is] the system (including checking that
highlighted. declarations have not been
overwritten)
If correct the outlet raises a system
incident with the HSH.
22.12 The user re-declares I The user resolves the user error by
and 22.8 the error but creates I making a new declaration for all
discrepancies on I products which overwrites all previous
every other product. I declarations.
22.17 System will not print I The user first checks consumables and
the stock unit I printer is operational. If this does not
balance. resolve the problem the user transfers
to another node (if available),
otherwise the user works’ with
information from the screen. The
outlet then raises _an_ incident with
COMMERCIAL IN CONFIDENCE
Page 49 of 85
F/13/49
ICL
Pathway
EPOSS End-to-end Reconciliation ;
Process For Release NR2 - Incident Version
Management & Resolution
POL00000758
POL00000758
Ref: CS/PRD/045
1.0
Date. 16/06/99
the HSH.
22.17
The revaluation
checks fails and
prevents the user
from continuing with
the stock unit
balance.
Revaluation amount entered by the
user is incorrect
e User reverses the transactions and
re-enters the transaction correctly
The stock holding for the product
was incorrect on the day of
revaluation
e User raises incident with NBSC who
advise the user to reverse the
transaction and re-enter the
amount that corresponds with the
stock holdings on the day of
revaluation. The user will have to
accept the discrepancy that it
creates.
TP have visibility of the error via the
TP incident manager.
¢ 22.18
Stock
orward
incorrect.
unit carry
figure is
The user resolves any user error by
confirming ending figures with the last
CAP/BP stock unit balance report. If
there is a difference the outlet raises a
system incident with the HSH.
22.18
Cash / stock on hand
figures are incorrect.
The user resolves any user error by
confirming declaration/adjustment
figures made (from the reports - if
taken and event/transaction log).
If there is a difference the outlet raises
a system incident with the HSH.
22.18
Product figures are
incorrect.
The user resolves any user error by:
« confirming figures from all the daily
and weekly reports for the
product;
* confirming correct use of the system
from the event/transaction logs.
lf an error is discovered follow
processes 19 and 20.
If no error discovered the outlet
raises an incident with the NBSC.
NB: POCL eliminates or progresses
correction of reference data. If
POCL reference data OK POCL raises
COMMERCIAL IN CONFIDENCE
Page 50 of 85
F/13/50
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
an incident with HSH.
e¢ 22.18
Receipts and
payment tables
totals are not equal.
The outlet raises a system incident
with the HSH.
22.19
User selects BP
instead of CAP.
User resolves user error by repeating
process 22 and CAP selected at the
rollover stage. Where necessary
outlet contacts NBSC for advice.
22.16
The system
highlights a
discrepancy for the
stock unit.
The user resolves any user errors by:
e checking that the latest
declarations are used and
confirming that they have not
been overwritten;
e checking each declaration against
the physical stock on hand;
e totalling declarations for the product
and comparing to system figure.
If correct the accepts the
discrepancy.
If incorrect the user raises an incident
with the HSH.
user
22.19
User selects the CAP
instead of the BP.
User resolves user error as follows.
Advise not to use stock unit until the
start of the next CAP.
If the stock unit is used before the
start of the next CAP the user will be
warned but not prevented.
If the user ignores the warning then
transactions will be entered in the
wrong CAP and will impact on the
stock unit reports, balancing and the
cash account.
If the operational needs prevent the
stock from remaining dormant then a
new stock unit will need to be created
which would be in the same CAP as
the outlet and used until the next CAP.
If the stock unit is used in the
incorrect CAP the outlet should
contact the NBSC for advice. The
NBSC will notify TP and any errors
created will be resolved via the normal
COMMERCIAL IN CONFIDENCE
Page 51 of 85
F/13/51
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
resolution process (64 action).
COMMERCIAL IN CONFIDENCE Page 52 of 85
F/13/52
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.7 Balance Cash Account and Roll-over - NORMAL CASH
ACCOUNT PERIOD
9.7.1Expansion of process 23
Have all stock units
balanced and rolled into
next cash account period?
Event H - Yes 23,2 - Produce
Cash account PI Office Reports
required No
NORMAL ONE Are there v
WEEK CAP dormant
23.1-Rollas I yes Shek 23.3 - Compare
permant Stock units ? to Physical Stock
mit . *
No Unit Reports
21/22 BalanceI I 23.5 - Amend
Stock Unit and Via a Stock Correct ?
Roll-over Unit
Yes
23.7 - Amend Roe Venily 23.4 Produce
Via a Stock Unit Seoportin (I Office Balance
(if possible) Deekete Report
23.8 - Produce
Cash Account
Snapshot
23.9 Print
Trial Cash
Account
23.10- Print
Final Cash
Account Paper Cash Account
Cash Account oe ' rel an i file 23.13 - Despatch
a er to Next ocal
<«— Documents to
Info. to TIP Cash Account I Documents I TP
Period
9.7.2 Exceptions that may be detected in processes 23
[ Process I Exception [Action by post office outlet ]
COMMERCIAL IN CONFIDENCE Page 53 of 85
F/13/53
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
ref.
23.1 IThe user cannot roll] The user resolves any user errors by
the stock unit as aI checking the event log and
dormant stock. transaction log for the stock unit to
confirm that there has been no
activity (activity includes : transfers
in/out, rems_ in/out, declarations,
adjustments, housekeeping, serve
customer and receipt of product
revaluation).
If no activity is confirmed then the
outlet raises a system incident with
the HSH.
The outlet balances the stock unit
using the full stock unit balance
process (21 & 22) which will prevent
the delay of the production of the cash
account.
23.2 Comparison of report} The outlet eliminates non-recovery
to dockets do not I of fallback transactions by:
match. recovering outstanding transactions.
The user re-checks the dockets and
the report.
If errors are discovered the offending
transactions are corrected, e.g.
reversed, input or reversed/re-input
via a stock unit (a new stock unit is
created if all the other stock units
have rolled into the next CAP). If the
correction requires an existing reversal
the error cannot be corrected at the
outlet and will be forwarded on the
cash account to Transaction Process.
If the outlet contacts the NBSC for
advice, the NBSC will advise the outlet
to accept the error, process the cash
account and await advice from TP. The
NBSC will also record the details which
will be available to the TP Incident
Manager.
Transaction processing do not expect
to be notified directly but expect the
outlet to keep the information
available to clarify the cause when TP
contact _them because of the error
COMMERCIAL IN CONFIDENCE Page 54 of 85
F/13/54
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
detected in the check of the cash
account information against the
supporting documents.
23.3. [The amount on the] The user resolves any user errors by:
price eport does not e checking the figures by stock unit to
Figure on the cash identify the error
laccount or the stock] « checking event / transaction log to
lunit supporting confirm correct use of the system
Hockets/reports. If correct the outlet raises a system
incident with the HSH.
e 23.5 IThe amendment does I The user resolves any user error by
Inot correct the error. checking event/transaction log to
ensure that the amendment was
made correctly.
If correct the outlet raises a system
incident with the HSH.
If incorrect the HSH will provide A & G.
23.5 IThe error requires anI If the correction requires an existing
lexisting reversal to I reversal the error cannot be corrected
correct. at the outlet and will be forwarded on
the cash account to Transaction
Process.
If the outlet contacts the NBSC for
advice, the NBSC will advise the outlet
to accept the error, process the cash
account and await advice from TP. The
NBSC will also record the details which
will be available to the TP Incident
Manager.
Transaction processing do not expect
to be notified directly but expect the
outlet to keep the information
available to clarify the cause when TP
contact them because of the error
detected in the check of the cash
account information against the
supporting documents.
23.4 IThe system will not I The user first checks consumables and
lallow the user to] printer is operational. If this does not
lproduce a office I resolve the problem the outlet raises
balance. an incident with the HSH.
The user would preview the report and
work off the screen.
COMMERCIAL IN CONFIDENCE
Page 55 of 85
F/13/55
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
23.4 (A SU has balancedI The outlet will display revaluation
land rolled CAP before I amounts on the Cash Account for two
the revaluation I weeks. The stock on hand figures for
Imessage has been I the product which appear on the cash
received. account for the first week may not be
correct or divisible by the value of the
product.
e TP will need to keep the revaluation
cash account lines open for 2
weeks
e PIVOT checks may need to be
relaxed
e 23.4 I Outlet Balances Cash I The transactions would not have been
Account leaving I included in the stock unit balance and
transactions on a_I create a discrepancy for the stock unit.
disconnected nodeIWhen the node is re-connected the
which are not I transaction would appear in the stock
reflected on theI unit and be allocated the current CAP
office account (user I the SU is in and will be included in that
ignores the warning) I account and create a compensating
discrepancy.
« TP would have to manage the
contra errors only if the transaction
was a receipt or payment product.
23.9 IThe system will not I The user first checks consumables and
allow the user to] printer is operational. If this does not
lproduce a Trial Cash] resolve the problem the outlet raises
Account. an incident with the HSH.
The user would preview the report and
work off the screen.
23.10 IThe system will not] The user first checks consumables and
lallow the user toI printer is operational. If this does not
lproduce a Final Cash] resolve the problem the outlet raises
Account. an incident with the HSH.
The user would preview the report and
work off the screen.
The user would reprint the Final Cash
Account when the system was
available and forward a copy to
Transaction Processing.
The outlet contacts NBSC who record
the details which will be available to
COMMERCIAL IN CONFIDENCE
Page 56 of 85
F/13/56
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
the TP Incident Manager. TP Incident
Manager informs the Operational
Teams.
COMMERCIAL IN CONFIDENCE Page 57 of 85
F/13/57
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.8 Balance Cash Account and Roll-over - 2/3 WEEK CASH
ACCOUNT PERIOD
9.8.1Expansion of process 24
Are all stock units in
the current CAP ?
Cash account nat the Nex! nits Will Ro
required (Cash Account Will Into Correct CAP
No Be Produced In lat Next Stock Unit
2/3 WEEK [Balance
CAP
24.4 - Balance and] 24.3 - Complete
Roll CAP for the Process 23 at the
Stock Units in the End of the
Current CAP - Extended CAP
Processes 21/22
24.5 - Produce
Cash Account
For Current CAP
- Process 23
No Is outlet in the
required CAP ?
Yes
COMMERCIAL IN CONFIDENCE Page 58 of 85
F/13/58
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.8.2 Exceptions that may be detected in processes 24
Cash Accounts can span a period of more than the Cash Account
Period. This occurs when the sub-postmaster is absent and unable
to complete the account this could be for various reasons (e.g.
holidays) but is planned with permission from the Retail Network
Manager and Transaction Processing. There are occasions however
when this may occur without being planned (e.g. urgent domestic
distress) although permission is still required.
Incidents in addition to those already identified for the cash account
process :
Process I Exception Action by post office outlet
ref
24.1 The user selects the I The system allows the user to return
wrong CAP to the 2/3 week function and select
the other option providing that none
of the stock units in the outlet have
balanced and rolled into to the next
CAP.
If one of the stock units in the outlet
have rolled into the next CAP the
option cannot be amended.
The outlet contacts the NBSC who
notify TP Incident Manager that the
Cash Account would not be produced
when expected. TP contact the outlet
and provide the advice and guidance
required.
SU rolls The stock units do] The user resolves any user errors by
into the not roll into the] checking event log to confirm correct
next CAP I correct CAP use of the system.
If correct the outlet raises a system
incident with the HSH.
COMMERCIAL IN CONFIDENCE Page 59 of 85
F/13/59
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.9 Balance Cash Account and Roll-over - TRANSFER OF
OWNERSHIP OR CLOSURE OF OUTLET - FINAL
ACCOUNT
9.9.1Expansion of process 25
Is it the end of the CAP or
is the office to be closed?
Event H - Yes 25.1 - Complete
Cash account > IProcess 21, 22
required No lor 23
FINAL ACCOUNT 25.2 - Balance and
Roll All Stock
Units Into the
Next BP
25.4 - Amend Via
25.3 - Produc }&—————a Stock Unit,
Snapshot Office Correct? I Balance SU and
Balance and No {Roll Into Next
Confirm Entries Balance Period
Yes
25.5-Produce 25.6 - Amend Via
Weekly Suspense Correct ? I a Stock Unit,
Account Report & Balance SU and
Confirm Enteries Roll Into Next
Balance Period
Are balancing entries
required to complete
final account ?
Yes
125.7 - Enter Products
to Complete Cash
Account Via a Stock
Unit, Balance Stock
Unit Roll Into Next BP}
25.8 - Produce
I__yp ISnapshot Office
Bqalance
25.9 - Produce
Weekly Suspense
Account Report
25.11 - Transfer 25.10 - Manually
%<— to Incoming Post- j———IComplete Final jg —_____]
master or Close ICash Account
Outlet
COMMERCIAL IN CONFIDENCE Page 60 of 85
F/13/60
ICL
Pathway
EPOSS End-to-end Reconciliation ;
Process For Release NR2 - Incident Version 1.0
Management & Resolution
POL00000758
POL00000758
Ref: CS/PRD/045
Date. 16/06/99
9.9.2 Exceptions that may be detected in processes 25
Final Accounts are the last Cash Account that an outgoing sub-
postmaster completes before the business is transferred to the
incoming sub-postmaster. The transfer can happen at the end of
the Cash Account Period (CAP) and will therefore mean only one
Cash Account is produced in the CAP. If the transfer occurs mid-CAP
then 2 Cash Accounts will be produced for one outlet during the
CAP.
Incidents in addition to those already identified for the cash account
process :
Process I Exception Action by post office outlet
ref
25.7 User has not entered I The audit team would complete the
the figures to manual account (pink) correctly, which
complete the will differ from the system produced
account and rolled cash account. The missing product
outlet CAP figures would be entered in the next
CAP and appear on the following
week’s system produced cash
account. The auditors would inform
the NBSC who would record the
incident details, which would them be
available to the TP Incident Manager.
25.7 Outlet uses the final I See section process 15.3.3 error type.
account products
(surplus and
shortage) during
‘normal’ cash
account
25.1 Outlet produces cash I Outlet contacts NBSC to advise of the
account on the situation. Information available to TP
system instead of Incident Manager.
the manual version
25.2 Outgoing subpm Outlet contacts NBSC to advise of the
rolls CAP therefore situation. NBSC arranges for TP
forcing the incoming I Incident Manager to contact the outlet
subpm to work in the I and provide advice and guidance.
wrong CAP
COMMERCIAL IN CONFIDENCE
Page 61 of 85
F/13/61
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.10 Balance Cash Account and Roll-over - INITIAL
ACCOUNT
9.10.1 Expansion of process 26
Outlet to 26.1 - At Close of Business
be Migrated >} Outlet Produces a Cash
Account on the Current System
26.7 - Non- Is it the end of
Horizon Cash Ye the CAP ?
[Account Processed
las Normal No
v
26.8 - Stock Holding and 26.2 - Transaction Details,
Suspense Account Details Stock Holdings and Suspense
Entered by Stock Unit to Account Details Entered by
Horizon Stock Unit to the Horizon System.
26.9 -Stock Unit Balance, 26.3 -Produce Stock Unit
Office Balance and Suspense Balance(s), Office Balance and
Account Report Produced to Suspense Account Report to
Confirm Entries are Correct Confirm Enteries are Correct
26.4 - Outlet Begins Operating
with Horizon
26.5 - Automated Cash Account
Produced at the End of the CAP
Displaying Transactions for the
Complete Week
26.6 - Outlet in
I Normal Horizon
Operation
COMMERCIAL IN CONFIDENCE Page 62 of 85
F/13/62
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.10.2 Exceptions that may be detected in processes 26
Process I Exception Action by post office outlet
ref
26.5 &I The Horizon cash The outlet corrects the error (by input,
26.6 account figures(not reverse or reverse and re-input) via a
stock or b/fwd new stock unit this is (not possible if
figures) do not match I an existing reversal is required to
the supporting correct the error). The error could be
documents on the migrated transaction or the
‘live’ transactions input by the user.
Same as errors on normal cash
account.
26.5 & I The B/fwd figure on Outlet cannot amend this figure and
26.6 the Horizon Cash should have a discrepancy
account is incorrect. I , Await error notice to be issued from
TP
e 26.5& I Stock breakdown The stock would be adjusted by the
26.6 I starting figure stock unit at the next stock balance.
incorrect Impact for TP is incorrect derived sales
figures
26.8 & I System prevents the I The cause could be incorrect reference
26.2 input of transactions I data at the outlet or the outlet holding
or stock
stock or transacting products not
proper to the outlet
e HFSO contacts the POCL Reference
Data team who arrange via
Pathway to have the Reference
Data updated to allow the outlet
to process the transaction.
The outlet posts the item to
suspense until the reference data
is received when the outlet will
transact the product.
The HFSO complete a profoma and
forward to TP to indicate the
products being carried in
suspense by the outlet
The Reference Data team inform the
relevant Account Team to manage
the problem (ie. update the
records or manage the
withdrawal of the product from
the outlet)
COMMERCIAL IN CONFIDENCE
Page 63 of 85
F/13/63
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
COMMERCIAL IN CONFIDENCE Page 64 of 85
F/13/64
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.11 Maintain/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;
e CS/PRD/O59 - NR2 End to End Incident Processes for the TPS
System.
COMMERCIAL IN CONFIDENCE Page 65 of 85
F/13/65
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12 Reconcile and Settle (Chesterfield)
9.12.1 Expansion of process 15 - reconcile and settle
(Chesterfield)
To process I and 17
Settlement
Fi
proce ss Data from clients y
17 15.2 - Settle Error notification
Reports (sce note 1) with Clients
Al Poct
i
162 transactions
Reports (see note 1)
Data for Apachi 15.1 - Reconcile
From joni F Transaction 15.3 - Manage
process Transaction info. from client Records Errors
17 National lottery PIVOT Wa
Paper cash account POCL (non financial) POCL
From and supporting docs. ALPOCK I
process Validated RTIS
33/24/'
23/24/25/26 transaction (oon financial Client
data See note = queries
154-Receive Sub-postmaster
and Validate queries
TIP Data
Al PocL
ICL Pathway
data
Notes:
From process 14
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.e. as PIVOT but produced daily.
COMMERCIAL IN CONFIDENCE Page 66 of 85
F/13/66
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.1.1 Expansion of process 15.1 - reconcile transaction
records
Paper cash accounts
and supporting documents
5 -
ae ceaage I Cash Accounts for
ane Scrulinise I automated outlets
removed and filed
Opening
Team
15.1.2 - Collate
and Batch
[Batching
[Team
y
15.1.3 - Key
Information to
CDBD
DP
Unit
From process 16.2
Data fe 15.1 Present plus 2
een Cash Accounts I CAPS stored
APACHI (from . : -
Farnboroueh: and Supporting I on-site. Others
‘amborough) Documents stored off-site
Filing
15.1.6 - Update Team
APACHI with Do the figures
APS information pelis 32 Cash match ? Reconciled — To
Yes _ transactions rocess
- Account and Supp] P
Apachi PI Docs. Reconciled VW
by CBDB No
Validated transaction CBDB
process data (from TIP)
15.4 15.1.7 - Update
F Transaction information Error Database PIVOT
rom __(from Clients) CLASS 3 (non financial)
process
17 > RTIS
(non financial)
COMMERCIAL IN CONFIDENCE
Page 67 of 85
F/13/67
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.1.2 Exceptions that may be detected in process 15.1 -
reconcile transaction records
Process Exception Action by Transaction Processing
reference
15.1 I RECONCILE No errors identified at this point (as
TRANSACTION process 15.3 ‘Manage Errors’)
RECORDS
These will be raised
in the same context
as process reference
15.3 ‘Manage
Errors.’
COMMERCIAL IN CONFIDENCE Page 68 of 85
F/13/68
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.1.3. Expansion of process 15.2 - settle with clients
Data from
Settlement due _—— clients T
15.2.1 - Receive
Settlement data
received
I and Summarise
Settlement Data
Request for {
settlement
received 15.2.2 -
Calculate
Settlement Data
!
15.2.3 - Prepare
Authority to
Pay
15.2.4 -
Authorise
Payment
’
15.2.5 - Send to
Finance
Cashiers
Y
15.2.6 -
Settlement
Made
Settlement Due - This is a regular payment (daily/ weekly) which is
based on a an agreed forecast
COMMERCIAL IN CONFIDENCE Page 69 of 85
F/13/69
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
Settlement Data Received - Authorised summaries/ invoices from
clients received from teams in TP
Request for settlement received - Invoice from client or other
request ie. by telephone from DNS when funds are required
15.2.1 Receive and summarise settlement data - Check settlement
figures for reasonableness and against records where appropriate.
Request figures from TP teams where necessary
15.2.2 Calculate settlement data - Compile final payment due from
figures received or held on file
15.2.3. Prepare authority to pay - Complete a form CC106 -
‘Authority to pay.’ Details: payable to, method of payment, (BACS,
CHAPS or cheque), bank account number, sort code, date
15.2.4 Authorise) payment - CC106 authorised by CM2,
countersigned by authorised personnel (BPC). The BPC will refer to
forecasts for reasonableness (where appropriate) before
authorisation. Record all payments made
15.2.5 Send to Finance cashiers - CC106 taken to Central cashiers
for settlement (this updates the ‘S’ ledger and is reflected in the
CLASS 181’s
15.2.6 Authority to pay to central cashiers - Settlement made
9.12.1.4 Exceptions that may be detected in process 15.2 -
settle with clients
Process Exception Action by Transaction Processing
reference
15.2 I SETTLE WITH No errors identified at this point (as
CLIENTS process 15.3 ‘Manage Errors’)
These will be raised
in the same context
as process reference
15.3 ‘Manage
Errors.’
COMMERCIAL IN CONFIDENCE Page 70 of 85
F/13/70
POL00000758
POL00000758
Ref: CS/PRD/045
ICL EPOSS End-to-end Reconciliation ;
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.2 Expansion of process 15.3 - manage errors
CLASS 3,
PIVOT, RTIS
15.3.1 - Produce
Report of Errors
Error Re-
solution
Team(ERT)
v
15.3.2 - Check
Report for
Obvious Errors
Uncleared
errors
v
15.3.3 -
Investigat ocgs
15.3.4- (including manual cash 153.6-
Resolve by accounts or keying error Resolve
Error Notice le Outlet error or system error >I
ERT Client
> Verror L__
153.12 -
7 Is the error 15.3.5 - ~
wy notice brought Resolve with Complete QPA
to account within I Client Form
Yes} the time limits ? -
ERT [ERT
153.7 15.3.9 - AccountedI 15.35.13 - Details TS.3.1F=
Inform Region ror by Outlet Keyed by Produce
Business Centre lon Cash Account Performance PI Management
to Follow-up Info, Team Information
[ERT [Outlet OPA OPA
Team Team
15.3.8 - Amount 15.3.10 - Error 15.3.1T - Details’
Carried in Received in Amended in
] Holding Account Transaction I} CLASS 3 and
Until Cleared Processing Error Cleared _[€
I ERT I ERT [ ERT
COMMERCIAL IN CONFIDENCE Page 71 of 85
F/13/71
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.2.1 Exceptions that may be detected in process 15.3 -
manage errors
Action by Transaction Processing
Not expected under EPOSS. If this
occurs an incident will be raised by TP
Incident Manager with the NBSC to
eliminate any POCL reference data
error. If this does not resolve the
incident NBSC raises an incident with
HSH.
This could be reference data or
system error ie. where an entry has
been mapped to the wrong line.
EPOSS should not omit figures where
there is a volume/value check set up.
Not expected under EPOSS. TP would
not expect any value amounts to be
omitted. If this occurs TP Error Team
would clear any user error. If this did
not resolve the error an incident will
be raised via the TP Incident Manager
with the NBSC, who will eliminate any
POCL reference data error. If this
does not resolve the incident NBSC
raises an incident with HSH.
This is expected under EPOSS e.g. a
postmaster could fail to enter a figure
in Table 10g. This will be classed as a
user error, which will be cleared by
the TP Error Team. If this did not
resolve the error an incident will be
raised via the TP Incident Manager
with the NBSC, who will eliminate any
POCL reference data error. If this
does not resolve the incident NBSC
raises an incident with HSH.
NB. No checks are currently made at
TP if there are no entries in table 10g.
Process Exception
reference
CASH ACCOUNT
ERRORS
15.3.3 1. Wrong line entry
on cash = account
(result not the
cause)
15.3.3 2. Omitted figures -
volume/value check
(receipt and
payment products
only )
15.3.3 2.1 Omitted figure
volume only.
15.3.3 2.2 Omitted value
figures on Table 12
If no traffic has been transacted it is
expected that 0.00 should appear on
Table 12. If this is blank then an
incident would be raised with the HSH
COMMERCIAL IN CONFIDENCE
Page 72 of 85
F/13/72
ICL
Pathway
EPOSS End-to-end Reconciliation ;
Process For Release NR2 - Incident Version
Management & Resolution
POL00000758
POL00000758
Ref: CS/PRD/045
1.0
Date. 16/06/99
by the TP Incident Manager. This will
be classed as a system error
15.3.3
3. Misbalanced tables
(eg. addition errors
in table 6).
Not expected under EPOSS. Any
misbalance will be raised as an
incident by TP Incident Manager with
the HSH. This will be classed as a
system error
15.3.3
3.1 Misbalance.
(Receipts / Payments
- results not the
cause).
Not expected under EPOSS. An
incident will be raised by TP Incident
Manager with the HSH if this occurs.
This will be classed as a system error
15.3.3
4. Incorrect entry.
This is expected under EPOSS.
Postmaster selected wrong stock
item/ product. Errors in receipts and
payments as a result of a wrong stock
item / value being entered in Table 6,
6a, 8 or 9. This is classed as a user
error where current processes will
prevail. This also applies to the
dedicated lines 0040 and 1086 on the
production of the Final Cash Account.
All user errors will be cleared by the
TP Error Teams.
ISYSTEM PRODUCED
SUPPORTING
DOCUMENT ERRORS
15.3.3
5. Wrong line entry.
These are the Counters Revenue
Schedule, the Savings Stamp
summary and_ Benefits Agency
supporting documents
This is not expected under EPOSS. An
incident will be raised with HSH by
TP Incident Manager where this
occurs. This will be classed as a
system error
15.3.3
6. Omitted figures
(volume/value).
This is not expected under EPOSS. An
incident will be raised with HSH by TP
Incident Manager if this occurs. This
is in respect of saving stamps, P&A
and Counters Revenue Schedule and
the production of the cash account.
This will be classed as a system error
15.3.3
7. Incorrect entry..
This is not expected under EPOSS. An
incident will be raised with HSH by TP
Incident Manager if this occurs. This
COMMERCIAL IN CONFIDENCE
Page 73 of 85
F/13/73
ICL
Pathway
EPOSS End-to-end Reconciliation ;
Process For Release NR2 - Incident Version
Management & Resolution
POL00000758
POL00000758
Ref: CS/PRD/045
1.0
Date. 16/06/99
will be classed as a system incident.
15.3.3
8. Late /non receipt.
This is expected under EPOSS. Not to
be raised as an incident until such
time that there is proof that the
system is playing a part. This will be
classed as a user error in the first
instance. The TP Error Team will clear
any user error and may access the
NBSC database via the TP Incident
Manager to check any known cause,
e.g. outlet reported problem with
consumables..
15.3.3
8.1 Incorrect entry on
non system
produced supporting
documents
These are manually keyed in DPU.
Errors found here will be internal to
TP, i.e. an incident will not be raised.
Existing processes will remain in
place to address these errors.
INEW ERROR TYPES
15.3.3
9. Missing/ extra cash
account files
Work on exception reports (Live Trial
Team) or CLASS 1 report which
expresses what CBDB did not receive.
Current processes followed. The
revised Interim Tip procedures will be
followed for automated offices with
respect to this incident
The resolution for this exception is
described in process 15.4.
15.3.3
10. Incorrect/
Inconsistent
Reference Data
TP/System Support Team to check
with Reference Data. Any errors
discovered will result in an incident
raised with NBSC by TP Incident
Manager to clear any POCL reference
data errors. If this does resolve the
incident the NBSC will raise an
incident with the HSH.
15.3.3
11. Rejected cash
account file
Where files are rejected by Counters
Business Database. Investigations
where there is more than one cash
account received will be made by the
System Support Team. An_ incident
would be raised via the NBSC if found
to be a recurring problem.
15.3.3
12. Illegible print
(cash account)
As current processes. No incident will
be raised.
15.3.3
13.
Illegible print
As current processes. No incident will
COMMERCIAL IN CONFIDENCE
Page 74 of 85
FI13/74
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
(supporting be raised.
documents)
15.3.3 14. Printer problems I Informal process followed to request
(other) reprint i.e. Incomplete documents etc.
No incident will be raised.
15.3.3 15. Incorrect entry Specifically for the dedicated lines for
the production of the Final Account
(lines 0040 and 1086) which can be
accessed by a system user in error.
The resolution of this exception is
described in process 25.7.
COMMERCIAL IN CONFIDENCE Page 75 of 85
F/13/75,
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.2.2. Expansion of process 15.4 - receive and validate TIP
data
From process 14
I
Gateway PC
v Weekly v Daily
15.4.1 - Receive 15.4.2 - Receive
[Electronic Cash [Transaction Files
count Files [From ICL
From ICL Pathway [Pathway
ITIP ITIP
Vv BES Reports (settlement) r >
NB: ITIP will not do anything I 15.4.3 - Volume . © Process «
with the transaction files. ITIP I and Value Data I RMMI Extract (to disc) tr process ?
translates the cash account Valid ated by Ip Funds and Insurance Extract 9
files into a format acceptable Land “Stored’ To process ?
by CBDB ITIP
15.4.4 - Reports.
Information to
CBDB
ITIP
Validated
transaction
data
To process 15.1
COMMERCIAL IN CONFIDENCE Page 76 of 85
F/13/76
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
9.12.2.3 Exceptions that may be detected in process 15.4 -
receive and validate TIP data
Process Exception Action by Transaction Processing
reference
RECEIVE AND
VALIDATE TIP DATA
15.4 I Missing Transaction} The Systems Support Team will
Files monitor missing transaction files
reported by Interim TIP. These will be
raised as an_ incident if the
transaction files are still missing after
a period of 5 days. The incident will
be raised by the Systems Support
team with the Incident and Problem
Manager to the HSH
15.4 I Unexpected The Systems Support Team will
Transaction Files monitor unexpected transaction files
reported by Interim TIP. These files
are monitored daily. TP will
investigate the reason for receipt of
the unexpected file. This could be
where:-
e Pathway could send a duplicate
transaction file in error
(although never expected to
happen)
e Reference Data may be incorrect
e An outlet may perform
transaction on a non trading
day
e The outlet could be one of the
nominated 1500 non
automated offices which has
performed an automated
‘Benefit Encashment’ via the
Payment Card Helpline. If this is
the cause the report is ticked
and filed in date order. If the
incident relates to Reference
Data the incident is logged and
incident procedures
(documented based on the
BSM generic procedures) are
followed
COMMERCIAL IN CONFIDENCE Page 77 of 85
FI13/77
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
e« 1 I Missing CashI The Systems Support Team will
5. I Account Files monitor missing cash account files
4 reported by Interim TIP on a daily/
weekly basis These will be checked
on a daily basis and raised as an
incident if missing The incident will
be raised by the Systems Support
team with the Incident and Problem
Manager to the HSH. A cash account
is considered missing after 5 days
when an incident is raised if this
occurs
15.4 I Missing Client} The Systems Support Team will
Transmission monitor missing client transmission
Summary summary files reported by Interim
TIP These will be checked on a daily
basis and raised as an incident if
missing The incident will be raised by
the Systems Support team with the
Incident and Problem Manager to the
HSH
15.4 I Unexpected Client] The Systems Support Team will
Transmission monitor unexpected client
Summary Files transmission summary files reported
by Interim TIP These will be checked
on a daily basis and raised as an
incident if unexpected files are
received The incident will be raised
by the Systems Support team with
the Incident and Problem Manager to
the HSH
15.4 I Exception Reporting I Discrepancies between the reference
data held by Interim TIP (as supplied
by POCL Reference Data), and the
reference data used by the HORIZON
system (ie. Pathway - also supplied by
POCL Reference data) when
transaction or cash account files are
created, are highlighted as errors by
Interim TIP.
Interim TIP will produce a _ daily
‘Exception Log’ report listing any such
errors. (This report can be obtained
from SAR (a mainframe printing
package) or sent to a nominated
printer for collection). This is classed
as_an_incident_and_was_ monitored
COMMERCIAL IN CONFIDENCE Page 78 of 85
F/13/78
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
through Model Office Testing.
Investigations will determine the
cause and raised as an incident with
the NBSC and HSH (where the
problem is identified with Horizon
Reference Data)
The Client Transmission Summary
Exists only for Client Product Transaction information that has been
sent from Pathway Outlets via the PCS to the Client for each
individual Client’s trading date (initially sent from PCS via AP Host
Farnborough). This is currently only the AP products. Client
Transaction Summary details will be a national repeating group per
Client Product depending on how many AP Client Products are
involved. There will only be one Client Transmission Summary
Header and one Client Transmission Summary Trailer for any one
day. If AP transactions do not take place on a calendar day, TIP only
expects to receive the Sub File Header and Sub File Trailer
9.13 Maintain Payment Records (POCL Client) - 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 79 of 85
F/13/79
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
10 POCL Incident Management and Resolution
Processes for EPOSS Related Incidents
EPOSS incidents are handled by two organisations:
e NBSC (Leeds);
e TP Incident Management Point (Chesterfield) linked to the NBSC.
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 POCL
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.
10.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 to] e 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
complete daily orI system are:
weekly reports At stock unit level
¢ Girobank in and outpayments
e« Pension and allowances payments (OBCS
and manual)
e BT bills
e Green giros
COMMERCIAL IN CONFIDENCE Page 80 of 85
F/13/80
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
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
complete stock unit
balance
1. In the event of printer failure, the user
should preview the stock unit balance. On
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
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
COMMERCIAL IN CONFIDENCE Page 81 of 85
F/13/81
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
balancing until the following Wednesday.
User unable to} 1. In the event of printer failure, the system
complete cash I will automatically preview the final cash
account 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 82 of 85
F/13/82
POL00000758
POL00000758
ICL EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution Date. 16/06/99
11 ICL Pathway Incident Management and
Resolution Processes for EPOSS Related
Incidents
11.1 Key Interfaces
Post office
outlets
POCI TP
Incident >
System Support
(Chesterfield)
POCL
NBSC (Leeds) [7 7 ~ 7
i
f
1
<e- — —!
pee cee eee eee eee eee ye} ICL Pathway Leg
; HSH
: ————————
: T
I bvy
i v
F ICL Pathway
: SMC
F ICL Pathway ICL Pathwa
i Technical Expert Bs I
: Domains
==> Horizon system advice and guidance, hardware, comm. or software related incidents
———— POSS predefined business incidents = — =» Reference data error
-+-+=+=3R= = BSU raised system incident
COMMERCIAL IN CONFIDENCE Page 83 of 85
F/13/83
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
The vast majority of EPOSS related incidents handled by ICL
Pathway concern the operation of the EPOSS 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:
¢ 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.
11.1.1 EPOSS predefined business incidents
NB: No incidents of this type are currently identified. However, the
capability of handling EPOSS predefined business incidents is
included in the Pathway NR2 incident management processes.
Wherever possible EPOSS 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
EPOSS incidents that have accounting reconciliation implications
are known as “EPOSS 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.
11.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
COMMERCIAL IN CONFIDENCE Page 84 of 85
F/13/84
ICL
POL00000758
POL00000758
EPOSS End-to-end Reconciliation Ref: CS/PRD/045
Pathway _— Process For Release NR2 - Incident Version 1.0
Management & Resolution 16/06/99
Date:
counter systems are reported by the post office outlet directly to
the HSH. Incidents associated with the operation of Interim TIP
interface are reported to the HSH by TP Incident Management
(Chesterfield).
11.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
expert 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.
11.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.
11.2Inappropriate calls from outlets
The HSH will consider the following calls to be inappropriate:
e 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 85 of 85
F/13/85