POL00001535
POL00001535
Project PING Requirements Catalogue
PING Project
(Interfacing Client Data into POL
Systems)
Requirements Catalogue
uthors jan Trunde’ echnical
Architecture
BDA Sign-off Ann Clarke Business
(Peer Reviewer) Architecture
TDA Sign-off Peter Stanley Technical
(Peer Reviewer) Architecture
Delivery Manager I Sally Rush Project
Delivery
Project Sponsor I Rod Ismay Project Sponsor
Business Dawn Brooks P&BA
Stakeholder
Business Lynn Hobbs Network
Stakeholder
POL Reference Number I PROJ 60 PING HTA REQ
FS Reference Number REQ/CUS/CDE/0001
Version Number Version 0.4
Date Printed: Thursday, 28 May 2009 Page 1 of 41
Project PING ©Post Office™ 2009
F/506/1
POL00001535
POL00001535
* . Project: PING
e Project PING Doe Ret.
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
1 CONTENTS
1.1 TABLE OF CONTENTS
1 Content.........esecseccseeee
1.1 Table of Contents.
1.2. List of Tables .
1.3. List of Figures
2 Document Control
2.1 Document Information
2.2 Document History ..
2.3. Change Process
2.4 Changes in this Version
2.5 Key Contacts
2.6 Review Detail
2.7 Associated Documents.
2.8 Abbreviations/Definitions
3 Introduction
3.1 Purpose
3.2 Background
3.3 Scope...
4 Process Overview.........
4.1 Current Camelot Process .
4.2 Proposed Camelot Proces:
4.3 Transaction Acceptance Processe:
4.3.1 Transaction Receipt from the Client..
4.3.2 Generation of the Transaction Acceptance file
4.3.3 Branch processes to accept the Transaction Acceptance
4.3.4 Back-end Systems processes in POLFS
4.4 Architecture...
4.4.1 Transaction Integrator
4.4.2 Branch Database
4.4.3 XI Changes.....
4.4.4 Transaction Volume:
4.5 Sample Processed Transaction Acceptances Report — Office Copy
5 Requirements Catalogue...
1.2 List OF TABLES
Table 1: Document Information..
Table 2: Document History
Table 3: Changes in this Version
Table 4: Key Contacts.......
Table 5: Review Details.
Table 6: Associated Documents.
Table 7: Abbreviations/Definitions
Table 1 — TA Branch Database........
1.3 List OF FIGURES
Date Printed: Thursday, 28 May 2009 Page 2 of 41
Project PING ©Post Office™ 2009
F/506/2
POL00001535
POL00001535
* . Project: PING
4 Project PING Doe Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
2 DocumeNT CONTROL
2.1. DOCUMENT INFORMATION
HNG-X Release No
HNG-X Release 2
POL Programme
Back Office Efficiency Programme
POL Project
CP09-079 The PING Project (Interfacing Client Data into POL Systems)
Document Title
PING Project (Interfacing Client Data into POL Systems) Requirements
Catalogue
Document Type
Requirements Catalogue
Abstract
This document details the Requirements for the PING Project. It details
the Requirements that should be employed in the implementation of the
solutions for the PING Project. This document details the Requirements
Specification, Requirements Catalogue and Acceptance Criteria
Document Status
DRAFT
Originator & lan Trundell — Solution Architect
Department
Contributors Paul Jepson, Ann Clark, Saunder Narayan, Gareth Jenkins, Penny
Maguire
Post Office Distribution
As defined in review contacts.
Supplier Distribution
Gareth Jenkins — Fujitsu Services
Penny Maguire — Steria
Andrew Fowler — Logica
EDG Team — CSC
Client Distribution
Not applicable.
2.2 DOCUMENT HisTORY
Table 1: Document Information
0.1 10/10/2008 Initial Version
0.2 12/2/2009 Updated to include additional
requirements / clarification
0.3 20/4/2009 Updated to reflect comments received
after formal review
0.4 26/05/2009 Updated following document review
2.3 CHANGE PROCESS
Table 2: Document History
Any changes to this issued version of this document will be made, controlled and distributed
by: -
Business Solutions
Post Office Ltd
80 Old Street
London
Date Printed: Thursday, 28 May 2009
Project PING
Page 3 of 41
©Post Office™ 2009
F/S506/3
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
2.4 CHANGES IN THIS VERSION
0.3 = General comments updated throughout
04 - General comments updated throughout
Table 3: Changes in this Version
2.5 Key ConTACTS
Sally Rush Project Manager
lan Trundell Technical Design Authority
Ann Clarke Business Solution/ Change Manager for Finance
Business Partner Team Group/Finance
Penny Maguire Steria — SAP Landscape Architect
Gareth Jenkins Fujitsu Services Design Authority
‘Andrew Fowler Logica Project Manager
Table 4: Key Contacts
2.6 REviEW DETAILS
—
Mandatory Review Authority Name
Post Office Ltd:
Chief System Architect Peter Stanley
Domain Architect Don Burgess
PING Solution Architect lan Trundell
Business Analyst Paul Jepson
IS Architecture / Security Dave M King
Project Manager Sally Rush
Test Manager Chris P Young
Project Sponsor Rod Ismay
Programme Manager Martin Box
Business Solution Manager Ann A Clarke
Legal Sarah M White
Service Delivery Steve Beddoe
Physical Security Danny Boles
Network Shaun Turner
P&BA Dawn Brooks
Agency Remuneration Chris Howard
HNG-X Use Case Mike Hamill
Fujitsu RMGA
Date Printed: Thursday, 28 May 2009 Page 4 of 41
Project PING ©Post Office™ 2009
F/506/4
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
Analysis & Solution Specification Gareth Jenkins
Design Authority
Testing
Software Support
Security Howard Pritchard
Customer Services
Logica Andrew Fowler
csc EDG Team representative
Optional Review/ Issued for Information
Post Office Ltd
Security Manager Sue Lowther
Operations Manager
Release Manager
OBC Reference Data Service Manager
Business Strand Lead
Test Manager
Business Analyst
Business Consultant
POL-FS Solution Architect Saunder Narayan
Table 5: Review Details
2.7 ASSOCIATED DOCUMENTS
Document cross-references in the text of the document are in the form ‘Doc Ref [x]’ where ‘x’
is the number in the ‘Ref column in the table below.
1 RS1712 Trial to manually interface POL
Camelot client data into POL.
systems
2 EA/IFS/002 POL FINANCE SYSTEMS TO. Steria
TMS/HORIZON (PRISM)
TRANSACTION
CORRECTIONS
INTERFACE SPECIFICATION
ETL Interface?
4 RS1576 / CP09-0079 Interfacing Client Data in POL POL
Systems
5 Tbe HNG-X Transaction Fujitsu
Acceptance Solution Design
6 Tbe PING Branch Communications = POL
7 Tbe Transaction Acceptance to Fujitsu
HNG-X AIS.
8 Tbe PING Business Processes POL
9 Tbe Client take-on process POL
10 Tbe OLA with CSC (EDG to TI) csc
41 The OLA (Fujitsu, Logica, POL) POL
12 Tbe PING Test Plan POL
Date Printed: Thursday, 28 May 2009 Page 5 of 41
Project PING ©Post Office™ 2009
F/S06/5
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version
Date:
POL00001535
POL00001535
PING
0.4
26/05/2009
13 Removed
14 The PING Exception Process POL
45 Not Applicable Transaction Acceptance Fujitsu
Processed TA report — included
in document 5 —- HNG-X
Transaction Acceptance
Solution Design initially
16 Tbe PING Migration Plan POL
17 Benefit Profile - PING 0.1 20/05/2009 I PING Benefits Realisation Plan I POL
v0.1.doc
18 I PSO/S80/E2E/SOL/079 3.0 6/1/2006 Camelot Outlet Transactions to I= POL
Management Information AIS
19 Tbe Reference Data Definition POL
20 = Tbe Business Process L1/L2 POL.
21 Tbe PING Service Definition POL
22 camelotfield mapping 2.3 16/10/2008 I Field Mapping Specification for Logica
specification v2.3.doc Camelot
23° The PING Disputes Process POL
24 CP08-0011 0.1 15/04/2009 I Client Data Generic Interface POL
25 Tbe Logica PING Solution Design Logica
Table 6: Associated Documents
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
Date Printed: Thursday, 28 May 2009
Project PING
Page 6 of 41
©Post Office™ 2009
F/S506/6
POL00001535
POL00001535
. Project: PING
Project PING Doo Ref
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
2.8 ABBREVIATIONS/DEFINITIONS
Abbreviation Definition
AIS Application Interface Specification
AP-ADC Automated Payments Advanced Data Capture
API Application Program Interface
DIW Data Integrator Warehouse
EDG Electronic Data Gateway
PaBA Product and Branch Accounting — The Post Office the finance team
POL TI Post Office Limited Transaction Integrator
RMGA Royal Mail Group Account
SFTP Secure File Transfer Protocol
TI Transaction Integrator
TIs Technical Interface Specification
TMS Transaction Management System
Table 7: Abbreviations/Definitions
Other generic IT terms can be looked up at: http:/Avww.whatis.com/
Term
Definition
Paystation Plus.
Off counter terminal capturing AP type transactions, hosted by Ingenico
Post & Go
Off counter terminal capturing postal type transactions, hosted by Wincor
Nixdorf
Date Printed: Thursday, 28 May 2009
Project PING
Page 7 of 41
©Post Office™ 2009
F/506/7
POL00001535
POL00001535
* . Project: PING
. Project PING b
" oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
3 INTRODUCTION
3.1. PURPOSE
This document details the business and technical requirements for a HNG-X Transaction
Acceptance that will be introduced into the HNG-X service. The documents therefore
represents the baseline reference for those involved in the various stages of design,
development, deployment and support for solution components to meet the overall
requirement. It is also intended to support the Post Office Ltd concurrence and approval
processes that are required to be undertaken in order that a solution can be implemented.
Use cases will be documented and input to Doors as appropriate.
Inputs used in the production of this document have been:
« Feasibility Study
Outputs/Outcomes that subsequent activities are required to deliver based on the
requirements detailed in this document are:
= TDA Strategic Concurrence.
« Subsequent Supplier Solution Outline Design.
« Subsequent Supplier Technical and Application Interfaces Specification documents.
« — Information feed into the quotation phase.
Date Printed: Thursday, 28 May 2009 Page 8 of 41
Project PING ©Post Office™ 2009
F/506/8
POL00001535
POL00001535
Project: PING
e Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
3.2 BACKGROUND
In line with the commercial contracts with clients, a number of settlements made by Product
and Branch Accounting are based upon data provided by the client. Such an example is
Camelot, where settlement is based upon data captured by the Camelot terminal in outlets
rather than the data being captured at transactional source by HNG-X.
The client data is uploaded into POL FS and compared with the equivalent HNG-X data which
has to be manually input by the agent/counter clerk. Ideally the data, when compared, should
be the same but a number of conformance issues have been identified where agents/counter
clerks do not perform end of day routines correctly, do not input the Camelot details into HNG-
X as they should, and can key incorrect figures, leaving Product and Branch Accounting with a
reconciliation difference. This difference may require the issuing of a transaction correction.
Changes through automated re-engineering should provide improvements to branch
compliance as well as reducing costs.
Although Client based settlements are not a preferred settlement option it is recognised that
the data being provided by clients such as Camelot is robust, controlled by reference data,
and more accurate than the HNG-X data stream due to the conformance issues mentioned
previously
The solution is to automate a process that converts the Client data file (eg Camelot), into a
data feed to the branch, i.e. a Transaction Acceptance file. The branch will then accept the
data and thus avoid the issues described above.
A number of non-financial benefits should result from the full change:
= Time savings at outlets achieved through the less frequent interrogation of ‘off
counter’ equipment and the manual input of data into HNG-X, resulting in less time
required to deal with associated differences, and transaction corrections.
= A fit for purpose generic solution which can be used for future off counter development
and client based settlements ie further kiosk developments such as Paystation Plus /
Post & Go
3.3 SCOPE
The document describes the high-level processes for the Transaction Acceptance for the
following activities:-
= Transaction File Receipt from the Client
= Generation of the Transaction Acceptance file and POLFS Control entry
= Branch processes to accept the Transaction Acceptance
= Back-end Systems processes in POLFS
= Revised operational instructions which describe the preceding changes for
agents/counter clerks
= Duty instructions for POL FS users
Out of scope :
= There will be no change to the way that transactions are currently conducted ie lottery
on-lines sales.
= As settlements are already based on client data there should be no change to
settlement timescales or the commercial contracts with clients, although there may be
a minor impact on the client enquiry process.
Date Printed: Thursday, 28 May 2009 Page 9 of 41
Project PING ©Post Office™ 2009
F/S506/9
POL00001535
POL00001535
Project: PING
e Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
4 PROCESS OVERVIEW
4.1 CURRENT CAMELOT PROCESS
The following diagram describes the current process for data received from Camelot
(Lottery Sales) and the associated reconciliation process via POLFS.
Branch Summary, Branch Summary
Honan
Buk Enoy
POLFS reconciles values
Horizon Value £1000
Camelot Value £1000
Daily Branch
Data
Buk Eniry
Daly Branen
Daia
1. Transactions are undertaken at the Camelot terminal, eg Sale of Lottery Ticket
At the end of day the Clerk should request a Branch On line summary — this
shows the monies taken by the camelot terminal
3. The Clerk needs to take monies from the Camelot till and enter into the Branch
accounts via HNG-X.
4. The Branch input data is captured and passed to POLFS
5. Camelot provide a summary of transactions undertaken via the terminal and send
it to POLS (via EDG) which is a contractual required for settlement
6. Amanual reconciliation process in POLFS reconciles the values between the 2
data streams (eg £1000 as show in the example above)
7. Transaction Corrections (TC's) are issued where the reconciliation fails
4.2 PROPOSED CAMELOT PROCESS
Date Printed: Thursday, 28 May 2009 Page 10 of 41
Project PING ©Post Office™ 2009
F/506/10
POL00001535
POL00001535
. Project: PING
Project PING Doo Ref
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
The proposed process involves a data feed from the Client and this being used to
generate a Transaction Acceptance. The HNG-X entry is not required as the branch
will receive a TA which will be accepted (this is explored in more detail in the following
sections).
Camelot provide a summary of transactions undertaken via the Lottery terminal
which is passed to POLFS via EDG as contractually required
POL TI will create a Transaction Acceptance record for the branch indicating the
value of transactions undertaken
The Branch will be presented with the value to “accept” only . Unlike TC’s there
will be no opportunity to write off or ask for evidence due to the inherent
robustness of the Camelot data provided . Also post HNG the only available
‘evidence’ will be within the office systems so all accountability to bring the TA to
account is already within the branch domain
The “accepted” value will be passed to POL back end systems such as POLFS to
provide the opposite posting into the matching account and HRSAP to provide the
remuneration calculation
4.3 TRANSACTION ACCEPTANCE PROCESSES
The following section describes the processes necessary to undertake Transaction Acceptance for the
following components:
Transaction File Receipt from the Client
Generation of the Transaction Acceptance file
Branch processes to accept the Transaction Acceptance
Back-end Systems processes in POLFS
4.3.1 Transaction Receipt from the Client
Data received from the client will be via the EDG as this is the preferred interaction with
external sources. EDG will pass the data to the target system (eg POL TI) unchanged. EDG
will expect a file to be received daily from the Client. Where no file is received an alert will be
raised and the Client contacted.
Date Printed: Thursday, 28 May 2009 Page 11 of 41
Project PING
©Post Office™ 2009
F/506/11
POL00001535
POL00001535
* . Project: PING
e Project PING b
" oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/08/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
4.3.2. Generation of the Transaction Acceptance file
Two models exist for the creation of Transaction Acceptance file:-
o Where the Client does not have a current interface it is expected that the Client will
conform to the POL TI “generic” interface (as defined in CP08-0011 — Client Data Generic
Interface)
o Where the Client has a current interface or is not willing to migrate to the generic
Transaction Integrator interface
43.24 Transaction Integrator to send to branch and POLFS (control)
The standard/generic Transaction Integrator format is the preferred interface format to send
data to POLFS (see diagram below — interface 3 & 4).
Asecond stream of data will be passed to the branch for the Transaction Acceptance data
(see doc ref[7]) (see diagram below — interface 5).
The Client will be asked to conform to the generic AIS (see diagram below — interface 2). This
may require some Clients to undertake rework if there is already an existing interface. Where
this is not possible, the solution at 4.3.2.2 will be followed.
It is expected that Paystation Plus and Post & Go will follow this route.
Solution overview
o Transaction Integrator to process Client transaction data and summarise into a TA file
that is passed to the HNG-X Branch Database.
o Acontrol entry is created for POLFS such that matching of processed TA's can be
undertaken. This will be via the generic ETL to POL-FS AIS. It will be possible for
P&BA to detect where a branch has not accepted the TA.
o Each non-Horizon system (eg Paystation Plus, Post and Go, Camelot) will create a
separate file containing TA’s pertinent to the branch device (Camelot terminal 1 / 2
etc)
Date Printed: Thursday, 28 May 2009 Page 12 of 41
Project PING ©Post Office™ 2009
F/506/12
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
‘TRANSACTION ACCEPTANCE FOR CAMELOT
vga Fame]
[erortes I
43.22 Existing Client Interfaces that cannot be changed
Where there is an existing Client stream that contains the transactional data this information is
used to update the POLFS Settlement Accounts (via EDG). In order to keep the solution
consistent, the data will be passed to the Transaction Integrator to transform the data into the
generic POL TI process. This remainder of the steps will then be as option 4.3.2.1.
It is expected that Camelot data will follow this route. The EDG to POLFS data load can then
be removed.
Asecond stream of data is required to generate the Transaction Acceptance to pass to the
branch.
Solution overview
o Client Data to be passed to Transaction Integrator.
co The data will be pre-processed to transform it into the standard POL TI interface (see doc
ref[x])
o Transaction Integrator to process Client transaction data and summarise into a TA file that
is passed to the HNG-X Branch Database
o Acontrol entry is created for POLFS such that matching of processed TA’s can be
undertaken. This will be via the generic ETL to POL-FS AIS. It will be possible for P&BA to
detect where a branch has not accepted the TA
co The existing POLFS process to load data into the Vendor accounts can be
ceased/removed
Note: this makes the end-to-end solution consistent for both models and puts the data
processing obligations into POL TI. The branch processes and POLFS load processes for
Transaction Acceptance clients will be consistent.
Date Printed: Thursday, 28 May 2009 Page 13 of 41
Project PING ©Post Office™ 2009
F/506/13
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
I S
4.3.3. Branch processes to accept the Transaction Acceptance
The following section describes the process undertaken at the Branch to accept the Transaction
Acceptance data. The POL Transaction Integrator will pass data to the Branch Database, whereupon
it will be available to the Branch Manager or Supervisor at the next log on.
Date Printed: Thursday, 28 May 2009 Page 14 of 41
Project PING ©Post Office™ 2009
F/506/14
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
4331 LogOn
After making the existing check for Outstanding TCs, where the user has a Role of MANAGERS or
SUPERVISORS (to be further defined) a further check will be made to determine whether there are
any outstanding TAs.
If there are any, then the User is presented with a list of all Outstanding TA’s to process. There will
not be an option to bypass this, and it will normally be the case that Users will just Accept all TAs
without further consideration.
The solution always needs to allow for the SU not being present and the situation where the current
SU is not appropriate (ie it is SU DEF). If the supplied SU doesn't exist (or is not available due to
being locked) and the Logging On User is attached to SU DEF, then bypass TAs for that SU during the
Log On. They will not be marked as failed and can be processed at a subsequent Log On or manually
later. The final solution regarding Stock Units is yet to be defined.
4332 Processing TAs
When the user is presented with a list of TAs to be processed, the user can either select a specific TA
to look at it in more detail, or select a function to Accept all the TA’s.
Date Printed: Thursday, 28 May 2009 Page 15 of 41
Project PING ©Post Office™ 2009
F/506/15
POL00001535
POL00001535
Project: PING
Ny Project PING bos Ref
Requirements Catalogue :
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
2 Apr 09 11:36 Help
oo es
Post Mail
tems
" 1 ee me
: sete cs - I pe
nProguct ay I _
Lottery Sales Cash £52300 cA Select id
ery Sales Cas Suspend
Label Sales Plastic £ 2054 Pot
Stamp Sales Cash £200.45 PGI
Instants £5. 100 CAT Select I Cancel
Figure 1 -TA Summary
Figure 1 is a rough attempt at what could be displayed. It shows 4 TAs. Any of them can be selected
using the Select buttons to look at the full details of the TA.
However normally, the User would be expected to touch the Enter button which would result in
accepting all the TAs. In turn this will generate transactions (in one or more hidden baskets) which will
be recorded in BRDB as normal and the next night will be passed back to POL FS in the normal BLE
file as well as to Credence in the normal MI interface.
An identifier will be associated with the transactions that are generated to support the matching
process. This will be included in the TA record and is put into the tc_reference field as fora TC. This
will be correctly passed back to POL FS and can be used there for auto matching with the data passed
into POL FS from the client.
Since these transactions need to be matched up in POL FS it is important that the BLE Summarisation
process does not aggregate them. Since it is expected that the products, which are used for TAs, are
specifically for use for TAs, then what is required is that the Reference Data for those products map
them to Articles which are configured not to summarise the data in the Modes being used for TAs
acceptance.
Summarisation is set by POL FS Article, i.e. Product.
Date Printed: Thursday, 28 May 2009 Page 16 of 41
Project PING ©Post Office™ 2009
F/506/16
POL00001535
POL00001535
* . Project: PING
Ny Project PING b
" oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/08/2009
4.3.4 Back-end Systems processes in POLFS
4344
Transaction Integrator to send to branch and POLFS (control)
A Control entry is made using the ETL to POL FS Generic Interface currently under implementation for
Paystation Plus and Post & Go. Camelot data to be included in the ETL to POL-FS extract.
The Counter Application will convert the TA file upon acceptance to the TA Branch Summary that will
use HNG-X mode 14 SC-Sale to Customer.
43.4.2
WPUTABO01
Finance Posting
\ Sie = Various ie. FAD Code
WPUUMS01
{ Aggregate Sale
Site = Various Le. FAD Code
WPUFIBO1
Finance Posting
Site = A000 I
/_ WPUTABO1
Method of Payment
\ Site = Various ie. FAD Code I
\».6r Paystation contra to Cash
Fi Document (Doc Type = RV)
total for day for branch
Dr Cash (total for day for branch)
Dr cheques (total for day for branch)
Dr Debit cards (excludes Paystation/Post & Go}
Dr Other methods of payment
(Cr Paystation contra to Cheques
(Cr Post&Go contra to Cash
Cr Anon Customer
Controif 0.9. Gt. 626300)
(Branch)
0.0} 190 pnous Bueaig
(Cr Vendor e.g. 120025 (GL 620100) ~~.
+ by Aicle §400000115
by Day
Fi Document (Doc Type = KX)
Dr Contra to Cash Creques
+ by Prof Cerre (Branch)
+ byDay
Dr Debit Card Payments
+ by Pf Centre (Branch)
+ byDay
(Cr Anon Customer (GL 532110)
+ byDay
Transaction Integrator to send to branch and update POLFS (control)
a pinows Sweets
ToS Bie
1:5 / UoZioH vBeMieg dais
‘youeia £4
As described in Section 4.3.2.2, existing Client data, such as Camelot update the Vendor account via
XI. A Control entry is made using the Programs ZIFX0045 and ZIFX0043 The TA file will have an
article of type 40. The Counter application will convert the TA file to the TA Branch Summary that will
use HNG-X mode 14 SC-Sale to Customer, where Settlement=C.
The intention is to migrate the solution to the model described in Section 4.3.2.2, and standardise on
the feed via Transaction Integrator. This will require a migration strategy for each Client to ensure the
data feeds are not duplicated. There may be an opportunity to parallel run the data streams before the
existing POLFS route is ceased.
Date Printed: Thursday, 28 May 2009
Project PING
Page 17 of 41
©Post Office™ 2009
F/506/17
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
POL00001535
POL00001535
Project: PING
Doc Ref:
Version: 0.4
Date: 26/05/2009
‘Aticle’s Settiement
Type EQUAL
t0°C" (sourced from
ROS)
9
EI
WPUUMS01
Aggregate Sale
SD contig + POL-FS Article Master AAG
cantols posting 627" —_/
—
WPUTABO1
Finance Posting
WPUFIB01
Finance Posting
Program ZIFXGGAS & enty on ZINTMAP
SE controls the erry 627° /
Batch session
Program ZIPXOO43 & ety on ZINTMAP -—P>
contol GL Account postings
5B
i 8
F Document (Doc Type = RV) 3
‘Dr Cash / Near Cash Vand
(o9.551100 <6 a)
+” by Profit Cente (Branch) i #
+ byDay i 8
is
Cr Dummy Customer -=s-02n-neeBheannd 1B
+ byDay i
Ye 8
8
3
8
Fi Document (Doc Type = KC) :
Note: below signs are where Transaction :
type = VEN1. if transaction Type = VEN2 H
FI Document (Doc Typs
tomer
Dr Dummy Ci
+ byDay
Cr Client Actuals Control 627"*
Where MM = Month
+ by Profit Centre (Branch)
+ by Anicle (Product)
+ byDay
then DriCR are reversed
Dr Client Actuals Control 627°"
+ by A\ticle (Product)
+ byDay
a=» =do( Settlement
Cr Vendor
+ by A\ticle (Product)
+ by Day
FI Document (Doc Type = KC)
‘Or GL Account
+ by Profit Centre (Branch)
by Article (Product)
+ byDay
r GL Account
+ by Profit entre (Branch)
+ byAticle (Prod
+ byDay
Date Printed: Thursday, 28 May 2009
Project PING
Page 18 of 41
©Post Office™ 2009
F/506/18
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
4.4 ARCHITECTURE
The following components are enhanced to support the solution.
4.4.1 Transaction Integrator
The use of Transaction Integrator will enable a generic Transaction Acceptance process to be
followed. By utilising a standard detailed transaction file format it will be possible to output data to the
Branch Database for use by HNG-X (see diagram below).
Business
OP Odeo
BOX!
Transaction
Acceptane
for HNG-X
The file delivery process will operate like TCs, namely that Fujitsu will process all files delivered to the
input directory at the time it runs (proposed to be 06:05 am each day as with TCs). If multiple files are
generated then they will all be processed. The monitoring will only raise an alert if there are no files
delivered.
The files are loaded into the TPS Host system where they are validated and any error files generated
and returned.
A new set of processes will need to be implemented based on the TC processes to load, validate and
process the TA file and deliver it to BRDB.
There is no change to the remuneration model for products. If the product is currently paid using
HNG-X data, this will continue, but, with the more accurate Transaction Acceptance figure. This data
will still be extracted by Fujitsu and passed on the HNG-X to HRSAP AIS, not from Transaction
Integrator.
4.4.2 Branch Database
A new table will be required in TPS Host and BRDB to hold TA's the contents of which will be
determined during Solution Design.
Date Printed: Thursday, 28 May 2009 Page 19 of 41
Project PING ©Post Office™ 2009
F/506/19
POL00001535
POL00001535
Project: PING
N Project PING boo Ret
Requirements Catalogue °
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
Transaction Integrator will require a number of “controls” to ensure that the solution is robust and that
the data received from Clients is processed correctly and updates the appropriate systems. The
paystation® project will implement POL TI with the appropriate controls.
AP > Giients. Reta for 2 years
fon Sates - REMs, Revaluation ete. ~ Rolain 90 days
Events ~ Log on ete. Retain 90 days
4.4.3. XI Changes
The two data streams into POL FS (from POL TI and HNG-X) will be using existing interfaces. How
SAP-XI handles these data streams and how they are posted into POL FS is entirely dependent on
the reference data pertaining to the Article. As mentioned previously in Section 4.3.3.2, no new
modes are required, but Mode 14 will be re-used.
4.4.4 Transaction Volumes
Volume figures will be defined in a form that can be fed into PA/PER/033 during the definition of the
Als's.
Date Printed: Thursday, 28 May 2009 Page 20 of 41
Project PING ©Post Office™ 2009
F/506/20
POL00001535
POL00001535
i . A " hl Project: PING
Q PING Project (Interfacing Client Data into POL Systems) Doc Ref
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
4.5 SAMPLE PROCESSED TRANSACTION ACCEPTANCES REPORT — OFFICE COPY
bz/90S/4
The following example is illustrative only and will require further definition as part of the Solution Design.
The Processed Transaction Acceptances report will allow the branch to verify which services have been processed and which TA’s
have been accepted.
1
2 3 4 5 6 7 8 9 10 1 2 3 4
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
o1 Feltham Post Office FAD 123456X Page 1
02 11:42 08/04/2009 TP O01
03 Transaction Acceptances Report - office Copy
04
05 Date Date Outcome Reference Credit/ Affected Settlement Amount Quantity Client Term SU
06 Received Processed Invoice Product Product Reference
07
08 21/03/04 22/03/04 abcdefghijklmn N123456789012345678 CRM abcdefghijklmnop abcdefghijklmnop 123456789.12 12345678 abcdefghijklmnop
09
10 21/03/04 22/03/04 Serve Customer C123456789012345678 INV Lottery Sales cash 523.00 Camelot 1 cAL
i
12 21/03/04 22/03/04 Serve Customer P123456789012345678 INV Label Sales Plastic 20.54 Post & Go 2 PGL
13
14
15
16 *** END OF REPORT ***
The data shown in the example is illustrative only —
the exact text can change, and so differ from that in the example.
Date Printed: Thursday, 28 May 2009 Page 21 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
zz/90S/4
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doe Ref:
Version:
Date
POL00001535
POL00001535
PING
0.4
26/05/2009
5 REQUIREMENTS CATALOGUE
Acceptance
Reg!D Sup; Compone: Description Acceptance C: ia method
TA-01. I Fujitsu Branch Acceptance Branches should be provided with an opportunity to compare locally held Document review of HNG- I Document
information with client data ie the transactions should not be forced via the X Transaction Acceptance I Review
branch without acceptance (as described in 4.3.3) Solution Design (doc
reff5])
TA-02. Fujitsu Branch Acceptance During the logon process the solution must ensure that where the user has Acceptance Criteria as per I POL Test
Role of MANAGERS or SUPERVISORS any outstanding TA’s must be requirement.
processed. Verification that this
requirement has been
Note: There is no need to attach the current User to the specified SU but purely I satisfied will be evidenced
for the TAs to be processed in that SU and the remainder of the Log On to by the End to End Test
continue with the User remaining attached to their current SU. report
Note: Flexibility of Roles is not controllable by POL Ref data so POLneed to
agree the exact roles up front. Future changes are subject to CRs, but initial
set is flexible.
TA-03. I POL Branch Acceptance End of day cut offs should be considered and associated timing differences Document review of PING I Document
should be eliminated so that branches should be able to directly reconcile Branch Communications Review
locally held information directly with client data (doc ref[6}) and PING
Business Processes (doc
ref{8])
TA-04. I Fujitsu Branch Acceptance For MANAGERS and SUPERVISORS roles it should not be possible to Document review of HNG- I POL Test
progress to serve customers until initial logon (start of day) processes have X Transaction Acceptance
been completed Solution Design (doc
ref{S])
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
Date Printed: Thursday, 28 May 2009 Page 22 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
€z/90S/4
POL00001535
POL00001535
» I A , I Project: PING
» PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone Description Acceptance method
report
TA-05. I Fujitsu Branch Acceptance The solution must allow for the SU not being present and the situation where Document review of HNG- I POL Test
the current SU is not appropriate (ie it is SU DEF). X Transaction Acceptance
Note: if the supplied SU doesn't exist (or is not available due to being locked) Solution Design (doc
and the Logging On User is attached to SU DEF, then TAs for that SU willbe —_I ref[5])
bypassed during the Log On. They will not be marked as failed and can be
processed at a subsequent Log On or manually later. Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-06. I Fujitsu Branch Acceptance The default option should be acceptance of the client data value, no manual Document review of HNG- I POL Test
override to change or alter the client data value should be made available. X Transaction Acceptance
Solution Design (doc
ref[5})
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
Date Printed: Thursday, 28 May 2009 Page 23 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
yz/90S/4
POL00001535
POL00001535
7 - . , Project: PING
» PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone Description Acceptance a method
TA-O7. Fujitsu Branch Acceptance The solution must ensure that TA is undertaken in the correct stock unit Document review of HNG- I POL Test
X Transaction Acceptance
Solution Design (doc
ref{5])
Note: Manager and Supervisor roles may logon to a default Stock Unit
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-08. I Fujitsu Branch Acceptance The solution must only allow the Branch Transaction Acceptance records to be I Document review of HNG- I POL Test
‘accepted’ X Transaction Acceptance
Solution Design (doc
Note: where a branch has a genuine issue a query must be raised. The TA may I ref[5])
be corrected via the Client (crediting the branch through the data feed) or a
Transaction correction will be sent to the branch to correct the discrepancy, but,
the TA MUST be accepted poaaien Criteria as per
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-09. I Fujitsu Branch Acceptance The solution must present the Manager or Supervisor with a list of All Acceptance Criteria as per I POL Test
outstanding TA’s requirement.
Verification that this
Note: see sample screen at Section 4.3.3.2. This will be refined during the requirement has been
Solution Design. satisfied will be evidenced
by the End to End Test
report
Date Printed: Thursday, 28 May 2009 Page 24 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
$z/90S/4
@
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doe Ref:
Version:
Date
POL00001535
POL00001535
PING
0.4
26/05/2009
ReqiD Supplier
TA-10.
Fujitsu
Component
Branch Acceptance
Description
Transaction Acceptance must be restricted to roles Controlled by reference data
Note: the Likelihood is that this will be restricted to Supervisor and Manager
roles
Acceptance Cri
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
Acceptance
method
POL Test
TA-11.
Fujitsu
Branch Acceptance
Where the User selects a TA the solution must present the Manager or
Supervisor with detail of the TA
Note: the AIS and Solution Outline design work will define the actual screens
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
POL Test
TA-12.
POL
Branch Acceptance
Branches should have a daily routine at start of day to accept data for the
previous business day, this may vary as branches have different opening times
Review of Transaction
Acceptance Branch
Communications (doc ref
[6]) and PING Business
Processes (doc ref[8])
Document review
TA-13.
POL
Branch Acceptance
Clear operational instructions for users, including steps to be taken if client data
does not reconcile with locally held information
Review of Transaction
Acceptance Branch
Communications (doc ref
[6]) and PING Business
Processes (doc ref[8])
Document review
TA-14,
POL
Branch Acceptance
Provision should be made for core/outreach outlets which operate on a
temporary basis.
Document review of
Transaction Acceptance to
HNG-X AIS (see doc
Ref[7]) and HNG-X
Transaction Acceptance
Solution Design (doc
ref{5])
Document
Review
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 25 of 41
©Post Office™ 2009
97/90S/4
POL00001535
POL00001535
7 - . , Project: PING
‘ PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone: Description Acceptance Criteria matied
Branch Acceptance The solution must consider the “legal” issues regarding Transaction Acceptance I Document review of HNG- I Document
and the fact that the TA affects the stock and cash position at the Branch X Transaction Acceptance I Review
Solution Design (doc
ref{5])
TA-16. I Fujitsu Branch Balancing The solution must ensure that the HNG-X system checks that all outstanding Acceptance Criteria as per I POL Test
TA’s are processed in line with existing Stock Unit balancing processes requirement.
Verification that this
requirement has been
Note: the current check does not allow the last Active SU to be Balanced if satisfied will be evidenced
there are outstanding TCs . This will be extended to check for outstanding TAs by the End to End Test
or TCs. report
Note: If TA’s are enforced at Logon there should not be any to process, but it is Ps
a back-stop
TA-17. I Fujitsu Branch database The Transaction Acceptance volumes will be in the order of 20,000 records per Statement of fact
day (see Section 4.4.4)
Note: This allows for Branches receiving TA’s for each device (kiosk/atm)
Note: TA’s will be in addition to Transaction corrections
Note: allowing for the following devices,, eg Camelot, Post and Go and
Paystation, ATM the number of TA’s to accept could be 10 or more per branch
Device Number MOP. Total
Kiosk — 2 * 2 MOPS 2 2 4
Paystation —1 * 3 MOPS 4 3 3
Camelot 2 * 1 MOP. 2 41 2
ATM 4 4 4
10
Date Printed: Thursday, 28 May 2009 Page 26 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
22/90S/4
POL00001535
POL00001535
- . , Project: PING
PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqiD Supplier Component Description Acceptance Cri lapping lay
method
TA-18. I POL Branch process The Branch processes must be documented Doc Review of the Document
Business Process flows Review
Note this includes, (see doc ref[8})
* Transaction Acceptance, and challenges where the branch
disagrees,
¢ — Stock Rem-in / out
* _ Daily processes — timings
TA-19. I Fujitsu Branch Transaction The solution must provide a Daily Transaction Acceptance report as defined in Acceptance Criteria as per I POL Test
Acceptance Report the Solution Outline Design (see Doc Ref [5]) to show the products where TA requirement.
has been accepted and any TA’s that are outstanding. Verification that this
requirement has been
Note: The content must show satisfied will be evidenced
by the End to End Test
«Date report
« Product
« Value
« Volume
« Device id (terminal Id)
* any Outstanding TAs to be show on the processed TAs report for
visibility / action
See example report in section 4.5, exact report will be defined as per Solution
Outline Design (doc Ref[5}).
Note: the existing TC report will remain unchanged.
The expectation is that all TAs are processed on the next Log On so there is no
requirement for a separate Outstanding TAs report at the Branch
TA-20. I POL Business Process POL will document a Disputes process to allow branches that do not agree with I Document review of Document
the Transaction Acceptance values Branch Transaction Review
Acceptance Disputes
Process (doc ref[23])
TA-21. I POL Business Process Product and Branch Account will Police the TA acceptance / conformance Doc Review of the Document
process. Business Process flows Review
Date Printed: Thursday, 28 May 2009 Page 27 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
82z/90S/4
POL00001535
POL00001535
» I A , . Project: PING
» PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone: Description Acceptance C: matied
(see doc ref[8})
TA-22. POL Business Process POL will document the Exception process, eg what to doc if Duplicate TA’s are Document review of Document
received into POLFS, what happens if ETL sends 2 files? Transaction Acceptance Review
Exception Process see
doc reff14])
TA-23. I POL Business Process POL to document the counter processes Document review of HNG- I Document
X Transaction Acceptance I Review
BPD L1/L2 (doc ref{20})
TA-24. I POL Business Process POL to document the Service Definition document Document review of Document
Transaction Acceptance Review
Service Definition (doc
ref{21])
TA-25. I CSC Client Interface EDG shall be the solution to send/receive Client transaction data and Statement of
associated error files Fact
TA-26. I Logica Client Interface Client data received by POL T! shall be validated to ensure it conforms to the Acceptance Criteria as per I POL Test
AIS requirement.
Verification that this
Note: Exceptions will be returned to the Client (via EDG) requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-27. I POL Client Take-on A standard Client take-on process must be documented Document review of Client I Document
The document will define how a new client will provide data to Post Office and take on process (see doc Review
what impact there is at the counter for TA / reference data / stock movement etc I ref [9])
Note: Rules / principles must be considered
TA-28. I POL Client Take-on A Generic take-on process will be document that describes how new or existing I Document review of Client I Document
clients will utilise the Transaction Acceptance process Take-on process (see doc I Review
reff9])
TA-29. I POL HNG-X - Stock Any solution should improve stock management in HNG-xX if the client provides I Document review of HNG- I Document
stock data. X Transaction Acceptance I Review
Solution Design (doc
ref[5])
Date Printed: Thursday, 28 May 2009 Page 28 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
6z/90S/4
POL00001535
POL00001535
7 - . , Project: PING
» PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqiD Sup Compone Description Acceptance a lapping lay
method
TA-30. I Fujitsu / HNG-X — TA Data Feed I Fujitsu / Logica to implement a mechanism to pass data between Fujitsu Document Review of the Document
Logica Credence and Fujitsu HNG-X to support the Sending / receiving of associated I Transaction Acceptance to I Review
TA files HNG-X AIS (see doc
ref{7])
TA-31. I Fujitsu/ HNG-X—TA Data Feed I Data to be processed daily with provision for weekends and bank holidays in ‘Acceptance Criteria as per I POL Test
Logica line with the above requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-32. I Fujitsu/ HNG-X—TA Data Feed I Solution supported by changes to SLA/OLA with Fujitsu/ Logica, controls to be I Review of OLA (see doc I Document review
Logica in place relating to management of non delivery (11))
TA-33. I Fujitsu HNG-X — TA Data Feed I The permissible modes that are acceptable to Transaction Acceptance records I Review of Solution Outline I Document
will be defined in the Solution Outline Design and the AIS Design, see Doc ref [5] Review
Document Review of the
Transaction Acceptance to
HNG-X AIS (see doc
ref{7])
TA-34. Fujitsu HNG-X — TA Data Feed I The solution must cater for Transaction Acceptance records which will be sent Acceptance Criteria as per I POL Test
to HNG-x in a distinct file, which is separate to the TC stream. requirement.
Verification that this
requirement has been
satisfied will be evidenced
Note : TAs and TCs are totally distinct streams with their own filenaming by the End to End Test
conventions and interface directories report
Date Printed: Thursday, 28 May 2009 Page 29 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
o¢/90S/4
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
POL00001535
POL00001535
Project: PING
Doe Ref:
Version: 0.4
Date: 26/05/2009
Description
ReqiD Sup
Componet
TA-35. HNG-X — TA Data Feed I The solution must cater for one or more Transaction Acceptance files to be
received daily.
Fujitsu /
Logica
Acceptance
method
POL Test
Acceptance ia
Document Review of the
Transaction Acceptance to
HNG-X AIS (see doc
ref{7])
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-36. I Fujitsu / HNG-X — TA Data Feed I The TA feed should allow credits and debits in the same file.
Logica
Document Review of the
Transaction Acceptance to
HNG-X AIS (see doc
ref[7])
POL Test
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the Joint Test report
TA-37. I Fujitsu / HNG-X - TA Data Feed I The TA feed to HNG-X should be documented in an Interface Specification
Logica
Document Review of the
Transaction Acceptance to
HNG-X AIS (see doc
Ref[7])
Document
Review
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 30 of 41
©Post Office™ 2009
Le/90s/s
POL00001535
POL00001535
7 - . , Project: PING
» PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone Description Acceptance a method
TA-38. I Fujitsu HNG-X — TA Data Feed I The solution should load data into the HNG-X Host system where they are Acceptance Criteria as per I POL Test
validated and any error files generated and returned. requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the Joint Test report
Review of Solution Outline
Design, see Doc ref [5]
TA-39. Fujitsu / HNG-X — TA Data Feed I Transaction Acceptance records will be sent to the Branch on Day B (by 08:00). I Document Review of the Document review
Logica The Fujitsu solution should check for the existence of TA files between the Transaction Acceptance to
hours of hh:mm and hh:mm. Times to be specified in the AIS. HNG-X AIS (see doc
Ref[7])
Note: Where no TA files are received, Fujitsu should raise an Alert (see TA-xx)
TA-40. Fujitsu HNG-X — TA Data Feed I Where no Transaction Acceptance are passed between the hours of hh:mm Acceptance Criteria as per I Fujitsu Test
and hh:mm Fujitsu should raise an Alert (see TA-xx). Times to be specified in requirement.
the Als. Verification that this
requirement has been
Note: The OLA will document what to do where there are no TA’s satisfied will be evidenced
by the End to End Test
Note: the solution will need to consider non-working days as, for example, for I report
TC's no alerts are raised for missing files on a Sunday.
TA-41. I Logica HNG-X — TA Data Feed I Implement process to support the receipt of files that are not loaded into HNG-X I Acceptance Criteria as per I POL Test
and have been retumed to Logica. Such that the files will be rectified and re- requirement.
presented to HNG-X. Verification that this
requirement has been
satisfied will be evidenced
by the Joint Test report
TA-42. I POL HNG-X — TA Data Feed I Document the process in the OLA(s) for files that have not been loaded into Review of OLA (see doc Document review
HNG-X. These should be returned to Logica, where the files will be rectified (11)
and re-presented to HNG-X.
TA43, I POL HNG-X— TA Data Feed I Management of calls from agents to be handled via NBSC, relating to missing I Review of OLA (see doc I Document review
client data. Data gathered as a result of calls to be used as part of OLA/ORF [11})
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 31 of 41
©Post Office™ 2009
ze/90S/4
» I A , I Project: PING
» PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
process
TA-44. POL / Logica HNG-X — TA Data Feed I The feed to HNG-X should be include the information to allow acceptance By Document Review of the POL Test
Branch, by Terminal ID (Kiosk Id), by Product, by Day Transaction Acceptance to
HNG-X AIS (see doc
Ref[7])
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the Joint Test report
TA-45, I Client HNG-X- TA Interface The client should conform to the Generic Client to ETL interface [ref] for the Statement of
provision of transaction data Fact
TA-46. I Logica HNG-X- TA Interface Where the Client data cannot be changed (i.e. Camelot), the information must Document review of Document
be transformed via POL TI into the standard data extract process for TA. Logica PING Solution Review
Design (doc ref[25})
Note: it is assumed that the key fields will be present in the client file to
generate the correct POL TI (see doc ref[x]) format
TA-47. I Logica HNG-X- TA Interface POL TI shall transform specific Client files to the Generic POL TI AIS schema Document Review of the POL Test
(names of these clients shall be advised by POL) Transaction Acceptance to
HNG-X AIS (see doc
Note : this requirement is only for files from Clients that are unwilling to use the I Ref[7])
Generic schema, e.g. Camelot
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the Joint Test report
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 32 of 41
©Post Office™ 2009
POL00001535
POL00001535
e¢/90S/4
POL00001535
POL00001535
» I A , I Project: PING
» PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue oe Fe
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone Description Acceptance a method
TA-48. I Fujitsu HNG-X- TA Interface The solution must allow for stock adjustments to be undertaken for activation of I Document review of Document
products, eg Scratch cards for Camelot. Transaction Acceptance to I Review
HNG-X AIS (see doc
Note : the solution must consider Volume and value for Rem-in/Rem-out viaa __I Ref[7]) and HNG-X
Transaction Acceptance
Solution Design (doc
ref[5])
TA-49. POL HNG-X- TA Interface Data provided to Fujitsu Services must distinguish between Transaction Document Review of POL Test
Corrections and Transaction Acceptance Transaction Acceptance to
HNG-X AIS (see doc
Note: this applies to both file and record level Ref[7])
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-50. I Fujitsu / HNG-X- TA Interface The solution must allow for system derived stock on hand totals, that have Document review of Document
Logica been created by Camelot scratch card activations. Transaction Acceptance to I Review
HNG-X AIS (see doc
Note: Reference data will define products, eg for Camelot games. It may be Ref[7])
possible to utilise Text fields for the TA if the TC AIS is used as a basis
TA-51. I Fujitsu HNG-X- TA Interface The solution must ensure that files can be traced through the systems to ensure I Document review of HNG- I Document
Logica that audit is possible X Transaction Acceptance I Review
csc Solution Design (doc
Client ref[5]) and Document
review of Logica PING
Steria Solution Design (see doc
Ref[25])
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 33 of 41
©Post Office™ 2009
ve/90s/4a
POL00001535
POL00001535
» I A , I Project: PING
» PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone: Description Acceptance Criteria matied
HNG-X- TA Interface The Transaction Acceptance data must be transformed from the existing Acceptance Criteria as per I POL Test
Camelot Client File (see doc ref[22]) requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-53. I Logica HNG-X- TA Interface POL TI shall transform all its inbound files that now conform to the generic Acceptance Criteria as per I POL Test
outbound POLFS format requirement.
« Generate Transaction Acceptance requests & send to the HNG-X Branch Verification that this
DB. requirement has been
* Generate records for the Generic POL ETL to POL FS interface file. satisfied will be evidenced
* The above two shall be cross referenced by inserting a unique number in _ I by the End to End Test
both data streams at the article/site/day level of granularity, say, in the report
Account Reference field.
Note : the two streams generated from POL T! will eventually be reconciled in
POL FS and the unique number insertion is to enable matching & clearing of
control accounts.
TA-54. I Logica Credence The solution shall enable TAs to reflect individual kiosks when viewed on Acceptance Criteria as per I POL Test
Credence. requirement.
Verification that this
Note: To facilitate P&BA to verify the Branch level summary in POL FS with the I requirement has been
kiosk level breakdown in POL MIS. satisfied will be evidenced
Note: This is however not a requirement when viewed in POL FS, because by the End to End Test
in POL FS summarisation is done at the less granular Branch level report
Note: The design envisages that POL TI will give a unique identifier to the two
streams of data that it sends it to the Sales stream direct to POL FS and the TA
that generates the MoP stream in HNG-X. This unique identifier comes back to
POL FS from both streams and matches off.
TA-55. I POL/Logica I Posting and controls inI Exception reporting of non accepted transactions, if possible with root cause Document review of HNG- I Document
POLFS analysis, and by age eg non polling, core/outreach or part time branch, disputed I X Transaction Acceptance I Review
values Solution Design (doc
Date Printed: Thursday, 28 May 2009 Page 34 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
se/90S/4
POL00001535
POL00001535
I - I Project: PING
PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Ri Acceptance
eq iD Supplier Component Description Acceptance Criteria
method
ref[5]) and Logica PING
Solution Design (see doc
Ref[25])
TA-56. POL’ Posting and controls in The solution should support current contractual obligations for POL including for I Document review of HNG- I Document
Logica POL FS ‘example settlement on client data X Transaction Acceptance I Review
Solution Design (doc
ref[5]) and Logica PING
Solution Design (see doc
Ref[25})
TA-S7. I Fujitsu Posting and controls inI The solution should continue to use double entry accounting. Document review of HNG- I Document
POL FS X Transaction Acceptance I Review
Solution Design (doc
ref[5]) and Logica PING
Solution Design (see doc
Ref[25})
TA-58. POL Posting and controls in There should be a reconciliation / control to compare branch transactions to Document review of HNG- I Document
POL FS client data to validate settlement/receipts X Transaction Acceptance I Review
Solution Design (doc
Note: PaBA will undertake reconciliation reffS}) and Logica PING
Solution Design (see doc
Ref[25})
TA-5S9. POL Receipt of client data Agreement of generic AIS documentation with clients, outlining clear roles and Client Interface AIS to be Document review
responsibilities, together with a change process to be agreed and adhered to by I reviewed (see doc [13])
both parties, including testing
TA-60, I POL Receipt of client data All data should be received from the Client using EDG, and passed via the POL Statement of
TI tool Fact
TA-61. I POL Receipt of client data Back out processes should data prove to be incomplete or inaccurate, Review of OLA (see doc Document review
supported by escalation routes to client as part of the OLA [11])
TA-62. I POL Receipt of client data Business standard reference data processes to be utilised to manage client Review of Business Document review
data, so that changes to equipment, locations are co-ordinated and data posted I processes
to dummy profit centres occurs on an exceptional basis (see doc [8])
Note:
assumed no impact on POL RDS to Fujitsu RDMC interface or the RDS system
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 35 of 41
©Post Office™ 2009
9¢/90S/4
POL00001535
POL00001535
- . , Project: PING
PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
R Acceptance
eq iD Supplier Component Description Acceptance Criteria
method
and any of its interfaces
TA-63. I POL Receipt of client data Clear timescales to be agreed for client corrections Review of OLA (see doc Document review
[11]
TA-64. POL Receipt of client data Client files are to be received daily by hh:mm Statement of
Fact
Note: Agreements with Clients must ensure that data is received by hh:mm
TA-65. I POL Receipt of client data Controls to check completeness and accuracy of data prior to submission to Document review of Document
branches Transaction Acceptance to I Review
Note: This will be defined as part of AlS production HNG-X AIS (see doc
Ref[7]) and
Document review of HNG-
X Transaction Acceptance
Solution Design (doc
ref{S])
TA-66. I POL Receipt of client data Format of data to correct an error made by the client to be agreed eg an Client Interface AIS to be Document review
incremental change to correct a transaction as opposed to reversing and reviewed (see doc [13])
replacing a transaction and Exception Process
Note: Would need to understand how this might correct a difference held in document to be reviewed
suspen/se (see doc ref [14])
TA-67. I POL Receipt of client data OLA agreed with client and managed via Service Delivery including non receipt_I Review of OLA (see doc I Document review
of files, controls around loading files and management of exceptions, clear [11])
points of contact and escalation
TA-68. I POL Receipt of client data Timescales agreed for receipt of files over weekends and bank holidays taking Review of Client OLA (see I Document review
into account bank holidays in Scotland, and Ireland doc [11})
TA-69. I Logica/ Reference Data Validation shall use Master Data as appropriate ‘Acceptance Criteria as per I POL Test
Fujitsu requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 36 of 41
©Post Office™ 2009
2¢/90S/4
POL00001535
POL00001535
I - I Project: PING
PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqiD Supplier Component Description Acceptance Cri Aecepeince
method
TA-70. I POL/Logica Reference Data The Reference data system (MDM) must provide Transaction Integrator with Document review of HNG- I Document
the appropriate data to fulfil the needs of the TA interface as described in TA-53 I X Transaction Acceptance I Review
Solution Design (doc
ref{5])
TA-71. I POL Reference Data The solution must be generic, and therefore be easily adaptable to other client Document review of HNG- I Document
interfaces, ideally using Reference Data X Transaction Acceptance I Review
Solution Design (doc
ref[5]) and Document
review of Reference Data
AIS (see doc ref[19])
TA-72. POL / Fujitsu Reference Data Any Transaction Acceptances will be validated against standard Reference Statement of
Data, so care must be taken that TAs for non-core products are only sent to Fact
Branches that support those products
Any TAs that fail Reference Data validation will be marked as “failed” and the
user will be informed.
Note: For TCs this is done at the counter at “acceptance time” , so the same is
envisaged for TA’s
TA73. I POL Reference Data Reference data shail be created as appropriate for Articles that carry the
Method of Payment data stream from HNG-X as well as the Sales Data Stream
from POL TI
TA-74. Removed
TA-75. I Fujitsu Reference Data ‘A “Process TAs’ button (similar to the Process TCs” button) on the Acceptance Criteria as per I POL Test
Housekeeping Menu is required to allow them to be processed other than at requirement.
Log On. Its effect will be to invoke the functionality described in section 4.3.3.2 I Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-76. POL Remuneration POL will document and communicate the remuneration model for TA Document Review of Document
acceptance . Remuneration will be based on TA being processed Branch Communications I Review
(doc ref[6})
Note: assume that this has no impact on HNG-X and is handled by existing Ref
data flows.
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 37 of 41
©Post Office™ 2009
8€/90S/4
POL00001535
POL00001535
7 - . , Project: PING
» PING Project (Interfacing Client Data into POL Systems) Doc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone: Description matied
TA-77. I Fujitsu Solution Design Multiples are no longer a problem since the solution is not using mode MG. Statement of
This is the options that had restrictions Fact
TA-78. I Fujitsu Solution Design The solution must replace the manual input of transactional data from off- Statement of
counter equipment into HNG-X by an automated process. This will result in Fact
less TCs having to be produced, ideally none at all.
TA79. I Fujitsu Solution Design Re-use of Mode 14 Bulk input will be utilised for the Transaction Acceptance Document review of HNG- I Document
process X Transaction Acceptance I Review
Solution Design (doc
ref[5))
TA-80. I POL Solution Design The solution should be as automated as possible and require minimal manual Document review of HNG- I Document
intervention, save for the HNG-X TA process. X Transaction Acceptance I Review
Solution Design (doc
ref[5))
TA-81. I Fujitsu Testing and The solution must allow for a trial period to be undertaken to asses the Branch I Document review of HNG- I POL Test
implementation processes, and Help desk facilities X Transaction Acceptance
Solution Design (doc
ref{5])
TA-82. I POL Testing and No impact on client settlement Acceptance Criteria as per I POL Test
implementation requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-63, I POL Testing and The agreed migration approach should be tested, Statement of
implementation Note: this must be seamless to the client Fact
TA-84, I POL Testing and The End to end testing scenarios must include Acceptance Criteria as per I POL Test
implementation + Posting of data in POL FS, requirement.
= Matching, Verification that this
* — Reporting use of control accounts, requirement has been
.- £ ti ri satisfied will be evidenced
xceptions reporting, by the End to End Test
* — Scripts at NBSC, report
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 38 of 41
©Post Office™ 2009
6€/90S/4
POL00001535
POL00001535
» I A , I Project: PING
» PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Description matied
= Review of duty instructions
Note: This will determine the rig requirements for Fujitsu
TA-85. I POL Testing and There must be clear phases for implementation by product eg Camelot, Post Review of migration plan I Document
implementation and Go, Paystation Review
Note: this must include any process for updating POLFS (as defined in section
4.3.2.2)
Note: Assumption is that this is transparent to HNG-X
TA-86. I POL Testing and The standard implementation pattern should be followed, ie model office, limited Statement of
implementation pilot, roll out phases supported by IRF decisions Fact
TA-87. I POL Testing and There must be benefits realisation plan which is agreed and monitored Review of benefits Document
implementation supported by a resource plan within P & BA Realisation plan Review
TA-88. I POL Testing and There must be defined critical success factors for each phase of roll out Statement of
implementation Fact
TA-89. I POL It has been confirmed there is no intention to undertake further promotions at Statement of
this time Fact
TA-90. Logica HNG-X — TA Data Feed I Logica to create TA files at a time specified in the TA AIS Does the solution allow for I Document review
to ensure that Fujitsu can process the data by the required time, as stated in multiple TA files to be
the TA Als. delivered and processed
TA-91 Logica HNG-X — TA Data Feed I The solution must not create TA’s for non HNG-X outlets Acceptance Criteria as per I POL Test
requirement.
Note: this may require some Reference Data to denote a non-HNG-x outlet. Verification that this
These outlets will be catered for under direct settlement requirement has been
satisfied will be evidenced
Note:A non HNG-X outlet is where we have a peice of supplier kit, but, it is not eae End to End Test
a traditional outlet and does not have an HNG-X terminal. However, the client
data should be extracted on the ETL to POL-FS inteface
TA-92. I Logica Camelot Data feed Validation of the Camelot file should be in line with validation performed by Acceptance Criteria as per I POL Test
POL-FS. requirement
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 39 of 41
©Post Office™ 2009
POL00001535
ov/90s/4
POL00001535
- . , Project: PING
PING Project (Interfacing Client Data into POL Systems) D
. oc Ref:
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
ReqiD Supplier Component Description method
TA-93. Requirement removed — see TA-91
TA-94. I Fujitsu Branch Acceptance When a TA is accepted for a Camelot Scratch Card Activation the effect should I Document review of HNG- I POL Test
be the same as the current process. i. it triggers a Rem In transaction for the I X Transaction Acceptance
stock, and adjusts the stock on hand. Solution Design (doc
ref[5})
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-05. I POL Reference Data Rem In to be retired from the counter for Camelot. ‘Acceptance Criteria as per I POL Test
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-96. I Logica Camelot to Tlinterface I Details of Net Adjustments, Commission Sales and Commission Claims from Document review of Field I POL Test
the Trailer record to be loaded into DIW to allow for extraction on the ETL to Mapping Specification for
POL-FS interface. Camelot (doc ref[22]).
The Field Mapping Specification for Camelot is to be amended. Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-97. I Fujitsu/POL I Reference Data The reversal option for Transaction Acceptance’s should be disabled, Acceptance Criteria as per I POL Test
whether it be stock updates or sales. requirement.
Date Printed: Thursday, 28 May 2009 Page 40 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
byi90s/4
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
POL00001535
POL00001535
Project: PING
Doe Ref:
Version: 0.4
Date: 26/05/2009
ReqiD Supplier Component
Description
Acceptance
Acceptance Criteria matied
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
000
Date Printed: Thursday, 28 May 2009
Project PING Requirements Catalogue v0.4.doc4
Page 41 of 41
©Post Office™ 2009