POL00038878
POL00038878
Branch Trading Reporting, Management
and Control and Transaction
Management
Conceptual Design
GRAEME SEEDALL
3 March 2004
© Post Office™ 2004
Version 1.0
Page 1 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Table of Contents
4 Document Control 6
44 Document Information 6
4.2 — Document History... cosseseseeesesuseeesesee coosssseseeesessseststeeesnseesee coscssssesesessensnstiueeesesseee cessssseeestsssesnin®
4.3 Change Process....... cososssseseeenssesetninnsesesssee cosssssseneeeesseneeesee coosssssneeesesennneneee cossossseseeensneneeenee sosssssseneeeessenesenee 7
44 Changes in this Version 7
45 Key Contacts 7
1.6 Review Details......... ocosnsnsneeseseeecesnee socssssssneeseseeeseseee sossssoueeeneniisninnnnnssunsnnnneneseeeeneeeeneee cocosaseeeseunnennesesee coveeeeeeee®
1.7 Associated Documents. i)
1.8 Abbreviations/Definitions a . 9
2 1
"1
NE easasetneeenseeee 1
2241 Exclusions......... 1
23 — Background .... sess 1
24 — Document Explanation: 12
241 Creation Process ... cssssssesesssesessnunsstsnnnnnsssnseseseseeesiuuensesunssneessee essssssessseeeessussisssninsennssssseeessseeestssseseee D2
242 Business Process Models 12
3 Overview 13
3.4 Business Proposition oo... ....ccccsssseesssssssessnsssensssssessssnesisssseneinssaseetnsseneeinsnsesenuesssseeunsseeeesa cessussnsettsssseeeunassseeee 13
344 Accounting, Reconciliation and Settlement, including Debt Recovery and Branch Control 13
3.2 Functional Summary. 14
3.24 Overview 7 . esse . 14
3.3 Systems summalry............... osesnsesee ose . oes cocsonsnseeee wos . ceed
34 Potential for Change AT
4 — Constraints 18
44 Business & Functional... ocssssssseessnennnnnsnnniunansnneinsnsnsnnnissansannnssannnnnsnannnnansnansnnnnsannnsansannnsaneanesanennnnsseeensens DS
42 Legal & Regulatory. 18
43 Architectural Framework & Building Blocks. 18
43.4 Integration with Other Systems... . . .
43.2 Post Office™ Strategic Direction .........
433 Post Office™ Approved Technology
43.4 Post Office ™ Approved Components
44 Fujitsu Services
45 PrismAlliance
46 — Other Constraints ....
5 Design Principles.
6 — Funotional Requirements
6.1 Overview - Local Verification .......
62 Overview - Other Data Capture
63 Overview — Produce Reports
64 Overview - Daily Trading... oe
6.5 Overview ~ Produce Branch Accounts ...
6.6 Overview - Stock Control
6.7 Overview - Discrepancy Management.
6.8 Overview - Transaction Management...
Exclusions
High Level Process Models
81 A4Accounts and Settlement..........
loin
841 A441 Create / Verify Branch Trading Statement.
812 A4.1.1 Local Verification z
813 A4.1.2 Produce Reports and Information . wee hoses
844 A4.1.2.3 Produce Sales Report to Assist Remuneration Check
8.15 A4.1.3 Other Data Capture .
816 A4.1.5 Discrepancy Management...
817 A4.15:1 Receive Automated Message...
848 A4.1.5.2 Handle Transaction Correction - .
8.19 A4.1.6 Compare Generated with Actual Cash Position ......... es we
81.10 4.1.6.1 Compare Generated with Actual Cash Held for Stock Unit 34
8.4.14 A4.1.6.2 Create Variance Report ... Compare Generated with Actual Cash Held Across Branch 35
8.142 A4.1.6.3 Make Good or Hold Any Cash Variance ........... cesetseceeesee
8.4.43 1 3 A4.1.7 Produce Branch Accounts .
A4.1.7.1 Stock Checking .....
eI
a
3 March 2004 Version 1.0 Page 2 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.15 Ad.1.7.4 Make Good any Outstanding Variances .........cccssteseesiustineineineinsinetneieeseeneatineinsineinsenetnneneeeete 39
84.16 — A4.1.7.5 Produce and Confirm Trading Statement 40
8.1.47 — Ad4.1.7.5.2 Confirm Trading Statement At
re
8.2 A4.3 Summarise Transaction Data
9 — Information Flows
O44 Transaction Data...
91.2 Cheque and Voucher Values
913 Adjustment Transactions
944 Summaries. .
915 Despatched Dockets......
916 Transaction Corrections
947 Trial Balance Report
918 Final Balance Report............
919 Branch Trading Statement.
Trading Statement Confirmation Event.
40
11 Sales Report to Assist Remuneration Check:
42 so
Non Accounting Data
94143 Bulk Data
9.1.14 Additional Client Data
9.145 Stock Unit Cash Declarations......... sesesnnnneennnnaneen
9.4.16 — Cash Variances,
9.1.47 — Stock Revaluation Information
8 Cash Centre Financial Transaction Data
9 Ledger Entry Information (Horizon Outlets)
0
4
Ledger Entry Information (Cash Centres) .
Explicit Transactions............ os
9.1.22 Explicit Cash Centre Transactions.
9.4.23 Summaries for HRSAP
9.1.24 Card Account Enlivenments. .
25 Client Transaction Summary (CTS).....
26 User Events Log
91.27 — Variances Report ...
9.1.28 Authorisation Diserepancies Reports...
9.4.29 Transaction Corrections Report.
10 Business Processes......
Business Processes
Local Verification,
Produce Reports and Information
Other Data Capture cscs
Discrepancy Management
Compare Generated with Actual Cash Position.
Produce Branch Accounts ..
Summarise Transaction Data
40.2 Business Data
1 B ss Data Model......
10.2.2 Reference Data Sources
10.2.3 On-line Transaction Data (Authorisation/ lessages eto) oa
10.24 — Transaction Data :
410.3 User Interfaces.........
10.4 — Reconciliation
40.5 Audit cc escceeeenetene
tt Non- Functional Requirements
41.1 Volumetrics
11.2 — Sizing Assumptions .
Mf Service Levels
14.3.4 Post Office™
41.4 Problem Management & Tracking
41.4.4 Incident Management
3 March 2004 Version 1.0
© Post Office™ 2004
Page 3 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
$44.2 — Branch Support... .ceccccsssssssssmenensssssssseseseeeeeesseeestuennenseseee cocsstseneeesssnunstitneneesesese
41.4.3 Client Support
4144 — Eailure Recovery... see a
MAS — Backup & RECOVELY 0c scsesssesnsstinnennneennnenssneene
415 — Business Continuity . : sesnnensanesnnnnesaneesnansae
M16 raining. .
Change Specific Non Functional Requirements Required.
12 Technical Requirements.
12.4 Architecture. Principles... see
42.1.4 Application .....
121.2 — Resilience
124.3 Performance
A ComMUNIcations .....eeeceeeseseeeinseeseeseeseeeeineeneineenee ceseeneeneensteeeneeneune ce
12.2 — Architecture Building Blocks 02. eesccceeeeeeene ossssssesesssususuusnssnnensnnnesesenesesiisuusieeeessessee
12.3 Architecture Components
12.4 — Integration & Interfaces ......
Security Requirements.
13.1 Security Policy.
13.2 Physical Security
43.3 Technical Security... - oe
13.4 — Implementation & Development Security
13.5 Security Management.
13.6 — Security Testing
44 Deliverables / Work Packages
14.1 Post Office™
14.2 Fujitsu Services.........
14.21 Development .
4.2.2 End to End Integration, Testing and Acceptance
4.2.3 Managed Service.......
14.24 Documentation.
14.2 Internal Processes & Procedures
—
ls
<t
ligh Level Solutions jesign
14.3, a Internal Processes & Procedures
14.5 Roteonos Data Changes...
45 Planning
15.1 Timescales.
15.2 Dependencies... cessusssnsesiesssneeunassotennnssonesnnsnsatenunsnsesnuaneeeennuenesesnaee
416 Acceptance
47 Testing.
Testing Statement......
{ntemal Functional Testing.
Non Functional Testing
17.14 Interface Testing.............
474 EE Integration Testing...
17.1.6 — E2E Functional Testing........
W717 Pre-Pilot 7
18 Implementation & Migration ....
48.1 Migration Principles
18.1. Migration Timeline...
18.2 Migration Requirements ..... . . 7 esses nose 100
19 Appendix A — Requirements Catalogue 102
20 Appendix B - Reports............. 113
20.1 Branch Trading Statement. . 7 ose coscesaneeeee . 113
20.1.1 Specification 13,
20.2 Variance Report 114
eh
20.3 — Transaction Corrections Report .......ssscccssssssesussssseesnsssessseesessanetesssetenensssese cessunnsetetensssteninssntetinnssseeineseseenssneeee AS,
204 — Sales Report. 116
20.5 — Declaration: Stock on Hand - Stock Report. 7
20.6 Counter Weekly Stock on Hand - Stock Report . cesses cesses ae 8
20.7
20.8
20.9
Stock Unit Balance: Snapshot... 19
Trial Balanoe Report & Final Balance Report (Stock Unit Balance: Report) & Office Balanoe Snapshot 124
Remittance in Slip, Remittance Out Slip, Counter Weekly Remittances In, Counter Weekly Remittances Qut and Counter Weekly
Remittances Summary... 125
3 March 2004 Version 1.0 Page 4 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.10 Office Daily Remittances In, Office Daily Remittances Out, Office Weekly Remittances In and Office Weekly Remittances Out
125
20.14 Transfer In Slip, Transfer Out Slip, Counter Weekly Transfers In & Counter Weekly Transfers Out . 126
20.12 Counter Weekly Transfer Summary ......-.c-ccsserceeee snstonaarenneennarenarectnterneecate ceseeneeneeneeneee 126
20.13 Office Weekly Transfer Reconciliation & Office Weekly Unreconciled Transfers ........-cccsse cessnneeneensasesnanesneeesee 1B
20.14 Office Daily Revalued Product List & Counter Daily Revaluation Session Slip .......s.cccssssuseeunsesseenseeneennseenen 128
20.15 EVEN LOGS... .ccessseseeenseeeneen secneenneees secneennneees cesses . 130
132
132
2016 Office Weekly Suspense Account
20.17 Return Advice Note ........
20.18 Reports proposed to be dele : - seseceetnsessesesnneeenatee ceseceesnneneeenneeenete - 182
20.19 Other reporting considerations . . . . 133
2 Appendix C — Simplification Work Requirements 134
3 March 2004 Version 1.0 Page 5 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
1 Document Control
1.1 Document Information
Horizon Release No: $80
Document Title: Branch Trading Reporting, Management and Control and Transaction Management
Document Type: Conceptual Design
Abstract: This document details the Business, & Operational Requirements for Branch Trading Reporting
{including transaction verification), Management (including Cash and Stock Management) and
Control (including product reporting and regular declarations) and Transaction Management. It
‘shows the High Level Business Process Model, Details the Technical Requirements and describes
the Architectural End-to-End scope and Principles that should be employed in the implementation
of the solutions for the Branch and Transaction Management elements of the Impact Programme.
Document Status: Draft
Originator & Department: David Parnell — Business Solutions
Contributors: Fujitsu Services
Post Office Distribution: Graeme Seedall ; David Parnell
Supplier Distribution: Gareth Jenkins; Bill Reynolds (Fujitsu)
Table 1: Document Information
1.2 Document History
04 1112103 Draft for discussion
02 © 30/1/04 For review by workshops attendees
03 I 17/2104 Containing feedback/comments from workshops attendees
04 3/3/2004 ‘Submitted for formal review
1.0 29/3/2004 Baselined following formal review
12
20
etc
Table 2: Document History
3 March 2004 Version 1.0 Page 6 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
1.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
1.4. Changes in this Version
0.4 None, First draft template.
02 «Second Draft, updated with output from requirements workshops of Jan 04
10 «Final review with Design Authority
Table 3: Changes in this Version
1.5 Key Contacts
David Parnell : 7 Business Process Architect
Gareth Jenkins Applications TDA
Table 4: Key Contacts
3 March 2004 Version 1.0 Page 7 of 133
© Post Office™ 2004
Doc Ref: BIRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
Management
1.6 Review Details
Post Office Ltd:
Design Authority Clive Read
Programme Manager Sue Harding
Technical Design Authority
Business Design Authority David Pamell, Chris Allen
Product Deployment.
Business Change Ben Gildersleve, Ann Clarke, Julie Pope
Release Manager Graeme Seedall
Fujitsu RASD Gareth Jenkins
Fujitsu Project Manager
Optional eview/lssued for Information
Bill Reynolds.
Ruth Holleran Rod Ismay, Ann Cruttenden, Tony Marsh, Vicky Noble, Shaun Delaney, Jacky
POL.
Mackenzie, Tony Utting, Sheena Patience, John Dutton, Alvin West,
Table 5: Review Details
3 March 2004 Version 1.0 Page 8 of 133
© Post Office™ 2004
Doc Ref: BIRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
1.7 Associated Documents
CRICDE/006 3.2 07/07/03 E2E Programme Conceptual Design. Post Office
Ltd
BD/BRD/017 041 21/02/03 Business Requirements - End to End Re-Architecting Post Post Office
Office Product, Branch, Client, Cash and Stock Processes & Ltd
‘Systems Feasibility Study
PSO/IND/E2E/ST PO Ltd Financial Systems Release 3 Conceptual Design Post Office
R023 Ltd
tbs Counter Dialogues for Impact R3 Fujitsu
(o be produced, so title may change) Services
tbs Horizon to POL Client Transmission Summaries AIS Fujitsu
(to be produced by Fujitsu, so title may change) Services
tbs Card Enlivenment Interface Fujitsu
(to be produced by Fujitsu, so title may change) Services
tbs 15 HR SAP 4.6B Interface Documentation Prism
JEDILFS/007 40 LFS to SAPADS and SAPADS to LFS Application Interface Prism
BPIDES/023 Specification
SD/SPE/016 32.0 Horizon OPS Menu Hierarchy Fujitsu
Services
tbs Horizon to POL Data Warehouse AIS Fujitsu
(to be produced by Fujitsu, so title may change) Services
EA/IFS/003 0.2 POL FS AIS Prism
THIFS/008 Horizon to Post Office Technical Interface Specification Fujitsu
Services
SDIDES/005 Horizon OPS Reports & Receipts Fujitsu
Services
PSO/IND/E2E/SO- 1.0 ‘SAPADS to POL FS Application Interface Specification Prism
L016
BP/DES/030
EA/IFS/002 04 POL Finance Systems to TMS / Horizon Transactional Prism
Corrections Interface Specification
TWIFS/001 70 Pathway to TIP Application Interface Specification Post Office
Ltd
Table 6: Associated Documents
Unless a specific version is referred to above, reference should be made to the current approved versions of the
documents.
1.8 Abbreviations/Defi
Abbreviation Definition
ADC ‘Advanced Data Capture
AIS Application Interface Specification
ABL Alliance and Leicester
AP Automated Payments
APS Automated Payments Service
3 March 2004 Version 1.0 Page 9 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
ATM Automated Teller Machine
BTS Branch Trading Statement
cBDB The Post Office Ltd. Accounts system to be replaced by the IMPACT programme
cLs Cash Logistics (formerly CH&D - Cash Handling & Distribution)
csv Comma Separated Values
cTs Client transaction Summary
cit Counter Transaction Timings
DRS Data Reconciliation Service
EDS Electronic Data Systems, a service provider.
EOD End of Day
EPOSS Electronic Point of Sale Service
ETU Electronic Top-Ups for mobile phones.
FAD Financial Accounts Division (FAD Code)
Fis Financial Institutions
HRSAP ‘SAP Human Resources, the Post Office Ltd human resources system.
LFS Logistics Feeder Service
MI See MIS
Ms Management Information Systems, the set of systems that gather Post Office transaction data and provide
management reports about transaction activity.
NBSC Network Business Support Centre
NRDS New Reference Data System
OLA Operational Level Agreement
ONCH Overnight Cash Holding
OpTIP Operational Transaction Processing system, a system to be replaced by the Impact programme
PAF Postal Address File
POL-FS The new Post Office Ltd Financials System being implemented as a replacement to the CBDB suite as part of
the IMPACT programme.
$60 Horizon system release reference, a release contains a number of approved developments, grouped together
to minimise the development, testing and implementation costs, which would be greater if the required
changes were developed, tested and implemented individually
$70 See S60 above
$80 See S60 above
SAPADS ‘SAP Advanced Distribution System
SLA Service Level Agreement
Tc Transaction Correction
TIS Technical Interface Specification
TMS Transaction Management Service, the set of system within the Horizon domain that provide the service of
collecting and summarising the data from the Post Office branches for the central system.
TPS Transaction Processing Service
Table 7: Abbreviations/Definitions
Other generic IT terms can be looked up at: http://www.whatis.com/
3 March 2004 Version 1.0 Page 10 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
2 Introduction
This section describes the objective of the document, any history of its production and other background information, but
excludes material that is already contained in the preceding document control sections.
2.1 Purpose
This document is intended to detail Post Office requirements for the IMPACT Release 3 Branch Trading project. It is intended to
act as the baseline reference for those involved in the various stages of design, development, deployment and support for the
component parts of the Branch Trading project. It is also intended to support the concurrence and approval process required for
the solutions that are to be implemented to meet the specified requirement.
2.2 Scope
Requirement Analysis Stage for Release 3 of the IMPACT Programme has been partitioned to address front-end Branch Trading
and back-end aspects of the requirement.
This document concerns the provision of revised Branch Trading processes at post office branches and Post Office central
facilities that are to be supported via Horizon as part of the IMPACT Release 3 Programme. The document defines Post Office
requirements for these revised front-end Branch Trading processes.
Post Office requirements for IMPACT Release 3 relating to back-end processes are defined in the companion document entitled
PO Ltd Financial Systems Release 3 Conceptual Design (Post Office ref. PSO/IND/E2E/STR/023)
2.2.1 Exclusions
None
2.3 Background
This document has been produced by Post Office Ltd with the assistance of Fujitsu Services and Prism Alliance.
The IMPACT business case authorised by Post Office resulted from a Feasibility Study that evaluated opportunities for
simplifying Post Office end-to-end processes throughout the business. The programme was formerly known as the End-to-End
(E2E) Programme. The business changes that are to be introduced by the IMPACT Programme are to be delivered in three
stages that have been aligned with Horizon releases S60 (Release 1), S70 (Release 2) and S80 (Release 3).
This document is produced as part of the Requirements Analysis stage of Release 3 of the IMPACT Programme.
3 March 2004 Version 1.0 Page 11 of 133
© Post Office™ 2004
Doc Ref: BIRMC&TM-001
POL00038878
POL00038878
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
2.4 Document Explanations
241
Creation Process
Details of the Business Proposition and Requirements have been provided by representatives of the Post Office™ Business
Sponsor, Product Deployment Representative and the Business Architecture Representative.
The High Level End-to-End Solution Architecture and Architecture principles have been provided by the Post Office™ Technical
Architect, who has also supplied the Technical Requirements, Supplier Domains and the required Supplier Deliverables.
Business Process Models
Post Office's functional requirements are represented in the form of Process models using Process objects and supporting
descriptions and information flow definitions. The tool used for creating these Process Models is Popkin Systems Architect. The
models have been created according to the IDEFO modelling standard. An example of the high level process map for the Branch
Trading aspects of the Programme is shown below.
Accounts and Settlement [IDEF0]
The example depicts a number of process boxes and related information flows. Where appropriate, each process box has been
decomposed to a lower level process as part of the IMPACT Release 3 Requirement Analysis activities and is described within
this document. Systems Architect has also been used to capture and manage the inter-dependencies between processes from
which the data attributes required to create systems interfaces will be derived.
Boxes depicted in red are part of the overall process but deemed out of scope for this particular part of the IMPACT design.
Boxes depicted in black are processes which needed to be shown because of their relationship but are delivered elsewhere ¢.g.
Royal Mail Group
These requirements together with the non-functional requirements are also represented as individual statements to enable
compliance and acceptance processes to verify that the delivered solution meets the Post Office requirements. Each
requirement is individually numbered using the following syntax: -
22?-xx - where 727 is a fixed label corresponding to the project and xxx is the requirement number, starting at 001
3 March 2004
Version 1.0 Page 12 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
3 Overview
3.1. Business Proposition
The Accounting and Cash Management Programme Conceptual Design [CR/CDE/006] identified a number of areas for the
business proposition of the programme of which only some will be achieved by the completion of this project. The business
proposition section of the programme is copied below (Section 3.1.1 in this document is a copy of Section 3.3 from the
programme CD). These aims of the programme were considered to develop the principles identified in Section 3.2.1 to scope
this project.
3.1.1. Accounting, Reconciliation and Settlement, including Debt Recovery and Branch Control
3.1.1.1 Scope
Interface of data to RMG financial systems (including for data passed to HR-SAP)
Management of PO Ltd Bank Accounts
Capture, Validation, Verification and Correction of client transaction data from any channel where applicable
Provision of validated client transaction data to internal and external recipients (though some of this is done via POL FS and
Responding to client/branch enquiries concerning transaction data (Enquiries to allow response)
Accounting at branches
Branch control
Recovering debt from branches, clients etc (inc non-transaction) debt
3.1.1.2 Key Priorities
Make the identification of debt easier
Reduce the amount of reconciliation required
Increase the amount of debt recovered
Put the emphasis on clients and customers to validate the data
‘Simplify branch processes by reducing the amount of paper
Centralise/consolidate agents debt
Enable matching of cash at branches with settlement with client
3.1.1.3 Business Drivers/Issues
© — Re-focus on Debt Recovery (financial recovery of money), target 95%
Only 10% of discrepancies are actually debt
Establish a central debt monitoring environment to enable the identification of debt with a high degree of accuracy.
To report Business and Client information separately and accurately.
To increase accounting control in branches
Alignment of management and accounting information
Establish an appropriate and flexible accounting hierarchy
Performance measures of throughputs and the actual financial debt.
Rationalise systems in place to report client and business information.
To modify the method of recovering debt e.g. using payroll for agents.
Enable proper accounting of cash and stock
Improve timing, accuracy, granularity and summarisation levels.
Avoidance of losses from remittances and client settlement
Accounting and settlement on our data, not clients
3 March 2004 Version 1.0 Page 13 of 133
© Post Office™ 2004
Doc Ref: BIRMC&TM-001
Conceptual Design
POL00038878
POL00038878
Project IMPACT - Branch Trading Reporting
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Manual journal documents and human intervention produce errors
Accounting period alignment — branch Wednesday, business Sunday.
Settlement estimating can produce positive or negative interest position
Cash centre accounting is manual, weekly, therefore no through view from transaction to settlement.
3.2. Functional Summary
3.2.4
The following depicts the high level processes and information flows between these processes.
Frode
Nonagement
rnermason
Nanagemen: Infomation
[ Raveanse Da) Stock Rewtaton formation
onsgement =
seamen prod Change no
‘esos and” I_POL Business Ledger 25-F5
Seviement I sausmentTansactons
Debi Recovery Amounts Throws *ayel!
‘Gent Transaction Daa Repory
7% \__spc naa __ 5
“rang Transactions
“Trading 2b.
CCashCente Traneacion Data
Cheques Pmcessed
Siwamine Sesiemens
Sone ai. dense: nm fasuets Gn"
rc Enquiry Res ponsebiter Sates Enuir Cigaiautors eons. dented Transaction Erors,
“ransacion Data if Cosing Analysis
” I ‘Cash Centre Financial Transacton Data y, Mandatory Data
Sook ae ‘Bank Statements,
I eae I
sma] 2 nrc ge
a 7 £
rah leingKoeksoe koeapstes cs
j
3
ca Near Cash Usagds Through ‘Vouchers Despatched
ae oes
ad
I ’
A x Forecast Performance Repors,
Overview
The specification of the requirement detailed in this document, including the descriptions of the new Branch Trading processes,
where relevant and practical, have taken the following principles into account:
Flexibility should be provided for each Branch to manage their own affairs to fit with local requirements, subject to the retention of
appropriate Post Office retail line and business monitoring and control measures.
The balancing of Stock Units at the branch, for the purposes of rolling-over to a new trading period, should take place on a monthly
basis, instead of the current weekly process. Prior to completing the monthly balance, all discrepancies should be brought to account
and all business settled. There should be flexibility within the balancing period to manage local branch affairs, including more frequent
“interim” balancing if required at a local level. There should also be the opportunity to compare and/or balance, on a daily basis, the
Horizon generated cash figure against physical cash held at the Branch (See 4).
As indicated in principle 2 above, the branch trading period should be a month according to a predefined (4-4-5 week) calendar. It is
intended that the branch balance period should continue to end on a Wednesday. This schedule should be arranged to optimise the
phasing of central support requirement for branch processes. This may mean that the schedules for branches may be offset, i.e.
groups of branches will have different balancing schedules to smooth the support requirements. When branches are grouped and
given a balancing and/or trading period end, this will remain consistent for each branch (i.e. it will be a Wednesday mid month every
month, or it will be month end Wednesday every month) this will reduce the confusion in individual branches.
3 March 2004
Version 1.0 Page 14 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
4. To support local branch management processes, there is a continuing requirement to declare physical cash holdings on a daily basis.
Improved local branch reporting should be provided to cover individual Stock Unit positions and the overall branch position regarding:
The Horizon generated cash position
The cash position declared by branch office staff
Q Any +/- variance between the generated and declared positions
This information should be provided to support local branch management and is not incorporated in central accounts.
5. At the end of each branch trading period (which will end on a Wednesday (on a 4-4-5 week basis), local branch management should
be required to produce a Branch Trading Statement that will be comprised of
2 _ asimple summary of business aligned to the trading period that is expected to be printed on one Ad sheet of paper,
‘subject to the number of Stock Units configured for the branch
Q asummary of the branch stock in hand position reporting stock volumes held.
The statement should be generated, signed and retained at the branch to be available to support branch and retail line
management processes. Horizon should notify Post Office central systems when the production of the statement has been
completed at the branch. The Branch Trading Statement should report on the branch trading position at the end of each
trading period once all Stock Units have been balanced and rolled-over to the next trading period. Completion of the
statement should require confirmation by the local branch management that the position reported represents an accurate
account of the branch position. Confirmation should be evidenced by production of a signed copy of the statement that
should be retained at the branch. There is not a requirement to forward an electronic version of the statement to Post Office
central systems.
6. _ It should be possible to obtain a report on a branch's trading position at any time within a trading period to help support effective
branch management and retail line monitoring and control
7. _ Itis an objective to reduce requirements to produce daily and weekly reports at the branch to those required to support mandatory
daily despatch processes, and to introduce greater flexibility for reporting and despatch requirements for all items that are not time
critical and do not have to be despatched daily. Consideration should be given to aligning reporting requirements with the differing
business needs of the various branch types, e.g. it may be practical for Directly Managed Branches to continue to despatch weekly
whilst Rural Branches despatch monthly. The ideal future state would be that daily despatch should be restricted to time critical items
such as cheques, application forms, etc only. It is recognised that the extent to which this principle can be realised by IMPACT will be
constrained by client requirements and it is therefore recommended that it is carried forward for further consideration and action by the
Post Office Sales & Marketing Product Re-Engineering Programme.
8. Processes concerned with checking and confirming stock holdings at the branch should be aligned to the monthly trading period. The
completion of these processes should be a mandatory part of the process responsible for producing the end of period Branch Trading
Statement.
9. Stock in hand held at the branch should be reported and managed by volume and not value until sold or there is reason to adjust the
stock in hand figure, e.g. following detection of lost stock. When stock is sold or adjusted, the associated transaction will include the
value of the sale or adjustment and this value will be reflected in the branch trading position and reflected in Post Office ledgers. The
unit of measure for all stock reporting on Horizon will be the retail sales unit of measure, i.e. the units in which the stock is sold.
10. The existing differentiation between value and non value stock within Horizon should be removed. It is proposed that all stock handled
by Horizon should be controlled, i.e. stock deliveries/dispatches to the branch should be remitted in and out.
11. Within the monthly trading period, branches should have facilities to identify and the flexibility to manage local variances between
system generated and actual cash holding positions, in line with Principle 1 above. These variances will be identified through one of
three mechanisms:
Q Acash declaration (assume that the near-cash items cheques and foreign currency are included in this)
Q Astamp declaration
Q Astock check or declaration
Q Balancing the SU
All local variances identified at the branch must be actioned within the monthly trading period, i.e. Stock Units should not be
allowed to roll-over at trading period end with an outstanding local variance. Prior to balancing the Stock Unit at period end,
any outstanding variances should be forwarded to the branch manager/supervisor's Stock Unit as local suspense items that
should be addressed locally at branch level before the branch rolls over into the next trading period.
12. By the end of a monthly trading period, branches should be required to make good discrepancies between Horizon generated cash
and stock positions and the actual physical position determined by branch office staff. To help facilitate this, existing Horizon facilities
that permit branch staff to post cash discrepancies to a cash suspense account will be removed. Remaining branch suspense
accounts should only be used following prior authorisation via Post Office central processes and will be restricted to use by branch
staff with Horizon manager/supervisor roles.
3 March 2004 Version 1.0 Page 15 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
‘Suspense values can be cleared in several ways, namely through:
Suspense can be cleared to cash, causing a cash variance, which can then be made good
Q Transaction Corrections forwarded to the branch via POL FS (previously known in their manual form as Error Notices)
which create pre-defined transaction to clear suspense and move to the authorised product line
Q Arrangement made for sub postmaster to pay via salary or credit card (handled via Transaction Corrections)
In Directly Managed Branches Managers or Supervisors will be able to clear values into central write off (posting should be
handled via a new Horizon transaction)
This principle would remove the requirement for the use of vouchers to move losses into the centre. Consideration should be
given to the use of this facility to replace the need for paper vouchers that are currently used in conjunction with TP to handle
requirements such as re-imbursement for postage costs.
13. Central accounting and control functions should operate from information based on the daily transaction stream delivered from the
branch.
14. Reference data should be implemented more robustly to optimise the use of validation and range checks that are applied against
transactions at the point of sale in the branch, helping to simplify existing central control processes. The objective is to identify
potential errors more quickly, reduce discrepancies and improve the accuracy of branch accounting without introducing increases in
main path Branch activities.
15. The capture of bulk data should not be linked to the production of the trading account and should be addressed, where practical, by
daily processes to facilitate timely inclusion in Post Office ledgers.
16. The capture of non accounting data should not be linked to the production of the trading account and should be addressed, where
practical, by periodic processes for data capture.
17. Additional data currently captured manually at the time of a transaction should, where practical, be captured and electronically
reported via Horizon. It is recognised that the extent to which this principle can be realised by IMPACT may be constrained by client
requirements and it is therefore recommended that it is carried forward for further consideration and action by the Post Office Sales &
Marketing Product Re-Engineering Programme.
18. The manual Error Notice based process currently operated to handle variances identified centrally or at the branch should be
automated using a Transaction Correction handling process controlled centrally via POL FS to help facilitate the clearing of
discrepancies within a Branch Trading Statement period.
19. An enhanced Sales Report should be available to Branches to enable review of sales activities over a user specified period. For
example, Agents should be able to produce a sales report covering a calendar month to help estimate their expected remuneration for
the period. It is recognised that any such estimate would only be for guidance and would represent an approximation of the Agent.
entitlement.
20. It should not be possible to complete the production of the period end Branch Trading Statement until all items covered by dockets
(e.g. Redeemed Savings Stamped, Redeemed Postal Orders, encashed benefit foils) have been cleared. This principle applies to
items such as cheques, and consideration should be given to opportunities to automate the whole associated process, including cut
off, dispatch and zeroing of volumes held on Horizon.
21. Consideration should be given to the introduction of improved processes that enable the removal of the need for using manual
vouchers and error notices through the use of Transaction Corrections together with additional automation support.
3 March 2004 Version 1.0 Page 16 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
3.3. Systems summary
The following diagram provides an overview of the end state architecture that has been specified by the IMPACT Programme:
Other POL & RMG
IClient Systems HR
(SAP/HR)
RMG
Financials
(ES-FS)
Management
Information
Counter
Application [
‘Transaction
Management I
Reference
Data
3.4 Potential for Change
Stock —
Warehouse:
Management
(Yantra)
Key
l Changed Applications
} Unchanged Applications
<— > Information Flows
The design of the solution to these requirements should be based on a generic approach which will allow future additions to the
functionality.
At the time of writing the most significant changes being considered by the business that may have an impact on this
requirement are
.
Movement of central handling of stock of Foreign Exchange products from Hemel Hempstead stock centre to
handling via Cash Centres, and any consequential requirements to manage Foreign Exchange stock like Cash.
Implementation of a new stock management system within the Hemel Hempstead stock centre.
3 March 2004 Version 1.0
© Post Office™ 2004
Page 17 of 133
Doc Ref: BTRMC&TM-001 Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
4 Constraints
41 Business & Functional
BT-001 Fujitsu Services
Production of a balance report for a stock unit must be possible to be produced within 5 times the
‘current production time for a stock unit with a busy transaction profile, long trading statement period
~BT-002 Fujitsu Services
Functionality not specifically identified to be changed within this document must not be affected to
degrade the existing service provided by the Horizon system.
BT-003 I POL, Fujitsu
I_ Services, PRISM
4.2 Legal & Regulatory
BT-004- POL
Migration to POL-FS must occur at the end of a financial period.
it will be verified that branch processes and reporting changes meet legal and regulatory financial
reporting constraints (e.g. auditors) to ensure that there is sufficient information from the new system
to support regulatory reporting, litigation and criminal prosecution.
4.3 Architectural Framework & Building Blocks
No Specific Requirements
4.3.1 Integration with Other Systems
No Specific Requirements
43.2 Post Office™ Strategic Direction
No Specific Requirements
4.3.3 Post Office™ Approved Technology
No Specific Requirements
43.4 Post Office™ Approved Components
No Specific Requirements
4.4 Fujitsu Services
Itis required that simplification works be carried out to simplify the Horizon System architecture and eliminate reconciliation processes no
longer required. The requirements are documented within Section 21, Appendix C. It is not required that these requirements are to be met
within the same timescales as the other IMPACT requirements documented within this document.
4.5 Prism Alliance
4.6 Other Constraints
No Specific Requirements
3 March 2004 Version 1.0
© Post Office™ 2004
Page 18 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
5 Design Principles
This conceptual design and the requirements identified within it have been developed in accordance with the design principles laid out
within Section 3.2.1 of this document.
3 March 2004 Version 1.0 Page 19 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
6 Functional Requirements
The Requirement Analysis activities that produced this Conceptual Design focussed on Post Office requirements associated with the
‘Create/Verify Branch Trading Statement’ and ‘Summarise Transaction Data’ sub-processes within the ‘Accounts and Settlement’ process,
as depicted in the Functional Summary diagram in Section 3.3. Analysis and decomposition of these high level processes identified their
underlying sub-processes. Where relevant to the scope of this work, these processes were decomposed further into their underlying
processes. This analysis activity was repeated until an underlying process had been identified that could be performed by a single business
tole and for which further functional decomposition would provide no material benefit. The processes identified at the lowest level of
functional decomposition were then further analysed to specify the logical procedural flows and interactions between business user and
system roles. These procedural flows provide the requirement definition on which the counter dialogues will be constructed during the
Solution Specification Stage.
The remainder of this section provides an overview of the high-level process areas that were studied during the Requirement Analysis
activity. The results of the process analysis were used to construct a business process model that was captured in the Popkin System
Architect modelling tool. The process diagrams for the decomposition of the processes, including the procedural flows, are reproduced in
Section 8 below from outputs generated from the modelling tool. Section 9 contains a description of the information flows between the
processes in the model and Section 10 contains the process descriptions.
6.1 Overview - Local Verification
The main purpose of the Local Verification function is to ensure the quality of the data being captured within Horizon by the Branch. This is
to ensure that it reflects reality and is sufficient to feed the subsequent processing based upon it. This is an important part of the overall
Branch Trading design, and has allowed other changes such as monthly account.
The three main functions within this area are:
to validate the data captured, at the point of capture to ensure data accuracy
‘* to perform range checks on reported data, at a summary or sample level, to highlight areas for further investigation and potential
corrective action
* toreconcile the data with other available sources i.e. client data.
The requirements discussions agreed Horizon currently has the functionality to verify data entered at the branch. The only change required
will be to the ranges specified through reference data. This will then meet the objectives of controlling the quality of data captured at the
branch
It was agreed that functionality to perform range checks on data were not required at the branch. These will be provided by Management
Information type reporting systems, which are not within the scope of this part of the IMPACT programme. These requirements are
documented within the document, PO Ltd Financial Systems Release 3 Conceptual Design.
Much of this function currently takes place within Transaction Processing, so by moving these checks earlier in the chain, this should pro
actively eliminate the errors. This will also reduce processing work throughout POL.
Areview of system-based reconciliations has been made to identify those that support business requirements for managing data accuracy,
and thus must be reproduced in new/enhanced systems, and those that can be eliminated by system redesign. These requirements are
documented within the document, PO Ltd Financial Systems Release 3 Conceptual Design.
6.2 Overview - Other Data Capture
The purpose of the functions within Other Data Capture are to ensure that as much of the data that is captured at the Branch is
communicated in the most efficient and effective manner. This will involve more data being transmitted electronically to recipients, for
example POL Clients. This will also meet the programme objectives of simplifying the work required at the Branch.
The three main functions identified within this functional area are:
to input non-accounting data, which is data regarding levels and proportions of various classes of transaction. This data does not
have a financial effect but is required for further processing, often related to remuneration;
to input bulk data, which is data generated from transactions that have been carried out through mechanisms other than Horizon
terminals within branches, including Lotto terminals and ATMs;
— to capture additional data related to customer transactions which must be reported to the client, but which is currently captured
manually at the point of transaction for example
The requirements discussions concluded that the existing facilities for entering non-accounting and bulk data within the Horizon system will
continue to meet the requirements to capturing such data.
The requirements analysis also identified opportunities, within the procedures for administering various products, to capture customer data
at the point of transaction and reduce the post transaction processing of this data. However, it has been recognised that changing these
procedures would require negotiations with the clients. As such this is best altered as part of the Product Re-engineering programme
currently being implemented within Post Office Ltd. In spite of this being out of scope, the opportunities have been identified, and these
have been taken into account when designing a generic Branch Trading process. Following further business as usual product re-
engineering work, this should release additional benefits for POL.
3 March 2004 Version 1.0 Page 20 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
6.3 Overview — Produce Reports
This functional area has the purpose of producing various reports from the data captured within Horizon. This allows data to be
communicated directly from the branch to various sources. As part of the requirements analysis, the various product summaries that are
produced on a daily or periodic (usually weekly) basis have been reviewed. Opportunities to eliminate the production of some of these
summaries have been identified, though it has been recognised that such elimination would require negotiations with the POL clients.
Again, this is part of the Product Re-engineering programme. Again, in spite of this being out of scope, this has been taken into account
when designing the Branch Trading process, so additional benefits can be realised for POL. Where it has been possible to remove manual
summaries and replace them with ones from Horizon, this has been taken.
This analysis considered requirements for improved control over dockets sent from the branch and identified that this would return little
benefit over the existing cut-off mechanisms, which it was decided would remain unchanged. The analysis has also reviewed the content of
other reports produced at the branch and revised the content of some of these reports to enhance the information they provide.
6.4 Overview - Daily Trading
The purpose of these functions is to support the Branch Managers in performing a regular (probably daily) set of processes to give them the
information and controls to adequately manage their business. In reviewing this area the requirements study identified benefits from utilising
the current daily cash declaration process. The cash declaration data compared to the system generated figures for cash, can be used as
an indicator as to the likely state of balance within the Branch. This is based on the assumption that a cash variance/discrepancy would be
the first and best place to identify a potential error.
The variances won't be reported centrally because they are local pieces of information, for the Branch to deal with. It was agreed that to
report, monitor and control these would be too large a scale exercise for it to be beneficial. In particular, because the variances will be
available for every Stock Unit. This report should be used as a flexible tool for Branches to make the best use to manage themselves on a
day to day basis. This is particularly relevant within a longer trading period.
The requirements discussions identified requirements for a new report to be produced by the Horizon system, the Cash Variance Report.
This report will summarise by day and by stock unit the following data for the Branch Manager:
the system generated cash holdings
the declared cash holdings, if made (indication will be shown when cash was not declared)
any variances between these figures
any values held in suspense
the numbers of any outstanding Transactions Corrections (correction actions generated from the Post Office Ltd. accounts
system).
This report will be produced and retained within the Branch, but can be reviewed by the Retail Line Manager and/or Auditors on visits.
Again, these roles will view the report as an indicator as to whether or not the Branch Manager is effectively using the managerial controls
available.
6.5 Overview - Produce Branch Accounts
This area of functions has the purpose of providing all of the mechanisms for the branch to produce a balanced set of accounts, which
accurately reflect the result of all of the trading for the period. The requirements discussions agreed to move Branches from settling their
accounts on a weekly basis, to a monthly basis. This recognises that the creation of regular Cash Variance Reports should provide the
Branch Manager with the ability to manage the Branch on a day to day basis, within this extended period. It will also give an early indication
of any potential errors in the accounts. Existing mechanisms to correct such errors will be available to be used within the accounting period
(i.e. the Branch Manager will not have to wait till the end of the accounting period to make such corrections). With the data quality
(verification) work discussed above, this should improve the transaction stream of data, potentially reduce errors, and hence simplify the
overall branch trading (accounting) process.
The new Post Office Ltd accounting system (POL-Financial System (POL-FS)) will base its information directly on the daily stream of
Transaction Data being provided by Horizon, rather than the current Cash Account summaries. There will no longer be a requirement for the
branch accounts to be posted into the Post Office Ltd. Accounts systems.
A requirement will remain for branch accounts to be produced and on a regular basis (monthly on a Wednesday, on a 4-4-5 week basis) but
they will be produced for local accounting purposes and so will be retained within the branch. Requirements were agreed to support the
management of conformance to these requirements, by reporting the production (and non-production) of branch accounts to the
Management Information system(s).
The analysis has also devised a new branch accounts report (Trading Statement Report) to ensure that it displays the required accounting
information that the Branch Manager needs in a simpler more summarised format The design has retained elements of the current
balancing and accounting process which are simple and understood, but has attempted to rationalise processes to a degree. There has
also been a separation of processes where there is no strict requirement for them to be finalised together. This should mean a more
streamlined process, both daily and weekly.
3 March 2004 Version 1.0 Page 21 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
6.6 Overview - Stock Control
This area identifies a group of functions that support the control of stock around the Post Office Ltd. business. In branch trading terms the
functions have the purpose of providing appropriate information as to movements of stock items within the branch, whether through delivery
(remittance in or out), sale or adjustment. The overall purpose of the Stock Control function is to ensure that the business has visibility of its
stock holdings across the Post Office Network, to accurately account for that stock which is held on the balance sheet, and to effectively
control all stock (whether balance sheet stock or not).
It has been agreed to remove the notions of value and non value stock, and just have Stock. This will bring effective system control to
managing stock, and to remove the reporting of stock by value within the branch accounts and reports. In Branches stock will only be
associated with a value when it is sold or adjusted; value indicated stamps are a notable exception to this. This will remove the need for
stock revaluations; instead stock will simply be re-priced at the appropriate time.
6.7 Overview - Discrepancy Management
This area of functions has the purpose of providing mechanisms to make adjustments to branch accounts, to correct errors and ensure
Branch accounts align with the Post Office Ltd. Accounts within POL-FS. Various mechanisms are available to identify errors that require
adjustments, and the discrepancy management functions may be initiated from various places across the business. The main areas will be
from within the Branch, from POL Clients or centrally via distributing electronic transaction corrections. These corrections will replace the
current error notice processes and should not involve any manual paperwork or processing. They will be received and actioned via Horizon,
and will be distributed more quickly, potentially only days after an error is recorded.
The analysis has also identified requirements to more tightly control and police the use of the suspense account within the branch accounts,
only a limited subset of the existing suspense account products will be retained. The contractual requirements for agents to make good
unknown errors in branch accounts will be used instead.
6.8 Overview - Transaction Management
This functional area has the purpose of summarising the data regarding transactions to the appropriate levels for onward communications
to the central systems
The requirements discussions have identified the needs to support the various data feeds currently fed into, and out of, OpTIP and CBDB
and to identify mechanisms for the acceptance, and delivery, of the information on those feeds by the replacement systems.
In doing this the analysis has identified all opportunities to eliminate future development and testing costs, within the transaction
management systems. The opportunity to have cash centre transaction data automatically fed into the central systems is also to be realised
via this mechanism,
3 March 2004 Version 1.0 Page 22 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
7 Exclusions
Anumber of facilities or implementation methods are described in the overall requirements analysis. Post Office confirms that
that the following items are not required in the Branch Trading Reporting, Management and Control and Transaction
Management solution: -
Item
Comment
Management Information
itis confirmed that reporting of management information across
transaction data, identifying trends and providing mechanisms to
analyse transactional data is excluded from the scope of these
requirements.
Product Re-engineering
Itis confirmed that, though many of the benefits sought through
elimination of off-system data capture and reporting could be achieved
by changing the way that this data is captured (on-system) that such
changes are out of scope of these requirements. Since such changes
‘would require negotiations with the clients for which these product are
sold and so would best be altered as part of the Product Re-engineering
programme.
‘Stock Management
Opportunities for improving overall stock holdings stock replenishment
processes have not been followed up as part of this project. Any such
opportunities are assumed to be being followed up by the
implementation of Yantra
Bureau de Change handled through Cash Centres.
There is a project currently considering the benefits of handling Bureau
de Change stock products through cash centres. Any requirements
telated to making such changes are deemed out of scope of this project.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 23 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8 High Level Process Models
8.1 A4 Accounts and Settlement
Debt Recovery tans
‘pao Goat Fay Warmatia)
Penn Da cerry Are Tau Paok
“ar cheques Processes, I Verfeation
oor onsen FREE BOT
. Friece I Gator branch Enea ‘eager I
hn an Vee tins
sock Teaseton aera Bren Trdg Statement Stock Trematn ntarnan Tresesien Caress rg Transoctoe POL Buhess Lair
Tenet oe - — my nt
‘stock Revation r Actein eetins __ “Trg I een Tansactons er M's ma
co Brine Con Feng © I cei ety eat
ach bth
aaron Fret Tn Lesge Ent intematin) on
Sanaa
a I cvetrommcsote I
chet Siay Rap a
FS Set aa aaa cn ate Ce Ee I coin Fow Fees poe
enact ts a lw Fg Dae er per
7a wi baa 2 ad
me ‘Sammars for HRSAP Wardatory Data
LS connor I rar tora Rae —
meee nt sree Semhou I pases te ematn {remem sera >
3 March 2004 Version 1.0 Page 24 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
8.1.1 A4.1 Create / Verify Branch Trading Statement
Cheque and Voucher Values Produce ‘Summaries
-——
Reports and
Transaction Data Local Transaction Data formation I-—esbatched Dockets.
———————+I_ Verification 2
1 A412
A444
Other Data
Capture
3
A413 Compare
° Generated w ith Adjustment Transactions
Adjustment Transactions +> _ Actual Cash 7 >
Position
6]
Discrepancy
A416
Corrections Management. I_! ;
> Outstanding Transaction
5 Corrections
A415 Produce J
p Branch
Accounts
7 Branch Trading Statement
A4A.7
3 March 2004 Version 1.0 Page 25 of 133
© Post Office™ 2004
POL00038878
POL00038878
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.2 A4.1.1 Local Verification
Perform Range
Transaction Data Checks - 8 Exception Warning Report,
> Periodic -—_——
1
att
M
PerformRange
Checks -Transaction! Transaction Data
Validate Data [I
Captured
2I
A41.1.2
HorizorI Sales
Automated
Reconciliation Authorisation Discrepancies Reports
I I Authorisation Discrepancies Repo
3
4.1.1.3
3 March 2004 Version 1.0 Page 26 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project
COMMERCIAL IN CONFIDENCE
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
8.1.3 4.1.2 Produce Reports and Information
Cheque and Voucher Values
Produce Daily
Summaries Summaries
Transaction Data
A421
‘Summaries
Produce
Periodic
Summaries
A422
Produce Sales
Report to Assist
Verity
‘Summaries
Summaries
4
A4A24
Sales Report to Assist Remuneration Check
Remuneration
Check
3
A41.23
Despatch
[Redeemed Dockets I Despatched Dockets
A4125
pp Horizon Reports
C}
A4126
Produce Other User Events Log
Transaction Corrections Report
3 March 2004 Version 1.0
© Post Office™ 2004
Page 27 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001
Conceptual Design
Project
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
POL00038878
POL00038878
COMMERCIAL IN CONFIDENCE Management
8.1.4 4.1.2.3 Produce Sales Report to Assist Remuneration Check
User
Decide to Produce Kone
Seles Report ve revise data Ne
Nee
Torizan Siem
Ne DisplayError
so Messave
v v
Sales Ropar Display Sales “eport generat Produce Sales
Button RevewSere sible for date Ye Report
I} — euscren res 2 = se]
3 March 2004 Version 1.0 Page 28 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
Project
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.5 A4.1.3 Other Data Capture
Non Accounting Data Input Non
Accounting
Data
1
A413.4
Buk Data Input Buk Data
>
2I
A41.3.2
put
Additional Gent Data Addtonal >
*) Client Data Transaction Data
3
A41.33
3 March 2004
© Post Office™ 2004
Version 1.0
Page 29 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.6 A4.1.5 Discrepancy Management
Receive
Transaction Corrections Automated
Message
1
A4151
Hand Outstanding Transaction Corrections
Transaction :
Correction Adjustment Transactions
2
A41.5.2
3 March 2004 Version 1.0 Page 30 of 133
© Post Office™ 2004
POL00038878
POL00038878
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.7 4.1.5.1 Receive Automated Message
Tog On User
Horzon Sysiem
Display Transaction
Correction Recieved
Message
Yes
Transaction a
Correction No End
Message Arrives in Manager
Branch Logging On?
3 March 2004 Version 1.0 Page 31 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
‘Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.8 4.1.5.2 Handle Transaction Correction
POL00038878
POL00038878
‘ack to Resahe ‘Goose
“Teseer Tresscion Tersseo
Corectow Cores Cher cancion Ostia I Jom
es
aa Sp
Trersecion ay [ Bess Oat) coe Kessoa> (Reco Trarascton]
eo 7 ee Ly oleae en LES te Sana
processed vale
"esate ‘Goren Fae
3 March 2004 Version 1.0 Page 32 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
8.1.9 A4.1.6 Compare Generated with Actual Cash Position
re
‘Transaction Data Generated w ith
Actual Cash Held
for Stock Unit
1
A4.1.6.1
Stock Unit Cash Declarations
Make Good or
Hold Any Cash
Variance
Cash Variances
¥
Outstanding Transaction Corrections
Create Variance
Report ... Compare
Generated w ith Actual
3
AdjustmentTransactions
eS
A41.6.3
Variances Report
Cash Held Across
Branch
2I
A41.6.2
3 March 2004 Version 1.0
© Post Office™ 2004
Page 33 of 133
POL00038878
POL00038878
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
‘Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.10 4.1.6.1 Compare Generated with Actual Cash Held for Stock Unit
3 March 2004 Version 1.0 Page 34 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.11 4.1.6.2 Create Variance Report ... Compare Generated with Actual Cash Held Across Branch
User
Ne
co
Hoduen rec
anyway?
Display ota
Sockun's Hate
Declared Yer,
Message
Cash Decartions Cash Deciaaion
Reventon Reten Soreen
Fredice Sock
Dy ore vernces ed
por -——>I
3 March 2004 Version 1.0 Page 35 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.12 A4.1.6.3 Make Good or Hold Any Cash Variance
Tae
Make Good Hold
Beside 0 Wake Goad FiGann aw ir Anwar Basaero Tea
3 Cash Varance fora be Wade Good Cash Variances
prtcur Sek Unt I 34 L I
Taran Sa
ara ar oo
ia >] Peasarart
3 March 2004 Version 1.0 Page 36 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.13 A4.1.7 Produce Branch Accounts
Investigate ke an)
Balance ‘Outstanding
Discrepane Variances
1.
1
Produce Trial
jalance
E
fier
Stock Revalt ‘Stock : _ Branch Trading Statement
fa
Revaluation} p) Confirm veces Statement Confirmation Eve
(Stamps) ‘Statement il
me mits
_IRoll Over inactI
I Stock Units
3 March 2004 Version 1.0 Page 37 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
8.1.14 A4.1.7.1 Stock Checking
‘Transaction Data
Local Stock
>} Check Stock
-—pl Held for Stock
Adjustment Transactions
Unit 9
AaA7.4.2
Review Stock
BI Held Across I Office Snapshot Report
Branch
3
A41.7.13
Remit h/Out
Stock
1 Stock Changes due to Remittances
A4N7.4.4
3 March 2004 Version 1.0 Page 38 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001
Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.15 4.1.7.4 Make Good any Outstanding Variances
User
Make Good
Decide to Make Good Put Cash in Draw Enter Amount
Cash Variance for a Made Good
particular Stock Unit I —2> > —
Horizon System
New "Make Good" Update Cash
Button Declaration and End
> Lp} Record Amount I- >>}
Made Good
3 March 2004 Version 1.0 Page 39 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001
COMMERCIAL IN CONFIDENCE
Conceptual Design
Project
IMPACT - Branch Trading Reporting,
Management
Management
and Control and Transaction
8.1.16 4.1.7.5 Produce and Confirm Trading Statement
Verified Transaction Data
>
Produce Trading
‘Statement Reports
4
Branch Trading Staterrent
A4.1.7.6.1
Confirm Trading I Trading Statement Confirmation Event
Statement
so
2I
A4.1.7.6.2
3 March 2004
© Post Office™ 2004
Version 1.0
Page 40 of 133
POL00038878
POL00038878
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.1.17 A4.1.7.5.2 Confirm Trading Statement
Pay
‘ay Te
samt crea =
> nerten tenn I —
ie Ask
vo > Ries ena oe]
[Beat
3 March 2004 Version 1.0 Page 41 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
8.2 A4.3 Summarise Transaction Data
Cash Adjustments
‘Cheque and Voucher Vaties —Gard Account Enlivenmrents
Stock Transaction Information
Adjustment Transactions
Sean
Stock Revaluation Information Transactions forI ‘Accumulate
Day Daily Transactions Transactions for
Transaction Data ‘Summarisation
Branch Cash Holding J
4 A432
AaB
Transaction Data and Sumraries
Cash Centre Financial Transaction Data [~ Summarise Summaries for HRSAP
Deliver Data to
Cash Centre External Systerrs
Transactions Explicit Transactions for MIS
Pouch Details (Electronic)
Cash Centre Transaction Data
4 Explicit Cash Centre Transactions
A433 Ledger Entry Information
a
4I Other Data Feeds (to Clients)
IVEY
Version 1.0 Page 42 of 133
3 March 2004
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9 Information Flows
9.1.1 Transaction Data
Attribute Description
Description This is the data stored as a result of conducting a transaction at a branch — both customer
facing and non-customer facing (e.g. bulk input or Remittances) which have an impact on the
position at the branch
Logical data items = Session ID
= Transaction ID
= User ID
= Stock Unit
= Trading Date
= Date and Time
= Product ID
= Sale value
= Sale quantity
= Additional data items (where relevant)
= Remittances Information (where relevant)
= Transfer Information (where relevant)
Special requirements. None
Time constraint All transactions conducted at the branch must be recorded at the end of a Session
Type of Object Electronic records
Source Horizon
Destination TMS, Clients (where relevant) & MI
9.1.2 Cheque and Voucher Values
Attribute Description
Description This is a representation of those transactions associated with Cheques and Vouchers.
Logical data items See Transaction Data (Section 9.1.1)
‘Special requirements. None
Time constraint See Transaction Data (Section 9.1.1)
Type of Object Electronic records
Source Horizon
Destination TMS & MI
3 March 2004 Version 1.0 Page 43 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.3. Adjustment Transactions
Attribute Description
Description This is a representation of those transactions associated with Adjustments, either as a result
of Transaction Corrections or as a result of resolution of variances in cash or stock levels,
Logical data items See Transaction Data (Section 9.1.1)
Special requirements None
Time constraint See Transaction Data (Section 9.1.1)
Type of Object Electronic records
Source Horizon
Destination TMS, POL-FS & MI
9.1.4 Summaries
Attribute Description
Description These are the printed outputs required to meet client and onward processing needs where an
electronic data feed is not used, or when the branch wishes to retain locally.
Logical data items The logical data items vary from summary to summary but will follow the general pattern of
= Header
= Product/client name
= FAD code/name
= For each transaction’
= Transaction number
= Transaction additional data (¢.g. reference number)
= Value
= Total value of transactions
Note there is no change proposed in this area
Special requirements None
Time constraint To be produce in accordance with Branch Processes
Type of Object Printed output or manual forms
Source Horizon or the Branch
Destination Clients, Other Processing Agents, Branch or TP
9.1.5 Despatched Dockets
Attribute Description
Description These are the physical dockets and the details of their contents which are sent out of the
branch.
There are two flows here:
= The Physical Dockets and any control report sent with them.
= The electronic record sent indicating that the dockets have been sent out
3 March 2004 Version 1.0 Page 44 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Attribute Description
Logical data items = Header
= Product/client name
= FAD code/name
For each transaction’
= Transaction number
= Transaction additional data (e.g. reference number)
= Value
Total value of transactions including physical dockets/vouchers.
As current information flow, no change required.
Special requirements None
Time constraint Dependant on business procedures for clearing dockets from the branch, which may be
based on client requirements.
Type of Object Physical vouchers and either electronic file or printed output
Source Horizon
Destination TMS & MI
3 March 2004 Version 1.0 Page 45 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.6 Transaction Corrections
Attribute Description
Description These are the Transaction Corrections which have been generated by POL-FS for the
automatic correcting of a branch accounts
Logical data items The TC will define the number of buttons to be displayed and the set of Transactions to be
processed for each button and the text to be displayed to the Branch Manager (and similar
roles defined in the process description for “Receive Automated Message (A4.1.5.1)")
For further information see document, POL Finance Systems to TMS / Horizon Transactional
Corrections Interface Specification
Special requirements None
Time constraint ‘Should be delivered overnight from POL-FS
Type of Object Electronic records
Source POL-FS
Destination Horizon (multiple flows — initially one to TMS and subsequently a second flow from TMS to
the Branch.
9.1.7 Trial Balance Report
Attribute Description
Description This is the report produced whenever a user decides to balance a stock unit for the end of a
balance period or trading period. The report identifies trading position, cash and stock holding
and any discrepancies, which must be investigated and corrected before the Stock Unit can
be balanced
Logical data items See Section 20.8 in Appendix B
Special requirements None
Time constraint None
Type of Object printed output
Source Horizon
Destination For retention in the Branch
BT - 006 Fujitsu Services I Anew trial balance report will be produced, the content and format of which will be as
I specified in Appendix B of this document.
3 March 2004 Version 1.0 Page 46 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.8 Final Balance Report
Attribute Description
Description This is the report produced whenever a user rolls over the balance of a Stock Unit for the end
of a balance period or trading period. The report identifies trading position, cash and stock
holding and adjustments.
Logical data items See Section 20.8 in Appendix B
Special requirements. None
Time constraint None
Type of Object printed output
Source Horizon
Destination For retention in the Branch
BT-007 Fujitsu Services The content and format of trial and final balance reports will be altered as specified in Appendix B of
this document
9.1.9 Branch Trading Statement
Attribute Description
Description This is the report produced at the end of each monthly accounting period to reflect the
branch's trading position for that period.
Logical data items See Appendix B (20.1 & 0)
Special requirements None
Time constraint Monthly
Type of Object printed output
Source Horizon
Destination For retention in the Branch
BT - 008 I Fujitsu Services Anew trading statement report will be produced, the content and format of which will be as specified
in Appendix B of this document
3 March 2004 Version 1.0 Page 47 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
POL00038878
POL00038878
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.10 Trading Statement Confirmation Event
Attribute Description
Description This is the event notification from the branch that a branch trading statement has been
produced.
Logical data items e FAD Code
¢ Date
e Time
«© User
« — Trading Statement Completed Indicator
For further information see document, Horizon to POL Data Warehouse AIS
Special requirements. None
Time constraint Monthly
Type of Object Electronic record
Source Horizon
Destination MI
9.1.11 Sales Report to Assist Remuneration Check
Attribute Description
Description This report will provide the outlet manager with sales information, which can be used for
various reasons including to calculate/check remuneration. Excludes current day and any
period for which Horizon does not have transaction data.
Logical data items Current sales report should remain with additional functionality to allow date range request
for information (see Section 20.4)
Special requirements. None
Time constraint On user request, likely to be at least monthly
Type of Object Printed output
Source Horizon
Destination Branch
9.1.12 Non Accounting Data
Attribute Description
Description This is information about transactions which are not captured at the point of sale and is used
to generate non-accounting Transactions so that the information is available for Post Master
Remuneration etc.
This information may not affect the branch accounts but may affect settlement or
temuneration processes.
There are no changes proposed in this area with respect to the data captured and the
controls around capturing this data at trading period end. However, it is anticipated that
business procedures will be written for this data to be entered more frequently than trading
period end processing.
Logical data items Manual records used to update Horizon.
3 March 2004 Version 1.0 Page 48 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Attribute Description
Special requirements None
Time constraint As described by business procedures, at least monthly before Trading Statement processing
can be completed.
Type of Object Manual records
Source User entered
Destination Horizon
9.1.13 Bulk Data
Attribute Description
Description These are summary transaction details relating to transactions that are captured at the point
of sale using third party equipment. Information required for accounting, settlement and
remuneration purposes.
There are no changes proposed in this area with respect to the data captured and the
controls around capturing this data at trading period end. However, it is anticipated that
business procedures will be written for this data to be entered more frequently than trading
period end processing.
Logical data items Manual records used to update Horizon
Special requirements None
Time constraint As described by business procedures, at least monthly before Trading Statement processing
can be completed.
Type of Object Manual records
Source User entered
Destination Horizon
9.1.14 Additional Client Data
Attribute Description
Description This is additional data that is to be associated with a Transaction for passing on to a Client
using the AP ADC functionality or by some manual process.
There are no changes proposed in this area with respect to the data captured and the
controls around capturing this data at trading period end. However, it is anticipated that
business procedures will be written for this data to be entered more frequently than trading
period end processing.
Logical data items Various — Client specific
Special requirements None
Time constraint As described by business procedures, may be based on client requirements.
Type of Object Paper supporting documents or application forms
Source Paper documents
Destination Clients
9.1.15 Stock Unit Cash Declarations
3 March 2004 Version 1.0 Page 49 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Attribute Description
Description This is the result of the actual cash figures entered into the system by: denomination and
calculated total
Logical data items
For each declaration:
e User ID
© Stock Unit
¢ — Declaration Date
¢ Date/Time
¢ — TIILID (if in a Shared Stock Unit)
¢ — Variance Adjustments (if applicable)
For each denomination:
° Value
Total (calculated from denominations)
Special requirements
None
Time constraint
Daily at end of day
Type of Object Electronic record
Source Horizon
Destination Horizon
9.1.16 Cash Variances
Attribute Description
Description These are the differences between the system generated total figure and the cumulative total
of the actual cash figures entered by the user within a Stock Unit.
Logical data items
For each Stock Unit:
e User ID
© Stock Unit
¢ Date/Time
¢ — Variance value
¢ — Declared Value
Special requirements
None
Time constraint If invoked to be completed by End of Day or first thing the next morning as part of the log-on
process.
Type of Object Electronic record
Source Horizon
Destination Reported locally in Branch
9.1.17 Stock Revaluation Information
Attribute
Description
Description
Information about stock which is to be revalued.
Logical data items
= Product Id
= Changes to Value
= Effective date of change
Special requirements.
None
3 March 2004
© Post Office™ 2004
Version 1.0 Page 50 of 133
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Attribute Description
Time constraint
Must be available on the day of revaluation, is usually provided to give reminders of
revaluation for 4 days before revaluation.
Type of Object Electronic Record
Source Reference Data
Destination Horizon
9.1.18 Cash Centre Financial Transaction Data
Attribute
Description
Description
Daily feed of Cash Centre summary and transaction details. The S80 SAPADS - POLFS
interface will be based on the S60 interface. Client transactions (e.g. giro change) need to be
captured at the individual level. The detailed records will have a Client Id and Transaction
Time added, but will otherwise be the same as the S60 AIS.
The file will contain all activity in cash centres that have a financial effect on PO Ltd.
For further information see document, SAPADS to POL FS Application Interface
Specification.
Logical data items
= Cash (£ and Foreign exchange) & Bank balances
= Transactions initiated in cash centre & completed in liquidity team managed
bank accounts
= Cash (£ and Foreign exchange) Remittance in/out data.
= NI Cheques remittances
= Write offs and adjustments
Special requirements
None
Time constraint
Target delivery time to TMS = 4.00am, daily,
Type of Object Electronic Records
Source SAP ADS
Destination TMS & POL FS.
9.1.19 Ledger Entry Information (Horizon Outlets)
Attribute
Description
Description
The files will contain all Horizon outlet activity that has an impact on the financial ledgers or
the stock quantities.
Logical data items
= Movements in Cash/near cash in hand
= Sales of stock items quantity and value
= Client transactions number and value
= Remittance in and out of cash/near cash and stock
= __Adjustment/suspense item values
3 March 2004
© Post Office™ 2004
Version 1.0 Page 51 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Attribute Description
Special requirements The link between the Horizon definitions of client products and the POL FS definitions of
materials, clients will be controlled using Type A reference data.
Time constraint File must be received & processed by 07:30 on day B where day A = Trading day
Type of Object Electronic records
Source TMS
Destination POLFS
9.1.20 Ledger Entry Information (Cash Centres)
Attribute Description
Description Daily feed of Cash Centre summary and transaction details, as provided by SAPADS to the
TMS (no further summarisation is applied).
Logical data items It is assumed that the flow defined within Section 9.1.18 is passed on to POL-FS,
unchanged. For further information see that definition.
Special requirements. None
Time constraint File must be received & processed by 07:30 on day B where day A = Trading day
Type of Object Electronic files
Source TMS
Destination POLFS
9.1.21 Explicit Transactions
Attribute Description
Description The TMS will provide the MIS with explicit Horizon transaction details on a daily basis.
Logical data items = Horizon transactions
The data itemsifile structure will be detailed in the TMS-MIS AIS [being produced by PRISM].
The data is as provided by the existing OpTIP interface, with additional data related to
Banking, ETU, Debit Card and Bureau de Change transactions.
Allevents, currently passed to OpTIP, to be passed plus the following:
= Variance Report Produced
= Cash Made Good (or excess cash withdrawn)
= User Prompted about Outstanding Transaction Corrections
= Trading Report Produced
Special requirements. None
Time constraint Must be available to the MIS by 3:00am, daily.
Type of Object Electronic records
Source TMS
Destination MIS
3 March 2004 Version 1.0 Page 52 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.22 Explicit Cash Centre Transactions
Attribute Description
Description Cash Centre transactions for external clients reported from the SAPADS to TMS interface.
Logical data items Transaction details to include:
= Transaction Date
= Transaction Time?
= Cash Centre (FAD)
= Client
= Product/Service
= Amount
= Quantity
Special requirements None
Time constraint Must be available to the MIS by 5:00 am, daily
Type of Object Electronic records
Source TMS
Destination MIs
9.1.23 Summaries for HRSAP
Attribute Description
Description Remuneration data for HRSAP, based on sales transactions carried out at Horizon outlets.
Logical data items For the period being processed (previous month)
= Outlet
= CIT
= Total Value
= Total Volume
Products to be included, and associated Product/CTT mappings, will be defined in Reference
Data. Details to be provided by PRISM in the TMS - HRSAP AIS.
Special requirements None
Time constraint There are two calendars
= The periods for which data is summarised
= The date on which such summaries should be sent to HRSAP.
Both will be defined in Ref Data
Type of Object Electronic records, CSV file
Source TMS
Destination HRSAP
3 March 2004 Version 1.0 Page 53 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.24 Card Account Enlivenments
Attribute Description
Description Details of Card Accounts activated in a Calendar Month (by the customer making an initial
transaction).
Logical data items = Calendar Month
= Outlet
= Volume
Special requirements None
Time constraint File received from EDS by the 3rd of the month.
Type of Object Electronic records, CSV file
Source EDS (via POL currently)
Destination TMS
9.1.25 Client Transaction Summary (CTS)
Attribute Description
Description The client summary report is currently a daily interface into OpTIP which reports the value
and volume of the AP client data
In order for Client Settlements and the client to have a consistent view of the settlement
required each day the information which is currently sent to OpTIP must be sent to the client
settlements team daily
Logical data items Transaction details (as per current file)
= Record Type Identifier
= Client Identifier Code
= Version Number of Client Identifier
= Item Id
= Version Number of Item
= Client Trading Date
= Total Number of Transactions
= Total Value of Transactions
Special requirements. None
Time constraint Daily, to be available by 07.30
Type of Object Electronic records
Source TMS
Destination POL (Client Settlement Team)
3 March 2004 Version 1.0 Page 54 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.26 User Events Log
Attribute Description
Description Areport of User events that have happened within the Horizon System
Logical data items As current but additionally, make good adjustments, doing the branch trading statement,
viewing/producing cash variance report and displaying reminders that there are outstanding
transaction corrections.
Special requirements. None
Time constraint None
Type of Object Physical Report
Source Horizon
Destination Branch
9.1.27 Variances Report
Attribute Description
Description A report of cash holdings, by Stock Unit, identifying any variances between the system
derived cash position and the physical cash position.
Logical data items ‘System derived cash holding
Declared cash holding
Variance between the two above
Values in suspense accounts
Number of Outstanding Transaction Corrections
Branch Totals
Special requirements. None
Time constraint None
Type of Object Physical Report
Source Horizon
Destination For retention in the Branch
BT-009 Fujitsu Services A new variances report will be produced, the content and format of which will be as specified in
‘Section 20.2 in Appendix B of this document
3 March 2004 Version 1.0 Page 55 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
9.1.28 Authorisation Discrepancies Reports
Attribute Description
Description Reports currently produced to identify potential reconciliation errors across the Network
Banking service.
Logical data items As currently defined for reports N101 and N102
Itis assumed that the report N103 will no longer be required.
Special requirements None
Time constraint None
Type of Object Physical Reports
Source Horizon
Destination Finance
“BT-062 Fujitsu Services The NB103 DRS reconeiliation reports will be eliminated
9.1.29 Transaction Corrections Report
Attribute Description
Description Reports providing details of Transaction Corrections Process and Outstanding Transaction
Corrections.
Logical data items Transaction Correction Reference
Transaction Correction Status
Affected Product
Settlement Product
Amounts
Allowed Options
Description
Date Issued
For further information see Section 20.3 in Appendix B
Special requirements. None
Time constraint None
Type of Object Physical Report
Source Horizon
Destination To be retained in branch
~BT-065 Fujitsu Services 4 new Transaction Corrections report will be produced, the content and format of which will be as
‘specified in Section 20.3 in Appendix B of this document
3 March 2004 Version 1.0 Page 56 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10 Business Processes
10.1 Main Business Processes
10.1.1 Local Verification
4. Perform Transaction Checks ~ Periodic
2. Perform Range Checks - Transaction ... Validate Data Captured
3. Automated Reconciliatic
10.1.1.1 Perform Transaction Checks — Periodic (A4.1.1.1)
Attribute Description
Description Compare transactions on a periodic basis (driven by the data warehouse parameters) with
set ranges (to be specified at product level) to give warnings of unusual transaction activity.
This is a central function (probably performed within MI systems) not operated at the
Branch
Trigger Reports will be produced within Management Information systems on an ad-hoc or
predefined periodic basis
Automation The Management Information systems will check against parameter levels and produce
reports to show when an expected limit is exceeded.
Frequency On an ad-hoc or predefined periodic basis.
Constraints Data available within MI
Start up Conditions Product level analysis undertaken and limits defined at transaction level.
Completion Conditions I Reports produced.
BT -010 I POL A review of which periodic checks are to be made, with which parameters, on data within
i _ Management Information systems must be made.
3 March 2004 Version 1.0 Page 57 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.1.2 Perform Range Checks - Transaction ... Validate Data Captured (A4.1.1.2)
Attribute
Description
Description
Uses reference data definitions to verify that data entered at the time of the transaction is
within pre-set tolerance. he majority of these tolerances are defined by the client and are
mandatory business rules (ie. it should not be possible to override)
The types of mandatory business rules to be driven by parameters defined within NRDS
include:
Dates for open/closure of products
Definition of core or non core products and associated branches
Minimum and maximum transaction quantity
Minimum and maximum transaction value
Multiple transaction value allowed (total value must be divisible by this amount)
Retail price (unit price)
Override price allowed flag (e.g. Girobank fee)
Transaction must record both volume and value information
If a clerk attempts to enter a value at the point of transaction that is outside the permitted
range defined within reference data, it should not be possible for the transaction to continue
and the system should enforce conformance to the mandatory business rules
Trigger
‘An error message will be displayed when a mandatory business limit is exceededinot
adhered to
‘Automation
The Horizon system will check against parameter levels recorded within NRDS and display
an error message when a defined mandatory business rule is exceeded/not adhered to.
As provided by current functionality within the Horizon system, though the ranges specified
within Reference Data may be tightened.
As current functionality, no change proposed within this process.
Frequency
Ata transaction level as frequently as the defined mandatory business rule parameters are
exceeded/not adhered to
Constraints
None
‘Start up Conditions
Product level analysis undertaken and limits defined at transaction level and applied within
NRDS
Completion Conditions
Correct data entered or transaction abandoned.
BT-011 POL ‘A review of parameters, defined through reference data, for control and management of data entry
at the counter, is to be made. Any changes to reference data must be implemented prior to removal
i of current CBDB range check processes.
3 March 2004 Version 1.0 Page 58 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
3 March 2004 Version 1.0 Page 59 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.1.3. Automated Reconciliation (A4.1.1.3)
Attribute Description
Description This process enlails automated reconciliation of data streams within the Fujitsu domain
Current examples of this are the Banking DRS reconciliation and APS to TPS
reconciliation. It is suggested that the future process remain as current although the
changes to the TMS domain may have implications on the current process.
Trigger Receipts of electronic files as described below.
Automation There are a number of areas for potential reconciliation checks:
¢ Between the Branch and TMS
« Between APS Transactions sent to Clients and Transaction Summaries passed
to POLFS
¢ Between Financial Institutes views of on-line Transactions and the Branch /
TMS's view
Integrity of individual data flows
Proposed reconciliation mechanisms in these areas are discussed below.
Between the Branch and TMS
There is a potential danger in that messages harvested from that Branch and the
summaries might not match. This is currently addressed, by generating a “reconciliation
total” at the branch and checking that all harvested transactions at the Data Centre match
this total
In addition, the POL FS interface will check that all Summaries passed to it add up to zero,
thus ensuring that no summaries are missing.
Itis proposed that such reconailiation checking is sufficient.
Between APS Transactions and Summaries
It is proposed that transactions are harvested once to TMS rather than separately for
OpTIP and AP Clients. This means that the set of Transactions summarised for TMS and
those passed to the AP Clients will be the same (The section above describes the checks
that the transactions match the summaries passed to POL FS).
Note that Transactions are not necessarily passed to the AP clients on the day that they are
received by TMS, however the CTS file will account for any differences in this.
It is proposed that the existing reconciliation between TPS and APS is removed thus
simplifying the TMS processing
Between Fl and TMS view of on-line Transactions
It is proposed that the current 3 way reconciliation carried out by DRS between the Fis
view, the real-time transaction flow from the Branch and the EOD flow (which in turn is
matched to the summaries passed to POL FS) is retained as itis.
Integrity of individual data flows
All File interfaces will ensure that they include appropriate Trailer records which contain
totals of financial data within the file, thus ensuring that any corruption within the file is
detected. Any failures of such control total checks will result in the entire file being rejected.
3 March 2004 Version 1.0 Page 60 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Currently, reconciliation checks are performed between DRS transactions and the
associated cash account entries (NB103). This reconciliation function is to be discontinued
when the Cash Account flow to OpTIP/CBDB is terminated and no replacement is required.
Frequency To match frequency of transfer of data files. Mostly nightly
Constraints None
Start up Conditions Data transferred
Completion Conditions I Reconciliation reports produced
BT - 062 I Fujitsu Services I The NB103 DRS reconciliation reports will be eliminated.
10.1.2 Produce Reports and Information
Produce Daily Summaries
Produce Periodic Summaries
Produce Remuneration Checks
Verify Summaries
Despatch Redeemed Dockets
Produce Other Horizon Reports
Oakes
10.1.2.1 Produce Daily Summaries (A4.1.2.1)
Attribute Description
Description Produce daily summaries for those products which are time critical and for which not all information
is supplied on the electronic transaction stream to a client and/or for which documentation must be
passed on to subsequent processes.
This process must take account of those process changes being developed as part of Other Data
Capture which reduces the need for manual transcription and production of summaries as the data
is available via electronic stream — thus only summaries which lie outside of that capability should
be included in this process.
As is current process and functionality for production of such summaries. Simplification is
dependent on product re-engineering
Trigger User Initiated
Automation The user will initiate production of the relevant summaries
Frequency Daily
Constraints Based on client requirements.
Start up Conditions Transactions completed
Completion Conditions I Summaries completed and despatched
BT-012 POL ‘revised end of day procedure will be defined, identifying which summaries must be produced at
I ‘end of day. The buttons on the “Counter Daily” menu will be reviewed accordingly. The revised list of
items will be defined in reference data for display when the “End of Day” button is pressed on
Horizon.
3 March 2004 Version 1.0 Page 61 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.2.2 Produce Periodic Summaries (A.4.1.2.2)
Attribute Description
Description Produce summaries for those products which are not time critical and for which not all information is
supplied on the electronic. Reports will either be mandatory or non-mandatory. Mandatory reports,
will be produced to conform to client reporting needs, which will be informed to the branch by
business procedures, currently this is weekly and is likely to remain so. Mandatory reports will
require a system controlled cut-off such that items/transactions only ever appear on one instance of
the report, and there will need to be a check that the reports are produced before the branch trading
‘statement can be produced. The following reports are identified as mandatory:
= Counter Weekly Green/Violet Giros
= Counter Weekly Inland Revenue Tax Credits
= Counter Weekly P&A
= Counter Weekly Pos Paid
= Office Weekly Green/Violet Giros
= Office Weekly POs Encashed
= Counter Weekly Miscellaneous Transactions
= Counter Weekly Travel Schemes
‘A new Counter Weekly Redeemed Savings Stamps mandatory report is required with similar
content to the Office Weekly Redeemed Savings Stamps Summary.
There are reports which summarise mandatory reports which must be produced on the same cycle.
All of these reports need to change such that a cut-off is taken and the next report will only look at
the Stock Unit reports (ie Counter Weekly) produced since the last time the summary report was
cut-off. This is a new type of cut-off functionality. It should be noted that an implicit cut-off will occur
when the branch is moved to a new Trading Period. These are
= Office Weekly Inland Revenue Tax Credits
= Office Weekly Inland Revenue Tax Credits P5589
= Office Weekly P&A P2311MA
= Office Weekly Pensions and Allowances.
= Office Weekly Redeemed Savings Stamps Summary
The Office Weekly P2311MA (B) report is a mandatory report with no data on it requiring a cut-off
and so this report can remain unchanged.
Non-mandatory reports are produced to support local investigations/verifications, it is not required
that they be produced as part of the branch trading statement. Some of the reports identified as
non-mandatory already have cut-off functionality, it is not required that this be changed. When
produced these reports should be produced back to the last cut-off, or if longer than the branch data
retention period since the last cut-off, the report is to be produced with all retained data. Those non-
mandatory reports that have no cut-off should be produced, whenever they are produced, with all
data back to the start of the trading period. The following periodic reports are identified as non-
mandatory:
= Counter Weekly Remittances In
= Counter Weekly Remittances Out
= Counter Weekly Remittances Summary
= Counter Weekly Stock on Hand
= Counter Weekly Transfers In
= Counter Weekly Transfers Out
3 March 2004 Version 1.0 Page 62 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
= Office Weekly Remittances In (P)
= Office Weekly Remittances Out (P)
= Office Weekly Sales Report
= Office Weekly Postage Labels
= Office Weekly Transfer Reconciliation
= Office Weekly Unreconciled Transfers
= Foreign Currency Holdings
= Office Weekly Suspense Account
= Counter Weekly Transfer Summary
This process must take account of those process changes being developed as part of Other Data
Capture which reduces the need for manual transcription and production of summaries as the data
is available via electronic stream — thus only summaries which lie outside of that capability should
be included in this process.
The following reports, currently produced on a weekly basis, have been identified as no longer
needed and they are now required to be removed
= Counter Weekly DVLA V10
= Counter Weekly DVLA V11
= Office Weekly Cash Flow
= Office Weekly Counters Revenue Schedule
Trigger User Initiated
Automation The user will initiate production of these relevant summaries
Frequency minimum weekly
Constraints Based on client requirements.
Start up Conditions Transactions completed
Completion Conditions I Summaries completed and despatched
BT-014 POL A revised end of period (probably weekly) procedure will be defined, identifying which summaries
must be produced at end of period.
BT -015 I POL IThe list of summaries will be reviewed and classified as mandatory and optional. Business rules
I for content on optional summaries will be defined. As either:
I « — Summary of transactions of type since last cut off, whether cut-off is in this trading
I period or last.
I «Summary of transactions of type since last cut off, if cut off in this trading period, but
I only summary of transactions of type since start of trading period if last cut-off was in
L previous trading period
3 March 2004 Version 1.0 Page 63 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.2.3 Produce Sales Report to Assist Remuneration Check (A4.1.2.3)
Attribute Description
Description The Sales Report is produced to review sales or to support the postmaster in assessing whether his
pay invoice received from HRSAP is going to be substantially correct - and allows the postmaster
some advance warning of his likely pay for the period. This is an estimating tool and not a re-
creation in Horizon of the HRSAP calculation
Trigger User driven process
Automation Selection of appropriate function to produce a report
This is the Sales report with a specified Date Range based on Trading date (which then aligns with
periods used for HRSAP summarisation). NB will not align with Branch Trading Statement periods,
unless requested by the user.
Should the user enter a date range outside of the Horizon range of retained data (as defined within
data retention periods), or including the current day, then a warning message should be given,
advising the user that the report cannot be produced for the range entered
Frequency Monthly
Constraints Only applies to periods for which Branch holds Trading data
Start up Conditions User wants to produce report.
Completion Conditions I Report produced
“BT-016 Fujitsu Services Functionality to allow entry of date range on the of Sales Report to be produced will be implemented
within Horizon, the system will verify that a valid date range has been entered, If invalid it will allow re~
entry, if valid it will produce the existing sales report but with data covering the specified date range.
10.1.2.4 Verify Summaries (A4.1.2.4)
Attribute Description
Description This process provides the branch manager with the ability to check off his summaries against other
information (e.g. individual dockets) to ensure completeness.
Provides an opportunity to verify the summaries that have been produced correctly reconcile with
the information on the manual supporting documents
Trigger Production of the summaries
Automation Verification of the summaries is a manual process, though there must be the ability to amend and
re-run the process if errors are found. After verification copies of some summaries, defined by
business procedures, may need to be retained at the branch.
As is current process and functionality for such verification
Frequency Daily/ Periodic following production of summary.
Constraints Based on client requirements
Start up Conditions Summaries produced which require verification
Completion Conditions I Summaries Verified
3 March 2004 Version 1.0 Page 64 of 133,
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.2.5 Despatch Redeemed Dockets (A4.1.2.5)
Attribute Description
Description This process ensures that any docket which is sent from the branch is done in a way which provides
sufficient information to control and audit the movement of the dockets.
This may happen on a periodic basis but should all be cleared out as part of the monthly trading
process as defined and managed by business procedures.
The benefit of this process is to keep an audit trail on all items despatched from the branch
Itis assumed that this process is performed separately for each Stock Unit.
Trigger During a trading month this is a user driven process whenever despatches are required. However,
at the end of the trading period the system should remind the user that despatches are required
Automation This process is automated using the existing functionality for cut-offs for dockets to be sent from the
branch.
No change is required to this functionality.
Frequency As required — likely to be some on a weekly basis but definitely monthly
Constraints None
Start up Conditions Dockets to remit.
Completion Conditions I All dockets remitted
10.1.2.6 Produce Other Horizon Reports (A4.1.2.6)
Attribute Description
Description This allows the user to produce a number of reports based on Horizon information.
Trigger User initiated process.
Current process same as is. Report may be defined differently as documented within Information
flows.
Automation The user will select the appropriate function and produce a report against which he/she can check
his/her transactions.
As current process and functionality for producing reports.
Frequency According to user requirements and business procedures
Constraints Information is available with Horizon system
Start up Conditions User chooses to produce report
Completion Conditions I Report is produced,
3 March 2004 Version 1.0 Page 65 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.3 Other Data Capture
1. Input Non Accounting Data
2. Input Bulk Data
3. Input Additional Client Data
10.1.3.1 Input Non Accounting Data (A4.1.3.1)
Attribute Description
Description Input data, into the electronic transaction data stream, not collected at the point of sale
related to non-financial transaction and/or supplement information about transaction
activity, which do not affect accounts but do affect remuneration.
Examples of these transactions are Royal Mail, Parcel Force, and Girobank.
Uses for this data include:
= Management information
= Settlement information
= ___Remuneration
Trigger User initiated, business process rules to be defined and communicated to branches
Automation When the user enters the relevant summary information into Horizon, the system will
validate against verification rules defined within NRDS for mandatory business rules where
applicable
Asis current process and functionality for such data entry.
Frequency Weekly, specific day to be defined (unless the current list of items can be reduced
significantly and then the frequency could be daily)
Constraints in order fo simplify current processes and reduce requirements for capture of dala using
this method:
= There is a dependency on sales and marketing to drive forward product re-
engineering and contract re-negotiations on client contracts
= There is a dependency on Agent Remuneration to re-negotiate current
remuneration formulas and rates
Start up Conditions Non accounting data items to be defined and business process to be defined and
communicated
Completion Conditions I Data entered.
BT-019 I POL
Business procedures for entering non-accounting data, identifying what data and when, will be
produced.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 66 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.3.2 Input Bulk Data (A4.1.3.2)
Attribute Description
Description Input bulk transaction data, into the electronic transaction data stream, that is captured at
the point of sale using third party equipment.
Examples of these types of transactions are ATMs and Lottery.
The data needs to be input into the transaction stream for various reasons:
To be reflected within the branch trading position and feed into the business accounts
Settlement - used for invoicing of management fees and also used to validate against
client settlement figures
Remuneration — paid monthly usually around the middle of the calendar month - agents
paid on either volume of value of transactions undertaken
The current process for using this functionality following system failure will remain
Trigger User initiated, business process rules to be defined and communicated to branches
Automation When the user enters the relevant summary information into Horizon, the system will
validate against verification rules defined within NRDS for range checks and mandatory
business rules where applicable
Areview of the min/max limits defined within NRDS will tighten the allowed range for input.
As is current process and functionality for such data entry.
Frequency Daily where possible, weekly for any remaining items (specific day to be defined)
Constraints Dependency on Sales and Marketing to undertake product re-negotiation with clients (e.g.
A&L Girobank regarding frequency of data capture)
Start up Conditions Bulk Input data items to be defined and business process to be defined and communicated
Completion Conditions I Data entered.
BT-021 POL Business procedures for entering bulk data, identifying what data and when, will be produced.
3 March 2004 Version 1.0 Page 67 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.3.3 Input Additional Client Data (A4.1.3.3)
Attribute
Description
Description
Enhance the transaction data stream with data required within the transaction data for
particular clients/produets.
Additional client data in this context refers to the current process whereby
additional data fields relating to transactions, that are not captured within
Horizon, are captured using the manual summaries within the branch.
Process drivers for capture of additional data items are:
= Contractual requirements with clients
"Validation of settlement figures (specific evidence)
= Responding to customer and client enquiries
= Investigating exceptions/discrepancies
Product re-engineering has been defined as out of scope, but ADC and PAF functionality
could be utilised by applying NRDS functionality.
It is therefore suggested that for transactions where evidence is provided, details are then
recorded and the evidence is returned to the customer — these details could be captured
using Horizon ADC and PAF functionality at the point of transaction capture driven by
NRDS. This would result in no additional work for the branch as they will effectively replace
the manual recording of information on paper summaries for these products and enter the
details directly into Horizon.
This process would result in the following benefits:
= Removal of some of the current manual processes within the branch
= Allow validation rules to be applied to the additional data capture fields
= Allow data to be sent electronically direct to the client
= Remove the need for some additional work and legacy systems within the
centre
Where we are keeping supporting documents, currently various activities may be
undertaken within the centre for these. For example they may be keyed into a legacy
system and then matched against client transaction data. As matching will not take place in
the future, the supporting documents could be despatched direct to the client. The client
would then be responsible for customer enquiries and would also need to provide evidence
when raising queries. There would be a dependency on Sales and marketing to agree the
relevant changes with the affected Clients to enable us to do this.
Trigger
Transaction will be user initiated, trigger for additional data capture items will be driven by
parameters defined within NRDS.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 68 of 133
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Automation Relevant data items for additional data capture will be prompted by the system and
verification rules applied as defined within NRDS (mandatory business rules)
Changes to be designed and implemented by the Product Re-engineering Programme. No
changes are required within this project.
Current process and functionality for such data entry are to be retained as a result of this
project.
Frequency At a transaction level as frequently as the need arises for the capture of additional data
items
Constraints Dependency on Sales and Marketing to drive through product re-engineering and
undertake contractual negotiations with clients
Start up Conditions = Relevant NRDS parameters will need to be defined and implemented.
= May be requirements for the additional production of Horizon summaries —
need to undertake product level analysis
= Design and implement additional electronic interfaces where required
Completion Conditions I Transaction completed data entered
BT-022 POL The existing products will be reviewed for opportunities to capture additional data at the point of
‘sale, removing needs to manually record transaction data. The review will analyse, and if necessary,
renegotiate client reporting requirements.
BT 023 I POL [ New and replacement products will be implemented using existing system capabilities
10.1.4 Discrepancy Management
1. Receive Automated Message
2. Handle Transaction Corrections
10.1.4.1 Receive Automated Message (A4.1.5.1)
Attribute Description
Description This process is the receipt of the Identified Transaction Error (Transaction Correction) into the
branch for action by the branch. This has resulted from investigations centrally and a correction
being generated from POL-FS.
Trigger Automated advice arriving within the branch
‘Automation ‘Advice of a Transaction Correction will be electronically generated by POL-FS and appear in the
branch. On receipt the Horizon system will display a reminder to specified users (defined by role)
that there are Outstanding Transaction Corrections at each subsequent logon until there are no
more Outstanding Transaction Corrections. A single prompt is provided indicating that there are
Outstanding Transaction Corrections. The number of Outstanding Transaction Corrections will also
appear on the Variance Report whenever it is produced. An event should be recorded of who was
shown the message.
3 March 2004 Version 1.0 Page 69 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Frequency ‘Ad Hoc
Constraints Prompt (wording implemented through Type C Ref Data) to Manager and Supervisor roles only (but
all users with those roles)
Start up Conditions Next Logon following receipt of TC (and all subsequent logons until there are no more Outstanding
Transaction Corrections)
Completion Conditions
When all Outstanding Transaction Corrections processed.
BT-024 Fujitsu Services
(user with the appropriate role will be informed, at log on, that there are outstanding Transaction
‘Corrections awaiting processing, whenever there are any.
10.1.4.2 Handle Transaction Corrections (A4.1.5.2)
Attribute Description
Description This is the mechanism for Processing the Transaction Correction by the branch
Trigger User Initiated
Automation There will be a button for Transaction Correction Management within the menu hierarchy which is
only accessible by users with the appropriate role. This will provide the user with a list of the
unprocessed Transaction Corrections, displayed in date/time order.
Having selected the Transaction Correction to process, the system will display text making clear
what will happen when they select any of the options presented
For each Transaction Correction the user will have up to three options - Each option, when
selected, will perform an identified set of transactions, defined within the Transaction Correction.
(which may include an option to Do Nothing - requesting further investigation).
Should the Transaction Corrections fail validation, then an error is displayed to the user with a
request to contact the NBSC. The Transaction Correction will be marked as complete, but no
change will have been made to the local system.
Frequency Potentially daily — in reality probably could occur weekly but most likely on a monthly basis
Constraints No more than one person must be able to work on a Transaction Correction at the same time.
Start up Conditions Message must have been received from POL-FS.
Completion Conditions I Branch can't balance until all Transaction Corrections have been processed.
BT-025 I Fujitsu Services
I
I
I
"There will be a button for Transaction Correction Management within the menu hierarchy which is
‘only accessible by users with the appropriate role. This will provide the user with a list of the
unprocessed Transaction Corrections, displayed in date/time order. Having selected the
Transaction Correction to process, the system will display text making clear what will happen when
they select any of the options presented, the user should be able to print the details of the
transaction correction at this point in order to consider its implications before invoking it.
For each Transaction Correction the user will have up to three options - Each option, when
selected, will perform an identified set of transactions, defined within the Transaction Correction.
_(this may include an option to Do Nothing (requesting further investigation).
10.1.5 Compare Generated with Actual Cash Position
= Compare Generated with Actual Cash Held for Stock Unit
3 March 2004
© Post Office™ 2004
Version 1.0 Page 70 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
= Create Variance Report ... Compare Generated with Actual Cash Held Across Branch
Make Good, Hold or Declare Any Cash Variance
10.1.5.1 Compare Generated with Actual Cash Held for Stock Unit (A4.1.6.1)
Attribute Description
Description This process allows for each stock unit to make a comparison of their actual cash with the system
held position on a daily basis. It is a tool to allow the manager to maintain control over whether any
potential variances are emerging and allow them to action this if they wish to. In essence it serves
as an indicator to allow corrective action on the basis that correcting the cash position is the first
place the branch will investigate if variances are emerging.
Each Stock Unit will be expected to make a daily declaration of cash held to compare the system
generated value of cash held by the stock unit with the actual value of cash held within the stock
unit and declare any variance.
Local tool
Trigger This is a user driven process in the first instance but at first log on the following day the system will
prompt for yesterday's figures. This can be declined
Automation Get rid of Current ONCH functionality. The current ONCH button should access the common declare
cash functionality. Have current weekly cash balance functionality on a daily basis (the declared
figure will go to SAPADS). The function identifies variances between the declared cash figure and
the system generated cash figure for the Stock Unit.
For shared stock units the system should give the option to roll-up the stock unit part declarations,
after a part declaration is completed, where only the declared Ids used on that day are carried
forward into the summation — not any declarations for any previous day.
Frequency Daily — at the end of the day
Constraints None
Start up Conditions Each stock unit to make an actual cash declaration
Completion Conditions I Declaration of physical cash held made for the Stock Unit
BT-026 Fujitsu Services ‘At the end of performing a cash declaration, in a shared stock unit, the system will enter, if the user
‘chooses to, the cash discrepancies function to support the identification of any variance
BT-028 I Fujitsu Services Reminders for ONCH function to be performed at log on if not performed previous day will be
I removed and, instead, the system will remind users to perform cash declaration function if it has
i not been performed on the previous day, but this may be declined.
BT-029 Fujitsu Services” When the cash declaration has been made the figures for denominational split will be passed to
I ‘SAP-ADS as if an ONCH declaration had been performed.
I
3 March 2004 Version 1.0 Page 71 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.5.2 Create Variance Report ... Compare Generated with Actual Cash Held Across Branch (A4.1.6.2)
Attribute Description
Description This report allows the manager to review variances within his branch as a result of cash
comparisons which have taken place at stock unit level. This will highlight for him where variances
exist and is a tool to assist him in deciding what action to take.
Trigger User driven process
Automation System will produce a report which displays the data as defined in the flow definition in Section
9.4.27.
Frequency User initiated, anticipated daily
Constraints At least one stock unit declaration for cash must have been made to get variances identified from it.
Though, user may wish to produce it to simply see cash derived position.
Start up Conditions User requests Variance Report.
Completion Conditions I Variance Report produced.
BT-030 Fujitsu Services ‘Anew function will be made available to provide the variance report to the defined content and format
10.1.5.3 Make Good or Hold Any Cash Variance (A4.1.6.3)
Attribute Description
Description This process allows for action to be taken on the cash variances highlighted at stock unit level
For any cash variance, decide on the information available either
= to make good the variance by adjusting the physical cash in the stock unit. Taking this
action is to be informed to the Horizon system which should record that this action has
been taken.
= to hold the variance for some specified time to try to reconcile
Trigger This is a user driven process following on from Compare Generated With Actual Cash Held for
Stock Unit
Automation The branch manager/postmaster will be able to review the identified Cash Variances across the
branch using the Variance Report described above and take any of the following actions at stock
unit level:
= Hold Variance - which allows local investigation and resolution within the current
trading period
= Make Good - for more information see process definition for “Make Good any
Outstanding Losses” process below.
Frequency Potentially daily
Constraints Business Accounting Procedures
Start up Conditions Identified Variance within a Stock Unit
Completion Conditions I Variance “dealt” with.
10.1.6 Produce Branch Accounts
= Stock Checking
3 March 2004 Version 1.0 Page 72 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Produce Trial Balance
Investigate Balance Discrepancies
Make Good or Declare any Outstanding Losses
Produce Final Balance
Produce and Confirm Trading Statement
Roll Over Inactive Stock Units
Stock Revaluation (Stamps)
10.1.6.4
10.1.6.1 Stock Checking
— Remit In/Out Stock
«Local Stock Check Stock Held for Stock Unit
«Review Stock Held Across Branch
It should be noted that, there are consequences of the principles that “Stock will be held by volume/quantities only until sold or
lost. Unit of measure for all transactions on Horizon will be the retail sales unit of measure.” and that “All products will be remitted
in and out and no product/stock will be excluded.”, which have some far reaching implications. These are’
— The principles don't fit with the detailed requirements for the handling of stamps. It has been agreed that “Other Stamps’ will
need to be managed by Value rather than by Volume.
«There is a consequential requirement to convert all current non-value stock to Value Stock, in order to bring them under
system reported control. Stocks of Motor Vehicle Licenses (MVLs) will be controlled in a way that movements (including
remittances in, sales, stock adjustments and remittances out) of all MVLs of different types (months) will be reported to
POL-FS as a summation of movements for all the different types (months). This means that the stock control system within
POL-FS will have only a combined total of all MVLs within the branch. Requirements for any further information for other
purposes (@.g. requirements planning) will be reviewed and implemented under another stock control programme if
necessary, not as part of the IMPACT programme.
It is further noted that, since the development of the stock control systems is progressing outside of SAP-ADS then the existing
Weekly Stock Holding feed to SAP-ADS is extremely unlikely to be required for stock management and control purposes and this
should be removed as part of this programme. Whilst recognising that making changes to handle Bureau de Change products
through cash centres is out of scope of this programme (as documented in Section 7), it would be disadvantageous to remove
this flow should it subsequently be required by that project. Consideration to this other requirement should be made before
completely removing this flow.
~BT-055 POL ‘There is a requirement to control all items of stock. This will be achieved through reference data by
{defining as controlled products those products which are currently non-value products
BT-056 I Fujitsu Services All stock items will be monitored throughout the Horizon system by volume and not by value.
I
BT-058 I Fujitsu Services I The existing Weekly Stock Holding feed to SAP-ADS will be removed
I
I POL
I
~BT-063 "Fujitsu Services” ‘The consolidated stock unit non-value stock report is no longer required and can be removed. The
‘check to ensure that the consolidated stock unit non-value stock report is produced as part of end of
period processing will also be removed.
~BT- 064 POL Functionality to declare stock holdings of non-value products will be removed from the horizon
i ‘system.
ie “Anew Transaction Corrections report willbe produced, the content and format.
vices
of which will be as specified in Section 20.3 in Appendix B of this document
3 March 2004 Version 1.0 Page 73 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.6.1.1 Remit In/Out Stock (A4.1.7.1.1)
Attribute Description
Description This is the function to receive or despatch stock from the branch and is not automated in the way
that cash remitting is automated.
Trigger This is a user driven process triggered by the branch manager/postmaster whenever stock is
required to be remitted in or out
Automation The user will be presented with a screen into which he keys, by product, the quantities he wants to
remit out or the quantities he has received in the remittance to his branch The movement to be
recorded for POL-FS.
No change to current functionality other than to extend the set of products to which the process is to
apply (i.e. current non-value stock)
Foreign Currency may be altered to be automatically Remitted In & Out as for cash — any changes
to this and Travellers Cheques to be implemented as part of a separate project.
Frequency Available at any time but likely to happen once a week
Constraints None
Start up Conditions Stock Remittance delivered to branch or there are Stock items to be returned to stock centre.
Completion Conditions I NB This impacts the volume of Stock on hand immediately (unlike cash).
410.1.6.1.2 _Local Stock Check Stock Held for Stock Unit (A4.1.7.1.2)
Attribute Description
Description This process allows for each stock unit to make a comparison of their actual stock with the system
held position on a periodic basis. It is also the mechanism by which the branch declares its stock
position at trading statement time
Each Stock Unit will be expected to compare the system generated volume of stock held by the
‘stock unit with the actual volume of stock held within the stock unit and declare any difference.
Adjustments made to stock holdings through declarations and/or stock adjusting will be reported
separately from stock adjustments due to stock item sales.
Trigger This is a user driven process and must be completed in full before the branch trading statement can
be produced.
Automation For all stock items except Stamps the user will produce a report (existing stock report adjusted to
show just volume information) and physically check his stock against the report. If there are any
differences then the user will create an adjustment transaction for the amount of the difference - by
volume. In shared stock units an alternative approach is for all parts of the stock unit to perform a
blind declaration of stock, part declarations are summed up and the overall declaration investigated
by reviewing discrepancies or producing a trial balance. Stock adjustments will result in
corresponding changes to the system generated cash level. Declarations resulting in Discrepancies
will result in an automated Cash Discrepancy being recorded rather than adjusting the system
generated cash level.
For “Other Stamps” (special stamps and 1st & 2nd class are currently handled as Stock) the user
will be presented with a screen against which he can key in the quantities of stock items for each
3 March 2004 Version 1.0 Page 74 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
‘denomination of stamp that he has. On completion the system will compare this with the system
calculated sales value for Stamps, any differences will then automatically, on request of a trial
balance, create an adjustment transaction to reflect the difference as a cash discrepancy.
Methods of Payment will continue to be adjusted by value.
The following products should operate as for Other Postage (i.e. by value adjustment), as is
currently the case, unless any specific product can be subdivided into individual items which can be
volume controlled.
= Philatelic Items Other
= Presentation Pack
= Prestige Stamp Books
= Mini Sheets
= Other Stamps Ordinary
= Other Postage Stationery
= Other Stamp Special
= Stamp Book Other
= Disct Whsle Stamp Books
= Migration Only Item-HCS.
For Foreign Currency and Travellers Cheques a declaration will be entered into a screen by
currency for the amount held, in the foreign currency. (i.e. as at present)
All of the above is current process and functionality for stock checking on the Horizon system.
Different prices may be defined for a stock item when adjusted (lost) compared to when sold
(through a transaction). Adjustments will be reported separately to POL-FS from movements of
stock due to sales.
Frequency Potentially weekly for some items and must be performed monthly for all items as part of Trading
Statement process.
Constraints Business procedures will define what should be done with Stock Remittances delivered but not
Remitted in.
Start up Conditions User initiated when required. E.g. Any stock variances to be identified and recorded must be
performed as part of Trading Statement processing.
Completion Conditions I Stock report produced OR Stock declaration made.
BT-036 Fujitsu Services Adjustments in stock (whether identified via adjustments or stock declarations) should be adjusted at:
the adjustment price whenever defined in reference data.
10.1.6.1.3 _ Review Stock Held Across Branch (A4.1.7.1.3)
Attribute Description
Description This process allows a branch to review the system held stock holding across the branch
Trigger This is a user driven process following on from Local Declare Stock Held in Stock Unit
Automation This process is provided by the existing Office Snapshot report
This report is for Managers / Supervisors only. Report will need to be amended to not reflect stock
values.
3 March 2004 Version 1.0 Page 75 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Frequency Potentially weekly and definitely monthly— usually after stock unit comparisons made.
Constraints None
‘Start up Conditions User initiated.
Completion Conditions I Office Snapshot Report produced
BT-037 — Fujitsu Services ‘Report will be redefined without stock values as defined in Section 20.7 in Appendix B of this
I document
10.1.6.2 Produce Trial Balance (A4.1.7.2)
Attribute Description
Description This allows the user to produce a balance at stock unit level. This is a trial balance to assess
whether he/she is on track for balancing. This balance is a trading balance which will not include
‘stock values but will include stock volumes held figures.
If this is to actually “balance’, will therefore need to show Stock Sales as “receipts” (currently they
are not shown since they have no impact on the “cash and stock on hand’ figure).
Trigger User initiated process.
Current process same as is. Report is different in the way in which Stock is shown by volumes,
without values
Automation The user will select the appropriate function and produce a report against which he/she can check
his/her transactions.
All this is current process and functionality for balancing on the Horizon system, except for the
summation of declarations in shared stock units where the requirement is that if a Stock Unit is not
used then previous figures are carried forward. If a Stock Unit is used then only the declared Ids
used on that day are carried forward into the summation — not any declarations for any previous
day, This requirement is for both cash and stock to work the same way.
Frequency Potentially daily, more likely weekly but definitely monthly
Constraints Existing constraints: All relevant declarations (cash, stamps, bureau cash, bureau travellers
cheques) made, all mandatory reports produced, if last SU to balance then Parcel Traffic Report
produced.
New constraints: all dockets and vouchers have been remitted out (i.e. no stock of dockets or
vouchers); for last Stock Unit, no outstanding Transaction Corrections and no items held in “local
suspense”
Start up Conditions User initiated, must be performed as part of Trading Statement processing
Completion Conditions I Trial Balance Report produced
10.1.6.3 Investigate Balance Discrepancies (A4.1.7.3)
Attribute Description
Description This is the mechanism by which a user may track back through transactions to highlight where any
discrepancies might exist.
3 March 2004 Version 1.0 Page 76 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Trigger After production of a trial balance or after production of cash variance report.
Automation This mechanism will allow the user to investigate summary totals held on the balance report and
allow for producing existing reports as required to get to the individual data items
This is purely a manual process. The system provides support in allowing various reports to be
produced and Transactions to be queried, but it provides no guidance / control of the process.
Frequency Potentially daily, probably weekly and definitely monthly
Constraints None
Start up Conditions User initiated.
Completion Conditions I Discrepancies Investigated
10.1.6.4 I Make Good any Outstanding Losses (A4.1.7.4)
Attribute Description
Description This process allows for action to be taken on the cash or stock variances highlighted at stock unit
level. Any variance identified for any reason other than the limited number of known error reasons
(see below) must be made good before the stock unit can balance, though when the stock unit is
not the last to balance discrepancies can be transferred to another stock unit as part of balancing.
Taking this action to correct the stock of Physical Cash for the stock unit is to be informed to the
Horizon system which should record that this action has been taken.
ABranch Trading Statement can not be finalised for a trading period (although it will be possible to
roll over a balance period) until all variances are made good. (Note that this is different from the
current process where making good must take place in the next period.)
Trigger This is a user driven process
Automation Itis proposed that two new “buttons’ are introduced onto the Horizon system:
Make good a loss
« — Remove excess cash
Detailed design will decide where these buttons will be added to the system. These buttons will be
available for any clerk to record the “making good” event. Such “make good” events will be recorded
in the audit trail. The last cash declaration for the Stock Unit would also be updated to record that
the value of cash declared has now been corrected by the amount made good.
Directly Managed Branches don’t make good, instead they move cash variances to Profit & Loss,
after they have performed sufficient investigations, to be defined within local business procedures.
These transactions will be considered to be "Housekeeping" transactions and their use is to be
restricted to DMB Managers/Supervisors.
Multiples - Move to a new (debt recovery) suspense product where the funds will be recovered
through POL-FS
Transactions moving cash into suspense will generate a unique transaction id reference, as is
current functionality.
Of current 10 Suspense buttons, between 3 and 7 will be retained, mapped into individual POL FS
account codes. Buttons for Migration Products and Loans to Post Offices will not be needed. The
3 March 2004 Version 1.0 Page 77 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Attribute Description
removal of vouchers will have the following Front-end implications:
1) New buttons for:
a) Postage costs
b) Minor expenses (both restricted to Branch Manager with a £100 transaction
limit)
¢) Spoilt Postage Labels
2) Working assumption is that the following suspense products will be retained:
Need to confirm requirements for:
a) Client Issued Error Notices;
b) Pre Purchase Products;
c) Unpaid Cheques;
d) POL cheques.
e) MVL Car Hire companies (not thought to require additional front end
functionality due to low values involved); and
) Robberies & Burglaries.
The function to make entries into these remaining suspense products should be altered so that it is
only available to Managers or Supervisors in all branches.
Frequency Potentially daily — in reality probably could occur weekly but most likely on a monthly basis
Constraints This activity has to take place in each Stock Unit.
Start up Conditions Reference Data for suspense products will be provided by Post Office
Completion Conditions I No variances (i.e. discrepancies) in the SU when it is balanced.
BT-031 I POL A review of vouchers remitted from the branch will identify which dockets will need to be treated via
I which adjustment products.
BT-032 Fujitsu Services ‘Anew function for recording a “make good” action will be made available this will allow the user to
‘enter the amount made good. It will record the amount made good, making a new declaration for
‘cash by altering the previous declaration by the amount made good. Amounts made good will be
Teported on variance reports, balance reports and trading statements.
BT 0347 POL ‘A process for appiying for hardship will be defined to allow a branch manager to make allemative
I arrangements for when a variance cannot be made good immediately. Variances will be held whilst
I the application is processed, this may extend the Trading Period. Approved hardship amounts will
i appear as Transaction Corrections
BT-035 POL Reference Data will be edited to limit the suspense accounts available within branches to the limited
known errors” set.
10.1.6.5 Produce Final Balance (A4.1.7.5)
Attribute Description
Description This allows the user to produce a balance at stock unit level. This is a final balance to confirm the
information which feeds into the trading statement. This balance is a trading balance which will not
include stock values but will include stock volumes held figures.
Trigger The process should follow on directly from the Trial Balance process.
Current process same as is. Report is different from now (but similar content and format as trial
balance report, with different headers and footers.)
Automation The user will select the appropriate function, the system will rollover the stock unit into the next
3 March 2004 Version 1.0 Page 78 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Balance period or trading statement period (chosen by the user) and produce a report which he/she
can check, sign and store.
‘As part of the Stock Unit Trial Balance process, any variances between Declared figures and
Systems Generated figures will be recorded as Discrepancies (as at present). However a new
check is to be introduced after producing the Trial Balance (ie. when the “rollover” button is pressed
prior to producing the Final Balance). This check will act as follows:
1. Ifit isn’t the last Stock Unit to rollover, the clerk will be advised that the Discrepancy is to
be posted to a “local adjustments” account. They have the option of accepting or rejecting
this action.
a. Should they accept it, then a pair of transactions will be generated resulting in
the Discrepancy being reduced to zero and a corresponding amount being put
into a “local adjustments product’
b. Should they reject it, then the rollover is aborted and the clerk is free to do
whatever they wish to balance the Stock Unit and will then need to balance the
Stock Unit again at a later time.
c. The “local adjustment” is not associated with any Stock Unit (as with a
Suspense account). Items can be added to it by any clerk, but only as part of
the Balancing Process. Managers / Supervisors will be able to move items from
it into cash in their SU to be Made Good.
2. If this is the last Stock Unit to Rollover an additional check will be performed to ensure
that the net total of transactions, within the Trading Period, in the “local adjustment”
account has a net value of zero.
3. If this is the last Stock Unit to Rollover, then the user will be informed if the Stock Unit has
a Discrepancy and that this must be resolved before the last Stock Unit can be rolled
over.
Local Adjustment will behave in a similar way to existing Suspense Account items, namely the
values will not be associated with any Stock Unit, but is considered as part of the overall Branch
balance.
There is an existing report that shows the state of all suspense accounts and all Transactions
associated with the suspense accounts during the Trading Period, indicating which Stock Unit
carried out the Transaction. It is proposed that Local Adjustment transactions are included in this
report as with any other Suspense transactions - the only difference being that a Branch Rollover
will not be permitted if the carried forward figure for the Local Adjustment Account is non-zero.
Since this is a Local Adjustments item, it is assumed that there is no need for any movements into
and out of it to be visible centrally (i.e. to POL FS) and any values held in it should be considered as
part of the Branch's Cash Holding,
Note it is understood that Horizon should be changed such that only Supervisors and Managers
(etc) will be allowed to carry out Suspense Transactions. The only exception to this will be the
automatic posting of Discrepancies to Local Adjustment.
Frequency Potentially daily, more likely weekly but definitely monthly.
3 March 2004 Version 1.0 Page 79 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Constraints Existing constraints: All relevant declarations (cash, stamps, bureau cash, bureau travellers
cheques) made, all mandatory reports produced, if last SU to balance then Parcel Traffic Report
produced.
New constraints: all dockets have been sent (ie. no stock of dockets); for last Stock Unit, no
outstanding Transaction Corrections and no items held in “local suspense”
Start up Conditions Dependant on whether this is the last Stock Unit to balance or not and whether there are any
discrepancies. See Automation for details.
Completion Conditions I To produce the report and sign it for retention in the branch for two years.
BT-038 Fujitsu Services Anew check is to be introduced after producing the Trial Balance (i.e. when the “rollover” button is pressed
prior to producing the Final Balance). This check will act as follows:
1. Ifitisn’t the last Stock Unit to rollover, and there is a Cash Discrepancy, the clerk will be advised
that the Discrepancy is to be posted to a “local adjustments” account. They have the option of
accepting or rejecting this action.
a. Should they accept it, then a pair of transactions will be generated resulting in the
Discrepancy being reduced to zero and a corresponding amount being put into a “local
adjustments product”.
b. Should they reject it, then the rollover is aborted and the clerk is free to do whatever
they wish to balance the Stock Unit and will then need to balance the Stock Unit again
ata later time.
c. The “local adjustment’ is not associated with any Stock Unit (as with a Suspense
account). Items can be added to it by any clerk, but only as part of the Balancing
Process. Managers / Supervisors will be able to move items from it into cash in their SU
to be Made Good.
2. Ifthis is the last Stock Unit to Rollover an additional check will be performed to ensure that the net
total of transactions, within the Trading Period, in the “local adjustment” account has a net value of
Zero.
3. _ If this is the last Stock Unit to Rollover, then the user will be informed if the Stock Unit has a
Discrepancy and that this must be resolved before the last Stock Unit can be rolled over.
Local Adjustment will behave in a similar way to existing Suspense Account items, namely the values will not
be associated with any Stock Unit, but is considered as part of the overall Branch balance.
“BT-039 Fujitsu Services There is an existing report that shows the state of all suspense accounts and all Transactions associated
with the suspense accounts during the Trading Period, indicating which Stock Unit carried out the
Transaction. It is proposed that Local Adjustment transactions are included in this report as with any other
__ Suspense transactions
PBT-040 I Fujitsu Services I Horizon should be changed such that only Supervisors and Managers (etc) will be allowed to carry out
I Suspense Transactions. The only exception to this will be the automatic posting of Discrepancies to Local
Adjustment.
3 March 2004 Version 1.0 Page 80 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.1.6.6 Produce and Confirm Trading Statement (A4.1.7.6)
Attribute Description
Description This is the branch's mechanism for reviewing and confirming the trading position for the current
period.
The office will produce paper copy of the Trading Statement for local retention.
Trigger User driven process which can only be completed after other linked activities have been completed.
E.g. checking that all Stock Units have rolled over and produced a Final Balance.
Automation The user will select the appropriate function which will display the summary trading position (as per
outlined report) and this may be printed. When the user is content to confirm the position he will be
presented with a textual message which describes the liability and responsibility which the
postmaster is accepting. If the postmaster accepts this the system will record this action, committing
an event which says postmaster has done trading statement and accepting liability for the trading
position
{DN this relies on the work being done outside of IMPACT to align proper control of user name and
password}
The confirmation event will be made available to the data warehouse to enable monitoring of who
has and who hasn't done a trading statement. The ‘confirmation transaction” will not contain the
constituent parts that make up the trading position.
Frequency Monthly, on a Wednesday, (on a 4-4-5 week basis) controlled by a calendar (as with Cash
Account).Separate calendars will be provided and each branch will “know” which one to use.
Constraints Can only be run after completion of other linked processes:
If anything in Suspense Account, must print off Suspense Report (reports what's in Suspense
Account and all movements within period). This is still required. Currently asked if want to produce
Consolidated SU non-value stock report — this is no longer required
Must be done by a Manager or Supervisor.
Start up Conditions Can only be run after completion of other linked processes. All stock units must have completed a
final balance for current period.
Completion Conditions I Signed copy of report to be retained locally.
BT- 041 Fujitsu Services ‘The user will select the appropriate function which will display the Trial Trading Statement (as per
i ‘outlined report) and this may be printed. When the user is content to confirm the position he will be
presented with a textual message which describes the liability and responsibility which the
postmaster is accepting. If the postmaster accepts this the system will record this action, print the
Final Trading Statement and commit an event which identifies that the agent has produced the
‘Trading Statement and accepted liability for the trading position.
BT - 043 Fujitsu Services The confirmation event will be made available to the data warehouse to enable monitoring of who
has and who hasn't done a trading statement. The “confirmation transaction’ will not contain the
‘constituent parts that make up the trading position.
POL
“BT-044" I Fujitsu Services A facility for different branches to operate on a different (four weekly) branch trading calendar, will be
3 March 2004 Version 1.0 Page 81 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
I implemented, which branch is operating to which calendar is to be defined by reference data.
BT -045 Fujitsu Services "The current functionality for extending accounting periods should be removed. The Horizon system
should continue to remind users to roll-over the accounting period if they logon to a SU in the wrong
Trading Period according to the calendar.
BT-063 Fujitsu Services The consolidated stock unit non-value stock report is no longer required and can be removed. The
i check to ensure that the consolidated stock unit non-value stock report is produced as part of end of
period processing will also be removed.
10.1.6.7 Rollover Inactive Stock Units (A4.1.7.7)
Attribute Description
Description This is the mechanism for rollover all previous figures for stock units which have been inactive within
the current period,
Trigger User driven process
Automation The user will select the appropriate function which will then identify all Stock Units for which there
have been no transactions within the period and roll-over those stock units with all figures retained
as at the end of the last period.
As is current process and functionality.
Frequency On a user chosen period but likely to align with the Monthly Trading Statement periods.
Constraints As now
Start up Conditions There must be inactive Stock Units which need to be rolled over into the next Trading Statement
period.
Completion Conditions I Inactive Stock Units rolled over into the next Trading Statement period
10.1.6.8 Stock Revaluation (A4.1.7.8)
Attribute Description
Description This process informs users of upcoming revaluation of stock items.
No particular actions need be taken by the branch to perform revaluation, since the price is only
applied to the stock item at point of sale or stock adjustment. Transactions before revaluation will
occur at the price before revaluation (re-pricing) and transactions performed after the revaluation
(re-pricing) will occur at the new price. In general, it will be in the branch manager's interest to
ensure stock levels are checked before revaluation (re-pricing).
Trigger User driven process on instruction of revaluation
Automation The user is reminded, for a series of days, at logon of an upcoming revaluation (defined by
Reference Data). The reminder will suggest that the branch manager checks stock and makes any
adjustments prior to the price change
Frequency Dependent on revaluation frequency, estimated annually for stamps.
Constraints None
3 March 2004 Version 1.0 Page 82 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Start up Conditions Based on calendar of revaluation.
Completion Conditions I Revaluation completed
BT-046 Fujitsu Services Revaluation functionality to be redefined such that the user is reminded, for a series of days, at
logon of an upcoming revaluation (defined by Reference Data). The reminder will suggest that the
branch manager checks stock and makes any adjustments prior to the price change
BT-047 POL ‘Any non-vaiue indicated items held as part of the balance figure (e.g. as Other Stamps) must be re-
classified before implementation of this function (otherwise current revaluation functionality will be
required)
10.1.7 Summarise Transaction Data
41 Scan Transaction for Day
2 Accumulate Transactions for Summarisation
3. Summarise Cash Centre Transactions
BT-059 Fujitsu Services There is a requirement to continue ensuring reconciliation between data flows which remain within
the Fujitsu domain and ensuring that control totals are applied to any external interface to allow
detection of file corruption. All these reconciliations should take advantage of the simplified process
described in Section 21, Appendix C, of this document.
10.1.7.1 Scan Transaction for Day (A4.3.1)
Attribute Description
Description Determine the transactions to be included as part of the summarisation processing for the trading
day. All counter transactions and events are to be included, including any new events arising from
Branch Trading requirements,
Trigger Timed event, as part of end of day processing.
Automation Fully automated process
Frequency Daily
Constraints None
Start up Conditions Trading Day completed.
Completion Conditions I All transactions for the Trading Day have been scanned.
10.1.7.2 Accumulate Transactions for Summarisation (A4.3.2)
Attribute Description
Description The purpose of this process is to summarise transactions at the required level of detail for each
external data feed provided by the TMS.
Trigger The triggers will be timed events.
Automation The process is fully automated.
Frequency Daily for POLFS, MIS and CTS
3 March 2004 Version 1.0 Page 83 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Weekly for SAPADS
Monthly for HRSAP
Constraints None
Start up Conditions Process triggered.
Completion Conditions I All transactions for the Trading Day for each summarisation have been processed.
10.1.7.3. Summarise Cash Centre Transactions (A4.3.3)
Attribute Description
Description This process takes a daily feed of transaction details and summaries from SAPADS for passing to
POLFS and the MIS. It is based on the SAPADS to POLFS interface to be implemented at S60, with
additional data relating to Cash Centre transactions with external clients.
At S80, this interface will be routed via the TMS to allow details of cash centre transactions to be
extracted and passed to the MIS.
For further information regarding the data passed by this process see documents POL FS AIS &
Horizon to POL Data Warehouse AIS.
Trigger Timed event — part of EOD processing
Automation All aspects of this process are automated.
Frequency Daily
Constraints None
Start up Conditions Daily SAPADS interface received.
Completion Conditions I SAPADS interface fully processed.
10.1.7.4 Deliver Data to External Systems
Attribute Description
Description The data feeds provided by the TMS have differing timings and destinations. This process ensures
that the data is delivered at the correct time to the required destination.
POLFS Txn Summary — Daily, to be delivered to POL-FS.
MIS - Daily, to be available on the FTMS
HRSAP —Monthly, to be FTPd to HRSAP-
SAPADS - Weekly, to be FTPd to SAP-ADS.CTS — Daily, to be available on the POL Gateway.
Trigger Timed events for each interface.
Automation The process is completely automated.
Frequency As defined above
Constraints As defined within the appropriate AlSs (Refs: 277]
Start up Conditions System generated time based trigger
Completion Conditions I Interface files generated and transmitted
3 March 2004 Version 1.0 Page 84 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.2 Business Data
10.2.1 Business Data Model
The Conceptual Design Product Description requires that a Business Data Model is included in this section. The model will be created in
System Architect and is to show the logical model for the data that will be used in the physical design. The model will be a subset of the
POL Corporate Data Model and be integrated with the POL master model repository. The model will be generated from a function/ activity
to entity matrix captured in System Architect, which is to reference the Process Models developed during the Branch Trading workshops.
The ‘first cut’ data model should be verified with the business representatives to ensure that the business rules and logic embodied within it
are appropriate to the solution.
10.2.2 Reference Data Sources
NRDS to be the only source of Types A and B reference data to Horizon domain. Type A reference data is transmitted via the direct interface
and implemented unchanged. Type B may be transmitted via the direct interface, or by other means, but must be “adjusted” before it can be
implemented.
Type C reference data is managed wholly within the Horizon domain.
10.2.2.1 Post Office™ Provided
No Specific Requirements
10.2.2.2 Supplier Provided
No Specific Requirements
10.2.2.3 Client Provided
N/A
10.2.3 On-line Transaction Data (Authorisation/Messages etc)
None
10.2.4 Transaction Data
The following data should be output;
o Cash Centre Cash Holding Information
o Branch Cash Holding for Cash Planning
o Branch Cash Holding for POL FS
{DN :Further work in this area needs to be completed (define data flows)}
10.3 User Interfaces
Requirements for changes in user interactions are defined within the process flow diagrams within Section 8.
10.4 Reconciliation
Reconciliation is expected to change as defined within Section 10.1.1.3.
10.5 Audit
The audit requirement for TMS will remain unchanged with 7 years of data being archived and the same number of audit
enquiries being available to POL.
10.6 Accounting Requirements
3 March 2004 Version 1.0 Page 85 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
10.6.1 Settlement
NA
10.6.2 Invoicing
NA
10.7 Ml
10.7.1 Post Office™
NIA
10.7.2 Supplier
N/A
10.7.3 Client
NIA
3 March 2004 Version 1.0 Page 86 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
11 Non-Functional Requirements
This section describes the non-functional characteristics that the Impact Programme and its supporting infrastructure must
support. These include volumes, service and support management and failure recover and training.
11.1 Volumetrics
The volumes to be supported are specified in the Application Interface Specifications
11.2 Sizing Assumptions
The following assumptions are to be made when assessing the impact of the Branch Trading facities:-
= — There will be no significant changes to the numbers of Transactions taking place within the branch
= The data retention period will be increased such that all trading data is available within the Branch for a minimum of 42
days. Note that this will have implications on the central data storage requirements.
= Summaries of all Transactions that take place in a branch need to be passed to POL FS on a daily basis.
= Summaries of all Transactions that take place in a branch need to be passed to HR SAP on a monthly basis.
= The size of each file is defined in the respective interface documentation (AIS)
BT -049 I Fujitsu Services The data retention period will be increased such that all trading data is available within the Branch
I for a minimum of 42 days.
BT-050 I Fujitsu Services The data retention period will be increased such that all trading data is available at the data centre
I for a minimum of 42 days.
“BT-051 POL Process for recovery situations when the Branch is nearing, or has exceeded, 42 days since it
produced the last Branch Trading Statement will be defined.
11.3 Service Levels
Service Levels to be based on current service levels with Counter and TMS being unchanged.
Help Desk service levels are also to be consistent with those being developed for S60 and will be developed as part of the
Service Architecture being developed by Torstein Godeseth,
Data delivery service levels will be as follows:
« LFS remains unchanged
TMS - POL-FS — to be consistent with that being developed for S60
Transaction Correction — to be like Planned Orders - 95% by 08.00 and 100% by 24.00 - both Day A
TMS — MIS (SAPADS data) ~ by 05.00
TMS - MIS (Horizon data) - by 03.00
TMS — HRSAP 100% by 21.30 on Friday preceding weekend of pay run
TMS (CTS file) - no SLA
11.3.1 Post Office™
No Specific requirements
3 March 2004 Version 1.0 Page 87 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
11.4 Problem Management & Tracking
11.4.1 Incident Management
No specific requirements.
11.4.2. Branch Support
No specific requirements.
11.4.3 Client Support
No specific requirements.
11.4.4 Failure Recovery
No specific requirements.
11.4.5 Backup & Recovery
No specific requirements.
11.5 Business Continuity
No specific requirements.
11.6 Training
BT-052 POL Training will be required at the Branches in support of the new business processes, it is currently
I
assumed that this will be provided by POL
11.7 Change Specific Non-Functional Requirements Required
Change Area Non-Functional Considerations
‘4.1.1.4 Perform Transaction Cheoks —Periodic. Change. I Changes implemented in MIS systems no change at front end
Production of new reports and exception reports Non-Functional and Migration requirements to be considered
under the MI part of the Impact program
A4.1.2.3 Produce Sales Report to Assist Remuneration I Performance - Current production not a problem in terms of
Check. Change: Different sales report over different I performance. No perceived problems with increased times likely.
periods. Accessibility/Security — no change
Usability - no change
Data Retention- to match period of data held by Horizon
Mitigation of failure — no change
Auditability - no special requirements
Legal & Regulatory - none
A4.1.5.1 Receive Automated Message Change: Reminders I Performance — As for other logon reminders
on Receipt/Delivery of Transaction Corrections Acoessibility/Security — no change
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure — no change
Auditability - no change
Legal & Regulatory ~ no change
A4.1.5.2 Handle Transaction Correction. Change: I Performance - no specific requirements over other Horizon
Management of Transaction Corrections, Implementation of I functions
corrective actions, etc. Accessibility/Security — no change
Usability — no change
Data Retention - to match period of data held by Horizon
Mitigation of failure - no change
Auditability - no change
Legal & Regulatory — no change
3 March 2004 Version 1.0 Page 88 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
Change Area
Non-Functional Considerations
A4.1.6.1 Compare Generated with Actual Cash Held for
Stock Unit. Change: Removal of ONCH declarations
functionality, reminders on cash declarations.
Performance - no change
Accessibility/Security - no change
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure - no change
Auditability - no change
Legal & Regulatory - no change
4.1.6.2 Create Variance Report. Change: Implementation
of new report - format to be defined, complexity may affect
usability of report produced - may need to re-format to
simplify.
Performance - no change
Accessibility/Security - no change
Usability — no change
Data Retention - to match period of data held by Horizon
Mitigation of failure — no change
Auditability - no change
Legal & Regulatory - no change
41.7.1 Make Good any Outstanding Variances. Change’
Changes to Suspense Account produets.
Performance - no change
Accessibility/Security - some / all of these postings should be
restricted to the Manager roles (ie. manager/ supervisor/ auditor!
emergency manager). Which particular functions have such
restrictions as defined in process descriptions in Section 10.
Usability — no change
Data Retention - to match period of data held by Horizon
Mitigation of failure - no change
Auditability - no change
Legal & Regulatory - no change
A4.1.7.2. Stock Checking. Change: Removal of value
information on Stock reports
Performance - no change
Accessibility/Security - no change
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure - no change
Auditability - no change
Legal & Regulatory - no change
4.1.7.3 Produce Trial Balance. Change: Change in reports
to exclude stock in balance.
Performance — needs to be reviewed not perceived to be a
problem at the moment
Accessibility/Security - no change
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure - no change
Auditability - no change
Legal & Regulatory - no change
A4.1.7.4 Investigate Balance Discrepancies. Change: No
change.
Performance — needs to be reviewed not perceived to be a
problem at the moment
Accessibility/Security - no change
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure — no change
Auditability - no change
Legal & Regulatory - no change
A4.1.7.5 Produce Final Balance. Change: Functionality to
control not being able to complete Trading Statement with
variances.
Performance — needs to be reviewed not perceived to be a
problem at the moment
Accessibility/Security - no change
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure — no change
Auditability - no change
Legal & Regulatory - no change
Ad1.7.6 Produce and Confirm Trading Statement. Change
New Report, change in electronic confirmation functionality
Performance — needs to be reviewed not perceived to be a
problem at the moment
Accessibility/Security - only accessible by
manager/supervisor/auditor/emergency manager as current cash
account function.
Usability - no change
Data Retention - to match period of data held by Horizon
Mitigation of failure - no change
Auditability - no change
3 March 2004
© Post Office™ 2004
Version 1.0
Page 89 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Change Area Non-Functional Considerations
Legal & Regulatory - no change
3 March 2004 Version 1.0 Page 90 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
{2 Technical Requirements
12.1 Architecture Principles
12.1.1 Application
No specific requirements.
12.1.2 Resilience
No specific requirements.
12.1.3 Performance
No specific requirements.
12.1.4 Communications
No specific requirements
12.2 Architecture Building Blocks
12.3 Architecture Components
12.4 Integration & Interfaces
3 March 2004 Version 1.0 Page 91 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
13 Security Requirements
Role based access required to system functionality as specified within Section 10.1.
13.1 Security Policy
The security requirements are as outlined in the PO Ltd IS Security approach. This assesses each component and produces a
security classification.
13.2 Physical Security
No specific requirements
13.3 Technical Security
No specific requirements.
13.4 Implementation & Development Security
No specific requirements.
13.5 Security Management
No specific requirements.
13.6 Security Testing
No specific requirements.
3 March 2004 Version 1.0 Page 92 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
14 Deliverables / Work Packages
14.1 Post Office™
The conceptual design document.
Associated work packages.
Updated AIS / TIS for those items identified in Section 14.4 below
14.2 Fujitsu Services
14.2.1 Development
Fujitsu services should develop a design proposal to meet the requirements set out in this document and provide the post office
with a commercial proposal which will specify the costs, time-scales and resource implications for progressing to the solution
build and test stage, and the implementation and rollout stage. It is understood that a single design proposal should be produced
for all requirements except those identified within Section 21, Appendix C.
Acommercial proposal for the requirements identified within Section 21, Appendix C should be produced as agreed in the
Schedule 12 proposition letter signed by Fujitsu Services and Post Office Ltd. 26/3/2004. Fujitsu Services will develop separate
Design Proposals to meet these requirements.
14.2.2 End to End Integration, Testing and Acceptance
Fujitsu services will assist with End to End integration, testing and acceptance.
Post Office will determine how this task is carried out and the requirement for supplier support will be specified in a separate
document.
14.2.3 Managed Service
Fujitsu Services shall provide service support for the branch trading application.
14.2.4 Documentation
Fujitsu Services shall update relevant current and produce any new contract controlled documents in support of the branch
trading application.
14.2.5 Internal Processes & Procedures
Fujitsu Services shall update where necessary, any internal processes & procedures, in order to support the branch trading
project.
14.3 Prism
14.3.1 High Level Solutions Design
™ — Assuming that processes associated with the central correction of Non-Accounting Data will be supported by central
systems (to be defined) but that any correction required in Horizon will be effected by the same Transaction Correction
mechanism as is to be used for Accounting Data.
Assuming that processes required to support central reporting and investigation of branch anomalies is being addressed via
the Management Information Work Stream and that no support from Horizon systems is required.
14.3.2 Internal Processes & Procedures
14.4 AISs
The following AISs will be produced to support the IMPACT R3 Branch Trading Requirement defined in the CD
© — SAPADS to Horizon
3 March 2004 Version 1.0 Page 93 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
POL FS to Horizon
Horizon to POL FS
Horizon to HR SAP
Horizon to Sales MI
ee eecce
Horizon TMS to External Sources (many)
Reference Data to Horizon
External Sources to Horizon TMS (just CAPO)
14.5 Reference Data Changes
BT-053 POL
BT-055 POL
New data structures and data items are required to support the overall Branch Trading objectives.
These are:
To control the trading statement
Trading calendar and periods
« — Trading Statement Indicator
To ensure correct summarisation for SAPHR
Agent Contract Types
« Remuneration Summarisation Timetable
¢ Remuneration calendar
— Remuneration groupings
To ensure correct allocation to suspense
© Suspense products
— Suspense products to branch
— Suspense products minimum values
To ensure correct accounting in POLFS
* POLFS materials and clients mapped to Horizon products
‘To enable monitoring of transaction corrections
e — Automated Message Receipt Prompt (Type C)
To ensure distinction between a sale value and a loss value for stock items
© — Stock Loss Value
‘To monitor the revaluation process
¢ — Revaluation date
There is a requirement to control all items of stock. This will be achieved through reference data by
defining as controlled products those products which are currently non-value products
3 March 2004
© Post Office™ 2004
Version 1.0
Page 94 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
15 Planning
15.1 Timescales
15.2 Dependencies
The business change plan needs to include activities to introduce the following capabilities by the time that the IMPACT R3 Branch Trading
functionality is introduced to the businesses:
to introduce functionality to support POL requirements for rota check processes designed to identify unexpected branch trading
patterns together with the support for the required processes to support investigations into detected instances of these
unexpected trading pattems. This activity is required to be completed prior to the introduction of IMPACT R3 functionality at S80
© review of Horizon products targeted for support at $80 to identify and introduce:
© an appropriate set of product specific range checks to cover client and POL requirements. It is envisaged that this
activity will involve definition and introduction of the reference data required to implement the required range checks
and can be achieved using existing Horizon functionality. This activity is required to be completed prior to S80
introduction
© price to be used when accounting for stock adjustments. This activity requires an extension to the product reference
data definition to accommodate this additional information. This activity is required to be completed prior to the
introduction of the associated IMPACT R3 functionality at S80
© stock that is to be controlled by Horizon (i.e. Horizon non-value stock that needs to be made Horizon value stock).
Changes introduced will need to be accompanied with changes to the accounting hierarchies to reflect the required
accounting action for each product/controlled stock item. This activity is required to be completed prior to the
introduction of the associated IMPACT R3 functionality at S80
— confirm requirements and establish IMPACT R3 feeds to Post Office Financial Risk Model to replace existing feeds from Intellect
and other legacy systems
3 March 2004 Version 1.0 Page 95 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
16 Acceptance
Refer to Acceptance Process CCD PAPRD/013
Acceptance takes place upon determining that the solution is fit for purpose. Acceptance for each Requirement will be conducted
by one or more of the following methods: -
1. Document Review (DR)
Requirements that cannot be objectively verified by a test of the Work Package solution may be satisfied by
PO undertaking a Document Review. The outcome of any such review will be documented by PO in the
Document Review report
2. Design Walkthrough (DW)
Requirements may be satisfied by PO evidencing a Design Walkthrough of the Fujitsu Services Design as
specified in the Design Proposal. The outcome of any such design walkthrough will be documented by PO in
the Design Walkthrough report.
3. Fujitsu Services Test (FST)
Tests that are run and managed by Fujitsu Services for the purpose of verifying that a Fujitsu Services Work
Package satisfies the Work Package Acceptance Criteria. Fujitsu Services shall produce a test report
presenting the results of the tests. The assessment of the results of these tests will be by inspection carried
out by Fujitsu Services or jointly with PO, in conjunction with the Acceptance Criteria.
4. PO (E2E) Test (POT)
Tests that are run and managed by PO (which in terms of the scope of this document), are for the purpose of
verifying in terms of the E2E solution, Acceptance Criteria have been met. PO shall provide appropriate
evidence to FS, if any non-compliances are identified.
5. Monitoring (M)
PO shall specify any requirement beyond the level of support that Fujitsu Services are required to provide
under normal operational practice (such as a report etc). Typically the duration of this requirement may be of
the order of one month and no greater than 3 months, but in any event to be agreed in advance between PO
and FS.
6. _ Statement of Fact (SOF)
Where the solution to a Requirement is self-evident and does not lend itself to formal proving.
7. Statement of Obligation (SOO)
Relates to requirements that represent either:
« — Anexisting Fujitsu Services obligation or
« — Agreed additional Fujitsu Services obligation (to be recorded subsequently as an amendment to
the contract clauses, schedules, or contract controlled documents)
8. Other
‘© Used by exception, to be agreed between the parties
The Acceptance Method for each Requirement is indicated against it in Appendix A
17 Testing
Refer to Testing CCD VI/STR/064
NB: E2E references within this section refer to end-to-end (E2E) testing and not the E2E Programme (former name for IMPACT)
17.1.1 Testing Statement
The testing plan will be based around the following PO Ltd testing statement
Testing will be able to confirm the acceptance criteria for some requirements have been met during the various test phases. The
criteria and the targeted test phase for the requirements statements (as detailed in this section) will be added at a subsequent
release of this document. The testability of the acceptance criteria should be assessed by the testing team during the
Requirements reviews.
‘An appropriate Test Strategy will be developed to reflect the release contents.
This will include some or all of the following testing phases.
17.1.2 Internal Functional Testing
Gaining assurance of main suppliers internal functional testing via :~
3 March 2004 Version 1.0 Page 96 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
co Review suppliers internal test plans/ scripts for completeness
co — Review suppliers internal test results / progress reports
o Review suppliers internal testing fault logs for impact
17.1.3 Non Functional Testing
Due to the nature of this type of testing the aim would be to achieve this via engagement with the supplier in:-
© — Supplier document reviews
o Review of supplier test plans / scripts for completeness
co Witness specific key tests during a supplier testing cycle
o Review supplier test results
o Review supplier test fault logs for impact
17.1.4 Interface Testing
Lead or Support Suppliers through the execution of Direct Interface testing between two suppliers e.g. Lead Horizon to SAP/ADS
co Review or develop and agree Interface scripts between two supplier domains
© — Support or co-ordinate set — up of test environments
© — Support or co-ordinate the provision of Required Ref. Data
© Support or execute where appropriate the tests
o Review the test results including any faults
17.1.5 E2E Integration Testing
This phase is where POL would lead, supported by suppliers, in demonstrating the successful connection of all the appropriate
systems (test versions) in the releases E2E solution including carrying out some E2E test transactions to confirm the readiness to
enter the POL E2E functional testing cycles.
17.1.6 E2E Functional Testing
This phase is where POL would lead, supported by suppliers, in demonstrating through short “days in the life of the POL
business’ cycles that the revised systems interact correctly in an E2E manner and with the revised business process and
procedures.
This is also to assure POL that the changes to current systems and the introduction of new systems has not impacted upon the
businesses operation including E2E financial aspects (accounting, reconciliation, settlement, remuneration) have been and can
maintained during live operation. E2E Management Information is maintained or new information reflects the requirements and
business needs.
Successful completion of this phase would lead to the introduction into the live environment via one or more of the following:-
© apre-pilot (transactions carried out in the passive Post Office)
© pilot (small number of outlets)
© — go-live.( rolled out to the full estate)
17.1.7 Pre-Pilot
This final testing phase is whereby a “live” Post Office is used to test that the connectivity of the live E2E systems has been
achieved and that a small number of transactions representing the changes can be carried out and report correctly in accounting
and management information terms
Completion of this final phase should be the point of hand-over to the Implementation team / phase.
3 March 2004 Version 1.0
© Post Office™ 2004
Page 97 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
18 Implementation & Migration
This section documents an initial analysis of implementation and migration requirements. The detailed requirements will be developed as
part of a separate work stream.
18.1 Migration Principles
The following principles define the overall migration approach:
+Final Accounting CAP on Wednesday before end of final accounting period on CBDB
“All branches start to feed POL-FS on same trading day (i.e. the next day)
*Stock in hand and Suspense in hand migrates at day following final accounting CAP
-CBDB balances migrate to POL-FS completely as at the period end
18.1.1 Migration Timeline
The diagram below shows the major events within the migration.
May 20
Ape 20 SAP-HR
From TMS data
fiow
BDBOPTIp 23/7 CAP
a rs
I
OPED food ost
1
A / B Cc
Final CBDB.
Same Tane
In ALL brauches
cBDB
POL-S
This shows three separate phases during the migration process:
= A‘ This is the time from when the branch migrates to include support for the functionality described in this CD until the final
Cash Account that is to be processed by CBDB. The diagram shows that as being 23/3/05, however the exact date will be
decided nearer the time. It is required to be a Wednesday (since Cash Accounts change on a Wednesday) and it should also
be the Wednesday immediately prior to a Post Office Ltd Month End.
= B: This is the period when POL FS will be providing the central support for the Financial systems, however the branches will
still be operating most of the current processes
™ C: This is when the braches switch to using Branch Trading statements rather than the current Cash Accounts.
Other points to note from the diagram:
.
During period B, the first time that the Summarisation process operates to pass data to POL FS, it is necessary to ensure that
the Opening Position is correctly passed across to POL FS. This Opening Position should be based on the closing levels
reported in the Final Cash Account sent to CBDB. All transactions from the point at which the Final cash account was taken
must be identified and their effect passed to POL FS even if they took place in earlier Trading Days so that there are no
Transactions not accounted for in either CBDB or POL FS
During period B there will still be cash account information coming from some branches (following non-polling) which will
need to be sent to CBDB. In order to support this, the existing interface to OPTIP will need to be maintained during this period.
Once all Final Cash Accounts have been sent through, it is then possible to switch off the feed to OPTIP and to replace it with
an enhanced data feed to MIS. The completion of final cash accounts will be monitored from OpTIP data
= The switch from phase B to phase C need not take place at the same time in all branches. This will allow the new processes
to be piloted. A “soft launch” mechanism is required to enable the rolling over of a Cash Account to result in the migration of
Stock Units and the branch into the new way of working (i.e. moving from phase B to phase C).
= CBDB will pass data to HR SAP covering the period up until the final Cash Account (i.e. the end of phase A). This means that
the first run of data from TMS to HR SAP will probably be nearly 2 months after the move from Phase A to Phase B.
3 March 2004 Version 1.0 Page 98 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: IMPACT - Branch Trading Reporting,
POL00038878
POL00038878
Management and Control and Transaction
Management
18.2 Migration Requirements
Change Area
Migration Approach/Requirements
Ad1.1.4 Perform Transaction Checks Periodic. Change:
Production of new reports and exception reports
Changes implemented in MIS systems no change at front
end. Non-Functional and Migration requirements to be
considered under the MI part of the Impact program.
A4.1.1.3 Automated Reconciliation. Change: Move from
APSITPS to TMS
Requirements to be defined as part of migration work stream.
4.1.2.3 Produce Sales Report to Assist Remuneration
Check. Change: Different sales report over different
periods.
Could be implemented at any time, would be beneficial to be
implemented in period A. No need for soft launch.
A41.5.1 Receive Automated Message. Change’
Reminders on Receipt/Delivery of Transaction Corrections.
Needs to be implemented from the beginning of point B, can
be implemented, but not used, from commencement of
implementation. Need to consider mapping Transaction
Corrections transactions to the cash account during Period B.
A41.5.2 Handle Transaction Correction. Change:
Management of Transaction Corrections, Implementation of
corrective actions, etc.
Needs to be implemented from the beginning of point B, can
be implemented, but not used, from commencement of
implementation. Need to consider mapping Transaction
Corrections transactions to the cash account for during
Period B.
Although branches may still be doing cash accounts, the
moment that CBDB is ceased no cash account errors should
be brought to account and the facility to do this should be
removed. Manual processes will be set up to deal with this in
POL-FS. Error Notices buttons to be removed at switch over
from Period A to Period B, after which process is for
outstanding Error Notices to be converted to Transaction
Corrections.
A4.1.6.1 Compare Generated with Actual Cash Held for
Stock Unit. Change: Removal of ONCH declarations
functionality, reminders on cash declarations.
During period A, implemented at implementation of $80. Day
1 Period A.
A4.1.6.2 Create Variance Report. Change: Implementation
of new report - format to be defined, complexity may affect
usability of report produced - may need to re-format to
simplify.
During period A, implemented at implementation of S80. Day
1 Period A.
4.1.7.1 Make Good any Outstanding Variances. Change:
Changes to Suspense Account products.
Prior to going live with S80 there will be known and unknown
values in Suspense. The known (or legitimate) items should
be mapped across to the new suspense products so that
they can appear in the new account. For the unknown
suspense items, these should not be taken across, but we
would like the values to be mapped onto the Cash variance
Report so that they appear as shortages/surplus and will then
be dealt with by the mew processes. These
shortages/surpluses should be identified as a result of this
migration mapping.
At commencement of Period C. Need to clear any values out
of the discrepancy product. Need to consider what to, how
and when (during the first balance of Period C)?
A4.1.7.2 Stock Checking. Change: Removal of value
information on Stock reports
Implemented at commencement of Period C.
Transfer of Non-value stock to be controlled stock,
implemented during Period C. Need to consider how to
obtain opening balances. Back end controls for process
manual returns need to continue until this is completed.
‘A4.1.7.3 Produce Trial Balance. Change: Change in reports
to exclude stock in balance.
Implemented at commencement of Period C. Must be able to
correlate brought forward figure to carried forward items on
old style reports.
A4.1.7.4 Investigate Balance Discrepancies. Change: No
change.
4.1.7.5 Produce Final Balance. Change: Functionality to
control not being able to complete Trading Statement with
variances,
As for trial balance
A4.1.7.6 Produce and Confirm Trading Statement. Change:
New Report, change in electronic confirmation functionality
Implemented at commencement of Period C. Must be able to
correlate brought forward figure to carried forward items on
old style reports.
3 March 2004
© Post Office™ 2004
Version 1.0
Page 99 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
3 March 2004 Version 1.0 Page 100 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
19 Appendix A - Requirements Catalogue
Gaps in the requirement numbers represent requirements that have been removed, and the numbering has been retained for clarity.
Req ID ‘Supplier Description T Acceptance Criteria I Acceptance
i I A __ Method
BT - 004 I Fujitsu Production of a balance report for a stock unit must be possible to be The time taken to produce balance reports fora stock unit = FST
Services an oo. . with an agreed transaction profile will be tested on the I
produced within 5 times the current production time for a stock unit with a previously released system. The time taken for the new I
I busy transaction profile, long trading statement period balance reports to be produced for a stock unit with the I
I ‘same agreed transaction profile for a 5 week trading period
will be tested on the system developed for this release. This I
time will not be greater than 5 times the time taken in the I
previous test. I
BT - 002 Fujitsu i Functionality not specifically identified to be changed within this document The agreed set of regression tests will establish that there is I FST i
Services i . . no deviation of conformance to requirements, for the areas
I Must not be affected to degrade the existing service provided by the Horizon not affected by this development, from that provided by the
system. previously released system. I
BT - 003 I POL, Fujitsu I Migration to POL-FS must occur at the end of a financial period None I SOF
Services, I
PRISM L L +
BT - 004 POL I [twill be verified that branch processes and reporting changes meet legal and _ POL will identify all legal and regulatory financial reporting» DR
i . . ' constraints that the Branch Trading developments will I
I regulatory financial reporting constraints (e.g. auditors) to ensure that there is comply with. POL will review this Conceptual Design I
I sufficient information from the new system to support regulatory reporting, document against any identified constraints. I
tigation and criminal prosecution. i
I
BT- 006 Fujitsu Anew trial balance report will be produced, the content and format of which Tests will verify that the trial balance report is produced with I FST
Services . . . the content and format as specified in Appendix B of this i
will be as specified in Appendix B of this document document. I
BT -007 Fujitsu "The content and format of trial and final balance reports willbe altered as. _—_‘Tests will verify that the trial and final balance reports are ==) FST
Services I produced with the content and format as specified in I
specified in Appendix B of this document Appendix B of this document. I
BT - 008 Fujitsu I Anew trading statement report will be produced, the content and format of Tests will verify that the trading statement report is produced I FST
Services with the content and format as specified in Appendix B of this
3 March 2004 Version 1.0 Page 101 of 133
© Post Office™ 2004
POL00038878
POL00038878
In entry of date ran
produced will be implemented within Horizon, the system will verify that a I report matching the existing content and format of the sales
I valid date range has been entered, If invalid it will allow re-entry, if valid it will I report as defined within the “Horizon OPS Reports and
i I produce the existing sales report but with data covering the specified date Receipts” document (Ref SD/DES/005) is produced
Services
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier I Description Acceptance Criteria I Acceptance
L I Method
which will be as specified in Appendix B of this document document. I
BT - 009 Fujitsu ‘Anew variances report will be produced, the content and format of which will __ Tests will verify that the variances report is produced with the I FST
Services i cee ' content and format as specified in Appendix B of this I
I be as specified in Section 20.2 in Appendix B of this document document. I
BT -010 POL ©‘Kreview of which periodic checks are fo be made, with which parameters, on POL will review the IMPACT-POL-FS Conceptual Design to I DR
__data within Management Information systems must be made. I_Nerify that requirements for periodic checks are captured. L
BT -011 POL _ A review of parameters, defined through reference data, for control and I Adocument of the findings of the review of reference data I DR
management of data entry at the counter, is to be made. Any changes to _ parameters will be produced and reviewed to ensure thatit
reference data must be implemented prior to removal of current CBDB range _ puts in place controls to replace all CBDB range checks that
I check processes. can be replaced by this method. I
] I
I
Existing processes for transferring, testing and implementing I SOO (existing)
new reference data to the Horizon counter willbe usedto I
H make any identified changes. I
BT -012 POL : Arevised end of day procedure will be defined, identifying which summaries I Adocument of the findings of the review of end of day I OR
+ must be produced at end of day. The buttons on the “Counter Daily’ menu will I procedures will be produced and reviewed to ensure that it I
I be reviewed accordingly. The revised list of items will be defined in reference _ all processes which must be performed on a daily basis I
I data for display when the “End of Day’ button is pressed on Horizon. within the branch. /
I
Existing processes for transferring, testing and implementing I SOO (existing)
new reference data to the Horizon counter will be used fo
L {make any identified changes. it
BT -014 POL "A revised end of period (probably weekly) procedure will be defined, POL will re-write the office procedures documentation to I OR
identifying which summaries must be produced at end of period. identify which reports and summaries must be produced with I
i which periodicity. POL will review the office procedures I
documentation to ensure that sufficient guidance is given to I
L counter staff. I i
BT -015 POL The list of summaries will be reviewed and classified as mandatory and POL will review the list of summaries to be producedona I DR
optional. Business rules for content on optional summaries will be defined. As periodicity other than daily and will document which types
either: are to be produced on what periodicity. Those summaries
— Summary of transactions of type since last cut off, whether cut-off is _ which involve a cut off will also be reviewed to identify how
in this trading period or last. the summaries should appear. POL will review the I
Summary of transactions of type since last cut off, if cut off in this documentation of this review to identify if the summaries I
trading period, but only summary of transactions of type since start I currently produced are required to change. (Note it is I
iod if last cut-off w vious trading peri ies wil L ;
I
I
I
I
I
I
3 March 2004 Version 1.0 Page 102 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description Acceptance Criteria I Acceptance
range. — oe — —
Business procedures for entering non-accounting data, identifying what data I
+ and when, will be produced. identify which non-accounting data must be entered with I
i which periodicity. POL will review the office procedures I
documentation to ensure that sufficient guidance is given to I
7 I 7 7 “counter staff. 7 I
BT -021 POL Business procedures for entering bulk data, identifying what data and when, — POL will re-write the office procedures documentation to _ OR
will be produced identify which bulk data must be entered with which I
periodicity. POL will review the office procedures. I
documentation to ensure that sufficient guidance is given to
__ counter staff. {
BT - 022 POL The existing products will be reviewed for opportunities to capture additional I POL will review the existing products for which data is _ DR
I data at the point of sale, removing needs to manually record transaction data. I captured on non-system means (@.g. paper), identifying I
The review will analyse, and if necessary, renegotiate client reporting opportunities to remove non-system data capture and /
+ requirements. transfer. The review documentation will be reviewed to I
i ensure that all opportunities that could be taken to eliminate
. Le. . . non-system based data capture have been taken. I i
87-023 POL ‘New and replacement products will be implemented using existing system POL will review documentation, produced by POL, Sales and DR
© capabilities. Marketing, for all proposed new and replacement products to _
I
ensure that the proposals utilise existing functionality.
user with the appropriate role will be informed, ai log on, that there are it will be tested that whenever a user with the role of
outstanding Transaction Corrections awaiting processing, whenever there are I Manager or Supervisor logs onto the system and there is an
I any. outstanding Transaction Correction to be processed within
i the branch that the message, to be defined within the Branch
Trading Counter Dialogues documentation, is presented to
the user.
I There will be a bution for Transaction Correction Management within the ty for accessing ani
I menu hierarchy which is only accessible by users with the appropriate role. I managing Transaction Corrections is carried out to conform
This will provide the user with a list of the unprocessed Transaction — to the definition within the Branch Trading Counter Dialogues
Corrections, displayed in date/time order. Having selected the Transaction — documentation.
Correction to process, the system will display text making clear what will
happen when they select any of the options presented, the user should be
"able to print the details of the transaction correction at this point in order to
_ consider its implications before invoking it.
I For each Transaction Correction the user will have up to three options — Each
I option, when selected, will perform an identified set of transactions, defined
within the Transaction Correction. (this may include an option to Do Nothing
I Fujitsu
I Services
ae ae
BT -026
Fujitsu At the end of performing a cash declaration, in a shared stock unit, the system = It will be tested that after making a cash declaration the user FST
I Services __will enter, if the user chooses fo, the cash discrepancies function to support _ is given the option to enter the cash discrepancies function. __
3 March 2004 Version 1.0 Page 103 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
© Description Acceptance Criteria I Acceptance
the identification of any variance.
Reminders for ONCH function to be pel formed at log on not ‘performed “~—"itwill be tested that when the user does not pet form a cash
I previous day will be removed and, instead, the system will remind users to declaration on one day, at log on at the following day the
I perform cash declaration function if it has not been performed on the previous I user will be reminded and given the option to make the
I day, but this may be declined. declaration at that time. It will be tested that that option can
i be declined is the user wishes not to make a declaration/
When the cash declaration has been made the figures for denominational split _ It will be tested that denomination cash holding data from
will be passed to SAP-ADS as if an ONCH declaration had been performed. cash declarations is used to populate the Horizon - SAP-
ADS interface as defined within the Horizon - SAP-ADS AIS
documentation,
BT - 029 Fujitsu FST
Services
POL
Tests will verify that denomination data can be read and POT
used by SAP-ADS cash planning functions in place of the
I i ONCH data it previously received, as defined within SAP-
{ H __ADS testing documentation.
BT - 030 I Fujitsu I Anew function will be made available to provide the variance report fo the § It will be tested that users can initiate the production of the
Services I defined content and format Variance Report and that when produced the report has the
content and format as defined in Appendix B of this
I document.
A review of vouchers remitted from the branch will identify which dockets will I POL will review the vouchers remitted from branches to
need to be treated via which adjustment products. identify which mechanisms are to be used to account for the
values those vouchers represent. POL will review the
documentation produced by the review to ensure that all
vouchers, where possible, are replaced by accounting
schani
BT - 032 Fujitsu I Anew function for recording a “make good” action will be made available this I It will be tested that users can initiate a make good
Services I will allow the user to enter the amount made good. It will record the amount transaction and that when performed that the previous
made good, making a new declaration for cash by altering the previous declaration will be adjusted to correct the previous
declaration by the amount made good. Amounts made good will be reported = declaration of cash by the amount made good. It will also be
‘on variance reports, balance reports and trading statements. tested that when an amount is made good then this amount
is displayed in variance reports, balance reports and trading
_ Statement reports subsequently produced.
I Aprocess for applying for hardship will be defined to allow a branch manager I POL will produce a procedure definition for applying for
I to make alternative arrangements for when a variance cannot be made good I hardship loansitreatments for when the branch manager
I immediately. Variances will be held whilst the application is processed, this I wishes to make good losses in the branch accounts but is
I may extend the Trading Period. Approved hardship amounts will appear as not readily able to do so. The documented definition will be
Transaction Corrections reviewed to ensure that the process will quickly and
effectively generate the Transaction Corrections needed to
iH _ allow the branch to complete the Branch trading Statement.
BT - 035 POL I Reference Data will be edited to limit the suspense accounts available within I Adocument of the findings of the review of suspense
FST
BT - 034 POL OR
FST.
BT - 034 POL DR
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
i
4
t
I
I
I
I
I
Tv
I
I
I
I
I
I
I
I
I
I
I
i
+
I
I
I
I
I
I
I
I
I
i
+
i
3 March 2004 Version 1.0 Page 104 of 133,
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description Acceptance Criteria I Acceptance
branches to the limited “known errors” set. accounts reference data parameters will be produced and
reviewed to ensure that it limits the use to an acceptable set
of suspense products.
I
I
I
Existing processes for transferring, testing and implementing I $00 (existing)
new reference data to the Horizon counter willbe used fo
. . . . . make any identified changes. . al I
BT - 036 Fujitsu Adjustments in stock (whether identified via adjustments or stock © It will be tested that when an adjustment price is defined I FST
Services declarations) should be adjusted at the adjustment price whenever defined in _ within the reference data for a product, that an adjustment of
reference data. the stock holding by one unit of that item will make an I
alteration in the cash position equal to the adjustment price I
ee a ofthat item.
BT - 037 Fujitsu Report will be redefined without stock values as defined in Section 20.7 in I Tests will verify that the Office Snapshot report is produced I FST
I Services + Appendix B of this document with the content and format as specified in Appendix B of this /
i i document. i
BT - 038 I Fujitsu I Anew check is to be introduced after producing the Trial Balance (i.e. when Tests will verify that stock units trying to balance will display I FST
Services I the ‘rollover’ button is pressed prior to producing the Final Balance). This the behaviour as documented within this requirement. I
I check will act as follows: I
L 4. Ifitisn’t the last Stock Unit to rollover, and there is a Cash I
I
Discrepancy, the clerk will be advised that the Discrepancy is to be I
posted to a “local adjustments” account. They have the option of /
accepting or rejecting this action /
d. Should they accept it, then a pair of transactions will be /
generated resulting in the Disorepancy being reduced to i
zero and a corresponding amount being put into a “local I
I
adjustments product”. I
I
e. Should they reject it, then the rollover is aborted and the I
I
clerk is free to do whatever they wish to balance the I
I
Stock Unit and will then need to balance the Stock Unit I
again at a later time. I
f. The “local adjustment" is not associated with any Stock /
I Unit (as with a Suspense account). Items can be added I
3 March 2004 Version 1.0 Page 105 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description Acceptance Criteria I Acceptance
to it by any clerk, but only as part of the Balancing
Process. Managers / Supervisors will be able to move
items from it into cash in their SU to be Made Good.
5. If this is the last Stock Unit to Rollover an additional check will be
performed to ensure that the net total of transactions, within the
Trading Period, in the “local adjustment” account has a net value of
zero.
6. If this is the last Stock Unit to Rollover, then the user will be
informed if the Stock Unit has a Discrepancy and that this must be
resolved before the last Stock Unit can be rolled over.
- Local Adjustment will behave in a similar way to existing Suspense Account
I items, namely the values will not be associated with any Stock Unit, but is
considered as part of the overall Branch balance.
BT - 039 Fujitsu There is an existing report that shows the state of all suspense accounts and I It will be tested that when cash discrepancies are corrected I FST
Services _ all Transactions associated with the suspense accounts during the Trading via the local adjustment method, as described within
I Period, indicating which Stock Unit carried out the Transaction. It is proposed I requirement BT - 038, that transactions to and from this
I that Local Adjustment transactions are included in this report as with any other I local adjustment account appear on the suspense account
L I Suspense transactions __summary report.
BT - 040 I Fujitsu I Horizon should be changed such that only Supervisors and Managers (etc) _ It will be tested that only users with Manager or Supervisor I FST
I Services + will be allowed to carry out Suspense Transactions. The only exception to this : roles are able to perform transaction with suspense account
will be the automatic posting of Discrepancies to Local Adjustment. products. All users will be able to make adjustments to Local
BT -044 Fujitsu The user will select the appropriate function which will display the Trial : Tests will verify that when using the system to produce the
Services Trading Statement (as per outlined report) and this may be printed. When the I Branch Trading statement the system display the behaviour
I user is content to confirm the position he will be presented with a textual I as documented within this requirement.
I message which describes the liability and responsibility which the postmaster
is accepting. If the postmaster accepts this the system will record this action,
print the Final Trading Statement and commit an event which identifies that
the agent has produced the Trading Statement and accepted liability for the
trading position. L
BT - 043 Fujitsu _ The confirmation event will be made available to the data warehouse to I Tests will verify that the action of producing the Branch I FST
I Services _ enable monitoring of who has and who hasn't done a trading statement. The I Trading Statement produces an event within the Horizon
3 March 2004 Version 1.0 Page 106 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID
I Supplier
© Description
“confirmation transaction” will not contain the constituent parts that make up
the trading position.
Acceptance Criteria I Acceptance
system, which can be reported on the User Events Log, and
the existence of which is used to populate the Horizon - MIS
interface as defined within the Horizon - MIS AIS
documentation,
I
I
I
I
I
/
POL Tests will verify that events data used to populate the POT
Horizon - MIS interface can be read by the MIS system and _
is reported in reports in which the data should be reported, _
as defined within MIS system testing documentation. i
BT - 044 Fujitsu A facility for different branches to operate on a different (four weekly) branch _ It will be tested that a calendar of Branch Trading Statement I FST
Services trading calendar, will be implemented, which branch is operating to which I production dates can be implemented such that the system I
calendar is to be defined by reference data. will warn users when the production of the Branch Trading _
I __ Statement is overdue. I
BT-045 I Fujitsu I The current functionality for extending accounting periods should be removed. Tests will verify that the Horizon system continues to provide ] FST
I Services _ The Horizon system should continue to remind users to roll-over the — the warning to users at log on whenever the stock unit has I
I accounting period if they logon to a SU in the wrong Trading Period according _ not rolled into the correct Trading Statement period —
I I to the calendar. according to the calendar. The warning will be as defined _
L i _ within the agreed Counter Dialogues documentation. i
BT - 046 » Fujitsu Revaluation functionality to be redefined such that the user is reminded, fora Tests will verify that reminders are given to users at log on to FST
Services series of days, at logon of an upcoming revaluation (defined by Reference remind users when a product is about to be revalued. The I
Data). The reminder will suggest that the branch manager checks stock and reminders are to be as defined within the agreed Counter _
makes any adjustments prior to the price change Dialogues documentation. /
BT - 047 indicated items held as part of the balance fig g. as Ott
Fujitsu
Services
Fujitsu
Services
I Stamps) must be re-classified before implementation of this function
I (otherwise current revaluation functionality will be required)
I The data retention period will be increased such that all trading data is
I available within the Branch for a minimum of 42 days.
I The data retention period will be increased such that all trading data is
available at the data centre for a minimum of 42 days.
Process for recovery situations when the Branch is nearing, or has exceeded,
ly
Stamps’ within the Horizon system to ensure that only value
indicated items (e.g. 2p stamp) appear within this
classification. Any non-value indicated items will be
reclassified
Existing processes for transferring, testing and implementing
new reference data to the Horizon counter will be used to
Tests will verify that all trading data is retained by the
Horizon counter system for a minimum of 42 days.
"Tests will verify that all trading data is retained by the FST
Horizon data centre systems for a minimum of 42 days.
POL will identify and document procedures for irying to) DR’
3 March 2004
© Post Office™ 2004
Version 1.0
Page 107 of 133
S00 (existing
POL00038878
POL00038878
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description Acceptance Criteria I Acceptance
42 days since it produced the last Branch Trading Statement will be defined. ensure that the Branch Trading Statement is produced within
42 days since the last, and if not, how to produce the Branch
Trading Statement. POL will review this procedures
document to ensure that the business can proceed through
such events.
I
I
I
I
I
BT - 052 POL I Training will be required at the Branches in support of the new business POL will document the many changes arising from this OR
. project. POL will review this documentation to ensure that
processes, it is currently assumed that this will be provided by POL. sufficient guidance is given to counter staff. I
g i
BT - 053 POL New data structures and data items are required to support the overall Branch I POL will review the Reference Data to Horizon AIS to ensure DR
. . that the updates required from these Branch Trading I
Trading objectives. These are: requirements are supported through the control of reference
data I
I
© To control the trading statement Tests will show that the reference data system is able to / POT
i . generate the data to the defined Reference Data to Horizon
Trading calendar and periods AIS I
I
I Trading Statement Indicator I
To ensure correct summarisation for SAPHR I
I
— Agent Contract Types I
I
« Remuneration Summarisation Timetable I
I
Remuneration calendar I
I
Remuneration groupings I
I I
I To ensure correct allocation to suspense I
— Suspense products /
I
— Suspense products to branch I
I
Suspense products minimum values I
I
I I
I To ensure correct accounting in POLFS I
I
+ POLFS materials and clients mapped to Horizon products /
I
3 March 2004 Version 1.0 Page 108 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description Acceptance Criteria I Acceptance
To enable monitoring of transaction corrections
* Automated Message Receipt Prompt (Type C)
_ To ensure distinction between a sale value and a loss value for stock items
© — Stock Loss Value
To monitor the revaluation process
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
. I
« — Revaluation date I
I
I
review all non-valu
i . for redefining them as controlled stock items. SOO
_ through reference data by defining as controlled products those products ‘document of the findings of the review of non-value stock
BT- 055"
I which are currently non-value products items will be produced and reviewed to ensure that it
{ identifies those which are to be reclassified as controlled
items and that they will be controlled accurately by this
redefinition.
Existing processes for transferring, testing and implementing
new reference data to the Horizon counter will be used to
. i . . . . . __..make any identified changes. . .
Fujitsu All stock items will be monitored throughout the Horizon system by volume ‘The Horizon Reports and Receipts documentation and the
Services i Counter Dialogues documentation will be reviewed to ensure
_ and not by value. that all reports and dialogues exclude mention of the value of
stock items, other than Cash, Foreign Exchange and Other
Stamps stock.
$00 (existing)
BT- 056 OR
Tests will verify that reports, receipts and dialogues used to FST
present information about stock items match the definitions
within the Reports and Receipts documentation and the
I nnn sn sn Counter Dialogues documentation. aw .
© The following reports are no longer required and will be removed from the The Horizon menu hierarchy documentation will be re-written
. to remove the buttons for producing the identified reports.
Horizon system: The Horizon reports and receipts document will also be re-
© Counter Weekly DVLAV10 written to remove these reports. POL will review these
© Counter Weekly DVLAV11 documents to ensure that these reports will no longer be
“BT -057 POL oR
3 March 2004 Version 1.0 Page 109 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description Acceptance Criteria Acceptance
Method
© — Office Weekly Counters Revenue Schedule
© Declaration and Confirmation - Non-Value Stock
« — Counter Daily Cash on Hand (there is a separate report for Cash
available to be produced.
Declaration which is nearly identical, and it is just the cash I Existing processes for transferring, testing and implementing — SOO (existing)
Declaration report that we need to retain) new reference data to the Horizon counter will be used to
© — Office Weekly Cash Flow(this is replaced by the Variance report) make any identified changes.
— Cash Account Trial
— so Ce . ous :
BT - 058 Fujitsu The existing Weekly Stock Holding feed to SAP-ADS will be removed The Horizon -SAP-ADS AIS will be reviewed to ensure that = DR
Services i the weekly stock on hand data is no longer passed from
Horizon to SAP ADS.
It will be tested that the Horizon system feed to SAP-ADS, FST
matches the definition within the Horizon-SAP-ADS AIS
documentation,
POL It will be tested that SAP-ADS can accept the feed of data POT
_ without the weekly stock holding data.
BT - 059 Fujitsu There is a requirement to continue ensuring reconciliation between data flows : Fujitsu Services will review interface design documentation I DR
Services which remain within the Fujitsu domain and ensuring that control totals are : to ensure that all data flows are defined to include any
I applied to any external interface to allow detection of file corruption. All these I necessary reconciliations.
I reconciliations should take advantage of the simplified process described in
Section 21, Appendix C, of this document.
BT - 060 Fujitsu It is required that only reports that have previously been printed can be = Tests will verify that reports can be reprinted as documented
Services I reprinted; and that the reprint reports are identified by date and time — within this requirement.
I previously printed. The following particular requirements are identified for
I report re-prints:
i « — For Stock Unit Balance Reports and Branch Trading Statements,
the requirement is to be able to produce reprints for all reports for
Period N up until the rollover from Period N+1 to Period N+2
«There is no need to reprint the Office Weekly Counters Revenue
Schedule, since the original report has been removed
¢ — For the following reports:
Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA.
Office Weekly Redeemed Savings Stamps
Variance Report (new)
— The requirement is that each of these is a weekly report and it is
I i sufficient to be able to reprint any of these for which the data is still
i i available (ie the last 5 reports). In particular, this will ensure that all
3 March 2004 Version 1.0 Page 110 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
Req ID I Supplier © Description
Acceptance Criteria I Acceptance
‘such reports for the current Branch Trading Period can be reprinted
if required.
«The Track and Trace Manifest, currently allows reprint of the last
report produced. My understanding is that such a report is normally
produced daily, so no special consideration is required in terms of
long term storage of the data for this report.
¢ _Noother reports require reprints. L
The NB103 DRS reconeiliation reports will be eliminated Horizon system design documentation will be changed to
remove the NB103 DRS reconciliation reports functionality.
This documentation will be reviewed to ensure that it no
longer includes functionality to perform the NB103 DRS.
- ACCON CHO,
Horizon system design documentation will be changed to
remove the consolidated stock unit non-value stock report
i functionality. This documentation will be reviewed to ensure
I value stock report is produced as part of end of period processing will also be __ that it no longer includes functionality to produce the
i consolidated stock unit non-value stock report.
BT - 062
Fujitsu DR
Services
Fujitsu
Services
I can be removed. The check to ensure that the consolidated stock unit non-
I Temoved.
Tests will verify that a branch trading statement can be FST
produced without the requirement to also produce the
consolidated stock unit non-value stock report.
Functionality to declare stock holdings of non-value products will be removed The Horizon menu hierarchy documentation will be re-written
i to remove the buttons for declaring stock holdings of non-
_ ftom the horizon system: value products. POL will review this documentation to ensure
that these changes remove the ability to make non-value
stock declarations.
BT - 064 OR
Existing processes for transferring, testing and implementing
new reference data to the Horizon counter will be used to
make any identified changes.
Anew Transaction Corrections report will be produced, the content and format Tests will verify that the variances report is produced with the
tent and format ified in Appendix B of thi
of which will be as specified in Section 20.3 in Appendix B of this document fooument, onmat 2s speotioa in “ppenexonns
$00 (existing)
BT - 065 Fujitsu FST
Services
3 March 2004 Version 1.0 Page 111 of 133
© Post Office™ 2004
Doc Ref: BIRMC&TM-001
Conceptual Design
Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
20 Appendix B - Reports
20.1 Branch Trading Statement
20.1.1 Specification
Note where the branch is managed across many stock units the Trading Statement will be printed across multiple pages the first column to
be repeated on each page. After this a set of pages made up of the information contained within the Counter Weekly Stock on Hand Report
(see below) but summed up across all stock units for the whole branch, and formatted to A4 (portrait) will follow.
There is a requirement to be able to print Trading Statement document until the Branch has rolled over into the one after next period.
Feltham Past Office
FAD 123468
Branch Trading Report “Office Copy
Page 1
TR: 12
Curent Period
SUAA_SUBB__SUCC _SUDD__SUEE. Branch Total
Cash on Hand 8 Fwd £1,000.00 £2 .000.00 £3,900.00 £4,000 00 €5.009.00 £15,000.00
Other MOP B Fwd £0.00 £000 £0.00 £0.00 £0.00 £0.00
Forex B Fed £50000 £700.00 £800.00 £900.00 1,000.00 €4,000.00
Other Postage 8 Fad £100.00 £200.00 £300.00 £400.00 £800.00 £1,500.00
Receipts value Total $6000.00 €7.000 00 £8.000.00_€8.000.00 £1,000.00 £31.000.00
Remittance in (Cash) Total £70,00000 E000 £000 «£0.00 «0.00 £10,000.00
Remittance in (Other Stamps} Total 50000 £0.00 £000 «£000 —~£0.00 £500.00
Remittance In (ForEx} Total 1000.00 £0.00 £0.00 —« £0.00 ~—«£0.00 1,000.00
Gains from Suspense foo £000 e000 ~~—0.00—«FB00. OT £500.00
Transfers in fiom other SU. 000 #750000 9.50000 £3.00000 £0.00 £7,000 00
Payments value Total £7 000.00_£8.000.00 £9,006 00 £10,000.00_ £2,000 00 £36 000.00
Remittances Out (Cash) Total E1ooong 000 £0.00 0.00 £0.00 £1,000 00
Remittance Out (Other Stamps} Total £100.00 000 £0.00 £0.00 ‘£0.00 £100.00
Remittance Out (Forex) Total £100.00 £0.00 £0.00 0.00000 £100.00
Losses to Suspense £0.00 £0.00 £000 -£0.00_—*£0.00 £0.00
Transters Out to other SUS £7,000 00 £000 £0.00 £0.00 £0.00 £7,000 00
Cash on Hand C Fed $3000.00 £2500.00 4500.00 £6 60000 £8 600.00 £22 600.00
Other MOP C Fwd 20.00 £0.00 «£0.00 «0.00 «£0.00 £0.00
Forex C Fwd E7000 £60000 £50000 £400.00 £300.00 £2,500 00
(Other Postage C Fad £20000 £30000 £400.00 £100.00 £200.00 £7,200 00
Trading position (47) E0000 F000 £20000 «F000 £300.00 20.00
Transters In from Local Suspense £000 £000 £0.00 £0.00 £300.00 £300.00"
Transfers Out to Suspense £700.00 £0.00 #20000 £0.00 £0.00 £300.00
Balance © Fad 000 £000 0.09 F000 £0.00 20.00
Transaction Comections Accepted a o a a i
Discrepancy adjustments 2000 5000) ED EOON FRU OO
Stock Name
hem 4
hem 2
Stock Holdihgs at End of Period 12
Volume
cy
I declare that this is a true representation of the position at my branch
Signed
“End of Report “™*
For readers with electronic copy of this document, the definition of the report, along with definitions of the contents of the fields within the
&
report, may be viewed more readily by viewing the attached file ...
3 March 2004
© Post Office™ 2004
Version 1.0
Page 112 of 133
Doc Ref: BIRMC&TM-001
Conceptual Design
COMMERCIAL IN
CONFIDENCE
Project:
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
20.2 Variance Report
Feltham Past Office
09:56:32 09/02/2008"
a aE eee
SUAR x $0.00 E00 F000
SUEB Eo £0.00 #209 £000
Succ £0.00 2000 000 £000
SJ00 £0.00 740.00 £00 x
Teal x 40-00 200 x
ee eee un sia
SJAa * £709.00 £20006
SEB £780.06, £200.00, 200-00,
SUC 2180-00, £500.00 $200.90, 0.00
SUCD £200.00 £190.00, #20000 x
Toral o F.£9¢ 00 I —¥* 198.00 ra
SAA (shared: x >I £70000 500.00, ~
‘SUEB (unshared) Fa1.00 F000 200.00 $200.00,
SUCE (shared) 2400.00 #45000, £503.00, 4250-00,
‘SUCO (unshared) £100.00, £200-00, £159.00 x
Total x x £1,660 00 I 200 60 x
D3e01 £100.00, 7 £250.00 £100.90,
Boot £180.00, 0. £200.00 £180.00,
D3: 05 £200.00 £350.00, £150.00, £200.90,
Dac Of £250.00, 400,00 409-00 725090
Doc OF 400-00, £450.00, $500.00, £200 90
SOS OE Sa RL
Local Suspense F000 £9.00) 140.00 £0.00 700 F000
‘Orne: Suspense 2100 00 2100.00 £0.00) £0.00 000 £000
i
Tosa EL F000 I I }
Humber Precossed 0 o 1 c 1 0
Hnber Gutata nding ° 1 z e a o
= End of Report
POL00038878
POL00038878
For readers with electronic copy of this document, the definition of the report, along with definitions of the contents of the fields within the report, may be viewed more readily by viewing the attached file ...
3 March 2004
© Post Office™ 2004
Version 1.0
Page 113 of 133
Doc Ref: BIRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.3 Transaction Corrections Report
Feltham Post Office FAD Hae Paget
09:55 32 09/03/2004% Transaction Correction Repe™Qffice Copy” ———__ TP: 12
™. ee
fected }Sattiement™\ usted “Nalloved —
Date Issued sessed Reference I Status I Product I Product Antoupt Qua Opt OSS Qescription ——
™ ——.
savaareoosII\\ 2arev2004 1123456 Made Good giroBank Wash = £35.76, text 35 pagsed by POLTS
\ ~ Tis may ge mumboORae—
~ Tire this ~ ee
rsowzonsI I\bors2004 £23385 Halship Shisn Gas [obeh ON toe a pagza ty PODS. —
This may go tea rumberot
chs So
19/03/2004 (34567 ‘Outstanding Royal Mail Lnpayd MG xt’ as passed by POL ™ ™.
heqes HS Thids to 9 numberof Tiros SN ae
EV Like thin S _ ~~
voinszzo04I \2bbavznea nss67e More y OL tetas oabaed BY POL FS
Like th
0103/2004 n2sazt—Outstarting Suit ir tosh 80. S0\. “Fayt an passed by BOXES.
\ Like thhs,
2103/2004 vhond 13485 Made Gobd E (118 ash 6 \ oot as pabued by POL FS
is may go Tb.@ number lines
\ Lika this _~
tend
Report 4 NN NN
~
[FC identer onerendty N\ ™~
Poreosorduen cae \ BEarRaaT
oar \
Freee He
Joe repesied on saci IOFfce Nore ftene tf retired (Represents a diferent] [Since this was resoived as
(axe Iasspense procact \
procuced to the Brench Accounts, The I [techteye woe Nene ofthese are ea
Cecmsrccrcedsrnnner I [erenteye eautnes —
Pcrstosrenescd Lecce ote
fetes
For readers with electronic copy of this document, the definition of the report may be viewed more readily by viewing the attached file ...
3 March 2004 Version 1.0 Page 114 of 133
© Post Office™ 2004
POL00038878
POL00038878
Pace Hirber
I this sorescoheet =
lreete, then toes
Increment, nonever we
idenaire sat does
Norcal”
FAD code
™ NN [Conectors
a
[Fie Soo hare ot hee
ext. We ereid ey and
word eran" as epprorate
larcuse asmany ines as are
needed
iy woes for Nan
Iascounieg Devs
Bi)
[Fodicl abe used setienertn
loca TC
fi aresnense other thar MC was
lsed, then eat ratbe he pcduct
lacuniy sett agarnst, Ths coud be
Icancedifrequred,
[again sud be a same rather thar &
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.4 Sales Report
The content within this report is unchanged by the IMPACT requirement though the period of reporting and thus the information provided at
the head of the report will be changed. The order in which things are presented is also likely to change as a result of the changes to the
accounting hierarchy resulting from the move to not holding stock by value. In particular Stamps will be split into different parts of the report.
1 2 3 4 Notes
123456789012345678901234567890123456789012
01 [Feltham Post Office FAD: 123456x
02 [11:42 17/01/1998 CAP:01 BP:01 SU:SH1 I CAP field should be replaced by
03 I Sales Report - Office Copy the date range for which the
04 report is produced.
05 VOLUME VALUE
06I Cash 293.11
07 I CASH 293.11
08I Cheque 3432.79
09 I CHEQUES 3432.79
10I Giro Txfer 47.97
11] GIRO TRANSFERS 47.97
12] Voucher 20.00
13 I VOUCHERS 20.00
14 I Mop 3793.87
15I Game Green 5 20.00
16I Game Blue 5 20.00
17 I GAME LICENCES 40.00
18I Col TV Fee 1 86.50
19 I coLOUR 86.50
20I Mono TV Fee 3 85.50
21} MONO 85.50
22 ITV FEE 172.00
23 Sw£tPkC3Euro 3 14.97
24 1st Class 12 3.12
25 2nd Class 11 2.20
26 Post Stamp 30.00
27I Env 1stClass 0.60
28 IntRepCoupon 4 2.40
29I Reqistrd RG1 2 7.28
30 I POSTAGE STAMPS ETC 60.49
31 Stbkvnd £1 2 2.00
32 I STAMP BOOKS-VENDING 2.00
33 Stpbk 1stx10 6 15.60
34 I STAMP BOOKS-OTHER 15.60
35 I POSTAGE 78.09
36I Gas Stamp £1 20 20.00
37I Active Life 12.00
38I MVL Stamp 5 25.00
39 TV Stamp 19 19.00
40I Water Stamp 2.00
41I BT Stamp £2 5 10.00
42 I MISCELLANEOUS 79.00
43 I Home Help A 16.50
44I Home Help D 25.00
45 I HOME HELP/CARE STPS 41.50
46 INON POSTAGE STAMPS 120.50
47 I OTHER PAYMENTS AA 2927.78
48 PO FgnEx Out 1 150.00
49I PO Foreign Exch Out 150.00
50 I BurChnge Pay 1 27.00
51 I BUREAU DE CHANGE OUT 27.00
52 Lwood Prize 1 100.00
53I NatLot Prize 1 10.00
54 I LOTTERY PAYMENTS 110.00
3 March 2004 Version 1.0 Page 115 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
55 I OTHER PAYMENTS 3354.78
56
57 *** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
20.5 Declaration: Stock on Hand — Stock Report
1 2 3 4 Notes
123456789012345678901234567890123456789012
01 I Chelsea PO FAD: 0040389
02 I 23:42 23/01/1998 CAP:52 BP:01 SU:SH1 CAP field should be replaced
by the trading period
identifier of the trading
period within which the
report is produced.
03 I Stock on Hand - Office Copy
04
05
06
07 I ---
08 I DESCRIPTION VOLUME AMOUNT
09
10I 1st Class [£0.26] 427 444.02
11 2nd Class [£0.19] 453 86.07
12 BT £5 Pc [£5.00] 50 250.00
13 PO £5 [£5.00] 50 250.00
14 I PO Fee £5 [£5.00] 32.50
15 PO £6 [£6.00] 10 60.00
16I PO Fee £6 [£6.00] 6-50
17 PO £7 [£7.00] 10 70.00
18I PO Fee £7 [£7.00] 6.50
19 PO £9 [£9.00] 20 180.00
20I PO Fee £9 [£9.00] 16-00
2A pn
22 I TOTAL 1020 1068.59
23
24 ***k END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
3 March 2004
© Post Office™ 2004
Version 1.0
Page 116 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.6 Counter Weekly Stock on Hand - Stock Report
1 2 3 4 Notes
123456789012345678901234567890123456789012
01 [Feltham Post Office FAD: 123456x
02 I 11:12 16/01/1998 CAP:01 BP:01 SU:SH1 I CAP field should be replaced
by the trading period
identifier of the trading
period within which the
report is produced.
03 I Stock On Hand - Office Copy
04
05 I VALUE STOCK &-MOP VOLUME VALUE This report will only
06 deal in stock and only
07 be 4293.44 in volume.
08 ASH. 4293-11
09 hee 4032.79 I Assume removal of MOP
10 HEQUE 4032.79 From this report.
11 iro Taf. 47-97
12 I -GERO-TRANSFERS——————__________47..97
13 I —v¥oueh 320-00
14 I -voucHER 320-00
15 I Mop $693.87
16] Comcoin 200.00
17I COIN SETS 200.00
18I Game Red 2 12.00
19] Game Occas 2 4-00
20I Game Dealers 2 8.00
21 I GAME LICENCES 32-00
22I Col TV Fee 1 86-50
23 I COLOUR 86-50
24 ITV FEE 86.50
25 FDE 100 26-00
26 Pres Pack 1500.00
27 I PHILATELIC ITEMS 1526.00
28 1st Class 18488 4806.88
29 2nd Class 18489 3697-88
30 I POSTAGE 36977 8504.76
31] Reg Plus PL2 100 400.00
32 SwftPkC3Euro 97 484.03 I Any items without a
33 SwiftpackLge 100 490.00 I volume will need to
34] Env 2ndClass 38.00 I show volume, but
35] Env istClass 45.49 I not value.
36 IntRepCoupon 57-60
37] Registrd RG1 98 352-80
38 I MISCELLANEOUS 1777.83 I Doesn’t make sense to.
39 have Misc. by volume
40 will need to list all
41 stock items
42 *** END OF REPORT ***
T 2 3 4
123456789012345678901234567890123456789012
3 March 2004 Version 1.0 Page 117 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.7 Stock Unit Balance: Snapshot
1 2 3 4 Notes
01
123456789012345678901234567890123456789012
Feltham Post Office FAD: 123456X
11:09 01/10/1998 CAP:01
Office Snapshot - Office Copy
******Discrepancies in this Account******
57.50 *
*Discrepancy OVER
*Discrepancy SHORT
*
*Nett discrepancy
*
*Excess Cash Removed
*Cash Shortage Made Good
*
*Nett Cash Adjustment
nn *
FEI IIIS IIIS IIIT ITI III I te
VALUE-STOCK-& MOP VOLUME VALUE
Cash 4293.11
CASH 4293.11
Cheque 4032.79
CHEQUE 4032.79
Giro Txfer 47.97
GIRO TRANSFERS 47.97
MOP 8373.87
200-00
CoIN-sETs——____________200.00
Red 2 12.00
~Game 2 4.00
~Game—Dealers 2 8-00
~Game—Keepe: 2 8-00
GAME-LICENGES 32.00
EDE. 100 00
_Pres Pack 150000
_Sw£tPkc3E 97
ist class _—________18488 _____4806.88
~2nd-Class—________15489________3697.80
—Swiftpackige—_______100________400..00
-Env—2ndClass 38.00
Eny_istcl 4549
—IntRepCoup: 9 5760
—D/Whsle—stmp. 316
Tek. 449 149-00
Nathotinstnt 49500
MISCELLANEOU: 10666-84
TOTAL STOCK—& MOP
CAP field should be
replaced by the trading
period identifier of the
trading period within which
the report is produced.
Note that these
figures do not relate
to transactions and
so are not visible
to POL FS
Value Stock will be
removed from here
NB Other Stamps
will stay here
(none in the example)
Also ForEx Stock
3 March 2004
© Post Office™ 2004
Version 1.0
Page 118 of 133
POL00038878
POL00038878
Doe Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
49
50
51
52 RECEIPTS VOLUME VALUE
53
54 I Balance B/Fwd 21172.45 INeed to add in at
55 this point all Stock
56 Transcash 1 50.00 I movement transactions
57 GIRO DEPS/TRANSCASH 50.00
58 D/post inland 1 25.00
59 I Parcels 25.00
60 CARRS - PARCELS 25.00
61 BT bill pymnt 1 86.32
62 TELEPHONE RECEIPTS 86.32
63 NS ord dep ac 1 200.00
64 NS DEPOSITS 200.00
65 MVL v10 1 155.00
66 I v10 Issued 155.00
67 I DVLA MVL v10 155.00
68 Moneygram send 1 90.00
69 I Moneygram Send 90.00
70 OTHER RECEIPTS 621.32
vB
72 Rem In Supp Div 00.00
73 Rem In Other Pos 00.00
74 Rem In Client 100.00
75 Rem In Auto Dist 883.04
76 REMITTANCES IN 983.04
77
78 I Reval Up 0.00
79
80 TOTAL RECEIPTS 22761.81
81
82
83 PAYMENTS ‘VOLUME VALUE
84
85 ©B chq to DPC 1 99.00
86 I Cheque 99.00
87 COB chque fee 1 5.00-
88 I Fee 5.00-
89 OTHER BANKS CHEQUES 94.00
90 Giro w/drwl 2 100.00
91 GIRO WITHDRAWALS 100.00
92 Debit Card 1 50.00
93 DEBIT CARDS 50.00
94 NS ord w/drwl ac 1 150.00
95 I NS Withdrawals 150.00
96 NS WITHDRAWALS/ PAYMENTS 150.00
97 C/dian money ord 1 80.00
98 I International Money Orders 80.00
99 Moneygram rec 1 300.00
100 I Moneygram Receive 300.00
101I Co-op esh chque 2 200.00
102 I Co-op Cash Cheques 200.00
103 I OTHER PAYMENTS 580.00
104 I Rem Out Supp Div 0.00
105 I Rem Out Other Pos 0.00
106 Rem Out Data Cen 50.00
107] Rem Out Client 10.00
108 I Rem Out Auto Dist 871.60
109 I REMITTANCES OUT 931.60
110
111 I Reval Down 0.00
3 March 2004
© Post Office™ 2004
Version 1.0
Page 119 of 133
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
112
113 I Total Stock & MoP 20798.71
114
115 I Nett discrepancies 57.50
116
Wf nnn nnn nn
118 I TOTAL PAYMENTS 22761.81
119
120
121 I Transfers In 0.00
122
123 I Transfers Out 0.00
124
125 I Balance C/Fwd 20798.71
126
127 *** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
20.8 Trial Balance Report & Final Balance Report (Stock Unit Balance: Report) & Office
Balance Snapshot
These reports are the same apart from the headings and the values below. Any value in the Nett Discrepancies lines at the trial
balance will, if nothing else is done, be adjusted to the Discrepancy Shortage Transferred or Discrepancy Excess Transferred lines as part
of moving from the Trial Blance to the Final Balance. The Office Balance snapshot will differ, in the detail at the top and bottom of the report
(for example it won't have the EXAMINATION bit at the bottom) and in the reporting of discrepancies and variances transferred, depending
upon the state of the stock unit at the time of producing the report.
1 2 3 4 Notes
123456789012345678901234567890123456789012
o1 Feltham Post Office FAD: 123456X
02 11:42 17/01/1998 CAP:01 BP:01 SU:SH1 CAP field should be
replaced by the trading
period identifier of the
trading period for which the
report is produced.
03 Trial Balance - Office Copy
04
05 ******Discrepancies in this Account******
06 *Discrepancy OVER 4643.96 *
07 *Discrepancy SHORT 506.84 *
08 *
09 *Nett discrepancy
10 *
*Excess Cash Removed 40.57 * Note that these
*Cash Shortage Made Good 113.78 * figures do not relate
See aaaa==== ial to transactions and
*Nett Cash Adjustment 73.21- * so are not visible
ane * to POL FS
THESIS ISIE ISIS IO ISI III IO IO IO III II
12
13 VALUE_STOCK—& MOP VOLUME VALUE Value Stock will be
14 removed from here
15 Cash 4293.11
16 CASH 4293.11 NB Other Stamps
17 Cheque 4032.79 will stay here
18 CHEQUES 4032.79 (none in the example)
19 Giro Txfer 47.97
20 GIRO TRANSFERS 47.97 Also ForEx Stock
3 March 2004 Version 1.0 Page 120 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
21 Voucher 320.00
22 VOUCHERS 320.00
23 MOP 8693.87
24 200-00
25 INSETS. 00-00
26 -Game-Red 2 12.00
27 4-00
28 —Game—Deal 2 8.00
29 Game Keepe: 2 8.00
30 GAME-LICENCES——_________2__________32.00
31 _EDE 100 26-00
32 BP Pack 1500-00
33 _D/Whsle_stmp 3.
34 Tok 149 449.00
35 —NatLetInstnt 495.50
36 MISCELLANEOU: 47.
37 —Bus_1_-Steck 422500
38 sTOCK-SHELL2-085——_______________1225.00
39 VALUE_ePocK-omHeR______1879. 66
90 ne
41 TOTAL stocks MOP 14283.69 I This total is not
92 tne adjusted here but
43 will be the total of
44 the value column.
45
46
47 RECEIPTS VOLUME VALUE
48
49 Balance B/Fwd 0.00
50
51 Transcash 1 50.00 INeed to add in at
52 PO Foreign Exch In 500.00 this point all Stock
53 OTHER RECEIPTS 6441.30 I movement transactions
54 Transfers In 0.00
55
56
57 Rem In Supp Div 0.00
58 Rem In Other Pos 0.00
59 Rem In Client 100.00
60 Rem In Auto Dist 41793.04
61 REMITTANCES IN 41893.04
62
63 Reval Up 0.00
0.00 I only on Final
Balance, may also be
on Office Snapshots.
CT ee
65 TOTAL RECEIPTS 48884.34
66 tne nnn nnn
67
68 PAYMENTS VOLUME VALUE
69
70 OB chq to DPC 1 99.00
71 Cheque 99.00
72 COB chque fee 1 5.00-
73° Fee 5.00-
74 OTHER BANKS CHEQUES 94.00
75 NatLot Prize 1 10.00
76 LOTTERY PAYMENTS 160.00
77 OTHER PAYMENTS 3484.78
78 Transfers Out 0.00
79
3 March 2004 Version 1.0 Page 121 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
80 Rem Out Supp Div 0.00
81 Rem Out Other Pos 0.00
82 Rem Out Data Cen 50.00
83 Rem Out Client 8530.16
84 Rem Out Auto Dist 13351.50
85 REMITTANCES OUT 21931.66
86
87 Reval Down 0.00
0.00 J only on Final
Balance, may also be
on Office Snapshots.
88
89 Total Steck—s MoP 14283.69
90
91 4137.12- I Must be zero on Final
92 Balance
98 ten
94 TOTAL PAYMENTS 39954.13
95 een nnn
96
97 I Balance C/Fwd 14283.69
STOCK Volumes VOLUME VALUE
Comcoin 200-00
COIN SETS 200.00
Game Red 2 12.00
Game Occas 2 4-00
Game Dealers 2 8.00
Game Keeper 2 8.00
GAME LICENCES 2 32.00
FDE 100 26.00
Pres Pack 150000 I Some of these do not
D/Whsle Stmp 3-16 I have volumes here but
Gas Token 149 149.00 I should must in the
NatLotInstnt 495.50 I new report.
MISCELLANEOUS 647.66
Bus 1 Stock 1225-00
STOCK SHELL 2-085 1225.00
VALUE STOCK OTHER 1872.66 All stock will be
98 reported, “Other”
99 EXAMINATION stock does not make
100 Drawer examined and cash and stock found sense by volume
101 as shown in this summary
102 Datestamp
103 tonn nnn +
104 Signature... .....
105
106
107 Time
108
109
110 TRANSFER
111 Cash and stock in this summary have been
112 transferred to me
113 Datestamp
114 tennn--- +
115 Signature
116
117
118 Time : :
119
3 March 2004
© Post Office™ 2004
Version 1.0
Page 122 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
120
121 *** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
3 March 2004 Version 1.0 Page 123 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.9 Remittance In Slip, Remittance Out Slip, Counter Weekly Remittances In, Counter
Weekly Remittances Out and Counter Weekly Remittances Summary
1 2 3 4 Notes
123456789012345678901234567890123456789012
o1 Feltham Post Office FAD: 123456xX
02 11:42 17/01/1998 CAP:01 BP:01 SU:SH1 CAP field should be
replaced by the trading
period identifier of the
trading period within which
the report is produced.
03 I Weekly Remittances In - Office Copy
05 I SESSION: 1-15578-1
06 I DATE:10:44 17/01/1998
07 I SOURCE:Rem In Auto Dist
08
09 PRODUCT VOLUME VALUE Assume that all stock
10 IBuro TChq 1 0.00 REMs will only deal
11 I 250 in volume, even
12 IPo £20 25 500-00 value indicated
13 I PO Fee 50p 25 6.25 Stamps.
14 ICol TV Fee 10 865.00 Forex will
15 IHome Help D 25 143075 show value as well as
16 I BT stamp £2 1000 2000.00 volume
17 I ------- 2-222-222-2222 2-22-22 n nen
18 I TOTAL 1086 3515.00
19
20
21 I SESSION: 1-15639-1
22 I DATE:11:18 17/01/1998
23 I SOURCE:Rem In Auto Dist
24
25 PRODUCT VOLUME VALUE Cash REMs have no
26 ICash 4 5000.00 volume
27 I Gas—Stamp-£1—________39 30.00
28 A 10 0-00
29 I Game-Red. 2 12,00
30 I ---------------------------------------
31 I TOTAL 43- 5000.00
32 Any cheque and
dockets REMs will
also need to go onto
this report
33
34 *** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
20.100ffice Daily Remittances In, Office Daily Remittances Out, Office Weekly
Remittances In and Office Weekly Remittances Out
These reports summarise and reflect the various counter reports as described in the previous section. However the Office reports are A4
and are summaries of the totals, not detailed by product. As shown in the previous Section the totals will be totals of volume for stock
remittances, volume and value for Foreign Exchange remittances and value for Cash remittances.
The CAP field, at the tops of thee reports should be replaced by the trading period identifier of the trading period within which the report is
produced.
3 March 2004 Version 1.0 Page 124 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
20.11Transfer In Slip, Transfer Out Slip, Counter Weekly Transfers In & Counter Weekly
Transfers Out
Currently the transfer slips are different in that a Transfer Out contains a declaration that goods are received. This difference is to remain.
o1
02
20
21
1 2 3 4
123456789012345678901234567890123456789012
Notes
Feltham Post Office FAD: 123456X
11:42 17/01/1998 CAP:01 BP:01 SU:SH1
Transfer In Slip - Office Copy
SESSION: 1-21284-1
Source SU:AAA Dest SU:SH1
PRODUCT VOLUME VALUE
2nd Class 599 100.00
1st Class 699 156,00
Cash 1 600.00
Col TV Fee 125 10012,50
Mono TV Fee 22 627.00
Euro 150 9800
BT PC 50 60 300,00
BT PC 100 80 ——800-00
Game Blue 112 448.00
SESSION TOTAL 600.00
*** END OF REPORT ***
CAP field should be
replaced by the trading
period identifier of the
trading period within which
the report is produced.
Will need to report
stock solely by
volume not value.
Cash, ForEx and
Other Stamps by
volume and value
Total is now only
the total of entries
in the VALUE column
above. (i.e. cash,
FOREx and Other
Stamps transfers)
Note. Total may be
zero if transfer
only contains stock
items
1 2 3 4
123456789012345678901234567890123456789012
20.12Counter Weekly Transfer Summary
Content not changed but it should be noted that the VALUE column is now completed with Session Total value from the Transfer In/Out Slip
above which for stock only transfers may be zero.
01
02
Notes
1 2 3 4
123456789012345678901234567890123456789012
Feltham Post Office FAD: 123456X
11:52 17/01/2000 CAP:01 BP:01 SU:SH1
Transfers Summary - Office Copy
TRANSFERS IN
SESSION SRC DEST DATE TIME VALUE
1-58498-1
SH3 SH1 17-Jan 11:36 58.00
CAP field should be replaced by
the trading period identifier of
the trading period for which the
report is produced,
3 March 2004
© Post Office™ 2004
Version 1.0
Page 125 of 133
Doe Ref: BTRMC&TN-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
1-58512-1
SU1 SH1 17-Jan 11:37 9.00
1-58290-1
SH2 SH1 17-Jan 11:55 16.95
TOTAL: 83.95
TRANSFERS OUT
SESSION SRC DEST DATE TIME VALUE
1-58551-1
SH1 SH4 17-Jan 11:38 48.00-
1-58565-1
SH1 SU2 17-Jan 11:40 22.20-
1-58585-1
SH1 SH3 17-Jan 11:45 4.11-
1-58599-1
SH1 SH2 17-Jan 11:50 24.00-
TOTAL: 98.31-
*** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
3 March 2004
© Post Office™ 2004
Version 1.0
Page 126 of 133
POL00038878
POL00038878
Doe Ref: BTRMC&TN-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.130 ffice Weekly Transfer Reconciliation & Office Weekly Unreconciled Transfers
Content not changed but it should be noted that the VALUE column is now completed with Session Total value from the Transfer In/Out Slip
above which for stock only transfers may be zero.
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
01 I Feltham Post Office FAD 123456x Page 1
02 I 23:56 19/04/1997 CAP 02 I CAP!
shoul
repla:
tradir
identi
tradir
for wi
repor
prodt
03 Transfer Reconciliation - Office Copy
04
05 I SESSION ID SRC DST BP DATE TIME MODE VALUE
06 I 1-20364-1 ccc AAA 02 19-Apr 22:55 TO 34.35-
07 UNRECONCILED Transfer Value: 34.35-
OB a a a a
09 I UNRECONCILED Transfer Value CCC to AAA 34.35-
WO penne
a
12 I SESSION ID SRC DST BP DATE TIME MODE VALUE
13 I 1-19285-1 ccc BBE 01 O08-Apr 20:38 TO 60.00-
14 I 1-19296-1 ccc BBB 01 08-Apr 20:39 ER 60.00
15 Transfer RECONCILED
a a a a a
17 I UNRECONCILED Transfer Value for CCC 34.35-
VB en
19
20 *** END OF REPORT ***
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
20.140ffice Daily Revalued Product List & Counter Daily Revaluation Session Slip
Since all stock items (which are subject to revaluation, other than Foreign Exchange which is subject to “continual” revaluation) are held by
volume there is only requirement to report which products are to have their price changed imminently. Assume that the Counter Daily
Revaluation Session Slip will be removed and that any functionality at the counter will allow the production of the Office Daily Revalued
Product List.
1 2 3 4
123456789012345678901234567890123456789012345
01 I 11:03:48 30/03/2000
02 I OFFICE CODE 123456x
03
04
05 REVALUED PRODUCTS LIST - Office Copy
06
07
08 I Product Old Price New Price From
09
10 I Air/erd pck 4.00 4.45 31/03/2000
11 I Air/crd single 1.00 1.09 31/03/2000
12 I Reg del env rg2 4.00 31/03/2000
13
3 March 2004 Version 1.0 Page 127 of 133
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
POL00038878
POL00038878
IMPACT - Branch Trading Reporting,
Management and Control and Transaction
Management
*** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012345
3 March 2004
© Post Office™ 2004
Version 1.0
Page 128 of 133
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.15Event Logs
This table shows which Event types are printed on each type of Event Log. The following events have been added:
make good adjustments (including Excess Cash Removed and Cash Shortage Made Good),
™ doing the branch trading statement (actually replaces 41: Office CAP rolled),
= viewing/producing cash variance report (though this may be implemented using the generic “reports printed / previewed”
events (numbers 29 & 30))
™ giving reminders that there are outstanding transaction corrections.
Key: Y= yes.
123
24
125
26
27
28
‘User attached
‘Logoff Completed
‘Delete SU failed
Declaration Complete
‘Forced Logoff
Inactive Rollover ly YY
Failed
Inactive SU Rollover
Rollover Abandoned
x
~
Rollover Complete
IY
lY
IY
IY
SU Created IY
SU Deleted 1Y
Logon Completed IY Y Y
1Y
IY
IY
IY
IY
1Y
IY
i
<
Office Balance Failed
Delete SU failed
Delete SU failed
Declaration
Abandoned
Declaration Complete }Y IY IY
with Discrepancy
Position Locked
Position Unlocked
zpepey
zpepey
lY
ly
Unlock Failed IY
ly
iY
Report Confirmed Yy iY
3 March 2004 Version 1.0 Page 129 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
129 Report Printed ly YY YY
30 Report Previewed 1Y YY Y
31 Inactive Rollover YY IY
Failed
32 Discrep Committed IY YY Y
33 Balance Checks Y IY ly
Failed
134 Balance Checks Y jy ly
Failed
35 Deleted (was ly YY Y
Revaluation
abandoned)
40 Deleted (was Cash = /Y Y
Acc Created)
41 Deleted (was Office IY YY
CAP rolled)
42 Deleted (was Office IY Y
CAP Roll
Abandoned)
44 Office Balance Failed Y = IY
45 SU Balancing ly YY Y
46 Delete SU failed ly Y
52 Deleted (wasl] week IY YY
CA)
53 Deleted (was 2 week IY YY
CA)
54 Deleted (was 3 week IY YY
CA)
[New events below here
S55 Trading Statement 1Y YY
Created
56 Trading Statement 1Y YY
Period rolled
57 Trading Statement YY YY
Period Roll
Abandoned
58 Excess Cash Y IY IY
Removed
59 Cash Shortage Made IY YY Y
Good
3 March 2004 Version 1.0 Page 130 of 133
© Post Office™ 2004
Doc Ref:
BIRMC&TM-001
POL00038878
POL00038878
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
160
61
162
163
164
Cash Variance Report
Previewed
Cash Variance Report
Printed
Outstanding
Transaction
Correction Reminder
Displayed
Shared Stock Unit
Variance Check
Complete
Shared Stock Unit
Variance Check
Complete with
Discrepancy
1Y YY YY
ly YY Y
1Y Y
ly ry Y
1Y py Y
20.16Office Weekly Suspense Account
This will need changing to handle the changes to suspense accounts and to include the Local “suspense” account used to transfer variance
out o stock units to enable them to balance.
The CAP field, at the top of this report, should be replaced by the trading period identifier of the trading period for which the report is
produced.
20.17Return Advice Note
This will need changing since it includes stock values.
The CAP field, at the top of this report, should be replaced by the trading period identifier of the trading period for which the report is
produced.
20.18Reports proposed to be deleted.
The following reports are considered no longer necessary with these other changes and so are proposed to be deleted.
© Counter Weekly DVLA V10
© Counter Weekly DVLA V11
© Office Weekly Counters Revenue Schedule
© Declaration and Confirmation ~ Non-Value Stock
* Counter Daily Cash on Hand (there is a separate report for Cash Declaration which is nearly identical, and it is just the cash
Declaration report that we need to retain)
* Office Weekly Cash Flow(this is replaced by the Variance report)
BT - 057 I POL The following reports are no longer required and will be removed from the Horizon system:
I * Counter Weekly DVLA V10
I © Counter Weekly DVLA V1
I * Office Weekly Counters Revenue Schedule
I * Dectaration and Confirmation - Non-Value Stock
I * Counter Daily Cash on Hand (there is a separate report for Cash Declaration which is nearly identical,
I and tis just the cash Declaration report that we need to retain)
I * Office Weekly Cash Flow(this is replaced by the Variance report)
I I © Cash Account Trial
u Cash Account Final
3 March 2004 Version 1.0 Page 131 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
20.190ther reporting considerations
Though remaining unchanged in content and structure there are many more reports for which consideration must be made in the
move from the weekly cash account to the monthly Trading Period accounting cycle.
Business procedures will be developed to identify which of these should be produced on what periodicity.
Itis recognised that those which re-produce transactions that have happened during the period will increase in size, when produced
for these longer periods. It is also recognised that the time taken to produce the reports, for these longer periods, will increase
whether they reproduce transaction details or summarise them.
A number of reports can be re-printed at a later time. It is required;that only reports that have previously been printed can be
teprinted; and that the reprint reports are identified by date and time previously printed. The following particular requirements are
identified for report re-prints:
« — For Stock Unit Balance Reports and Branch Trading Statements, the requirement is to be able to produce reprints for all
reports for Period N up until the rollover from Period N+1 to Period N+2
« — There is no need to reprint the Office Weekly Counters Revenue Schedule, since the original report has been removed
« — For the following reports:
Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA.
Office Weekly Redeemed Savings Stamps
Variance Report (new)
The requirement is that each of these is a weekly report and it is sufficient to be able to reprint any of these for which the
data is still available (ie the last 5 reports). In particular, this will ensure that all such reports for the current Branch
Trading Period can be reprinted if required.
«The Track and Trace Manifest, currently allows reprint of the last report produced. My understanding is that such a
report is normally produced daily, so no special consideration is required in terms of long term storage of the data for this
report.
« — Noother reports require reprints.
BT-060 Fujitsu Services tis required that only reports that have previously been printed can be reprinted; and that the reprint
reports are identified by date and time previously printed, The following particular requirements are
identified for report re-prints:
« — For Stock Unit Balance Reports and Branch Trading Statements, the requirement is to be
able to produce reprints for all reports for Period N up until the rollover from Period N+1 to
Period N+2
¢ There is no need to reprint the Office Weekly Counters Revenue Schedule, since the
original report has been removed
«For the following reports:
Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA
Office Weekly Redeemed Savings Stamps
Variance Report (new)
« — The requirement is that each of these is a weekly report and it is sufficient to be able to
reprint any of these for which the data is still available (ie the last 5 reports). In particular,
this will ensure that all such reports for the current Branch Trading Period can be reprinted
if required.
e — The Track and Trace Manifest, currently allows reprint of the last report produced. My.
understanding is that such a report is normally produced daily, so no special consideration
is required in terms of long term storage of the data for this report.
¢ _Noother reports require reprints.
Many reports, outside of those identified within this section, are headed with information regarding the CAP the report is printed for.
Analysis and definition is required as to what information is to be displayed at the top of these reports in place of the CAP
information. The working assumption is that the CAP field will be replaced with one of,
« — Arange of dates over which the report has been produced.
« — Atrading period identifier for which the report is produced.
¢ — Atrading period identifier within which the report is produced.
3 March 2004 Version 1.0 Page 132 of 133
© Post Office™ 2004
POL00038878
POL00038878
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and Transaction
COMMERCIAL IN CONFIDENCE Management
21 Appendix C - Simplification Work Requirements
This Appendix sets out the requirements for the Simplification Works, which will be implemented within Release(s) post Release $75.
Requirement Ref:
Description
Comment
fA]
Change APS to source transaction from TPS, by
enhancing the TPS Harvester and the TPS Host
Database. Transfer APS security (Digital
Signatures) to TPS, and enhance TPS to
generate Acknowledgements for Smart Card
transactions. Eliminate APS Harvester and
TPSI/APS reconciliation.
‘Simplification of system boundaries & step towards
establishment of single data source - consolidation
of these systems will reduce number of data flows
and amount of reconciliation, and reduce amount of
maintained documentation.
)
Enhance APS file generation for clients to operate
directly from transaction store rather than via
intermediate files.
Reduction in file handling/processing and data
storage.
{c]
Move SLA Reporting from Data Warehouse to
OMDB.
Step towards elimination of Data Warehouse.
(0)
Move NBS reports from Data Warehouse to TES
(Transaction Enquiry Service). (originally intended
to DRS, but TES now the strategic destination,
see below)
Step towards elimination of Data Warehouse.
(E]
Merge DRS into TES
‘Simplification of system boundaries & step towards
establishment of single data source - consolidation
of databases, reduction in managing data flows.
Benefits in code evolution & maintenance.
3 March 2004
© Post Office™ 2004
Version 1.0
Page 133 of 133