Branch Trading Reporting,
FUJ00089971
FUJ00089971
Management and Control and
Transaction Management
Conceptual Design
ROLE NAME AREA OF SIGNATURE Date
RESPONSIBILITY
AUTHORS DAVE PARNELL Business
PHIL BOARDMAN ARCHITECTURE
CONTRIBUTORS I JULIE POPE PRopucT
NIGEL STONE DEPLOYMENT
BEN GILDERSLEVE
JOHN DUTTON
SHEENA PATIENCE
TOM FITZGERALD
Tony UTTING
ALVIN WesT
ANNE CLARK
MARTIN DRAKE
KAREN HILLSDEN
PHILIP GODDEN
HELEN PEDLEY
CHRIS ALLEN
BoB GURNEY
GARETH JENKINS
TECHNICAL
ARCHITECTURE
BDA Sicn-oFF I SUE HARDING Business
(PEER REVIEWER) ARCHITECTURE
TDA SicN-oFF I CLive READ TECHNICAL
(PEER REVIEWER) ARCHITECTURE
DELIVERY GRAEME SEEDALL PROJECT
MANAGER DELIVERY
3 March 2004 Version 1.0 Page 1 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
Table of Contents
1 Document Control
Document Information.
Document History.
Change Process.
Changes in this Version.
Associated Documents.
Abbreviations/Definitions.
Background,
2.4 Document Explanation:
2.4.1 Creation Process...
2.4.2 Business Process Models..
3 Overview...
3.1 Business Proposition.
3.1.1. Accounting, Reconciliation and Settlement, including Debt Recovery and Branch Control!
3.2 Functional Summary....
3.2.1 Overview...
3.3. Systems summary.
3.4 Potential for Change.
4 Constraints.
4.1 Business & Functional
4.2 Legal & Regulatory.
4.3. Architectural Framework & Building Blocks.
4.3.4 Integration with Other Systems..
4.3.2 Post Office™ Strategic Direction.
4.3.3 Post Office™ Approved Technology.
4.3.4 Post Office™ Approved Components..
44 Fujitsu Services.
4.5 Prism Alliance.
4.6 Other Constraint
5 Design Principles...
6 Functional Requirements..
6.1 Overview — Local Verification.
6.2 Overview — Other Data Capture.
6.3 Overview — Produce Reports...
6.4 Overview — Daily Trading.....
6.5 I Overview — Produce Branch Accounts.
6.6 Overview — Stock Control...
6.7 Overview — Discrepancy Management.
6.8 Overview — Transaction Management.
7 Exclusions...
8 High Level Process Models..
8.1 A4 Accounts and Settlement.
A4.1 Create / Verify Branch Trading Statement
A4.1.1 Local Verification...
A4.1.2 Produce Reports and Informatior
A4.1.2.3 Produce Sales Report to Assist Remuneration Chec!
A4.1.3 Other Data Capture...
A4.1.5 Discrepancy Management.
A4.1.5.1 Receive Automated Messagt
A4.1.5.2 Handle Transaction Correction.
A4.1.6 Compare Generated with Actual Cash Positiot
92 9 60 Co Go Go G9 G ~
CoNoneRwns
8.1.10 A4.1.6.1 Compare Generated with Actual Cash Held for Stock Unit. =
8.1.11 A4.1.6.2 Create Variance Report ... Compare Generated with Actual Cash Held Across Branch.. 35
8.1.12 A4.1.6.3 Make Good or Hold Any Cash Variance... 3
8.1.13 A4.1.7 Produce Branch Accounts...
3 March 2004 Version 1.0 Page 2 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
A4.1.7.1 Make Good any Outstanding Variances.
A4.1.7.2 Stock Checking...
A4.1.7.5 Produce and Confirm Trading Statement.
A4.1.7.5.2 Confirm Trading Statement
8.2 A4.3 Summarise Transaction Data.
9 Information Flows......
9.1.1 Transaction Date
Cheque and Voucher Values.
Adjustment Transactions
Summaries...
Despatched Dockets.
Transaction Correction:
Trial Balance Report.
Final Balance Report...
Branch Trading Statement.
Trading Statement Confirmation Even
Sales Report to Assist Remuneration Check.
Non Accounting Dat
Bulk Data...
Additional Client Data.
Stock Unit Cash Declarations.
Cash Variances....
Stock Revaluation Information...
Cash Centre Financial Transaction Data.
Ledger Entry Information (Horizon Outlets
Ledger Entry Information (Cash Centres)
Explicit Transactions.
Explicit Cash Centre Transactions..
Summaries for SAPHR..
Card Account Enlivenment:
Client Transaction Summary (CTS).
26 —_ User Events Log
1.27 Variances Report..
9.1.28 Authorisation Discrepancies Report
10 Business Processes..
10.1 Main Business Processes.
10.1.1 Local Verification...
10.1.2 Produce Reports and Information.
10.1.3 Other Data Capture......
10.1.4 Discrepancy Management..
10.1.5 Compare Generated with Actual Cash Po:
10.1.6 Produce Branch Accounts.
10.1.7 Summarise Transaction Data.
10.2 Business Data...
10.2.1 Business Data Model
10.2.2 Reference Data Sources...
10.2.3 On-ine Transaction Data (Authorisation/Messages etc).
10.2.4 Transaction Dat
10.3 User Interface:
10.4 Reconciliation.
10.5 Audit.
10.6 Accounting Requirement:
10.6.1 Settlement
10.6.2 Invoicing.
10.7
10.7.1 Post Office™.
10.7.2 N/ASupplier.
10.7.3 N/AClient.
11 Non-Functional Requirements.
11.1 Volumetirics.....
41.2 Sizing Assumption
11.3. Service Levels...
11.3.1 Post Office™.
41.4 Problem Management & Tracking
11.4.1 Incident Management.
© © ~~
1.1
1.1
1.1
1.
Roan
ARONISGCHBIVBZARONIS
3 March 2004 Version 1.0 Page 3 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
11.4.2 Branch Support.
11.4.3 Client Support.
11.4.4 Failure Recovery.
11.4.5 Backup & Recovery..
11.5 Business Continuity.
11.6 Training...
11.7 Change Specific Non-Functional Requirements Required.
12 Technical Requirements...
12.1 Architecture Principles.
oO
o
oO
©
Communications.
12.2 Architecture Building Blocks.
12.3 Architecture Components.
12.4 Integration & Interfaces.
13. Security Requirements.
13.1 Security Policy.
13.2 Physical Secu
13.3 Technical Security.
13.4 Implementation & Development Security.
13.5 Security Management.
13.6 Security Testing...
14 Deliverables / Work Package:
14.1 Post Office™..
14.2 Fujitsu Services.
14.2.1 Development.
14.2.2 End to End Integration, Testing and Acceptance:
14.2.3 Managed Service..
14.2.4 Documentation.
14.2.5 Internal Processes & Procedures.
14.3 Prism...
14.3.1 High Level Solutions Desig
14.3.2 Internal Processes & Procedures.
144 AlSs......
14.5 Reference Data Change:
15 Planning...
15.1 Timescales.
15.2 Dependencies.
16 Acceptance.
17 Testing.
Ani Testing Statement.
Internal Functional Testing.
Non Functional Testing..
Interface Testing.
E2E Integration Testing..
E2E Functional Testing.
Pre-Pilot...
18 Implementation & Migration.
18.1 Migration Principle:
18.1.1 Migration Timeline.
18.2 Migration Requirement:
19 Appendix A — Requirements Catalogu
20 Appendix B — Reports.
20.1 Branch Trading Statement.
20.1.1 Specificatio
20.1.2 Example
20.1.3 Example
20.2 Variance Report.
20.2.1 Specificatior
20.2.2 Example wk 1
20.2.3 Example wk 2.
20.3 Sales Repott.....
20.4 Declaration: Stock on Hand — Stock Repot
@
@ @
©
oo o
DAROGBNNNONN 2325656660009 H 0H 0H OOONININNNGDDXDODODOOOS
3 March 2004 Version 1.0 Page 4 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
20.5 Counter Weekly Stock on Hand - Stock Report.
20.6 Stock Unit Balance: Snapshot...
20.7 i i
20.8
Out and Counter Weekly Remittances Summary.
20.9 Office Daily Remittances In, Office e Daily Remittances Out, Office Weekly Remittances In and Office
Weekly Remittances Out..
20.10 Docket Rem Out Report.
20.11. Transfer In Slip, Transfer
20.12 Counter Weekly Transfer Summary...
20.13 Office Weekly Transfer Reconciliation & Office Weekly Unreconciled Transfers.
20.14 Office Daily Revalued Product List & Counter Daily Revaluation Session Slip..
20.15 Event Logs..
20.16 Office Weekly Suspense Account
20.17 Return Advice Note...
20.18 Reports proposed to be deleted.
20.19 Other reporting consideration:
3 March 2004 Version 1.0 Page 5 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
1 Document Control
1.1 Document Information
Horizon Release No:
S80
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: I Graeme Seedall ; David Parnell
Supplier Distribution:
Gareth Jenkins; Bill Reynolds (Fujitsu)
1.2 Document History
Table 1: Document Information
Version. Date. Reason for Issue. Associated
WP / CT Nos
0.1 11/12/03 Draft for discussion
0.2 30/1/04 For review by workshops attendees
0.3 17/2/04 Containing feedback/comments from workshops
attendees
1.0 3/3/2004 Submitted for formal review
44
1.2
2.0
etc
Table 2: Document History
3 March 2004
© Post Office™ 2004
Version 1.0 Page 6 of 120
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction 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
Version Changes
041 « None, First draft template.
0.2 * — Second Draft, updated with output from requirements workshops of Jan 04
1.0 Final review with Design Authority
.
.
1.5 Key Contacts
Table 3: Changes in this Version
Name
Position
Phone Number
David Parnell
Gareth Jenkins
Business Process Architect
Applications TDA
Table 4: Key Contacts
3 March 2004
© Post Office™ 2004
Version 1.0
Page 7 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
1.6 Review Details
Review Comments to:
Dave Parnell ” GRO i
Mandatory Review Authority Name
Post Office Ltd:
Design Authority
Programme Manager
Technical Design Authority
Business Design Authority
Product Deployment
Business Change
Release Manager
Clive Read
Sue Harding
David Parnell, Chris Allen
Ben Gildersleve, Ann Clarke, Julie Pope
Graeme Seedall
Fujitsu RASD
Gareth Jenkins
Fujitsu Project Manager
Bill Reynolds
Optional Review/Issued for Information
POL
Ruth Holleran Rod Ismay,Ann Cruttenden, Tony Marsh, Vicky Noble,
Shaun Delaney, Jacky Mackenzie, Tony Utting, Sheena Patience, John
Dutton Alvin West,
Table 5: Review Details
1.7 Associated Documents
CS/OLA/038. 4.0
Reference I Version Date I Title Source
CR/CDE/006 3.2 07/07/03 I E2E Programme Conceptual Design
17/02/03 I Operational Level Agreement for LFS.
Service Level Agreement for LFS.
PO Ltd IS Security approach
Table 6: Associated Documents
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 8 of 120
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
1.8 Abbreviations/Definitions
Abbreviation Definition
AIS Application Interface Specification
cLs Cash Logistics (formerly CH&D - Cash Handling & Distribution)
EPOSS Electronic Point of Sale Service
FAD Financial Accounts Division (FAD Code)
LFS Logistics Feeder Service
OLA Operational Level Agreement
ONCH Overnight Cash Holding
SAPADS. SAP Advanced Distribution System
SLA Service Level Agreement
TIs Technical Interface Specification
TPS Transaction Processing Service
Other generic IT terms can be looked up at: http://www.whatis.com/
Table 7: Abbreviations/Definitions
3 March 2004
© Post Office™ 2004
Version 1.0
Page 9 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction 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
The Requirement Analysis Stage for Release 3 of the IMPACT Programme has been partitioned to
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 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 10 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
2.4 Document Explanations
2.4.1 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.
2.4.2 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 [IDEFO]
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 are 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 eg. 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: -
3 March 2004 Version 1.0 Page 11 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
222-xxx - where ??7? is a fixed label corresponding to the project and xxx is the requirement number,
starting at 001.
3 March 2004
© Post Office™ 2004
Version 1.0
Page 12 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction 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 copied as 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 MI
Responding to client/branch enquiries conceming transaction data (Enquiries to allow response)
Accounting at branches
Branch control
Recovering debt from branches, clients etc (inc non-transaction) debt
ecee
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
e@ Re-focus on Debt Recovery (financial recovery of money), target 95%
© Only 10% of discrepancies are actually debt
e 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.
——________e___ Enable proper accounting of cash and stock
3 March 2004 Version 1.0 Page 13 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Conceptual Design
COMMERCIAL IN CONFIDENCE
Improve timing, accuracy, granularity and summarisation levels.
Avoidance of losses from remittances and client settlement
Accounting and settlement on our data, not clients
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
The following depicts the high level processes and information flows between these processes.
Management intrmatin
‘Retersce Data] Stock Revavation information
Mangere
Preset Change info
at
Reference Data & Busness Rules
cath CenreTraneacton Data
“rasng Debt
oun a I_POL Business Ledger (ES-FS,
Debt Recovery Amounts Tug Payrot
Cheques Processed.
‘Streamine Settements
(bat Transacton Data Repor,
Branch Labi Statement.
Settlement Payment to Cie
Customer Requirements Sal
Erauies Payment Request fo Clnt
GISALPHISTRTNBRE og
io Cash Centre Financial Transaction Data_» 1 Mandate 7
ae ‘ ae
‘Stock Usages Through Transaqtions A Seasonal Data
Stock Transat infomation ec franck Ea I tnvestnents 8 soronnas 5
I cash Poi FaangsPertoranes Oa
— Caton fouceee I
_—_ a r I
Stock Recs / E I
eo Reauiement Kawase 4
Prodi Maing Knope Sock Despaehes. rs
fhe le
3
Cash and Near Cash Usages Through Transactions
Vouchers Despatches
Cheque and Voucher Vales
$n cheaues ana Yuan aah
Centesens Cheques Despatched
tome Transat
‘Seasonal ala K Cash Onsattesy
Diartina Frese
Som 31 Gosh Osspacbedio Francia insta y
1 Management Repo. 7
Non Soneance Repos
Fa Cash Flow & Holdings Performance Data
nd
a8 Forecast Peformance Repos
3.2.1. 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:
1. 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.
2. 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).
3 March 2004 Version 1.0 Page 14 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
As indicated in principle 2 above, the branch trading period should be 4 weeks. 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.
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:
Q_ The Horizon generated cash position
Q_ 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.
At the end of each branch trading period (which will end on a Wednesday mid-month (on a 4-4-5 week basis),
local branch management should be required to produce a Branch Trading Statement that will be comprised of:
Q~ asimple summary of business aligned to the trading period that is expected to be printed on one
A4 sheet of paper
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 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.
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.
It is 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.
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.
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.
. 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 remmed in and out.
. 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
Q = Astock declaration
3 March 2004 Version 1.0 Page 15 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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.
Suspense values can be cleared in several ways, namely through:
Q Cash 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 subpostmaster to pay via salary or credit card (handled via Transaction
Corrections)
Q DMB reverse suspense item to clear value 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 additional
automation support.
3 March 2004 Version 1.0 Page 16 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00089971
FUJ00089971
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 ee
IClient Syst HRS Tafocmaton
Clients = (SAP/HR)
Counter Transaction ne
Application Management Ny Ses
ae ib Management
Cash
Reference ‘Management
Data (SAP/ADS)
3.4 Potential for Change
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
© Post Office™ 2004
Version 1.0
Page 17 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
4 Constraints
The requirements throughout this document are generic to all suppliers unless stated otherwise.
Gaps in the requirement numbers represent requirements that have been removed, and the numbering has
been retained for clarity.
4.1 Business & Functional
BT- I Fujitsu Production of a balance report for a stock unit must be possible 1
001 I Services a . a
I to be produced within 4 times the current production time for a
stock unit with a busy transaction profile, long trading statement
period
BT- I Fujitsu Functionality not specifically identified to be changed within this 1
002 I Services . .
I document must not be affected to degrade the existing service
I provided by the Horizon system.
BT- I POL, Fujitsu Migration to POL-FS must occur at the end of a financial period. 4
003 I Services,
I PRISM
4.2 Legal & Regulatory
BT- I POL It will be verified that branch processes and reporting changes 2
004 I meet legal and regulatory financial reporting constraints (e.g.
I auditors) to ensure that there is sufficient information from the
I 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
4.3.2 Post Office™ Strategic Direction
No Specific Requirements
4.3.3. Post Office™ Approved Technology
No Specific Requirements
4.3.4 Post Office™ Approved Components
No Specific Requirements
4.4 Fujitsu Services
4.5 Prism Alliance
3 March 2004 Version 1.0 Page 18 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
BT- I POL oO
005 I
4.6 Other Constraints
No Specific Requirements
: PRISM defined requirements regarding migration to POL-
FS to be defined here.}
3 March 2004
© Post Office™ 2004
Version 1.0
Page 19 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction 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.3.1 of this document.
3 March 2004 Version 1.0 Page 20 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
6 Functional Requirements
In order to analyse and assess the functional requirements across the scope of this project the following areas were
identified and analysed separately, initially, and then as a whole. The findings of the overall study are summarised
here by these area groupings for ease of reading.
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 that the data is as accurate as possible
to perform range checks on reported data, at a summary or sample level, to highlight areas for further
investigation and potential corrective action
* to reconcile 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.
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.
A review 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.
MacDonaldD2 Sounds as though this requirement will be met by tightening existing capability and is not really within
the scope of Impact. If this is so, suggest it is removed from the CD for clarity.
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.
MacDonaldD2 Again out of scope so suggest removing
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,
3 March 2004 Version 1.0 Page 21 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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.
MacDonaldD2 Needs to be confined to whatever is deemed in scope for Impact
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).
eo eee
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,
mid-month, 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).
3 March 2004 Version 1.0 Page 22 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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.
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 (rem 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.
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 branch managers 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.
3 March 2004 Version 1.0 Page 23 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
7 Exclusions
A number 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
It is 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.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 24 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8 High Level Process Models
8.1 A4 Accounts and Settlement
Loser ney nemo
3 March 2004 Version 1.0 Page 25 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.1 A4.1 Create / Verify Branch Trading Statement
Cheque and Voucher Values Aoduce: ‘Summaries
>} Reports and
Transaction Data Local Transaction Data nrcvatn; [cosbatched Dockets
Verification >) :
1 A412
Aa
Other Data
Capture
3
A413 Pore
a Generated with Adjustment Transactions
Adjustment Transactions Actual Cash >
Position
De 6
crepancy Ad16
Transaction Corrections Management
> Outstanding Transaction
5 Corrections
A415 Produce
Branch
Accounts
7 Branch Trading Statement
A417
Version 1.0 Page 26 of 120
3 March 2004
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.2 A4.1.1 Local Veri
ation
PerformRange
Checks -
>I Periodic
Transaction Data
1
4.4.1.4
Mi
PerformRange
Checks -Transaction
Transaction Data
SUE pp»
.. Validate Data
Captured
2
A41.1.2
Horizon Sales
Automated
Reconeilation Authorisation Discrepancies Reports
= I —Aaihorsaton Ds crepances
4.1.1.3
3 March 2004 Version 1.0 Page 27 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.3. A4.1.2 Produce Reports and Inform:
Cheque and Voucher Values
ation
Froduce Daily
‘Summaries ‘Summaries
Transaction Data
A424
‘Summaries
Produce
Periodic
Verify
Sunmeres ‘Surmaries
A41.24
‘Sumraries
A41.2.2
Produce Sales
Report to Assist
‘Sales Report to Assist Remuneration Check
Remuneration
Check
3
A412.3
Despatch
Redeerred Dockets Despatched Dockets
A125
Produce Other
Horizon _I_User Events Log
Reports
A4126
3 March 2004 Version 1.0 Page 28 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
8.1.4 A4.1.2.3 Produce Sales Report to Assist Remuneration Check
Decide to Revew
Tee
Remuneration Ys “weet to 0
range?
Forizen Sem
DispiayEror
No Message
‘Sales Report Display Sales: ‘report generat Produce Sates End
rengerequestes?
3 March 2004 Version 1.0 Page 29 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.5 A4.1.3 Other Data Capture
input Non
Non Accounting Data Asean
Data
1
A41.3.1
Bulk Data input Bulk Data
>
2)
A41.3.2
i Input
Additional Gent Data naar
>) Client Data Transaction Data
3]
A4.1.3.3
3 March 2004 Version 1.0 Page 30 of 120
© 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.6 A4.1.5 Discrepancy Management
. Receive
Transaction Corrections peel
Message
1
A415.1
Tae Outstanding Transaction Corrections
Ulex tel Adjustment Transactions
A415.2
3 March 2004 Version 1.0 Page 31 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.7 A4.1.5.1 Receive Automated Message
Toon User
Horizon System
Dsplay Transaction
Correction Recieved
Message
Transaction
Correction ind
Message Arrves inI
Branch
3 March 2004 Version 1.0 Page 32 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.8 4.1.5.2 Handle Transaction Correction
Ter
Deca oRedd Chase Chae crepe bil
Conestens overtone Cie correston Ont (ea ae Gon
Horton Stem
oo a SaRayDaaTT Cemetle Correct Resa ara
woceses
3 March 2004 Version 1.0 Page 33 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.9 A4.1.6 Compare Generated with Actual Cash Position
Compare
Transaction Data Generated w ith
Actual Cash Held
for Stock Unit
1
Make Good
A464 ‘Stock Unit Cash Declarations ine paN = Adjustmen Transactions
i
Cash Variances :
A41.63
Create Variance
Report ... Compare
Generated with Actual Variances Report
Cash Held Across
>I Branch
Outstanding Transaction Corrections 2I
A4.16.2
3 March 2004 Version 1.0 Page 34 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.10 A4.1.6.1 Compare Generated with Actual Cash Held for Stock Unit
3 March 2004 Version 1.0 Page 35 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.11 A4.1.6.2 Create Variance Report ... Compare Generated with Actual Cash Held Across Branch
User
No
Desk wReVeW
Coan DesaatosI
“Wane
prooe repo
war
les
Heinen
z a aa Tisayret a
cate rege? Message
Tosh Desa Coan Desiraion
RetewButen op) Revere
No Report >I
3 March 2004 Version 1.0 Page 36 of 120
© 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.12 A4.1.6.3 Make Good or Hold Any Cash Variance
Make Good Hold
Desi to Wks Go = SerAnoate I Deseo Held ay
cash Varace fora ve Mace Good ‘cash Varances
partcubr Seek nt
Lo
Fareen Sem
Now We Goad Upaate Cah
ston oclraton and ea
> “foe Cod
3 March 2004 Version 1.0 Page 37 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.13 A4.1.7 Produce Branch Accounts
g Statement Confirmation Event
3 March 2004 Version 1.0 Page 38 of 120
© 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 Make Good any Outstanding Variances
User
Make Good
Decide to Make Good Put Cashin Draw Fhier Ampunt ©
a Cash Variance for aI be Made Good
particular Stock Unt I >>} —>I a
Forzon System
New “Wake Good
Button
Update Cash
Declaration and
Record Amount
‘Made Good
3 March 2004
© Post Office™ 2004
Version 1.0
Page 39 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
8.1.15 A4.1.7.2 Stock Checking
Transaction Data Teal Seek
Check Stock
Held for Stock Adjustment Transactions
Unit 9
A4.1.7.2.2
Review Stock
Branch
A4.1.7.2.3
Rem In/Out
Stock
Stock Changes due to Remmittances:
A4A.7.2.1
3 March 2004 Version 1.0
© Post Office™ 2004
Page 40 of 120
FUJ00089971
FUJ00089971
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.16 A4.1.7.5 Produce and Confirm Trading Statement
Produce Trading
Verified Transaction Data seats man Reports Branch Trading Staterrent >
—__+I
1
A41.7.6.4
ConfirmTrading I Trading Statement Confirmation Event
Statement
>
2
A4.1.7.6.2
3 March 2004 Version 1.0 Page 41 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.1.17 A4.1.7.5.2 Confirm Trading Statement
yA Pr Bw
cence tse
“Som heed
3 March 2004 Version 1.0 Page 42 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
8.2 A4.3 Summarise Transaction Data
Cash Adjustments
Card Account Enlivenments
Cheque and Voucher Values
Stock Transaction Information
Adjustment Transactions
FUJ00089971
FUJ00089971
Explicit Transactions fog MIS
Other Data Feeds (to Clients)
Scan
Stock Revaluation Information Treneactone for Accumulate
Day Daily Transactions Tpersentone tel
Transaction Data Se
Branch Cash Holding :
i A432
A434
Transagtion Data and Summaries
Cash Centre Financial Transaction Data i i
Summarise EE Summaries for SAPHR
anode External Systems
Transactions a
Pouch Details (Bectronic)
Cash Centre Transaction Data
I Expicit Cash Centre Transactions
A433 Ledger Entry information
poo
4
A434
3 March 2004 Version 1.0 Page 43 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Conceptual Design
COMMERCIAL IN CONFIDENCE
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 —
(eg. bulk
Remittances) which have an impact on the position at the branch
both customer facing and non-customer facing input or
Logical data items
"Session ID
"Transaction ID
= UserID
= Stock Unit
= Trading Date
= Trading Period
= Date and Time
= Product ID
* Sale value
= Sale quantity
= Additional data items
= Remittances Information
* — Transfer Information
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 POL-FS, HR-SAP, Clients & 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 POL-FS & MI
9.1.3. Adjustment Transactions
3 March 2004
© Post Office™ 2004
Version 1.0 Page 44 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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 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 (eg. 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
3 March 2004
© Post Office™ 2004
Version 1.0 Page 45 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
Attribute Description
Description These are the physical dockets and the details of their contents which are
remitted 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
remmed out
Logical data items
= Header
= Product/client name
"FAD code/name
For each transaction:
= Transaction number
= Transaction additional data (eg. reference number)
= Value
Total value of transactions including physical dockets/vouchers.
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 MI
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)”).
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
3 March 2004
© Post Office™ 2004
Version 1.0 Page 46 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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.9 in Appendix B
Special requirements None
Time constraint None
Type of Object printed output
Source Horizon
Destination For retention in the Branch
I BT- I Fujitsu I A new trial balance report will be produced, the content andI 7
006 I Services
I format of which will be as specified in Appendix B
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.9 in Appendix B
Special requirements None
Time constraint None
Type of Object printed output
Source Horizon
Destination For retention in the Branch
BT- I Fujitsu The content and format of trial and final balance reports will be 1
007 I Services . .
I altered as specified in Appendix B
9.1.9 Branch Trading Statement
3 March 2004 Version 1.0 Page 47 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
Attribute Description
Description This is the report produced at the end of each month accounting period to
reflect the branch's trading position for that period.
Logical data items
See Appendix B (20.1 & 20.1.2)
Special requirements
None
Time constraint
Monthly
Type of Object
printed output
Source Horizon
Destination For retention in the Branch
BT- I Fujitsu A new trading statement report will be produced, the content 1
008 I Services a _ "
and format of which will be as specified in Appendix B
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 * FAD Code
° Date
« Time
« Trading Statement Completed Indicator
Special requirements None
Time constraint Monthly
Type of Object
Electronic record
9.1.11
Source Horizon
Destination MI
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 20.6)
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
3 March 2004
© Post Office™ 2004
Version 1.0 Page 48 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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 remuneration processes.
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.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.
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
3 March 2004 Version 1.0 Page 49 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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.
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
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 user:
e User ID
eStock Unit
«Trading Date
«Trading Period
« Date / Time
© Till ID (ifin a Shared Stock Unit)
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
3 March 2004 Version 1.0 Page 50 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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
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
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
3 March 2004 Version 1.0 Page 51 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
Attribute Description
Description Daily feed of Cash Centre summary and transaction details. The interface
already exists as a direct SAPADS to POLFS feed at Release 1 — Release 3
adds client related transaction data, and routes the interface via the TMS.
The file will contain all activity in cash centres that have a financial effect on
PO Ltd.
See SAPADS - POLFS AIS [Ref?] {DNiINeedireference}
MacDonaldD2 A data feed from SAPADS to TMS is not shown in the main
flow diagrams !!
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) Rem in/out data.
= NI Cheques remittances
Write offs and adjustments.
Special requirements
None
Time constraint
Target delivery time to TMS = 3.00am, daily.
Type of Object
Electronic Records
Source
SAP ADS
Destination
TMS then passed on to POL FS.
9.1.19 Ledger Entry Informat
ion (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
= REM in and out of cash/near cash and stock
= Adjustment/suspense item values
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.
MacDonaldD2 Will this product / material conversion be within POL FS or
within TMS ?
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 Informati
ion (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 MIS,
unchanged. For further information see that definition.
None
‘Special requirements
3 March 2004
© Post Office™ 2004
Version 1.0 Page 52 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001
COMMERCIAL IN CONFIDENCE
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Conceptual Design
9.1.21
9.1.22
9.1.23
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
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 items/file 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.
‘Special requirements
None
Time constraint
Must be available to the MIS by ??.??
{DN: Currently available by 03:00 (SLA) and usually before midnight (in
practice)}
Type of Object Electronic records
Source TMS
Destination MIS
Explicit Cash Centre Transactions
Attribute Description
Description Cash Centre transactions for external clients extracted from the SAPADS to
POLFS interface.
Logical data items
Transaction details (no summarisation — attributes to be determined).
‘Special requirements
None
Time constraint
Must be available to the MIS by 77.2?
{DN: Fujitsu pass data to MIS by 03:00, so if they only : pel this from SAP
ADS at 03:00 will miss that day's MIS feed. Is this acceptable?}
Type of Object
Electronic records
Source TMS
Destination MIS
Summaries for SAPHR
Attribute Description
Description Remuneration data for SAPHR, based on sales transactions carried out at
Horizon outlets.
Logical data items
For the period being processed (previous month)
Outlet
CTT
Product Grouping
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 —
SAPHR AIS.
MacDonaldD2 Does this mean that the required Reference Data will be
defined in this AIS ?
Special requirements
None
Time constraint
A single monthly interface. To be provided to SAPHR to an agreed timetable
(held in reference data (Fridays))
Type of Object
Electronic records, CSV file?
Source
TMS
Destination
SAPHR
3 March 2004
© Post Office™ 2004
Version 1.0 Page 53 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Conceptual Design
COMMERCIAL IN CONFIDENCE
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 3° 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
© Post Office™ 2004
Version 1.0 Page 54 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Conceptual Design
COMMERCIAL IN CONFIDENCE
9.1.26 User Events Log
Attribute
Description
Description
A report 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 Transaction Corrections
Special requirements
None
Time constraint
None
Type of Object
Physical Report
Source Horizon
Destination For retention in the Branch
BT- I Fujitsu A new variances report will be produced, the content and format 1
009 I Services
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 Report
3 March 2004
© Post Office™ 2004
Version 1.0 Page 55 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
Source Horizon
Destination Finance
10 Business Processes
10.1 Main Business Processes
10.1.1 Local Verification
1. Perform Transaction Checks — Periodic
2. Perform Range Checks — Transaction ... Validate Data Captured
3. Automated Reconciliation
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 I Product level analysis undertaken and limits defined at transaction level.
Conditions
Completion Reports produced.
Conditions
BT- I POL A review of which periodic checks are to be made, with which 2
010 parameters, on data within Management Information systems
must be made.
10.1.1.2 Perform Range Checks — Transaction ... Validate Data Captured (A4.1.1.2)
3 March 2004 Version 1.0 Page 56 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
Attribute Description
Description Uses reference data definitions to verify that data entered at the time of the
transaction is within pre-set tolerance. The majority of these tolerances are
defined by the client and are mandatory business rules (i.e. 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 range 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
MacDonaldD2 All the above checks are already done as part of the
transaction processing so where is the hole ? What other knowledge does
CBDB have to enable it to do tighter checks ?
Trigger An error message will be displayed when a mandatory business limit is
exceeded/not adhered to
Automation The Horizon system will check against parameter levels recorded within
NRDS and display an error message when a defined mandatory business
tule is exceeded/not adhered to.
As provided by current functionality within the Horizon system, though the
ranges specified within Reference Data may be tightened.
Frequency At a transaction level as frequently as the defined mandatory business rule
parameters are exceeded/not adhered to
Constraints None
Start up Product level analysis undertaken and limits defined at transaction level and
Conditions applied within NRDS.
Completion Correct data entered or transaction abandoned.
Conditions
BT- I POL A review of parameters, defined through reference data, for 233
011 I control and management of data entry at the counter, is to be I
I made. Any changes to reference data must be implemented I
I prior to removal of current CBDB range check processes.
10.1.1.3. Automated Reconciliation (A4.1.1.3)
3 March 2004 Version 1.0 Page 57 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
Attribute
Description
Description
This process entails 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 POL FS
¢ 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.
It is proposed that such reconciliation 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 (section 0 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 FI 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 it is.
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
3 March 2004
© Post Office™ 2004
Version 1.0 Page 58 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
corruption within the file is detected. Any failures of such control total
checks will result in the entire file being rejected.
Frequency
To match frequency of transfer of data files. Mostly nightly
Constraints
None
Start up Data transferred
Conditions
Completion Reconciliation reports produced
Conditions
10.1.2 Produce Reports and Information
PONS
Produce Daily Summaries
Produce Periodic Summaries
Produce Remuneration Checks
Verify Summaries
REM out and Despatch Redeemed Dockets/Vouchers
10.1.2.1 Produce Daily Summaries (A4.1.2.1)
Attribute Description
Description Produce daily summaries for those products for 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 more 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 Transactions completed
Conditions
Completion Summaries completed and despatched
Conditions
BT- I POL A revised end of day procedure will be defined, identifying which 2 I
012 I summaries must be produced at end of day. The buttons on the
I “Counter Daily” menu will be reviewed accordingly. The revised I
I list of items will be defined in reference data for display when the
I “End of Day” button is pressed on Horizon.
BT- I Fujitsu The methods for producing summaries (daily and periodic) will 1 I
013 I Services
allow production of summaries, to be printed and/or previewed
‘on screen and allow a cut-off. This is existing functionality which
will remain as is.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 59 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction 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 transaction stream to a client and/or for
which documentation must be passed on to subsequent processes, on some basis
other than daily.
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 more 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 these relevant summaries
Frequency minimum weekly
Constraints Based on client requirements.
Start up Transactions completed
Conditions
Completion Summaries completed and despatched
Conditions
BT- I POL A revised end of period (probably weekly) procedure will be 2
014 I defined, identifying which summaries must be produced at end
I of period. The revised list of items will be defined in reference
I data for display when the “End of Week” button is pressed on
I Horizon.
BT- I POL The list of summaries will be reviewed and classified as 2
015 I mandatory and optional. Business rules for content on optional
I summaries will be defined. As either:
I * Summary of transactions of type since last cut off,
I whether cut-off is in this trading period or last.
I « Summary of transactions of type since last cut off, if cut
I off in this trading period, but only summary of
I transaction transactions of type since start of trading
I period if last cut-off was in previous trading period
10.1.2.3 Produce Sales Report to Assist Remuneration Check (A4.1.2.3)
Attribute Description
Description The Sales Report is produced to support the postmaster in assessing whether his
pay invoice received from SAPHR 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
3 March 2004 Version 1.0 Page 60 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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 HR SAP 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 (or summaries)
Start up User wants to produce report.
Conditions
Completion Report produced
Conditions
BT- I Fujitsu Functionality to allow entry of date range on the of Sales Report 1 I
016 I Services
to be produced will be implemented within Horizon, the system I
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 data range. I
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 (eg. 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 Summaries produced which require verification
Conditions
Completion Summaries Verified
Conditions
3 March 2004
© Post Office™ 2004
Version 1.0 Page 61 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction 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 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
It is 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 form 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 Dockets to remit.
Conditions
Completion All dockets remitted
Conditions
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 User chooses to produce report
Conditions
Completion Report is produced.
Conditions
3 March 2004
© Post Office™ 2004
Version 1.0 Page 62 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
BT- I Fujitsu The methods for producing reports will allow the reports to be 1
017 I Services printed and/or previewed on screen. This is existing functionality
I which will remain as is.
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
As is 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 to simplify current processes and reduce requirements for capture
of data 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 I Non accounting data items to be defined and business process to be
Conditions defined and communicated
Completion Data entered.
Conditions
BT- I Fujitsu The functionality for entering non-accounting data will remain as 1
018 I Services is
BT- I POL Business procedures for entering non-accounting data, 2
o19 I identifying what data and when, will be produced.
10.1.3.2 Input Bulk Data (A4.1.3.2)
3 March 2004 Version 1.0 Page 63 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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
A review 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 Bulk Input data items to be defined and business process to be defined and
Conditions communicated
Completion Data entered.
Conditions
BT- I Fujitsu The functionality for entering bulk data will remain as is.
BT- I POL Business procedures for entering bulk data, identifying what data I
021 I I and when, willbe produced.
10.1.3.3 Input Additional Client Data (A4.
3 March 2004 Version 1.0 Page 64 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
Attribute
Description
Description
Enhance the transaction data stream with data required within the
transaction data for particular clients/products.
Additional client data in this context refers to the current
process whereby additional data fields relating to transactions,
that re 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:
e Removal of some of the current manual processes within the
branch
e 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 inifiated, trigger for additional data capture items
will be driven by parameters defined within NRDS
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
3 March 2004
© Post Office™ 2004
Version 1.0 Page 65 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
Start up = Relevant NRDS parameters will need to be defined and
Conditions 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 Transaction completed data entered
Conditions
BT- I POL The existing products will be reviewed for opportunities to 2
022 =I capture additional data at the point of sale, removing needs to
I manually record transaction data. The review will analyse, and if
I necessary, renegotiate client reporting requirements.
BT- I POL New and replacement products will be implemented using 2
023 I existing system capabilities.
10.1.4 Discrepancy Management
14. 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.
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 Next Logon following receipt of TC (and all subsequent logons until there are no
Conditions more Outstanding Transaction Corrections)
Completion When all Outstanding Transaction Corrections processed.
Conditions
[BT- I Fujitsu ———~*I A.user with the appropriate role will be informed, at log on, that. I _ 4
024 I Services 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 Accepting or Rejecting the Transaction Correction by
the branch
Trigger User Initiated
3 March 2004 Version 1.0 Page 66 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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.
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 I Message must have been received from POL-FS
Conditions
Completion Branch can’t balance until all Transaction Corrections have been processed.
Conditions
BT- I Fujitsu There will be a button for Transaction Correction Management 1
025 I Services 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.
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
I Correction the user will have up to three options — Each option,
I when selected, will perform an identified set of transactions,
I defined within the Transaction Correction. (which may include an
I 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
= 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. 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.
Frequency Daily — at the end of the day
3 March 2004 Version 1.0 Page 67 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
Constraints None
Start up I Each stock unit to make an actual cash declaration
Conditions
Completion Declaration of physical cash held made for the Stock Unit
Conditions
BT- I Fujitsu At the end of performing a cash declaration, in a shared stock 1
026 I Services unit, the system will enter, if the user chooses to, the cash
I discrepancies function to support the identification of any
I variance.
BT- I Fujitsu For a non-shared stock unit the functionality of declaring cash 1
027 _I Services will remain as is
BT- I Fujitsu Reminders for ONCH function to be performed at log on if not 1
028 I Services performed previous day will be removed and, instead, the
I system will remind users to perform cash declaration function if it
has not been performed on the previous day, but this may be
I declined. _
BT- I Fujitsu When the cash declaration has been made the figures for 1
029 I Services denominational split will be passed to SAP-ADS as if an ONCH
I declaration had been performed.
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.1.31. There will be an option to print this report.
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 I User requests Variance Report.
Conditions
Completion Variance Report produced.
Conditions
~BT- I Fujitsu A new function will be made available to provide the variance I
030 I Services 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
= __ for DMBs and Multiples can post to a central “Profit_& Loss” account
Trigger This is a user driven process following on from Compare Generated With Actual
Cash Held for Stock Unit
3 March 2004 Version 1.0 Page 68 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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 I Identified Variance within a Stock Unit
Conditions
Completion Variance “dealt” with.
Conditions
10.1.6 Produce Branch Accounts
Stock Checking
Make Good or Declare any Outstanding Losses
Produce Trial Balance
Investigate Balance Discrepancies
Produce Final Balance
Produce and Confirm Trading Statement
Roll Over Inactive Stock Units
Stock Revaluation (Stamps)
10.1.6.1 Make Good any Outstanding Losses (A4.1.7.1)
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.
A Branch 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
It is 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 Button to move variances to
Profit & Loss. (This is a new product /button and will operate like another
Suspense product.) For Make Good —
Multiples — Move to a new Suspense product where the funds will be recovered
3 March 2004
© Post Office™ 2004
Version 1.0 Page 69 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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 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)
c) 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;
) Unpaid Cheques;
) POL cheques.
) Write offs (button needed ? ... not expected to be);
f) MVL Car Hire companies (not thought to require additional front
end functionality due to low values involved); and
_ g) Robberies & Burglaries.
{DN: Above list of suspense product to be confirmed by 19 March 2004.)
The function to make entries into these remaining suspense products should be
C)
d
e)
altered so that it is only available to Managers in all branches. In Directly Managed
branches all users will be able to enter variances into the “Profit & Loss” suspense
product.
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 I Reference Data for suspense products will be provided by Post Office
Conditions
Completion No variances (ie discrepancies) in the SU when itis balanced.
Conditions
BT- I POL A review of vouchers remitted from the branch will identify 2 I
031 which dockets will need to be treated via which adjustment I
a products
BT- I Fujitsu Anew function for recording a “make good” action will be made 1 I
032 I Services
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 reported on variance
reports, balance reports and trading statements.
BT- I Fujitsu
033 _I Services
BT- I POL
034 I
BT- I POL
035 I
Access to the functionality to enter amount into suspense 1
A process for applying for hardship will be defined to allow a 2 I
branch manager to make alternative arrangements for when a I
variance cannot be made good immediately. Variances will be I
held whilst the application is processed. This may lead to an I
extended Trading Period. Approved hardship amounts will
appear as Transaction Corrections
Reference Data will be edited to limit the suspense accounts 2
available within branches to the limited “known errors’ set.
10.1.6.2 Stock Checking
« Rem In/Out Stock
3 March 2004
© Post Office™ 2004
Version 1.0 Page 70 of 120
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
« Local Stock Check Stock Held for Stock Unit
« Review Stock Held Across Branch
It should be noted that, there are consequences of the principle:
's 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 remmed in and
excluded.” , which have some far reaching implications. These are:
out and no product/stock will be
¢ 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 adjus'
stments 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 (e.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 required for stock
management and control purposes and this should be removed as part of this programme.
10.1.6.2.1Rem In/Out Stock (A4.1.7.2.1)
whenever stock is required to be remitted in or out
Attribute Description
Description This is the function to received 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
quantities he wants to rem out or the quantities he
All above is existing functionality.
cash — any changes to this and Travellers Cheque:
separate project.
Automation The user will be presented with a screen into which he keys, by product, the
to his branch The movement to be recorded for POL-FS.
Foreign Currency may be altered to be automatically Remitted In & Out as for
ie has received in the remittance
s to be implemented as part of a
Frequency Available at any time but likely to happen once a week
Constraints None
Start up I Stock REM delivered to branch or there are Stock items to be returned to stock
Conditions centre.
Completion NB This impacts the volume of Stock on hand immediately (unlike cash).
Conditions
10.1.6.2.2Local Stock Check Stock Held for Stock Unit (A4.1.7.2.2)
Attribute Description
Description This process allows for each stock unit to make a
with the system held position on a periodic basis.
which the branch declares its stock position at tradi
stock held by the stock unit with the actual volume
unit and declare any difference.
Each Stock Unit will be expected to compare the system generated volume of
Adjustments made to stock holdings through declarations and/or stock adjusting
will be reported separately from stock adjustments due to stock item sales.
comparison of their actual stock
It is also the mechanism by
ing statement time
of stock held within the stock
report adjusted to show just volume information) at
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
against the report. If there are any differences then the user will create an
ind physically check his stock
3 March 2004 Version 1.0
© Post Office™ 2004
Page 71 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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 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.
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 REMs delivered
but not REMmed in.
Start up User initiated when required. E.g. Any stock variances to be identified and
Conditions recorded, must be performed as part of Trading Statement processing.
Completion Stock report produced OR Stock declaration made.
Conditions
BT- I Fujitsu Adjustments in stock (whether identified via adjustments or 1 I
036 I Services stock declarations) should be adjusted at the adjustment price
I whenever defined in reference data.
10.1.6.2.3Review Stock Held Across Branch (A4.1.7.2.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 (which is probably OK). Report will
need to be amended to not reflect stock values.
Frequency Potentially weekly and definitely monthly- usually after stock unit comparisons
made.
Constraints None
Start up User initiated.
Conditions
Completion Office Snapshot Report produced.
Conditions
BT- I Fujitsu Report will be redefined without stock values as defined in 1 I
037 __I Services section 20.6 in Appendix B
10.1.6.3 Produce Trial Balance (A4.1.7.3)
3 March 2004 Version 1.0 Page 72 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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.
As is current process and functionality for balancing on the Horizon system.
Frequency Potentially daily, more likely weekly but definitely monthly.
Constraints None
Start up User initiated, must be performed as part of Trading Statement processing
Conditions
Completion Trial Balance Report produced
Conditions
10.1.6.4 Investigate Balance Discrepancies (A4.1.7.4)
Attribute Description
Description This is the mechanism by which a user may track back through transactions to
highlight where any discrepancies might exist.
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 User initiated.
Conditions
Completion Discrepancies Investigated
Conditions
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 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:
3 March 2004
© Post Office™ 2004
Version 1.0 Page 73 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
1. If it 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 (ie 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.
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 remmed 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 Dependant on whether this is the last Stock Unit to balance or not and whether
Conditions there are any discrepancies. See Automation for details.
Completion To produce the report and sign it for retention in the branch for two years.
Conditions
3 March 2004
© Post Office™ 2004
Version 1.0 Page 74 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
BT- I Fujitsu Anew check is to be introduced after producing the Trial Balance (ie 4
038 I Services when the “rollover” button is pressed prior to producing the Final Balance).
I This check will act as follows:
I 1. If it isn’t the last Stock Unit to rollover, the clerk will be advised
I that the Discrepancy is to be posted to a “local adjustments”
I account. They have the option of accepting or rejecting this
I action.
I a. Should they accept it, then a pair of transactions will be
I generated resulting in the Discrepancy being reduced to
I zero and a corresponding amount being put into a “local
I adjustments product’.
I b. Should they reject it, then the rollover is aborted and the
I clerk is free to do whatever they wish to balance the
I Stock Unit and will then need to balance the Stock Unit
I again at a later time.
I c. The “local adjustment” is not associated with any Stock
I Unit (as with a Suspense account). Items can be added
I to it by any clerk, but only as part of the Balancing
I Process. Managers / Supervisors will be able to move
I items from it into cash in their SU to be Made Good.
I 2. If this is the last Stock Unit to Rollover an additional check will be
I performed to ensure that the net total of transactions, within the
I Trading Period, in the “local adjustment” account has a net value
I of zero.
I 3. If this is the last Stock Unit to Rollover, then the user will be
I informed if the Stock Unit has a Discrepancy and that this must
I be resolved before the last Stock Unit can be rolled over.
I Local Adjustment will behave in a similar way to existing Suspense
I Account items, namely the values will not be associated with any Stock
I Unit, but is considered as part of the overall Branch balance.
BT - 039 I Fujitsu There is an existing report that shows the state of all suspense 1
I Services accounts and all Transactions associated with the suspense
I accounts during the Trading Period, indicating which Stock Unit
I carried out the Transaction. It is proposed that Local Adjustment
I transactions are included in this report as with any other
I Suspense transactions
BT - 040 I Fujitsu Horizon should be changed such that only Supervisors and 1
I Services Managers (etc) will be allowed to carry out Suspense
I Transactions. The only exception to this will be the automatic
I posting of Discrepancies to Local Adjustment.
10.1.6.6 Produce and Confirm Trading Statement (A4.1.7.6)
3 March 2004 Version 1.0 Page 75 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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. Eg. checking that all Stock Units have rolled over and produced a
Final Balance exist.
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, mid-month (on a 4-4-5 week basis) controlled by a
calendar (as with Cash Account).
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). Assume that this is still
required. Currently asked if want to produce Consolidated SU non-value stock
report — no longer relevant
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
Signed copy of report to be retained locally.
BT - 041 I Fujitsu
Services
The user will select the appropriate function which will display the
Trial Trading Statement (as per outlined report) and this may be I
printed. When the user is content to confirm the position he will I
be presented with a textual message which describes the liability I
and responsibility which the postmaster is accepting. If the I
postmaster accepts this the system will record this action, print I
the Final Trading Statement and commit an event which I
identifies that the agent has produced the Trading Statement I
and accepted liability for the trading position. I
BT - 042 I Fujitsu
A new trading statement report will be produced, the content 1 I
Services and format of which will be as specified in Section 20.1 in I
Appendix B I
BT - 043 I Fujitsu The confirmation event will be made available to the data 1 I
I Services warehouse to enable monitoring of who has and who hasn't I
I done a trading statement. The “confirmation transaction” will I
I not contain the constituent parts that make up the trading I
I position. I
BT - 044 I Fujitsu A facility for different branches to operate on a different 1 I
I Services (monthly, on a Wednesday, mid-month (on a 4-4-5 week basis)) I
I branch trading calendar, will be implemented, which branch is I
I operating to which calendar is to be defined by reference data. I
Set of calendars and which branches are to operate to which 1
BT - 045 I POL
calendars to be defined within reference data.
BT - 046 I Fujitsu
I Services
The current functionality for extending accounting periods should I 1 }
be removed. The Horizon system should continue to remind I
users to roll-over the accounting period if they logon to a SU in I
the wrong Trading Period according to the calendar.
3 March 2004
© Post Office™ 2004
Version 1.0 Page 76 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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 There must be inactive Stock Units which need to be rolled over into the next
Conditions Trading Statement period.
Completion Inactive Stock Units rolled over into the next Trading Statement period
Conditions
10.1.6.8 Stock Revaluation (Stamps) (A4.1.7.8)
Attribute Description
Description This process allows any stock items, still being reported/held by value at the
branch, to be revalued.
It is currently assumed that the one remaining stock item for which this process will
be required is Non-Specific Value stamps.
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
Start up Based on calendar of revaluation.
Conditions
Completion Revaluation completed.
Conditions
BT- I Fujitsu Revaluation functionality to be redefined such that the user is 1 I
I Services 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
I adjustments prior to the price change
BT -047 I POL Any non-value indicated items held as part of the balance figure I 4
I (e.g. as Other Stamps) must be re-classified before
I implementation of this function (otherwise current revaluation
I functionality will be required) I
10.1.7 Summarise Transaction Data
1. Scan Transaction for Day
2. Accumulate Transactions for Summarisation
3. Summarise Cash Centre Transactions
10.1.7.1. Scan Transaction for Day (A4.3.1)
3 March 2004 Version 1.0 Page 77 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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 Trading Day completed.
Conditions
Completion All transactions for the Trading Day have been scanned.
Conditions
10.1.7.2 Accumulate Transactions for Summarisation (A4.3.2)
Attribute
Description
Description
The purpose of this process 1s fo summarise transactions at the required level of
detail for each external data feed provided by the TMS.
The main summarisations required are as follows
* POLFS
TMS will provide POLFS with a daily feed of summarised and individual
Horizon transaction data.
The transactions to be summarised are:
Cash in Hand
Cheques in Hand
Rem out of Cheques
Payment by cards
Forex in Hand
Client product/service transactions with customers
Rems in/out of stock
Stock adjustments (from declaration process)
020000000
Horizon transactions must be summarised by Outlet/Product Grouping
(account) and by mode for the Trading Day. Horizon will use reference
data (Horizon-POLFS Mappings) to determine the appropriate account.
The transactions to be provided individually are:
Rems in/out of cash
Rems in/out of Forex
Rem Discrepancies in/out of suspense
Transaction corrections
Recoveries relating to Transaction Corrections
00000
Details of the interface are given in the Horizon to POLFS AIS [Ref?]
= SAPHR
The TMS will provide SAPHR with details of Horizon transactions as an
input to the agent remuneration process.
Transactions must be summarised by Outlet/CTT for each period. A
timetable for summarisation will be held in Reference Data for each
relevant Agent Contract Type. Reference data will also specify which
Products are to be included, and the Producl/CTT mappings (see
Horizon to SAPHR AIS for details — Ref?).
Note: data will be provided one month in arrears rather than two as at
present, and will consist of a single monthly feed, rather than the
monthly and separate CFPO feed provided currently.
Transactions will include Card Account Enlivenments received from
EDS.
«= MIS
Transaction details (for fully harvested Outlets) for the trading day are to
3 March 2004
© Post Office™ 2004
Version 1.0 Page 78 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
be passed unsummarised to the MIS. Horizon events are also to be
included, as per the current OPTIP interface, and including any extra
events introduced as part of S80 Branch Trading changes.
The transaction data required will be as currently passed to OPTIP with
additional attributes for Banking, ETU, Debit Card and Bureau de
Change products and which events, and what information is to be
transmitted about them, to be documented in the Horizon — MIS AIS).
« Other Data Feeds
These are existing data feeds provided by OPTIP or CBDB which need
to be replicated by the TMS to support continuing requirements.
© CTS (Client Transmission Summary)
The existing CTS will continue to be produced for use by the
Client Settlement Team. This will be unchanged.
Trigger The triggers will be timed events.
Automation The process is fully automated.
Frequency Daily for POLFS, MIS, DPI, OBCS and CTS
Weekly for SAPADS and Martins
Monthly for SAPHR
MacDonaldD2 Surprising to see entries here which are not mentioned in the
description above
Constraints
None
Start up I Process triggered.
Conditions
Completion All transactions for the Trading Day for each summarisation have been processed.
Conditions
10.1.7.3, Summarise Cash Centre Transactions (A4.3.3)
3 March 2004
© Post Office™ 2004
Version 1.0 Page 79 of 120
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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.
= POLFS
TMS will provide POLFS with a daily feed of summarised and individual
Cash Centre transaction data.
The transactions to be provided individually are:
Rems in/out of cash to branches
Rems in/out of Forex to branches
Rems in of discrepancies
Coin Club & Customer bulk cash sale
Coin Club & Customer bulk cash purchase
Cash in/out of Bond
Bank Machine ATM cassette rem out
Bank Machine ATM cassette rem in
Repatriation of Scottish Notes
000000000
The transactions to be provided in summary form are.
Cash in Hand movements
Receipt of Cheques from clients
Girobank a/c movements
Joint Stock Bank movements
Rem out of Cheques to EDS
Rem in of NI Cheques from Branch
Girobank Change Sales and Purchases
Sales of foreign coin to Coin Co — issue and invoice
Loss on sale of foreign coin
Sale of counterfeit/mutilated notes
Cash Centre losses/gains
Girobank deposits
Girobank deposit shortages not settled
Girobank deposit surpluses not settled
Unidentified pouches
0000000202070 0000
Cash centre transactions will be summarised by SAPADS — no further
summarisation is required in the TMS.
= MIS
The TMS will extract transaction level data for passing to the MIS on the
daily interface.: The required attributes and transaction types are
defined .}ins the AIS [Ref: ???]
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
SAPADS interface fully processed.
10.1.7.4 Deliver Data to External Systems
3 March 2004
© Post Office™ 2004
Version 1.0 Page 80 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
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 .
SAPHR —Monthly, to be FTPd to SAPHR:
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: ???]
Start up System generated time based trigger
Conditions
Completion Interface files generated and transmitted
Conditions
3 March 2004
© Post Office™ 2004
Version 1.0 Page 81 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction 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.
MacDonaldD2 Any chance of including this data model in the CD ?
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.
MacDonaldD2 Does this mean that any existing Type B is to be sourced from NRDS at S80 ?
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
NIA
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.4Reconciliation
Reconciliation is expected to change as defined within Section 10.1.1.3.
3 March 2004 Version 1.0 Page 82 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
10.5 Audit _
BT fp {DN: Audit requirements particularly for TMS need to be defined I
and documented here.}
10.6 Accounting Requirements
10.6.1 Settlement
NIA
10.6.2 Invoicing
10.7MI
10.7.1 Post Office™
10.7.2 N/ASupplier
10.7.3 N/AClient
3 March 2004 Version 1.0 Page 83 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction 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.2Sizing Assumptions
The following assumptions are to be made when assessing the impact of the Branch Trading facilities:-
= 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.
MacDonaldD2 The accounting period is increased from 7 to a maximum of 35 days so is increasing data retention
to 42 realistic. Does it need to potentially be much higher ?
= 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)
more data than the data centre (i.e. it is more than 35 days since
alo I Pulisu The data retention period will be increased such that all trading 1 I
I Services . . Pr - I
I data is available within the Branch for a minimum of 42 days. I
BT- I Fujitsu The data retention period at the data centre will remain at 42 1 I
050 I Services I
I days as at current. I
oe I POL Process for disaster recovery situations when the Branch had 2 I
I I
J
the last Branch Trading Statement produced) will be defined.
11.3 Service Levels
Reviews of this service will be held at agreed intervals, typically monthly. The review will be attended by
the service managers from POL and Fujitsu Services, together with appropriate operational and technical
managers. The review will consider the service performance against the OLA and SLA; the impact of any
forecast service changes; open problems and any service improvements.
Availability
The new solution should be consistent with the current service levels as set out in {REF SLA}.
Reliability
The new solution should be consistent with the current service levels as set out in {REF SLA}.
Data Delivery Times
It is envisaged that the data delivery times will align with current LFS delivery times, although needs to be
confirmed.
3 March 2004 Version 1.0 Page 84 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
Help desks
Helpdesk support for issues between Horizon / SAPADS will be required as outlined in the current LFS
OLA (appendix A)
Helpdesk support between Horizon / POL FS will need to be agreed.
Service level reports
Service Level reports should be produced in line with current LFS reports, and should be discussed as part
of the current Logistics feeder service, operational review forum.
NB The resulting solution should not significantly impact the run times of the current batch process, and
Current operational achievements should still be met
11.3.1 Post Office™
No Specific requirements
3 March 2004 Version 1.0 Page 85 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
11.4Problem 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.5Business Continuity
No specific requirements.
11.6 Training
BT- I POL 7 “Training will be required at the Branches in support of the newI 2
052 «I
I using work aids which will be produced by POL.
business processes, it is currently assumed that this will be done
11.7 Change Specific Non-Functional Requirements Required
Change Area
Non-Functional Considerations
A4.1.1.1 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.2.3. Produce Sales Report to Assist
Remuneration Check. Change: Different sales
report over different periods.
Performance - Current production not a problem in
terms of performance. No perceived problems with
increased times likely.
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.2.5 Despatch Redeemed Dockets.
Change: No change
Performance. — performance requirements as for
Rem of Cheques/Stock now.
Accessibility/Security -no change
Usability -no change
Data Retention - to match period of data held by
Horizon
Mitigation of failure —no change, Adjustments as for
now if system derived figures for Dockets/Voucher
held does not match actual.
Auditability —no change
Legal & Regulatory —no change
3 March 2004 Version 1.0 Page 86 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
COMMERCIAL IN CONFIDENCE
Conceptual Design
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
A4.1.5.1 Receive Automated Message Change:
Reminders on Receipt/Delivery of Transaction
Performance — As for other logon reminders
Accessibility/Security — no change
Corrections 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. I Performance — no specific requirements over other
Change: Management of Transaction I Horizon functions
Corrections, Implementation of corrective I Accessibility/Security —no change
actions, etc. Usability — no change
Data Retention
Horizon
Mitigation of failure — no change
Auditability - no change
Legal & Regulatory — no change
- to match period of data held by
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
A4.1.6.2 Create Variance Report. Change:
Implementation of new report — format to be
defined, complexity may effect 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
A4.1.7.1 Make Good any Outstanding Variances.
Change: Changes to Suspense Account
products,.
Performance — no change
Accessibility/Security — some / all of these postings
should be restricted to the Manager roles (i.e.
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
A4.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
3 March 2004
© Post Office™ 2004
Version 1.0
Page 87 of 120
FUJ00089971
FUJ00089971
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
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: I Performance — needs to be reviewed not perceived to
Functionality to control not being able to I bea problem at the moment
complete Trading Statement with variances. 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.6 Produce and Confirm Trading I Performance — needs to be reviewed not perceived to
Statement. Change: New Report, change in I be a problem at the moment
electronic confirmation functionality 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
Legal & Regulatory — no change
3 March 2004 Version 1.0 Page 88 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
12 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.4Integration & Interfaces
3 March 2004 Version 1.0
© Post Office™ 2004
Page 89 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction 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.4Implementation & 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 90 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction 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 may be produced
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.3Prism
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.4AISs
The following AlSs will be produced to support the IMPACT R3 Branch Trading Requirement defined in the
cD:
3 March 2004 Version 1.0 Page 91 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
FUJ00089971
FUJ00089971
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
eee cc cee
SAP ADS to Horizon
POL FS to Horizon
Horizon to POL FS.
Horizon to HR SAP
Horizon to Sales MI
Reference Data to Horizon
External Sources to Horizon TMS (just CAPO)
Horizon TMS to External Sources (many)
14.5Reference Data Changes
053 I Services
"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 summarisation for Martins
¢ Camelot stores and numbers
¢ — Martins outlet indicator
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
¢ Revaluation date
3 March 2004
© Post Office™ 2004
Version 1.0
Page 92 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
an I POL There is a requirement for the values of current reference data 1 ]
I items to be reviewed to ensure more robust data capture. I
I These are: I
I « Min/max ranges for transactions inc bulk data entry and I
I non accounting data I
as I POL There is a requirement to control all items of stock. This will be 1 ]
I achieved through reference data by defining as controlled I
I products those products which are currently non-value products I
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:
eto 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 patterns. 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 S80 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
$80
© 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 93 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
16 Acceptance
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. Supplier Test
o This method will comprise tests that are run and managed by Suppliers. The method
of testing will be specified in the IMPACT R3 test plans, and the mapping of each
Requirement to one or more test cases will be managed by Suppliers. The
assessment of these tests will be by inspection of test results carried out by
Suppliers or jointly with Post Office.
¢ 2. Document review
o This method will comprise a document review by Post Office Ltd. of the relevant
section of a document or documents. The classification and contractual status of
any documents used for this purpose will remain unchanged.
* 3. Post Office Test
co This method will comprise tests that are run and managed by Post Office Ltd. The
actual method of testing, which may utilise the Post Office Ltd. End-to-End test
environment, will typically be used for those aspects of the solution that can only be
verified as part of an overall Post Office End-to-End environment. The Post Office
Test could also include document review.
« 4. Statement of fact or obligation
0 This classification will be used for those Requirements that represent an existing
Fujitsu Services obligation, or where the solution to a Requirement is self-evident
and does not lend itself to formal proving.
« 5. Not part of Supplier Acceptance
o This classification will be used against Requirements that are not part of Post Office
Ltd’s acceptance activities.
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.
3 March 2004 Version 1.0 Page 94 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
Internal Functional Testing
Gaining assurance of main suppliers internal functional testing via :-
o Review suppliers internal test plans/ scripts for completeness
o Review suppliers internal test results / progress reports
o Review suppliers internal testing fault logs for impact
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
Review of supplier test plans / scripts for completeness
Witness specific key tests during a supplier testing cycle
Review supplier test results
Review supplier test fault logs for impact
00000
Interface Testing
Lead or Support Suppliers through the execution of Direct Interface testing between two suppliers e.g.
Lead Horizon to SAP/ADS
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
Review the test results including any faults
00000
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.
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:-
© a pre-pilot (transactions carried out in the passive Post Office)
o pilot (small number of outlets)
© go-live.( rolled out to the full estate)
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 Page 95 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
18 Implementation & Migration
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
New MIS on Spree SAPHR
From TMS data
sun SAP HR
271305 From CBDB/OPTip cap
ry
Finals pranch
OPTip feed off Cash Meount I
f
A B ¢€
Final GBDB
Cash Ace:
ry
Different in
different branches
Tn ALL pra
cBDB
POL-FS
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 seule it with an enhanced data feed to MIS
itoring required? What about really late
= 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
3 March 2004 Version 1.0 Page 96 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Conceptual Design
COMMERCIAL IN CONFIDENCE
of a Cash Account to result in the migration of Stock Units and the branch into the new way of working
(ie moving from phase B to phase C).
= CBDB will pass data to HR SAP covering the period up until the final Cash Account (ie 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.
18.2 Migration Requirements
Change Area
Migration Approach/Requirements
A4.1.1.1 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.
Remuneration Check. Change: Different sales
report over different periods.
4.1.1.3 Automated Reconciliation. Change: I (ON?) Requirements) to! bel definedias part of
Move from APS/TPS to TMS migration work stream.}
A4.1.2.3. Produce Sales Report to Assist I Could be implemented at any time, would be
beneficial to be implemented in period A. No need
for soft launch.
A4.1.2.5 Despatch Redeemed Dockets.
Change: No change.
Need to happen within Period C. Number of
Dockets and Vouchers to reduce. Controls,
currently in CBDB to be within POL-FS, during
period B need to be considered. Opening position
must be manually input at point of implementation
of new functionality.
A4.1.5.1 Receive Automated Message. Change:
Reminders on Receipt/Delivery of Transaction
Needs to be implemented from the beginning of
point B, can be implemented, but not used, from
Corrections. commencement of implementation. Need to
consider mapping Transaction Corrections
transactions to the cash account for during Period
B.
A4.1.5.2 I Handle Transaction Correction. I Needs to be implemented from the beginning of
Change: Management of Transaction I point B, can be implemented, but not used, from
Corrections, Implementation of corrective I commencement of implementation. Need to
actions, etc. consider mapping Transaction Corrections
transactions to the cash account for during Period
B.
Error Notices buttons to be removed by some time
near the end of 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 S80. Day 1 Period A.
A4.1.6.2 Create Variance Report. Change:
Implementation of new report — format to be
defined, complexity may effect usability of report
produced — may need to re-format to simplify.
During period A, implemented at implementation
of S80. Day 1 Period A.
A4.1.7.1 Make Good any Outstanding Variances.
Change: Changes to Suspense Account
products.
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.
3 March 2004
© Post Office™ 2004
Version 1.0
Page 97 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
A4.1.7.4 Investigate Balance Discrepancies.
Change: No change.
A4.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
Implemented at commencement of Period C.
Must be able to correlate brought forward figure to
electronic confirmation functionality
carried forward items on old style reports.
3 March 2004 Version 1.0 Page 98 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
19 Appendix A — Requirements Catalogue
Req ID I Supplier Description Acceptance
Method
I
BT-001 I Fujitsu Production of a balance report for a stock unit must be possible 1
ervices
to be produced within 4 times the current production time for a
stock unit with a busy transaction profile, long trading statement
period
BT-002 I Fulitsu Functionality not specifically identified to be changed within this 1
ervices
document must not be affected to degrade the existing service
provided by the Horizon system.
BT - 003 Po. Migration to POL-FS must occur at the end of a financial period. 4
I Fujitsu
I Services,
I PRISM
BT - 004 POL It will be verified that branch processes and reporting changes 2
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.
BT -005 POL
BT-006 I Fujitsu A new trial balance report will be produced, the content and 183
I Services format of which will be as specified in Appendix B
BT - 007 Fujitsu The content and format of trial and final balance reports will be 1&3
I Services altered as specified in Appendix B I
BT-008 I Fujitsu A new trading statement report will be produced, the content 183
I Services I and format of which will be as specified in Appendix B
BT-009 I Fujitsu A new variances report will be produced, the content and format 183 I
Services I
of which will be as specified in Section 20.2 in Appendix B
BT- 010 POL A review of which periodic checks are to be made, with which 2
parameters, on data within Management Information systems
must be made.
BT-011 POL A review of parameters, defined through reference data, for 283
I control and management of data entry at the counter, is to be I
made. Any changes to reference data must be implemented
prior to removal of current CBDB range check processes.
BT -012 POL A revised end of day procedure will be defined, identifying which 2
summaries must be produced at 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.
I The methods for producing summaries (daily and periodic)
Services allow production of summaries, to be printed and/or previewed
on screen and allow a cut-off. This is existing functionality which
will remain as is.
3 March 2004 Version 1.0 Page 99 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
BT-014 POL A revised end of period (probably weekly) procedure will be 2
defined, identifying which summaries must be produced at end
of period. The revised list of items will be defined in reference
data for display when the “End of Week’ button is pressed on
I Horizon.
BT-015 POL The list of summaries will be reviewed and classified as 2
mandatory and optional. Business rules for content on optional I
summaries will be defined. As either:
« Summary of transactions of type since last cut off,
whether cut-off is in this trading period or last.
Summary of transactions of type since last cut off, if cut off in
this trading period, but only summary of transaction transactions
of type since start of trading period if last cut-off was in previous
trading period
BT-016 I Fujitsu Functionality to allow entry of date range on the of Sales Report 1&3
Services 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 data range.
BT-017 I Fujitsu The methods for producing reports will allow the reports to be 1
Services printed and/or previewed on screen. This is existing functionality
which will remain as is.
BT-018 I Fujitsu The functionality for entering non-accounting data will remain as 1
I Services is.
BT-019 POL Business procedures for entering non-accounting data, 2
I identifying what data and when, will be produced.
BT- 020 I Fujitsu The functionality for entering bulk data will remain as is. 1
I Services
BT -021 POL Business procedures for entering bulk data, identifying what data 2
____I __I and when, willbe produced. = -
BT-022 I 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
I necessary, renegotiate client reporting requirements.
BT - 023 POL New and replacement products will be implemented using 2
existing system capabilities.
BT-024 I Fujitsu A user with the appropriate role will be informed, at log on, that 1&3
Services there are outstanding Transaction Corrections awaiting
processing, whenever there are any.
BT -025 Fujitsu There will be a button for Transaction Correction Management 1&3
I Services 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.
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).
BT — 026 Fujitsu At the end of performing a cash declaration, in a shared stock 1&3
I Services unit, the system will enter, if the user chooses to, the cash I
discrepancies function to support the identification of any
variance.
BT -027 Fujitsu For a non-shared stock unit the functionality of declaring cash 1
Services will remain as is
BT - 028 Fujitsu Reminders for ONCH function to be performed at log on if not 1&3
I Services performed previous day will be removed and, instead, the I
system will remind users to perform cash declaration function if it
has not been performed on the previous day, but this may be
declined.
BT - 029 Fujitsu When the cash declaration has been made the figures for 1&3
Services denominational split will be passed to SAP-ADS as if an ONCH
“3 March 2004 Version 1.0 Page 100 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
BT -030 Fujitsu Anew function will be made available to provide the variance 1&3
Services report to the defined content and format
BT - 031 POL A review of vouchers remitted from the branch will identify 2
which dockets will need to be treated via which adjustment
I products. — - ee - I
BT-032 I Fujitsu Anew function for recording a “make good” action will be made 1&3
Services 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 reported on variance
I reports, balance reports and trading statements.
BT - 033 Fujitsu Access to the functionality to enter amount into suspense 183
Services products will be limited by user role __I
BT - 034 POL A process for applying for hardship will be defined to allow a 2 I
I branch manager to make alternative arrangements for when a
variance cannot be made good immediately. Variances will be
I held whilst the application is processed. This may lead to an
I extended Trading Period. Approved hardship amounts will
appear as Transaction Corrections
BT-035 I POL Reference Data will be edited to limit the suspense accounts 2 I
available within branches to the limited “known errors” set.
BT - 036 Fujitsu Adjustments in stock (whether identified via adjustments or 1&3
Services stock declarations) should be adjusted at the adjustment price
— _I whenever defined in reference data. es
BT - 037 Report will be redefined without stock values as defined in 1&3
I Services section 20.6 in Appendix B
3 March 2004 Version 1.0 Page 101 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project: IMPACT - Branch Trading Reporting,
FUJ00089971
FUJ00089971
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
BT — 038 Fujitsu A new check is to be introduced after producing the Trial 183 ]
Services Balance (ie when the “rollover” button is pressed prior to I
producing the Final Balance). This check will act as follows: I
4. If it isn't the last Stock Unit to rollover, the clerk will be I
advised that the Discrepancy is to be posted to a “local I
adjustments” account. They have the option of I
I
accepting or rejecting this action. I
d. Should they accept it, then a pair of I
transactions will be generated resulting in the I
Discrepancy being reduced to zero and a I
corresponding amount being put into a “local I
I
adjustments product”. I
e. Should they reject it, then the rollover is I
aborted and the clerk is free to do whatever I
they wish to balance the Stock Unit and will I
then need to balance the Stock Unit again at a I
later time. I
f. The “local adjustment” is not associated with I
any Stock Unit (as with a Suspense account). I
Items can be added to it by any clerk, but only I
as part of the Balancing Process. Managers / I
I
Supervisors will be able to move items from it I
into cash in their SU to be Made Good. I
5. If this is the last Stock Unit to Rollover an additional I
check will be performed to ensure that the net total of I
transactions, within the Trading Period, in the “local I
adjustment” account has a net value of zero. I
I
6. If this is the last Stock Unit to Rollover, then the user will I
be informed if the Stock Unit has a Discrepancy and I
that this must be resolved before the last Stock Unit can I
be rolled over. I
I
Local Adjustment will behave in a similar way to existing I
Suspense Account items, namely the values will not be I
associated with any Stock Unit, but is considered as part of the I
overall Branch balance. I
"There is an existing report that shows the state ofall suspense [1&3
Services accounts and all Transactions associated with the suspense I
accounts during the Trading Period, indicating which Stock Unit I
carried out the Transaction. It is proposed that Local Adjustment I
transactions are included in this report as with any other I
Suspense transactions I
BT -040 Fujitsu Horizon should be changed such that only Supervisors and 1&3 I
Services Managers (etc) will be allowed to carry out Suspense I
Transactions. The only exception to this will be the automatic I
posting of Discrepancies to Local Adjustment. I
3 March 2004 Version 1.0 Page 102 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
FUJ00089971
FUJ00089971
Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
BT -041
BT-042
I Fujitsu
Fujitsu
Services
Services
The user will select the appropriate function which will display the I 1&3 I
Trial Trading Statement (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, print I
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.
Anew trading statement report will be produced, the content 1&3
and format of which will be as specified in Section 20.1 in
Appendix B
BT - 043
Fujitsu
Services
The confirmation event will be made available to the data 183
warehouse to enable monitoring of who has and who hasn't
done a trading statement. The “confirmation transaction” will I
not contain the constituent parts that make up the trading
position.
BT - 044
Services
Fujitsu
A facility for different branches to operate on a different (four 1&3
weekly) branch trading calendar, will be implemented, which
branch is operating to which calendar is to be defined by I
reference data.
BT —045
Fujitsu
Services
The current functionality for extending accounting periods should I 1&3
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 - 046
Services
Fujitsu
Revaluation functionality to be redefined such that the user is 1&3 I
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 I
adjustments prior to the price change
BT - 047
POL
Any non-value indicated items held as part of the balance figure I 4
(e.g. as Other Stamps) must be re-classified before
implementation of this function (otherwise current revaluation I
functionality will be required)
BT - 048
BT - 049
Fujitsu
Services
The data retention period will be increased such that all trading 1&3
data is available within the Branch for a minimum of 42 days.
BT - 050
Fujitsu
Services
The data retention period at the data centre will remain at 42 183
days as at current.
BT -051
POL
Process for disaster recovery situations when the Branch had 2
more data than the data centre (i.e. it is more than 35 days since
the last Branch Trading Statement produced) will be defined.
BT - 052
POL
Training will be required at the Branches in support of the new 2
business processes, it is currently assumed that this will be done
3 March 2004
© Post Office™ 2004
Version 1.0 Page 103 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
BT-053 I gultsu New data structures and data items are required to support the 183 I
I Services
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 I
« Suspense products minimum values
To ensure correct accounting in POLFS
« POLFS materials and clients mapped to Horizon
products.
To enable summarisation for Martins
* Camelot stores and numbers
¢ — Martins outlet indicator
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
¢ Revaluation date
BT—054 I POL I There is a requirement for the values of current reference dataI 183
items to be reviewed to ensure more robust data capture.
These are:
« Min/max ranges for transactions inc bulk data entry and I
non accounting data
BT-055 I POL There is a requirement to control all items of stock. This will be 183
achieved through reference data by defining as controlled
products those products which are currently non-value products
3 March 2004 Version 1.0 Page 104 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE 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.
3 March 2004 Version 1.0 Page 105 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
Curent Period
SU AA, UBB _SUCC —SUDB—SUEE—SUFF___Branch Total__I Cash on hand brought fwd figure at previous period end as on current
Cash on Hand B Fwd £10,000 £10,000 £10,000 £10,000 £10,000 £50,000 beloace reports Thus cpphes ts of € Feed Oren baton
Other Postage B Fwd £2,000 £2,000 £2,000 £2,000 £2,000 £10,000
Foreign Exchange B Fwd £3,000 £3,000 £3,000 £3,000 £3,000 £0 £15,000
[Receipts totalled as they are on the current balance reports, except that
Receipts value Total £10,000 £10,000 £10,000 £10,000 £10,000 £50,000 remittances in and transfers in are separated out and totalled onto the
Remittance in (Cash) Total £5,000 £5,000 £5,000 £5,000 _ £5,000 toes below,
Transfers in Total £5,000 £5,000 £5,000 £5,000 £5,000
[Payments totalled as they are on the current balance reports, except
Payments value Total £20,000 ___ £20,000 £20,000 £20,000 £20,000 £100,000 that remittances out (of cash and voucher) and transfers out are
Remittances Out (Cash) Total £0 £0 £0 £0 £0 £0 eaparoted cur end totaled oreo the tres below.
Remittances Out Vouchers £0 £0 £0 £0 £0 £0
Transfers Out Total £0 £0 £0 a re [Gash on hand dedlaraton at period end as on current balance reports]
‘Cash on Hand C Fd £10,000 £10,000 £10,000 £40,000 £50,000. Postage on hand dedlaration at period end as on current balance
Other Postage C Fwd, £2,000 £2,000 £2,000 _ £2,000 £2,000 £10,000 reports.
Foreign Exchange C Fwd £3,000 £3,000 £3,000 £3,000 £3,000 £0 £15,000
Trading position (+f) £0. EO i Bu au — [This should be @ sum of the above lines of all the cash and stamps on
hand, the receipts and payments, and the remittances into and out of
Transaction Corrections Accepted "£0 £0 £0 £0 £0 the Stock Unt.
If there is a non-zero value here it should be compensated in the
Discrepancy adjustments £0 £0 £0 £0 £0 lines below (Tran Corrections Accepted, Discrepancy adjustments,
Local Losses/Gains Account, Authorised surpluses/shortages), before
Tocallosses/qains account a FC 0 0 0 1a zero balance c fwd figure is recorded at line 29.
Known Discrepancies £0 This is the total value of the amounts in knovin discrepancies
(remaining suspense) accounts
Balance C Fwd £0 £080. Fo. £0
[This is the actual cash being putin or taken out to balance the SU and
lBranch. This is @ requirement for Ops and Securty.
[This should be the net effect of all the accepted trm corrections in
the period.
3 March 2004
© Post Office™ 2004
Version 1.0
Page 106 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
20.1.2 Example 1
Curent Period
SUAA__SUBB__SUCC_SUDD SUEE SUFF Branch Total
‘Cash on Hand B Fwd £10,000 £10,000 £10,000 £10,000 £10,000 £50,000
Other Postage B Fd £2,000 £2,000 £2,000 £2,000 _ £2,000 £10,000
Foreign Exchange B Fwd £3,000 £3,000 £3,000 £3,000 £3,000 £0 £15,000
Receipts value Total £10,000 £10,000 £10,000 £10,000 £10,000 £50,000
Remittance in (Cash) Total £5,000 £5,000 £5,000 £5,000 _ £5,000
Transfers in Total £5,000 £5,000 £5,000 £5,000 £5,000
Payments value Total £20,000 £20,000 £20,000 £20,000 £20,000 £100,000
Remittances Out (Cash) Total £0 £0 £0 £0 £0 £0
Remittances Out Vouchers £0 £0 £0 £0 £0 £0
Transfers Out Total £0 £0 £0 £0 £0
Fri example Shows that potential @ SU to SU transfer of ESk has not taken
Cash on Hand C Fwd £10,000 £10,000 £10,000 £15,000 £5,000 "£50,000 pies between SOD ahd SUE.
Other Postage C Fwd £2,000 £2,000 _ £2,000 £2,000 £2,000 £10,000 jeseptraley asegindg nko dats Saale nia
Foreign Exchange C Fwd £3,000 £3,000 £3,000 £3,000 _£3,000.--¥0_ £15,000 dantied 8a the cause of the eivor
Trading position (+/-) £0 £0 £0 £5,000 £5,000 £0
Transaction Corrections Accepted £0 £0 £0 £0 £0
Discrepancy adjustments £0 £0 £0 £0 £0
Local losses/gains account £0 £0 £0 £0 £0
Known Discrepancies £0
Balance C Fwd £0 £0 £0 £5,000 £5,000
3 March 2004 Version 1.0 Page 107 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
20.1.3 Example 2
Curent Period
SUAA____SUBB__SUCC_SUDD SUEE SUMGR__ Branch Total
‘Cash on Hand 8 Fwd £10,000 £10,000 £10,000 £10,000 £10,000 £0 £50,000
Other Postage B Fwd, £2,000 £2,000 £2,000 £2,000 £2,000 £0 £10,000
Foreign Exchange B Fwd £3,000 £3,000 £3,000 _£3,000_£3,000 £0 £15,000
Receipts value Total £10,030 £10,010 £10,000 £10,000 £10,000 £0 £50,040
Remittance in (Cash) Total £5,000 £5,000 £5,000 £5,000 £5,000 £0
Transfers In Total £5,000 £5,000 £5,000 £10,000 £5,000 £0
Payments value Total £20,050 £20,010 £20,000 £20,000 £20,000 £0 £700,060
Remittances Out (Cash) Total £0 £0 £0 £0 £0 £0 £0
Remittances Out Vouchers £0 £0 £0 £0 £0 £0 £0
Transfers Out Total £0 £0 £0 £0 £5,000 £0
‘Cash on Hand C Fwd £10,000 £10,000 £10,000 £15,000 £5,000 £0 £50,000
Other Postage C Fwd £2,000 £2,000 _ £2,000 £2,000 £2,000 £0 £10,000
Foreign Exchange C Fwd £3,000 £3,000 £3,000 _£3,000_€3,000 £0 £15,000
Trading position (+7) £20 £0 £0 £0 £0 0-20
Transaction Corrections Accepted £0 £0 £0 £0 £0 £0 £0
Discrepancy adjustments £0 £0_ £0 £0 £0 £20 £20
Local losses/gains account £20 £0 £0 £0 £0 £20 £0
Known Discrepancies £0
Balance C Fwd £0 £0 £0 £0 £0 £0 £0
3 March 2004 Version 1.0 Page 108 of 120
© Post Office™ 2004
‘This example shows where a Branch Office
may write small amounts to a local
suspense account facility, and make good
through a managers SU.
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
20.2 Variance Report
20.2.1 Specification
Days in Trading Period .
Cash Variances PE eb pad ee Tigue derved from any variance between the decored 9nd system
Suna lgenerted gues for cash held bythe stock unt atthe time of decleraton. I I
SU CC +ve if declaration is greater than system generated, -ve if reverse is true. I_I
SUDo fo decareton made =
‘Branch [Days since trading period tart.
a cas Zz z z = 3
SUAA NA
SUB. WA I
‘suCC WA 1
S000 WA Friary of he above variances sum ofthe values above F
Branch WA one ore x
a. _s§
WA
WA i {
Ma ia dechraton Fas been rade ha should be the Hater generated
WA figure atthe time of declaration, Othervise should be the system
my generated figure forthe stock unt at end of cay.
Sen i I I
phe MS Bis EI RD TL JSum of the figures above
i i I
7 decoration ss boon made forts day te value wil be entered
ere otherwise al spay X
Dec 04 T I
So any of he above variances #% sum ofthe values none re
Dec OF
Ec I f Fis WA bcne aw Wat ped ere Wang pefod ec
unt, IFigures should be taken from day 7 within next week, 14 in the next. etc,
am Ey
‘Amounts I 1 T T T T
his green area tobe leh bank
HIS Re AVE aaarn
Bi y
‘Number not processed - x x
[Number of Outstanding Transaction Corrections at end of day
[Net entries i "known suspense” Keme at end of day.
[Sum of adjustments (Excess Cosh Removed and Cash Shortage Mode
Icood) across all stock unts during the day
3 March 2004
© Post Office™ 2004
Version 1.0
Page 109 of 120
FUJ00089971
FUJ00089971
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
20.2.2 Example wk 1
‘Number not processed
3 March 2004 Version 1.0 Page 110 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
20.2.3 Example wk 2
Number not processed _
3 March 2004 Version 1.0 Page 111 of 120
© Post Office™ 2004
Doc Ref: BTRM
IC&TM-001 Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
20.3 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 I 11:42 17/01/1998 CAP:01 BP:01 SU:SH1 This should describe the
03 I Sales Report - Office Copy time period which the
04 report represents.
05 VOLUME VALUE
06I Cash 293.11
07 I CASH 293.11
08I Cheque 3432.79
09I CHEQUES 3432.79
10I Giro Txfer 47.97
11] GIRO TRANSFERS 47.97
12I 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] COLOUR 86.50
20I Mono TV Fee 3 85.50
21 I Mono 85.50
22 ITV FEE 172.00
23] SwftPkC3Euro 3 14.97
24 1st Class 12 3.12
25I 2nd Class 11 2.20
26I Post Stamp 30.00
27) Env 1stClass 0.60
28 I IntRepCoupon 4 2.40
29] Reqistrd RG1 2 7.28
30I POSTAGE STAMPS ETC 60.49
31 Stbkvnd £1 2 2.00
32 I STAMP BOOKS-VENDING 2.00
33 I Stpbk 1stx10 6 15.60
34 STAMP BOOKS-OTHER 15.60
35 I POSTAGE 78.09
36I Gas Stamp £1 20 20.00
37I Active Life 12.00
38 I 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
48I PO FgnEx Out 1 150.00
49I PO Foreign Exch Out 150.00
50I BurChnge Pay 1 27.00
51] BUREAU DE CHANGE OUT 27.00
52I Lwood Prize 1 100.00
53I NatLot Prize 1 10.00
3 March 2004 Version 1.0 Page 112 of 120
© Post Office™
2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
54I LOTTERY PAYMENTS 110.00
55 I OTHER PAYMENTS 3354.78
56
57 *** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
20.4 Declaration: Stock on Hand — Stock Report
1 2 3 4 Notes
123456789012345678901234567890123456789012
Chelsea PO FAD: 0040389
23:42 23/01/1998 CAP:52 BP:01 SU:SH1
Stock on Hand - Office Copy
USER EPROOL DECLARATION ID 11
DESCRIPTION ‘VOLUME AMOUNT
1st Class [£0.26] 427 424.02
2nd Class [£0.19] 453 86-07
BT £5 PC [£5.00] 50 250.00
PO £5 [£5.00] 50 250.00
PO Fee £5 [£5.00] 32.50
PO £6 [£6.00] 10 60-00
PO Fee £6 [£6.00] 650
PO £7 [£7.00] 10 70-00
PO Fee £7 [£7.00] 6:50
PO £9 [£9.00] 20 480.00
PO Fee £9 [£9.00] 16-00
TOTAL 1020 1068.59
*** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
3 March 2004
Version 1.0
© Post Office™ 2004
Page 113 of 120
Doc Ref: BTRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
20.5 Counter Weekly Stock on Hand - Stock Report
1 2 3 4
123456789012345678901234567890123456789012
Notes
Feltham Post Office FAD: 123456X
11:12 16/01/1998 CAP:01 BP:01 SU:SH1
Stock On Hand - Office Copy
VALUE STOCK & MOP VOLUME
Cash
Comcoin
COIN SETS
Game Red 2
Game Occas 2
Game Dealers 2
GAME LICENCES
Col TV Fee 1
COLOUR
TV FEE
FDE
Pres Pack
PHILATELIC ITEMS
1st Class
2nd Class
POSTAGE 36977
Reg Plus PL2 100
Sw£tPkC3Euro 97
SwiftpackLge 100
Env 2ndClass
Env 1stClass
IntRepCoupon
Registrd RG1 98
MISCELLANEOUS
100
18488
18489
*** END OF REPORT ***
This report will only
deal in stock and only
in volume.
Assume removal of MOP
From this report.
Any items without a
volume will need to
show volume, but
not value.
Doesn't make sense to.
have Misc. by volume
will need to list all
stock items
1 2 3 4
123456789012345678901234567890123456789012
3 March 2004
Version 1.0
© Post Office™ 2004
Page 114 of 120
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
20.6 Stock Unit Balance: Snapshot
1 2 3 4 Notes
123456789012345678901234567890123456789012
01 [Feltham Post Office FAD: 123456X
02 I11:09 01/10/1998 CAP:01
03 I Office Snapshot - Office Copy
04
05 I ******Discrepancies in this Account******
06 I *Discrepancy OVER 57.50 *
07 I *Discrepancy SHORT 0.00 *
op ft ne *
09 I *Nett discrepancy 57.50 *
wo f* 0 *
*Excess Cash Removed 40.57 * Note that these
*Cash Shortage Made Good 113.78 * I figures do not relate
* to transactions and
*Nett Cash Adjustment 73.21- * so are not visible
BO nnn nn nn * to POL FS
(eM Ptrtittitititittterttitririrrrritrcrcircrss?
12
13 I VALUE-STOCK- MOP VOLUME VALUE
14 Value Stock will be
15 Cash 4293.11 removed from here
16 I CASH 4293.11
17 I Cheque 4032.79 INB Other Stamps
18 I CHEQUE 4032.79 will stay here
19 Giro Txfer 47.97 (none in the example)
20 I GIRO TRANSFERS 47.97
21 I Mop 8373.87 I Also ForEx Stock
22 i 20
23 INSETS 200-00
24 Red. 2 42-00
25 I—Game as 2 4-01
26 Deal 2 3.
27 Keep 2 3-00
28 IGAME LICENCES ——s—s—s—i—‘<~C~*s*=~=~=~*~=S DD
29 FDE 100 26-0
30 I Pres Pack 4500.0
31 I PHILATELIC ITEM: 152
32 I Reg -Plus—PE2 100 490-01
33 I -Sw&tPkc3Bure——______97_________484.00
34 I ist Class ——i—‘i BBG
35 I -2nd-Class —________15489 _______3697.80
36 I —Swiftpaekige 100 400-01
37 I dct 38-
38 I-Env-istClass 45.4
39 I —IntRepCoup. 9. 57
40 wnsle—Stmp 3-4
41 I Gas Toke: 449 449.
42 I -NatbetInstnt 495,
43 Bi 1 84
44 I ¥ALUB—STOCK_OTHER
i ee
46 I TOPAL-STOCK—& MOP 20798.71
0 i
48
49
50
51
3 March 2004 Version 1.0 Page 115 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
52 I RECEIPTS VOLUME VALUE
53
54 I Balance B/Fwd 21172.45 I Need to add in at
55 this point all Stock
56 Transcash 1 50.00 Imovement transactions
57 I GIRO DEPS/TRANSCASH 50.00
58 D/post inland 1 25.00
59 Parcels 25.00
60 I CARRS - PARCELS 25.00
61 BT bill pymnt 1 86.32
62 I TELEPHONE RECEIPTS 86.32
63 NS ord dep ac 1 200.00
64 INS 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 I OTHER RECEIPTS 621.32
71
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 I REMITTANCES IN 983.04
7
78 I Reval Up 0.00
79 --
80 I TOTAL RECEIPTS
81
82
83 I PAYMENTS VOLUME VALUE
84
85 OB chq to DPC 1 99.00
86 I Cheque 99.00
87 COB chque fee 1 5.00-
88 I Fee 5.00-
89 I OTHER BANKS CHEQUES 94.00
90 Giro w/drwl 2 100.00
91 I GIRO WITHDRAWALS 100.00
92 Debit Card 1 50.00
93 I DEBIT CARDS 50.00
94 NS ord w/drwl ac 1 150.00
95 I NS Withdrawals 150.00
96 INS WITHDRAWALS/PAYMENTS 150.00
97 C/dian money ord 1 80.00
98 International Money Orders 80.00
99 Moneygram rec 1 300.00
100 I Moneygram Receive 300.00
101 I Co-op csh chque 2 200.00
102 I Co-op Cash Cheques 200.00
103 I OTHER PAYMENTS 580.00
104] Rem Out Supp Div 0.00
105 I Rem Out Other Pos 0.00
106 I 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
112
3 March 2004
© Post Office™ 2004
Version 1.0
Page 116 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
113 I Total Stock & MoP 20798.71
114
115 I Nett discrepancies 57.50
116
7p enn nnn anne
118 I TOTAL PAYMENTS 22761.81
119 wenn nn nnn anne
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 ***
T 2 3 4
123456789012345678901234567890123456789012
20.7 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 [ffelaleiies) 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
01 Feltham Post Office FAD: 123456X
02 11:42 17/01/1998 CAP:01 BP:01 SU:SH1
03 Trial Balance - Office Copy
04
05 ******Discrepancies in this Account******
06 ‘Discrepancy OVER 4643.96 *
07 *Discrepancy SHORT 506.84 *
os *
09 *Nett discrepancy
10 *
*Excess Cash Removed 40.57 * Note that these
*Cash Shortage Made Good 113.78 * figures do not relate
* to transactions and
*Nett Cash Adjustment 73.21- * so are not visible
BO nnn nnn nn nn * to POL FS
MR TITiTtititittrttrtrttrrrtrrrttrrrrrrcrc ry
12
13° VALUE-STOCK-& MOP VOLUME VALUE I 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
21 Voucher 320.00
22 VOUCHERS 320.00
23° MOP 8693.87
3 March 2004 Version 1.0 Page 117 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
24 —Comcoin- 200.00
25 COIN SETS— 200.00
26 —Game Red ——2- 12.00
27 Game as 2 4-01
28 Game Dealers— ——2 8.00
29 —Game—Keeper ——2 —— 8.00
30 GAME _LICENCES— 2 —__ 32.00
31 PDE 100 26.
32 Pres Pack 1500.00
33 D/Whsle stmp 8.16
34 —GasToken— 149 149.00
35 NatLotInstnt— 495.50
36 MISCELLANEOUS— 647.66
37° Bus 1 Stock— 1225.00
38 STOCK SHELL 2-085— 4225.00
39 VALUE STOCK OTHER 1872.66
900 nnn nn nnnnne
41 TOTAL STOCK-& MOP 14283.69 This total is not
920 nnn nnn anne 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 Need to add in at
52 PO Foreign Exch In 500.00 this point all Stock
53 OTHER RECEIPTS 6441.30 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 Only on Final Balance
64
65 TOTAL RECEIPTS 49884.34
66 nnn nn nn anne
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
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
3 March 2004 Version 1.0 Page 118 of 120
© Post Office™ 2004
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
84 Rem Out Auto Dist 13351.50
85 I REMITTANCES OUT 21931.66
86
87 Reval Down 0.00
0.00 Ionty on Final Balance
88
89 Total Steck—& MoP 14283.69
90
91 4137.12- IMust be zero on Final
92 Balance
98 nnn nn nn nnn
94 TOTAL PAYMENTS 39954.13
ee
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 4500.00 Some of these do not
D/Whsle Stmp 3.16 have volumes here but
Gas Token 149 449.00 I should must in the
NatLotInstnt 495.50 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
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 tonncnne +
115 Signature. .....
116
117
118 Time . AM/PM +------- +
119
120
121 *** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
3 March 2004
© Post Office™ 2004
Version 1.0
Page 119 of 120
Doc Ref: BTRMC&TM-001
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
20.8 Remittance
Remittances In, Counter Weekly Remittances Out
In Slip, Remittance Out
Weekly Remittances Summary
1 2 3 4
123456789012345678901234567890123456789012
Slip,
Counter Weekly
and Counter
Notes
Feltham Post Office FAD:
11:42 17/01/1998 CAP:01 BP:01
Weekly Remittances In - Office Copy
SU:SH1
SESSION: 1-15578-1
DATE:10:44 17/01/1998
SOURCE:Rem In Auto Dist
PRODUCT ‘VOLUME VALUE
Euro TChq 1 0-90
250
PO £20 25 500.00
PO Fee 50p 25 6:25
Col TV Fee 10 865.00
Home Help D 25 143.75
BT Stamp £2 1000 2000.00
TOTAL 1086 3515.00
SESSION: 1-15639-1
DATE:11:18 17/01/1998
SOURCE:Rem In Auto Dist
PRODUCT VOLUME VALUE
Cash z 5000.00
Gas Stamp £130 30.00
Comeein 19 — 20.00
Game-Red- ——______2 12.00
TOTAL 43- 5000.00
*** END OF REPORT ***
123456x
Assume that all stock
REMs will only deal
in volume, even
value indicated
Stamps.
Forex will
show value as well as
volume
Cash REMs have no
volume
Any cheque and
dockets REMs will
also need to go onto
this report
1 2 3 4
123456789012345678901234567890123456789012
20.9 Office 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.
20.10Docket Rem Out Report
Need to make it clear that this single report is proposed as a replacement for the following:
3 March 2004
© Post Office™ 2004
Version 1.0
Page 120 of 120
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
= Counter Daily Cheques Listing
= Counter Weekly POs Paid
"Office Weekly POs Encashed
" Office Weekly Redeemed Savings Stamps Summary
" Office Weekly Redeemed Savings Stamps Summary: Reprint
{DN: Are the last 3 of these still required and if so what they should look like?}
This will be based on the Cheques Report. This is what is called “Voucher Docket Summary” in 8.6 (A4.1.2.5).
Separately, there is also a Rem Receipt which should be as in Section 20.8.
1 2 3 4
123456789012345678901234567890123456789012
Feltham Post Office FAD: 123456x
11:42 17/01/1998 CAP:01 BP:01 SU:SH1
Cheques Listing - Office Copy
TXN VALUE
1-59452-2 5.00
1-59452-5 6.00
TOTAL: 11.00
*** END OF REPORT ***
1 2 3 4
123456789012345678901234567890123456789012
20.11 Transfer 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.
1 2 3 4 Notes
123456789012345678901234567890123456789012
01 [Feltham Post Office FAD: 123456X
02 I 11:42 17/01/1998 CAP:01 BP:01 sU:SH1
03 I Transfer In Slip - Office Copy
04
05I SESSION: 1-21284-1
06 I Source SU:AAA Dest SU:SH1
07
08 I PRopucT VOLUME VALUE I Will need to report
09I 2nd Class 599 100.00 stock solely by
10I 1st Class 699 156.00 volume not value.
11I cash 1 600.00 Cash, ForEx and
12I col TV Fee 125 20012.50 Other Stamps by
13 I Mono TV Fee 22 627.00 volume and value
14I Euro 150 98.00
15] BT Pc 50 60 300-00
16I BT Pc 100 80 ——800.00
17I Game Blue 112 448.00
wf nnn ane
19 SESSION TOTAL 600.00 Total is now only
the total of entries
in the VALUE column
above. (i.e. cash,
FOREx and Other
Stamps transfers)
3 March 2004 Version 1.0 Page 121 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001 Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
20
21
*** END OF REPORT ***
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.
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
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
Version 1.0
© Post Office™ 2004
Page 122 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction Management
20.130ffice 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
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-
On nnn nn
09 I UNRECONCILED Transfer Value CCC to AAA 34.35-
Oe
11
12 I SESSION ID SRC DST BP DATE TIME MODE VALUE
13 I 1-19285-1 CCC BBE 01 08-Apr 20:38 TO 60.00-
14 I 1-19296-1 CCC BBB 01 08-Apr 20:39 ER 60.00
15I Transfer RECONCILED
16, Bree ene
17 I UNRECONCILED Transfer Value for CCC 34.35-
i
19
20 *** END OF REPORT ***
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
20.14Office 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 [41:03:48 3070372000
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] Aixr/crd single 1.00 1.09 31/03/2000
12 I Reg del env rg2 4.00 31/03/2000
13
14
15
16 *** END OF REPORT ***
T 2 3 4
3 March 2004 Version 1.0 Page 123 of 120
© Post Office™ 2004
Doc Ref: BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00089971
FUJ00089971
IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
123456789012345678901234567890123456789012345
3 March 2004
© Post Office™ 2004
Version 1.0
Page 124 of 120
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE. Transaction 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.
EventTitle All I Bal I SU I Re I Co I Re I Us I Sto I Us I Us I Ac
Ev I anc I Bal I po I nfi I po I er/ I ck I er er ces
ent I ing I anc I rts I rm I rts I SU I Un to s
s ing Re I Pr it SU I Co
po I od ntr
omcneocn
3 Inactive Rollover YY Y
Failed
4 Inactive SU Rollover
5S. Rollover Abandoned
16 Rollover Complete
YY
lY
YY
7 User attached ly
19 SU Created 1Y
SU Deleted ly
12 Logon Completed YY YY
IY
lY
YY
ly
YY
ly
YY
<
~<
13 Logoff Completed
14 Office Balance Failed
18 Delete SU failed
19 Delete SU failed
120 Delete SU failed
21 Declaration Complete
122 Declaration
Abandoned
123 Declaration Complete IIY Y Y
with Discrepancy
124 Position Locked (Y py YY
125 Position Unlocked lY YY Y
126 Unlock Failed ly py Y
3 March 2004 Version 1.0 Page 125 of 120
© Post Office™ 2004
Doc Ref:
BTRMC&TM-001
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00089971
FUJ00089971
Project: IMPACT - Branch Trading Reporting,
Management and Control and
Transaction Management
27
29
30
31
32
33
34
35
40
41
42
44
45
46
52
53
54
55
56
S7
58
S59
160
61
162
Forced Logoff
YY Y
Report Confirmed
Report Printed
<
Report Previewed
Inactive Rollover
Failed
=I <)<I=)<
im
Discrep Committed
Balance Checks FailedI
Balance Checks FailedI
Deleted (was
Revaluation
abandoned)
=) <I<I =
=I <P<l<
<I<[</I<
Deleted (was Cash
Acc Created)
Deleted (was Office
CAP rolled)
1Y
Deleted (was Office
CAP Roll Abandoned)I
Office Balance Failed
SU Balancing
Delete SU failed
Deleted (wasl week
CA)
=) <)=I <
Deleted (was 2 week
CA)
Deleted (was 3 week
CA)
INew events below here
Trading Statement
Created
ly
ly
Trading Statement
Period rolled
Trading Statement
Period Roll
Abandoned
IY
ly
Excess Cash Removed}
Cash Shortage Made
Good
Cash Variance Report
Previewed
Cash Variance Report
Printed
Outstanding
Ty
3 March,
orrection Reminder
© Rost onisplayed
Version 4.
Page 126 of 12
FUJ00089971
FUJ00089971
Doc Ref: BTRMC&TM-001 Conceptual Design Project: IMPACT - Branch Trading Reporting,
Management and Control and
COMMERCIAL IN CONFIDENCE Transaction Management
20.16 Office 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.
20.17 Return Advice Note
This will need changing since it includes stock values
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)
20.19 Other 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.
It is 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, a review of which reports are required to be re-printed
in this way must be made. It is assumed that there are no requirements for reports to be re-printed for
periods outside of the period of data-retention periods previously defined.
3 March 2004 Version 1.0 Page 127 of 120
© Post Office™ 2004