@
RS1576 INTERFACING CLIENT DATA INTO
POL SYSTEMS (Project PING)
Post Office Limited
Feasibility Report
REFERENCE OWNER Rod Ismay
VERSION 02 AutHor(s) _ I Paul Jepson
‘STATUS Draft REVIEWERS =I Martin Box
Dawn Brooks
Gareth Jenkins (Fujitsu)
Penny Maguire (Steria)
Saunder Narayan
Jan Trundell
DATE 25" March 2009 I ApPRovers I Martin Elmslie (Financial Analyst)
Ops ‘SIGN-OFF Martin Box
BASELINE Dawn Brooks
NuMBER Ann Clarke
CassiFicaTi I /n Strictest Saunder Narayan
ON Commercial Jan Trundell
Confidence Peter Stanley
FUJ00091215
FUJ00091215
Table of Contents
CONTROL
Terms and Abbreviations
Version History
Referenced Documents
1. INTRODUCTION
1.1 Background
1.2 High Level Objective
1.3 Terms of Reference
1.4 Methodology
1.5 Key Contributors
2. EXECUTIVE SUMMARY
2.1 Recommended Solution
2.2 Overall Timescales for Recommended Solution
2.3 Summary of Costs and Benefits for Recommended Solution
3. HIGH LEVEL BUSINESS REQUIREMENTS AND SCOPE
3.1 Current State
3.2 Business Requirements and CSF’s
3.3 Current Business and Technical Architecture
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 2 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
an ke ee
10
10
10
10
i
i
12
12
13
14
FUJ00091215
FUJ00091215
4. OPTIONS ANALYSIS AND RECOMMENDATION
4.1 Options Analysis
4.1.1. No Change
4.1.2 ‘Imposed’ TA’s
4.1.3 Component Options For Transaction Acceptance Process
4.2 Recommended Options
4.2.1 Channels Impacted
4.2.2 Support Functions Impacted
4.2.3 Security Assessment
4.2.4 Proposed Migration Plan
4.2.5 Development, Approach & Environment
4.2.6 Legal and Compliance Risk Assessment
4.2.7 Dependencies on other Projects
4.2.8 Identified Risks, Issues and Requirements
5. OUTLINE FINANCIAL CASE
5.1 Primary benefit type
5.2 Impact of not delivering this activity
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 3 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
15
15
16
16
24
24
25
25
25
26
26
26
26
27
27
27
FUJ00091215
FUJ00091215
CONTROL
Terms and Abbreviations
TERM MEANING
AIS Application Interface Specification
AP ADC Automated Payments Advanced Data Capture
BLE Bulk Load Extract
BRDB Branch Database
CR Change Request
DIW. Data Information Warehouse
EDG Electronic Data Gateway
ETL Extract Transform Load
FS Fujitsu Services
FTMS File Transfer Management Service
HNG Horizon Next Generation
HRSAP Post Office Ltd’s Human Resources system
NBSC Network Business Support Centre
P&BA Product & Branch Accounting
POL Post Office Ltd
POL FS Post Office Ltd’s Financial System
POL MI Post Office Ltd’s Management Information system
RDS Reference Data system
TA Transaction acceptance
TC Transaction Correction
Tl Transaction Integrator
TIS Technical Interface Specification
TMS Transaction Management Service
TPS Transaction Processing Service
Version History
Version I DATE CHANGE DETAILS AUTHOR
0.2 20/02/20 I Initial Version Paul Jepson
09
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Feasibility Report
Page 4 of 40
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
Referenced Documents
Nr. I TITLE Versio I DATE Document REF. I LOCATION
N
1. HLBP RS 1576 — 1.0 07/05/0 RS1576
Interfacing Client 8
Data Into POL
Systems
2. HLBP RS 1712 - Trial 1.0 20/10/0 RS1712
To Manually Interface 8
Camelot Client Data Into
POL Systems
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 5 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
1. INTRODUCTION
1.1 Background
The purpose of the feasibility is to look at reducing the level in the identified number of
differences brought about by the manual input of data into Horizon predominantly
relating to (but not exclusive to) a range of existing ‘off counter’ products such as
Camelot online game sales and scratchcard stock activation , in addition to setting
business principles for future take-on of similar non horizon kiosk type transactions such
as Paystation Plus and Post & Go.
Proposed changes through an automated re-engineering should provide improvements
to branch compliance and processes, as well as reducing operational costs. Estimated
costs and cost reductions are included within this feasibility.
Client based settlements are not a preferred settlement option however it is recognised
that the data being provided by clients such as Camelot is robust ,controlled by
reference data ,and more accurate than the Horizon data stream due to conformance
issues.
Product and Branch Accounting recognises the need to be able to reduce the costs and
non conformance associated with the existing process for integrating client data for
settlement and reconciliation , and are looking to assess the options associated with
automatically interfacing this robust data stream more effectively into post HNG POL
systems (HLBP RS 1576 refers).
1.2 High Level Objective
This feasibility study has been undertaken to assess the technical solutions available to
interface a robust reference data controlled stream of client data directly into post HNG
POL systems.
The change would give the branch visibility of the transactions from the off counter kit
,and should reduce the number of Transaction Correction’s which subsequently need to
be issued, enabling immediate ownership of the data at branch level, improve
understanding and improve conformance.
This would :
- eliminate the need for comparison of two data streams in POL FS
- reduce the effort and cost associated with correction of the Horizon stream
- improve business accounting for cash as agents will need to account for the cash
accepted ‘off counter’ at an earlier point in time
- eliminate the need for agents to manually input data into Horizon
- reduce the potential for large value differences which are settled centrally to a customer
account held by the agent in POL FS (which ultimately adds debt to the POL balance
sheet)
1.3 Terms of Reference
Primarily this feasibility is limited in scope to consideration of the product areas identified
in 1.1, with the main initial focus being Camelot online game sales and scratchcard stock
activation (NOT Prize Payments / Scratchcard sales / Match Zero’s / Cancellations
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 6 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
where existing processes will continue) as this is where most business benefits are
considered able to be realised.
The scope of the feasibility will be:
= from the receipt and uploading of client data, including validation and reference data
controls
= achange at the counter as to how the data is accepted by the agent/counter clerk
(any available ‘evidence’ post HNG will be within the office so all accountability is
already within the branch domain)
= changes to the client enquiry process, for example if the agent/counter clerk
disputes the client data (for optimum control purposes it is envisaged that any
challenges will be processed initially via NBSC for consolidation to P&BA for
resolution)
= revised operational instructions which describe the preceding changes for
agents/counter clerks
= amodified interface into back-end systems, including a change to the accounting
solution and reference data to enable transaction acceptance / corrections to be
issued
= achange to duty instructions for POL FS users
= achange to remuneration being based on the accurate Client data (currently based
on ‘compromised’ POL data stream)
Out of scope...
= There will not be a change to the way that transactions are conducted...however
the way that the associated transactional data is interfaced into Horizon is likely to
change. As settlements are already based on client data there should be no change
to settlement timescales or the commercial contracts with clients. It may be useful
however for clients to understand that a change is taking place, as there may be an
impact on the enquiry process.
4.4 Methodology
Workshops have been held in Chesterfield and London at which the Camelot product
manager , P&BA operational team members , Business Solutions , Design Authority ,
Network representatives , and Suppliers were present to consider a proposed approach
to address the described issues.
Ata very high level the proposed approach is as follows :~
* A file of Transaction Acceptances (TA’s) is received by Horizon from Post Office
Ltd each night
+ The TA’s are made available in the Branches the following morning
* Branch Staff authorise the TA’s
* The details from the TA’s are then incorporated into the local Branch Accounts
The following summarises the current process :-
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 7 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
* The Lottery terminal is a stand alone piece of kit used for carrying out Lottery
transactions. In particular it is normally outside the Post Office area of a branch and
so has its own separate cash and is often set up as a separate Stock Unit.
The Lottery terminal provides a daily summarised report of the transactions it has
carried out. This is used in 2 ways:
« Reporting details centrally to Camelot
Reporting locally in the Branch so that the summary can be manually
keyed into the Horizon terminal.
The summaries should then be entered into Horizon where they are then
transmitted along with all other transactions to POL’s back end systems
P&BA then compare the data coming from Horizon with the direct feed they have
from Camelot. Where they differ, then Transaction Corrections (TC’s) are issued to
the Branch to rectify the situation, since it is expected that the Camelot feed is more
reliable that the data received from the Branch
Itis proposed that the process is changed as follows:
* On line game sales data and scratchcard stock activations from the Lottery
terminals is no longer manually entered at the branch
* The (reliable) feed from Camelot, is used to generate a data flow to the Branch
(similar to a Transaction Correction) that will result in the information received from
Camelot being put into the Branch’s accounts
This new flow of data plus the associated changes at the branch is being referred to as
Transaction Acceptances.
The proposed Transaction Acceptance process is as follows :-
1. Camelot provide a summary of transactions undertaken via the Lottery terminal which
is passed to POLFS via EDG as contractually required
2. POL 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
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 8 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
remuneration calculation
Camelot figures passed to
branch as TA, eg £1000
Pardanay, _Srnisinnay
ws I vous
1— ee ~
s
van
Branch accepts Daty been
Camelot TA if figures ok, a
eg £1000 I
canest I Bs
Camelot records Sale Payee
Eg £1000
A manual ‘proof of concept trial for the ‘Transaction Acceptance’ approach for Camelot
(on-line sales and stock
Activations) data only (HLBP RS1712 refers) was also undertaken and adopted the
following process.
BRANCH :
* Camelot transactions taken over the Camelot terminal as now.
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 9 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
* Daily transactions summary slip taken from terminal at the end of day and
calculated as now to determine the appropriate split for online sales / prize
payments / scratchcard sales etc.
Continue to enter Prize payments / scratchcard sales etc on Horizon as per normal
procedures BUT DO NOT ENTER ONLINE GAMES SALES ONTO HORIZON
Retain for data verification as now.
* Process scratchcard stock activations following existing local procedures to note the
volume activated BUT DO NOT ENTER ONTO HORIZON.
* Online game sales and stock activation Transaction Acceptances received the
following morning with text informing Branch of date of transactions the value’s
relate to.
After verifying that the online games sales values and scratchcard activations
volumes agree with the calculations noted previously the Branch should bring the
TA’s to account on Horizon, resulting in the Branch now balancing for the relevant
days transactions. (Crowns should accept the sales TA using “Make good cash” as
opposed to "Write off to Profit & Loss" which would result in a loss being posted to
the accounts. Non-crowns must make good the sales TA as "Settle centrally" will
not be allowable otherwise this will become a POL liability. Stock TA’s will adjust
stock automatically upon acceptance)
* Double entry for the branch is achieved when the accepted TA is received the day
after, resulting in the Branch now balancing for that day within POLFS.
Should the Branch consider it necessary to dispute the Client data upon receipt of a
transaction acceptance, it is proposed that the Branch should still bring the TA to account
prior to verifying the data as is the accepted process for such as Remittance disputes.
Where (if?) it is then established that the Client data is in error the following process is
envisaged...
* TAchecked against locally retained data
Difference established
NBSC called and reference allocated
Value of client data accepted
Difference held in suspense (assuming that locally held data would suggest that
more / less cash has been taken, resulting in a misbalance) ?
Call escalated to supplier via NBSC
* Corrective action agreed
+ Correction issued to branch via client data stream
P&BA:
* Camelot team review Camelot postings (Stock account 627011 ,Sales account
627010) daily.
«Each value to be issued individually via Transaction Acceptance process.
* AP&BA process may need to be set up to contact the branch, in order to process
the TA if the TA has not been accepted after an agreed timescale.
¢ Itis not envisaged that the current accounting / settlement process will require any
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 10 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
changes
Client :
* Camelot poll data from the Camelot terminal which is transmitted as a daily file to
POLFS as now.
1.5 Key Contributors
Ann Clarke (Business Solution) , Dawn Brooks (P&BA) ,lan Trundell (Design Authority),
Saunder Narayan (Design Authority) , Sally Rush (Design Authority), Gareth Jenkins
(Fujitsu Services) , Penny Maguire (Steria)
2. EXECUTIVE SUMMARY
The recommended proposition will:
* Reduce the levels of errors / differences in line with current business focus
« Report accurate accounting information
+ Improve the integrity and consistency of the data across all POL systems
* Make the end to end process speedier and more efficient
2.1 Recommended Solution
This report recommends that in order to best achieve the proposed automated solution
there are 3 key components to the process with the recommended end-to-end solution
comprising of an established option from each of the following :-
* Component A : How to receive data from the Client and in what format
* Component B : How to process the client data and create a TA
* Component C : How the Branch will process the TA data on Horizon
The full options within each of these component areas are detailed in section 4 but
following detailed assessment in conjunction with key suppliers it is recommended that the
following options are progressed...
* Component A - Option A 2 : Existing and new Client data is passed to Transaction
Integrator via existing EDG interface
* Component B - Option B 3 : Transaction Integrator to process Transaction
Acceptances for Branch and Client Data for POLFS, with pre-processing to
transform Client data formats as required in order to utilise a standard TI interface
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 11 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
* Component C - Option C 3: A discrete Transaction Acceptance process requiring
Branch acceptance at Log On
2.2 Overall Timescales for Recommended Solution
Key Milestones :-
+ Feasibility for interface development completed and reviewed by HLBP forum
* Business case completed and approved
* Development commences in line with CR’s agreed with Fujitsu , Steria, and Logica
* Potential opening of development window (provisionally looking for inclusion at
HNG Release 2)
2.3 Summary of Costs and Benefits for Recommended Solution
« Potential benefits at branches are...
- Reduction in time needed to enter the information into Horizon
- Elimination of the errors associated with entry of information into Horizon (no
TC's)
- Reduction in forgetting’ to record transactions when Horizon is down
- More accurate branch accounting and remuneration
- Helps retain the business with Camelot by offering a more robust end-2-end
service
* Impacts on Product and Branch Accounting are indicated in the attached business
case ..
i)
“asiness: Case PIN
‘¥0.2.doc"
Impact of avoided costs such as additional headcount for Paystation Plus and Post & Go
kiosks are excluded at this stage.
2.4 Perceived Benefits
* Costs Reduction as outlined in section 2.3
Reduction in scope for manual errors
* Improved accounting capabilities
. Improved remuneration based on accurate and consistent data
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 12 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
FUJ00091215
FUJ00091215
* _ Ageneric ‘Take On’ template / process for future Client products profiles
that fit the model
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 13 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
3. HIGH LEVEL BUSINESS REQUIREMENTS AND SCOPE
3.1 Current State
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 Horizon.
The client data is uploaded into POL FS and compared with the equivalent Horizon 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 Horizon 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.
Example of existing process (for Camelot on line sales)
1. 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
. The Clerk needs to take monies from the Camelot till and enter into the Branch
accounts via Horizon. This is currently undertaken via the Bulk input process
. The Branch bulk 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)
7. Transaction Corrections (TC’s) are issued where the reconciliation fails
= I ons ‘ “) Pous
f ~
Horan
ak wo
2
POLFS reconciles values
Qo, Horizon Value £1000 caer
‘K Camelot Value £1000 te
u
euterty
In Strictest Commercial Confidence
RS 1576 In 7° jag Client Data Into POL Systems Lee
Page 14 of 40
Feasibility Report Se
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
With conformance issues for this product currently being assessed as running at 60% of
the network proposed changes through this automated re-engineering should provide
improvements to branch compliance as well as reducing costs.
3.2 Business Requirements and CSF’s
In support of operational efficiency the aim of this change is to primarily reduce costs and
improve compliance. If the change is delivered then cost reductions should occur in a
number of areas :-
* Staff cost associated with dealing with enquiries, and issuing transaction corrections
should reduce
« Losses resulting from differences between data streams should reduce
* Debt carried on the POL balance sheet should reduce
* Branch time on balancing and on assessing TC’s would reduce as the branch would
have more local ownership of the data
* The introduction of TA’s will in effect bring a 3 day cycle in clearing down a single
days transactions / activations :-
Day 1 : Transactions taken over Camelot Terminal by Branch and polled by Client
Day 2 : Transactional data received within POLFS ,and transaction corrections sent
to Branch to bring to account to provide accounting entry for the online games sales
/ scratchcard stock activations
Day 3 : POLFS receives accounting entry and clears down open items
In line with the above it is recognised there could be an adverse impact on POL
cash flow as it is estimated there will be approx 350 branches that will move from
accounting daily, same day, to next day accounting. This will mean that the POL
Balance Sheet will be missing income for these branches for a total of 1 day once
the proposed automated solution has been rolled out. However, there will be a
significant improvement and recovery from the 1100 Camelot offices that should
more than outweigh this loss.
Anumber of non-financial benefits, which should also result from the change:
* Simplified and improved accounting and elimination of matching routines which
require system capacity
* A fit for purpose solution which can be used for future off counter development and
client based settlements
* Time savings at outlets achieved through the less frequent interrogation of ‘off
counter’ equipment and input of data into Horizon, and hopefully less time required
to deal with differences, and dealing with transaction corrections.
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 15 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
FUJ00091215
FUJ00091215
Critical success factors have been identified as follows...
* Areduction in the number of Transaction Correction’s which subsequently need to
be issued
* No impact on Clients in respect of settlement timescales or the existing commercial
contracts
* 100% of TA's accepted
* All TA’s accepted within the proposed time window
* 0% of challenges / disputes from branches
3.3 Current Business and Technical Architecture
It seems appropriate to include reference in this section to Transaction Integrator as POL’s
‘strategic tool to ensure external data is delivered in a consistent format into POL systems.
,as this is something that is being considered as key within the options for delivery of this
and other current projects ,but is still in its inception for the business.
‘Date Revied fom .
Cane og Guna Transaction Integrator
io
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 following paystation® project model will implement POL TI with
the appropriate controls...
{Formatted J
ra
Feasib,
Tempk, ...
Tempk I
4. OPTIONS ANALYSIS AND RECOMMENDATION
4.4 Options Analysis
From detailed discussions with both Fujitsu Services (HNG) and Steria (POLFS) it has
been established that there are 3 key components to the proposed Transaction
Acceptance process :-
Component A : How to receive data from the Client and in what format
Component B : How to process the client data and create a TA
Component C : How the Branch will process the TA data on Horizon
The options within each of these component areas are detailed further on in this section ,
and the recommended end-to-end solution will comprise of a component from each area.
Additionally 2 other options were considered
4.1.1, No Change
The purpose of including this is to make it clear that it is possible to achieve the business
‘outcome without any changes to Horizon code as was adopted for the ‘proof of concept’
trial (RS 1712 refers).
For this approach the following would happen :-
Data from Camelot would be used to generate Transaction Corrections within POL
FS such that they are identical to those generated manually by P&BA.
This would need to be done by 19:00 which is currently when the TC’s are cut-ff
within POL FS.
These TC’s would then be passed to Horizon overnight as normal. (It should be
noted that the current AIS limits TC’s to 1,200 per night. It is likely that if TAs are
being generated for all lottery terminals then this figure probably needs to increase
to 10,000 to 20,000 per night. This change is viewed to be more of a contractual /
operational issue than require any technical change to the solution.)
These then get sent to Horizon counters or loaded into BRDB for HNG as with any
other TC’s,
At the Branch, they will appear with any other TC’s. Specifically, users with a role
of MANAGERS or SUPERVISORS will be alerted to their presence when they Log
On each time. These TC’s being distinguished from “normal” TC’s by having
specific text associated with them (for example a specific first line “banner”) and the
User being trained to look out for them.
They can be processed as normal. Note that there is no capability to link TC’s
together so if there are multiple TC’s required for the info from the Lottery terminal,
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 17 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
then there is nothing to prevent some being processed and other ignored. However
all TC’s must be processed before the branch can be balanced (which may not be
for 5 weeks and so is not considered much of a control).
4.1.2 ‘Imposed’ TA’s.
It was considered that TA’s could be automatically recorded in the Branch’s accounts
without any User needing to acknowledge them , and even though this may technically
possible (and in fact is probably simpler than passing them to the Branch to process),
there are some significant drawbacks with this approach.
* The main issue is if the system starts generating transactions without a user being
present and these transactions affect the Branch’s Cash Position (which TA’s / TC’s
do), it will be very difficult to prove that the sub-postmaster is responsible for any
losses
¢ It is not clear to which Stock Unit the TA should be applied for those branches that
have more than one “real” Stock Unit
* Even if a Stock Unit is identified there may be issues fit is an Individual Stock Unit
and is currently in use or for any Stock Unit that is currently being balanced
Itis therefore proposed that this option is not considered further.
4.1.3 Component Options For Transaction Acceptance Process
N.B The bolded risks and issues for each option within the Components represent the key factor(s) as to why
the particular option may have been rejected
Component A : How to receive data from Client
OPTION A1_- EXISTING CLIENT DATA RECEIVED (AS NOW) VIA EDG
Solution overview :
+ Existing Clients provide a summary of transactions undertaken via the non horizon
kit in the required format to enable interface to POL systems via EDG
* Proven solution with proven POL system interfaces with data provided for
Settlement in an acceptable format therefore no impact on existing commercial
contracts
Risks and Issues :
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 18 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
+ Inability to process non standard / new Client file formats.
* Solution does not fit with POL Strategy to use Transaction Integrator for all
detailed transactional
data
OPTION A 2 — EXISTING / NEW CLIENT DATA PASSED TO TRANSACTION
INTEGRATOR VIA EXISTING EDG
Solution overview :
* EDG utilised as the existing conduit to receive data from the Client and pass to
Transaction Integrator
Intended process to be used by Post and Go and Paystation Plus
Transaction Integrator has the ability to produce a TA at the required terminal ID
level of granularity
* One source of data ensures system consistency
* Transaction Integrator has the flexibility to transform Client data to a standard
format with minimal changes
+ Transaction Integrator could also be used to create POLFS Vendor account
postings without contractual impact
Risks and Issues :
* Transaction Integrator is a new tool with no proven track record
* Controls for determining if Client data has been received would need to be
established
+ Existing Reference Data controls would need to be checked to ensure that the
solution populates POL
systems correctly
Costs associated with data conversions / re-formatting that may need to take place in POL
TI to enable data to be fed into POLFS, DIW etc has been provisional assessed at no
more than £50k.
This relates to any non-standard files that have not already been catered for within the
DIW project as it is understood that Camelot files are currently being processed via POL
Ti.
Component B : How to process Client data to create a TA
OPTION B 1 - TRANSACTION INTEGRATOR TO SEND TA TO BRANCH ONLY
(Settlement after TA acceptance)
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 19 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
Solution overview :
* Transaction Integrator to process Client transaction data and summarise into a TA
file that is passed to the Horizon Branch Database
* Could create a separate file containing TA’s pertinent to the branch device (eg
Camelot terminal 1/2) for each non horizon system
* Provides POLFS vendor account postings when TA is accepted
Risks and Issues :
* Transaction Integrator is a new tool with no proven track record
* Does not support existing Client contract if Client data is not used directly to
create POLFS Vendor account postings
¢ Lack of control as there is no way to determine if TA has been sent to Branch or if
ithas not been accepted
+ Branches could ignore TA’s
+ Existing Reference Data controls would need to be checked to ensure that the
solution populates POLFS correctly
OPTION B 2 - TRANSACTION INTEGRATOR TO SEND TA TO BRANCH AND
CLIENT DATA TO POLFS (Settlement after TA acceptance)
Solution overview :
* Transaction Integrator to process Client transaction data and summarise into a TA
file that is passed to the Horizon Branch Database
A control entry can also be created for POLFS such that matching of processed
TA’s can be undertaken
It will be possible for P&BA to detect where a branch has not accepted the TA
Could create a separate file containing TA’s pertinent to the branch device (eg
Camelot terminal 1/2) for each non horizon system
POLFS Vendor account postings provided using Program ZIFX0043 after TA has
been accepted
Risks and Issues :
* Transaction Integrator is a new tool with no proven track record
Extra control postings required in POL FS meaning extra running cost for storage
* Does not support existing Client contract if TA acceptance is to be used to
create POLFS Vendor
account postings
* The existing Transaction Integrator process would need to be reviewed to ensure
that the solution
populates POL FS correctly
+ Existing Reference Data controls would need to be checked to ensure that the
solution populates POL FS
correctly
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 20 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
OPTION B 3 - TRANSACTION INTEGRATOR TO SEND TA TO BRANCH AND CLIENT
DATA TO POLFS
(Settlement as Client Data received)
Solution overview :
« Transaction Integrator to process Client transaction data and summarise into a TA
file that is passed to the Horizon Branch Database
Ability to transform Client provided data into the generic interface format, therefore
providing a single business model for interfacing existing and new Client provided
data to POL FS
Control entry can also be created for POLFS such that matching of processed TA’s
can be undertaken
It will be possible for P&BA to detect where a branch has not accepted the TA
Could create a separate file containing TA’s pertinent to the branch device (eg
Camelot terminal 1/2) for each non horizon system
Supports existing Client contract to create POLFS Vendor account postings for
settlement from Client data
Control entry is made using the POL TI - POL FS generic interface currently under
implementation for Paystation Plus and Post & Go
Recognises that the Horizon posting is about Method Of Payment rather than
Sales
Avoids possible restrictions of mode MG with respect to Multiples, SAP Reference
field ete
Risks and Issues :
* Transaction Integrator is a new tool with no proven track record
« The existing Transaction Integrator process would need to be reviewed to ensure
that the solution
populates POL FS correctly
+ Existing Reference Data controls would need to be checked to ensure that the
solution populates
POL FS correctly
«Extra control postings required in POL FS meaning extra running cost for storage
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 21 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
=
weurasor
~~ weuumsor
Cet
\ / weuripor 3) Bytes Poa
a ROT
veg /a a abi ne np at Dee
~weurasor
Option B 3 Postings
OPTION B 4 - TRANSACTION INTEGRATOR TO SEND _TA TO BRANCH AND CLIENT
DATA VIA EDG TO POLFS
(Settlement as now)
Solution overview :
* Transaction Integrator to process Client transaction data and summarise into a TA
file that is passed to the Horizon Branch Database
* Control entry is created for POLFS using the same Programs ZIFX0045 and
ZIFX0043 as is currently done for Camelot.
« Could create a separate file containing TA’s pertinent to the branch device (eg
Camelot terminal 1/2) for each non horizon system
Avoids possible restrictions of mode MG with respect to Multiples, SAP Reference
field ete
Supports existing Client contract to create POLFS Vendor account postings for
settlement from Client data
Risks and Issues :
* Transaction Integrator is a new tool with no proven track record
* Current EDG POL FS interface has no transaction recoverability as it is not via XI
* Does not provide a single business model for interfacing existing and new
Client provided data to POL FS
* The existing Transaction Integrator process would need to be reviewed to ensure
that the solution populates POLFS correctly
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 22 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
« Existing Reference Data controls would need to be checked to ensure that the
solution populates POLFS correctly
« Extra control postings required in POL FS meaning extra running cost for storage
(a)
Option B 4 Postings
OPTION B 5 - UTILISE POLFS HOLDING TABLES TO CREATE TA (Settlement after
TA accepted)
Solution overview :
« Load data into POLFS and create TA from “holding tables” (these are not postings
in POL FS but holding tables in the reporting component RIS)
Risks and Issues :
« No automated Client posting in POLFS
* Relies on branch feed of data (ie the first time Client data would be ‘visible’ in
POLFS will be when the TA is accepted)
« POL FSis not the best place to transform the data using a holding table into a TA
* Does not support existing Client contract if TA acceptance is to be used to
create POLFS Vendor
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 23 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
account postings
* Solution does not fit with POL Strategy to use Transaction Integrator for all detailed
transactional data
This process needs to align with POLFS scheduling
OPTION B 6 - UTILISE POLFS TO AUTOMATE TC PROCESS (Settlement as now)
Solution overview :
* Load data into POLFS and create TA from client data
« Utilises proven existing Transaction Correction process
* Matching process in POLFS would be straight forward as the branch can only
“accept”
* Solution allows control of TA
Risks and Issues :
* This process needs to align with POLFS scheduling
* Solution would not allow the data to be presented to the Branch at a device/terminal
level because POL FS does not contain data to this level
If detailed transaction data could be stored in POLFS to be able to provide the
required level to create the TA this would have significant implications for processing
and storage as well as cost
* Solution does not fit with POL Strategy to use Transaction Integrator for all
detailed transactional data
* POL Ml and POLFS could be using different data streams and therefore result in
discrepancies
Component B : Initial indication of work involved for STERIA :
= Option B 1 : % day to switch off batch job for relevant client interface(s)
= Option B 2 : could require a functional spec change to amend the Horizon interface
which would require Fujitsu resource ,but may be achievable with master data changes
and a small amount of config. Steria would need to prototype this in the test system to
confirm
= Option B3 : based on existing assets as far as POL FS and SAP-XI are concerned.
Therefore there is no expected development although there will be a requirement to
decommission the existing Camelot interface
estimated at up to 1 man week
= Option B4 : based on existing assets. Therefore there is no expected POL FS or SAP-
XI development
"= Option B 5 : assuming that existing feeds (or ETL) will provide data in a generic format
for POLFS to handle, then POLFS will only require one change to cover all client data
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 24 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
* Option B 6 : May be quite straight forward, dependant on how the existing TC
functionality could be used for this option
Component C : How the Branch will process the TA data on Horizon
OPTION C 1 - STANDARD TC APPROACH
Solution overview :
‘© Standard single TC stream of transaction acceptance information will be passed to
branch utilising existing processes
No changes will be made to existing Horizon counter processing to accept TC
Proven solution
“make good” can be utilised to only allow acceptance of TA
Existing text field narrative can be used to distinguish product, device, and method
of payment
Solution allows debits and credits in same interface
Processing cycles could be investigated to determine whether there is a better
alignment with all products ie Change processing cycle cut-off (currently 19:00) to
allow processing of all TC’s , which may provide an opportunity to shorten
processing timecales
Risks and Issues :
« E2E Control process needs to be created to address duplicate data/files
* TC process only enforces acceptance by end of trading period
* TC’s cannot be linked so would be possible to “accept” partial product information
and leave outstanding for up to 5 weeks
* No distinction between Transaction correction and Transaction acceptance which
may not aid existing non conformance
« Possible cash flow implications
OPTION C 2 - RECEIVE TA LIKE EXISTING TC
Solution overview :
© Discrete data stream for TA’s to “mirror” TC process but utilising the same data file
format and naming
e Different products could have different cut-offs
‘* ‘make good” can be utilised to only allow acceptance of TA
© Existing text field narrative can be used to distinguish product, device, and method
of payment
Risks and Issues :
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 25 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
FUJ00091215
FUJ00091215
+ E2E Control process needs to be created to address duplicate data/files
+ TC process only enforces acceptance by end of trading period
+ TC's cannot be linked so would be possible to “accept” partial product information
and leave outstanding for up to 5 weeks
* Possible cash flow implications
OPTION C 3 - DISCRETE TA
Solution overview :
* Based on the existing TC feed, create a distinct interface and feed to the Branch
Database
« The timing of the interface can be “tuned” to the specific product needs of each
service (eg Post & Go, Camelot, Paystation Plus)
« Utilises the free form text field to define product, method of payment etc.
« “make good” can be utilised to only allow acceptance of TA
To ensure branch conformance to process the TA within a timely period, the below
‘sub option enforces the acceptance of TA’s during Manager or Supervisor login within
processing day
* Allows creation of a specific TA report which would show outstanding and
processed TA’s
Can separate TA and TC “acceptance” process and enforce stricter or more flexible
timescales
« New mode would allow accounting of stock to be undertaken where this is
applicable to the product ie Camelot scratchcards
« TA’s can be linked such that the branch must accept a “set” of TA’s for the product,
eg Camelot sales for cash, Camelot sales for cheque
Risks and Issues :
« E2E Control process needs to be created to address duplicate data/files
* Controls would need to be established for the monitoring of files, as currently there
is only one data feed
* Possible cash flow implications
SUB OPTION C 3 - FORCED TA AT LOGON
Solution overview :
« Shortest possible timeframe from Client presenting data to POLFS settlement
therefore improving cash flow
« The TA could automatically propose the Stock Unit associated with the Product
such that the Manager/Supervisor can easily login and accept the TA
* TC’s would continue to operate as now, whereby they can be left unprocessed until
the Branch Trading Period
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 26 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
Risks and Issues :
* Business resistance to enforcing “do not pass go” approach.
+ The manager may not be in a position to validate the figures at the point he/she
logs on
ial indication of work involved for FUJITSU Services (Appendix A
Component C :
refers)
Based on the requirements set out in Appendix A the indicative estimate for delivering this functionality in
HNG Release 2 is in the range £200K to £300K.
This estimate excludes the following items:
+ Release costs, as these have yet to be defined between the parties. How much of the release
costs get allocated to PING will depend in part what other projects form part of Release 2
+ The costs of providing additional POLFS and SAP-X! test rigs for the post HNG world. The.
current contract reduces test rigs sharply once the main HNG programme is completed and PING
will need additional test rigs, as other post HNG projects will too.
+ Ongoing charges. PING is likely to incur ongoing charges, but we've not been able to estimate
them as yet.
This estimate is subject to the requirements and outline design being finalised in the months to come. FS
would aim to provide a firmer estimate once those two phases have been completed , which should also
include UAT and end to end testing support of the post POL SAP interface provisionally estimated at up to 4
man weeks.
4.2 Recommended Options
Component A — Option A 2 : EXISTING / NEW CLIENT DATA PASSED TO
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 27 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
TRANSACTION INTEGRATOR VIA EXISTING EDG
Component B ~ Option B 3 : TRANSACTION INTEGRATOR TO SEND TA TO BRANCH
AND CLIENT DATA TO POLFS (Settlement as Client Data received) WITH PRE-
PROCESSING TO TRANSFORM CLIENT DATA AS REQUIRED TO UTILISE
STANDARD TI INTERFACE
Component C — Option C 3 : DISCRETE TA WITH FORCED TA AT LOGON
The following diagram illustrates an overview of the proposed solution
‘TRANSACTION ACCEPTANCE FOR CAMELOT
I
4.2.1 Channels Impacted
This change will impact the following networks / channels:
Extemal Contact Centres No Intemal Contact Centres Yes
Internet No Intranet No
Direct Mailing No Crown Offices Yes
Commercial No Agency Yes
Branch and Contact Centre impacts have been indicated in previous sections
Appropriate comms will be required to be issued prior to implementation
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 28 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
4.2.2 Support Functions Impacted
This change will impact on the following Support Funetions
Stock & Distri in No
Communications Yes
Product & Branch Accounting Yes
MI Yes
Equipment & Space Yes
Human Resources Yes
Procurement No
Client Billing Yes
Contact Centre Yes
Security No?
Finance Yes
Product & Branch Accounting New way of working / Savings of admin staff resource
plus Agency / Reduction in non-conformance / Increase in cash liquidity
MI- Improvement to Horizon data stream ie manually input bar code summary will be
replaced by "TA" acceptance
Equipment & Space — PC’s and Desk space to be saved in P&BA
Human Resources — Resource savings in P&BA as indicated in business case
Client Billing - May impact Billing process for WH Smith Branches ?
Contact Centre - Reduction in non-conformance calls
Finance - Increase in cash liquidity
4.2.3 Security Assessment
The AIS is the recommended way forward by Design Authority and is assumed to have
been approved from a systems security angle.
4.2.4 Proposed Migration Plan
On day ‘X' Ref data will switch off / deactivate the buttons on horizon used for confirming
the days trading for Camelot Terminals and on Day 'B' introduce the new TA process.
The intention is to migrate the solution to the model described in Section 4.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 EDG to POLFS route is ceased.
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 29 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
4.2.5 Development, Approach & Environment
Acchange request will be raised to engage Fujitsu to develop the solution in HNG. A
standard approach will be undertaken whereby the following stages are undertaken :-
+ Requirements definition
+ Interface specification documented
+ High level Solution Design
+ Work Packages raised for Logica (ETL), Steria (POLFS)
+ Development and Unit testing undertaken by Suppliers
+ E2E testing undertaken to ensure interfaces / processes are in place and working
+ Model Office / Pilot
+ Full Rollout
4.2.6 Legal and Compliance Risk Assessment
By adopting the recommended options to automate the interfaces using a standard format
this will ensure compliance with POL’s data security policies, whereas currently this may
not be the case.
4.2.7 Dependencies on other Projects
HNGX (change freeze)
SAP rationalization
Validation of existing Client data via Transaction Integrator
Paystation Plus roll out
Post & Go roll out
Implementation of foreign currency ATM's
4.2.8 Identified Risks, Issues and Requirements
The attached documents all comments made by stakeholder contributors to date...
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 30 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
TA Regis Cat
v0.2.doc”
5. OUTLINE FINANCIAL CASE
NB: THIS SECTION MUST BE COMPLETED WITH THE FINANCE TEAM
Financials
Costs
One off total costs
Amount (£)
Comments
Recurring costs (per annum)
Other Costs (e.g. Income
Loss)"
* Le. Impact on income through promotional activity e.g. 12mths forthe price of 11mths
Expenditure
Revenue Expenditure
Amount (£)
Comments
Capital Expenditure
* Includes total expenditure - one off and recurring
Cost Coverage
‘Amount (&)
Comments:
+ In budget bid
+ Re-forecast of existing
budget
« Recovered from 3% Party
Benefits
Amount (£)
Comments
Income (per annum)
One Off
Recurring
Other (Non Financial)
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 31 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
5.1 Primary benefit type
© Income Generation ¥ @st Avidance Qst Reduction
T Tactical T Legal T Health& Safety
¥ @mpliance ™ Cther, provide details-
5.2 Impact of not delivering this activity
* Continued levels of non-compliance and associated cost
« Lack of solution for planned ‘off counter’ transactions, and products
APPENDIX A: PROPOSED REQUIRED CHANGES IN FUJITSU DOMAIN
TO INTRODUCE TA’s
Itis proposed that the file format for TA’s should ,as a minimum, be similar to that for TC’s.
However for any option other than the “no change” option, then it is considered that TA,’s
should be kept separate from TC’,s. The following changes therefore needed to be
considered :-
* Keeping TA’s and TC’s in separate files enables them to be distinguished based on
the name of the file in which they are found and also enables them to be generated
from somewhere in POL’s back end systems other than POL FS.
* There may be a need to Introduce a new Record Type in the file format to allow
TA’s and TC’s to be distinguishable
* Consider combining the above, so that there is a new record type used to
distinguish TA’s from TC’s and a fixed number of multiple files (each with its own
sequence numbers and schedule for arrival), which then provides flexibility such
that TA’s and TC’s can be generated from multiple sources within POL’s back end
systems and Fujitsu don’t need to link the source of the data to the way in which it is
processed
Once the approach is agreed an updated AIS and TIS will be required and there will
be a need to consider any changes required to the overnight schedule and to
volume capacity.
TA Interface :
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 32 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
It has become clear that TA’s are quite distinct from TC’s and so it is now proposed
that TA’s are handled totally separately from TC’s and TC’s are left alone.
It is expected that there will be opportunities to copy much of the overall design of TC
processing (and perhaps even some of the code) when implementing TA’s.
It is proposed that FS introduce a new file type to be delivered to Horizon. The way that it
is processed through the system will be similar to that for TC’s ie one or more files are
delivered to an Input directory on the main Horizon Host by something like FTMS or copied
from a share elsewhere in the Data Centre as is currently done for TC files from POL FS.
It is proposed that this is handled like TC’s in that all files are delivered to the input
directory at the time it runs (06:05 am each day as with TC’s). If multiple files are
generated then they will all be processed.
Note that the alerting will only complain if there are no files delivered.
The files are then loaded into the TPS Host system where they are validated and any error
files generated and returned. It is assumed that this process will operate as for TC’s ie
error files should be delivered to Huthwaite as well as the source system.
The files are then copied to BRDB (as with TC’s) to a new table for TA’s.
A new AlS will be required to address issues like volumes, any error handling / alerting for
missing files and any Service Level reporting required.
Host Changes :
Anew 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.
Database Changes :
The following new table will be required in TPS Host and BRDB to hold TA’s.
Column Type Meaning
branch_accounting_code I NUMBER(6) FAD Code of Branch to which TA is
being directed
‘stock_unit VARCHAR2(3)_I Name of Stock Unit to which TA is to
be applied.
NB if none is specified or the named
SU doesn't exist in the branch, then
the TA will be applied to the SU to
which the User is currently attached.
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 33 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
Column Type Meaning
system VARCHAR2(16) I Name of external system generating
the TA eg “Camelot”
terminal_id NUMBER(2) Identifier of terminal for external
system (allows them to be separately
processed)
prod_id NUMBER(10) Product against which the TA should
be applied.
‘Settlement_prod_id NUMBER(10) _ I Product against which the TA should
be settled. This will probably be a
MOP product such as cash, cheque
or a pseudo plastic product.
Not required if amount is zero.
Mandatory otherwise.
accounting_sense VARCHAR2(5) I Indicates the accounting sense of
how the TA is to be applied.
Equivalent to the TCINV / TCCRM
field for TC’s.
amount NUMBER(11,2) I Value of TA in pounds and pence
Can be zero for a “stock adjustment”
quantity NUMBER(S) _I Quantity for TA. should be 1 if
amount is non zero
reference VARCHAR2(18) I Matching Reference to be returned
to POL FS
There is a need to define what should happen if the User is attached to the default
‘stock unit, since that cannot handle any transactions. If all TA’s describe valid stock
units then they can be processed. Otherwise they are not processed and User must
process them manually.
It is considered that there will always be a need to allow for the Stock Unit not being
present and the situation where the current Stock Unit is not appropriate (ie it is SU
DEF). However if the concept of “Reserved Stock Units” were to be introduced as a
future development, then it could be exploited by TA’s as this would reduce the
likelihood of this.
For costing purposes it is assumed that if the supplied Stock Unit doesn’t exist (or is
not available due to being locked) and the Logging On User is attached to SU DEF,
then TA’s for that Stock Unit will be bypassed during Log On. They will not be marked
as failed and can be processed at a subsequent Log On or manually later.
For TC’s prod_id and settlement_prod are derived from an Article in the AIS. We need
to agree as part of the AIS work whether these should be delivered as prod_id’s or
Articles. At the counter they will need to be prod_id’s, but we can derive them using
Reference Data using similar rules to those for TC’s.
Log On Changes :
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 34 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
Log On needs to return a second flag to the counter indicating whether or not there are
any outstanding TA’s.
After making the check for outstanding TC’s, (but again only if the user has Role
MANAGERS or SUPERVISORS) a further check is required as to whether there are any
outstanding TA’s. If there are some, 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 expected
that users will accept all TA’s without further consideration.
Processing TA’s :
When the user is presented with a list of TA’s to be processed as below, the user can
either select a specific TA to look at it in more detail as all the info associated with a TA may not
be able to be presented on the summary screen so a detail screen needs to be made available, or select a
function to accept all.
a Po im
Post Mai Sezen
ems Enty
E 1
Camelot 1 Lottery Sales Cash £523.00, cat Selec I Suspend
oct
1 x
Post&Go2 LabelSales Plasto € 2054 Pat Seed
=
Post&.Go2 Stamp Sales Cash £20045 Pot Teed I Previous
I I ad _prey
Camelot 1 Insta 6S “00” GAT Seed I Cancel
unoo]
Bea
Space
The user will be expected to touch the Enter button which would result in accepting all the
TA;s and 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 Bulk Load Extract (BLE) file.
When a TC is currently processed on Horizon, details of that TC are included in the BLE
file passed to the XI software for loading into POL FS. That part of the processing is done
to match it with the original TC sent from POL FS and it is assumed that a similar
mechanism will be used for TA’s. An implication for this is that if the TA doesn’t originate
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 35 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
from POL FS, then such details will need to be replicated so as to allow this matching to
work.
An identifier will be included in the transactions that are generated to support the matching
process. This will be included in the TA record and is put into the TA_reference field as for
a TC to ensure the TA is correctly passed back to POL FS and used for auto matching with
the data passed into POL FS from the client.
Transaction Acceptances will be validated against standard Reference Data, so care must
be taken that TA’s for non-core products are only sent to Branches that support those
products. This is the responsibility of the POL processes that generate the TA files. Any
TA‘s that fail Reference Data validation will be marked as “failed” and the user will be
informed. This mechanism is the same as is currently done for Transaction Corrections.
Since these transactions need to be matched up in POL FS it is important that they are not
aggregated by the BLE Summarisation process. Since it is expected that the products
deemed appropriate for TA’s are specifically for use for TA’s, then Reference Data for those
products needs to map them to Articles which are configured not to summarise the data in
the Modes being used for TA’s acceptance
Anew mode ,or re-use of mode 14 (Bulk Input), may therefore be required if there is not
the flexibility within RDS in terms of which Modes can be set as not requiring
summarisation. There is a view that existing Mode 01 (Sale to Customer) may be viable.
Note that the transactions generated will be fed into HR SAP for remuneration in the
normal way dependent on the product mode to CTT mappings defined in Reference Data.
Reporting TA’s :
Itis proposed that a new report is introduced with the layout of this report being similar to
that for Processed TC’s.
Since the expectation is that all TA’s are processed on the next Log On, then there
doesn’t seem much point in having a separate Outstanding TA’s report. However
should there ever be any Outstanding TA’s these will be included in the Processed
TA’s report and highlighted for immediate action.
A “Process TA’s” button (similar to the Process TCs” button) on the Housekeeping
Menu will be set up to allow TA’s to be processed other than at Log On. Its effect will
be to invoke the functionality required for the above.
The following is copied from DES/GEN/SPE/0004 section 5.5.7 which is the HNG
definition of the Processed TC’s report
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 36 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
“OFFICE DAILY PROCESSED TRANSACTION ACCEPTANCES REPORT
Description - This is an office-wide report (i.e. it reports on all stock units) that is printed on the Ad
back office printer in landscape format. It shows transaction acceptances that were processed
between the two dates specified within the report criteria.
It is a single report and not part of a Report Group
Frequency - as required
Optional - a new page will occur once all lines have been used on the previous page. The
headings are repeated on every page. No need to retain
Sequence - Listed by order of receipt from POL Financial System.”
Definition
FieldName Line I Character [Length] Conienis/Notes
No. _I Positions
Transaction Repeated as necessary.
details:
Date Received 06 [01-8 a
Date Processed 08 10-17 8
‘Outcome 08 [20-33 14 For a successful acceptance : the mode
in which the acceptance was transacted
(see below)
Reference 08 35-53 9 Reference number prefixed by an
iteration flag of ‘N’ (new)
Crediv/invoics 08 56-58 3 ‘CRM=Credit note, INV=Invoice
Affected Product 08 63-78 16 Product Receipt Name
Settlement Product I 08 80-95 16 Product Receipt Name, or Blank if
transaction acceptance failed
Amount 06 ‘97-108 2 Either an amount or quantity (but not
‘Quantity 08 To117 I 6 both). Suppressed if zero.
Client Reference 08 119-134 I 16 External System
Terminal 08 136-137 I 2 Terminal id
‘Stock Unit 08 739-171 I 3 Stock unit used
Report Text in Outcome field
Mode Report Text
‘Accepted ‘Serve Customer
Failed (eg where the
TA has failed
processing due to
Reference data
validation failing)
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 37 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
FUJ00091215
FUJ00091215
FUJ00091215
FUJ00091215
Mode Report Text
Not Processed (eg
where the TA has not
yet been processed
due to no one
Logging On since it
was delivered or
‘Stock Unit issues)
Note that the layout is purely indicative. Costings are based on provision of a single
report for the Back Office printer accessing date from a single table bounded by a
“from” and “to” date.
In Strictest Commercial Confidence
RS 1576 Interfacing Client Data Into POL Systems
Page 38 of 40
Feasibility Report
Template Version V2.0 October 2008
Template Publication Date: October 2008
TA Report Layout and Example Contents
1 2 3 4 5 6 ul 8 1 2 3 4
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
Feltham Post Office FAD 123456X Page 1
11:42 08/04/2009 ‘TP O1
PrOGesse Transaction Acceptances Report - Office Copy
outcome Reference credit/ affected Settlement Amount Quantity Client Term sv
Invoice Product Product Reference
21/03/04 22/03/04 abcdefghijkimn N123456789012345678 CRM abcdefghijklmnop abedefghijklmnop 123456789.12 12345678 abcdefghijkImnop
21/03/04 22/03/04 Serve Customer C123456789012345678 INV Lottery Sales Cash 523.00 Camelot aca
21/03/04 22/03/04 Serve Customer P123456789012345678 INV Label Sales Plastic 20.54 Post & Go 2 PL
i++ END OF REPORT **#
ag a
T z a q 3 Gg T z 3 q
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
The data shown in the example is illustrative only —
the exact text can change, and so differ from that in the example.
FUJ00091215
FUJ00091215
TA’s and Balancing :
The Stock Unit balancing process currently has a check that if this is the last active Stock
Unit to be balanced in a Branch, then there mustn’t be any outstanding TC’s. It is proposed
that this check is extended to look for Outstanding TA’s or TC’s but as Branches should be
processing TA’s as soon as they arrive, this check is considered very much a long term
back-stop for any controls that may be able to be embedded into the recommended
solution. Therefore when Balancing a Stock Unit, the current check on not allowing the last
Active Stock Unit to be Balanced if there are outstanding TC’s will be extended to check for
outstanding TA’s as well.
Accounting for alternative Methods of Payment :
Horizon always works on the principle of double-entry book keeping. This means that
when a value of Lottery payments are entered, there would be a corresponding entry for
the same amount of Cash. This simple case can easily be mapped to a TC (or TA) where
the Article to be made good represents the Lottery product and the Instruction Article
represents Cash. However the current process of manual entry onto Horizon allows it to
be settled for by a combination of cash plus cheques so this would require two separate
TC’s to be processed.
This would therefore require two separate TA’s, unless the concept of “linked TA’s” is
introduced whereby a number of separate TA’s need to be accepted together. It was
considered that for TA’s, all outstanding TA’s must be accepted together and unlike TC's it
should not be possible to process them individually.
By treating all TA’s as being accepted together, it then enables a number to be raised to
cover various methods of payment and with PayStation Plus and Post & Go, some
methods of payment could represent card payments (which are outside Horizon, but could
appear as normal Service products in Horizon).
FUJ00091215
FUJ00091215