FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O0S
if; i ersion: .
Acceptance Specification Date. 18/12/98
Document Title EPOSS Acceptance Test.
Document Type Acceptance Specification
Abstract This document describes the Acceptance Test for EPOSS
Status Approved
Author P. John Pope
Approval By 18/12/98
Distribution Pathway Management Team
Test & Integration Manager
Pathway Library
POCL/DSS Acceptance Manager
PDA
Recommended ICL Pathway Test Authority(ies) Test Manager
for Approval Manager
Signature
Name P. John Pope Graeme Seedall
Date 18/12/98 18/12/98
Approved For and behalf of ICL For and behalf of Authority(ies)
Pathway
Signature
Name J.C. C. Dicks R. Holleran
Date 18/12/98
0. DOCUMENT CONTROL
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 1 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O0S
iF ii i ersion: .
Acceptance Specification Date: 18/12/98
0.1 DOCUMENT HISTORY
Version Date
0.1 1/5/97
1.0 12/5/97
1.1 12/5/98
1.2 26/10/98
Reason
First draft for internal Pathway review
Issued for joint review
Re-issued to reflect introduction of New Release 2 and
changes to test condition naming and content.
Re-issued to reflect introduction new versions of the
EPOSS Business Thread and HLTPs, and revisions in
the standard for Acceptance Test Scripts.
1.3 6/11/98
Re-issued after changes agreed during the EPOSS
acceptance workshop and subsequent discussions
2.0 27/11/98
comments
3.0
4.0
17/12/98
18/12/98
0.2
Reference
()
(2) Acceptance 0.1
Standard
Acceptance 1.2
Standard
Authorities’
Agreement
POCL
Agreement
DSS
Agreement
7.2
7.2
7.2
Authorities’ 8.1
Agreement
Authorities’ 8.1
Agreement
DSS 8.1
ASSOCIATED DOCUMENTS
Version Date
13/09/96
13/7/98
22/5/97
22/5/97
22/5/97
8/3/98
8/3/98
8/3/98
Title
Standard for Raising and
Progressing Acceptance
Incidents.
Standard for documenting
Acceptance Specifications
Acceptance Procedures
Schedule (A)A07
Acceptance Procedures
Schedule (P)A11
Acceptance Procedures
Schedule (D)A11
Requirements Schedule
(A)BO4
Solutions Schedule
(A)BOS
Requirements Schedule
Re-issued for approval after incorporating further
Re-issued after review with POCL on 15/12/98 of V2.0
Re-issued with 836/3(f) moved to 5.2
Source
Pathway
Pathway
DSS/POCL
POCL
DSS
DSS/POCL
Pathway
DSS
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 2 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
Agreement (D)A15
(10) DSS 8.1 8/3/98 Solutions Schedule Pathway
Agreement (D)A16
(11) POCL 8.0 13/11/97 Requirements Schedule POCL
Agreement (P)A15
(12) POCL 8.1 8/3/98 Solutions Schedule Pathway
Agreement (P)A16
(13) CR/FSP/004 4.0 30/9/97 Service Architecture Design Pathway
Document
(14) PA/STR/O09 2.0 24/2/98 Release Contents Definition Pathway
for Pathway New Release 2
(15) CR/FSP/010 0.1 6/6/97 EFTPOS Statement of Pathway
Requirement
(16) SD/DES/005 2.5 17/8/98 BA/POCL Reports and Pathway
Receipts
(17) CS/PRO/021 4.2 16/10/98 NR2EPOSS PPD Pathway
(18) BP/FSP/004 3.6 30/8/98 EPOSS Functional Pathway
Description
(19) IM/STR/005 1.0 15/11/96 Automated Payments Client Pathway
Migration Strategy
(20) CR/FSP/006 2.2 8/9/97 Audit Trail FS Pathway
(21) VUTSC/105 2.2 5.6.98 Pathway Release 2 Pathway
Technical Integrity and
Networking HLTP.
(22) RDP/AIS/001 3.3c 2.2.98 Application Interface POCL
Specification Reference
Data to Pathway
(23) TVIFS/001 (1)5. (3)21/3/9 Pathway to TIP Application POCL
0 7 Interface Specification
(2)5. (4)tb.a
4
(24) SD/DOC/004 0.1 8/6/98 Benefit Payment Service Pathway
Reconciliation
(25) SD/STD/001 1.2 18/3/98 Pathway Horizon Office Pathway
platform Style Guide
(26) ES/IFS/002 2.0 15/1/97 Peripheral Server Version Escher
2.0
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 3 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O0S
iF i, i ersion: .
Acceptance Specification Date. 18/12/98
(27) POCL 0G 23/10/96 POCL Infrastructure Service POCL
Agreement Levels and Remedies
Schedule
G10
(28) PA/STD/003 1.2 27/1/98 Business Requirements Pathway
Definition
(29) SD/SPE/016 4.2 5/11/98 Horizon OPS Menu Pathway
Hierarchy for Release 2
(30) TD/DES/030 1.1 14/4/98 Time Services Specification Pathway
(31) VI/TSC/034 1.0 27/3/98 Business Thread RDSO1 Pathway
(32) PA/PRO/OO7 1.3 14/1/98 New Service Introduction Pathway
Process
(33) VI/TSC/082 3.0 27/11/98 Business Thread EPOO1 Pathway
31/10/98
(34) VI/TSC/041 2.0 27/11/98 HLTP EPO0101 Pathway
(35) VI/TSC/042 2.0 27/11/98 HLTP EPO0102 Pathway
(36) VI/TSC/085 2.0 27/11/98 HLTP EPO0103 Pathway
(37) IA/MAN/004 0.1 30/6/98 Horizon System Audit Pathway
Manual [NR2]
(38) CS/PRO/025 0.4 5/5/98 NR 2 Access Control and Pathway
User Administration PPD
(39) CS/PRO/024 0.4 28/4/98t. NR2 Operating Environment Pathway
b.a PPD
(40) PA/STR/003. 1.0 26/11/96 Pathway Release Policy Pathway
(41) CS/IFS/001 1.0 12/11/98 Reference Data Change Pathway
Catalogue
(42) CR/IFSP/017 1.2. 23/10/98 BPS Recovery of Fallback & Pathway
Recovery Transactions FS
(43) CS/PRD/O30 1.0 30/1/98 Process for Operational Pathway
Business Change - Product
(44) VI/TSC/110 1.0 30/1/98 Systems Management High Pathway
Level test Definition
(45) CS/PRD/033 1.0 1/10/98 POCL Verification of Pathway
Reference Data Changes for
NR2
(46) CCN 271 10/6/98 POCL Applications - Pathway
EPOSS: Transaction Times
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 4 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
(47) VI/TSC/083 HLTP RDSO101 Pathway
(48) VI/TSC/040 HLTP TPS0O101 Pathway
(49) VI/TSC 097 2.0 23/9/98 HLTP APSO101 Pathway
(50) VI/TSC/084 1.1 2/11/98 BT BPS10 Pathway
(51) VI/TSC/048 1.0 13/3/98 BT BITO3 Pathway
(52) VI/TSC/145 1.0 28/10/98 HLTP BPRO101 Pathway
(53) CS/PRO/048 0.3 7/5/98 NR2 Horizon System Pathway
Helpdesk PPD
(54) CS/PRO/024 0.4 28/4/98 NR2 Operating Environment Pathway
PPD
(55) tb.a E2E Closure Report
0.3. ABBREVIATIONS
AS Acceptance Specification
BT Business Thread
DSS Department of Social Security
HLTP High Level Test Plan
LLTP Low Level test Plan
PDA Programme Delivery Authority
POCL Post Office Counters Ltd
0.4 CHANGES IN THIS VERSION
Updates to section 5 to reflect agreements reached in discussions on 15/12/98
are highlighted.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 5 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
0.6 TABLE OF CONTENT
0. DOCUMENT CONTROL..........ccscsssesesssssssssessssssseseseseeeseseaseeseseeseneaeseeneenseaees 2
0.1 DOCUMENT HISTORY.....
0.2 ASSOCIATED DOCUMENTS.
0.3. ABBREVIATIONS.....cccrce
0.4 CHANGES IN THIS VERSION.
0.5 TABLE OF CONTENT...
1. PURPOSE & SCOPE.
2. ACCEPTANCE INCIDENT: -
3. ACCEPTANCE PERIOD..........cccccsssssssssssesesssssesesesessenssssssesesasaesesesnensaeseneaseneee 8
4. DELIVERABLES & SERVICEG...........:cccssssssesssssessssssssesesesseseesssesnsaseseceeeeeseess 8
5.
5.
. ACCEPTANCE CRITERIA.
ACCEPTANCE CRITERIA AND TEST CONDITIONS.
.1 Description Of Tests Conducted By Acceptance Trial.
.2 Description of tests conducted by Acceptance Revie’
5. CRITERIA FOR LATER ACCEPTANC!
5.3 CRITERIA SUMMARY
6. ACCEPTANCE INCIDENT SEVERITY.
6.1 HIGH SEVERITY INCIDENTS.
6.2 I MEDIUM SEVERITY INCIDENTS.
6.3 LOW SEVERITY INCIDENT:
eae
1
5.
5.
2
8.1. APPOINT TEST MANAGER
8.2. ACCEPTANCE INCIDENT REPORTS.
8.3. ACCEPTANCE INCIDENT ANALYSIS REPORTS.
8.4 ATTENDANCE AT TRIALS AND REVIEWS.
8.5 I MANAGEMENT AND Co-ORDINATION
8.6 PROGRESS REVIEWG.......
9. CONTRACTOR RESPONSIBILITIEG............:::ssssssssesesseesesessessseseeseneseeee
10. ACCEPTANCE TRIAL TEST CONDITIONG..........c:csesssssssseesesessseneneees
1. PURPOSE & SCOPE
This document describes the Acceptance Test for EPOSS in accordance with the
Acceptance Procedures that are set out in the Schedules referred to in section
0.2 and also in the Pathway document “Standard for Documenting Acceptance
Specifications”. This Test will determine that EPOSS meets all the Acceptance
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 6 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
i " Version: 4.0
Acceptance Specification Date. 18/12/98
Criteria that are agreed in the Acceptance Specification and that are within the
scope of the “Pathway Release Contents Specification” document for New
Release 2, if applicable.
Schedule C3
Policies & Standards
Customer Service
Education Levels
POCLIDSS POCLIDSS POCLIDSS
Implementation Implementation Implementation
Training Service Rollout
S DSS Interface TIP Interface MIS Interface
Sad PAS CMS
3II z
2 3
Help Desks < 8
Reference
Data
POCL
Infrastructure
APS:
BES OBCS: HAPS. EPOSS
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 7 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
Schedule C3
Policies & Standards
Customer Service
Education Levels
POCLIDSS POCLDSS POCLDSS
Implementation Implementation Implementation
Training Service Rollout
z DSS Interface TIP Interface MIS Interface
a PAS cus
Help Desks 2 é g
Reference 3
Data 8
2
PoC
Infrastructure
APS
BES BCS ee POSS
Figure1-1: This Acceptance Test in relation to others
2. ACCEPTANCE INCIDENTS
The standard and method for originating, progressing and resolving Acceptance
Incidents shall be as described in the associated Document “Standard for
Raising and Progressing Acceptance Incidents”.
3. ACCEPTANCE PERIOD
The Acceptance Period for the Acceptance Tests, which comprise the
Operational Trial, is as determined by schedule BO7 of the AUTHORITIES’
Agreement.
The Pathway programme plan details the schedule for the EPOSS Acceptance
Test.
4. DELIVERABLES & SERVICES
This section details the Deliverables and Services that are the subject of this
Acceptance Test and as defined by the related Agreements.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 8 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O0S
iF i, i ersion: .
Acceptance Specification Date. 18/12/98
Deliverable or Contract Method
Service. Reference
EPOSS POCL Agreement Schedule A15: I Acceptance Trial
Requirements Acceptance Review
Table of Deliverables and Services.
5. ACCEPTANCE CRITERIA
This section lists the identifier of each Acceptance Criterion that will be
demonstrated by the Acceptance Test. It also lists the Acceptance Test
Conditions that are used to determine whether (or not) the Acceptance Criterion
has been met together with the applicable test Phase, Technical Test, or Live
Trial.
Acceptance Criteria are split into three sets of tables according to the nature of
the acceptance method, one set for those tested by Acceptance Trial, a second
for those tested by Acceptance Review and a third which lists those criteria which
are for Acceptance at a later release. The Release on which Acceptance is to be
conducted is defined by reference to the Release Contents Description included
in the Associated Documents section of the Acceptance Specification.
Exceptionally, it may be necessary for one particular Acceptance Criterion to be
tested by a combination of trial and review in which case there are entries for
Trial and Review.
5.1 ACCEPTANCE CRITERIA AND TEST CONDITIONS
Conformance of the EPOSS Acceptance Criteria will be demonstrated through
Acceptance Trials and/or Acceptance Reviews.
Tests conducted by Acceptance Trials comprise practical tests using prepared
test scripts. If applicable the Test Condition(s) appropriate to a criterion are
specified in section 5.1.1 together with a description of the test. Detailed
composition of the test in terms of sequences of Test Conditions is contained in
Section 10. In the tables in section 5.1.1 the rows labelled Function Run Entry
will be populated immediately prior to the running of the Acceptance Trials ina
working version of the Acceptance Specification. These will provide invigilators
with references to the checklists used to monitor the progress of the testing. The
order of running of Test Conditions will not necessarily correspond to the order
presented in HLTPs because of the “physicalisation” of the testing. The Function
Run Entry will allow the invigilator to read across from the criterion to the
checklist.
Tests conducted by Acceptance Review comprise typically document reviews,
site visits or presentations. If applicable the Test Condition(s) are described in
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 9 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
section 5.1.2.
5.1.1. Description Of Tests Conducted By Acceptance Trial
The tables below show which Acceptance Criteria will be met by Acceptance
Trial.
All of the tests in this section will be scheduled during the Technical Test phase.
All of the tests in this section will be performed during the Technical Test phase.
Where as part of a test a report or receipt is printed the contents of the report will
as part of the test be checked for compliance to appropriate specification.
Requirement Id 473
Criterion 2
Derivation Requirement
Criterion Description I Access to OPS and Services offered via OPS to staff
working in the Outlets shall be controlled by a mechanism,
conforming to the POCL Style Guide, offering multiple
access levels and providing specific identification of each
User
HLTP / Business HTLP VI/PLA/011 Post Office domain security
Thread Scenario See also response to 820/1
See also Acceptance Review
Scenario Description I Access Controls: Tests to validate correct operation of
access control policy. OPS05_2
Function Run Entry
Requirement Id 533
Criterion 1
Derivation Requirement
Criterion Description I If the Service Infrastructure has a facility to operate in
dummy training mode, it shall not interfere with the
transfer or integrity of DSS Data or POCL Data
HLTP / Business The training facilities are provided by the underlying Riposte software
Thread Scenario and not by the EPOSS software. When a user enters training mode a
‘training’ version of the message store is created and a training
‘service’ takes control of the desktop system.
Operation of training mode is tested in the training mode system test,
TRAO1.
Test of non interference with live data is covered in TIP Interface
system tests, HLTP TPS0101 (48)
Scenario Description I At PO 1; Enter Training Mode in EPOSS and perform a
random sample of Transactions, e.g. Create Stock Unit,
Attach Stock Unit, perform EPOSS/OBCS/APS/BES
transactions.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 10 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Expected result:
TIP: No TIP transactions produced/harvested.
DW: No DW transactions produced/harvested
Function Run Entry
Requirement Id 555
Criterion 6
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support printing on manually fed pre-printed forms at the
counter, for example Girobank summary forms G4631,
G4632 and G4633;
HLTP / Business
Thread Scenario
Produced at several points in the Business Thread
e.g. BT EPO01 3.3.2/19, 3.3.4/6, 3.3.7/6, 3.3.10/8
EPO0102
Scenario Description
Clerk 1 produces counter daily Client Summary reports.
These are used for checking against manually collated
batches of client vouchers.
Clerk 2 produces counter daily transaction summary
reports. Client summaries are used for checking against
manually collated batches of client vouchers
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment
Clerk 1 produces counter weekly Client Summary reports
Function Run Entry
Requirement Id 555
Criterion 8
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support printing of existing Client reports at the counter.
This shall include printing in large fonts and printing with
90 degree rotation
HLTP / Business
Thread Scenario
Scenario Description
This will be proved by achieving 555/6.
Function Run Entry
Requirement Id 555
Criterion 9
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support the connection of electronic weighing scales
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 11 of 134
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
Ref.:
Version:
Date:
CR/ACS/008
4.0
18/12/98
EPOSS
Acceptance Specification
(which shall not be supplied under the Related
Agreements) to the Service Infrastructure. As a minimum,
connections shall include Avery Berkel type D104 and
A702. It shall be possible to share a set of weighing
scales between two or more Counter Positions at which
the Service Infrastructure has been installed
HLTP / Business
Thread Scenario
BT EPO01 3.3.12/3 EPO0102 & EPO0103
See also response to 824/2
Note: A702 not supported at Release2 - see Later
Acceptance.
Scenario Description
Clerk 1 serves a number of customers with a variety of
products including scales transactions, settling with a
variety of methods of payment.
Function Run Entry
Requirement Id 555
Criterion 11
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support the printing of cash accounts and plain paper
summaries
HLTP / Business
Thread Scenario
BT EPO01 3.3.6/24 EPO0102
see also response to Requirements 834/3 and 837
Scenario Description
Cash Account printed by Manager
Function Run Entry
Requirement Id 691
Criterion 5
Derivation SADD 4.1.3.3.2.7
Criterion Description
EPOSS shall provide the facility to manage and report on
the movement of Cash or Stock Items, either at Stock Unit
level within each Outlet, or at the level of transfers to and
from other locations external to each Outlet.
HLTP / Business
Thread Scenario
BT EPO01, 3.3.2; 3.3.4/8,9
See also Acceptance Review
Scenario Description
In3.3.2 this thread is a variety of Remittance In, Transfer In
Transfer Out transactions, including reversal and error
correction, under normal conditions and with LAN and
power failures
8)Manager 1 returns stock (including cash) to an external
source (e.g. another outlet or a supplies division) by
remitting items out from Stock Unit 1. On completion, a
Remittance Out slip showing the decrease in cash and
stock levels is produced.
9)Manager 1 has accidentally remitted out an incorrect
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 12 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
item of stock. He obtains the transaction reference number
from the Transaction Log and reverses the transaction
Function Run Entry
Requirement Id 692
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall accept single or multiple Methods of
Payment as settlement
HLTP / Business
Thread Scenario
BT EPO01 3.3.2/16,18 EPO0102
Scenario Description
Whilst purchasing a number of products which Clerk 1 has
entered at his counter, a customer decides he no longer
requires one of the products. The clerk voids the
transaction and continues with the session, finally settling
the session in cash
Clerk serves a number of customers with a variety of
products, settling with a mixture of methods of payment.
Function Run Entry
Requirement Id 693
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow production of a VAT receipt for
Customers at the end of each Customer Session, but
before the next Transaction is entered
HLTP / Business
Thread Scenario
BT EPO01 - 3.3.3/1b EPO0102
format of receipt is as agreed in (16)
Scenario Description
A customer purchases, and requires a receipt for, a
number of products which Clerk 1 enters at his counter.
At the end of the session the customer pays the balance
with the correct amount of cash, and the session is settled.
The clerk then produces a receipt.
Function Run Entry
Requirement Id 693
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall allow automatic production of a non VAT
receipt for Customers to support a specific Service e.g.
BES or APS.
HLTP / Business
Thread Scenario
The capability to produce receipts for Services such as
BES or APS is provided by a combination of Reference
Data, through which the content of the receipt is specified,
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 13 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
and the Service in question selecting that type of receipt.
HLTP APS0101(49)/BT ref 3.2018 to 2.2024
BT BPS10(50)/case2
Scenario Description
APS:
Make an APS payment. Use automated token
identification. Key in valid payment details. Print receipts
and stack payment. Do not end customer session
(repeated with various tokens)
Print customer session receipt. End customer session.
Confirm committal of Magnetic Card Payment transactions
BPS:
A customer is issued with a card and collects a payment
and printed receipt at their NPO.....
Observe that receipts are produced automatically by the
BES and APS services.
Function Run Entry
Requirement Id 693
Criterion 4
Derivation Requirement
Criterion Description
A bilingual Welsh/English receipt header and footer is
required in designated Outlets
HLTP / Business
Thread Scenario
Bilingual Receipt BT EPO01 3.3.3/2 HTLP EPO0102
English receipt BT EPO01 3.3.3/2 HTLP EPO0101
Note EPO0102 is run in an office designated by ref data to
be English, EPO0103 Welsh.
Scenario Description
A customer purchases, and requires a receipt and a
duplicate receipt for, a number of products which Clerk 1
enters at his counter. At the end of the session the
customer pays the balance with the correct amount of
cash, and the session is settled. The clerk then produces
a receipt and a duplicate receipt.
Note: that the receipt is in the correct language will be
checked according to which HLPT is being run
Function Run Entry
Requirement Id 693
Criterion 5
Derivation Requirement
Criterion Description
EPOSS shall allow production of additional (duplicate)
receipts and they shall be marked as such
HLTP / Business
BT EPO01 3.3.3/2 HLTP EPO0102
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 14 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
Thread Scenario
Scenario Description
A customer purchases, and requires a receipt and a
duplicate receipt for, a number of products which Clerk 1
enters at his counter. At the end of the session the
customer pays the balance with the correct amount of
cash, and the session is settled. The clerk then produces
a receipt and a duplicate receipt
Function Run Entry
Requirement Id 694
Criterion 1
Derivation Requirement
Criterion Description
The CONTRACTOR shall provide a point of sale / "Till"
function to record all sales
HLTP / Business
Thread Scenario
BT EPO01 3.3.3/3,9; 3.3.6/1b, 13, 23a HLTP EPO0102
Scenario Description
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment.
Clerk 1 declares and produces a report for cash in hand.
He then balances Stock Unit 2 and produces a stock unit
trial balance report. This shows no discrepancies
Clerk serves a number of customers with a variety of
products, settling with a variety of methods of payment.
Manager produces weekly Sales Report.
Manager 1 confirms the office balance and produces an
office final balance report.
He also produces Transaction Log reports to verify
transaction activity within the outlet.
For detail of range of products covered in the scripts see
summary added as section 5.1.3 to this document.
Function Run Entry
Requirement Id 694
Criterion 2
Derivation Requirement
Criterion Description
Data shall be automatically recorded in EPOSS if captured
during another Service at the point of sale.
HLTP / Business
Thread Scenario
Scenario Description
This requirement duplicates 835/1
Function Run Entry
Requirement Id
694
Criterion
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 15 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
fi H Version: 4.0
Acceptance Specification Date: 18/12/98
Derivation Requirement
Criterion Description
EPOSS shall allow the manual input by the User of weight
values where scales are not linked
HLTP / Business
Thread Scenario
BT EPO01 3.3.12/2 EPO0102
Scenario Description
The scales connection to the counter is inoperable, so an
item is weighed manually. The clerk then provides the
weight to the system, selects the destination and service
required for the item, and settles the session.
Function Run Entry
Requirement Id 695
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall provide the facility to adjust cash and Stock
levels within a Stock Unit to reflect the actual levels on
hand
HLTP / Business
Thread Scenario
This facility is demonstrated at numerous points within the
testing. For example BT EPO01 - HLTP EPO0102
3.3.4/12, 3.3.9/6b, 3.3.10/17a
Scenario Description
Clerk 2 declares and produces reports for the actual
physical contents for stock (shared stock unit only),
stamps and cash in hand in Stock Unit 2. The system
reports that there is a discrepancy (a loss) between the
actual amounts declared, and that maintained by the
system. After investigation this loss is removed by re-
declaration.
Clerk 1 adjusts his existing stock of 1st Class stamps at
the old price to zero, and adjusts the stock of Postage
Stamps upwards by the total value of 1st Class stamps at
the old price.
Clerk 1 posts unpaid cheque and voucher amounts to the
Suspense Account, awaiting payment, and adjusts the
stock of unpaid cheques and vouchers to zero
Function Run Entry
Requirement Id 695
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall provide each Outlet with the flexibility to set
up Stock Unit(s) according to the local working practice
requirement.
HLTP / Business
Thread Scenario
EPOSS allows the creation of either shared or un-shared
Stock Units, and in the case of the former the attachment
of multiple Users. Tested repeatedly during HTLP
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 16 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
EPO0103 (multiple counter scenario).
Scenario Description
See response to 695 5/6
Function Run Entry
Requirement Id 695
Criterion 3
Derivation Requirement
Criterion Description
Within EPOSS there shall be a Stock Unit management
facility at Outlet level to change Stock Unit options and
assignments
HLTP / Business
Thread Scenario
BT EPOO1 - 3.3.1/3,4,5,20,21,24,25, 3.3.2/1,2,3,4;
3.3.4/1¢;_3.3.5/1b,4; EPO0102
Scenario Description
Stock unit management is provided within EPOSS, and is
exercised at numerous points during the testing.
In the above the functions of create, assign, re-assign and
delete are tested, for both shared and individual stock
units.
Function Run Entry
Requirement Id 695
Criterion 56
Derivation Requirement
Criterion Description
EPOSS shall allow a User or group of Users to be
accountable for a Stock Unit, so that each Outlet has at
least one Stock Unit, but there can be other Stock Units,
effectively operating independently. Each Stock Unit can
in turn be tied to both a User or group of Users or a single
Till or group of Tills.
HLTP / Business
Thread Scenario
Note: definition of a Till:
A part or whole of a Stock Unit depending upon
whether or not that Stock Unit is the sole charge of
one individual or is shared between several.
The system supports the concept of multiple stock units
capable of independent operation. The creation of stock
units, attachment of users to them and reporting on the
balance within them is exercised repeatedly throughout
the test threads. Users can only do transactions against
the stock unit to which they are allocated. Every
Transaction is recorded against User, Stock Unit and
Node.
e.g. in BT EPO01 3.3.2/ 1-4 HLTP EPO0103
Scenario Description
Manager 1 creates Stock Units 1 to 4 for use in the outlet.
Manager 1 creates Clerks 1 to 4 as users for the outlet.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 17 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
Manager 1 attaches himself to Stock Unit 1.
Manager 1 attaches Clerk 1 to Stock Unit 2.
Function Run Entry
Pathway do NOT accept that POCL can request by-node
reporting under this Requirement. (1) the Requirement is
not about reporting, and (2) Nodes are not mentioned in
the Requirement - they are NOT synonymous with Tills.
Requirement Id 695
Criterion 7
Derivation Requirement
Criterion Description
EPOSS shall allow each Stock Unit to be Balanced
individually. The Stock Unit may be Balanced more than
once within a POCL Outlet Accounting Period. Cash and
Stock Items shall be entered by denomination or Stock
Item level. This applies whether or not multiple Tills are
linked to a single Stock Unit
HLTP / Business
Thread Scenario
BT EPO01 HLTP EPO0102 and 03
3.3.3/7-10 + 3.3.4/12-14
Scenario Description
He declares and produces reports for the actual physical
contents for stock (shared stock unit only), and stamps in
Stock Unit 2. The system reports that there is a
discrepancy (a gain) between the actual amounts
declared, and that maintained by the system. After
investigation this gain is removed by adjustment
Clerk 1 declares and produces a report for cash in hand.
He then balances Stock Unit 2 and produces a trial
balance report. This shows no discrepancies.
Clerk 1 rolls over Stock Unit 2 ready for working in the
next BP of the current CAP and produces a final balance
report. This is allowed even though there is an
outstanding transfer out session.
Clerk 2 declares and produces reports for the actual
physical contents for stock (shared stock unit only),
stamps and cash in hand in Stock Unit 2. The system
reports that there is a discrepancy (a loss) between the
actual amounts declared, and that maintained by the
system. After investigation this loss is removed by
redeclaration
Clerk 2 balances Stock Unit 2 and produces a trial
balance report. This shows no discrepancies
Clerk 2 rolls over Stock Unit 2 ready for working in the
next BP of the current CAP and produces a final balance
report. This is allowed even though there is an
outstanding transfer in session.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Page 18 of 134
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
[Function Run Entry
Requirement Id 695
Criterion 8
Derivation Requirement
Criterion Description
At the end of the POCL Outlet Accounting Period an
Outlet Balance is struck with the details provided by the
Balanced Stock Units
HLTP / Business
Thread Scenario
BT EPO01 3.3.6/23-23a EPO0102
Scenario Description
Manager 1 performs an office balance and produces an
office trial balance report. The report shows a net shortage
discrepancy, but the Payments total is found to be equal to
the Receipts total.
Manager 1 confirms the office balance and produces an
office final balance report.
Function Run Entry
Requirement Id 695
Criterion 9,10
Derivation Requirement
Criterion Description
An Outlet brings to account manual voucher Transactions
including Transaction Vouchers, automated voucher
Transactions including Transaction Vouchers, reports the
Suspense Account position and the Stock and cash totals
within the approved Cash Account format.
The cycle is repeated in the new POCL Outlet Accounting
Period with an Outlet Balance brought forward value that
includes the Stock and cash in hand, Suspense Account
and loss and gain position from the previous POCL Outlet
Accounting Period.
HLTP / Business
Thread Scenario
BT EPOO1 EPO0102
3.3.6/1-24[CAP1], 3.3.10/1-25[CAP2]
Scenario Description
A variety of transactions are processed, culminating with
the Manager rolling over the office into the next CAP. He
produces a Cash Account Snapshot to provide a definitive
summary of all of the business transacted at the outlet
during the current CAP. The Snapshot shows a net
shortage discrepancy, but the Payments total is found to
be equal to the Receipts total. He then produces a Cash
Account Report and rolls over the office into the next CAP.
A suspense item carried forward from CAP'1 is adjusted in
CAP2.
Function Run Entry
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 19 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 695
Criterion 11
Derivation Requirement
Criterion Description
EPOSS shall provide a secure mechanism for controlling
access to a Stock Unit
HLTP / Business
Thread Scenario
BT EPO01 3.3.1/21 EPO0101 @ 14:30
Scenario Description
820/1 tests controls on access to the system. The only
aditional control on access to a stock unit is that one
cannot attach to an individual stock unit already in use.
Attempt to attach a user Supervisor 1 to individual Stock
Unit 2 (already has a user attached)
Function Run Entry
Requirement Id 695
Criterion 12
Derivation SADD 4.1.3.1.2.1
Criterion Description
Before a Counter Clerk is allowed to record Customer
Transactions on EPOSS, EPOSS shall require that the
Counter Clerk has validly connected to a Stock Unit, either
exclusively or shared with other Counter Clerks, against
which his Transactions are to operate.
HLTP / Business
Thread Scenario
Users log on at many points in the script. Observe that on logging on
to the system there is no alternative to attaching to a stock unit. Ifa
new user has not yet been allocated to a stock unit he will be attached
to the default stock unit.
e.g. in BT EPO01 3.3.1/4_ EPO0101
Scenario Description
Manager 1 changes his attachment from the Default Stock
Unit to Stock Unit 1. He is restricted to performing
functions appropriate to his role.
Function Run Entry
Requirement Id 696
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow production of a daily Report that
shows, at Outlet level, the cash holdings by individual
denomination of bank note and coin. The format of the
report shall be agreed by POCL and the CONTRACTOR
by a date consistent with the project plan agreed by the
parties, such that the date does not adversely impact
contractual milestones as defined in Clause 605.1 of the
Authorities Agreement.
HLTP / Business
Thread Scenario
This Requirement is met by a combination of the daily
declaration report and the weekly cash flow report.
Review (16) for agreement of formats
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 20 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
The report is printed on many occasions during testing
e.g. BT EPO01 EPO0102_ 3.3.2/20, 3.3.6/12
Scenario Description
At the end of day, Clerk 1 declares the value of cash on
hand by denomination in Stock Unit 2, for inclusion in the
office weekly Cash Flow report. When he has finished he
realises that he has made a mistake during declaration, so
he re-declares the cash on hand and produces a
Declaration Report
Manager 1 produces the office weekly Cash Flow report.
Function Run Entry
Requirement Id 696
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall support the summarisation of daily and
weekly Transaction Vouchers at Stock Unit level.
HLTP / Business
Thread Scenario
BT EPO01 3.3.10/7-12 EPO0102
Scenario Description
Clerk 1 produces counter daily transaction summary
reports. Client summaries are used for checking against
manually collated batches of client vouchers.
Clerk 1 produces counter weekly Client Summary reports.
At the end of day, Clerk 1 declares the value of cash on
hand by denomination in Stock Unit 2, for inclusion in the
office weekly Cash Flow report, and produces a
declaration report.
Clerk 1 produces the counter weekly Rent Schemes
report.
Clerk 1 produces the counter weekly Bus Tokens report.
Clerk 1 produces the counter weekly Infrequent
Transactions report.
For detail of range of products covered in the scripts see
summary added as section 5.1.3 to this document.
Function Run Entry
Requirement Id 696
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall support a reporting facility to print on Client
cut sheet stationery where the Client requires it (including
without limitation Girobank daily summaries).
HLTP / Business
Thread Scenario
Scenario Description
This requirement duplicates 555/6
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 21 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
age A Version: 4.0
Acceptance Specification Date. 18/12/98
[Function Run Entry
Requirement Id 696
Criterion 6
Derivation Requirement
Criterion Description
EPOSS shall allow production of duplicate receipts and
they shall be marked as such
HLTP / Business
Thread Scenario
Scenario Description
This requirement duplicates 693/5
Function Run Entry
Requirement Id 696
Criterion 7
Derivation Requirement
Criterion Description
EPOSS shall support a reporting facility to print on Client
cut sheet stationery to support Girobank and the
Postmaster’s Daily Record (PDR) summarisation.
HLTP / Business
Thread Scenario
Scenario Description
This requirement duplicates 555/6.
Function Run Entry
Thread Scenario
Requirement Id 696
Criterion 9
Derivation Requirement
Criterion Description I EPOSS shall allow reporting to be previewed on screen
HLTP / Business
Scenario Description
This is a general facility provided by the EPOSS system.
The Low Level Test Plans call for all reports to be both
previewed and printed
e.g. EPO0102 29/3/97 at 04:00:00
Print and preview Other banks cheques. Check results match data entered,
Remit In stock from a client to Stock Unit 1, while the counter printer is switched off.
Warning that printer not working. Remittance In slip produced as a screen preview
automatically. Shows stock items, quantity and value.
Function Run Entry
Requirement Id 800
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall support the recording of all Transactions
between the Customer and the User.
HLTP / Business
This duplicates 694/1
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 22 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Thread Scenario
Scenario Description
Function Run Entry
Requirement Id 800
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall allow the selection of Customer Sessions to
allow for:
a) normal Customer service or;
b) a Refund or;
c) a Reversal
HLTP / Business
Thread Scenario
Tested in numerous instances
e.g. BT EPO01 3.3.4/2, 3.3.11/1d, 2 HLTP EPO0102
Scenario Description
A customer who was served in a previous Balance Period
within the same Cash Account Period returns to the outlet
and requests a refund. Clerk 2 obtains the relevant
transaction reference numbers from the Transaction Log
and reverses the transactions. The customer is refunded.
A customer returns to the outlet to request a refund for
purchases made. Clerk 1 obtains the transaction reference
numbers from the Transaction Log and finds that the
transactions were carried out in a previous CAP. He uses
the “new” reversal facility to select the quantity and value
of products returned for reversal and reverses them. The
customer is refunded
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment.
Function Run Entry
Requirement Id 800
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall uniquely identify a customer session and
each transaction within the Balancing Period.
HLTP / Business
Thread Scenario
HTLP VI/PLA/011
OPS06_3
See also 803/1
Scenario Description
Riposte Message Store - Audit
Multiple test to check integrity of message store
Function Run Entry
Requirement Id 800
Criterion 4
Derivation Requirement
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 23 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Criterion Description
EPOSS shall allow Customer Session completion to be
implemented in a way to encourage a ‘one Customer one
session’ rule.
HLTP / Business
Thread Scenario
EPOSS allows the customer to add to or subtract from his
purchase requirements up till final settlement of the
transaction.
For example BT EPO01 - 3.3.2/16 EPO0102
Scenario Description
Whilst purchasing a number of products which Clerk 1 has
entered at his counter, a customer decides he no longer
requires one of the products. The clerk voids the
transaction and continues with the session, finally settling
the session in cash.
Function Run Entry
Requirement Id 800
Criterion 5
Derivation Requirement
Criterion Description
EPOSS shall provide a cash tendered facility to calculate
change due to the Customer. Use of this feature shall be
at the discretion of the User and not forced by EROSS
HLTP / Business
Thread Scenario
This facility is simply part of the stack handling process. A
running total for the session is provided. If cash received
in excess of the total is entered then the running total will
show the change due, which can be settled using the fast
cash capability. E.g. BT EPO01 3.3.4/4 EPO0102
Scenario Description
Clerk 2 serves a staff member with a number of products,
some discountable and some non-discountable. At the end
of the session the clerk applies a session discount which
is applied to all of the discountable products sold. The
staff member tenders an amount greater than the balance
due , receives some change, and the session is settled
Function Run Entry
Requirement Id 800
Criterion 6
Derivation SADD
Criterion Description
Within a Customer Session EPOSS shall allow: Void
Transactions. [SADD 4.1.3.1.10.]
HLTP / Business
Thread Scenario
Tested in many places in the thread:
e.g. BT EPO01 3.3.2/16, 18a EPO0102
Scenario Description
Whilst purchasing a number of products which Clerk 1 has
entered at his counter, a customer decides he no longer
requires one of the products. The clerk voids the
transaction and continues with the session, finally settling
the session in cash.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 24 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
Clerk 1 produces a transaction log showing customer
sales transactions performed during the day. Voided
transactions are not shown.
Function Run Entry
Requirement Id 801
Criterion 1
Derivation Requirement
Criterion Description I EPOSS shall support the current range of business
performed within outlets eg
(a) value stock
(b) method of payment
(c) a counter shortage known as a "loss"
(d) a counter shortage known as a "gain"
(e) a POCL product
(f) an inpay supported by a client voucher (receipt)
(g) an outpay supported by a a client voucher (payment)
HLTP / Business BT EPO01: HLTP EPO0102
Thread Scenario 1. (a), (b), (e), (f) BT 3.3.4/4
2. (c) BT 3.3.4/12
3. (d) BT 3.3.3/7
4. (g) BT 3.3.4/5
See Also 808/3
1. A customer purchases a mixture of discounted and non-
discountable products. Clerk 2 applies a discount on all
the discountable products in the session. The customer
pays the balance in cash and receives some change, and
the session is settled. (this includes a Girobank deposit)
2. Clerk 2 is a temporary clerk. He will not be available
again. At a counter he declares the actual physical
contents for stock (shared stock unit only), stamps and
cash in hand in Stock Unit 2. The system reports that
there is a discrepancy (a loss) between the actual
amounts declared, and that maintained by the system.
After investigation this loss is removed by re-declaration.
3. Clerk 1 is going on holiday until the start of the next
CAP. At a counter he declares the actual physical
contents for stock (shared stock unit only), and stamps in
Stock Unit 2. The system reports that there is a
discrepancy (a gain) between the actual amounts
declared, and that maintained by the system. After
investigation this gain is adjusted.
4. Clerk 2 serves a number of customers with a variety of
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 25 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
products, settling with a variety of methods of payment.
(this includes a Girobank a/c withdrawal)
Function Run Entry
Requirement Id 801
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall support the Customer Transaction by price
type as follows:
(a) fixed price - where the price is held by EPOSS; or
(b) variable price (open) - where the User enters the
actual price. If the valid range excludes zero the User is
forced to enter a non zero price; or
(c) variable price (default) - where the default price is non
zero. The User can either accept this price or overtype to
change it within the valid range.
HLTP / Business
Thread Scenario
BT EPO01 3.3.3/3 HLTP EPO0102
Scenario Description
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment.
Settle session by TV stamp redemption, using the TV stamp non-zero default value
Settle session by TV stamp redemption, overriding the TV stamp non-zero default value
Function Run Entry
Requirement Id 801
Criterion 3
Derivation Requirement
Criterion Description
Where necessary Composite Products shall be declared
at individual denomination or item level by the User as
part of the Balancing activity
HLTP / Business
Thread Scenario
this is demonstrated whenever cash or stamps are
declared and input by denomination.
e.g. BT EPO01 3.3.4/12 HLTP EPO0102
Scenario Description
Clerk 2 declares and produces reports for the actual
physical contents for stock (shared stock unit only),
stamps and cash in hand in Stock Unit 2. ......
Function Run Entry
Requirement Id 802
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall maintain the current Stock record for Value
Stock items and Methods of Payment to reflect the
Transactions completed, e.g. if a postal order and the
Associated Fee are sold for cash the Stock of the former is
decreased and that of the cash is increased.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 26 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
Fi i ersion:
Acceptance Specification Date: 18/12/98
HLTP / Business BT EPO01 3.3.2/5,18,20 ; 3.3.3/6a
Thread Scenario
Scenario Description
Manager 1 produces a balance snapshot for Stock Unit 1
which shows no stock or transaction activity. He then
replenishes stock (including cash) from an external source
(e.g. another outlet or a supplies division) by remitting
items into Stock Unit 1. Whilst remitting in stock, he
suspends the session to serve a customer. On completion,
a Remittance In slip showing the increase in cash and
stock levels is produced.
Clerk 1 serves a number of customers with a variety of
products (including postal order), settling with a variety of
methods of payment.
At the end of day, Clerk 1 produces a balance snapshot
for Stock Unit 1 which reflects the stock position and
activity during the day. He then declares the value of cash
on hand by denomination in Stock Unit 2, for inclusion in
the office weekly Cash Flow report. When he has finished
he realises that he has made a mistake during declaration,
so he re-declares the cash on hand and produces a
declaration report
Clerk 1 ... produces a balance snapshot for Stock Unit 2
to provide a summary of the stock unit’s activities during
the current BP.
Function Run Entry
Requirement Id 802
Criterion 2
Derivation Requirement
Criterion Description
EPOSS must allow compensating errors to be remedied
without the need to perform a Reversal or a sale.
HLTP / Business
Thread Scenario
BT EPO01 3.3.3/7 HLTP EPO0102
Scenario Description
..declares and produces reports for the actual physical
contents for stock (shared stock unit only), and stamps in
Stock Unit 2. The system reports that there is a
discrepancy (a gain) between the actual amounts
declared, and that maintained by the system. After
investigation this gain is removed by adjustment
Function Run Entry
Requirement Id
803
Criterion
1
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 27 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
ifi H Version: 4.0
Acceptance Specification Date. 18/12/98
Derivation Requirement
Criterion Description
EPOSS shall accurately maintain data and record all
Transaction Sessions as double entries
HLTP / Business
Thread Scenario
This can be observed all through the test thread. EPOSS
maintains a running balance for each session, and a
session cannot be completed until payments (by cash or
other methods) and purchases net to zero.
e.g. BT EPO01 3.3.2/18, 3.3.6/24 HLTP EPO0102
See also 800/3
Scenario Description
Clerk 1 serves a number of customers with a variety of
products (including postal order), settling with a variety of
methods of payment.
Manager 1 rolls over the office into the next CAP. Two
copies of the final Cash Account report are automatically
produced. (note: BT tracks transaction data from the
beginning of a CAP (clean slate) to the completion and
rollover of that CAP).
Function Run Entry
Requirement Id 803
Criterion 2
Derivation Requirement
Criterion Description
If EPOSS is interrupted or fails during a Customer Session
the Service Infrastructure shall ensure that data capture is
resilient and consistent with the need to retain a balanced
status
HLTP / Business
Thread Scenario
Power interruption and LAN disconnects are tested
repeatedly for all transaction types.
E.g. BT EPO01 3.3.8/4 HLTP EPO0102
This requirement is a subset of 830/1
See also Pathway Release 2 Technical Integrity and
Networking HLTP (21) for extensive testing of failure
scenarios.
Scenario Description
Whilst Clerk 1 is serving a customer, there is a power
failure at the counter. When power is restored the
customer session is lost and stock levels remain
unchanged.
Function Run Entry
Requirement Id 804
Criterion 1
Derivation Requirement
Criterion Description
A journal of all Transaction data must be available to allow
the user to refer back to a previous Transaction.
HLTP / Business
BT EPO01 - 3.3.2/8 HLTP EPO0102
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 28 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Thread Scenario
See Also 800/2 and 694/1
Scenario Description
Manager 1 has accidentally remitted into Stock Unit 1 an
incorrect item of stock. He obtains the transaction
reference number from the Transaction Log and reverses
the transaction.
Function Run Entry
Requirement Id 804
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall provide a Transaction log for any Balancing
Period in the POCL Outlet Accounting Period to allow the
User to refer back to a previous Transaction
HLTP / Business
Thread Scenario
See also 804/1
Scenario Description
This is a sub-set of Requirement 816/3
Function Run Entry
Requirement Id 804
Criterion 3
Derivation Requirement
Criterion Description
The Transaction log may be used in conjunction with a
Transaction Reversal by the User to identify the unique
Transaction Id
HLTP / Business
Thread Scenario
Transaction log accessed repeatedly during testing for a
variety of transactions.
e.g. BT EPO01 3.3.2/8 HLTP EPO0102
Scenario Description
Manager 1 has accidentally remitted into Stock Unit 1 an
incorrect item of stock. He obtains the transaction
reference number from the Transaction Log and reverses
the transaction.
Function Run Entry
Requirement Id 804
Criterion 4
Derivation Requirement
Criterion Description
The Transaction log shall be easily accessible to the User
for the resolution of enquiries
HLTP / Business
Thread Scenario
BT EPO01 3.3.14/1b
Scenario Description
Manager 1 produces a full range of transaction log reports
covering the previous 2 CAPs.
Function Run Entry
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 29 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 805
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall maintain a log of Transactions attempted
and actioned at Stock Unit level
HLTP / Business
Thread Scenario
see 804/4 above for transactions.
See 805/2 for other events
Scenario Description
Auditor 1 wishes to check the events that have taken
place at the outlet over the last three CAPs. He uses a
“single user password account” to gain entry to the
system, and produces event logs to provide the
information.
Function Run Entry
Requirement Id 805
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall provide an audit/Event log for any Balancing
Period in the current POCL Outlet Accounting Period by
Stock Unit
HLTP / Business
Thread Scenario
BT EP01: 3.3.13/8 HLTP EPO0102
Scenario Description
Auditor 1 wishes to check the events that have taken
place at the outlet over the last three CAPs. He uses a
“single user password account” to gain entry to the
system, and produces the full range of event logs to
provide the information.
Function Run Entry
Requirement Id 805
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall provide a facility to allow the User to inspect
activities on the Stock Unit within the POCL Outlet
Accounting Period so that, without limitation all attempts to
access a Stock Unit can be detected
HLTP / Business
Thread Scenario
BT EP01: 3.3.13/8 HLTP EPO0102
See also 805/2
Scenario Description
Auditor 1 wishes to check the events that have taken
place at the outlet over the last three CAPs. He uses a
“single user password account” to gain entry to the
system, and produces event logs to provide the
information.
Function Run Entry
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 30 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref: CR/ACS/008
fi 4 Version: 4.0
Acceptance Specification Date. 18/12/98
Requirement Id 805
Criterion 4
Derivation Requirement
Criterion Description
The audit/Event log shall be readily available to the User
for the resolution of enquiries
HLTP / Business
Thread Scenario
BT EP01: 3.3.13/8 HLTP EPO0102
See also 805/2
Scenario Description
Auditor 1 wishes to check the events that have taken
place at the outlet over the last three CAPs. He uses a
“single user password account” to gain entry to the
system, and produces event logs to provide the
information.
Function Run Entry
Requirement Id 805
Criterion 5
Derivation SADD 4.1.3.1.16
Criterion Description
All Transactions and actions undertaken in EPOSS shall
be recorded in an audit trail by use of, and maintained by,
the POCL Infrastructure Services.
HLTP / Business
Thread Scenario
All Transactions and actions are recorded in the RIPOSTE
message store. Transaction data can be printed on the
Transaction log, Event data (e.g. logging on) can be
printed on the Event Log.
Scenario Description
see 805 / 1,2 above
Function Run Entry
Requirement Id 806
Criterion 1
Derivation Requirement
Criterion Description
The date and time within EPOSS shall be accurately
maintained and remain in step with Greenwich Mean Time
and/or British Summer Time as appropriate.
HLTP / Business
Thread Scenario
Time testing is covered extensivly by the Systems
Management HLTP (44)
TM10
See also Acceptance Review
Scenario Description
Advance a platform clock and wait for resync.
Function Run Entry
Requirement Id 807
Criterion 1,2,3
Derivation Requirement
Criterion Description
EPOSS shall allow the movements of Value Stock Items
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 31 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
Ref.:
Version:
Date:
CR/ACS/008
4.0
18/12/98
EPOSS
Acceptance Specification
and Methods of Payment into and out of Stock Units within
the same Outlet to be recorded.
The data recording a movement shall be entered in a
Transaction Session similar to a Customer Session except
that the session total comes to the Transfer total rather
than to zero. However, EPOSS shall adjust overall item
Stock levels when the data entry session is complete so
that the "balance" of the Stock Unit is maintained
HLTP / Business
Thread Scenario
This is tested in many places - for example:
BT EPO01 - 3.3.2/9,12; 3.3.6/17_ I HLTP EPO0102
Scenario Description
Manager 1 transfers out cash and stock from Stock Unit 1
to receiving Stock Unit 2. Whilst performing the transfers,
he suspends the session to serve a customer. On
completion, a Transfer Out slip showing the decrease in
cash and stock levels is produced.
Clerk 1 transfers into Stock Unit 2 cash and stock (except
the stamp books) that have been transferred out from
sending Stock Unit 1. On completion, a Transfer In slip
showing the increase in cash and stock levels is produced
Clerk 3 rolls over Stock Unit 2 ready for working in the first
BP of the next CAP and produces a final balance report.
Note: this includes an attempt to transfer to stock to a unit
in a different CAP
The range of products covered by the scripts is
summarised in section 5.1.3.
Function Run Entry
Requirement Id 807
Criterion 4
Derivation Requirement
Criterion Description
Each movement is entered to the current Balancing Period
for the Stock Unit
HLTP / Business
Thread Scenario
Near the end of day 2 of BT EPO01 a Balance Report is
produced, which will show the amounts transferred in and
out earlier in the BT:
BT 3.3.3/9,10 _ HLTP EPO0102
Scenario Description
Clerk 1 declares and produces a report for cash in hand.
He then balances Stock Unit 2 and produces a trial
balance report. This shows no discrepancies
Clerk 1 rolls over Stock Unit 2 ready for working in the
next BP of the current CAP and produces a final balance
report. This is allowed even though there is an
outstanding transfer out session
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 32 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
Fu
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
FUJ00058412
}J00058412
In here is a test that the CAP cannot be rolled with
outstanding transfers
Function Run Entry
Requirement Id 807
Criterion 5
Derivation SADD 4.1.3.3.2.6
Criterion Description
EPOSS shall provide the facility to manage and report on
the movement of Cash or Stock Items at Stock Unit level
within each Outlet
HLTP / Business
Thread Scenario
this is a sub-set of 691/5
Scenario Description
Function Run Entry
Requirement Id 808
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall provide a Suspense Account facility where
items that cannot be cleared operationally during one
POCL Outlet Accounting Period can be identified and
carried forward to the next
HLTP / Business
Thread Scenario
Tested a number of times during the thread
e.g. BT EPO01 3.3.7/1b; 3.3.9/6; 3.3.10/17a,22;
3.3.11/1b HLTP EPO0102
Scenario Description
1b:Reasons for part of the discrepancy (brought forward
from the previous CAP) have been found. Manager 1
authorises Clerk 1 to post amounts for some shortages
and gains to the Suspense Account. A reason for the
remainder of the discrepancy has not been found. This is
retained in the system.
6:Manager 1 receives an Error Notice from POCL to make
a correction for a remittance transaction for which an
incorrect amount was entered and which resulted in part of
the shortage held in the Suspense Account. He instructs
Clerk 1 to redeem this shortage from the Suspense
Account and apply the Error Notice.
17a: (in cap2) Clerk 1 posts unpaid cheque and voucher
amounts to the Suspense Account, awaiting payment, and
adjusts the stock of unpaid cheques and vouchers to zero.
22: Manager 1 produces the office weekly Suspense
Account report
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 33 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
1b: Payment has been received for an unpaid cheque
previously posted to the Suspense Account. Clerk 1
tedeems its value from the Suspense Account.
Function Run Entry
Requirement Id 808
Criterion 4
Derivation Requirement
Criterion Description
EPOSS shall provide an on demand Outlet Balance
Report to a POCL agreed format, this format shall be
agreed by a date consistent with the project plan agreed
by the parties, such that the date does not adversely
impact contractual milestones as defined in Clause 605.1
of the Authorities Agreement. This Report shall provide a
“snap shot” of the Outlet position within the current POCL
Outlet Accounting Period
HLTP / Business
Thread Scenario
BT E001 3.3.6/22a HLTP EPO0102
Scenario Description
Manager 1 produces an office balance snapshot which
provides an amalgamation of all data within the CAP.
Function Run Entry
Requirement Id 809
Criterion 1
Derivation Requirement
Criterion Description
Within a Customer Session EPOSS shall maintain a
running record of all Transactions performed;
HLTP / Business
Thread Scenario
This requirement duplicates 825/5(a)
Scenario Description
Function Run Entry
Requirement Id 809
Criterion 2
Derivation Requirement
Criterion Description
Within a Customer Session EPOSS shall maintain the
current balance;
HLTP / Business
Thread Scenario
This requirement duplicates 825/5(b)
Scenario Description
Function Run Entry
Requirement Id
809
Criterion
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 34 of 134
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date. 18/12/98
Derivation Requirement
Criterion Description
Within a Customer Session EPOSS shall maintain the
accounting sense (pay out/take in);
HLTP / Business
Thread Scenario
This requirement duplicates 825/5(c)
Scenario Description
Function Run Entry
Requirement Id 809
Criterion 4
Derivation Requirement
Criterion Description
Within a Customer Session EPOSS shall maintain
settlement details
HLTP / Business
Thread Scenario
This requirement duplicates 825/5(d)
Scenario Description
Function Run Entry
Requirement Id 809
Criterion 5
Derivation Requirement
Criterion Description
Multiple Transactions for the same Customer shall be
logically grouped into a single Customer Session
HLTP / Business
Thread Scenario See 800/4
Scenario Description
Function Run Entry
Requirement Id 810
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow the Refund or Reversal of a
Transaction according to Client and POCL accounting and
business rules as agreed between the parties from time to
time.
HLTP / Business
Thread Scenario
BT EPO01 3.3.4/2,9 HLTP EPO0102
3.3.11/1d HLTP EPO0102
see also responses to 812/2, 825/10
Scenario Description
A customer who was served on a previous day within the
same Cash Account Period returns to the outlet and
requests a refund. Clerk 2 obtains the transaction
reference numbers from the transaction log and reverses
the transactions. The customer is refunded.
Manager 1 has accidentally remitted out an incorrect item
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 35 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref. CR/ACS/008
tee ge Version: 4.0
Acceptance Specification Date. 18/12/98
of stock. He obtains the transaction reference number
from the transaction log and reverses the transaction.
A customer returns to the outlet to request a refund for
purchases made. Clerk 1 obtains the transaction reference
numbers from the Transaction Log and finds that the
transactions were carried out in a previous CAP. He uses
the “new” reversal facility to select the quantity and value
of products returned for reversal and reverses them. The
customer is refunded.
Function Run Entry
Requirement Id 810
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall enable certain Transactions not to be
refundable or reversible to comply with any changes to the
Client and POCL accounting and business rules as
agreed with POCL from time to time
HLTP / Business
Thread Scenario
BT EPO01 3.3.4/2, 3.3.11/1d HLTP EPO0102
see also responses to 810/1, 812/2, 825/10
Scenario Description
A customer who was served on a previous day within the
same Cash Account Period returns to the outlet and
requests a refund. Clerk 2 obtains the transaction
reference numbers from the transaction log and reverses
the transactions. The customer is refunded. [Also in this
thread is an attempt to reverse non-refundable EPOSS
product]
A customer returns to the outlet to request a refund for
purchases made. Clerk 1 obtains the transaction reference
numbers from the Transaction Log and finds that the
transactions were carried out in a previous CAP. He uses
the “new” reversal facility to select the quantity and value
of products returned for reversal and reverses them. The
customer is refunded.
Function Run Entry
Requirement Id 810
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall be able to validate Transaction details
against Reference Data.
HLTP / Business
Thread Scenario
BT RDS01 3.3.2 (This forms part of the Ref Data AS)
See also Acceptance Review
Scenario Description
* Data transfer is simulated from the POCL Gateway to the Pathway
Gateway.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 36 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
* the files will contain the necessary elements stated at 3.1.5 above, in the
stated sequence (where present)
Utilise FTP to move data to Sequent Server.
Examine content via the relevant UNIX commands, (all OK, no missing
files/data)
* the file will contain elements to:
Add new Region, Amend Region, Close Region,
Add Client, Amend Client, Delete Client,
Amend Default Opening Times at existing open Outlet(s),
Add Accounting detail for new Client,
Amend Accounting Period for existing Client(s),
Amend Week for existing Client(s), Amend Day for existing Client(s),
Add new (open) Outlet, Amend Outlet, Close Outlet,
Add Satellite, Amend Satellite, Close Satellite,
Replace existing Product (core and non core) with new version,
(note: wide range of different product amendments made here)
Load data from the Sequent to RDMC, (all OK, no load errors)
* Load validation is automatic and based on the file/record layout rules in the
RDAIS [2] document
Examine loaded data on RDMC, (all OK, no data integrity errors).
* The Outlet identification must match the existing Outlets set up.
Examine and confirm Audit trail via use of SQLPLUS enquiry utility against
the relevant Database Tables on the RDMC.
Confirm the loaded elements have been allocated the correct Class.
* A mixture of Class 1 through 5 based on the Class Rules.
Set the relevant (and available) Outlet(s) to active.
Run ‘external’ packages to cater for: EPOSS data, Change Control
The TMS Agent should be polling continuously and therefore immediately
pick up Class 1 elements and transform the data to the Outlets Counter(s).
* In reality, this would make examining Class 1 data difficult, the Agent could
be activated after the examination.
Perform a ‘scheduled release’ of the Class 2 thru 5 elements for the TMS
Agent to pick them up and transfer to the Outlet(s).
Activate the TMS Agent (R_LD_ALL) to retrieve data via the RDDS and
create the Attribute Grammar on the Sequent Server Message Store and then
the TMS Agent (R_LD_REPLIC) to replicate to all relevant applicable Post
Office Counters.
Examine and confirm results via the relevant RIPOSTE enquiry tool at the
Outlet PC.
Instigate start of day at the Counter which coincides with the Start Date of the
Reference Data elements to prove they are live and functional
Transact normal business against the installed elements.
Instigate close of day at the Outlet. Action normal end-of-day Harvesting
Examine and confirm results via use of SQLPLUS enquiry utility against the
relevant Database Tables on the RDMC.
Examine and confirm Audit trail via use of SQLPLUS enquiry utility against
the relevant Database Tables on the RDMC.
Run the MIS extract procedure and check that the output files are to the
correct format and contain the correct data
Run TPS extract and check TPS_OUTLET and TPS_CLIENT tables are
populated correctly
Function Run Entry
Requirement Id 810
Criterion 4
Derivation Requirement
Criterion Description
EPOSS shall provide the ability to Rate Shop against a
value input for a fixed price POCL Product.
HLTP / Business
BT 3.3.5/5,6 HLTP EPO0102
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 37 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Thread Scenario
Scenario Description
A customer wishes to purchase as many items of a
product for which he has a fixed sum of money. Clerk 3
uses the “Price Shopping” facility to enter this value and
the system determines the number of products that the
customer may purchase for this amount. The customer
decides to purchase the number calculated by the system.
This option is selected by the clerk. The customer pays
the balance with the correct amount of cash, and the
session is settled note: this senario includes an attempt to
rate shop an open value item.
A customer wishes to purchase as many items of a
product for which he has a fixed sum of money. Clerk 3
uses the “Price Shopping” facility to enter this value and
the system determines the number of products that the
customer may purchase for this amount. The customer
decides to purchase one more than the number calculated
by the system. This option is selected by the clerk. The
customer pays the balance with the correct amount of
cash, and the session is settled.
Function Run Entry
Requirement Id 812
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow Reversals for Customer Services, and
Transfers either within the Outlet or to a remote location
HLTP / Business
Thread Scenario
See 810/182
Scenario Description
Function Run Entry
Requirement Id 812
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall allow Reversals to be entered for normal
Transactions (but not for Reversals) only for Customer
Service Transactions which are not part of other Services
e.g. BES or APS or disallowed in Reference Data supplied
by POCL to the CONTRACTOR from time to time.
HLTP / Business
Thread Scenario
Reference data defines whether or not EPOSS will allow a
transaction to be reversed, except for APS where the
service itself refuses reversals.
Re EPOSS products, see Requirement 810/1,2 above
BT EPO01 3.3.4/9
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 38 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Re APS: HLTP APS0101(49), “BT Ref” 2.1014, 2.1018
Re BES: BES transactions are defined by Reference Data
to be non reversible. Ref BITO3(51) case 131
Scenario Description
EPOSS
Manager 1 has accidentally remitted out an incorrect item
of stock. He obtains the transaction reference number
from the Transaction Log and reverses the transaction
note: within this scenario an attempt is made to reverse a
reversal
APS
Initiate reversal of an APS payment. Input details from the
original customer APS receipt. Print receipts and complete
reversal.
Initiate reversal of an APS payment. Input details from the
original customer APS receipt. Respond to the error
message indicating that scheme rules do not allow
reversal. Void the transaction.
BES
At a single stock-unit office, a representative cross section
of benefit transactions are conducted for a range of payee
types An attempted reversal of the BES transaction is
attempted but can not be completed.......
Function Run Entry
Requirement Id 812
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall permit Users to enter a Reversal which
needs not correspond to a particular Transaction on the
Transaction log identified by the User according to Client
and POCL accounting and business rules as agreed
between the parties from time to time
HLTP / Business
Thread Scenario
BT EPO01 3.3.11/1d
See also 810/1,2
Scenario Description
A customer returns to the outlet to request a refund for
purchases made within a previous Cash Account Period.
Clerk 1 uses the “new” reversal facility to select the
quantity and value of products returned for reversal and
reverses them. The customer is refunded.
Function Run Entry
Requirement Id
813
Criterion
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 39 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
ifi H Version: 4.0
Acceptance Specification Date. 18/12/98
Derivation Requirement
Criterion Description
EPOSS shall allow revaluation of fixed price Value Stock
Stock Items and Methods of Payment when the price
changes.(Note: While price changes would not normally
apply to Methods of Payment, it is a desirable feature in
case of future alternative currencies, e.g. the "Euro".
However, the remainder of this requirement is written in
terms of Value Stock.)
HLTP / Business
Thread Scenario
BT EPO01 3.3.9/1a,1b
Note: POCL Reference Data does not support revaluation
of method of payment.
Scenario Description
When Clerk 1 logs on to the system he is prompted that
Reference Data price changes (including changes to first
and second class stamps, discounted stamps and postal
order fees) are effective from today. He uses the manual
revaluation process to revalue these products
Reference Data price changes (including changes to
philatelic items, discounted stamps and postal order fees)
are effective from today. Clerk 1 uses the manual
revaluation process to re-value stock for these products in
Stock Unit 2.
Function Run Entry
Requirement Id 813
Criterion 2
Derivation Requirement
Criterion Description
When a price changes for a fixed price Value Stock Stock
Item, the Stock value must change to maintain the
relationship Stock value = Stock quantity x price. The
change in Stock value must be "balanced" by one or more
Transactions for designated POCL Products (and thence
reported on designated Cash Account lines). Thus the
requirement for maintaining an equal and opposite effect
on the Stock Unit is maintained
HLTP / Business
Thread Scenario
The EPOSS functionality can be seen by performing a
revaluation and subsequently printing a Cash Account.
BT EPO01 3.3.6/1a,14b; 3.3.9/1a,b; 3.3.10/25
Scenario Description
A Reference Data price change (decrease in value of
stamp books) is effective from today. Clerk 3 uses the
manual revaluation process to re-value stock for this
product in Stock Unit 2, but makes a mistake when
entering the value. He reverses the transaction but forgets
to re-perform the revaluation with the correct value.
Clerk 3 attempts to balance Stock Unit 2 but is advised of
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 40 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
revaluation errors relating to stamp books and Airpacks
because the relationship of (value = stock quantity x price)
has not been maintained. He realises that he has
overlooked the revaluation of stamp books at the
beginning of the day, and that he should not have re-
valued Airpacks since they have not changed price. He
uses the manual revaluation process to re-value the stock
of stamp books in Stock Unit 2, and the reversal process
to reverse the revaluation of Airpacks. He then produces
another balance snapshot.
Overnight, the system has detected that Reference Data
price changes (including changes to philatelic stamps,
discounted stamps, stamp books and postal order fees)
are to take effect from today, and price changes to 1st and
2nd Class stamps are to take effect from the start of Day 4
of CAP 2. When Clerk 1 logs on to the system he is
informed that this will take place, and a report detailing the
changes is produced. He is also informed that the
previous day’s overnight cash holding for Stock Unit 2 has
not been declared. He inadvertently overlooks the
declaration.
Reference Data price changes (including changes to
philatelic items, discounted stamps, stamp books and
postal order fees) are effective from today. Clerk 1 uses
the manual revaluation process to re-value stock for these
products in Stock Unit 2.
Manager 1 wishes to roll over the office into the next CAP
earlier than the Post Office cash account calendar
stipulates. He produces a Cash Account Snapshot to
provide a definitive summary of all of the business
transacted at the outlet during the current CAP. The
Snapshot shows a net surplus discrepancy, but the
Payments total is found to be equal to the Receipts total.
He then produces a Cash Account Report and rolls over
the office into the next CAP
Function Run Entry
Requirement Id 813
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall allow efficient revaluation of multiple Value
Stock Stock Items of the same generic type e.g. postal
order fees.
HLTP / Business
BT EPO01 3.3.9/1a
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 41 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Thread Scenario
Scenario Description
When Clerk 1 logs on to the system he is prompted that
Reference Data price changes (including changes to first
and second class stamps, discounted stamps and postal
order fees) are effective from today. He uses the manual
revaluation process to revalue these products. Note that in
the LLTP both 50p and £1PO Fees are revalued against
band 1
Function Run Entry
Requirement Id 813
Criterion 4
Derivation Requirement
Criterion Description
EPOSS shall ensure that only Value Stock Stock Items
allowed in Reference Data provided by POCL to the
CONTRACTOR from time to time can be accessed/for
revaluation]
HLTP / Business
Thread Scenario
BT EPO01 3.3.6/1a, 14b
HLTP EPO0102
See also Acceptance Review
Scenario Description
A Reference Data price change (decrease in value of
stamp books) is effective from today. Clerk 3 uses the
manual revaluation process to re-value stock for this
product in Stock Unit 2, but makes a mistake when
entering the value. He reverses the transaction but forgets
to re-perform the revaluation with the correct value.
He also uses the manual revaluation process incorrectly to
re-value stock (increase in value) for a product (Airpacks)
that has not had a price change.
Clerk 3 attempts to balance Stock Unit 2 but is advised of
revaluation errors relating to stamp books and Airpacks.
He realises that he has overlooked the revaluation of
stamp books at the beginning of the day, and that he
should not have re-valued Airpacks since they have not
changed price . He uses the manual revaluation process
to re-value the stock of stamp books in Stock Unit 2, and
the reversal process to reverse the revaluation of
Airpacks. He then produces another balance snapshot.
Function Run Entry
Requirement Id 814
Criterion 1,2
Derivation Requirement
Criterion Description
EPOSS shall provide a function to record the value of
cash held in the Stock Unit by denomination for two
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 42 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
distinct purposes (a) as part of the Cash Flow Reporting
process (b) as part of the Stock Unit Balancing process.
The dialogue to record the information screen may be
common for both activities to avoid unnecessary
duplication when Balancing.
The Cash Flow/Balancing reporting process aspect of
EPOSS may be used at any time but is normally used
daily as part of the end of day activity.
HLTP / Business
Thread Scenario
Note: In the solution the information screen is NOT
common to both activities. There are two separate
routines, one “daily”, one “weekly” which can be used at
any time. Tested in both single counter and multi-counter
Offices.
(a) BT EPO01 3.3.2/4a,20 3.3.3/9 HLTP EPO0102+3
(b) BT EPO01 3.3.6/12 HLTP EPO0102+3
Scenario Description
(e) a)Manager 1 makes a zero cash on hand declaration in
Stock Unit 1, for inclusion in the office weekly Cash Flow
report. He also declares a start balance of zero cash for
this stock unit using the stock unit balancing cash
declaration procedure.
(f)
At the end of day, Clerk 1 produces a balance snapshot
for Stock Unit 1 which reflects the stock position and
activity during the day. He then declares the value of cash
on hand by denomination in Stock Unit 2, for inclusion in
the office weekly Cash Flow report. When he has finished
he realises that he has made a mistake during declaration,
so he re-declares the cash on hand and produces a
declaration report.
Clerk 1 declares and produces a report for cash on hand.
He then balances Stock Unit 2 and produces a trial
balance report. This shows no discrepancies
b)Manager 1 produces the office weekly Cash Flow report.
Function Run Entry
Requirement Id 814
Criterion 3
Derivation Requirement
Criterion Description
The EPOSS shall allow entry by cash value for each
denomination and total value declared (EPOSS validating
each field entry as numeric). The total entered is used in
the Stock Unit Balance Report and the difference between
this total and the EPOSS maintained figure for the cash
Method of Payment Stock value generates a loss or gain.
HLTP / Business
BT EPO01 3.3.4/12 HLTP EPO0102
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 43 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Thread Scenario
See also 814/1 above
Scenario Description
Clerk 2 declares and produces reports for the actual
physical contents for stock (shared stock unit only),
stamps and cash in hand in Stock Unit 2. The system
reports that there is a discrepancy (a loss) between the
actual amounts declared, and that maintained by the
system. After investigation this loss is removed by re-
declaration.
Function Run Entry
Requirement Id 814
Criterion 4
Derivation Requirement
Criterion Description
The EPOSS maintained Stock value for the cash Method
of Payment is not altered during the process. The User is
advised of any discrepancy to warn of potential errors and
(in Balancing) the implied balancing loss or gain.
HLTP / Business
Thread Scenario
BT EPO01 3.3.2/20 HLTP EPO0102
See also 814/1 above
Scenario Description
At the end of day, Clerk 1 produces a balance snapshot
for Stock Unit 1 which reflects the stock position and
activity during the day. He then declares the value of cash
on hand by denomination in Stock Unit 2, for inclusion in
the office weekly Cash Flow report. When he has finished
the system informs him of a discrepancy between the total
cash amount entered and the system held balance
holding. After checking he re-declares the correct amount
of cash on hand and produces a declaration report
Function Run Entry
Requirement Id 814
Criterion 5
Derivation Requirement
Criterion Description
A zero cash holding is declared by using the function in
the normal way and confirming zero entries
HLTP / Business
Thread Scenario
BT EPO01 3.3.2/4a HLTP EPO0102
Scenario Description
Manager 1 makes a zero cash on hand declaration in
Stock Unit 1, for inclusion in the office weekly Cash Flow
report. He also declares a start balance of zero cash for
this stock unit using the stock unit balancing cash
declaration procedure.
Function Run Entry
I Requirement Id
[814
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 44 of 134
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
fi H Version: 4.0
Acceptance Specification Date: 18/12/98
Criterion 6
Derivation Requirement
Criterion Description
EPOSS shall allow the last known declaration to be
carried forward for Cash Flow reporting purposes where
no activity has occurred to change the last known cash
position. This is required to cater for rest days including
Outlets that shut on Saturdays etc
HLTP / Business
Thread Scenario
BT EPO01 3.3.10/15 HLTP EPO0102
Scenario Description
Manager 1 produces the office weekly Cash Flow report. A
daily cash holding for each stock unit has not been
declared for every day of the week so, for each missing
day, the report displays holdings from the most recent
declaration (including one from a previous CAP and one
from a previous cash flow reporting week).
Function Run Entry
Requirement Id 814
Criterion 7
Derivation Requirement
Criterion Description
In Outlets that Team Work EPOSS shall allow cash
declaration across all the Tills that contribute to the Stock
Unit position
HLTP / Business
Thread Scenario
HTLP EPO0103 is all performed in a multi -position outlet
with shared stock units in use. This functionality tested
repeatedly e.g. within BT EPO01 3.3.10/9, 15
Scenario Description
POSCO1/Clerk 1 and POSCO2/Supervisor 1. Enter Daily Cash On Hand, with each user
contributing his portion.
POSCO1/Manager 1. Produce an Office Weekly Cash Flow report
Cash Flow report shows consolidation of both users.
Function Run Entry
Requirement Id 815
Criterion 1,2,3
Derivation Requirement
Criterion Description
EPOSS shall allow a facility to bring unused Stock Units
(and their Stock Unit information) forward into the next
POCL Outlet Accounting Period.
An unused Stock Unit is one for which no activity has
taken place since its most recent final Balance.
This facility may be used at any time to ensure that all
Stock Units registered in an Outlet are recorded as fully
up to date, prior to producing the Cash Account for that
POCL Outlet Accounting Period.
HLTP / Business
Thread Scenario
BT EPO01 3.3.6/18a, 3.3.13/18 3.3.6/22HLTP EPO0102
See also Acceptance Review
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 45 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Scenario Description
Manager 1 attempts to roll Stock Unit 2 into the next CAP
using the “dormant” stock unit rollover procedure, but is
warned that activity has taken place for this stock unit
during the current CAP
Manager 1 rolls over Stock Units, including Stock Unit 3
that is not empty, that have remained dormant (i.e. have
had no traffic) during the current CAP.
Manager 1 attempts to roll over Stock Unit 4 that has
remained dormant during the current CAP into the next
CAP, but is warned by the system that there is an
outstanding transfer in. He reverses the pending transfer
and rolls the stock unit over.
Function Run Entry
Requirement Id 815
Criterion 4
Derivation Requirement
Criterion Description
The co-ordination of this activity is under the control of the
Outlet Manager
HLTP / Business
Thread Scenario
Scenario Description
This is a continuation of 815/1
Restriction of users to appropriate functions is
exhaustively tested during BT 3.3.1 For detail see 820/1
Function Run Entry
Requirement Id 816
Criterion 3
Derivation Requirement
Criterion Description
Outlets require record retrieval on demand for the
previous two (2) complete POCL Outlet Accounting
Periods. Older records shall be made available at 24
hours notice.
HLTP / Business
Thread Scenario
The retention period on the RIPOSTE message store is
currently set at 35 days.
BT EPO01 3.3.13/8 3.3.14/1b, 10 HLTP EPO0102
See also Acceptance Review
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 46 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
age A Version: 4.0
Acceptance Specification Date. 18/12/98
Scenario Description
Auditor 1 wishes to check the events that have taken
place at the outlet over the last three CAPs. He ...
produces a full range of event log reports to provide the
information.
Manager 1 produces a full range of transaction log reports
covering the previous 2 CAPs..
Manager 1 logs off . When he logs on again his stock unit
and the office are both working in the next CAP + 2. He
produces reprints of office reports for the previous
extended CAP.
Function Run Entry
Requirement Id 816
Criterion 4
Derivation Requirement
Criterion Description
EPOSS shall support the recording of all Events and data
entries including fallback and Recovery actions.
HLTP / Business
Thread Scenario
EPO01 BT 3.3.3/8
Scenario Description
Whilst Clerk 1 is adjusting stock in Stock Unit 2, there is a
power failure at the counter. When power is restored the
adjustments are lost and stock levels remain unchanged.
He produces an Event Log report which shows the
recovery events
See also 804 and 805 above
Function Run Entry
Requirement Id 816
Criterion 5
Derivation Requirement
Criterion Description
EPOSS requires entry of User identity and password to
access the Service.
HLTP / Business
Thread Scenario
EPOSS will implement a tiered level of access control.
Each facility will have an associated access level and the
user will require a corresponding (or better) privilege level
to access the facility. Combined with the user logon
requirement, this will provide a controlled environment for
all users of the system.
BT EPO01 3.3.1, 3.3.8/1¢
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 47 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
Scenario Description
Restriction of users to appropriate functions is
exhaustively tested during this thread. For detail see
820/1
Clerk 1 wishes to leave his counter temporarily in the
middle of a customer session. He applies a temporary
lock. On arrival back at the counter, he removes the lock
by providing his password. This returns him to the
customer session which he continues and settles.
Function Run Entry
Requirement Id 816
Criterion 6
Derivation Requirement
Criterion Description
Each facility within EPOSS shall have an associated User
authority level (clerk, supervisor, manager). EPOSS shall
also provide reasonable safeguards against accidental or
deliberate access by other than the normal means to
Software or data.
HLTP / Business
Thread Scenario
See 820/1
Wider aspects of security are covered by the Security AS
RC/ACS/002
Scenario Description
Function Run Entry
Requirement Id 816
Criterion 7
Derivation Requirement
Criterion Description
Within an Outlet there shall be a facility to maintain and
allocate a User access and privilege level log
HLTP / Business
Thread Scenario
Scenario Description I See 820/1
Function Run Entry
Requirement Id 817
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow discounting for all discountable POCL
Products. A list of discountable POCL Products shall be
maintained in Reference Data supplied by POCL
HLTP / Business
Thread Scenario
BT EPO01 - 3.3.4/3,4. HLTP EPO0102
Scenario Description
See 817/2 below. In the detail of the HTLP all
discounting scenarios are attempted, including attempting
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 48 of 134
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
to discount non-discountable items.
Function Run Entry
Requirement Id 817
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall allow discount by an entered percentage for
the last Transaction or for all discountable POCL Product
Transactions in the Customer Session
HLTP / Business
Thread Scenario
BT EPO01 - 3.3.4/3,4 HLTP EPO0102
Note: The facility to apply a “session discount’ will need to
be removed once the concept is proven as POCL
reporting requirements preclude the facility in live
operations for NR2
Scenario Description
Clerk 2 serves a staff member with a number of
discountable and non-discountable products. A discount
is given by percentage on one product and by fixed
amount on another product. At the end of the session the
staff member pays the balance with the correct amount of
cash, and the session is settled.
Clerk 2 serves a staff member with a number of
discountable and non-discountable products. At the end of
the session the clerk applies a percentage session
discount which is applied to all of the discountable
products sold. The staff member pays a sum greater than
the balance in cash and receives some change, and the
session is settled.
Function Run Entry
Requirement Id 817
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall allow discount by an entered value for the
last Transaction or for all discountable POCL Product
Transactions in the Customer Session
Note: The facility to apply a “session discount’ will need to
be removed once the concept is proven as POCL
reporting requirements preclude the facility in live
operations for NR2
HLTP / Business
Thread Scenario
BT EPO01 - 3.3.4/3,4a HLTP EPO0102
Scenario Description
See 817/2 above
Clerk 2 serves a staff member with a number of
discountable and non-discountable products. At the end of
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 49 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
the session the clerk applies a fixed amount session
discount which is applied to all of the discountable
products sold. The staff member pays the balance in cash,
and the session is settled
Function Run Entry
Requirement Id 818
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall provide a facility to update Reference Data
files with Reference Data supplied from the POCL
Reference Data System.
HLTP / Business
Thread Scenario
BT RDSO1
Scenario Description
This is the subject of the whole of RDS01 (31)
Function Run Entry
Requirement Id 818
Criterion 2
Derivation Requirement
Criterion Description
It shall be possible for a date and time stamp to be applied
to Reference Data identifying when the change is to be
activated, to facilitate timely price changing.
HLTP / Business
Thread Scenario
BT EPO01 3.3.8/1a, 3.3.9/1b HLTP EPO0102
Scenario Description
Overnight, the system has detected that Reference Data
price changes (including changes to philatelic stamps,
discounted stamps and postal order fees) are to take
effect from the start of Day 3 of CAP 2. When Clerk 1 logs
on to the system he is informed that this will take place,
and a report detailing the changes is produced.
Reference Data price changes (including changes to
philatelic items, discounted stamps and postal order fees)
are effective from today. Clerk 1 uses the manual
revaluation process to re-value stock for these products in
Stock Unit 2.
Function Run Entry
Requirement Id 818
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall allow the Reference Data content to be
presented as a locally produced Report, with changes
made in Reference Data by the most recent update clearly
identified
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 50 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
Fi i ersion:
Acceptance Specification Date: 18/12/98
HLTP / Business BT EPO01 3.3.14/1c HLTP EPO0102
Thread Scenario
Scenario Description
Manager 1 produces a product report to provide details of
recent reference data changes made to items available at
the outlet.
Function Run Entry
Requirement Id 818
Criterion 4
Derivation Requirement
Criterion Description
When an update to Reference Data is made, each
affected local Outlet shall be warned by EPOSS at the
start of the next POCL Core Day that a change has been
made
HLTP / Business
Thread Scenario
BT EPO01 3.3.8/1a HLTP EPO0102
The requirement has been clarified to refer to only
product/price changes.
Scenario Description
Overnight, the system has detected that Reference Data
price changes (including changes to philatelic stamps,
discounted stamps and postal order fees) are to take
effect from the start of Day 3 of CAP 2. When Clerk 1 logs
on to the system he is informed that this will take place,
and a report detailing the changes is produced.
Function Run Entry
Requirement Id 818
Criterion 9
Derivation R821/FS 4.1.3.1.1
Criterion Description
Reference Data shall also define the availability of specific
POCL Products in each Outlet. Such availability shall be
controlled centrally, and an Outlet shall not be able to
modify such data.
HLTP / Business
Thread Scenario
There is no facility to modify reference data locally.
BT EPO01 3.3.4/5 HLTP EPO0102
Note: distribution of ref data is tested in the Ref Data AS
Scenario Description
Clerk 2 serves a number of customers with a variety of
products, settling with a variety of methods of payment.
Within this attempts are made to sell products defined in
reference data to be not available at the outlet.
Function Run Entry
Requirement Id 819
Criterion 4
Derivation Requirement
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 51 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
Criterion Description
Under certain authorised circumstances an authorised
Outlet may produce one Cash Account to span a 2 or 3
week period and this must be managed by EPOSS. Within
this variation there is a requirement to correctly associate
the week number with a specific Transaction according to
a Client's requirements. This is one of either:
the week in which the Transaction took place or;
b) the final week in which the Cash Account is produced.
HLTP / Business
Thread Scenario
BT EPO01 3.3.14/1. HLTP EPO0102
Scenario Description
Manager 1 wishes to extend the current CAP to a “3-week”
period. He uses the Extended CAP facility to set the
period to the next CAP + 2.
Function Run Entry
Requirement Id 819
Criterion 6
Derivation Requirement
Criterion Description
EPOSS shall allow Users to produce trial Outlet Cash
Accounts
HLTP / Business
Thread Scenario
BT EPO01 3.3.6/23c HLTP EPO0102
Scenario Description
Manager 1_ produces a trial Cash Account Report.
Function Run Entry
Requirement Id 819
Criterion 7
Derivation Requirement
Criterion Description
EPOSS shall provide a facility to move forward into the
next POCL Outlet Accounting Period once a final Cash
Account has been produced
HLTP / Business
Thread Scenario
BT EPO01 3.3.6/24 HLTP EPO0102
Scenario Description
Manager 1 rolls over the office into the next CAP. This is
on the actual day that the Post Office cash account
calendar stipulates. Two copies of the final Cash Account
report are automatically produced.
Note that there is only one step - rolling the CAP produces
the Final cash account. A Final cash account cannot be
obtained other than by rolling the CAP
Function Run Entry
Requirement Id 820
Criterion 1
Derivation Requirement
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 52 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
Criterion Description I EPOSS shall provide a means of controlling user access
to its data, processes and functions.
HLTP / Business
Thread Scenario
Access controls are tested throughout the business thread
BT EPO01, most particularly in 3.3.1/1-27.
Also 3.3.2/1, EPO0103 (for session transfer)
See also response to 473/2
Scenario At each point in the test thread set out below the system actions are
Description I checked for consistency with the Horizon OPS Menu Hierarchy (29)
The default “Setup level” user logs on to the system. He is restricted to
performing functions appropriate to his role (as defined in (29)). He creates a
“Manager level user” Manager 1 for the outlet.
Manager 1 logs on to the system for the first time and is forced to amend his
initial password. He is attached to the Default Stock Unit.
Manager 1 creates Stock Unit 1.
Manager 1 changes his attachment from the Default Stock Unit to Stock Unit
1. He is restricted to performing functions appropriate to his role (as defined in
(29)) and functions allowable only on the default stock unit.
Manager 1 adds other users with different access role types to the system, viz
Supervisor 1 and Clerk 1. He attaches the users to Stock Unit 1.
Supervisor 1 logs on to the system for the first time and is forced to amend
his initial password. He is restricted to performing functions appropriate to his
role (as defined in (29)).
Clerk 1 logs on to the system for the first time and is forced to amend his
initial password. He is restricted to performing functions appropriate to his role
(as defined in (29)).
Support Engineer 1 uses the default “Engineer User” to gain access to the
system. Whilst logging on to the system, he verbally authenticates himself to
the Horizon System Help Desk with an encrypted key generated by the
system. The Help Desk then notifies him verbally of a one-shot key which
allows him entry to the system when keyed in. He is restricted to performing
functions appropriate to his role (as defined in (29)). After logging out he can
no longer gain access to the system.
Migration User 1 uses the default “Migration User” to gain access to the
system. Whilst logging on to the system, he verbally authenticates himself to
the Horizon System Help Desk with an encrypted key generated by the
system. The Help Desk then notifies him verbally of a one-shot key which
allows him entry to the system when keyed in. He is restricted to performing
functions appropriate to his role (as defined in (29)). After logging out he can
no longer gain access to the system.
Support User 1 uses the default “Support User” to gain access to the system.
Whilst logging on to the system, he verbally authenticates himself to the
Horizon System Help Desk with an encrypted key generated by the system.
The Help Desk then notifies him verbally of a one-shot key which allows him
entry to the system when keyed in. He is restricted to performing functions
appropriate to his role (as defined in (29)). After logging out he can no longer
gain access to the system.
Auditor 1 uses the default “Auditor User” to gain access to the system. Whilst
logging on to the system, he verbally authenticates himself to the Horizon
System Help Desk with an encrypted key generated by the system. The Help
Desk then notifies him verbally of a one-shot key which allows him entry to
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 53 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
e@ the system when keyed in. He is restricted to performing functions appropriate
to his role (as defined in (29)). After logging out he can no longer gain access
to the system.
@ Emergency Manager 1 uses the default “Emergency Manager User” to gain
access to the system. Whilst logging on to the system, he verbally
authenticates himself to the Horizon System Help Desk with an encrypted key
generated by the system. The Help Desk then notifies him verbally of a one-
shot key which allows him entry to the system when keyed in. He is restricted
to performing functions appropriate to his role (as defined in (29)). After
logging out he can no longer gain access to the system.
e Manager 1 forgets his password. He uses the default “Support User” to gain
access to the system to change his password to a new value. Whilst logging
on as Support User 2 to the system, he verbally authenticates himself to the
Horizon System Help Desk with an encrypted key generated by the system.
The Help Desk then notifies him verbally of a one-shot key which allows him
entry to the system when keyed in. After logging out he can no longer gain
access to the system as Support User 2, but is able to log on as Manager 1
again using his new password.
e Supervisor 1’s system held details require amendment. Manager 1 changes
the details.
Supervisor 1 forgets his password. Manager 1 changes his old password to a
new value. When the supervisor logs on again he is prompted for the new
password which allows him entry to the system.
e Supervisor 1 logs on to the system after the system pre-determined time
when a user is required to change his password. He is forced to amend his
password before being allowed entry to the system.
e Supervisor 1 wishes to change his own password to the system. He uses the
administration facility to do so. When he next logs on he is prompted for the
new password which allows him entry to the system.
e Supervisor 1 is to be stopped from using the system. Manager 1 amends the
user to disable him so that he is unable to log on to the system.
@ Supervisor 1 who is disabled from using the system is to be allowed to use the
system again. Manager 1 amends the user to enable him to do so, and he is
able to log on again.
e Supervisor 1 attempts to log on to the system with an invalid password a
number of times in succession until the system-imposed limit is reached. He
becomes locked out of the system so Manager 1 has to unlock him. He is
then able to log on again using his correct password.
e Another stock unit is required. Manager 1 creates Stock Unit 2.
e Clerk 1 is to be given supervisor responsibilities. Manager 1 amends his
access role to give him the required authority, and changes his attachment
from Stock Unit 1 to Stock Unit 2. When Clerk 1 next logs on he has access
to supervisor functions
e Auditor 1 gains access to the system again using the one-shot key procedure
and produces an Event Log of events that have occurred during the day.
e@ Supervisor 1 and Clerk 1 no longer work in the outlet. Manager 1 attaches
them to the Default Stock Unit and deletes them from the system.
e Stock Unit 2 is no longer required in the outlet. Manager 1 deletes it from the
system.
e@ Manager 1 changes his attachment from Stock Unit 1 to the Default Stock
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 54 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
fi H Version: 4.0
Acceptance Specification Date: 18/12/98
© Unit.
e@ Manager 1 leaves his counter inactive for longer than the system imposed
period after which temporary lock occurs.
@ Manager 1 leaves his counter inactive for longer than the system imposed
period after which forced logoff occurs.
PO5C01/Manager 1. Transfer a newly logged on session to
POS5C02. Transfer the session back to POS5C01.
Function Run Entry
Requirement Id 820
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall include fallback procedures for situations
where the User cannot use the POCL Service
Infrastructure for any reason. These facilities shall
maintain the integrity, security and levels of Customer
Service consistent with the need to maintain trading.
HLTP / Business
Thread Scenario
There are many tests throughout the business thread
simulating power failures and LAN disconnects.
e.g. BT EPO01 3.3.3/3, 3.3.14/5 HLTP EPO0103
See also Acceptance Review
Scenario Description
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment
Manager 1 performs an office balance and produces an
office trial balance report. The report shows no
discrepancies, and the Payments total is found to be equal
to the Receipts total. warning displayed re disconnect counter. Trial Balance
Report printed
Function Run Entry
Requirement Id 820
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall ensure that, following an Incident, or if
operationally desirable for any other reason:
(a) the user can return to a complete and recent position;
(b) no corruption of secured data has occurred;
(c) a full recovery can be effected swiftly and in an
auditable manner.
HLTP / Business
Thread Scenario
There are many tests throughout the business thread
simulating power failures and LAN disconnects.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 55 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
e.g. BT EPO01 3.3.2/7 HLTP_EPO0101
Scenario Description
Whilst Manager 1 is remitting items into Stock Unit 1,
there is a power failure at the counter. When power is
restored the remittance session is lost and stock levels
remain unchanged.
Function Run Entry
Requirement Id 820
Criterion 4
Derivation Requirement
Criterion Description
EPOSS shall back up Stock Unit and Outlet data in order
to support the ability to return to a recent known position
for fallback and Recovery. Depending on the specific
solution, there may be times within the Cash Account
cycle (pre/post Cash Account roll over) when local control
of back up is required.
HLTP / Business
Thread Scenario
Solution: Backup of data will be handled by the data
replication facilities of the TMS/Journalising middleware.
This will allow seamless recovery from Incidents such as
localised failure. A return to a known and trusted
reference position will be provided by the setting of
appropriate data markers.
Tested extensively in Technical Integrity and Networking
HLTP (21)
Also there are many tests throughout the business thread
simulating power failures and LAN disconnects.
e.g. BT EPO01 3.3.2/7 HLTP EPO0102
The specific solution (using Riposte) does not require the
local control of backup.
Scenario Description
Whilst Manager 1 is remitting items into Stock Unit 1,
there is a power failure at the counter. When power is
restored the remittance session is lost and stock levels
remain unchanged.
Function Run Entry
Requirement Id 820
Criterion 5
Derivation Requirement
Criterion Description
EPOSS shall allow Recovery of data to a known recent
position. This includes both the Outlet and individual
Stock Unit data where necessary to maintain integrity of
the EPOSS. Recovery should not itself constitute a risk
e.g. a one shot only option. Thus in the event of a power
down / power interruption during a Recovery activity
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 56 of 134
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O08
iF i, i, ersion: .
Acceptance Specification Date. 18/12/98
further Recovery attempts can be made later
HLTP / Business Technical Integrity and Networking HLTP (21)
Thread Scenario
Tests 10.1.1/1-4
Tests 10.2.1/1-4
Scenario Description
Tests on single counter outlet
Tests on multiple counter outlet
Function Run Entry
Requirement Id 820
Criterion 6
Derivation Requirement
Criterion Description
EPOSS shall ensure that the committal process for a
Transaction is robust and consistent across all
Transaction types so that an interruption does not result in
an unrecoverable error
HLTP / Business
Thread Scenario
There are many tests throughout the business thread
simulating power failures and LAN disconnects.
e.g. BT EPO01 3.3.2/7
Scenario Description
Whilst Manager 1 is remitting items into Stock Unit 1,
there is a power failure at the counter. When power is
restored the remittance session is lost and stock levels
remain unchanged.
Also Technical Integrity and Networking HLTP (21) is
concerned with this.
HLTP BPRO101 (52) extensively covers the requirement
for testing of counter reconciliation subsequent to fallback
and recovery modes for BES transactions.
Re APS: this criterion duplicates 554/3,4 which is covered
by the APS AS.
Function Run Entry
Requirement Id 820
Criterion 7
Derivation Requirement
Criterion Description
EPOSS shall ensure that in the event of a failure of any
part of the Service Infrastructure, Recovery can be
performed to a known position and with the minimum of
disruption to the User. Data re-entry shall be minimal
where previously committed Transactions have to be re-
entered
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 57 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref. CR/ACS/008
tee ge Version: 4.0
Acceptance Specification Date. 18/12/98
HLTP / Business
Thread Scenario
EPO01 3.3.9/1c,2,3 for testing of bulk entry facility.
See also the Technical Integrity and Networking HLTP
(21) which exhaustively tests Infrastructure resilience.
See also 820/4
Scenario Description
A counter is out of action so Clerk 1 keeps manual totals
of different products and services sold, together with totals
for different Methods of Payment used, until the counter is
back in action. When the counter is working again, he
uses the Bulk Entry facility to key the values in to the
system
Whilst Clerk 1 is using the Bulk Entry facility, there is a
power failure at the counter. When power is restored the
Bulk Entry session is lost and stock levels remain
unchanged.
Whilst using the Bulk Entry facility, Clerk 1 has
accidentally selected an incorrect product. He voids this
individual item, then continues and completes the Bulk
Entry session
Function Run Entry
Requirement Id 820
Criterion 8
Derivation Requirement
Criterion Description
EPOSS shall warn the User where there is the possibility
that data are corrupt
HLTP / Business
Thread Scenario
BT EPO01, HLTP EPO0102
3.3.11/1a; 3.3.13/1 - early/late CAP
3.3.6/14b - revaluation errors
3.3.6/16 - negative stock
3.3.6/23 - parcel traffic
3.3.13/15 - receipts not equal to payments
Scenario Description
sees When Clerk 1 logs on to the system he receives a warning that
the stock unit Cash Account Period is ahead of that stipulated in the
Post Office cash account calendar. :
When Clerk 1 logs on to the system he receives a warning that the
stock unit Cash Account Period is behind that stipulated in the Post
Office cash account calendar.........
Clerk 3 attempts to balance Stock Unit 2 but is advised of revaluation
errors relating to stamp books and Airpacks. He realises that he has
overlooked the revaluation of stamp books at the beginning of the
day, and that he should not have re-valued Airpacks since they have
not changed price . He uses the manual revaluation process to re-
value the stock of stamp books in Stock Unit 2, and the reversal
process to reverse the revaluation of Airpacks. He then produces
another balance snapshot
Clerk 3 attempts to balance Stock Unit 2 but is advised that there is
negative stock. He adjusts the stock to correct this, makes a re-
declaration and produces a trial balance report........
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 58 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref. CR/ACS/008
fi 4 Version: 4.0
Acceptance Specification Date. 18/12/98
Manager 1 attempts to perform an office balance but is advised that
there have been no Parcel Traffic transactions during the current
CAP. After investigation this is found to be correct so he continues
with the office balance
Clerk 1 balances Stock Unit 2 and attempts to produce a trial balance
report but the system prevents continuation, warning that the Receipts
total is not equal to the Payments total. The reason is found to be due
to the sale of an incorrectly defined product. The errant transaction is
reversed and the trial balance is then produced and shows no
discrepancies.
Note, Physical data integrity is dealt with by the OPS
rather than EPOSS. In this sense the requirement is a sub-
set of criterion 472/2, which is dealt with in the POCL
Infrastructure ATS
Function Run Entry
Requirement Id 823
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall make Transaction and process data
captured through EPOSS available to any Service
delivered through the medium of the OPS and specified by
POCL as requiring access to data.
HLTP / Business BITO3 case 131
Thread Scenario
Scenario Description I See 960/3
Function Run Entry
Requirement Id 823
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall ensure that in the event of an Incident, data
integrity is maintained and that no corruption of data is
introduced arising from the interruption of any
uncompleted activity.
HLTP / Business
Thread Scenario
There are many tests throughout the business thread
e.g. BT EPO01 3.3.2/7 HLTP EPO0102
This requirement is a subset of 830/1
See also Pathway Release 2 Technical Integrity and
Networking HLTP (21) for extensive testing of failure
scenarios.
Scenario Description
Whilst Manager 1 is remitting items into Stock Unit 1,
there is a power failure at the counter. When power is
restored the remittance session is lost and stock levels
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 59 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
EPOSS Ref.: CR/ACS/008
age A Version: 4.0
Acceptance Specification Date. 18/12/98
remain unchanged.
Function Run Entry
Requirement Id 824
Criterion 1
Derivation Requirement
Criterion Description
Where an Outlet has electronic scales connected to the
OPS, EPOSS shall provide the price for a particular
weight of package (provided by the scales), with the
contention being handled by the scales accepting or
denying a connection by a counter terminal
HLTP / Business
Thread Scenario
HTLP EPO0103 within BT 3.3.12/1 at 97.4.3.11 /0:15:00
See also 824/2
Scenario Description
Attempt to perform a weighed mail item transaction on a
set of shared scales by pressing the 'scales' buttons
simultaneously.
Function Run Entry
Requirement Id 824
Criterion 2
Derivation Requirement
Criterion Description
The OPS shall request the scales only when needed and
can only proceed with the scales associated Service if the
scales accepts its request. The OPS shall release the
scales as soon as it has finished with them.
HLTP / Business
Thread Scenario
3.3.12/1,1a
HTLP VI/TSC/105 Technical Integrity and Networking.
A) 10.4.5.1 to 10.4.5.3
See also 555/9
Scenario Description
Clerk 1 serves a customer who is sending a mail item. The
counter scales are working, so the item is placed on them
to provide its weight to the system. The clerk then selects
the destination and service required for the item, and
settles the session.
Clerk 1 serves a customer who is sending a mail item. The
counter scales are working but are shared and are in use
at another counter, so the item is weighed on a separate
manual scales. The clerk then provides this weight to the
system, selects the destination and service required for
the item, and settles the session
Weighscales - testing to validate the correct operation of
weigh scales accessed by more than one counter system.
Function Run Entry
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 60 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 825
Criterion 1
Derivation Requirement
Criterion Description I EPOSS shall provide a function to record all sales
HLTP / Business
Thread Scenario This duplicates 694/1
Scenario Description
Function Run Entry
Requirement Id 825
Criterion 3
Derivation Requirement
Criterion Description
All counter Transactions shall be associated with a
Customer Session. Multiple Transactions for the same
Customer shall be logically grouped into a single
Customer Session.
HLTP / Business
Thread Scenario
All Transaction entered in Serve Customer mode are
associated with a customer session. Transactions entered
in other modes are recorded (as required by 807/2) ina
Transaction Session similar to a Customer Session.
Grouping of multiple transactions is dealt with in 800/4.
Scenario Description
Function Run Entry
Requirement Id 825
Criterion 5
Derivation Requirement
Criterion Description
Within a customer session, EPOSS will maintain:
(a) a running record of all transactions performed;
(b) the current balance;
(c) the accounting sense (pay out/take in);
(d) settlement details.
HLTP / Business
Thread Scenario
This can be observed on screen at many places during
testing. E.g. BT EPO01 3.3.3/3 HLTP_EPO0102
Scenario Description
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment.
During the test it will be observed that the session balance
is correctly incremented at each step.
Function Run Entry
Requirement Id 825
Criterion 6
Derivation Requirement
Criterion Description
EPOSS must accept single or multiple methods of
payment as settlement.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 61 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
Fi i ersion:
Acceptance Specification Date: 18/12/98
HLTP / Business
Thread Scenario
Scenario Description
This requirement duplicates 692/1
Function Run Entry
Requirement Id 825
Criterion 8
Derivation Requirement
Criterion Description
EPOSS shall allow a Customer Session to be suspended
and then recalled for completion at a later date. In
between the User shall be able to continue to enter and
complete further sessions as required
HLTP / Business
Thread Scenario
BT EP01 3.3.7/3 HLTP EPO0102
Scenario Description
Whilst serving a customer with a number of products,
Clerk 1 wishes to serve another customer at the same
time. He suspends the first customer session. Another
customer is then served and his session is settled. Finally,
the session for the first customer is returned to, continued
and settled.
Function Run Entry
Requirement Id 825
Criterion 9
Derivation Requirement
Criterion Description
EPOSS shall provide a "Void" transaction facility.
EPOSS shall enable the use of this facility for certain
Transactions to be prohibited according to defined Client
and POCL accounting and business rules
HLTP / Business
Thread Scenario
Transactions are voided at several points in the testing,
for example BT EPO01 3.3.2/17,17a
BT EPO01 3.3.2/18,18a
Scenario Description
A customer decides, after having requested the purchase
of various products (including a TV licence) and before
settling, that he no longer wishes to purchase anything.
Clerk 1 at his counter voids each transaction, thereby
abandoning the session
A customer decides, after having requested the purchase
of various products (including a TV licence) and before
settling, that he no longer wishes to purchase anything.
Clerk 1 at his counter voids each transaction, but forgets
to void a TV stamp redemption and continues serving
another customer with a number of products (that do not
include a TV licence). The system will not allow the
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 62 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
session to be settled because of the TV stamp redemption
present without a TV licence sale from the previous
customer. The clerk voids this and then settles the
session, producing a receipt (which does not show the
voided transactions).
Clerk 1 serves a number of customers with a variety of
products (including postal orders), One customer requests
a non-voidable item to be voided, but the system will not
allow this. The clerk settles the sessions with a variety of
methods of payment.
Clerk 1 produces a transaction log showing customer
sales transactions performed during the day. Voided
transactions are not shown.
Function Run Entry
Requirement Id 825
Criterion 11
Derivation Requirement
Criterion Description
Some POCL Products are linked and shall remain so
within a Transaction, including for Refund/Reversal or
voiding purposes, for example a postal order of £1.00 has,
currently, an Associated Fee of 25 pence. As part of this
linkage, certain Stock Items with no current price shall be
re-classified as Value Stock Stock Items e.g. tax discs
HLTP / Business
Thread Scenario
Void of Postal Order done in BT EPO01 3.3.2/17
Sale of Postal Order done in BT EPO01 3.3.3/3
Reversal of Postal Order sale done in BT EPOO1
3.3.4/2,3a
HLTP EPO0102
Void of a discounted item done in BT EPO01 3.3.4/3
Scenario Description
A customer decides, after having requested the purchase of
various products (including a TV licence) and before settling,
that he no longer wishes to purchase anything. Clerk 1 at his
counter voids each transaction, but forgets to void a TV stamp
redemption.
Clerk 1 serves a customer with a number of products (that do
not include a TV licence). The system will not allow the session
to be settled because of the TV stamp redemption present
without a TV licence sale from the previous customer. The clerk
voids this and then settles the session.
Clerk 1 serves a number of customers with a variety of
products, settling with a variety of methods of payment.
A customer who was served on a previous day within the same
Cash Account Period returns to the outlet and requests a
refund. Clerk 2 obtains the transaction reference numbers
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 63 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
from the transaction log and reverses the transactions. The
customer is refunded.
A staff member wishes to have a refund on a discounted item
from a session that has already been settled. Clerk 2 obtains
the relevant transaction reference number from the Transaction
Log and reverses the transaction. The customer is refunded
Clerk 2 serves a staff member with a number of discountable
and non-discountable products. A discount is given by
percentage on one product and by fixed amount on another
product. Note: within this a discounted product is voided and it
is checked that the discount automatically voids.
Function Run Entry
Requirement Id 825
Criterion 13
Derivation Requirement
Criterion Description
EPOSS must allow the input of weight values where
scales are not linked.
HLTP / Business
Thread Scenario
Scenario Description
This requirement duplicates 694/3
Function Run Entry
Requirement Id 833
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall provide a training mode to allow
familiarisation with the package and shall operate in such
a way as to preclude any corruption of live data.
HLTP / Business
Thread Scenario
Scenario Description
Training mode is provided as a copy of the live system.
The functionality is thus identical to the live system except
that it does not produce output for harvesting and Riposte
does not replicate to other counters. BT TRA0O1 tests
training mode functionality.
Requirement not to corrupt live data duplicates
requirement 533/1
Function Run Entry
Requirement Id 835
Criterion 1
Derivation Requirement
Criterion Description
Benefits encashment and other automated Transactions
shall be integrated with the Transaction recording
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 64 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
elements of EPOSS such that there is no necessity to
separately notify the EPOSS of the Transaction.
HLTP / Business
Thread Scenario
HLTP TPSO0101 (49)
Scenario Description
PO2, SH2; Print EPOSS Transaction Log containing BES
(zero and +ve), EPOSS, APS & OBCS transactions.
Observe that no extra steps were taken over and above
executing the transactions to effect their recording in the
EPOSS system.
Function Run Entry
97/3/30 19.30
Requirement Id 835
Criterion 3
Derivation Requirement
Criterion Description
Benefits encashment and other automated Transactions
shall be integrated with the Transaction recording
elements of EPOSS such that Transaction Records
created and stored locally shall be entirely consistent with
any data transferred at the time of the Transaction to PAS
or other systems outside the POCL Service Infrastructure
HLTP / Business
Thread Scenario
Scenario Description
This is a sub-set of requirement 891 (Reconciliation)
which is covered by the Reconciliation ATS.
Function Run Entry
Requirement Id 835
Criterion 7
Derivation Requirement
Criterion Description
EPOSS shall be capable of providing summaries of any
type of Transaction for comparison with physical Records
contained within the Outlet. For example EPOSS shall be
able to list and total cheques accepted by value
HLTP / Business
Thread Scenario
BT EPO01 3.3.3/4
HLTP EPO0102
See also Acceptance Review
Scenario Description
Clerk 3 produces counter daily Client Summary reports.
These are used for checking against manually collated
batches of client vouchers
here produce a range of reports including:
Produce a Counter Daily Cheques Listing report
Function Run Entry
Requirement Id
835
Criterion
8
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 65 of 134
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
fi H Version: 4.0
Acceptance Specification Date: 18/12/98
Derivation Requirement
Criterion Description
The system must be able to list and total benefits
transactions made via BES for comparison against
physical records (outlet copy of receipts)
HLTP / Business
Thread Scenario
HLTP BPS1001 (BT 2)
See also Acceptance Review
Scenario Description
PO clerk selects the 'Daily' Report from the Summary Of
Encashments screen via the Desktop menu. This provides
a summary of the encashment receipts on a daily basis at
the PO.
Function Run Entry 18:35:00
Requirement Id 836
Criterion 3 (a-e,g)
Derivation Requirement
Criterion Description
For each Transaction processed at a Counter Position
through the POCL Service Infrastructure the following
information shall be captured:
a) value of each Transaction;
b) volumes of Transactions;
c) a unique code for each POCL Product across all Clients
(e.g. breakdown by denomination of Royal Mail stamps
sold);
d) source (e.g. Outlet, User and Till identification);
e) Client reference and Client scheme or product
reference
for each Transaction;
f) (see 5.2) Customer identification and details (e.g. for
Transactions involving cheques,
passports, motor tax discs);
g) Method of Payment; date and time of the Transaction.
HLTP / Business
Thread Scenario
Printing a combination of session receipt and transaction logs proves
that all the above data has been captured.
BT EPO01 3.3.2/18,18a
BIT tests (see below)
Scenario Description
Clerk 1 serves a number of customers with a variety of
products (including postal orders), One customer requests
a non-voidable item to be voided, but the system will not
allow this. The clerk settles the sessions with a variety of
methods of payment, producing a receipt.
Clerk 1 produces a transaction log showing customer
sales transactions performed during the day. Voided
transactions are not shown.
APS Transaction - 12/02/97.
APS TRANSACTIONS
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 66 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
Customer B hands the Clerk a BT Payment Plan ( Magcard ) &
pays £50.00 towards his bill
BT Payment Plan ( Magcard )
Customer Receipt and duplicate counter receipt produced
The customer asks for a 2 x Littlewood Scratchies
From Serve Customer menu, Clerk selects 2 x Littlewood
Scratchies
Clerk ends session and session receipt is printed. (When PO
Sales Transaction or OBCS & TT encashment, navigate to the
Functions menu to produce a customer receipt with unique
identifier
BES Transaction - BT000002 10/02/97.
FPO ENCASHMENT & TRANSACTION
Swipe Customer B benefit card for FPO encashment
Customer encashment of benefit at FPO
Customer answers EVP questions correctly for benefit
encashment
Clerk ends session and session receipt is printed. (When PO
Sales Transaction or OBCS & TT encashment, navigate to the
Functions menu to produce a customer receipt with unique
identifier
From the Reports icon, select the Transaction Log icon & print
the following;
Customer Query
Summary Query
Function Run Entry
Requirement Id 837
Criterion 9
Derivation Requirement
Criterion Description
EPOSS shall be able to deliver Reports at the User's
discretion, subject to POCL and Client rules on frequency
of despatch and POCL Outlet Accounting Periods. Client
Reports shall be produced on a daily or weekly basis.
Where operationally appropriate, several weekly Reports
shall be produced during a POCL Outlet Accounting
Period
HLTP / Business
Thread Scenario
BT EPO01 EPO0102
3.3.2/16a,19 (daily with & without cut-off)
3.3.3/4; 3.3.4/6; 3.3.6/3 (weekly with & without cut-off)
See also Acceptance Review
Scenario Description
Each of these threads apart from the last reads:
Clerk 1 produces counter daily transaction summary
reports. Client summaries are used for checking against
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Page 67 of 134
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
manually collated batches of client vouchers.
Function Run Entry
Requirement Id 838
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall have the facility to allow input of Transaction
related data after the event for items required for
management information purposes (e.g. for Clients,
Agents pay) which may not impact on the Outlet Balance
e.g. Non-value Stock Stock Items, value recorded for
information only.
HLTP / Business
Thread Scenario
BT EPO01 3.3.10/1d, 3, 24c HLTP EPO0102
See also 960/1
Scenario Description
Clerk 1 has been keeping a manual tally of Non-
Accounting data items (e.g. International Registered mail
items, Standard Contract Inland parcels) handled. He uses
the Non-Accounting Data facility to register the quantities
of such items.
Clerk 1 has been keeping a manual tally of Parcel Traffic
items handled (e.g. Inland Stamped Parcels, International
Metered Parcels). He uses the Parcel Traffic facility to
register the quantities of such items.
Manager 1 produces a trial Cash Account report.
Function Run Entry
Requirement Id 915
Criterion 14
Derivation Requirement
Criterion Description
There shall be no degradation to any Transaction data in
the live Service Architecture as a result of accessing
localised training packages.
HLTP / Business
Thread Scenario
Scenario Description
This duplicates 533/1
Function Run Entry
Requirement Id 960
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow POCL to record various zero-value
Transactions to measure work done, for example for
various Royal Mail and Parcelforce activities and for
distribution of various forms, for example E111s. The
measurement of work may be for charging Clients, for
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 68 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
remunerating subpostmasters, for monitoring work done to
check assumptions in cases where the costs are
subsumed in other charges, and so forth. Potential
reasons for new zero-value Transactions might be to
provide data for Clients in support of Service Level
monitoring, for example recording Transaction times for
mail receipts.
HLTP / Business
Thread Scenario
BT EPO01 3.3.10/1d, 3, 24¢c HLTP EPO0102
See also 838/1
Scenario Description
Clerk 1 has been keeping a manual tally of Non-
Accounting data items (e.g. International Registered mail
items, Standard Contract Inland parcels) handled. He uses
the Non-Accounting Data facility to register the quantities
of such items.
Clerk 1 has been keeping a manual tally of Parcel Traffic
items handled (e.g. Inland Stamped Parcels, International
Metered Parcels). He uses the Parcel Traffic facility to
register the quantities of such items.
Manager 1 produces a trial Cash Account report.
Function Run Entry
Requirement Id 960
Criterion 2b,c
Derivation Requirement
Criterion Description
Automated zero value Transactions shall be reported
separately. Initially these shall be:
(b) benefit encashment Transactions, which may be zero
value for various reasons, e.g.:
« Customer terminates before signing the declaration,
perhaps as a quasi-enquiry;
e User terminates, perhaps if unsatisfied as to Customer
identity, etc.;
* no payment due;
*® no payment available at this Outlet (e.g. restricted
Outlet or Foreign Encashment);
e the Transaction is normally zero value, e.g. requested
change of Nominated Post Office;
(c) associated benefit Card Transactions, (if "automated"
with POCL sub-contracted to the CONTRACTOR as
"Client"), recording:
« receipt of batches of Cards into Outlets;
e returns of uncollected Cards;
e issuing of Cards to cardholders;
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 69 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
Fi i ersion:
Acceptance Specification Date: 18/12/98
HLTP / Business (a) BITO3 case 131
Thread Scenario
(b) BPS1001 BT B0002, BPS1001 BT7
Scenario Description
(c) see 960/3 for description
(b)
This case involves partial Batch reconciliation, with
completion later the same day.
During the production life of the batch all normal
acceptance and delivery status values are received from
Royal Mail Track and Trace.
The batch contains cards for 10 customers.
The batch reconciliation is commenced as a “non-urgent”
batch. After scanning of the first 5 cards, the reconciliation
is halted to allow the clerk to serve a customer. (Helpdesk
is used at this stage to confirm that the batch status is
“received”. Reconciliation is recommenced later - the clerk
first initiates the “Report” function which lists the batch
and associated cards with status as appropriate (i.e.
“received” and “in transit”).
The reconciliation is completed for all of the remaining
cards, and a report produced.
A customer receives a PUN which is chewed up by the
dog. The customer contacts the Helpdesk to arrange for
an exceptional PUN to be delivered immediately. This
PUN is taken to the NPO and the card is collected. Whilst
attempting to collect a payment that is due the customer
changes his mind and leaves the office. The transaction is
voided.
Function Run Entry
Requirement Id 960
Criterion 3
Derivation Requirement
Criterion Description
Particular aspects are:
(a) zero value BES Transactions shall be recorded on the
EPOSS Transaction log and included in data passed to
POCL's TIP system, as indicated in requirement 881 (nil-
value receipts);
(b) automated payments shall continue as now;
(c) extra automated Transactions, including zero-value
ones such as those indicated above for Card/book/receipt
movements shall be designed as POCL Products in the
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 70 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
normal way with normal Transaction controls and data
flows, including interfaces with POCL systems.
HLTP / Business
Thread Scenario BITO3 case 131
Scenario Ata single stock-unit office, a representative cross section of benefit
Description transactions are conducted for a range of payee types (including encashments
by beneficiary, appointee, alternative payee, permanent agent and by a casual
agent). These encashments include several with milk tokens as well as
encashments for which the office is the NPO, FPO and specified office for use
with a temporary token. At least one card and token are keyed manually and
one additional encashment transaction voided. The encashments include an
attempted collection which results in a nil receipt being produced.
For one of the encashments completed the customer comes back to the post
office and requests to return the money collected and for the transaction to be
voided. An attempted reversal of the BES transaction is attempted but can not
be completed.
An encashment summary report is produced at the end of the week, which
identifies the receipts/AtPs required for despatch and indicates the EPOSS
transaction identifier for each encashment. Transactions are forwarded to PAS
and TPS. The transaction details generated for transfer to CAPS and to TIP are
checked for consistency of transaction identifiers with the local encashment
summary report and for consistency of encashment details with the original
transactions. The nil receipt transaction that was completed is included in the
TIP output and the EPOSS transaction log.
Note: an AP transaction cannot be reversed (voided in the
terminology of the requirement) and there are no zero value AP
products
Function Run Entry _ I
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Page 71 of 134
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
5.1.2 Description of tests conducted by Acceptance Review
The table below shows which Acceptance criteria are to be met by Acceptance
Review. Acceptance Tests will use the versions of any relevant documents (as
referenced from section 0.2) contained in the approved version of the
Acceptance Specification.
Requirement Id 473
Criterion 2
Derivation Requirement
Criterion Description I Access to OPS and Services offered via OPS to staff
working in the Outlets shall be controlled by a mechanism,
conforming to the POCL Style Guide, offering multiple
access levels and providing specific identification of each
User
Test Condition Access conforms to the POCL Style Guide
Method Review of Style Guide
References (25) Pathway Horizon Office platform Style Guide
See also Acceptance trial
Phase Technical Test
Requirement Id 530
Criterion 1
Derivation Requirement
Criterion Description I If for any reason it is not possible to - or it is decided by
POCL not to - make EPOSS functionality immediately
available on commencement of Roll Out the Service
Infrastructure, BES/APT functionality shall be available
and operational with no adverse system or operational
impacts. In effect it shall be a requirement to isolate
EPOSS functionality so that it cannot inadvertently be
used/misused to the detriment of Customer service and
POCL accounting needs.
Test Condition Reference Data changes could be made to remove
unwanted products and hide EPOSS functionality from any
(or all) outlets. Alternatively the menu access to reach the
unwanted functionality could be locked, thus preventing
inadvertent use.
Method Inspection of the flexibility afforded by Reference data to
introduce (or remove) functionality.
Inspection of control afforded via the menu hierarchy
References (22) - Application Interface Specification Reference Data
to Pathway
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 72 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O08
iF i, i, ersion: .
Acceptance Specification Date. 18/12/98
(29) - Horizon OPS Menu Hierarchy for Release 2
Phase Technical Test
Requirement Id 555
Criterion 10
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support the printing of reports necessary to meet existing
Client commitments
Test Condition
Necessary reports are specified in a controlled document
Method Inspection of document
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 691
Criterion 5
Derivation SADD 4.1.3.3.2.7
Criterion Description
EPOSS shall provide the facility to manage and report on
the movement of Cash or Stock Items, either at Stock Unit
level within each Outlet, or at the level of transfers to and
from other locations external to each Outlet.
Test Condition
Stock and cash management facilities are defined in a
controlled document.
Reporting facilities are defined in a controlled document.
See also Acceptance Trial
Method Document inspection.
The detailed testing of management and reporting are
covered elsewhere in this document.
References (18) - EPOSS Functional Description
(16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 692
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall allow the implementation of new types of
Methods of Payment, including without limitation debit
cards and EFTPOS.
Test Condition
This is a statement of required capability.
Method
Inspection of documents to show that new types of
Methods of Payment, specifically including debit cards and
EFTPOS, are achievable through Reference Data
definition.
Note: this excludes, for example, the EFTPOSS service -
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 73 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O08
iF i, i, ersion: .
Acceptance Specification Date. 18/12/98
we can provide a method of payment to register payment
received by the service.
References (22) - AIS Reference Data to Pathway
(29) - Horizon OPS Menu Hierarchy for Release 2
Phase Technical Test
Requirement Id 692
Criterion 3
Derivation Requirement
Criterion Description
Pathway shall indicate their proposals to implement an
EFTPOS Service. Pathway shall be aware that POCL may
wish to implement an EFTPOS Service commencing the
first quarter of 1997
Test Condition
Pathway have indicated their proposals
Method Document Inspection
References (15) - EFTPOS Statement of Requirement
Phase Technical Test
Requirement Id 693
Criterion 3
Derivation Requirement
Criterion Description
The CONTRACTOR shall agree the format of all styles of
receipts with POCL by a date consistent with the project
plan agreed by the parties, such that the date does not
adversely impact contractual milestones as defined in
Clause 605.1 of the Authorities Agreement.
Test Condition
The formats of all receipts are defined in a Controlled
Document.
Method Inspection of document to show it is agreed.
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 694
Criterion 4
Derivation Requirement
Criterion Description
4) EPOSS shall be event driven so that both data capture
and the recording of Services are dynamic (e.g. the
swiping of a magnetic stripe card initiates the
Transaction).
Test Condition
Method
This duplicates Requirement 825/2
References
Phase
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 74 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 695
Criterion 4
Derivation Requirement
Criterion Description
The CONTRACTOR shall be aware that Stock Units are
individual units of accountability which contain Stock (fixed
price Stock Items, Customer and Client specific Tokens,
retail Stock Items, cash and Transaction Vouchers for a
POCL Outlet Accounting Period
Test Condition
Contractor is aware. This view underlies the system
design.
Method Inspection of EPOSS Functional Description
References (18) - EPOSS Functional Description
Phase Technical Test
Requirement Id 696
Criterion 4
Derivation Requirement
Criterion Description
The CONTRACTOR shall be aware that Girobank is only
an example - POCL needs to keep the flexibility to print on
other cut sheets e.g. tax discs/cheques in due course
Test Condition
Report production, format and data derivation is controlled
by a combination of POCL reference data and the EPOSS
application. The definitions are agreed via the reports and
receipts FS (ref 16). Inspection of ref 16 and observation
of Girobank reporting proves the ability to provide cut -
sheet reporting. This ability may be replicated in the future
via the normal change process.
Method Inspection of document to show it is agreed.
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 696
Criterion 5
Derivation Requirement
Criterion Description
The format of all styles of receipts shall be agreed by
POCL and the CONTRACTOR by a date consistent with
the project plan agreed by the parties, such that the date
does not adversely impact contractual milestones as
defined in Clause 605.1 of the Authorities Agreement . A
bilingual Welsh/English version is required in designated
Outlets.
Test Condition
The formats of all receipts are defined in a Controlled
Document.
See also 693/4
Method
Inspection of document to show it is agreed.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 75 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Vi Ref. CRIACS/O08
iF i, i, ersion: .
Acceptance Specification Date. 18/12/98
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 696
Criterion 8
Derivation Requirement
Criterion Description
EPOSS shall support reporting by journal/tally roll and on
A4 sheets to Client requirements at both Stock Unit and
Outlet levels, with the format to be agreed by a date
consistent with the project plan agreed by the parties,
such that the date does not adversely impact contractual
milestones as defined in Clause 605.1 of the Authorities
Agreement.
Test Condition
Production of outlet reports consistent with specification
Method Inspection of reports.
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 806
Criterion 1
Derivation Requirement
Criterion Description
The date and time within EPOSS shall be accurately
maintained and remain in step with Greenwich Mean Time
and/or British Summer Time as appropriate.
Test Condition
This capability is provided by a number of products:
The Windows NT machines that run Riposte have their
clocks co-ordinated by a built in Riposte feature. Hence
the counter machines are co-ordinated with the
correspondence servers. The correspondence servers
are co-ordinated with a single time master using NT
facilities.
Other NT machines at the centre, that do not run Riposte
also co-ordinate with this single time master using a
product called TimeSERV. The time master is calibrated
by a GPS receiver.
The clocks on the Sequent machines and the Routers are
co-ordinated by using NTP.
See also Acceptance Trial
Method By inspection of document describing Time Service.
References (30) - Time Services Specification
Phase Technical Test
Requirement Id 810
Criterion 3
Derivation Requirement
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 76 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Criterion Description
EPOSS shall be able to validate Transaction details
against Reference Data.
Test Condition
The behaviour of transactions will be governed as far as
possible by reference data parameters.
This area extensively covered by the Ref Data AS
Method Inspection of EPOSS Functional Description
References (18) - EPOSS Functional Description
Phase Technical Test
Requirement Id 811
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow TMS to pass all recorded information
to authorised remote locations (e.g. TIP).
Test Condition
EPOSS data is replicated to the correspondence servers
by Riposte. The onwards is through “harvesting” that data
within TMS. EPOSS itself has no influence over this
harvesting, and so places no restrictions on the onward
distribution of the data. Harvesting is tested in the TPS
AS
See Also Requirement 880/1 (covered in TIP AS)
Method Inspection of EPOSS FS
References (18) - EPOSS Functional Description
(23) - Pathway to TIP Application Interface Specification
Phase Technical Test
Requirement Id 811
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall be flexible enough to support the
introduction of new Client Services in an integrated
manner and ensure that any new POCL Product can be
added, and that EPOSS is automatically updated.
Test Condition
The range of definitions applicable to Client Services is
defined in controlled documents.
Method Inspection of the flexibility afforded by Reference Data
design and the process for introduction of new services.
References (22) - AIS, Reference Data to Pathway
(32) - New Service Introduction Process
(28) - Business Requirements Definition
Phase Technical Test
Requirement Id 813
Criterion 4
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 77 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
Fi i ersion:
Acceptance Specification Date: 18/12/98
Derivation Requirement
Criterion Description
EPOSS shall ensure that only Value Stock Stock Items
allowed in Reference Data provided by POCL to the
CONTRACTOR from time to time can be accessed
Test Condition
Access is as defined in the Horizon OPS Menu Hierarchy
for Release 2
Method Document Review
References (29) - Horizon OPS Menu Hierarchy for Release 2
See also Acceptance trial
Phase Technical Test
Requirement Id 815
Criterion 2
Derivation Requirement
Criterion Description
An unused Stock Unit is one for which no activity has
taken place since its most recent final Balance.
Test Condition Unused is defined as having no transactions (i.e serve
customer or stock movements) and no pending transfers
in
Method Document Review
References (18) - EPOSS Functional Description [2.9.2, 6.5.3.6]
Phase Technical Test
Requirement Id 816
Criterion 3
Derivation Requirement
Criterion Description
Outlets require record retrieval on demand for the
previous two (2) complete POCL Outlet Accounting
Periods. Older records shall be made available at 24
hours notice.
See also Acceptance Trial
Test Condition
That the procedures for obtaining older records are
defined in a controlled document
Method Document Review
References (37 - Horizon System Audit Manual [NR2]
Phase Technical Test
Requirement Id 818
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall allow the Reference Data content to be
presented as a locally produced Report, with changes
made in Reference Data by the most recent update clearly
identified
Test Condition
A suitable report is specified in a controlled document.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 78 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
Method Document inspection
See also Acceptance Trial
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
Requirement Id 818
Criterion 6
Derivation Requirement
Criterion Description
EPOSS shall allow each Outlet to produce various
formatted outputs including but not limited to the Cash
Account and the Cash Flow Report. Other reporting shall
be agreed between the parties during the Operational
Trial.
Test Condition
That the reports are specified in a controlled document
Method Document Review
References (16) BA/POCL Reports and Receipts
Phase Operational Trial
Requirement Id 818
Criterion 7
Derivation Requirement
Criterion Description
Changes to the product range and the internal reporting
structure within current principles shall be possible by
Reference Data rather than by Software update.
Test Condition
The range of definitions implemented by Reference Data
applicable to the product range and the internal reporting
structure is defined in a controlled document.
Method Inspection of satisfactory operation of Reference Data
update from POCL Reference Data System.
Inspection of satisfactory operation of the capability
afforded by Reference Data design to provide for the
product range and the internal reporting structure.
References (41) Reference Data Change Catalogue
Phase Technical Test
Requirement Id 818
Criterion 8
Derivation Requirement
Criterion Description
EPOSS shall be a robust Service, including features to:
a) check internal consistency, reporting errors, warning of
non critical errors and preventing critical errors;
b) refuse deletions if there is dependent business data
which would lead to inconsistency of data within the
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 79 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS v Ref.: GRIACSIONB
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
c) Service Infrastructure;
d) make Reference Data available at the counter
terminals;
e) check Reference Data consistency and report
exceptions.
Test Condition g) The robustness of operation of EPOSS is assessed by
evaluation of open related incident reports. Note that the
requirement is referring to functionality not actually
provided by EPOSS. Existence of checks for internal
consistency is assessed by review of documents detailing
the procedures used. (note:Validation of ref data changes
is also tested elsewhere (RDS0101(47))). Requirement
(b) will be met at NR2 by refusing deletions of Products,
Cash Account mappings, and Accounting Nodes.
That the E2E Closure Reports contains no non-conforming
entries for ICL Pathway specific elements relating to this
criterion
Method Assessment of related open incidents.
Document Review
References Incident Data Base.
(45) POCL Verification of Reference Data Changes for
NR2
(43) Process for Operational Business Change - product
(41) Reference data Change Catalogue
(55) E2E Closure Report
Phase Technical Test
Requirement Id 818
Criterion 9
Derivation Requirement
Criterion Description I Reference Data shall also define the availability of specific
POCL Products in each Outlet. Such availability shall be
controlled centrally, and an Outlet shall not be able to
modify such data.
Test Condition That the E2E Closure Report contains no non-conforming
entries relating to Reference Data control of Product
availability in Outlets
Method Document Review
References (55) E2E Closure Report
Phase Technical Test
Requirement Id 819
Criterion 3
Derivation Requirement
Criterion Description I EPOSS shall provide a facility to input Cash Account
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 80 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
details including week end date and week number
Test Condition Cash Account details are input via reference data
Method Document inspection
References (18) - EPOSS Functional Description
(22) - AIS, Reference Data to Pathway
Phase Technical test
Requirement Id 820
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall include fallback procedures for situations
where the User cannot use the POCL Service
Infrastructure for any reason. These facilities shall
maintain the integrity, security and levels of Customer
Service consistent with the need to maintain trading.
Test Condition
A procedure is defined
See also Acceptance Trial
Method Document Review
References (17) - NR2 EPOSS PPD Section 13
Phase Technical Test
Requirement Id 821
Criterion 1,2,3
Derivation Requirement
Criterion Description
1) EPOSS shall be flexible enough to provide the ability
to define the Transaction range available at specific
Outlets, including:
a) preventing specific Transactions from being available
locally (by Outlet);
b) declining to use specific non-mandatory Transactions
locally (by Outlet);
c) modifying specific POCL Products, where allowed in
Reference Data provided from time to time to the
CONTRACTORS by POCL, for specific Outlets. [Note: It
is a condition that the Reference Data used is agreed only
with ICL Pathway and with no other Contractor.]
2) EPOSS shall be flexible enough to introduce new
functionality as agreed with POCL.
3) EPOSS shall provide facilities to:
a) prepare EPOSS Transaction data and EPOSS
processed data for export to; and
b) import data from other systems outside the POCL
Service Infrastructure.
Test Condition
e The range of definitions applicable to Transactions’
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 81 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
e ranges is defined in a controlled document.
e The capability to introduce new functionality is defined
in a controlled document.
« The export of EPOSS-recorded information is through
“harvesting” of replica data within TMS; and the
importing of data from other systems is through loading
Reference Data to TMS for replication to EPOSS.
Method
e Inspection of the flexibility of the required capabilities
to define the Transaction range within Reference Data.
e Inspection of the flexibility afforded by Reference Data
design to introduce agreed new functionality.
e Inspection of the satisfactory operation the harvesting
of EPOSS data from TMS by harvesting agents,
specifically for TIP; and of introducing data to EPOSS
via TMS by agents, specifically for Reference Data.
References
(18) - EPOSS Functional Description
(22)- AIS Reference Data to Pathway
(23) - Pathway to TIP AIS
(41) - Reference Data Change Catalogue
(43) - Process for Operational Business Change - product
Phase
Technical Test
Requirement Id
823
Criterion
1
Derivation
Requirement
Criterion Description
EPOSS shall make Transaction and process data
captured through EPOSS available to any Service
delivered through the medium of the OPS and specified by
POCL as requiring access to data.
Test Condition
The storage of EPOSS transaction data and data derived
from transactions is the responsibility of the TMS
middleware. It is the responsibility of this middleware to
ensure that the data is made available any Services which
require access to the data.
The capability of EPOSS to make data available at the
OPS level is defined in a controlled document.
Method Inspection of the flexibility afforded by Reference Data
design to introduce agreed new functionality.
References (22) - AIS Reference Data to Pathway.
Phase Technical Test
Requirement Id 825
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall be event driven so that both data capture
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 82 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
and the recording of Services such as BES and APS are
dynamic
Test Condition
The capability to control application sequencing by
peripheral events
Method Inspection of a document to show that Ref Data for the
relevant applications (BES and APS) contains Token
Definitions.
Observation that the swiping of a magnetic stripe card
initiates BES and APS transactions.
References (22)- AIS Reference Data to Pathway
It is suggested swiping is observed during MOT. Failing
this a specific review meeting at a test rig will be scheduled
at the request of POCL’s Ttest Manager.
Phase Technical Test
Requirement Id 825
Criterion 4
Derivation Requirement
Criterion Description
Data shall be automatically recorded in EPOSS if
captured during another Service e.g. BES, APS or OBCS
Test Condition
For normal operation see 835/1
That BES transactions committed before a session is
aborted (e.g. by power failure) are recorded and later
reconciled.
Method Document Review
References (42) BPS Reconciliation of Fallback & Recovery
Transactions FS
Phase Technical Test
Requirement Id 825
Criterion 7
Derivation Requirement
Criterion Description
EPOSS shall provide the flexibility to allow the
implementation of new Methods of Payment including
EFTPOSS and debit cards.
Test Condition
Method This duplicates 692/2
References
Phase
Requirement Id 825
Criterion 10
Derivation Requirement
Criterion Description
EPOSS shall allow the Refund or Reversal of a
Transaction with access maintained at user level.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 83 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Note that certain Transactions may not be refundable or
reversible to comply with Client and POCL accounting and
business rules.
Test Condition
Access is defined in a controlled document
Whether or not a transaction is reversible is defined by
POCL Reference Data.
Whether or not a product is refundable is controlled by the
Menu Hierarchy, which defines the availability of the
products on the refunds menu.
Method Document Review
See also 810/1 and 810/2
References (18) EPOSS Functional Description
(22) AIS Reference Data to Pathway
(29) Horizon OPS Menu Hierarchy for Release 2
Phase Technical Test
Requirement Id 825
Criterion 12
Derivation Requirement
Criterion Description
EPOSS shall have the facility to accept data, via the
POCL Service Infrastructure, from a variety of media such
as, Tokens, keyboard, electronic scales, bar codes and to
add functionality to accept data from other approved
peripheral devices
Test Condition
EPOSS communicates with peripherals via the Peripheral
Broker.
Method Document Review to establish the ability to define and
add approved peripherals to the system.
Observation of system interacting with peripherals (Scales
transactions prove the ability of EPOSS to interact with the
Peripheral Broker).
References (26 - Peripheral Server)
Phase Technical Test
Requirement Id 825
Criterion 14
Derivation Requirement
Criterion Description
EPOSS shall be flexible enough to support the
introduction of new Client Services in an integrated
manner and thereby ensure that any new POCL Product is
event driven and that EPOSS is automatically updated.
Test Condition
The range of definitions applicable to Client Services is
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 84 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
defined in controlled and referenced documents
See also 694/4(event driven) and 811/2(auto update)
Method
Inspection of the flexibility of the required capabilities to
define the Client Services within Reference Data,
specifically to establish that such related applications can
be peripheral event driven and that interfaces exist
through which the journal may be updated.
References
(22) - AIS Reference Data to Pathway.
Automated Payments Client Design Specifications (as
available)
(19) - AP Client Migration Strategy Proposal
Phase
Technical Test
Requirement Id
832
Criterion
1-20
Derivation
Requirement
Criterion Description
The CONTRACTOR shall agree with the AUTHORITIES,
before commencement of Roll Out of EPOSS, the overall
business processes at the counter such that:
1. the capture of data at the Outlet is complete, accurate
and robust e.g. a unique Transaction reference;
2. any transfer of data is secure, complete, accurate and
robust;
3. whether operating normally or in stand-alone mode the
EPOSS shall be capable of validating Transactions by
format and value;
4. in the event of fraud it shall be possible to prove that
the Service was operating without defect (see
Requirement 829);
5. for appropriate Transactions receipts are automatically
generated for Customers and a copy retained in the Outlet
to allow recovery or problem resolution;
6. accountability for cash, Stock and any supporting
documentation is maintained by Outlet and User where
appropriate;
7. the Method of Payment is recorded at the point of sale;
8. the access control system allows segregation of
responsibilities. A log of Users and the functions to which
they have access shall be available to Outlet managers;
9. aback up of all Transactions shall be taken each day;
10. User and device are uniquely identified within each
Outlet;
11.data shall undergo a balancing procedure to enable a
final review and authorisation;
12. Transaction data shall be made available to other
services as agreed in each AP Client Specification and the
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 85 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
Ref.:
Version:
Date:
CR/ACS/008
4.0
18/12/98
EPOSS
Acceptance Specification
13.“Pathway to TIP Application Interface Specification’,
and other POCL Services;
14. Transaction data not delivered in accordance with the
above shall be clearly identifiable;
15.all Transactions can be reconciled to an appropriate
supporting voucher and where necessary these vouchers
are to be available for central validation of amounts
collected;
16.an up to date record of cash and Value Stock on hand
shall be maintained and current balances can be reported;
17. all transfers of Stock and cash to and from other
Outlets and between Users within an Outlet shall be
clearly recorded;
18. all specified summaries shall be produced
automatically when required and all Transactions shall be
included since the last summary was completed;
19. items posted to Suspense Accounts can be identified
for future investigation;
20. information to show compliance with the relevant
legislation, including without limitation Health and Safety
at Work Act, Data Protection Act, Companies Act is
available;
21.an Outlet shall be able to continue operating and to
maintain an audit trail in the event of any failure of the
Service Infrastructure.
Test Condition
The overall business processes at the counter are defined
in controlled documents.
Method
Inspection of documents to see that they are agreed
References
9. (17)-NR2 EPOSS PPD.
10. (28) - NR 2 Access Control and User Administration
PPD
11. (39) - NR2 Operating Environment PPD
12. (20) - Audit Trail FS
13.
Phase
Technical Test
Requirement Id
834
Criterion
1
Derivation
Requirement
Criterion Description
The CONTRACTOR shall ensure that contingency
arrangements are available for all Outlets both during and
after Roll Out of EPOSS to such Outlets.
Test Condition
The business processes applicable to fallback working are
defined in a controlled document.
Method
Examination of a controlled document.
References
(17) - NR2 EPOSS PPD
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 86 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS v Ref.: GRIACSIONB
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
Section 13 - Fallback procedure
Section 14 - Recovery Procedures
(53) - NR2 Horizon System Helpdesk PPD
(54) - NR2 Operating Environment PPD
Phase Technical Test
Requirement Id 834
Criterion 3
Derivation Requirement
Criterion Description
To provide contingency cover during and after Roll Out,
EPOSS shall enable each automated Outlet to produce
plain paper summaries to a format which shall be agreed
by a date consistent with the project plan agreed by the
parties, such that the date does not adversely impact
contractual milestones as defined in Clause 605.1 of the
Authorities Agreement.
Test Condition The formats agreed for plain paper summaries are defined
in a controlled document.
Method Examination of a controlled document
Code and equipment inspection
References (16 - BA/POCL Reports and Receipts)
Phase Technical Test
Requirement Id 835
Criterion 2
Derivation Requirement
Criterion Description
Benefits encashment and other automated Transactions
shall be integrated with the Transaction recording
elements of EPOSS such that there is a single
Transaction Record created and stored locally to provide
the basis for Outlet summarisation and Balancing and
Transaction level data transfer.
Test Condition
At the conclusion of an EPOSS customer session a
Transaction Record is written to the message store as a
set of messages detailing all the items comprising the
customer session. Within this will be a set of messages
for each BES Transaction (receipt), linked by a common
reference. This Transaction Record is the basis for unit
accounting and is accessed by both the CAPS and TIP
harvesters.
See Acceptance Trial 960/3
Method Document Inspection
References (24) - Benefit Payment Service Reconciliation (3.2.1)
Phase Technical Test
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 87 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 835
Criterion 4
Derivation Requirement
Criterion Description
Benefits encashment and other automated Transactions
shall be integrated with the Transaction recording
elements of EPOSS such that Transaction times are kept
to a minimum.
Test Condition
In normal counter operations no duplication of effort is
required to record transactions within EPOSS
Counter transaction performance measurement is defined
in a controlled document
Method Observation (during MOT or at an arranged review if so
requested by the Test Manager) that in normal counter
operations no duplication of effort is required to record
transactions within EPOSS.
Document Review to confirm that methods of
measurement of counter transaction performance are
defined in a controlled document.
Note: that system timings comply with the SLA is covered
in the Service Levels AS
References see also response to requirement 870/1
(29) - POCL Counter Transaction Performance
Measurement
Phase Technical Test
Requirement Id 835
Criterion 7.8
Derivation Requirement
Criterion Description
EPOSS shall be capable of providing summaries of any
type of Transaction for comparison with physical Records
contained within the Outlet. For example EPOSS shall be
able to list and total cheques accepted by value
The system must be able to list and total benefits
transactions made via BES for comparison against
physical records (outlet copy of receipts)
Test Condition That suitable reports are specified in a controlled
document
See also Acceptance Trial
Method Document Review
References (16) - BA/POCL Reports and Receipts
Phase Technical Test
[Requirement Id
[836
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 88 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
ifi H Version: 4.0
Acceptance Specification Date. 18/12/98
Criterion 4
Derivation Requirement
Criterion Description
The OPS shall be flexible to support further Services. The
CONTRACTOR shall be willing to integrate and operate
these under the Change Control Procedure, provided that
there are no valid technical reasons that preclude their
inclusion.
Test Condition Acceptance that the introduction of new Services as
described in the Pathway Release Procedure requires the
use of the Change Control Procedure
Method Document Inspection
References (40) - Pathway Release Policy
Phase Technical Test
Requirement Id 837
Criterion 1-5,7,8
Derivation Requirement
Criterion Description
EPOSS shall support the production of a variety of
Reports in pre-defined formats including:
1. Transaction level Reports by Stock Unit for Clients
using pre-printed cut sheets (Client stationery);
2. Transaction level Reports by Stock Unit for Clients
printed on plain paper;
3. Reports on the current level of Value Stock Stock Items
at Stock Item level;
4. Reports on Transaction volumes and values;
5. Cash Account Reports;
7. Reports on Transfers of cash and Value Stock;
ad hoc Reports for management information purposes.
o>
Test Condition
The required reports are defined in a controlled document.
Method Document Inspection
References (16 - BA/POCL Reports and Receipts)
Phase Technical Test
Requirement Id 837
Criterion 9
Derivation Requirement
Criterion Description
EPOSS shall be able to deliver Reports at the User’s
discretion, subject to POCL and Client rules on frequency
of despatch and POCL Outlet Accounting Periods. Client
Reports shall be produced on a daily or weekly basis.
Where operationally appropriate, several weekly Reports
shall be produced during a POCL Outlet Accounting
Period
Test Condition
The frequency (ad hoc, daily, weekly) of the documents is
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 89 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS v Ref.: GRIACSIONB
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
defined in a controlled document.
See also Acceptance Trial
Method Document Inspection
References (16 - BA/POCL Reports and Receipts)
Phase Technical Test
Requirement Id 870
Criterion 1,2,3
Derivation Requirement
Criterion Description
1) EPOSS shall not slow down the activity of serving
Customers and as such EPOSS shall be designed to
minimise the number of key depressions (or other
interaction with peripheral devices) involved in each
Transaction. In all cases the response of EPOSS to any
peripheral input shall be instantaneous.
2) Summarisation and balancing activities, including
processing and printing, shall be optimised and avoid re-
processing when data are changed during accounting.
3) The CONTRACTOR shall identify technical measures
relating to the Transaction times identified in sections 1
and 2 above, monitor these measures and report against
them. These measures shall be identified by the
CONTRACTOR and approved by the AUTHORITIES by a
date consistent with the project plan agreed by the parties,
such that the date does not adversely impact contractual
milestones as defined in Clause 605.1 of the Authorities
Agreement . The measures must be capable of identifying
trends in Transaction times and in identifying specific
Outlets where Transaction times are significantly better or
worse than the average.
Test Condition
The design criteria for EPOSS are described ina
controlled document
Summarising and balancing activities partial results are
cached in main storage.
Counter Performance Transaction measurement is defined
in a controlled document
Method Agreement to a controlled document
Observation of summarising and balancing activities
Agreement to a controlled document
References (28) - Horizon OPS Menu Hierarchy for Release 2
(18) - EPOSS Functional Description
(29) - POCL Counter Transaction Performance
Measurement
Note: Acceptance of Service Levels is covered by the
© 1998 ICL Pathway Ltd
COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 90 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS v Ref.: GRIACSIONB
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
Service Level AS, which relies upon the Performance
Assurance High Level Test Plan for Release 2
Phase Technical Test
Requirement Id 870
Criterion 4
Derivation Requirement
Criterion Description
For each Outlet where the overall Transaction times are
more than 10% greater than the average, the
CONTRACTOR shall agree, with the AUTHORITIES, what
improvements shall be made, in line with a process to be
agreed by a date consistent with the project plan agreed
by the parties, such that the date does not adversely
impact contractual milestones as defined in Clause 605.1
of the Authorities Agreement.
Test Condition
Process has been agreed
Method confirm agreement reached
References (46) Approved CCN No. 271
Ato A ref ID: R870-2
Phase Technical Test
Requirement Id 871
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall be implemented such that the version of any
reference data being referenced from outlets has been
updated with the latest version of reference data. The
version of the reference data is fully updated once all
updates have been applied.
Test Condition
That the necessary processes are defined in controlled
documents
Method Document Review
References (41) - Reference data Change Catalogue
(31) - Business Thread RDSO1
(43) - Process for Operational Business Change
Phase Technical test
Requirement Id 871
Criterion 2,3
Derivation Requirement
Criterion Description
2) Transaction data shall be forwarded to POCL central
systems (e.g. TIP) soon after the completion of the POCL
Core Day on which the Transaction occurred as part of a
batch transmission. Transaction data not available for the
next batch transmission shall be included in a subsequent
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 91 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
transmission. Data which are included in the first batch
transmission to take place after the time of the Transaction
are deemed to be in the first batch transmission and so
on. The Service Levels for these are defined in the
AUTHORITIES’ Agreement, schedule B03.
3) Batch transmission times shall be agreed for each
POCL central system in the AUTHORITIES’ Agreement,
Schedule B03.
Note: Schedule BO3 has now been superseded by ref. (27)
Test Condition
The operational timetables for TIP, HAPS and Reference
Data are defined in agreed documents
Method
Examination of agreed documents
References
(27) - POCL Infrastructure Service Levels and Remedies
Schedule G10: TIP, para 3.1; Ref Data para 4.1
Phase
Technical Test
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 92 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
5.1.3 Summary of Test and Report content
This summary is referenced from within section 5.1.1
EPO0102
The outlet for the single counter outlet used in the second HLTP has more than
one individual stock unit, for which a variety of counter transactions in different
modes are tested.
During the first Cash Account Period, one of the stock units has multiple Balance
Periods during which Remittances (in and out), Transfers, Sales, Sales
discounts, Price changes, Transaction voiding and Transaction reversals are
performed at various times.
Coverage is included for the following types of Remittances, Transfers and Sales
transaction :-
Cash
Saving Stamps
Postal Orders
Game Licences
BT Phonecards
1st & 2nd Class stamps
Other Postage stamps
Special Stamps
Stamp Books
Discounted stamps
Philatelic items
Ordinary stationery items
Priority stationery items
Air packs
Commemorative Coins
Littlewoods Lotto
National Lottery Instants
Green Giros
BT Bill Payments
TV Licences
Passports
Counters Revenue transactions
Giro transactions (including Transcash, Deposits, Withdrawals)
National Savings transactions (including Deposits, Withdrawals)
Other Bank’s cheque encashment
Bureau de Change transactions
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 93 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway EPOSS
Acceptance Specification
FUJ00058412
FUJ00058412
Ref.: CR/ACS/008
Version: 4.0
Date: 18/12/98
Motor Vehicle Licences
Rent Schemes
Bus Tokens
E111
Active Life subscriptions
Encash postal orders
Settlement of sessions is performed using a variety of methods of payment:-
« Cash
Cheque
Giro Transfer
Voucher
Savings Stamps Redemption
Reporting (with cut-offs where necessary) of the above transactions is carried out
at both counter and office level on a daily basis throughout the Cash Account
Period. Counter-level reports are also carried out on a “by user” basis. Reports
include:-
Counter Daily
Giro Deposits
Giro Withdrawals
BT Bills
National Savings Deposits
National Savings Withdrawals
UK Passports
Other Banks Cheques
Cheques Listing
Counter Weekly
Postal Orders Encashed
Driving Licences V11
Driving Licences V10
Rent Schemes
Bus Tokens
Infrequent (Unsummarised) transactions
P&A
Green Giro
Transfers In/Out/Summary
Remittances In/Out/Summary
Office Daily
e Giro Deposits
¢ Giro Withdrawals
e BTBills
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 94 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
National Savings Deposits
National Savings Withdrawals
UK Passports
Remittances In/Out
Office Weekly
Redeemed Stamps
Sales Report
Postal Orders Encashed
Counters Revenue
Transfers Total/Reconciliation
Remittances In/Out
Green Giro
During subsequent Cash Account Periods further functionality relating to Sales,
Bulk Input, Non-Accounting Data, Parcel Traffic, Housekeeping and Price
Changes is performed. Further office-level reporting is performed on, for
example, the Suspense Account. Reprints of office-level reports are also carried
out.
Coverage which is not performed in the first CAP includes:-
Milk Tokens
Moneygrams
POCL Error Notice adjustments
Giro Error Notice adjustments
National Savings Error Notice adjustemnts
Non-Accounting items
Parcel Traffic items
Suspense Account posting & redemption (including unpaid cheques, vouchers,
losses, gains)
e Weighed mail items (scales)
5.2 CRITERIA FOR LATER ACCEPTANCE
The table below shows which Acceptance Criteria are for Acceptance at a later
level of specification.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 95 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 555
Criterion 7
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support printing on cheques and other forms at the
counter
Reason Cheques not at Release 2
Requirement Id 555
Criterion 9
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall
support the connection of electronic weighing scales
(which shall not be supplied under the Related
Agreements) to the Service Infrastructure. As a minimum,
connections shall include Avery Berkel type D104 and
A702. It shall be possible to share a set of weighing
scales between two or more Counter Positions at which
the Service Infrastructure has been installed
Reason A702 not supported at NR2
Requirement Id 555
Criterion 12, 13, 14
Derivation Requirement
Criterion Description
In each Outlet from Roll Out at such Outlet EPOSS shall:
12) Support the printing of PDF417 two dimensional bar-
codes on forms generated through back office processing.
Typically the two dimensional bar-code shall be used to
contain cash account information;
13) Support the printing of one dimensional bar-codes at
the counter on forms as well as tally roll print, if such
support is provided for in the Solution to this Requirement.
As a minimum, code 128, EAN 8, EAN 13 and code 39
shall be printable;
14) Support the printing of one dimensional bar-codes at
the back office, if such support is provided for in the
Solution to this Requirement. As a minimum, code 128,
EAN 8, EAN 13 and code 39 shall be printable.
Reason
Software and hardware support for these capabilities is
available, but no application is specified to make use of it.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 96 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date: 18/12/98
Requirement Id 629
Criterion 9
Derivation SADD 4.1.3.1.5
Criterion Description
EPOSS shall be capable of validating Methods Of
Payment against business rules for individual
Transactions.
Reason No relevant products currently exist
Requirement Id 691
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall allow cash ordering by denomination and
Stock ordering by Stock Item
Reason Not at release 2. Part of LFS
Requirement Id 691
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall allow the recording of Transfers of cash and
Stock into and out of the Outlet
Reason Not at release 2. Part of LFS
Requirement Id 691
Criterion 3
Derivation Requirement
Criterion Description
EPOSS shall provide a facility to allow the authorised
update of cash and Stock through TMS
Reason Not at release 2.
Requirement Id 691
Criterion 4
Derivation Requirement
Criterion Description
EPOSS shall allow the physical receipt of cash and Stock
Any discrepancy must be recorded against the
consignment reference
to be reconciled by EPOSS against the consignment note.
Reason Not at release 2.
Requirement Id 692
Criterion 4-8
Derivation Requirement
Criterion Description
The CONTRACTOR shall be aware that
4. POCL may require an EFTPOS facility as Method of
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
Printed on: 3/28/2022
Page 97 of 134
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; i Version: 4.0
Acceptance Specification Date. 18/12/98
Payment on EPOSS, probably just debit cards initially
(e.g. Switch, Connect) but perhaps extending to credit
cards later, (e.g. Visa and Mastercard). The capability to
handle both debit and credit cards from commencement of
Roll Out of such a facility;
5. indicative volumes for end of Roll Out of EFTPOS are:
between 30 and 50 million EFTPOS payments per annum;
70% above the floor limit (£15 working assumption) and so
needing authorisation;
6. the main Transactions for which EFTPOS will be used
are expected to be:
motor vehicle licence renewals (34%), bill payments (38%,
about half BT and half others);
television licence payments (11%) and payment for
purchases from PostShops (5%), all estimates;
other likely Transactions leading to EFTPOS are expected
to include travel insurance and bureau de change and
cash withdrawals;
there would be no Cash-Back option initially;
7. business arrangements have not yet been finalised but
the current assumptions are for:
a single Merchant Acquirer;
on-line authorisation and batch Transaction submission to
be via TMS;
reconciliation of EFTPOS payments on the EROSS
Transaction log with an electronic data stream version of
the daily bank account updates;
signed receipts may be stored in the Outlets, remitted to
Distribution Centres or dispatched to a central facility
(which the CONTRACTOR may wish to offer);
POCL expects to need to retrieve receipts in order to
prove Transactions at 0.2% or between 60,000 and
100,000 per annum at above volumes.
8. POCL requires guidance from Pathway as to the
options for EFTPOS on the particular facilities being
proposed and the relative costs and benefits of each
Reason
Not at release 2.
POCL now conducting their own review
Requirement Id 694
Criterion 5
Derivation Requirement
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 98 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
fi q Version: 4.0
Acceptance Specification Date. 18/12/98
Criterion Description
5) EPOSS shall have the facility to read data from any
input device supplied as part of the Service Infrastructure
used in providing OPS.
Reason
No EPOSS events use tokens
EPOSS does not use the magnetic card reader, and
scales are not supplied as part of the service
infrastructure
Requirement Id 808
Criterion 1,2
Derivation Requirement
Criterion Description
EPOSS shall provide a facility to reconcile Non-value
Stock Stock Items with unique serial numbers.
Reconciliation shall be by volume and by Stock Unit as:
(a) number on hand at the start of the POCL Outlet
Accounting Period (plus);
(b) number received (equals);
(c) number on hand at close of POCL Outlet Accounting
Period (plus);
(d) number issued/spoilt/returned
Reason
Functionality will be provided at NR2+ in conjunction with
LFS
Requirement Id 818
Criterion 5
Derivation Requirement
Criterion Description
EPOSS shall maintain other locally controlled Reference
Data. These shall include parameters for POCL Products,
POCL Product groups and subgroups, external Transfer
sources and destinations
Reason
Locally controlled Reference data is not supported, [SADD
4.1.3.3.5 contains a note that the requirement needs
amendment], as POCL have decided that they do not
require such a facility to be implemented. All Reference
data will be centrally maintained.
Requirement Id 819
Criterion 1,2
Derivation Requirement
Criterion Description
EPOSS shall sustain a dynamic set of Cash Account
tables that allows Outlets to introduce additional reporting
lines as new products are introduced within POCL. More
than one Cash Account format shall be supported and
currently there are two in use (which shall both be
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 99 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS vi Ref.: CRIACS/008
iF i, i, ersion:
Acceptance Specification Date. 18/12/98
supported) - standard Outlet format and CRU format.
Validation rules could be applied to individual line entries.
A Report shall be available in each Outlet that maps
Reference Data of POCL Products to the appropriate
line(s) of the Cash Account table(s).
Reason Not at release 2
Requirement Id 819
Criterion 4
Derivation Requirement
Criterion Description
Under certain authorised circumstances an authorised
Outlet may produce one Cash Account to span a 2 or 3
week period and this must be managed by EPOSS. Within
this variation there is a requirement to correctly associate
the week number with a specific Transaction according to
a Client's requirements. This is one of either:
a) the week in which the Transaction took place or;
b) the final week in which the Cash Account is produced.
Reason
(a) above is deferred: EPOSS permits CAPs up to 3 weeks
long. The agreed POCL process is that before starting a 2
or 3 week CAP the EPOSS extended CAP process is used
to roll the office directly into the final week of the extended
CAP. (b) above is therefore met by the normal reporting
process. (a) above can be met, as all transactions are
time/date stamped by the system, and the POCL calendar
is known to the system. Reports could therefore be written
to report client transactions against calendar CAP. This
will not be provided at NR2.
Requirement Id 819
Criterion 5
Derivation Requirement
Criterion Description
EPOSS shall support the production of the Cash Account
in printed and electronic formats. The printed Cash
Accounts shall include a 2D bar code.
Reason
The format and content of printed cash account reports is
defined in controlled documents. [Note the format and
content of 2D bar-coded Cash Accounts is not defined at
this time. See also Acceptance Criterion 555/12, above.]
Requirement Id 834
Criterion 2
Derivation Requirement
Criterion Description
The CONTRACTOR shall give due consideration to the
implementation plan for Parent Outlets and Satellite
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 100 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway EPOSS vi Ref.: CRIACS/008
iF ii i ersion:
Acceptance Specification Date: 18/12/98
Outlets.
Reason CCN pending
Requirement Id 834
Criterion 4
Derivation Requirement
Criterion Description
The element of the Service Infrastructure at every Outlet
shall be capable of printing a 2 dimensional bar-code on
any plain paper summary.
Reason
At present no application is specified to make use of two
dimensional bar-coding capabilities. Software and
hardware support for these capabilities is available.
Requirement Id 835
Criterion 5.6
Derivation Requirement
Criterion Description
EPOSS shall be capable of providing summaries of any
type of Transaction for comparison with physical Records
contained within the Outlet. For example EPOSS shall be
able to:
5) summarise the quantity of tax discs on hand;
6) summarise the quantity of milk Tokens on hand;
Reason These reports have not yet been defined by POCL
Requirement Id 835
Criterion 9
Derivation Requirement
Criterion Description
As Transactions become automated the relevant
summaries shall be enhanced to include details of items
issued/on hand, by individual serial number
Reason Not at Release 2
Requirement Id 836
Criterion 1
Derivation Requirement
Criterion Description
PostShops are currently equipped with an EPOS terminal -
CRISP (Counters Retail Information Systems in
PostShops) - which is a stand alone system. It is
desirable, subject to offered solutions, that these be
integrated into or replaced by the EPOSS
Reason Not at Release 2
Requirement Id 836
Criterion 2
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 101 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref.: CR/ACS/008
fi H Version: 4.0
Acceptance Specification Date: 18/12/98
Derivation Requirement
Criterion Description
Where an Agent may in future use the OPS for his own
business, all Services using the OPS shall identify such
Transactions separately from those relating to Services
under the POCL Agreement, in particular for financial
accounting.
Reason Not at Release 2
Requirement Id 836
Criterion 3(f)
Derivation Requirement
Criterion Description
For each Transaction processed at a Counter Position
through the POCL Service Infrastructure the following
information shall be captured:
(f) Customer identification and details (e.g. for
Transactions
involving cheques, passports, motor tax discs);
Reason Requirement for personal details fields not yet defined
Requirement Id 837
Criterion 6
Derivation Requirement
Criterion Description
EPOSS shall support the production of a variety of
Reports in pre-defined formats including reconciliation
Reports for Non-value Stock Stock Items e.g. milk Tokens,
tax discs;
Reason Not at R2
Requirement Id 838
Criterion 2
Derivation Requirement
Criterion Description
EPOSS shall also support the input of data for local
schemes where the value is not recorded for accounting
purposes but the volume is.
Reason No such current product
Requirement Id 839
Criterion 1
Derivation Requirement
Criterion Description
EPOSS shall provide the point of sale retail functionality in
use in PostShops. This includes, but is not restricted to:
a) Till functionality; b) discounting; c) coupon
management;
d) multibuys; e) promotions; f) marketing; g) reporting
Reason
Postshop functionality not available at Release 2
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 102 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
FUJ00058412
FUJ00058412
EPOSS Ref.: CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
Requirement Id 960
Criterion 2 (a)
Derivation Requirement
Criterion Description
Automated zero value Transactions shall be reported
separately. Initially these shall be:
(a) automated payments which fall into two categories:
e Smart Tokens, where Transactions are recorded (even
if zero value) once the Client has been identified since this
implies interaction with the Smart Token;
e swipe-cards or keyed Transactions, where recording of
zero value Transactions is controlled by POCL Product
parameters for minimum and maximum values but where a
Transaction can be made void during Customer Service;
.
Reason
Smart cards not supported at release 2
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 103 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
ICL Pathway
EPOSS
Acceptance Specification
FUJ00058412
FUJ00058412
Ref.: CR/ACS/008
Version: 4.0
Date: 18/12/98
5.3 CRITERIA SUMMARY
Req ID
Criterion
Trial
Review
Later
Acceptance
473
530
533
555
555
555
555
©]@INI@/>]>]r
555
555
aIo
555
12-14
629
691
691
691
691
NINININENEN
691
692
692
692
692
693
693
SIN
693
693
693
694
694
694
AIST SS
694
694
695
695
AIST SN
695
695
695
695
695
00] V}I Jeo] n9] Jon] 8 ]o2 Ip] I on] Jc0]ro] 41 F I eo)ro] 4 Jon] 8 ]09 0] s/o
695
9,10
SISNET S
695
11
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE
Printed on: 3/28/2022
Page 104 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
i " Version: 4.0
Acceptance Specification Date. 18/12/98
695
696
696
696
696
696
696
696
696
696
800
800
800
800
800
800
801
801
801
802
802
803
803
804
804
804
804
805
805
805
805
805
806
807
807
807
808
808
808
809
809
809
809
809
SISSY SNS
SIN
an] 8] 33] ]on] 8 Ie Ipo] 4] 8 oo Ipo] Ir] s/n] 3] 9 Ip9] 3] Jon] B] 09 Ir ]-3IO] co] NJ o}on] soo I] 3/5
SESTSY SY SE SESE ST ST SESS STS SS SESEST STS SSIES SES SY
SISNET SSIS
alalolm}alalole
7
nD
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 105 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
i " Version: 4.0
Acceptance Specification Date. 18/12/98
810
810
810
810
811
811
812
812
812
813
813
813
813
814
814
814
814
814
814
815
815
816
816
816
816
816
817
817
817
818
818
818
818
818
818
818
818
818
819
819
819
819
819
819
SISSY SNS
=
>] on] 8/09/55] ] co] NI] o>] on] 4/9/39] 09/9] >] NV > ]on] I co] 481] NJ orIon} B] co] 8] G9/Nd] 3/9/09] 3 no] IB] 9/9]
~
NEST SY SISSIES ST SDSS ST SESS STS SY SSIES SES SY
\
AVIS
~
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 106 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
i " Version: 4.0
Acceptance Specification Date. 18/12/98
820
820
820
820
820
820
820
820
821
823
823
824
824
825
825
825
825
825
825
825
825
825
825 10 v
825 11 v
825 12 v
825 13 v
825 14 v
832 1-20 v
833
834
834
834
834
835,
835
835
835
835
835
835
835
836
836
836
SISNET SY SSS
NI
SISISEST SS
<
SIN
€©]o0]~1]o>]on] 0909] s/n] IrI 4] 2° 00] Jon] on] 8] 09 09] >
<
NINES
©9Ir3]-+]co}o0] WP feo] no] 4] 8 ]eo]noI 4]
SN
Ke
(a-e,9)
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 107 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
836 4 v
837 1-5 v
837 6 v
837 7-8 v
837 9 v v
838 1 v
838 2 v
839 1 v
870 1-3 v
870 4 v
871 1 v
871 2-3 v
915 14 v
960 1 v
960 2 b,c a
960 3 v
6. ACCEPTANCE INCIDENT SEVERITY
This section identifies the guidelines to be applied during the analysis of
Acceptance Incidents, in order to establish the severity of such Acceptance
Incidents.
6.1 HIGH SEVERITY INCIDENTS
Failure to meet an Acceptance Criterion which would have a substantive impact
on the service received by the Customer, e.g. failure to pay benefits to the right
person, at the right place, at the right time.
Failure to meet an Acceptance Criterion which would have a major impact on the
ability of the AUTHORITY or AUTHORITIES to perform their business, or where
there was a major impact on the resources of the AUTHORITY or AUTHORITIES
necessary to overcome that impact on their business, e.g. failure to support
accurate POCL accounting
Failure to meet an Acceptance Criterion which would impact the security of the
service where there is no acceptable procedural workaround.
Consistent failure to meet Minimum Acceptable Thresholds for Service Levels,
e.g. where particular transactions do not meet the minimum Acceptable
Threshold under normal loading.
6.2 MEDIUM SEVERITY INCIDENTS
Failure to meet an Acceptance Criterion which is visible to the Customer and is
likely to give rise to an adverse public perception of the service, but does not
substantively impact the service received by the Customer, e.g. incorrect spelling
on a receipt.
Failure to meet an Acceptance Criterion which would have a medium impact on
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 108 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
the ability of the AUTHORITY or AUTHORITIES to perform their business, or
where there was a medium impact on the resources of the AUTHORITY or
AUTHORITIES necessary to overcome that impact on their business, e.g. non-
production of a weekly report, resulting in its manual transcription, which causes
additional resource or effort at every outlet of the average duration of one hour
per week per outlet.
Occasional failure to meet Minimum Acceptable Thresholds for Service Levels,
e.g. at peak loading, some transactions fail to meet Minimum Acceptable
Thresholds, but on average all transactions within the service do achieve
Minimum Acceptable Thresholds.
6.3 LOW SEVERITY INCIDENTS
Failure to meet an Acceptance Criterion that is neither visible to nor has
substantive impact on the service received by the Customer e.g. presentational,
style and other cosmetic faults that are only visible to the user.
Failure to meet an Acceptance Criterion which would have a minor impact on the
ability of the AUTHORITY or AUTHORITIES to perform their business, or where
there was a minor impact on the resources of the AUTHORITY or AUTHORITIES
necessary to overcome that impact on their business, e.g. non-production of a
weekly report, resulting in its manual transcription, which causes additional
resource or effort at ten or fewer outlets of the average duration of one hour per
week per outlet.
Failure to meet an Acceptance Criterion which would impact the security of the
service but where the workaround is as secure as the original solution (i.e. the
only impact on risk is in ensuring that the workaround is performed, but where
procedures have been agreed and are in place).
7. TEST DATA
Test data including any operator entered scripts that are required to run the
Acceptance Test are defined below.
Business Test Thread: EPO01 (33)
High Level Test Plan(s): EPO0101 (34)
EPO0102 (35)
EPO0103 = (36)
Organisation: Pathway T & I
8. AUTHORITY RESPONSIBILITIES
This section describes the AUTHORITY’s or AUTHORITIES’ Responsibilities in
relation to this Acceptance Test. Particular Acceptance Tests may also require
additional participation and responsibility by the AUTHORITY or AUTHORITIES.
8.1 APPOINT TEST MANAGER
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 109 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
if; H Version: 4.0
Acceptance Specification Date. 18/12/98
The AUTHORITY or AUTHORITIES shall nominate a Test Manager and other
representatives to review the tests prior to commencement of the test.
8.2. ACCEPTANCE INCIDENT REPORTS
The nominated representatives and Test Manager shall be diligent in raising
complete, accurate and timely Acceptance Incident Reports as set out within this
Acceptance Specification.
8.3. ACCEPTANCE INCIDENT ANALYSIS REPORTS
The Test Manager shall be diligent in returning signed Acceptance Incident
Analysis Reports with their decision (e.g. Accept, Reject, Discuss) normally
within five working days, or when urgency is requested by Pathway, within two
working days of receipt from Pathway. A copy of all correspondence will be
faxed to reduce delay.
8.4 ATTENDANCE AT TRIALS AND REVIEWS
The nominated representatives shall at their discretion attend Acceptance Test
Trials and Reviews including repeat Tests at reasonable times and reasonable
locations and with reasonable advance notice by Pathway.
8.5 MANAGEMENT AND CO-ORDINATION
The Test Manager shall be the single point of communication and co-ordination
with Pathway’s nominated Test Manager for all matters concerning this
Acceptance Test from its initial planning through to Acceptance.
8.6 PROGRESS REVIEWS
Unless otherwise waived by both parties, Pathway’s Test Manager and the
AUTHORITY’s or AUTHORITIES’ Test Manager shall meet each week to review
the progress and actions of both parties until Acceptance of the Acceptance Test
is achieved. The time and location of review meetings will be scheduled with at
least two week’s advance notice by Pathway.
9. CONTRACTOR RESPONSIBILITIES
The Contractor shall nominate a Test Manager for each Test who shall be the
single point of communication and co-ordination with the AUTHORITY’s or
AUTHORITIES’ Test Manager for all matters concerning this Acceptance Test
from its initial planning through to Acceptance.
Upon receipt of a signed Acceptance Incident Analysis Report from the
AUTHORITY or AUTHORITIES, where correction is required to be re-tested
within the same phase of Acceptance Test, the Contractor will return the
amended component(s), on average, within 4 days. This will include re-testing
necessary as per the agreed test strategies.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 110 of 134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual
obligations between ICL Pathway and the DSS and/or POCL.
FUJ00058412
FUJ00058412
ICL Pathway EPOSS Ref... CR/ACS/008
ifi i Version: 4.0
Acceptance Specification Date. 18/12/98
10. ACCEPTANCE TRIAL TEST CONDITIONS
The EPOSS HLTP and LLTP is ordered simply under the BT references as quoted above. Thus no additional mapping to test
conditions is required.
© 1998 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Printed on: 3/28/2022
Page 111 of
134
Nothing contained herein shall be deemed or construed as affecting existing contractual obligations or creating new contractual obligations between ICL Pathway and the DSS and/or POCL