FUJ00091234
FUJ00091234
Project PING Requirements Catalogue
PING Project
(Interfacing Client Data into POL
Systems)
Requirements Catalogue
ROLE NAME AREA OF SIGNATURE DaTE
RESPONSIBILITY
Authors lan Trundell Technical
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: Tuesday, 20 September 2022Thursday,28 May 2009 Page 1 of 41
Project PING
©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: I PING
Project PING boc tet
Requirements Catalogue iad
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
1 CONTENTS
1.1. TABLE OF CONTENTS
1 Contents
~ 1.1 Table of Contents.
1.2 List of Tables
List of Figures.
Ee)
Document Contro!
2.1 Document Information
2.2 Document History.
In
22
2.3 Change Process...
2.4 Changes in this Version
2.
2.
2.
25 Key Contacts..
6 Review Details
leo
oF 1 Purpose
Background
Scope ..
rocess Overview.
Current Camelot Process..
Proposed Camelot Process .
Transaction Acceptance Processe:
4.3.1 Transaction Receipt from the Clieni
4.3.2 Generation of the Transaction Acceptance file.
3 Branch processes to accept the Transaction Acceptance
.3.4 Back-end Systems processes in POLFS.
4.4 Architecture
1 Transaction Integrator.
2 Branch Database
3 XI Changes
4 Transaction Volume:
4.5 Sample Processed Transaction Acceptances Report — Office Copy
5 Requirements Catalogue...
a
1.2 LisTOF 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
RRUYW
RNau
1.3. List OF FIGURES
Date Printed: Tuesday, 20 September 2022Thursday28 May 2009 Page 2 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
Project PING boc tet
Requirements Catalogue eee
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
2 DOocuMENT 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 I As defined in review contacts.
Supplier Distribution —_I Gareth Jenkins — Fujitsu Services
Penny Maguire — Steria
Andrew Fowler — Logica
EDG Team — CSC
Not applicable.
Table 1: Document Information
2.2 DocuMmENT HISTORY
Version Date Reason for Issue Associated
WPICT
Numbers
0.4 10/10/2008 Initial Version
0.2 12/2/2009 Updated to include additional
requirements / clarification
03 20/4/2009 Updated to reflect comments received
after formal review
04 26/05/2009 Updated following document review
Table 2: Document History
2.3 CHANGE PROCESS
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: Tuesday, 20 September 2022Thursday28 May 2008 Page 3 of 41
Project PING ©Post Office™ 2009
@
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
FUJ00091234
FUJ00091234
Project: PING
Doc Ref:
Version: 0.4
Date: 26/05/2009
2.4 CHANGES IN THIS VERSION
Version Changes
03 - General comments updated throughout
04 - General comments updated throughout
2.5 Key CONTACTS
Table 3: Changes in this Version
Penny Maguire
Name Position Telephone
Number
Sally Rush Project Manager
lan Trundell Technical Design Authority
Ann Clarke Business Solution/ Change Manager for Finance
Business Partner Team Group/Finance
Steria — SAP Landscape Architect
Gareth Jenkins
Fujitsu Services Design Authority
Andrew Fowler
Logica Project Manager
2.6 REVIEW DETAILS
Review Comments to:
Mandatory Review Authority
Post Office Ltd:
Chief System Architect
Domain Architect
PING Solution Architect
Business Analyst
IS Architecture / Security
Project Manager
Test Manager
Project Sponsor
Programme Manager
Business Solution Manager
Legal
Service Delivery
Physical Security
Network
P&BA
Agency Remuneration
HNG-X Use Case
Peter Stanley
Don Burgess
lan Trundell
Paul Jepson
Dave M King
Sally Rush
Chris P Young
Rod Ismay
Martin Box
Ann A Clarke
Sarah M White
Steve Beddoe
Danny Boles
Shaun Turner
Dawn Brooks
Chris Howard
Mike Hamill
Fujitsu RMGA
Date Printed: Tuesday, 20 September 2022Thursday28 May 2008
Project PING
Page 4 of 41
©Post Office™ 2009
Project PING
@
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref
Version:
Date:
FUJ00091234
FUJ00091234
PING
04
26/05/2009
Analysis & Solution Specification
Design Authority
Gareth Jenkins
Optional Review/ Issued for Information
Testing
Software Support
Security Howard Pritchard
Customer Services
Logica Andrew Fowler
csc EDG Team representative
Post Office Ltd
Security Manager
Operations Manager
Release Manager
OBC Reference Data Service Manager
Business Strand Lead
Test Manager
Business Analyst
Business Consultant
POL-FS Solution Architect
2.7 ASSOCIATED DOCUMENTS
Sue Lowther
‘Saunder Narayan
Table 5: Review Details
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.
Ref Reference Version Date Title I Source
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 I Tbe Transaction Acceptance to Fujitsu
HNG-X AIS.
8 Tbe PING Business Processes POL
9 Tbe Client take-on process POL
10 I Tbe OLA with CSC (EDG to Tl) csc
41 I Tbe OLA (Fujitsu, Logica, POL) POL
12 I Tbe PING Test Plan POL
Date Printed: Tuesday, 20 September 2022Thursday28 May 2009 Page 5 of 41
Project PING
©Post Office™ 2009
FUJ00091234
FUJ00091234
® Pr tt: = PING
Q Project PING boc tet
Requirements Catalogue eee
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Ref I _ Reference Version I _ Date Title I Source
13 Removed
14 I Tbe PING Exception Process POL
145 I Not Applicable Transaction Acceptance Fujitsu
Processed TA report — included
in document 5 —- HNG-X
Transaction Acceptance
Solution Design initially
16 I The PING Migration Plan POL
17 I 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 I 3.0 6/1/2006 Camelot Outlet Transactions to I POL
Management Information AIS
19 I Tbe Reference Data Definition POL
20 = The Business Process L1/L2 POL
21 Tbe PING Service Definition POL
22 I camelotfield mapping 2.3. 16/10/2008 I Field Mapping Specification for I Logica
specification v2.3.doc Camelot
23 Tbe PING Disputes Process POL
24 I CP08-0011 0.1 15/04/2009 I Client Data Generic Interface POL
25 = The Logica PING Solution Design Logica
approved versions of the documents.
Table 6: Associated Documents
Unless a specific version is referred to above, reference should be made to the current
Date Printed: Tuesday, 20 September 2022Thursday28 May 2009
Project PING
Page 6 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Project: PING
Project PING Boe Ref
Requirements Catalogue eee
Version: 0.4
COMMERCIAL IN CONFIDENCE
Date: 26/05/2009
2.8 ABBREVIATIONS/DEFINITIONS
Abbreviation Definition
Als 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:/www.whatis.con/
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: Tuesday, 20 September 2022Thursday28 May 2008 Page 7 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
Project: PING
Project PING 5 ret
Requirements Catalogue oe Re
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: Tuesday, 20 September 2022Thursday28 May 2008 Page 8 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
Project: PING
Project PING boc tet
Requirements Catalogue eee
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: Tuesday, 20 September 2022Thursday28 May 2008 Page 9 of 41
Project PING ©Post Office™ 2009
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref
Version:
Date:
FUJ00091234
FUJ00091234
PING
04
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
_Braneh Summary. __-Branch Summary
Tus
4
Ss eZ
Herzon -
Buk Entry _ a
POLFS reconciles values
Ds Horizon Value £1000
4 K, Camelot Value £1000
Buk Exty
Camelot
——__Datypranen
Data
POLFS.
Daily Branch
Transactions are undertaken at the Camelot terminal, eg Sale of Lottery Ticket
2. Atthe 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: Tuesday, 20 September 2022Thursday,28 May-2009
Project PING
Page 10 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Project: PING
Project PING boc tet
Requirements Catalogue eee
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).
1. Camelot provide a summary of transactions undertaken via the Lottery terminal
which is passed to POLFS via EDG as contractually required
2. POL TI will create a Transaction Acceptance record for the branch indicating the
value of transactions undertaken
3. 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
4. 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 Tl) 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: Tuesday, 20 September 2022Thursday28 May 2008 Page 11 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
‘ Project: PING
Q Project PING boc tet
Requirements Catalogue eee
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/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)
co Where the Client has a current interface or is not willing to migrate to the generic
Transaction Integrator interface
4.3.2.1 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: Tuesday, 20 September 2022Thursday-28 May 2009 Page 12 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
‘ Project: PING
Q Project PING boc tet
Requirements Catalogue iad
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
( a
Ss bd
Transaction
Integr
. N craeta I Gree POU aa y
Camalet
4.3.2.2 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.
oc The data will be pre-processed to transform it into the standard POL TI interface (see doc
ref[x])
co 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 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: Tuesday, 20 September 2022Thursday28 May 2009 Page 13 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
Project PING pie EN
Requirements Catalogue iad
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
r
TRANSACTION ACCEPTANCE FOR CAMELOT
/ \
& et poses
const
XX 7
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: Tuesday, 20 September 2022Thursday28 May 2009 Page 14 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
‘ Project: PING
Q Project PING boc tet
Requirements Catalogue iad
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
Camelot Pd
4.3.3.1 Log On
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.
4.3.3.2 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: Tuesday, 20 September 2022Thursday28 May 2009 Page 15 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
. Project! PING
Q Project PING boc tet
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
I I ees a
Screen
Entry
1
Car
melot 1 Lottery Sales Cash £523.00 Select Buspenc)
Lock
19) 12
Post & Go 2 Label Sales Plastic £ 20.54 PG1 ‘Select
29
Post & Go 2 Stamp Sales Cash £200.45, PG1 ‘Select Previous
39 PREV)
Camelot 1 Instants £5 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: Tuesday, 20 September 2022Thursday,28-May2009 Page 16 of 41
Project PING ©Post Office™ 2009
Project: PING
q Project PING boc tet
Requirements Catalogue iad
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/21
FUJ00091234
FUJ00091234
009
4.3.4 Back-end Systems processes in POLFS
4.3.4.1. 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.
{otal for day for branch
(Dr Cash (total for day for branch)
(Dr cheques (total for day for branch)
y \ Dr Debit cards (excludes Paystation/Post & Go}
. ( WPUTABO1 —»>_DrOther methods of payment
{ Finance Posting \-».cr Paystation contra to Cash
\ site = Various ie FAD Code / (Ct Paystation contra to Cheques
N / Gr Post&Go contra to Cash
Cr Anon Customer
/ WPUUMSO1
‘ ‘Aggregate Sale i
Lb by Prot Cente (ranch)
\ Sito = Various ie. FAD Code I by Article $A00000115 ete
00 19U Pinoys Bupesto
BROWS BUTS
a ~ [Dr ETL Idoc Cont
(e.g.
a / + "by Atle Sac0000118 ete
5 / WPUFIBO1 = by Paystaton’ Posthico
] { Finance Posting les ov oay
Us ‘Site = A000 I (CrVendore.g. 120025 (GL 620100) -.
) Ie “ppt Sac00001 15
by Day
Dr Contra to Cash/ Cheques
+ by Prof Cenre (ranch)
+ by Day
Dr Debit Card Payments
+ by Profit Cerre (Branch)
+ by Dey
\Cr Anon Customer (GL 532110)
+ by Day
/_ WPUTABO1
(Method of Payment
\ Site = Various ie. FAD Code
4.3.4.2 Transaction Integrator to send to branch and update POLFS (control)
As described in Section 4.3.2.2, existing Client data, such as Camelot update the Vendor accoun'
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 tha’
use HNG-X mode 14 SC-Sale to Customer, where Settlement=C.
-SBUESK PIES TRG 16} GIS TOU Op SBURSOT SRL
“youesg Aq 13 / Uo2IOH Uaanjaq da:28Ip MoUs JOU 4 "0 0} JU Pinoys BuLe=I
it via
t will
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: Tuesday, 20 September 2022Thursday28 May 2009 Page 17 of 41
Project PING ©Post Office™ 2009
@®
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref
Version:
Date:
FUJ00091234
FUJ00091234
PING
04
26/05/2009
2
Hy
a
to°C" (sourced from
RDS) f
aa ator
/
Date Printed:
Project PING
Tuesday, 20 September 2022Thursday,-28-May-2009
Page 18 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
‘ Project: PING
Q Project PING boc tet
Requirements Catalogue eee
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
I des
BOX!
Transaction Data
received from
Client
Transaction
Acceptance records
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: Tuesday, 20 September 2022Thursday28 May 2008 Page 19 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
‘ Project: PING
Q Project PING boc tet
Requirements Catalogue iad
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.
Sales & AP > POL FS- Retain fr 90 days
a Glents.- Retain for 2 years
‘Non Sales - REMs, Revaluation etc. ~ Retain 99 days
Events ~ Log on ete. ~ Retain 90 days I tae Traneacion Su
ee
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: Tuesday, 20 September 2022Thursday28 May 2009 Page 20 of 41
Project PING ©Post Office™ 2009
FUJ00091234
FUJ00091234
Project: PING
= PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue 7
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
4.5 SAMPLE PROCESSED TRANSACTION ACCEPTANCES REPORT — OFFICE COPY
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 4 2 3 4
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
o1 Feltham Post Office FAD 123456X Page 1
02 11:42 08/04/2009 TP O1
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
un
12 21/03/04 22/03/04 Serve Customer P123456789012345678 INV Label Sales Plastic 20.54 Post & Go 2 PG1
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: Tuesday, 20 September 2022Thursday,-28-May-2009 Page 21 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
(i)
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091234
FUJ00091234
PING
0.4
26/05/2009
5 REQUIREMENTS CATALOGUE
Acceptance
ReqID Sup Compone' Acceptance Criteria shri
TA- Fujitsu Branch Acceptance Branches should be provided with an opportunity to compare locally held Document review of HN 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
ref[5])
TA-02. I 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[5])
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 22 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
e& PING Project (Interfacing Client Data into POL Systems) Masri rine
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqID Sup} Compone: n Acceptance C: cosets
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 will be 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: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 23 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
Q PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqID Sup} Compone: Acceptance Criteria cosets
TA-07. I 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, 4
the TA MUST be accepted. Aecopnance Crtenia asiper
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 Criteriaas 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: Tuesday, 20 September 2022Thursday,28-May-2009 Page 24 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
FUJ00091234
FUJ00091234
Project. PING
Q PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqID Sup} Compone: Description Acceptance Criteria cosets
TA-10. I Fujitsu Branch Acceptance Transaction Acceptance must be restricted to roles Controlled by reference data asi deal Criteria as per I POL Test
requirement.
Note: the Likelihood is that this will be restricted to Supervisor and Manager Verification that this
roles. requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-11. I Fujitsu Branch Acceptance Where the User selects a TA the solution must present the Manager or Acceptance Criteriaas per I POL Test
Supervisor with detail of the TA requirement.
Verification that this
Note: the AIS and Solution Outline design work will define the actual screens requirement has been
satisfied will be evidenced
by the End to End Test
report
TA-12. I POL Branch Acceptance Branches should have a daily routine at start of day to accept data for the Review of Transaction Document review
previous business day, this may vary as branches have different opening times I Acceptance Branch
Communications (doc ref
[6]) and PING Business
Processes (doc ref[8])
TA-13. POL Branch Acceptance Clear operational instructions for users, including steps to be taken if client data I Review of Transaction Document review
does not reconcile with locally held information Acceptance Branch
Communications (doc ref
[6]) and PING Business
Processes (doc ref[8])
TA-14. I POL Branch Acceptance Provision should be made for core/outreach outlets which operate on a Document review of Document
temporary basis Transaction Acceptance to I Review
HNG-X AIS (see doc
Reff7]) and HNG-X
Transaction Acceptance
Solution Design (doc
ref[5])
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 25 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
c Acceptance
ompone: Acceptance Criteria dente
TA-15. I POL 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 po
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 1 2
ATM 1 1 1
10
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 26 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
FUJ00091234
FUJ00091234
PING Project (Interfacing Client Data into POL Systems) Masri aaa
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Compone' Acceptance Ci ea peie©
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 I Acceptance Criteria as per I POL Test
Acceptance Report the Solution Outline Design (see Doc Ref [5]) to show the products where TA __I 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
(see doc ref{8})
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 27 of 41
©Post Office™
2009
FUJ00091234
FUJ00091234
Pr tt: PING
PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone: Description Acceptance C: ia aan
POL Business Process POL will document the Exception process, eg what to doc if Duplicate TA’s are I Document review of Document
received into POLFS, what happens if ETL sends 2 files? Transaction Acceptance Review
Exception Process see
doc ref{14])
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 TI shall be validated to ensure it conforms to the Acceptance Criteria as per I POL Test
Als 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. 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
ref[9])
TA-29. I POL HNG-X - Stock Any solution should improve stock management in HNG-x if the client provides I Document review of HNG- I Document
stock data. X Transaction Acceptance I Review
Solution Design (doc
ref[5])
I Date Printed: Tuesday, 20 September 2022Thursday-28 May 2000
Project PING Requirements Catalogue v0.4.doc4
Page 28 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Project. PING
Q PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
ReqID Sup} Compone: Acceptance Criteria cosets
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 Review of OLA (see doc Document review
Logica in place relating to management of non delivery [11])
TA-33. 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. I 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 byumie End to Enel Test
conventions and interface directories report
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 29 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
(i)
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
PING
0.4
26/05/2009
FUJ00091234
FUJ00091234
ReqID Sup
TA-35.
Fujitsu /
Logica
Compone!
HNG-X — TA Data Feed
The solution must cater for one or more Transaction Acceptance files to be
received daily.
Acceptance Criteria
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
Acceptance
method
POL Test
TA-36.
Fujitsu /
Logica
HNG-X — TA Data Feed
The TA feed should allow credits and debits in the same file.
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 Joint Test report
POL Test
TA-37.
Fujitsu /
Logica
HNG-X — TA Data Feed
The TA feed to HNG-X should be documented in an Interface Specification
Document Review of the
Transaction Acceptance to
HNG-X AIS (see doc
Reff7])
Document
Review
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 30 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
Q PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
ReqID Sup Compone: Acceptance C: ia aan
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. I 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.
Reff7])
Note: Where no TA files are received, Fujitsu should raise an Alert (see TA-xx)
TA-40. I 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 AIS. 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 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 returned 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 retumed to Logica, where the files will be rectified [11])
and re-presented to HNG-X.
TA-43. I POL HNG-X — TA Data Feed I Management of calls from agents to be handled via NBSC, relating to missing Review of OLA (see doc Document review
client data. Data gathered as a result of calls to be used as part of OLA/ORF [11]})
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 31 of 41
©Post Office™ 2009
e& PING Project (Interfacing Client Data into POL Systems) Masri aaa
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
process
TA-44. I POL/Logica I 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
Reff7])
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. 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: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 32 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
FUJ00091234
FUJ00091234
e& PING Project (Interfacing Client Data into POL Systems) Masri aaa
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
ReqID Sup, Compone' Acceptance Criteria dente
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 via a Ref[7]) and HNG-X
TA Transaction Acceptance
Solution Design (doc
ref[5])
TA-49. I 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
ref[5]) and Document
Client review of Logica PING
Steria Solution Design (see doc
Ref[25])
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 33 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
FUJ00091234
FUJ00091234
PING Project (Interfacing Client Data into POL Systems) Masri aaa
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
c Acceptance
ompone: Acceptance Criteria dente
TA-52. I Logica 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 TI 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 in Exception reporting of non accepted transactions, if possible with root cause Document review of HNG- I Document
POL FS analysis, and by age eg non polling, core/outreach or part time branch, disputed I X Transaction Acceptance I Review
values Solution Design (doc
ref[5]) and Logica PING
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 34 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone' Description Acceptance Criteria dente
Solution Design (see doc
Ref[25])
TA-56. I POL! Posting and controls in The solution should support current contractual obligations for POL including for I Document review of HNG- I Document
Logica POLFS 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-57. I Fujitsu Posting and controls in 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. I 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 ref[5}) and Logica PING
Solution Design (see doc
Ref[25])
TA-59. I 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. 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
and any of its interfaces
I Date Printed: Tuesday, 20 September 2022Thursday-28 May 2000
Project PING Requirements Catalogue v0.4.doc4
Page 35 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Project. PING
PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone' Description Acceptance Criteria dente
POL Receipt of client data Clear timescales to be agreed for client corrections Review of OLA (see doc Document review
(11)
TA-64. I 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 AIS production HNG-X AIS (see doc
Ref[7]) and
Document review of HNG-
X Transaction Acceptance
Solution Design (doc
ref[5])
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
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])
I Date Printed: Tuesday, 20 September 2022Thursday, 28-May-2009 Page 36 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
FUJ00091234
FUJ00091234
Project. PING
PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Compone' Description Acceptance Criteria dente
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. I POL/ Fujitsu I 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
TA-73. I POL Reference Data Reference data shall 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. I 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 Review
(doc ref{6])
Note: assume that this has no impact on HNG-X and is handled by existing Ref
data flows.
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
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 37 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
Q PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
ReqID Sup, Compone' n dente
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.
TA-79. 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 Document review of HNG- I POL Test
implementation processes, and Help desk facilities X Transaction Acceptance
Solution Design (doc
ref[5])
TA-62. 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-83. 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
. requirement has been
. inline use of control accounts, satisfied will be evidenced
pice pons! MSPperung, by the End to End Test
= Scripts at NBSC, report
= — Review of duty instructions
Note: This will determine the rig requirements for Fujitsu
Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 38 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
FUJ00091234
FUJ00091234
Pr tt: PING
PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Compone' Acceptance Criteria ea peie©
ui c method
POL Testing and There must be clear phases for implementation by product eg Camelot, Post Review of migration plan 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. 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. 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. I 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 AIS. delivered and processed
TA-91. I 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, itis not Reet Ered tp 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
report
TA-93. Requirement removed — see TA-91
I Date Printed: Tuesday, 20 September 2022Thursday,28-May-2009 Page 39 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
(i)
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091234
FUJ00091234
PING
0.4
26/05/2009
Req ID
TA-
Sup
Fujitsu
Compone!
Branch Acceptance
When a TA is accepted for a Camelot Scratch Card Activation the effect should
be the same as the current process. i.e. it triggers a Rem In transaction for the
stock, and adjusts the stock on hand.
Acceptance Criteria
Document review of HNG-
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
Acceptance
method
POL Test
TA-95.
POL
Reference Data
Rem In to be retired from the counter for Camelot.
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-96.
Logica
Camelot to TI interface
Details of Net Adjustments, Commission Sales and Commission Claims from
the Trailer record to be loaded into DIW to allow for extraction on the ETL to
POL-FS interface.
The Field Mapping Specification for Camelot is to be amended.
Document review of Field
Mapping Specification for
Camelot (doc ref[22]).
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-97.
Fujitsu / POL
Reference Data
The reversal option for Transaction Acceptance's should be disabled,
whether it be stock updates or sales.
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
POL Test
Date Printed: Tuesday, 20 September 2022 Thursday, 28-May-2009
Project PING Requirements Catalogue v0.4.doc4
Page 40 of 41
©Post Office™ 2009
FUJ00091234
FUJ00091234
Pi tt: I PING
Gg PING Project (Interfacing Client Data into POL Systems) bo ret
Requirements Catalogue Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
Acceptance
Acceptance Criteria freiiiodI
ReqID Supplier Component Description
by the End to End Test
report
000
Page 41 of 41
Date Printed: Tuesday, 20 September 2022Thursday28 May 2009
©Post Office™ 2009
Project PING Requirements Catalogue v0.4.doc4