FUJ00091292
FUJ00091292
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.5
Date Printed: Monday, 22 June 2009 Page 1 of 41
Project PING
©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/2009
1 CONTENTS
1.1 TABLE OF CONTENTS
1 Contents.............
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 Details...
2.7 Associated Document:
2.8 Abbreviations/Definition
3 Introduction..
3.1 Purpose.
3.2 Background...
3.3. Scope9
4 Process Overview.
4.1 Current Camelot Process
4.2 Proposed Camelot Proces:
4.3. Transaction Acceptance Processes.
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. oe
4.4.1 Transaction Integrator.
4.4.2 Branch Database.
4.4.3 XI Changes....
4.4.4 Transaction Volumes.
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 Do
Table 7: Abbreviations/Definitions.
NOOR RWW
1.3. LisT OF FIGURES
Date Printed: Monday, 22 June 2009 Page 2 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
° Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/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 As defined in review contacts.
Distribution
Supplier Distribution I Gareth Jenkins — Fujitsu Services
Penny Maguire — Steria
Andrew Fowler — Logica
EDG Team - CSC
Client Distribution Not applicable.
Table 1: Document Information
2.2 DOCUMENT HISTORY
Version Date Reason for Issue Associated
WPICT
Numbers
0.1 10/10/2008 Initial Version
0.2 12/2/2009 I 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
0.5 22/06/2009 Updated following document review
Table 2: Document History
Date Printed: Monday, 22 June 2009 Page 3 of 41
Project PING ©Post Office™ 2009
@
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE.
FUJ00091292
FUJ00091292
Project: PING
Doc Ref:
Version: 0.5
Date: 22/06/2009
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
2.4 CHANGES IN THIS VERSION
Version Changes
03 - General comments updated throughout
04 - General comments updated throughout
05 - General comments updated throughout
2.5 KEY CONTACTS
Table 3: Changes in this Version
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
Penny Maguire
Gareth Jenkins
Steria - SAP Landscape Architect
Fujitsu Services Design Authority
Andrew Fowler
Logica Project Manager
2.6 REVIEW DETAILS
Table 4: Key Contacts
Review Comments to:
Name & Email
paul jepson@
Mandatory Review Authority
Name
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
Peter Stanley
Don Burgess
lan Trundell
Paul Jepson
Dave M King
Sally Rush
Chris P Young
Rod Ismay
Martin Box
Ann A Clarke
Date Printed: Monday, 22 June 2009
Project PING
Page 4 of 41
©Post Office™ 2009
@
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE.
Project:
Doc Ref:
Version:
Date:
FUJ00091292
FUJ00091292
PING
0s
22/06/2009
Legal
Service Delivery
Physical Security
Network
P&BA
Agency Remuneration
HNG-X Use Case
Fujitsu RMGA
Analysis & Solution Specification
Design Authority
Testing
Software Support
Security
Customer Services
Logica
Sarah M White
Steve Beddoe
Danny Boles
Shaun Turner
Dawn Brooks
Chris Howard
Mike Hamill
Gareth Jenkins
Howard Pritchard
Andrew Fowler
csc
Optional Review/ Issued for Information
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
EDG Team representative
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 I Reference Version
Date Title I Source
1 RS1712
2 I EA/IFS/002
Trial to manually interface Camelot I POL
client data into POL systems
POL FINANCE SYSTEMS TO Steria
TMS/HORIZON (PRISM)
TRANSACTION CORRECTIONS,
INTERFACE SPECIFICATION
3 I ETL Interface?
4 RS1576 / CP09-0079 Interfacing Client Data in POL POL
Systems
5 DES/APP/DPR/0006 HNG-X Transaction Acceptance Fujitsu
Solution Design
6 Tbe PING Branch Communications POL
Date Printed: Monday, 22 June 2009 Page 5 of 41
Project PING
©Post Office™ 2009
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE.
FUJ00091292
FUJ00091292
Project: PING
Doc Ref:
Version: 0.5
Date: 22/06/2009
7 REQ/APPYAIS/004 narsaction Acceptance to HNG-X Fujitsu
8 I Tbe PING Business Processes POL
9 I Tbe Client take-on process POL
10 I Tbe OLA with CSC (EDG to TI) csc
11 I Tbe "OLA (Fujitsu, Logica, POL) "POL
12 I Tbe I PING Test Plan / POL
13 I Removed I
14 The I PING Exception Process "Po
15 I Not Applicable I Transaction Acceptance Processed I Fujitsu
TA report — included in document 5
= HNG-X Transaction Acceptance
Solution Design initially
16 I Tbe I PING Migration Plan I POL
17 I Benefit Profile - PING 04 20/05/2009 I PING Benefits Realisation Plan I POL
v0.1.doc
18 I PSO/SBO/EZE/SOLIO79 I 3.0 6/1/2006 I Camelot Outlet Transactions to. POL
Management Information AIS
19 I Tbe I Reference Data Definition I POL
20 I Tbe I Business Process L1/L2 I POL
21 I Tbe I PING Service Definition I POL
22 I camelot field mapping 23 16/10/2008 I Field Mapping Specification for Logica
specification v2.3.doc Camelot
23 I Tbe PING Disputes Process POL
24 I CP08-0011 04 16/04/2009 I Client Data Generic Interface POL
25 I 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: Monday, 22 June 2009
Project PING
Page 6 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
° Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/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
Tl Transaction Integrator
TIS Technical Interface Specification
TMS Transaction Management System
Table 7: Abbreviations/Definitions
Other generic IT terms can be looked up at: /htto://www.whatis.com/
Term Definition
Paystation Plus I 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: Monday, 22 June 2009 Page 7 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/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: Monday, 22 June 2009 Page 8 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/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: Monday, 22 June 2009 Page 9 of 41
Project PING ©Post Office™ 2009
@
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE. Date: 22/06/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.
ranch Summary Branch Surrey
POLFS reconciles values I
Horizon Value £1000 ay branch
Camelot Value £1000 aa
Buk erty
Camect I mo
Daly Branch
Data
1. Transactions are undertaken at the Camelot terminal, eg Sale of Lottery Ticket
2. At the end of day the Clerk should request a Branch On line summary — this
shows the monies taken by the camelot terminal
The Clerk needs to take monies from the Camelot till and enter into the Branch
accounts via HNG-X.
The Branch input data is captured and passed to POLFS
Camelot provide a summary of transactions undertaken via the terminal and send
it to POLS (via EDG) which is a contractual required for settlement
A manual reconciliation process in POLFS reconciles the values between the 2
data streams (eg £1000 as show in the example above)
Transaction Corrections (TC’s) are issued where the reconciliation fails
4.2 PROPOSED CAMELOT PROCESS
Date Printed: Monday, 22 June 2009 Page 10 of 41
Project PING
©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/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 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: Monday, 22 June 2009 Page 11 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/2009
7
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
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
© 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: Monday, 22 June 2009 Page 12 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE. Date: 22/06/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
Torun Rowe POLES
oman
Transaction
Integrator
“Transact invgrfor Process
Create TA I Crate POLFS data
Camelot
_——
Traractons
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.
© The data will be pre-processed to transform it into the standard POL TI interface (see doc
ref[x])
° Fee ction 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: Monday, 22 June 2009 Page 13 of 41
Project PING ©Post Office™ 2009
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE.
FUJ00091292
FUJ00091292
Project: PING
Doc Ref:
Version: 0.5
Date: 22/06/2009
TRANSACTION ACCEPTANCE FOR CAMELOT
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.
TRANSACTION ACCEPTANCE FOR CAMELOT
Pours
Date Printed: Monday, 22 June 2009
Project PING
Page 14 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
. Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE.
Date: 22/06/2009
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.
Help
‘Post&Go2 LabelSales Plastic £2054 PGI
I Post& Go2 Stamp Sales Cash £200.45, PGI
[Camelot 1 Instants £5 400 CAI
i
Page [Page Page
Up [Down I Ky
‘USERAA” TRTT BPoTT SU: A2B Shared Serve Customer
Figure 1 - TA Summary
Figure 1 is a rough attempt at what could be displayed. N.B The corresponding figure in the Design
Proposal will be the definitive version. \t shows 4 TAs. Any of them can be selected using the Select
buttons to look at the full details of the TA.
Date Printed: Monday, 22 June 2009 Page 15 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE
Date: 22/06/2009
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.
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 REC.
N.B When mode 14 is re-instated on HNG-X it is to be called ‘Transaction Acceptance’.
Date Printed: Monday, 22 June 2009 Page 16 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE. Date: 22/06/2009
Fi Document (Doc Type = RV)
Iota for day for branch
Dr Cash (total for day fr branch)
Dr cheques (total fr day for branch)
. - ~. Dr Debit cards excludes Paystaton/Post & Goll I
IN / weurasot Dr Other methods of payment
> Finance Posting I-»/Cr Paystation contra to Cash
Site = Various ie FAD Code) ICr Paystation contra to Cheques
V °/ (Cr posto conta to Cash
(Cr Anon Customer
WPUUMS01
Aggregate Sale a
Lope" yet centre Branch
ite = Various ie. FAD Code I byAricle SxODO00"IS ete
/ — I* by Paystation Poss Go
FiDocument (Doc Type
IDr ETL Idoe Control( e.g. G
by Amite $A00000115 ete
WPUFIBO1 by Paystation/ Posto
Finance Posting by Day
\ Site = A000 + Vendor e.g. 120025 (GL 620100) .-
\ I» byAMticle 5800000115
by Day
- ‘+ by Profi Centre (Branch)
+ byDay
/WPUTABO1 =r Debit Card Payments
{Method of Payment II_ y+ by Proft Centre (Branch)
Site = Various i.e. FAD Code [+
Cr Anon Customer (GL 632110)
+ by Day
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 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 REC, 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: Monday, 22 June 2009 Page 17 of 41
Project PING ©Post Office™ 2009
Project PING
Requirements Catalogue
COMMERCIAL IN CONFIDENCE.
FUJ00091292
FUJ00091292
Project: PING
Doc Ref:
Version: 0.5
Date: 22/06/2009
WPUUMSO1
Aggregate Sale
‘SD cong + POLS Atle Master AAG
onto posting o 627°"
WPUFIBOY NOT generated)
WPUTABO1
Finance Posting
Ne
WPUFIBO1 fees
Finance Posting
me Settlement
ito teeny 627°" + by Article (Product)
2
Batch session
Program ZIFX0043 & entry on ZINTMAP -—P>
contol GL Account postings
‘Dr Cash / Near Cash
(€9. 551100 ete)
Cr Dummy Customer ~
type = VEN1. If transaction Type = VEN2
Dr GL Account
Cr GL Account
FI Document (Doc Type = RV)
Dr Dummy Customer...
+ byDay
Cr Client Actuals Control 627°**
Where MM = Month
by Profit Centre (Branch)
by Article (Product)
by Day
FI Document (Doc Type = RV)
by Proft Centre (Branch)
by Day
Biiipitegy SuOnASSKS S WoT
by Day
FI Document (Doc Type = KC)
jote: below signs are where Transaction
then DriCR are reversed
Dr Client Actuals Control 627°"*
by Article (Product)
by Day
FI Document (Doc Typ
by Profit Centre (Branch)
by Article (Product)
by Day
by Profit Centre (Branch)
by Article (Produ
by Day
Date Printed: Monday, 22 June 2009
Project PING
Page 18 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
. Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE.
Date: 22/06/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 Obecis
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: Monday, 22 June 2009 Page 19 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
q Project PING Project: PING
Requirements Catalogue Doc Ref:
Version: 0.5
COMMERCIAL IN CONFIDENCE.
Date: 22/06/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.
LI
Sales & AP > POL FS - Retain for 0 days
» Chants. Retain for 2 years
Non Sales ~ REMSs, Revaluation ate — Retain 90 days
Events ~ Log on etc. ~ 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: Monday, 22 June 2009 Page 20 of 41
Project PING ©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref:
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 1 2 3 4
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
on 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
o7
08 21/03/04 22/03/04 abcdefghijklmn N123456789012345678 CRM I 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
Fey
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.
N.B The corresponding figure in the Design Proposal will be the definitive version
Date Printed: Monday, 22 June 2009 Page 21 of 41
Project PING Requirements Catalogue v0.4.doc4 Post Office™ 2009
@
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091292
FUJ00091292
PING
0.4
26/05/2009
5 REQUIREMENTS CATALOGUE
ReqID Suppl Component Acceptance Criteri Ashita hi
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
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 satisfied will be evidenced
purely for the TAs to be processed in that SU and the remainder of the Log On I by the End to End Test
to 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 Document
progress to serve customers until initial logon (start of day) processes have X Transaction Acceptance I Review
been completed Solution Design (doc
reflS]) POL Test
Acceptance Criteria as per
requirement
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
Date Printed: Monday, 22 June 2009 Page 22 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref:
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
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 Document
the current SU is not appropriate (ie it is SU DEF). X Transaction Acceptance I Review
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 I ref{5]) POL Test
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 Document
override to change or alter the client data value should be made available. X Transaction Acceptance I Review
Solution Design (doc
ref5)) POL Test
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
Date Printed: Monday, 22 June 2009 Page 23 of 41
Project PING Requirements Catalogue v0.4.doc4 Post Office™ 2009
@
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091292
FUJ00091292
PING
0.4
26/05/2009
TA-07.
Fujitsu
Branch Acceptance
The solution must ensure that TA is undertaken in the correct stock unit
Note: Manager and Supervisor roles may logon to a default Stock Unit
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
Document
Review
POL Test
TA-08.
Fujitsu
Branch Acceptance
The solution must only allow the Branch Transaction Acceptance records to
be ‘accepted’
Note: where a branch has a genuine issue a query must be raised. The TA
may 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.
Document review of HNG-
X Transaction Acceptance
Solution Design (doc
reff5})
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
Document
Review
POL Test
TA-09.
Fujitsu
Branch Acceptance
The solution must present the Manager or Supervisor with a list of All
outstanding TA’s
Note: see sample screen at Section 4.3.3.2. This will be refined during the
Solution Design.
Acceptance Criteria as per
requirement
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
POL Test
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 24 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doe Ref:
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TA-10. I Fujitsu Branch Acceptance Transaction Acceptance must be restricted to roles Controlled by reference Acceptance Criteria as per I POL Test
data requirement.
Verification that this
Note: the Likelihood is that this will be restricted to Supervisor and Manager requirement has been
roles 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 Criteria as 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 Acceptance Branch
times Communications (doc ref
[6]) and PING Business
Processes (doc ref[8])
TA-13. I POL Branch Acceptance Clear operational instructions for users, including steps to be taken if client Review of Transaction Document review
data does not reconcile with locally held information Acceptance Branch
Communications (doc ref
[6]) and PING Business
Processes (doc ref[8])
TA-14. I Fujitsu/POL I 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
Ref[7]) and HNG-X
Transaction Acceptance
Solution Design (doc
reff5])
TA-15. I Fujitsu/POL I Branch Acceptance The solution must consider the “legal” issues regarding Transaction Document review of HNG- I Document
Acceptance and the fact that the TA affects the stock and cash position at the I X Transaction Acceptance I Review
Branch Solution Design (doc
ref[5])
Date Printed: Monday, 22 June 2009 Page 25 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
@
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
FUJ00091292
FUJ00091292
Project: PING
Doc Ref:
Version: 0.4
Date: 26/05/2009
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 I 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 a back-stop
TA-17. I Fujitsu Branch database The Transaction Acceptance volumes will be in the order of 20,000 records Statement of fact
per 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 1 3 3
Camelot 2 * 1 MOP. 2 1 2
ATM 4 1 1
10
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
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 26 of 41
©Post Office™ 2009
@
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
FUJ00091292
FUJ00091292
Project: PING
Doc Ref:
Version: 0.4
Date: 26/05/2009
TA-19. I Fujitsu
Branch Transaction
Acceptance Report
The solution must provide a Daily Transaction Acceptance report as defined in
the Solution Outline Design (see Doc Ref [5]) to show the products where TA
has been accepted and any TA’s that are outstanding.
Note: The content must show
Acceptance Criteria as per I POL Test
requirement.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
* Date report
« = Product
e = =©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 Document review of Document
with 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])
TA-22. I 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 reff20})
TA-24, I POL Business Process POL to document the Service Definition document Document review of Document
Transaction Acceptance I Review
Date Printed: Monday, 22 June 2009 Page 27 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091292
FUJ00091292
PING
0.4
26/05/2009
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
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 I take on process (see doc Review
what impact there is at the counter for TA / reference data / stock movement _I ref [9])
etc
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 Document review of Client I Document
existing clients will utilise the Transaction Acceptance process Take-on process (see doc I Review
ref[9])
TA-29. I Fujitsu/POL I HNG-X - Stock Any solution should improve stock management in HNG-x if the client Document review of HNG- I Document
provides stock data X Transaction Acceptance I Review
Solution Design (doc
reff5])
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
reff7])
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
Date Printed: Monday, 22 June 2009 Page 28 of 41
Project PING Requirements Catalogue v0.4.doc4
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref:
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
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 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
reff7])
TA-34. I Fujitsu HNG-X — TA Data Feed I The solution must cater for Transaction Acceptance records which will be sent I 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
TA-35. I Fujitsu / HNG-X — TA Data Feed I The solution must cater for one or more Transaction Acceptance files to be Document Review of the POL Test
Logica received daily. 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
Date Printed: Monday, 22 June 2009 Page 29 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref:
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TA-36. I Fujitsu / HNG-X — TA Data Feed I The TA feed should allow credits and debits in the same file. Document Review of the I Document
Logica Transaction Acceptance to I Review
HNG-X AIS (see doc
ref7]) 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 Document Review of the Document
Logica Transaction Acceptance to I Review
HNG-X AIS (see doc
Ref{7])
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 Document
validated and any error files generated and returned. requirement Review
Verification that this
requirement has been POL Test
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 Document Review of the Document review
Logica 08:00). The Fujitsu solution should check for the existence of TA files between I Transaction Acceptance to
the 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)
Date Printed: Monday, 22 June 2009 Page 30 of 41
Project PING Requirements Catalogue v0.4.doc4 ©Post Office™ 2009
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version
Date:
FUJ00091292
FUJ00091292
PING
0.4
26/05/2009
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 I 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 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- I Acceptance Criteria as per I POL Test
X and have been returned to Logica. Such that the files will be rectified and re- I 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 I [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 I Review of OLA (see doc Document review
client data. Data gathered as a result of calls to be used as part of OLA/ORF I [11])
process
TA-44. I Fujitsu / POL I HNG-X — TA Data Feed I The TA feed to HNG-xX should include the following detail :- Document Review of the Document
/ Logica * by Branch Transaction Acceptance to I Review
© by Terminal ID (Kiosk Id) Retr AIS (see doc
* by Product POL Test
* by Day 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
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 31 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doe Ref:
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TA-46. I Logica HNG-X- TA Interface Where the Client data cannot be changed (i.e. Camelot), the information must I 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 Fujitsu / I HNG-X- TA Interface POL TI shall transform specific Client files to the Generic POL Tl AIS schema I Document Review of the Document
Logica (names of these clients shall be advised by POL). Transaction Acceptance to I Review
HNG-X AIS (see doc
Note : this requirement is only for files from Clients that are unwilling to use Ref[7]) POL Test
the 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
TA-48. I Fujitsu HNG-X- TA Interface The solution must allow for stock adjustments to be undertaken for activation Document review of Document
of 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 I Ref[7]) and HNG-X
Transaction Acceptance
Solution Design (doc
ref[5])
Ta-49. I POL HNG-X- TA Interface Data provided to Fujitsu Services must distinguish between Transaction Requirement no longer NIA
Corrections and Transaction Acceptance relevant as solution design
has moved to discrete TA
Note: this applies to both file and record level
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
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 32 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref.
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TA-51 Fujitsu HNG-X- TA Interface The solution must ensure that files can be traced through the systems to Document review of HNG- I Document
Logica ensure 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])
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 I Verification that this
. 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 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 requirement has been
the 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
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 33 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref.
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
back to POL FS from both streams and matches off.
TA-55. I Fujitsu / POL I Posting and controls in I Exception reporting of non accepted transactions, if possible with root cause I Document review of HNG- I Document
/ Logica POL FS analysis, and by age eg non polling, core/outreach or part time branch, X Transaction Acceptance I Review
disputed values Solution Design (doc
ref[5]) and Logica PING
Solution Design (see doc
Ref[25])
TA-56. I Fujitsu 7 POL I Posting and controls in I The solution should support current contractual obligations for POL including I Document review of HNG- I Document
/ POL FS for example settlement on client data X Transaction Acceptance I Review
Logica Solution Design (doc
ref[5]) and Logica PING
Solution Design (see doc
Ref[25])
TA-57. I Fujitsu Posting and controls in I 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 Fujitsu/POL I Posting and controls in I 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 reflS}) 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 I Client Interface AIS to be Document review
responsibilities, together with a change process to be agreed and adhered to _I reviewed (see doc [13])
by 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 Statement of
POL 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 processes
posted to dummy profit centres occurs on an exceptional basis (see doc [8])
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 34 of 41
©Post Office™ 2009
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091292
FUJ00091292
PING
0.4
26/05/2009
Note:
assumed no impact on POL RDS to Fujitsu RDMC interface or the RDS
system 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. 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 Fujitsu/POL I Receipt of client data Controls to check completeness and accuracy of data prior to submission to Requirement no longer N/A
branches. relevant as appropriate
Note: This will be defined as part of AIS production caatrols are defined within
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
suspense (see doc ref [14])
TA-67. I POL Receipt of client data OLA agreed with client and managed via Service Delivery including non Review of OLA (see doc Document review
receipt of files, controls around loading files and management of exceptions, I [11])
clear 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 I 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 Fujitsu / POL I Reference Data The Reference data system (MDM) must provide Transaction Integrator with Document review of HNG- I Document
/ Logica the appropriate data to fulfil the needs of the TA interface as described in TA-_ I X Transaction Acceptance I Review
53 Solution Design (doc
reff5])
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 35 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref.
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
TA-71 Fujitsu / POL I Reference Data The solution must be generic, and therefore be easily adaptable to other client I 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
TA73. 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 Verification that this
4.3.3.2 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 I 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
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. I Fujitsu Solution Design Re-use of Mode 14 Bulk Input will be utilised for the Transaction Acceptance Document review of HNG- I Document
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 36 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref.
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
process X Transaction Acceptance I Review
Solution Design (doc
ref[S])
TA-80. I Fujitsu/POL I Solution Design The solution should be as automated as possible and require minimal manual I Document review of HNG- I Document
intervention, save for the HNG-X TA process. X Transaction Acceptance I Review
Solution Design (doc
ref[S])
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 Document
implementation processes, and Help desk facilities X Transaction Acceptance I Review
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
. requirement has been
. Reporting use of control accounts, satisfied will be evidenced
xceptions reporting, by the End to End Test
= Scripts at NBSC, report
= 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 I 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
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 37 of 41
©Post Office™ 2009
PING Project (Interfacing Client Data into POL Systems)
Requirements Catalogue
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
Version:
Date:
FUJ00091292
FUJ00091292
PING
0.4
26/05/2009
TA-86. I POL Testing and The standard implementation pattern should be followed, ie model office, Statement of
implementation limited 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. 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 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 met 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
report
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 Document review of HNG- I Document
should be the same as the current process. i.e. it triggers a Rem In X Transaction Acceptance I Review
transaction for the stock, and adjusts the stock on hand. Solution Design (doc
reffS]) POL Test
Acceptance Criteria as per
requirement.
Verification that this
requirement has been
Date Printed: Monday, 22 June 2009
Project PING Requirements Catalogue v0.4.doc4
Page 38 of 41
©Post Office™ 2009
FUJ00091292
FUJ00091292
PING Project (Interfacing Client Data into POL Systems) Project: PING
Requirements Catalogue Doc Ref:
Version: 0.4
COMMERCIAL IN CONFIDENCE Date: 26/05/2009
satisfied will be evidenced
by the End to End Test
report
TA-95. 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 TI interface I Details of Net Adjustments, Commission Sales and Commission Claims from I Document review of Field I Document
the Trailer record to be loaded into DIW to allow for extraction on the ETL to Mapping Specification for I Review
POL-FS interface. Camelot (doc ref[22]).
POL Test
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.
Verification that this
requirement has been
satisfied will be evidenced
by the End to End Test
report
000
Date Printed: Monday, 22 June 2009 Page 39 of 41
Project PING Requirements Catalogue v0.4.doc4 Post Office™ 2009