Accounting & Cash Management
Programme- Release 1
Conceptual Design
Version 2.0
POL00038866
POL00038866
DANIEL HAWTHORNE
SUE HARDING
CLIVE READ
LOUIS PRASTITIS.
[DATE \@ "dddd, dd MMMM yyy" ]
© Post Office™ 2003
Version 2.0
Page 1 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Table of Contents
Reference Data
Management Information
2.2.1. a
3 PROGRAMME OVERVIEW - RELEASE 1..
SS PROPOSITION,
HAND FUNDS MANA\
Key Priorities
Business Drivers/
1.1. st Office™ Strategic Direction.
41.2. Integration with Other Systems.
4.1.3. Post Office™ Approved Technolo;
414. Post Office™ Approved Components,
DESIGN PRINCIPLES
& BUSINESS REQUIREMENTS.
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 2.0
Page 2 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Automated ONCH....
Cash & Bank Ledgers
Automated Remittances.
Reference Data.
Information Flow
User Interfaces...
Reconciliation
Audit
5.6. Business Blueprint Implication:
5.7. Business Risk.
PROGRAMME TECHNICAL REQUIREMENTS..
ARCHITECTURE PRINCIPLES
Application
10. HIGH LEVEL PROGRAMME PLANNING...
10.
10.2,
li. PROGRAMME AC
TIMESCALI
“EPTANCE STRATEGY...
12, PROGRAMME IMPLEMENTATION & MIGRATION STRATEGY
APPENDIX A ~ CHART OF ACCOUNTS....
1 Decumont Control
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 2.0
Page 3 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Horizon Release No: S60 + Back End Release to be determined
Document Title: Accounting & Cash Management Programme Conceptual Design — Release 1
Document Type: Programme Conceptual Design
Abstract: This document details the Business, & Operational Requirements for Accounting
& Cash Management — Release 1, 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 Accounting & Cash Management — Release 1.
Document Status: Draft
Originator & Department: I David Parnell - Business Solutions.
Contributors: Karen Hillsden, Helen Pedley, Luxmi Selvarajah, Paul Antunes, Gareth Jenkins,
Jamie Dixon, Phil Boardman, Bob Gumey, Bob Cragg, Peter Flood, Stephen
Hirst, Andrew Carter, Paul Uden, Ann Clarke, Julie Pope, Jeanette Brown, Bob
Lammin, Keith Barney, Phil Stanton, Andy Corbett, David Anders, Matt Warren,
Neil Salter and others
Post Office Distribution: As per review details
Supplier Distribution: As per review details
Client Distribution: None
Table 1: Document Information
01 July 2003 First draft CT0044a
02 July 2003 Second draft after review of Reference Data
requirements
03 July 2003 I Addition of process descriptions
1.0 July 2003 Following final draft amendments
2.0 July 2003 Inclusion of Reference Data Process and clarification
of work packages
Table 2: Document History
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 4 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
18. Change Precess
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
4 Changes in this Version
0.41 « None — first issue
0.2 «Reference Data changes
03 * Addition of process descriptions
1.0 « Amendments to information flows, addition of Chart of Accounts
2.0 « Reference Data processes as a result of workshop and deletion of “Transaction
Management” aspects for Projects 1 & 3 — now proper to Project 2 (section 9 refers)
Table 3: Changes in this Version
15. —- Key Contacts
Business Process Architect
David Pamell
Table 4: Key Contacts
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 5 of 90
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038866
POL00038866
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
16. Review Dotalls
Post Office Ltd:
Head of Technical Architecture
Head of Business Architecture
Technical Design Authority
Business Design Authority
Delivery Manager
Release Manager
Clive Read
Sue Harding
Daniel Hawthome
David Parnell, Karen Hillsden
Louis Prastitis
Ray Jackson
Supplier Review
Project Managers
Business Review
POL
Gareth Jenkins, Bob Gurney, Bob Cragg
Bill Reynolds, Peter Flood
Stephen Hirst, Ruth Holleran, Vicky Noble, Ann Cruttenden, Ann Clarke,
Bob Lammin
Table 5: Review Details
0.1
AIS BPDES023.
February
2001
Study
LFS Application interface Specification
Business Requirements - End to End Re-
Architecting Post Office Product, Branch, Client,
Cash and Stock Processes & Systems Feasibility
Table 6: Associated Documents
Unless a specific version is referred to above, reference should be made to the current approved versions
of the documents.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 6 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: Poon ‘Cash Management
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
18. Abbreviations/Definitions
Abbreviation Definition —
OPTIP Operational TIP
CBDB Counters Business Database
NNDB National Network Database
ONCH Overnight Cash Holdings
DTI Department of Trade and Industry
uD Local Information Database
STAM System for Transactional Accuracy Measurement
SAPADS. SAP — Advanced Distribution System
ES-FS Enterprise Systems — Financial System
SAPHR SAP — Human Resources
RLM Retail Line Manager
RDS Reference Data System
Table 7: Abbreviations/Definitions
Other generic IT terms can be looked up at: http://www.whatis.com/
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 7 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
2. Introduction
This programme has emerged from the E2E Simplification feasibility study which has addressed the core processes of Post Office Ltd ~ Sales,
Accounting, Cash Management and Stock Management plus the support processes of Reference Data and Management Information.
The major recommendation of that study is the need to take complexity out of the business both in process and systems terms making it simpler to
work both at the branches and in central functions plus offering a reduction in IT systems costs through the simpler use of technology.
The primary reasons for implementing this programme are to:
Improve efficiency and eliminate duplicate processes and systems in the accounting and reference data areas specifically.
Implement a simpler accounting model which supports the speed of change and product deployment and makes the job simpler
and more flexible in branches.
— Account via a single authoritative transaction data source and thus create an effective debt management process decreasing debt
write offs.
Account separately for client and business funds to give a clear view of the actual assets and liabilities of each.
« Decrease operational cost
The programme has identified the following high level benefits
There are benefits of £7.0m per annum from 2004/05 (full year 2005/06) arising from the closure of Optip (€4.8m), CBDB (£1.2m), Reference Data
(£0.7m) and Small Systems (£0.3m).
There are benefits to be obtained from Fujitsu Services through the new Horizon contract of £2.8m from 2004/05 as a result of simpler accounting
and reference data processes. Fujitsu have stated that they can reduce their resources if Post Office Ltd simplifies its processes. £2.8m
represents an element of that reduction. These are over and above the current business plan.
Additionally, there is an opportunity to gain business benefits in the region of £4.4m through:
‘© Improving understanding of the cash cycle which will reduce interest payments
Implementation of a new accounting model
‘© Creation of an effective debt management process so reducing bad debts
‘Utilising a single authoritative transaction data source
Improved reference data processes
There are other potential benefits which:
«Improve the understanding of the cash cycle to:
Decrease holdings in cash centres by £15m
Decrease the cash cushion at branches by £20m
« Increase the visibility of other cash items by £10m
‘* Provide a robust statement of cash to the DTI which consequently reduces borrowing costs
Increase the capability to implement organisational change
The programme is primarily aimed at putting in new systems and processes to replace old systems and manual processes with the replacement of
four major systems: OpTIP, CBDB, Reference Data, NNDB and a collection of small systems
The current timetable and migration approach suggest a three phased approach to delivering the programme, with gradual build up of the ledgers,
with a target completion date of March 2005, The following are the key implementation milestone within the business case:
« — Release 1 - April 2004
e — Release 2- October 2004
© Release 3— March 2005
21 Purpose
This document is intended to detail the design for the Deployment of Release 1 of the Accounting and Cash Management Programme. Itis
intended to act as a reference for those involved in the various stages of design, development, deployment and support for the Accounting
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 8 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
and Cash Management Programme. It is also intended to support the concurrence and approval process required for this system to be
implemented.
Inputs
Feasibility Study and associated documents
Business Case
Outputs
Work Packages for detailed requirements phase of the programme.
Subsequent Supplier Design Proposals
Subsequent Supplier Technical and Application Interfaces Specification documents.
22 «= Scape
The overall scope of the programme is as follows:
Cash Ledgers
— Overnight Cash (Project 1)
— Automated Cash Bank Ledgers (Project 2)
Automated Cash Rems (Project 3)
Branch, Client & Stock Ledgers
Branch Liability Management (Project 4)
¢ — Client Settlement Ledgers (Project 5)
« Automated Ledgering of Stock (Project 7)
Complete Ledgers & Decommission
e — Personal Agent Ledgers (Project 8)
— Simplification & Improvements Transaction Processing (Project 9)
Reference Data
«Reference Data (Project 10 & 18)
Managemont infermation
Management Information (Project 12)
Release 1 of the programme focuses on the Cash Ledgers, Reference Data and Management Information
221. Exclusions
Releases 2 and 3 of the programme will be the subject of a further Programme Conceptual Design - the whole then being integrated
together. This approach is being employed due to the pressing timescales of the Horizon S60 release.
Releases 2 and 3 will cover
— Branch, Client & Stock Ledgers
Complete Ledgers & Decommission
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 9 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
23. Document Explanations
231. Creation Process
Details of the Business Proposition and Requirements have been provided by the Post Office™ Business Sponsor and representatives and
the Business Architecture Representatives.
The specific domains and owners are as follows:
Accounting and Cash Management - Stephen Hirst
« — Transaction Processing - Vicky Noble
Network Operations - Ruth Holleran
e — Cash and Logistics Supplies - Bob Lammin
The High Level End-to-End Solution Architecture and Architecture principles should be provided by the Post Office™ Technical Architect,
who should also provide the Technical Requirements and state the required Supplier Deliverables.
Once supplier domains have been identified assistance may be required from a number of suppliers with the above.
232. Business Process Models
Post Office's functional requirements are represented in the form of Process models using Business objects together with Process objects
and supporting descriptions and information flow definitions. The common tool used for creating these Process Models is Popkin Systems
Architect. An example of the high level process map is shown below.
Accounts and Settlement [IDEF0]
This depicts process boxes and information flows. Where appropriate each process box is then decomposed to a lower level process.
Systems Architect will also capture and manage the inter-dependencies between processes and ultimately the data attributes required to
create systems interfaces thus creating an overall IS architecture.
Boxes depicted in rd are part of the overall process but deemed out of scope for this particular part of the design.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 10 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
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: -
27?-xxx - where 727 is a fixed label corresponding to the project and xxx is the requirement number, starting at 001
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 11 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
3. Programme Gverview — Release 1
a1 Business Proposition
The business proposition for Release 1 covers Cash and Funds Management, Reference Data and Management Information. The scope,
Priorities and business drivers for each of these are specified below.
32. Cash and Funds Management
321. Scone
Management of physical cash within branches and cash centres including:
© Inventory Management
© — Replenishment Planning
® — Overnight Cash Holdings (ONCH) Control
© Distribution of Cash
Management of the overall liquidity of the business including:
© Cashflow
© — Borrrowings
322 Koy Prierities
2 fundamental changes have made Post Office Limited's funding position a critical business survival issue
© The business is trading at a loss
@ The migration of benefits to ACT will be accompanied by the loss of pre-funding by government departments of the
necessary cash in the network
The business now has to borrow funds to fund its trading losses and to fund working capital needed in branches. Such borrowing is limited
in availability and its costs add to the trading loss. From April 2003 DTI will provide a loan and will require a robust statement of cash
holding as security.
323. Business Drivers/Issues
There is a requirement to:
© — Drive down cash holdings and therefore reduce the DT! borrowing requirement, which in turn will reduce the level of interest
paid.
Bring together all the elements of cashflow and provide cohesive management to deliver cashflow targets.
Improve management information, linked to financial statements, to support the management of cash (funds)
To improve the financial controls for cash remittances, where there are losses of £5m per year
To account separately for client and business funds to give a clear view of the actual assets and liabilities of each.
To clearly show the overall indebtedness of clients.
To be able to accurately identify physical cash at outlet rather than overall cash which can include cash equivalents such as
cheques.
To be able to forecast and manage cashflow within the DTI target (£330m for 2002/03)
To have a single, comprehensive view of cash (funds) in one place
© — To improve the integration of cash centre holdings into cashflow management
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 12 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
33. Reference Data
3.3.1. Scope
© The current reference data processes and systems within POL are complex, inflexible and inconsistent, therefore the quality
of reference data is mistrusted.
© — There are several systems within POL which master items of reference data and there are several more systems which key
in their own reference data which exists in master systems.
© The process of making reference data changes is complex and lengthy leading to allegations thal the business cannot get
its products to market quickly enough. This is compounded by a boundary between POL and Fujitsu Services with various
systems and process interfaces between the boundaries.
© The scope of this work includes the simplification of the processes operating at the boundary between POL and Fujitsu
332. Key Priorities
© — Toensure consistency in reference data usage within Post Office and Fujitsu
© — Tosimplify the current processes
© — Toallow changes, such as organisational changes, to be implemented in a more timely fashion
333. Business Drivers/Issues
Support data driven change within the business where there is economic advantage to The Post Office
Reduction in operation costs
Removal of inconsistent reference data being used within the organisation
Allow for new processes which effect a vastly improved speed to market
Lack of a fully automated end to end process to capture reference data changes leads to delays and errors.
Locally held reference data will need to be removed and made available from a central source.
a4. Management Information
3A1 Scope
There is a four tiered scope:
Replace current legacy MI systems - notably LID, STAM and Intellect - by building on the current data warehouse
functionality and thus reduce operating costs to the business
© Provide a facility to enable basket analysis enquiry for Sales and Marketing
© Provide the capability to access management information through a single viewpoint
© — Restructure and improve the current design
Currently the Sales MI deliverable has produced a first cut data warehouse with sales transactions from Horizon and reference data in order
to:
© Deliver sales data into the operation in order to drive up sales
© — Delivering sales data to Sales & Marketing for marketing purposes
342. Koy Prierities
Replacement of current management information systems which add to complexity
Having systems which enable the quick production of MI to flexible organisation structures
Generating a commercial based culture in the retail line via profit and loss
Timeliness of information
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 13 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AceCM-PCD
343. Business Drivers/issues
© Sales Ml has been delivered but its primary focus of gaining a quick view of what is happening has been obscured by
demands to use the data for other things e.g. Settlement. The business has stated that this should not be the case,
although the data can be used for providing interim figures
© — There is lack of clarity between MI and operational reporting
© There is a need to be able to reflect current and ever changing organisational structures in the delivery of MI. Current
systems cannot do this and are based around old organisational structures which means the data produced is of little value.
© — Historical data needs to move with changes in the organisation so that it accompanies those changes. Currently this is not
possible.
The current granularity of the data used within Sales MI (Item/Branch/Day) is not deemed to be sufficient for future needs
Potential gaps exist e.g. Data from other channels like internet transactions
Business ownership of the data warehouse and the organisational structure required for Ml
Need to report out to the operation
Use of staff hours as an efficiency measure
Use of Mystery Shopper and report out results
Need to have more robust costing data and break down overheads into their constituent components.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 14 of 90
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Programme
Doc Ref:
‘AcoCM-PCD
POL00038866
POL00038866
‘Accounting & Cash Management
35. Functional Summary
The following depicts the high level processes and information flows between these processes.
Provide
Mea et Monagemert inomaton
OT eriton
Flareace Baia’ Stock Resauation kfamation
Management preauct Change Io — 3
% I ascome ‘Recounts bd I_POL Business Ledonr ES-FS)
o adig Tansectons Settlement I Aqusted Transactions
a Trading basis A ———
Reference Data & Business Rules Debt Recovery Amounts, Throvgy Payrot
Cheques Processed Cent Tarsaction Data Repo,
amine Setters
Branch Lsbity Statement
Customer Requirements! ‘SiocK Revaluation formation) ee
Enquites Recent Gient Setienert Data lement Payment to Cie
Bronch Closure Notice Payment Request to Cert
I a Enguly Response! After Sales Enaury Client Authorsations dented Tansectien Enars
A ier Report
Trensection Data :
ral hoemenis Costing Andysis
(Cash Centre Cash Holding Information .pI Mensetry Data
[branch Cash Hoidng Marketing Forecasts
Stock Usages Through Transadten Porn Season Data
Stock Holding Inermaticn huesiments & Boroungs
a
Sik 3 Cash Flow Forecasts 4
Meragement ‘Supplier Orders me
‘Siock Despeiches
Stock Receipts
Tocal Requirement Rrowledie
Product Marketing Knowledge
‘Giher Fulfiments
(Cash and New Cash Usage
Through Transactions
ash
ash Centre Transaction Data
jouthers Despatched
Paque and Voucher Values
‘Ereques Despatched
Consignment Note
pening Cash, Cheques and Vi
Cash ReceBts
Management
‘Gash Receipts fom Financial retiions
Cash Despatches
Local Cash Requirements
Customer Transactions ‘Cash Orders
‘Seasonal Date i) Cash Despatched to Financial Institutions,
Marketing Forecasts
pecs Management Report
(Cash Centre Cash Holding nfematon
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Re
‘Non- Conformance Reports
Gash Flow & Holdings Performance Data
Forecast Pertxmance
auch Delivery Contrmation to Cash Centre
Reports
Version 2.0
Page 15 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
36. Systems summary
The following diagram depicts the end state architecture:
Target Application Architecture
, ‘,
Clients x
RMG
x Financials
wa S-FS)
Casi
__--- Management
~~ (SAP/ADS
See
> Warehouse
Management
Figure 1 - End State Architecture
/
‘Counter “
Application I
For Release 1 the new ledgering system (POL Financials) will need to operate alongside the current legacy estate with prime accounting
still output from CBDB but with cash/funds management information available from PO Financials.
Systems with a blue border are current systems which will have changes made to them.
Systems with a red border are new systems
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 16 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Release 1 Changes
RMG
Financials
ES-FS)
RMG
HR
(SAP/HR
——_.
Clients ; Freasaction
Counter Logistics Feeder J
Application vice
° Reference
Data
Figure 2 - Architecture at Release 1
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 17 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
4. Programme Constraints
41 Architectural
411 Fest Cifice™ Strategic Direction
Ref Requirement Description
TEC - 001 The applications should be data driven
TEC -002 I The applications should be module were ever possible thereby allowing components, such as the
presentation layer, to be easily swapped out as more suitable modules become available.
TEC - 003 I Minimisation of duplicate functions
TEC - 004 I Consolidation of related processes, to minimise movements of data, reduce audit and reconciliation
points
TEC -005 I Adoption of commodity platform products to minimise hardware and associated support costs and to
maximise availability of skilled resources
TEC -006 I Usage of packages, where business requirements can be mapped onto generic product capabilities
TEC -007 I Clear separations of functional boundaries to retain flexibility in the future
412. Integration with Other Systoms
Ref Requirement Description
TEC - 023 I Integration with SAP ADS
TEC - 024 I Integration with SAP HR
TEC -025 Integration with ES-FS
413. Pest Office™ Appreved Technology
Ref Requirement Description
TEC -—026 I Refer to Royal Mail Group list of Approved Technology
ala Pest Office™ Appreved Components
Ref Requirement Description
TEC -027 I Refer to Royal Mail Group list of Approved Components
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 18 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5. Design Principles
State the general design principles and Generic Common requirements of the Project/System Name e.g. such as will not degrade
existing services. This should not be confused with Architecture Principles, which should be detail in section
(8.2).
Ref Requirement Description
ACM-001 I Any individual component of the programme must conform to the POL Strategic Data Model
ACM-002 I The solutions should meet the business design assumptions as stated in the Business Requirements
Specification (Feasibility Report) vsn 0.1
[DATE \@ "dddd, dd MMMM yyy" ]
Version 2.0
Page 19 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
6. Business Requirements
61 Overview
The business requirements are separated into their current component projects. Within these component projects there is:
— Asmalil number of high level requirements which define the scope - prefixed XXH-XXX
— More detailed individual requirements to support that scope
62. Business Requirements
621 Automated ONCH
Ref High Level Requirement Description
AOH-001 I To provide a system generated daily declaration of cash for despatch to SAPADS and movements
making up that declaration for despatch to the POL Financial System
AOH-002 I To provide the ability to accurately identify cash & near cash items as part of the customer session
Ref Programme Requirement Description
AO 001 The Horizon system to derive a total of cash and near cash items on a daily basis and make this available to SAPADS on
a daily basis at the end of business
AO 002 The Horizon system to maintain a record of accurate cash and near cash items as conducted during a customer session
~ options for achieving this to be investigated
AO .003 An up-to-date inventory (cash) position must be available to the outlet at any time.
AO 004 The Horizon system to maintain the current process of allowing an agent to make daily denominational level declarations
with no reference to the system derived figure.
AO 005 ‘SAPADS to receive both daily system derived figure and daily denominational figure (if entered) - SAPADS to use the
daily denominational figure as an override to the system derived figure
AO 006 Horizon to make available to the POL Financial System the daily movements which make up the system derived
declaration for entry to the cash ledger. The daily movements must reconcile to the system derived cash declaration
figure.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 20 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
622. Cash e Bank Ledgers
Ref High Level Requirement Description
CBH-001 To implement a cash ledger which accurately identifies cash and near cash items
CBH-002 To receive a daily interface of cash movement data and cash centre sales data for population of the
cash ledger
CBH-003 I To provide a daily interface of cash movement data and branch sales data for population of the ledgers
CBH-004 I To provide the facilities to input directly at the centre other cash transactions eg. bank account details
CBH-005 I To provide the facility to identify and manage financial discrepancies as a result of errors in the cash
movement process
Ref Programme Requirement Description
CB 001 A daily view of cash and near cash items to be maintained in a central ledger as delivered from
Branches and Cash Centres
CB 002 Ability to capture all transactions contained in the Bank Statements into POL Financials.
CB 003 Ability to input the necessary information to produce the Borrowings and Investments Ledger from the POL financials
CB 004 Capture all transactions relating to manual adjustments of the ledgers to establish the final reporting position for POL FS.
CB 005 A daily view of all cash movements to be maintained in the ledger - movements derived from both Branches and Cash
Centres
CB 006 Ability to produce DTI reporting requirements
CB 007 Ability to maintain integrity between CBDB and the new cash ledgers until such time as CBDB is decommissioned
623. Automated Remittances
Ref High Level Requirement Description
ARH-001 To enable the automatic booking in of cash at a branch on receipt from the carrier
ARH-002 To enable the automatic booking out of cash from a branch on hand over to the carrier
Ref Programme Requirement Description
AR 004 Receipts will be printed for completed transfers. Delivery & Collection receipts for driver and rem in receipt for outlet.
AR 006 Central Inventory Management must be aware of outlets where the system or connectivity is down
AR 008 Records will be produced for each inward order activity Le. 2 receipts produced at time of delivery containing value, file
sent to SAPADS
AR 009 Inventory items will be replenished by denomination
AR 010 All inward orders will include details of the content and planned delivery date i.e. Planned Order and Delivery Note
AR O11 Messages between outlets and Central Inventory Management must be timely i.e. Delivery note should arrive at outlet
prior to the pouch.
AR 013 Aconfirmation of order details will be transmitted to the outlet prior to despatch i.e. Delivery Note.
AR 014 Tokens will be used for all inward orders i.e. Pouch Barcode
AR 015 Each order must contain a picking list/delivery note giving the order number and content details
AR 016 Goods receipt token swipe must be linked to the delivery notification message at the outlet
AR 018 The verification process at delivery will not allow an office to receive an incorrect remittance. i.e. a rem intended for
another office.
AR O19 The details of receipt will be automatically booked into the outlet on delivery
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 21 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
AR 020 The carrier's driver will be given a physical receipt
AR 021 Confirmation of the order receipt will be transmitted to Ceniral Inventory Management ie. via pouch delivery file
AR 022 All deliveries will be automatically booked into holdings with the onus on the branch to identify and declare discrepancies
when applicable
AR 023 All inward orders must be counted by the end of the trading day following the day of rem receipt
AR 024 Outlets will be liable for discrepancies in unchecked orders after expiry of the checking period above
AR 027 Pouch contents will be printed onto the delivery receipt
AR 030 Inward order discrepancies will be transmitted to Central Inventory Management
AR 031 A facility will be available to raise discrepancies where the clerk / postmaster enters the correct amount and the system
automatically generates the discrepancy
AR 032 Receive and update cash holdings as a one stage process
AR 034 Accountability of “unplanned orders’, i.e. the facility to book-in the remittance value - ability to remit cash when the
branch is disconnected
AR 035 The process must support unplanned orders, ie. a pouch thal is rec'd prior to electronic notification record
AR 036 Deleted
AR 037 Tokens will be used for all outward orders i.e. Pouch Barcode
AR 038 The verification process at make-up of an outward rem will identify the cash centre to which it is to be delivered
AR 039 The details of an outward rem will remain visible within the stock unit until it is collected by the carrier but flagged as
“unusable cash”
AR 040 Holdings will be reduced when the outward rem is despatched to the carrier via token swipe of the carrier
AR 041 The carrier's driver will give the branch a physical receipt
624, Reference Data
Ref High Level Requirement Description
RDH-001 To provide one new system which allows for the decommissioning of RDS and NNDB.
RDH-002 To develop the new system to cater for organisational flexibility
RDH-003 I To provide new business processes which eliminate duplication across the POL and Fujitsu domains
RDH-004 To provide new business processes which allow for the capture of data at source
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 22 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Ref Programme Requirement Description
RD-001 Reference data maintenance should be brought within the direct control of the data owners.
RD-002 The need for duplicated data entry should be eliminated by replacing current legacy systems (RDS and
NNDB - and others) with a single master reference data source.
RD-003 Groups of detailed reference data changes comprising a single business change to be viewed and.
managed as a single integrated_business change
RD-004 Reference Data must enable any combination of the following events to be active concurrently:
different users carrying out data maintenance tasks on separate business changes simultaneously
simultaneous enquiries from other users
data extracts for data transfer to other systems
RD-005 Mechanisms must be provided to allow the entry, verification, authorisation and distribution of detailed
data changes to be permanently associated with the business change they are part of, and with other
detailed changes comprising the same business change.
RD-006 Workflow messaging should be provided to allow any business change to be progressed and it’s
progress to be tracked. The workflow processes must be configurable, and it must be possible to change
the workflow life cycle and introduce new additional life cycles.
RD-007 Provision must be made for the allocation of reference data maintenance tasks to be changed and
reorganised to allow the business to improve it’s manual processing systems, reducing duplicated data
handling and improving change implementation times.
RD-008 ‘A bulk upload facility to allow the update of large volumes of similar changes.. A typical example
would be the linking of products to all the outlets it will be offered in.
RD-009 Facilities for authorised users to produce standard report sets and user defined ad hoc reports using a
reporting tool
RD-010 Provide for the introduction and amendment of standard and ad hoc reports by authorised users using a
reporting tool
RD-011 Provide information on the progress and processing of reference data changes so that the update process
can be monitored and improved
RD-012 Data structures must apply business rules directly to ensure the integrity and quality of data.
RD-013 A single master repository for reference data should be provided so that errors due to replicated data
entry in multiple systems are eliminated.
RD-014 The data must be held in data structures that accurately reflect the Post Office business.
RD-015 The closure or deletion of any reference data object in the database must automatically cause the
closure or deletion of all its children
RD-016 All versions of reference data objects should be recorded and be able to show the changes to the object
and the user who made them The system must be able to apply reference data changes from or to
specific dates and times.
RD-017 Deleted
RD-018 Deleted
RD-019 It must be possible for administrators to create files from the database without the need for
modification or addition to the system software. Administrators must be able to define search criteria
for the user interface for a reference data object on any of it’s fields.
RD-020 ‘Must ensure that the implementation technology does not impose technical limitations on the
implementation of business change.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 23 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
RD-021 Deleted
RD-022 Must provide facilities to integrate with the automatic scheduling of file extracts and batch interfaces,
automatic generation of control files, and the automatic transfer of extract \ interface files to the target
system. It must also provide facilities for the automatic receipt and processing of any incoming files,
including the generation of control files. This process must be configurable.
RD-023 Deleted
RD-024 Must provide automatic means by which new extract or upload file formats will become effective at a
scheduled date and time and old interface formats will cease to be valid at a specific date and time
RD-025 Must use standard screen layouts and consistent designs for finding, adding, changing and logically
deleting reference data.
RD-026 Must provide drill down functionality through hierarchies of reference data objects
RD-027 Must be capable of supporting agreed service levels for enquiry, update and batch processing functions
concurrently — SLAs to be defined.
RD-028 The system must be able to perform all batch processing within the required batch schedules
RD-029 The system must be implemented without disruption to the service provided to the Post Office business
or to other systems supporting Post Office Automation.
RD-030 The implementation process must include adequate fallback provision to prevent service disruption in
the event of unexpected problems. Fallback provisions must remain in place until the system is proven.
RD-031 Adequate training and support must be given to users of the system and to users supporting fallback
provisions during the implementation process.
RD-032 Source data for the system must be validated and errors in the data corrected prior to implementation
RD-033 The system must provide adequate help facilities in the context of the overall business process.
RD-034 In implementing the system the overall quality of data must be improved, and the Business Change
Process improved and extended to ensure the quality of Reference Data does not regress.
RD-035 The process and the system will provide data ownership mechanisms which will allow these
responsibilities and accountabilities to be enforced. In implementing the process and system formal
data ownership must be allocated to the appropriate business users to ensure accountability for data
quality.
RD-036 NBSC need access to accurate records of outlet closures, re-openings and contact telephone numbers. to
support their customer and internal support services. The quality of the information held in current
systems is not adequate for this purpose.
RD-037 The interface must pass a complete, accurate data set to all current interfaces.
RD-038 Operations staff need to have direct access and visibility to the system to enable them to maintain
network records
RD-039 Operations staff should have access to ad hoc reporting tools accessing reference data
RD-040 Tt should be possible to rationalise the system with NSBC data bases that duplicate the same
information
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 24 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
RD-041 Increase the scope of data held in the in the system, particularly:
¢ — toreplace the shared reference data elements of Smartpost
© — toreplace local systems and spreadsheets that are currently used and maintained by regions
© — to support requirements such as configuration management and outlet equipment that require
more detailed information on objects currently held as reference data
© — to support reference data for other Post Office Ltd units such as C&LS
e to replace any other reference data update that is carried out independently of the system.
RD-042 NBSC require some data, particularly the OOH contact list to be available 24 hours per day.
RD-043 Any data that is not actually used should be removed from the scope of reference data. (It is suspected
that there are examples in NNDB of data that is maintained, but never used. It would require some
investigation to ensure only unused data is removed)
RD-044 Deleted
RD-045 Deleted
RD-046 Some outlets have different opening hours in summer to those in winter. Currently the opening hours
have to be changed twice a year ( if they get notification). The system should be able to cope with this
change automatically.
RD-047 The system should provide facilities to group objects, particularly products & outlets into structures to
provide an effective means of managing similar products as a block
RD-048 Improved Product and Outlet Management must be provided
RD-049 The implementation of product and outlet structures must substantially reduce the need to apply high
volume changes to reference data
RD-050 Facilities must still be retained to allow large volume “one off” changes (e.g. an external restructuring
of telephone codes) to be implemented by special processes
RD-051 The change process should cover the complete range of reference data changes that occur within the
Post Office A unique change control number should be allocated automatically to each business
change, and this should be linked automatically to all consequential data changes
RD-052 Deleted
RD-053 The new business process must provide for changes to be built up over a period of time as information
about the change becomes available, allowing amendment to the data by authorised staff at any time up
to the release of the data for implementation
RD-054 The business process must have clear ownership of data enforced by the process and system, with
effective responsibilities and accountability for the accurate maintenance of the data. Data ownership
must be applied to each element of data
RD-055 The system will allow changes to be entered into a product or outlet record up to the time that the
record is authorised for release to Pathway.
RD-056 PACE change number needs to be held and tracked for verification purposes in the new system
RD-057 The system must be able to support the ability for a number of process steps in parallel pertaining to an
individual change
RD-058 Addresses held in the database should be generated by the same PAF facility being used for Advanced
Data Capture
RD-058 OBC forms to be replaced by an electronic data stream from POL to Fujitsu
RD-059 Remote access for data entry is required
RD-060 The system must be able to handle business rules
RD-061 FAD codes will remain
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 25 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
RD-062 The system must be able to calculate the timings of different process steps in relation to the end date
required for the whole process
RD-063 Access to the system will be by roles
RD-064 Both internal and external access will be required — e.g. POL and Fujitsu
RD-065 Simple reporting facility needs to be available against the system
RD-066 Analysis which utilizes reference data should be achieved via MI Data Warehouse
625. Management Infermation
Ref High Level Requirement Description
MIH-001 To restructure and improve the design of the data warehouse
MIH-002 To provide one new system which allows for the decommissioning of LID, STAM and Intellect
MIH-003 To provide a mechanism which will deliver basket analysis requirements to Sales and Marketing
MIH-004 I To provide the mechanism for a single view of management information irrespective of the number of
sources
MIH -005 I To capture the current outputs of the various legacy systems, assess their usage and, if still required,
determine their new source
MIH-006 I To provide performance based analysis
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 26 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Ref Programme Requirement Description
Overall MI (Mandatory)
MI-001 Outputs and interfaces which currently exist must be given a home in the future — following
justification of their existence
STAM (Mandatory)
MI-002 The business requirement is to be able to feed back to branches details on the errors they make.
MI-003 The system must be able to accept error details {branch concerned, type of error, cash account week,
number of errors of that type} from the following sources: -
1. DVLA (around 4000 per month) (Presently supplied on paper. So details are keyed in.)
2. “OBCS” (700 per month) (Supplied on disc.)
3. Benefits Agency (other than OBCS) (Around 1300 per month) (Mostly supplied on disc,
but one error type—“BA11”—details are supplied on paper. About 30-50 BAII’s a
month.)
4. GIRO (Around 1000 per month.) (Supplied on disc.)
National Savings and Investments (although we do not currently receive data from NS&1)
MI-004 A person with appropriate system authority should be able to amend any of the entered
errors. (i.e. Reverse error completely, alter number, error type, or cash account week.)
MI-005 It should be possible to enter, amend, and delete the following standing data: -
e Error type details
e Management Hierarchy details to allow summary reports to be available for each
level of the management hierarchy.
« Calendar details. (So that reports can be available for a specific cash account
period, quarter, half year, year, or a range of accounting periods such as periods
2 to 5 for 2002/03.)
MI-006 Each branch should be informed of the errors it has made.
MI-007 Be able to supply RLM's, Heads of Area, Heads of Segment with appropriate summary
details of the errors in their area
MI-008 Make it easy to feed in extra error information in the future.
MI-009 To work out a notional cost for recorded errors for each branch.
MI-010 Include appropriate branch error information on outlet contribution statement
MI-011 RLM, Head of Area, Segment, and National level summary reports. (Either for direct
access by relevant RLM, Head of Area, etc. or make it easy for reports to be sent
electronically.)
MI-012 Ability to support analyses to: - a/ Reveal branches and RLM areas where error record is
particularly good or bad, compared to business transacted b/ Reveal branches or outlets
where error performance is worsening.
LID (Mandatory)
MI-013 The business requirement is to be able to produce outlet contribution statements. These statements
should be capable of a very high degree of accuracy...
MI-014 The system must be able to provide reports on: -
¢ Volume and value of outlet based sales.
e “Notional” income. (ic. “Income” calculated by multiplying outlet value or volume of
sales by a standing factor.)
¢ Network costs.
© Contribution. (i.e. Difference between notional income and costs.)
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 27 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
MI-015
It needs to be possible for reports to be able to show actual to budget or actual to plan
comparisons.
MI-016
The system must provide functionality to interrogate sales transactions, notional income, and cost by
the following 4 main hierarchical reporting dimensions:
© Product: Markets> >Product Groups>Items
e Client: Market> client group> client
e¢ Network: National Network>Executive Director> Head of Segment> Head of
Area>RLM>Outlet
e Periodicity: (a) Year>Accounting Period>Day (b) Year>Cash Account
Period>Cash Account Week> Day
Outlet Type is in addition to the 4 main dimensions: (i.e. be able to analyse results into outlet types
such as large, medium and small sub scale payment offices.)
MI-017
The system will provide the following report types
*° Onscreen
e Flat file electronic download. In particular, it should be easy to schedule “standing”
reports, and output them to a particular directory, so that they may be easily
transmitted by e-mail.
e Paper
MI-018
The system must provide the flexibility around reporting dimensions. It should be possible to “Pick and mix’ from the 4
reporting dimensions.
MI-019
The reports sent to users will either identify any offices not included, or identify the level of
offices not included
MI-020
The system must hold for an appreciable time (3 months or over) a base record, compressed
from the original transaction data, but still holding enough details to provide extensive and
flexible analysis
MI-021
Outlet level data will be available, at a “higher level of periodicity” than a day (e.g. Outlet week
or outlet month) for an appreciable time.
MI-022
Daily level data, at a organisation level higher than the outlet (e.g. RLM area or segment) will
also be available for an appreciable time
MI-023
Detailed (item/outlet/date) historic data will needed to be available for at least 3 months.
Summary level data may be held for up to 5 years.
MI-024
The system should be capable of reporting “flash” reports within 4 working days of the original
transactions. Users should be are aware of: -
e Level of missing offices, if material, when reports are run.
e Missing data streams when reports are run
MI-025
The system should be capable of taking error notices issued to outlets into account.
MI-026
The system will provide the functionality to accept and store information from a range of appropriate
sources. e.g. Ability to accept forecast data from an Excel spreadsheet.
MI-027
The system and the systems reporting parameters must be driven using reference data to maintain the
integrity of the data and to ensure consistency with the Operational systems.
MI-028
System reporting parameters must deal with the historic changes in reference data appropriately.
MI-029
The system will provide the functionality to output the results of a report to initially screen and
optionally to printed copy or CSV file format, for import into Excel, Access etc. It should be possible to
schedule frequent “standing reports” to run over-night for subsequent dispatch.
MI-030
The system will provide a mixture of overnight reporting and ad-hoc enquiries (o be returned during the
day. Present POLMIS times will be acceptable as long as these are not degraded due to greater system
usage.
MI-031
The system must be available, as a minimum, Monday to Friday 8AM -7PM
OPERATIONAL MI (Desirable)
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 2.0
Page 28 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
MI-032 The system should meet the Operation MIS reporting requirements as specified in the MI Workshop by
providing reports, summarization and drill down facilities
CURRENT DESIGN IMPROVEMENTS (Desirable)
MI-033 The organisational hierarchy which is currently referenced on RLM etc. name not the numeric
identifier, The latter is required
MI-034 'CTT Sub Group' table needs to be renamed ‘CTT Number’
MI-035 Atable for CTT number descriptions is require
MLO36 "CTT Group Des¢’ table need to be renamed ‘Sales Reporting Group”
MI-037 The option to for users create further custom groups of branches that fall outside the network structure within the system
would be useful, for example all Asda
MI-038 The facility to report from the Data Warehouse is available to a limited extent via the service contract with Pariy carrying
out reporting. We need to understand the feasibility/costs of brining this functionality into PO Ltd
MI-039 A front end user tool to create product / expenditure groupings easily and without the need for constant system updates
such as is required at present.
PORTAL ACCESS (Desirable)
MI-040 Development of the system to capture additional PI data to enable the system to become the one access point black box
MI-044 Development of portal for access of results by retail line
BASKET ANALYSIS (Mandatory)
i042 Daily reporting on sales across all product calegories
i043 Daily reporting across all branches and segmenis
Ml-044 Weekly and monthly reports by branch and operator (each operator must have a reference and must use this as they log
‘on for each session)
MI-045 Daily reporting across all channels
MI-046 Daily reporting by value, volume and margin (all products)
MI-047 Ability to track sales generated in one channel and executed in another (i.e. where a consumer takes an application form
with a FAD code from a branch and then completes this on line or via telesales — the objective would be to ensure that
the branch and the segment is rewarded for their part in the sale and that we can track the success of multi-channel
campaigns.
MI-048 Provide the reporting basis for targeting product categories on their overall sales by volume, margin, value and mix.
MI-049 Identify the progress of the business against target - volume, value, margin, mix: for all products.
63. Exclusions
A number of facilities or implementation methods are described in the Feasibility Study ref: . E2E Simplification - Business Requirements
Specification (Vsn
2.0) Post Office confirms that that the following items are not required in the Accounting & Cash management
Programme solution: -
Feasibility Study ref: £2E Simplification - Business I Comment
Requirements Specification (Vsn 2.0) Process Area
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 29 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Feasibility Study ref: E2E Simplification - Business
Requirements Specification (Vsn 2.0) Process Area
Comment
Sales
All references to Prompts and Help in the sales process are not included
Inventory Management
All references to Cash and Stock inventory management are not
included - eg. electronic ordering and management of stock inventory
items
Local destruction of stock is not included
Printing of virtual and transaction stock is not included
[DATE \@ "dddd, dd MMMM yyy" ]
Version 2.0
© Post Office™ 2003
Page 30 of 90
POLO0038866
POL00038866
Programme Conceptual Design Project Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccOM-PCD
6A. High Level Process Medels
[DATE \@ “dddd, dd MMMM yyyy" ]
Version 2.0
Page 31 of 90
© Post Office™ 2003
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
AO - Post Office Processes in Scope
Reference aia
Management
1
at
Reference Data & Business Rules
Customer Regu
Enquines
sae
Stock Revaluation Information
Product Change fo
Managemert Information
>
aS ABC Data
“aang Transactions
‘rang Debts —*}
Cheques Processes
‘acount ard
‘Settement
POL Business Ledger (ES-FS}
‘Adjusted Transactions
I __Adusted Transactions
Debt Recovery Amounts Though, Payroll
‘Clent Transection Data Repory
reamine Setlement=
Branch Liability Statement
T5eK Revaluation Fiermation
Recent “Giient Sefemeri Oaia
Enquky Respenseihiter Sales Enauy
Branch Closure Notice
‘Cent Autherisations
Settiement Payment to Client
Payment Request to Cliert
Identted Transaction Errors
‘Stock Usages Through Transad
Transaction Data
‘Stock Holding InformationI
eat
‘Gash Movement nals
(Caan Centre Cash Holding niocna Mandatory Data
Branch Cash Had Marketing Forecasts
oes ‘Seasonal Data
Investments & Borrovings
See
ashy
— Caaf Flow Forecasts
Si
Management / Supper Orders mt
Stock [Btock Despatches
Coal Requrement Kronbeape
Produet Marketing Knowfedge
Seer Feiner Pouch Dever Confirmation Cash Centre
2 ash Cane Tansacton Data
‘Cash and Near Cash Usage
‘Treaugh Transactions
loubhers Despatched
{que and Voucher Values
heques Despatched
Opening Cash. Cheques and VE
ash Receipts
Gash
Management ‘Consignment Note
‘Gash Receipts fom Financial ins
hone
4
Toeal Gash Requitemeris information
Customer Transactions
‘Seasonal Data
‘Marketing Forecasts
‘Specials
a——— ‘Cash Despatches
Cash Orders
‘Cash Despatched to Financial Institutions’
Management Report
Cash Centre Cash Holding lnprmation
[DATE \@ "dddd, dd MMMM yyyy"
© Post Office™ 2003
Tion-Contormance Reports
Gash Flow & Holdings Performance Data
lanai 8 id
L ae Forecast Pertrmance Reperts
Version 2.0
Page 32 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A‘ - Reference Data Management
Client Reqts
Data Request
[DATE \@ "dddd, dd MMMM yyy" }
© Post Office™ 2003
Make Product
Changes
1
All
Reference
. Data
New Data Triggers *————} Verification
3
A13
Make Branch
and
Organisation
Changes 2}
A12
Version 2.0
Ref Data File
Page 33 of 90
Data
Verification
4I
Al4
Live Ref Data
POLO0038866
POL00038866
POLO0038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A11 Make Product Changes
Rejected Change
Initiate Log in PACE
New/Changed I Change Request
Product
imi
Client Managers — Product Deployment Team Product Deployment Team
Client Reats
)
Impact Assessment Request
Perfom Impact] ‘Agree Change I_I
Assessment Change Definition ~ Initial Data Items
ie) 0}
i New Data Triggers
Stakeholders PACE Team
Client Managers: Product Deployment Team
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 34 of 90
© Post Office™ 2003
POLO0038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A12 Make Branch and Organisation Changes
Initiate Non- Rejected Change
Data Request ‘Advanced
Change
f) Log in
Branch/Org
MI Team’
Change Request ‘Change
Initiate I O}
Advanced Change Request
Change
Mi Team NIET
t NET Impact Assessment Request
Perform impact
Assessment
i)
1 ‘Agree Change I__I 0BC 20 Send to Fujitsu
—_——
‘Stakeholders Change Definition d Initial Data Items oI
Enter Data I}—*
tems [New Data Tigger
OBC 20 Source I
MI Team ft f NIET
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 35 of 90
© Post Office™ 2003
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A13 Reference Data Verification
New Data Triggers
Verifyier I Verified Mandatory Data
Completeness
d
Prontse Pure, basis & advanced products Branch and organisation changes
Network Change Team
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
© Post Office™ 2003
aptured Data
Verify and
puthonise Datal
)
Change Originator
Verification Report
Authorised Data
RefData File
Data Feeds
Network Change Team
Page 36 of 90
>
‘Automated Advice of Changes (OBC 2 data)
Updated System
Reports
User Access,
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A14 Data Verification
Exceptions
erform }
i i
Ref Data File >!
Verified Ref Data
Automated Advice of Changes (OBC 2 data)
Authorise Live Ref Data
Release into I___,
Live
Fujitsu Network Change Team o)
Network Change Team
Pre Authorised Changes >
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 37 of 90
© Post Office™ 2003
POLO0038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A2 - Sales
Reference Data & Business Rules
Re-start Trans.acton/Session Paused Transaction/Session
Reference Data & Business RulesI
Cancelled Transaction
Customer Requirements/EnquiriesI
et al Transaction Information
ncelled Transaction
sais Cancelled transactior
Customer
‘Transaction Data
Session
Receipt
‘Stock Usages Through Transactigns
[Stock Ussaes Through Transaciys
Transaction Info
Stock Holding Informatio —
J ‘Gash and Near Gash Usages Through Transactions
Trans geton Authorisatibn / Bara inform atiqn
Non-Authorisation
Session Adjustment
Rett rence Datal& Business Rulqs Client Authorisations
Responses to Enquiries
——ee
Enquiries ‘Aer Sales Enquiries Requests for Authoriation frm Gil
aa a
Client
Branch Point of Sale
[DATE \@ "dddd, dd MMMM yyy" }
Version 2.0
Page 38 of 90
© Post Office™ 2003
POLO0038866
POL00038866
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
Programme
Doc Ref:
‘AcoCM-PCD
‘Accounting & Cash Management
A25 - Settle Customer Session
Transaction Authorisation / Extra Information
Transaction Info
Reference Data & Business Rules
RequestI payment Request
Settlement
' Cancelled Transaction
Wakerfake =
3) Payments Session Adustments
Payment Information
an
Payment Aubore ton fp raged)
Payer
Payment A uthorisatior/Non-Authorisation
Reference Data & Business Rules
tod Transaction Data
‘Transaction I Stock Usages Through Transagtions
Details
gp}
(Cash and Near Cash Usages Through Transactions:
[DATE \@ "dddd, dd MMMM yyyy"
© Post Office™ 2003
Produce
Posies Recebt
Version 2.0
Page 39 of 90
POL00038866
POL00038866
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A4 - Accounts and Settlement
[DATE \@ "dddd, dd MMMM yyyy"
Version 2.0
Page 40 of 90
© Post Office™ 2003
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A48 - Produce POL Ledger
Produce Ger.
L 1 _I Debt Infomation
Trading Transsctons
Tia Bana > Fonona I FOL ausnemLesseriESFS),I Ledge Tt Nominal edger] Consiaate/ POL BudnessLedger E545)
‘tedoer Branch Ledger ager sogh Rewew and Rep
3 3 ‘©
F
a2
Oiserepencies
Debt Recovery ems
Bank Statements
a Bank Ledge
recessed fp
Sreamiine SeWlements
tine Trin
edger
Invesments& Borowings
vert
ch
Liabiity
Branch Cloaire Nowe Managemer_entited Transaction Engrs
abe
of Produce C33}
BorouingsandI
edger
Produce Stoci
Ledger
[DATE \@ "dddd, dd MMMM yyyy"
© Post Office™ 2003
Finance
Version 2.0
Page 41 of 90
POL00038866
POL00038866
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
A485 - Produce Cash & Bank Ledger
Streamline Settlements > Bank
Cheques Processed yp Accounting
Bank Statements
> 1
A4851
Bank Account Info
General Ledger
Processing
POL Business Ledger (ES-FS)
Ledger Entry Information
[DATE \@ "dddd, dd MMMM yyy" }
Version 2.0
© Post Office™ 2003
2I
A4852
Page 42 of 90
ad
POLO0038866
POL00038866
POLO0038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A4851 - Bank Accounting
Bank Statements Processing of Bank Account Info
i
Statements
1
Streamline Settlements
Cheque
>I Management J
>
Cheques Processed 2I
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 43 of 90
© Post Office™ 2003
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccOM-PCD
4852 - General Ledger Processing
Ledger Entry Information [eC Stings in G/LI POL Business Ledger (ES-FS)
+}
1
Postings Info
Account
Clearing [GL]
[DATE \@ "dddd, dd MMMM yyy" }
© Post Office™ 2003
Version 2.0
Payments and Receipts Info
General Ledger
Account Analysis
3]
Accounts Reports
Page 44 of 90
Closing Operations.
(Period End
Closing)
POLO0038866
POL00038866
POLO0038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
Ad - Provide Management Information
“Tersacton Data I gence Vanagemert ntrmation
Praauve Stk \vanagemant hfomaon
Praaice
Accourting Mi
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 45 of 90
© Post Office™ 2003
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A6 - Cash Management
raven casnhoang te Cosh ang
Srmenconntiang nas ore ChargeRewets
: Coan Farca aang Fans
(rescore
I
i coin cute Teanstin Data
Cosnaraeer Camm Usegee THoah Tesschtay SecA] )] enoanen J CRRERRT CF) -comospaetasto reer acta ——
“Sg ah Cine aVari ape Peron sa oan anager
Loa Ca Rereen rmaon ee 5 7
a veushrs pt [ae specits
+ 1) Grae sVarhe Vater I area Force
“ Coon Recast inning I a a cance)
cmt doin ca i; tenet I conor
cuoueaene . a Cannons Halt Partrance Ot,
i Cosntangernt Care arson aropenntRagot
comnbesroetes [
wis
Carigrtt
Cosh ete Cash hg natin .
Pouch DaheryCortmatont Cash Cone
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 46 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A611 - Branch Cash Management
Cheques and Cheque and Voucher Values
Voucher
Verifcation and Cheques Despatched
Despatch Vouchers Despatched
9)
Branch Cheque and Voucher Holdings >
Cash Received
Cash Veriicatio Branch Cash Holding
& Declaration
Branch Cash holding for Cash Plaming
Cash Receiots __,[ Receive and
Verity Cash
Aete Delivery Pouch Delivery Confirmation
Cash and Near Cash Usages Through Transactions — Consignment Note ») 4
Aeid
Record and
Monitor Cash
+ and Near Cash)”
Opening Cash, Cheques and Vouchgs———} Hot
Branch Cash Opening Position and Usage:
Cash Despatches
Despatch Cas} "PS _
Pouch Collection Confirmation
een
5}
Ae
Amounts tq Despatch
Review PlannedI_)
Plamed Cash Oniers Orders and I as omer
Local Cash Requirements information JReauest Crees
Cash Despatched
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 47 of 90
© Post Office™ 2003
POL00038866
POL00038866
POLO0038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A612 - Cash Verification & Declaration
Branch Cash for
Branch Cash Opening Position and Usages Cash Planning
Branch Cash holding for Cash Planning
> (ONCH) 7 >
for Accounts Branch Cash hoijagdaraehHuenning
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 48 of 90
© Post Office™ 2003
POLO0038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A614 - Despatch Cash
Amounts to Despatch Prepare Pouch
oon il
Prepared Pouch
REM-out
Pouch -pending
arrival of Carrier
Amounts REMed out awaiting despatch
Cash Despatched
Barcode Scan >
Carrier Pouch Collection Confirmation >
ae
Cash Despatches
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 49 of 90
© Post Office™ 2003
POLO0038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A615 - Receive and Verify Cash Delivery
Cash Receipts Recieve and Pouch Delivery Confirmation
Scan Pouch iad 7 >
>) from Courier Cash Received
Consignment Note 4
Verify Pouch
Contents ?
a Discrepencies in cash pouch
2
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 50 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
65. Business Area Processes
651 Precess Bescriptions
6.5.11 Receive and scan pouch from carrier
Cash Receipts Recieve and Pouch Delivery Confirmation
‘Scan Pouch
from Courier Cash Received
Consignment Note 4
Verify Pouch
Contents
Discrepencies in cash pouch
Description: This process provides a constraint between the physical delivery of cash, by the carrier, and the updating of the information in
the various accounting systems of the liability for the cash. It is designed to remove the possibility that system updates may not transfer
liabilities for sums of cash when the cash has physically transferred location but not recorded as received by the postmaster. This, therefore,
supports the production of a more robust statement of cash holding.
On arrival of the carrier the agent would enter a part of the counter system which will demand some token data (barcode on pouch). The
system would then verify the delivery, and obtain remittance data from the consignment note sent by cash handling. Once verified, the
system will produce the paperwork (receipt) and update the cash figure within the stock unit.
As a result of running this process; the branch accounts will be updated with the liability of the value of the cash in the pouch (the branch
accounts will then provide the onward updates of the overall POL accounts) and the delivery confirmation information should be prepared
and transmitted to the Cash Centre accounts system, via LFS.
Triggers: The agent choosing the function within the Horizon counter system, on arrival of the carrier, triggers the process
Frequency of operation: On average the cash is delivered to a branch twice a week
Volumes: The process is operated once per cash delivery, per pouch.
Automation: Once the process has been selected from the counter system the process should operate with minimal intervention from the
agent, who should only be required to enter the token data, ideally by bar code scan or some other token reading function. Requirements
for instigating the counter transaction by the token read are to be investigated as part of the detailed requirements analysis.
Locations: To be performed at all branches where the Horizon counter system is available
Input requirements at the WP boundary: Apart from the trigger to instigate the process the only information flowed in to this process is;
the consignment note, containing a specified value of cash.
Output requirements at the WP boundary: The process outputs the following information;
= Pouch delivery confirmation —a piece of information flowing to the cash management system to inform its accounts that this
cash has now transferred liability.
= Discrepancies in cash — a piece of information flowing to the Physical Cash Management system to inform its accounts that
there is/was a discrepancy noted within the cash delivery.
= Receipt — a physical receipt printed part of which is signed by the carrier and the agent, part of which is taken with the pouch
by the courier.
= Remittance Slip - A physical printed slip which contains details of the value that has been remitted into the stock unit, for
checking purposes.
Time Constraints: None
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 51 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Fall back procedures: In case the counter system is unavailable when the courier arrives or the pouch token data is unreadable (bar code
doesn't scan) it should be possible for the agent to manually enter the pouch token code. Each occurrence of this happening should be
recorded for management information. In case the consignment note has not been delivered to the branch, the pouch should contain a
physical advice note, upon which is a token who's data contains the value to be remitted into the stock unit. Each occurrence of this
happening should be recorded for management information and subsequent investigation.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 52 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
6.5.1.2 Barcode Scan Carrier
Description: This process provides a constraint between the physical collection of cash, by the courier, and the updating of the information
in the various accounting systems of the liability for the cash. It is designed to remove the possibility that system updates may transfer
liabilities for sums of cash when the cash has not physically transferred location, as may happen when an agent REMs out a pouch of cash
some time(days) before the arrival of the courier in preparation for despatching the cash. This, therefore, supports the production of a more
robust statement of cash holding.
On arrival of the courier the agent should be able to enter a part of the counter system which will demand some token data (anticipated to
be a token held by the carrier such as an authorised collectors card) which will uniquely identify the courier and/or verify that the courier is
present (it is anticipated that the code will be of a verifiable value. requirements for managing/changing the valid set of courier codes are to
be investigated as part of the detailed requirements analysis). Only on validation of this token data will the counter system proceed to
produce the paperwork (receipt) to allow the despatch of the pouch of cash.
As a result of running this process; the branch accounts will be updated with the reduced liability of the value of the cash in the pouch (the
branch accounts will then provide the onward updates of the overall POL accounts) and the Branch Consignment Note information should
be prepared and transmitted to the Cash Centre accounts system.
Triggers: The agent choosing the function within the Horizon counter system, on arrival of the courier, triggers the process
Frequency of operation: On average the cash is despatched from the branch to the cash centre once every 2 weeks. However cash
positive branches (where cash receipts > cash pay outs), of which there are around 150, can despatch cash as frequently as twice per
week.
Volumes: The process is operated once per cash despatch.
Automation: Once the process has been selected from the counter system the process should operate with minimal intervention from the
agent, who should only be required to enter the token data, ideally by bar code scan or some other token reading function. Requirements
for instigating the counter transaction by the token read are to be investigated as part of the detailed requirements analysis.
Locations: To be performed at all branches where the Horizon counter system is available
Input requirements at the WP boundary: Apart from the trigger to instigate the process the only information flowed in to this process is;
the information that a pouch, containing a specified value of cash, has been made up in preparation of being despatched and the courier
token data value.
Output requirements at the WP boundary: The process outputs the following information;
= — Cash Despatches -Value of cash despatched to update the branch accounts, from where the overall POL accounts will be
updated
= Branch Consignment Note — a piece of information flowing to the Physical Cash Management system to inform its accounts
that this cash has now transferred liability to it, This should also carry the courier token data for subsequent verification and
analysis.
= Receipt — a physical receipt printed part of which is signed by the courier and retained by the agent, part of which is taken
with the pouch by the courier.
Time Constraints: None
Fall back procedures: In case the counter system is unavailable when the courier arrives or the courier token data is unreadable (bar code
doesn't scan) it should be possible for the agent to manually enter the courier token code, Each occurrence of this happening should be
recorded for management information. In case the courier does not have the token data or the token data available is deemed invalid an
emergency option (to be used only in these (rare) circumstance) should be made available which would allow the agent to despatch the
pouch to the courier without the token data. Each occurrence of this happening should be recorded for management information and
subsequent investigation.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 53 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AceCM-PCD
6.5.13 Derive Branch Cash for Accounts &. Cash for Planning
Branch Cash for
Branch Cash Opening Positon and usages ‘Cash Planning Branch Cash for Cash Planning
7 (ONCH) >
1
Branch Cash for Cash Planning
Derive Branch
Cash for Branch Cash for POL FS
accounts
2
Description: This process provides the accounting system with a ‘derived’ cash figure for each branch within the post office estate. It is
designed to ensure that a more robust cash figure is available each day for both the accounts and SAPADS. The system will gather the data
from all stock units within the branch, and output these figures as a total branch figure.
As a result of running this process SAPADS will receive the derived figure along with the currently declared ONCH figures, and should
enable them to more accurately plan cash deliveries to the branches.
Triggers: Scheduled automated run.
Frequency of operation: It is anticipated that this process will be run once, at the end of every business day.
Volumes: 1 file per branch, per run
Automation: This process would be fully automated, and would run at the end of each day, as part of the end of day process.
Locations: To be performed at all branches where the Horizon system is available
Input requirements at the WP boundary: Branch cash opening figures and usage figures will be required for this process to function
Output requirements at the WP boundary: The process outputs the following information;
= Aderived cash figure for each branch for use in POL financials. (may be a cash movement figure, as oppose to a total
figure)
= Aderived cash figure for each branch, for use within cash planning.
= Adeclared cash figure for each branch which have made complete declarations.
Time Constraints: Must be within POL financials and SAPADS at the start of business the next day.
Fall back procedures: Should there be a communications failure with a branch, the figure derived the previous day should be used. If the
derived figure fails, and there is no communications failure, the same should apply for the accounts, however, if a branch has completed the
daily ONCH figures, SAPADS could use this figure for its cash planning activity.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 54 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
6.5.14 Summarize Transaction Data
Description: This end of day process summarises all the transactions performed at the branch throughout the business day, and would
then output the Ledger Entry Information. The ledger entry information will be defined as part of the detailed requirements analysis. This is
teally an enhancement of the current process, which summarises the transactions from the branch, and compares the data to that of the
previous day, for reconciliation purposes.
Triggers: Scheduled automated run.
Frequency of operation: It is anticipated that this will run once per business day
Volumes: 1 summary per branch
Automation: This process would be fully automated, and would run at the end of each business day, as part of the end of day process.
Locations: To be performed at all branches where the Horizon system is available.
Input requirements at the WP boundary: The information that flows into this process are;
= Cash centre transaction data
‘Stock holding information
Pouch delivery confirmation
transaction data
branch cash holding
stock revaluations
stock adjustments
cash centre cash holdings
cash adjustments
= cheque and voucher values
Output requirements at the WP boundary: The process outputs the following information;
= Ledger entry information.
Time Constraints: None
Fall back procedures: Should the end of day process not run at a branch due to the terminal being switched off, the process would not run
until the next end of day process. the information would then be retrospectively fitted to the correct accounting days reports. Details of the
non-polling outlets are held within Fujitsu's domain, and may be used for information.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 55 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
65.15 Cash Centre Cash Management
Description: This process is the day to day cash handling process. The process will take the information fed to it, and output transaction
data and cash figures for the accounting function. The process will also output the consignment notes for transmission to the branches
Triggers: There would be some manual interaction to produce the consignment notes, as any planned order changes would need to be
manually input. Automated interface at the WP boundary.
Frequency of operation: This is a continual process leading to an interface at the WP boundary.
Volumes: TBC
Automation: There will be the need for some manual interaction, which will be defined as part of the detailed requirements analysis.
Locations: All cash centres
Input requirements at the WP boundary: The information that flows into this process are;
= Pouch Delivery Confirmations.
Pouch Collection Confirmations.
Cash receipts.
Cash from Financial Institutions.
Cash Orders.
= Cash Forecast and Holdings.
Output requirements at the WP boundary: The process outputs the following information;
= Cash Centre Transaction Data
= — Cash to Financial Institutions.
= Cash Holdings.
= Pouch delivery Confirmations.
= Consignment Note.
Time Constraints: None
Fall back procedures: ?
6.5.16 Process- Bank Accounting
The process diagrams below show where this process is within the process model:
Bank Statements Processing of Bank Account Info
Statements
4
Streamline Settlements Cheque
Management
Cheques Processed 2
Flow Chart - Diagram A4851
Description: This process aims to capture all transactions contained in the Bank Statements into POL Financials.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 56 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Bank Statement processing
The initial assumption is that POL only used one bank account , however after the initial requirements gathering exercise it has been
established that POL uses at least 5 different accounts . The Banks so far identified are the Bank of England and the Co-Operative Bank
Business processes for each of these accounts are completely different in the way they are processed, in most cases for legitimate
business processes, even if the use of the account itself has transactions of a similar nature e.g. Client settlement.
Within this process the transactions on the Bank Statements are reconciled to the ledger entries in the Bank accounts and any further
entries required are journalled manually into the ledgers as required.
Cheques are logged as a method of payment during the counter session. The cheques are counted and the value noted and these are
‘Remmed Out’ to the Centre on an agreed periodicity. When the cheques are ‘Remmed Out’ a message is sent via the Horizon system and
the Transaction Management System (TMS), which results in a posting to the financial system (SAP). The summarisation for cheques sent
to the centre is recognised as a special transaction and will be treated as such when creating the follow on postings to SAP.
The main steps of the proposed process are
14. The cheques are remmed out of the branch to the centre
2. The cheques are sent to EDS who clear the cheques on behalf of POL
3. _ EDS inform POL of the cheques — quantities and values which have been presented to the bank
4. The bank statement is received with the cleared cheques.
Further detailed analysis is required , to tie up the entire process from Counter to EDS and SAP Financials.
Debit Cards are used in certain Branches to pay for transactions i.e. DVLA. This is captured into Horizon at the Counter and submitted to
POL Financials via the TMS interface.
The current point of discussion is the treatment of this transaction. Currently itis being treated as cash, when in fact the monies are not
physically transferred into POL's account unti the next business day.
The requirement is to show the Streamline amount in process in the ledger until the amount is cleared by Streamline in the form of a
payment into POL’s bank account the following day. The processing of the bank statement will be offset against the unpaid Streamline
transactions. This will enable POL to have a constant and daily view of the outstanding funds from Streamline and provide forecasts to
Cash Planning based on actual data.
Development of Horizon Transaction Management systems is required.
Further detailed analysis is required, to ensure business is in agreement with proposed process including the reconciliation between
Streamline and the Banks, Streamline ( Emus File ) and the Fujitsu Systems of “DRS and EPOS” , error management process arising out
of differences in this E2E process as well as the clearing of Streamline debt within POL FS arising out of Bank Statement processing.
Potential sources of errors are:
1. Fujitsu Domain
2. Streamline
3. PO Counters
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 57 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
4. POL
- Streamline - Foreign Exchange Process
Main points around process
— Customer pays for Forex using debit card
© — Only used at approximately 700 Branches.
« — Currently deemed to be a Cash Transaction
There are 2 bank accounts relating to Bureau and non-Bureau transactions for Streamline.
This process although identified needs to be reviewed and agreed in its entirety, as the flow of information is a new process with regard to
Bureau.
- Pre - Ordering of Foreign Exchange via 1st Rate
Main Points around process:
¢ — Customers Pre Orders Forex
© Zip Zap File sent to 1*"Rate
1 Rate deliver stock to Branch and process debit card transaction
* — Counter deliver Forex to customer
~ Other Debit Card Transactions
TP do some central debit card transactions for bounced cheques where they ask for payment over the phone. These will be
settled in the same way via the bank account.
More detailed analysis is required to establish details of any other Debit Card transactions.
Further detailed analysis is required for total process.
Triggers: Receipt of Bank statements, Cheque processing information from Horizon and EDS, Streamline settlement information.
Frequency of operation: Daily/Weekly processes.
Volumes: Unknown, this to be confirmed through detailed requirements analysis.
Automation: Manual processes.
Locations: Performed centrally at POL Finance, Cashiers. There is a similar process required in the Cash Centres for Bank account
reconciliation and processing and this information will be captured in POL FS via the nightly feed from SAP ADS to POL FS. In this case
the Cash Centres have 2 banks each — one commercial bank account and one Girobank account.
Input requirements at the WP boundary:
» Bank Statements from the banks.
» — Streamline Settlements
> Cheques Processed via Horizon and EDS (external)
Output requirements at the WP boundary: Reports, which may be required. Bank account information.
Time Constraints: Receipt of Bank Statement and other information required to carry out this process.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 58 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Fall back procedures: Manual process. No fallback.
6.5.17 Process - Produce Borrowings and Investments Ledger
The process diagrams below show where this process is within the process model:
Flow Chart - Diagram A487
Description
This process is required in order to input the necessary information to produce the Borrowings and Investments Ledger from the POL
financials.
The Treasury function is managed by Royal Mail Group currently but would eventually be moved to POL. The requirements reflect the
move of the Investment and Loan reporting into POL FS but not the management of the Treasury function.
The following accounts are required in the POL FS COA to enable journal entries to be made on a daily basis to reflect the Investments and
Loans in POL. These need to be a visible split by Business and Client funds.
The business balances are not funded by the DTI — this is why there needs to be visibility between the 2.
There is no automatic feed from group to POL.
The accounts required are as follows:
Deposits
- DTI Loan Surplus
- Money Market Fund
- National Loan Fund
- Debt Management Office
- Local Authority Deposits
- Gilts
Loans
- DTI Loan
- Client/Business (Intra business funds movements - TBC)
- Bank Loans
- Royal Mail Surplus
There may be more P&L accounts required to reflect the change in information logged in POL FS — further analysis required at the detailed
analysis phase for Rel 4
The interest calculation within POL FS is not required at the moment.
Triggers: Information received from Group Treasury.
Frequency of operation: Daily.
Volumes: Up to 1-10 journals per day (TBC).
Automation: Manual process.
Locations: Performed centrally at POL Finance.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 59 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Input requirements at the WP boundary: Information received from Group Treasury - Spreadsheet (TBC)
Output requirements at the WP boundary: Reports, which may be required. Feed to ES-FS of closing ledger balances at month end
Time Constraints: None.
Fall back procedures: Manual process. No fallback.
6.5.18 Process — General Ledger Processing
The process diagrams below show where this process is within the process model:
Ledger Entry Information eestings in Gil] POL Business Ledger (ES-FS)
—_____
I
Postings info
ef Recount
Cleanng (GU)
2 Payments and Receipts Info
General Ledger
Account Analysis
E
‘Accounts Reports
4I
Giosing Operations
(Period End
Giosing)
Flow Chart - Diagram A4852
Description: This process aims to capture all transactions relating to manual adjustments of the ledgers to establish the final reporting
position for POL FS. The process involves reviewing various accounts periodically and doing the necessary investigations to make the
journal adjustments where required. The periodicity varies with the type of account under review.
This process also covers the running of automatic matching processes before the review of certain accounts e.g. Cash in Transit.
Visibility of Cash in Transit by Pouch/Coin Bag is required within POL FS. The matching of receipts from Cash Centres with despatches
from Branches and vice versa is required. The automatic matching of these transactions should be available in the ledger such that the
ledgers can be used to investigate potential theft/fraud.
Cash reporting
The balances of Cash by branch/cash centre should be available in order to investigate where there may be an opportunity to reduce the
amount of cash at the branches.
Triggers: Periodic review of POL Ledgers to ensure that the accounts reflect a true view of the current status.
[DATE \@ "dddd, db MMMM yyy" J
Version 2.0
Page 60 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Frequency of operation: Daily/Weekly/Monthly reviews depending on the accounts being reviewed.
Volumes: Unknown, this to be confirmed through detailed requirements analysis.
Automation: Manual processes.
Locations: Performed centrally at POL Finance.
Input requirements at the WP boundary: Bank Accounting information plus the Ledger Entry information from the Branches and the Cash
Centres.
Output requirements at the WP boundary: Reports, which may be required. Feed to ES-FS of closing ledger balances at month end
Time Constraints: The ledgers should have been updated with all the automatic feeds in order to be reviewed. The constraints are
therefore dependent on the automatic flows being updated.
Fall back procedures: Manual process. No fallback.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 61 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
652. Infermation Hows
6.5.2.1 Flow- Pouch Delivery Confirmation to Branch
Description
This remains the same as is.
This is the pouch delivery confirmation of a remittance of cash into the Branch.
This interface contains:
> — Consignment delivery ID ~ unique identifier by delivery
> Date and time of delivery
» — Transaction date and time
» Pouch ID
Nature of interface: Automated as per AIS BPDES023.
How many instances of the interface are likely to exist:
Frequency of use:
Data volumes:
Time Constraints:
Fall Back Procedures:
Security risks:
65.2.2 Flow-Ledger Entry information
Description: This flow carries information of the transactions processed and summarised through TMS into the POL FS. For release 1 the
transactions required to be processed are as follows:
» Cash transactions sourced from the Branches via Horizon (including corrections to cash due to discrepancies flowing from
Branches via TMS). The information required in this flow includes:
0 Cash at branch summarised from the end of day cumulative transactions
© Cheques at branch showed on a separate line
o Cheques sent out of the branch to the centre to enable the transaction in the ledgers to transfer the balance to EDS.
processing account or into an interim account dependent on what information is available throughout the cheque
handling process
© Commemorative coins are treated as stock when reported from Hemel or Branches and Cash when reported from the
Cash Centres.
» — Cash Centre Transactions:
o Movements at cash centres relating to the ‘Cash Ledger’ accounts specified in appendix A. This should be
summarised (unless the volume of data is not excessive to the extent that the ledger can accept transaction level
information - Volumes TBC BC) The data should be sourced from the end of day transactions on SAP ADS to
produce Cash Centre updated balances per relevant account in the POL FS totals. The cut off point for the end of day
has not yet been defined. NB: The split of notes and coins is not required to flow to POL FS - this will be handled in
SAP ADS.
o Cash pouch information, for remittances into cash centres, by pouch number to be transferred by transaction to POL
FS to enable matching within the ledgers
» — Cash in transit transactions sourced from the LFS messages created in Branches and in the Cash Centres (Sourced from SAP
ADS outbound interface - consignment note)
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 62 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
© Cash pouch information, for remittances out of cash centres and branches, by pouch number to be transferred by
transaction to POL FS to enable matching within the ledgers
© — Coin bag information by value and by barcode number - whether this detail is captured for bags dropped at coin
depots is still TBC - BC
> — Streamline data from external (Assumed Manual)
© Matched data to be jouralled into cleared cash at bank
o Discrepancies to create an appropriate entry in the POL FS
> Foreign Currency information
© Foreign currency to be reported by branch in sterling
o There is a requirement to report FX in transit - fo be confirmed how this is captured. (TBC)
© Foreign currency to be reported by stock management centre (Hemel) - this is currently reported using a cash account
on a weekly basis from Hemel. This feed would need to be capture and fed to POL FS.
> ATM information
co ATMnotes for Cashtek in Transit required to be reported separately in the ledgers
© Girobank ATM Bank Notes required to be reported separately in the ledgers
There is no requirement to report Branch ATM balances on a separate account in the ledgers
The content of the interface depends on the reporting requirement from the POL FS. Further analysis is required to confirm most of these
requirements in more detail.
Nature of interface: Automatic interface, which creates IDOCS, which post transactions/documents in the POL FS that, contributes to the
information required to produce the POL Ledgers, using a single stream of data from Horizon and other sources.
How many instances of the interface are likely to exist: If each type of flow of information is regarded as an instance there will be
several instances producing several types of IDOCS in the POL financials in order to produce the complete POL Ledgers. For release one
the number of instances of this interface are less than for release 2 when the Client, Branch and Agent Ledgers will be produced in more
detail
Frequency of use: Daily overnight. The cutoff times for end of day in the branches will determine at what point the flow is triggered from
the Branch to TMS
Data volumes: Unknown, this is to be confirmed through detailed requirements analysis.
Time Constraints: Known constraints are the volumes of data being processed. Increasing the processing power of the servers can
mitigate the time constraints, however this has a hardware cost implication. This will be confirmed through detailed requirements
analysis
Fall Back Procedures: This flow is the crux of the ledgers being produced using a single automatic stream of data via the TMS. There is
no fall back position to this flow. Resilience needs to be built into the system in order that the interface can be recovered as quickly as
possible.
Security risks:
The risks involved in this data flow are high because of the complexities involved. The fewer the variants in terms of differences in
treatment between different types of data the more easily mitigated these risks will be. There will be a certain level of matching of
summarised totals within the TMS for some of the data flows.
There is also the possibility that attempts to create transactions in SAP may fail due to a change in the source data, which has not been
carried forward into the logic of the interface. It is critical for the reference data updates to be done in a timely manner in order that these
transactions do not fail for that reason.
Further analysis of the process required before all risks are identified and a solution agreed.
65.2.3 Flow - Streamline Settlement
Description: This flow carries information of the Streamline settlements of Branch transactions to POL Financials. In release 1 this will be
fed into both CBDB and POL FS.
Key Components of process:
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 63 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
1. Debit Cards transactions at Branch flowing into TMS and into POL FS as a debtor through the main
Transaction Data flow (not necessarily aligned to trading day)
2. Tracking of outstanding payments through to Clearing and Matching in TMS.
3, Tracking of End to End process in SAP Financials, including the handing of reconciliation differences
identified in the TMS matching process. Reconciliation errors are currently identified in DRS (TMS in
the future) and passed to TP. TBC. Ann Clarke. NB the future process needs to include the clearing
of TMS as well as POL FS.
This flow is the external settlement data flow of information from Streamline which results in the matching of transactions in TMS (step 2)
and a resulting log of reconciliation differences produced by the TMS and processed manually into the financials (step 3).
This therefore indicates that this process and flow needs further definition before confirming the required flow of
information to the ledgers/TMS from external sources i.e. Streamline.
Nature of interface: Manual currently with information flowing simultaneously into DRS and Central Cashiers, further analysis required -
this flow may only be required to flow into the TMS process, in the future, rather than direct into the POL FS and we may not need
to change from the current flow. Additional TMS summarisation may be required to handle the discrepancies into the ledgers.
How many instances of the interface are likely to exist: Though this data must flow from Streamline and is currently in place to do the
matching for all transactions in the Banking process, the implementation of the TMS system would channel this flow to one consistent route
from Streamline for all outlet transactions. Matching against Branch transactions are carried out in DRS/TMS.
Frequency of use: Daily (working days - 5 days assumed)
Data volumes: One value daily.
Time Constraints: Information received by 3pm from Streamline. Reconciliations received by 8am the same day (before Streamline data
flows in).
Fall Back Procedures: N/A
Security risks: The matching of Streamline Debt against actual payments is something that is currently done outside the Financial System
and how we manage this in future may reduce the time taken in the matching process, however the level of detail required may mean that
at this stage the Clearing process is done on a daily basis total rather than at branch level. The process of matching in the POL FS will
need to be agreed.
Further analysis of the process required before all risks are identified and a solution agreed.
6.5.24 Flow-Cheques Processed
Description: This flow carries information of the Cheques Handled by EDS and submitted to the bank.
Key Components of the overall process:
1. Cheques are sent from branch to EDS
2. EDS submit cheques to bank and sends information to POL at this point
3. Cheques are cleared at the bank and the bank statement, showing cleared cheques is sent to POL and
processed. This can be seen as a separate flow.
This flow is expected to come in either as an Excel file or on paper and will be manually analysed and journaled into POL FS as required.
Nature of interface: Manual - the detail is not yet finalised dependent on the nature of the information coming from EDS if any. TBC
(expected to be as with current flow in Data Central - daily summary by day e.g. Day A vs Day B).
How many instances of the interface are likely to exist: We would expect this to be a single communication from EDS.
Frequency of use: Daily (5, 6 or 7 days to be confirmed - assume 5?- Marie Cockett)
Data volumes: Unknown, this to be confirmed through detailed requirements analysis.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 64 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Time Constraints: Unknown, this to be confirmed through detailed requirements analysis.
Fall Back Procedures: N/A
Security risks: The ability to track the process of cheque handling from end to end is vital and would substantially reduce the ability of
cheques dropping out of the system either due to error or fraud. The risk associated with this flow is minimal as it is information regarding
cheques being presented to the bank. It is information for tracking and matching only.
Further analysis of the process required before all risks are identified and processes established to manage risk.
6.5.2.5 Flow-Bank Statements
Description: This flow carries information of the Bank Statements to be processed in Central Cashiers department.
Key Components of the process:
« Bank Statement processing into the ledgers
The bank transaction details will flow through from the banks as is currently the case. The information will be used in analysing and
journaling transactions onto the ledgers as well as matching transactions cleared through the banks with control accounts such as cheques.
The content of the information in this flow is determined by the bank and will be used for a manual process as is the current requirement.
Nature of interface: Manual, but much more detailed requirements analysis is required to confirm the detail of this data flow e.g.
journal voucher types. NB this will need to be replicated into CBDB/ES-FS as well during the implementation of Release 2.
How many instances of the interface are likely to exist: At least five, but further detailed analysis is required
Frequency of use: Daily or weekly
Data volumes: Unknown, this to be confirmed through detailed requirements analysis.
Time Constraints: Volume of transactions against staff numbers, and timely receipt of Bank Statements
Fall Back Procedures: N/A
Security risks: This is an SAP internal process therefore the new process will not reduce any risk that exists in the current process. The
current risk is all business risk with regards to transmission of bank statements to POL on an open fax line and ensuring that there is
sufficient segregation of duties in the Finance department.
6.5.2.6 Flow- Branch Cash Holding for Cash Planning
Description
This is the Overnight Cash Balances report from Branches to Cash Centres. This information will be used for the stock planning of cash in
the cash centres.
There is a current interface in place which will need minimal change.
The interface contains:
> The optional declared position at the denominational level
» — Derived position at the total cash level (this is the additional information)
Nature of interface: Automated as per AIS BPDES023 with minor amendment. There is a separate record by denomination so the
additional information will flow as an additional record with a special flag to differentiate it
How many instances of the interface are likely to exist:
Frequency of use
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 65 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Data volumes:
Time Constraints:
Fall Back Procedures:
Security risks:
6.5.27 Flow-Cash Centre Cash Holding Information
Description: This flow carries information of the relevant transactions or summaries to POL FS via TMS from the Cash Centres.
» — Cash Centre Transactions:
o Movements at cash centres relating to the ‘Cash Ledger’ accounts specified in appendix A. This should be
summarised (unless the volume of data is not excessive to the extent that the ledger can accept transaction level
information - Volumes TBC BC). The data should be sourced from the end of day transactions on SAP ADS to
produce Cash Centre updated balances per relevant account in the POL FS totals. The cut off point for the end of day
has not yet been defined. NB: The split of notes and coins is not required to flow to POL FS — this will be handled in
SAP ADS.
© — Cash pouch information, for remittances into cash centres, by pouch number to be transferred by transaction to POL
FS to enable matching within the ledgers
‘The content ofthe interface depends on the reporting requitement from the POL FS. There is requirement to hold ‘cent information on these transactions for release 2. Mf this interface can
be addressed in release 1 for both sets of requirements this would be the preferred way forward. Further analysis is required to confirm most of these requirements in more detail
Nature of interface: Automatic interface, which creates documents in POL FS that contribute to the information required to produce the
POL Ledgers, using a single stream of data from Cash Centres
How many instances of the interface are likely to exist: This will be one interface from SAP ADS via TMS to POL FS.
Frequency of use: Daily ovemight. Time schedule TBC
Data volumes: Unknown, this is to be confirmed through detailed requirements analysis.
Time Constraints: Known constraints are the volumes of data being processed. Increasing the processing power of the servers can
mitigate the time constraints, however this has a hardware cost implication. This will be confirmed through detailed requirements
analysis
Fall Back Procedures: Manual journal if summarised, however if all transactions are sent to POL FS then this is not an option. In this
instance there is no fall back position to this flow. Resilience needs to be built into the system in order that the interface can be recovered
as quickly as possible.
Security risks:
The risk involved in this data flow is corporate fraud.
There is also the possibility that attempts to create transactions in SAP may fail due to a change in the source data, which has not been
carried forward into the logic of the interface. It is critical for the reference data updates to be done in a timely manner in order that these
transactions do not fail for that reason.
Further analysis of the process required before all risks are identified and a solution agreed.
6.5.2.8 Flow- Branch Consignment Note
Description:
This remains the same as is from the Branch to the Cash Centre.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 66 of 90
© Post Office™ 2003
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL00038866
POL00038866
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
This is the pouch collection confirmation of a remittance of cash out of the Branch.
This interface contains:
» Branch FAD code
» — Collection ID (for a number of pouches)
Collection Date and Time
Pouch ID
Pouch content
o Item ID
o
o Value etc.
VvVvVY
There are currently 2 events (which may have a time lag)
» The Rem out - this currently updates financials via the cash account
» — The collection at which point the record gets created for transmission to SAP ADS.
The preferred option is the rem out would transfer to a dummy stock unit (within Horizon) and then transfers to financials at the point of
collection.
Nature of interface: Automated as per AIS BPDES023.
How many instances of the interface are likely to exist:
Frequency of use:
Data volumes:
Time Constraints:
Fall Back Procedures:
Security risks:
65.2.9 Flow- Planned Orders
Description
NB: This will remain as is.
File contains details of the planned delivery to the branches.
By order — next order only
What, by denomination
When
Text format
VvVY
Nature of interface: Automated interface. Electronic file. Automated as per AIS BPDES023
How many instances of the interface are likely to exist: One
Frequency of use: Once per night.
Data volumes: Ave = 3200 transactions/planned orders per night
Time Constraints: To be received by Horizon by 6am and counter by 8am.
Fall Back Procedures: If no planned order received by day before delivery is due - the Branch calls the cash centre.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
© Post Office™ 2003
Page 67 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Security risks: The risk is that if this information is captured for fraudulent purposes this could result in the delivery being intercepted and
lost. The security of this interface is critical to the safety of the delivery. All messages are encrypted and the link between data centre and
SAP ADS is encrypted.
6.5.2.10 Flow - Consignment Note
Description
Contains actual delivery details which are picked and packed and sent to the Branch.
Consignment note - Electronic notification of the actual POL delivery details (per pouch)
Contains details:
» — Value by denomination
By pouch - unique barcode number
Branch ID
Cash Centre ID
vvv
NB If this interface is to be used for the feed of CIT information to the financials, then the Cash Centre information is required on this
message. The alternative is that there is a change in the way CIT is accounted for in SAP ADS.
Nature of interface: Electronic (LFS)
How many instances of the interface are likely to exist: One
Frequency of use: Regular feeds required - frequency to be confirmed. This enables same day delivery. The cost benefit to be
ascertained. The requirement is that the message arrives at the Branch before the physical delivery.
Data volumes: As per planned orders
Time Constraints: See above
Fall Back Procedures: This is a manual process based on the physical piece of paper in the pouch.
Security risks: As per planned orders
653. User interfaces
State the requirements of the HCi/User Interface e.g. “will provide Clerk prompts”
Ref Requirement Description
ACM-003 I The solutions should be fully intuitive such as to assist the operator in his/her operational activities
ACM - 004 I Data entry should be supported by robust validation routines
654 Beconcillation
Ref Requirement Description
ACM-005 I The solutions must be fully reconcilable where there is an explicit need for this
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 68 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
655. Audit
Ref Requirement Description
ACM -006 I The solutions must meet the auditing standards required by Post Office Ltd both internal and external to
the business
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 2.0
Page 69 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
656. Business Bluoprint Implications
6.5.6.1 Strategy
The Accounting and Cash Management Programme conforms to one of the key business focuses - simplification of our processes
6.5.6.2 Organisations Structure
There will be minimal impacts in Release 1 with the deliverables fitting into current organisation and structure. However, the new
Reference Data processes will enable greater organisational flexibility than currently exists.
6.5.6.3 Customer Experience
There will be no impact on the customer experience.
6.5.64 Facilities a Layout
There will be no impact on facilities and layout.
6.5.6.5 OurPeople
There will be impacts in a number of areas:
Network — changes to processes at the branch to:
© Accept remittances into the branch through use of token technology
© Despatch remittances from a branch through use of token technology
o Depending on chosen option - more accurate recording of MOP at time of customer session
Network — changes to retail line to
© Access management information
Network Support - changes to:
o The way Reference Data processes are delivered
Central Cash Management — changes to:
o The way cash is reported
o Information is accessed
Cash Handling & Distribution - changes at the cash centre to:
© Use more accurate cash holding information in the replenishment planning process
© The rem despatch process to deal with required token technology
6.5.6.6 Performance
There will be no impact on performance
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 70 of 90
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038866
POL00038866
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
65.6.7 Process a Data
There will be changes to business processes and the data required to operate:
New central cash management processes
0000
6.5.6.8 Application Software
The following systems will be modified:
© Horizon
o SAPADS
o POL Data Warehouse
The following will be a new system:
o POL Financial System based on SAP
o Anew reference data system
New hardware is required to run the SAP environment.
[DATE \@ "dddd, dd MMMM yyy" ]
© Post Office™ 2003
Version 2.0
Changed processes at the branch to deal with automated remittances and cash holding declarations
New central management information processes for the access to data
New reference data processes to ensure the capture of data at source
Page 71 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
65]. Business Risk
Ref Requirement Description
ACM-007 Itis essential that systems and connectivity have a high degree of resilience
‘ACM-008 I Message between suppliers, Central Inventory Management and outlets must nol be accessible by unauthorised
individuals
[DATE \@ "dddd, dd MMMM yyy" ]
Version 2.0
© Post Office™ 2003
Page 72 of 90
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038866
POL00038866
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AccCM-PCD
1. Programme Technical Requirements
This section should detail end-to-end architecture and provide an overview of the technical interfaces and architectural principles.
The programme will deliver the future state architecture over a series of releases, the diagram below is an overview of the end state
architecture.
Target Application Architecture
‘Management
7 aformation ,
y
RMG
_» Financials
“I ES-ES)
Data
\
\Losistics Feodeh,
: Service
I Reference I
Cat
_->I Management
(SAP/ADS
{Stock
+ Warchouse
‘Management
The above diagram shows the high level inter connectivity within the systems, the Reference Data System feeds all of the systems shown
above.
The following are new systems introduced by the programme:
* PO Financials
° — Reference Data
The following are systems that will be modified by the system
e — Transaction Management
¢ Counter Application
Management Information
Cash Management
e — Logistics Feeder Services
The following systems will be decommissioned as a result of the programme
uD
STAM
Intellect
CBDB
NNDB
RDS
WRDS.
TP small systems
.
.
.
.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
© Post Office™ 2003
Page 73 of 90
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
POL00038866
POL00038866
The following diagram shows a physical view of the above solution. Within the diagram the hosting domain is also clearly shown.
Fujitsu-Siemens Hw Fujitsu-Siemens H/w
BRANCH Fajitsa Domain
Counter
Application Physi =
Physical View
Riposte
Fujitsu-Siemens H/W.
Horizon Data Centre
ji
Sod
SAP R/3 Oracle(s) SAP R/3 Oracle(s)
Solaris Solaris
RDMC
Oracle(s)
Solaris
Fujitsu Siemens H/w
Logistics
Feeder
Service
Oraclets)
Solaris
Fujitsu Siemens Hw
‘Transaction
Management
(nc Adjustment
Notification)
Oracle(s}
Solaris
Fujitsu Siemens Hav
RMG
Business
Huthwaite
Domain
Systems
Domain
‘Management Information
Oracle(s). HP UNIX
HP Hav
IBM X47
Mainframe
Stock EDG
Warehouse
Management Oracle(s)
ae II HP UNIX
SAPR3 DB26)II HP Hw
IBM X47
Mainframe
Cash Mgt
SAP ADS ‘One
UNIX
SAP R3 DB2s)I
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Figure 3 : End-to-End Architecture Diagram
Page 74 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
11.
1114 Annlication
Ref Requirement Description
TEC - 001 The applications should be data driven
TEC -002 I The applications should be module were ever possible thereby allowing components, such as the
presentation layer, to be easily swapped out as more suitable modules become available.
TEC -003 I Minimisation of duplicate functions
TEC -004 I Consolidation of related processes, to minimise movements of data, reduce audit and reconciliation
points
TEC -005 I Adoption of commodity platform products to minimise hardware and associated support costs and to
maximise availability of skilled resources
TEC -006 I Usage of packages, where business requirements can be mapped onto generic product capabilities
TEC -007 I Clear separations of functional boundaries to retain flexibility in the future
112, Resillonce
Ref Requirement Description
TEC -008 I Itis essential that systems and connectivity have a high degree of resilience
113. Performance
Ref Requirement Description
TEC -009 I The new systems will at least match the performance achieved by the current system
114. Communications
Ref Requirement Description
TEC-010 I TCP/IPis the predominant and strategic data communications protocol
TEC -011 I Checkpoint Firewall-1 is the strategic firewall product.
Provide descriptions of the Building blocks detailed in the above diagram.
Ref Requirement Description
TEC -012 I Transaction Management — this system will hold transaction level information, this system will feed the
accounts, Clients and MI. in addition to sending data to SAP HR.
[DATE \@ "dddd, dd MMMM yyy" ]
Version 2.0
Page 75 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
TEC -013 I LFS — this is the mechanism by which SAP ADS communicates with the Horizon counters.
TEC -014 I SAP ADS - this system controls the physical movements of cash around the network.
TEC -015 I Reference Data — this is a new system which supports the maintenance and distribution of reference
data.
TEC -016 I Counter Application — this is the Horizon Counter terminal application
TEC -017 I Management Information — this is the POL Data Warehouse and Data Marts.
TEC-018 I ES-FS - a system managing a set of ledgers representing the full Royal Mail trading position.
TEC -019 I Stock Reconciliation - this is used to reconcile and control stock volumes across the network
TEC -020 I Stock Warehouse Management —this is used to manage the physical movement of stock throughout the
network.
TEC -021 I SAP HR — this is the Royal Mail group personnel systems.
TEC -022 I POL Financial — a system managing a set of ledgers representing the full Post Office Ltd trading
position. The ledgers will include accounting for branch transactions by client, and account for cash and
stock.
8. Programme Security Requirements
The security requirements are as outlined in the PO Ltd IS Security approach. This assesses each component and produces a security
classification. This is done where new systems are being implemented. There is no change to seourity requirements in the following
systems:
Counter Application (Horizon)
Transaction Management
Logistics Feeder Service
SAPADS
Group systems (eg. SAPHR, ES-FS, Stock Warehouse Management)
Security arrangements for Stock Reconciliation are to be determined.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 76 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Application/System Name: °
POL Financial
Application Scope YES NO
System freely available for use by ail, including General Public
System available for use by Post Office Ltd/Royal Mail emplayees and agents only fi]
System restricted to approved users only, including General Public
Application Type YES NO
System processes personal information (as defined within the Data protection Act 1998)
Information processed by the system unclassified ie public demain
Information processed by the system classified as INTERNAL
Information processed by the system classified as CONFIDENTIAL
Information processed by the system classified as STRICTLY CONFIDENTIAL
HEeeaao
System provides information to other applications/systems
Application Risks YES NO
is there a fraud tisk?
a
Would a compromise of the system cause Post Office Ltd/Royal Mail public embarrassment?
Would a compromise of the system cause severe business disruption?
Could a compromise of the system cause legalireguiatory penalty?
Access Control YES NO
Nature of user base internal Employee or agent
Third Party (existing contractual arrangement)
Third Party (no contractual arrangement)
Public
What access will users have to the system? information Change
HOO
information Insertion
Information Brawsing
Direct Access to DBMS /
Operating Systems:
Is personalisation of content required?
ky
BH HEH ERED
OO 888
Can users request access to personal information about theniselves treld on the system?
‘Royal ad Groups Pie 2008
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Maintaining Data Security
fs access required by
Individuals
Ow
Groups of users
Are physical security measures low?
(eg LIW, offsite workers, laptop accessors) YES/NO
Oo
@
Is an access contral systems available to control
access to permanent data? YES/NO
Is dia-up connectivity required? YES/NO
Is extranet connectivity required? YES/NO
Data transmissions Do data transmissions occur
‘Over untrusted networks (eg Internet)
Over trusted (infrastructure) network (eg RM WAN) @
Transmission nature (Many-to-many) / (One -to-one or One -to-many)
Frequency Frequent/infrequent
Volume High or Medium or Low
Email transmissions YES/NO i}
Recipients has Notes YES/INO i]
Source and destination trusted? YES/NO. i}
Binding non-repudiation required? YES/NO I}
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccCM-PCD
Systems Clas
Result:
sification SENSITIVE
Scheme Level3 Identity Validation wif be required hy support staf¥ requiring direct access to DBMS or Gperating System, No direct access at I
this level should be granted to users of applications ‘I
Standard User Identity
Validation Level:
perform free fo
uublish the crede
ielentity ch
ils io the Es
securely record shared secret information, and issue Single Sign-on credentials on a hardware device and I
User Access Authority:
Update/Delete InsertiRead Insert
Identity Validation
Required by Access Levels Level? Levelt
Level:
Confidentiality ICowidentiatiy Secices must be provided by Avcess Contol (Auttinisation)
Controls:
Data Transmission _ [Stetly Contidentil Data shout not he tansmited unless both Scarce andl Destination are bused
Controls:
Strictly Confidential may be frausmitied aver trusted (infrastructure) networks without encryption
integrity Controls: Integrity services niust be provided by Access Contrel (Authorisation),
Data modifications require andit logging
Rea
-ess requires audit logaing.
Adloquate integrity contecls Yor data transmissions cain be assumed
(Royal Moi Group Ple 2008
Page 79 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Application/System Name: 6
Managemant Information System
Application Scope YES NO
System freely available for use by all, including General Public @
System available for use by Past Office Ltd/Royal Mail employees and agents only ea] &
System restricted to approved users only, including General Public @
Application Type YES NO
System processes personal information (as defined within the Data protection Act 1998)
Information processed by the system unl
sified ie public domain
Information processed by the system classified as CONFIDENTIAL
Information processed by the system classified as STRICTLY CONFIDENTIAL
@
Oo
Information processed by the system classified as INTERNAL @
@
@
@
System provides information to other applications’systems
Application Risks YES NO
Is there a fraud risk? J]
Would a compromise of the system cause Past Office Ltd/Rayal Mail public embarrassment? @
Would a compromise of the system cause severe business disruption? @
Could a compromise of the system cause legal/regulatory penalty? @
Access Control YES NO
Nature of user base intemal Employee or agent
Third Party (existing contractual arrangement)
Third Party {no contractual arrangement)
Public
What access will users have to the system? information Change
Informatian Insertion
Information Browsing
EE SEEEB
Direct Access to DBMS /
Operating Systems
Is personalisation of content required?
Can users request access to personal information about themselves held on the system?
yal Mail Group Ple 2093
ODO OF O00088
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Maintaining Data Security
Is access required by
Individuals
Of
Groups of users
Are physical security measures low?
{eg LIW, offsite workers, laptop accessors) YES/NO i]
Is an access control systems available to control
access to permanent data? YES/NO @
Is diabup connectivity required? YES/NO @
Is extranet connectivity required? YESINO @
Data transmissions Do data transmissions occur @
Over untrusted networks (eg Internet} f@
Over trusted (infrastructure) network (eg RM WAN) @
Transmission nature (Many-to-many} / (One -to-one or One -to-many)
Frequency Frequent/infrequent
Volume High or Medium or Low
Email transmissions YES/NO @
Recipients has Notes YES/NO @
Source and destination trusted? YESINO @
Binding non-repudiation required? YES/NO i]
Page 81 ot 90
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038866
POL00038866
Accounting & Cash Management
Programme
‘AcoCM-PCD
Systems Classification
Result:
Standard User Identity
Validation Level:
SENSITIVE
iperform face to face identity checks, securely record shared secret information, and issue Single Sign-on credentials on a hardware device and
jpublish the credentials in the Enterprise Directory.
User Access Authority:
Identity Validation
Required by Access
Level:
UpdateiDelete
insertiRead Insert
Level3
Level2
Levelt
Confidentiality Confidentiality Services must be provided by Access Control (Authorisation)
Controls:
Data Transmission
Controls:
“Trusted network provides sufficient confidentiality
controls for Confidential data ~ eneryption nol necessary
Integrity Controls:
© Royal Mall reup Phe 2003,
Integrity sere ioes must be provided by Access Control (Authorisation).
modifications require audit logging
Rend access requires audit logging
Adequate integrity controle for data transmissions can be assumed
POL00038866
POL00038866
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccCM-PCD
Application/System Name: 8
Reference Data System
Application Scope YES NO
‘System freely available for use by all, including General Public @
System available far use by Post Office Ltd/Royal Mail employees and agents only @
System restricted to approved users only. including General Public &
Application Type YES NO
System processes personal information (as defined within the Data protection Act 1998)
Information processed by the system unclassified ie public domain
Information processed by the system classified as INTERNAL
Information processed by the system classified as CONFIDENTIAL
Information processed by the system classified as STRICTLY CONFIDENTIAL
HOHanAaO
ERE ERES
System provides information to other applications/systems
Application Risks YES NO
Is there a fraud risk?
Would a compromise of the system cause Post Office Ltd/Royal Mail public embarrassment?
Would a compromise of the system cause severe business disruption?
OAAaaA
a
Coukl a compromise of the system cause legal/regulatary penalty?
Access Control YES NO
Nature of user base Internal Employes or agent
Third Party (existing contractual arrangement)
Third Party (ne contractual arrangement)
Public
HOOBA
HHEG
What access will users have to the system? —_Information Change
Information Insertion
Information Browsing
Direct Access to DBMS /
Operating Systems
Is personalisation of content required?
Can users request access to personal information about themselves held on the system?
2
‘Royal Mall Group Ple 2005
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038866
POL00038866
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AccCM-PCD
Maintaining Data Security
is access required by
Are physical security measures low?
{eg LIW, offsite workers, laptop accessors)
Is an access control systems available to control
access to permanent data?
Is diatup connectivity required?
Is extranet connectivity required?
Data transmissions
Transmission nature
Frequency
Volume
Email transmissions
Recipients has Notes
Source and destination rusted?
Binding non-repudiation required?
Individuals
Groups of users
YES/NO
YES/NO
YES/NO
YES/NO
Do data transmissions occur
Over untrusted networks (eg Internet}
Over trusted (infrastructure) network (eg RM WAN}
(Many-to-many) /{One -to-one or One -to-many}
Frequent/Infrequent
High or Medium or Low
YES/NO
YES/NO
YES/NO
YESINO
Ow
&l
HBHHBOOSBEG
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038866
POL00038866
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
Systems Classification SENSITIVE I
Result:
Standard User identity
Validation Level:
perform face to fae identity checks, securely record shared secret information, and issue Single Sign-on credentials on a hardware device and
publish the credentials in the Enterprise Directory.
User Access Authority:
Identity Validation
Required by Access
Level:
Update/Delete
insertiRead insert
Level3
Level2 Levelt
Confidentiality Cenfideniality Services mun be provided by Access Control (Authorisation)
Controls:
Data Transmission
Controls:
Integrity Controls:
Royal Moll Group Plc 2003,
© Post Office™ 2003
‘Trusted netwark provides sufficient confidentiality controls for Confidential data ~ encryption not necessary
Integrity services must be provided by Access Control (Authorisation)
Data modifications require audit logging
Read access requires audit logging
Adequate integrity contvols for data transmissions ean be assumed.
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
9. Current Phase Deliverables
91. Pest Office™
1. Programme Conceptual Design
2. Detailed Project Conceptual Designs as a result of this document
a. ONCH/ Automated Remittances
b. Cash/Bank Ledgers
c. Reference Data
d. Management Information
3. Work Packages to suppliers
92. Work Packages
The following work packages will be given to suppliers
1. Project Conceptual Design - Professional Services to assist Post Office Ltd
a. ONCHiAutomated Remittances
b. Cash/Bank Ledgers.
c. Reference Data
2. Detailed Project Solutions Designs
a. ONCH/Automated Remittances
84. —_— PRISM Alliance
1. Project Conceptual Design — Professional Services to assist Post Office Ltd
a. ONCH/Automated Remittances
b. Cash/Bank Ledgers
c. Reference Data
d. Management Information
2. Detailed Project Solutions Designs
a. ONCH/Automated Remittances
b. SAPADS changes to support Cash/Bank Ledgers
85. Suppllertobe determined
1. Detailed Solutions Designs
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 86 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
a. Cash/Bank Ledgers.
b. Reference Data
¢. Management Information
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 2.0
Page 87 of 90
© Post Office™ 2003
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
10. High Level Programme Planning
101 = Timescales
The following plan depicts the whole of Accounting & Cash Management Programme with Release 1 milestones show as based on the
business case:
Programme Analysis,
Release 1
Releases 2/3
Requirements
AnlaysisDesign
Release 1
Release 2
Release 3
Develop/Test/Implement
Release 1
Release 2
Release 3
err I oTR3
2003 I 2003
amr 4] Qrri orr2 I grr I grea I grri
2003 2004 2004 I 2008 2008 I 20035
EE
Sourcing
jDecisionsI
31/7
Roll] out
. AprI04 Roll out
VV Opt 04 A
I Rol] out
Mar 05
Accqunting/CashI ManagementI Programme
102. Dependencies
List the project dependencies both outside the project and within it.
Figure 4 - Programme Plan
1. The three Cash Ledger projects are mutually dependent the combination of which gives the overall visibility of cash
2. _ Reference Data is dependent upon having the detailed requirements of the Cash Ledger projects known
3. There is a dependency on Horizon release timescales not slipping and there being sufficient capacity in the releases at the appropriate
times
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 2.0
Page 88 of 90
POL00038866
POL00038866
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
1 Programme Acceptance Strategy
High high-level set of acceptance strategy for Project/System Name should be documented here based upon the requirements detailed
within this document.
Ref Description
ACM-009 A separate work strand will be initiated which defines the acceptance strategy and the detailed
acceptance criteria
ACM-010 I Acceptance tests must cover:
Functional and direct interface tests
Non-functional tests for disaster recovery
ACM-011 Successful completion of direct interface tests between POL, Fujitsu and PRISM Alliance are required to
confirm satisfactory system acceptance.
'ACM-012 _I Where appropriate, acceptance tests may be based on the outcome of design walkthroughs.
‘ACM-013 I Fujitsu Services and PRISM Alliance must support such validation/inspection of the design and
implementation as necessary for stage testing and acceptance.
12. Programme implementation a. Migration Strategy
Ref Description
ACM-014 A separate work strand will be initiated which focuses on business and technical migration
ACM-015 I There must be integrity between CBDB and the cash ledgers during the migration period
ACM-016 Cash adjustments made in Horizon must flow through to the cash ledgers
ACM-017 I Bank statements and cheques will need to be processed in both CBDB and the new system during
migration
ACM-018 I Reporting of cash will be via the new system but all other accounting reporting will continue via CBDB
during migration
ACM-019 I Existing reference data feeds need to be maintained during migration until switched over to the new
source or no longer required
[DATE \@ "dddd, dd MMMM yyyy"]
Version 2.0
Page 89 of 90
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038866
POL00038866
Project: Accounting & Cash Management
Programme
Doc Ref:
AccCM-PCD
The following Chart of Accounts is for Release 1 only (Cash elements) and will be extended to incorporate the remainder of Release 2/3
aspects later
POL Chart of Accounts
ew
Bn Seer
fin Sten
can
Emsrie
Eras
Bou ase! Gamat
Hansa ac TAT
anewsab ans lAMT
fen ;
ess 800
eieaiekh abe uAaosiT
Hewenabane ~~ SAgIT
eiawskp angie Cae> peomaaT
Hane Carp uratt
onan
spat
oat
canes
‘me AFP OUNTESUEUTS Te
nt
sap aise ci
Sap AOBSSE CA
31
‘vidi
i Apes
simile
gps
Aspe
eave
No Aiea nastiest
[DATE \@ "dddd, dd MMMM yyyy"]
© Post Offioa™ 2003
Bek Slain
ek Sie
es Stata
cease,
Ems
Em
ex siascaa
enh ae
ovat AS
eesti
eanis04V
Herel ae
inaish abe
Hines
eas
ein
eile
eramisvemieg
kata
errant
eta
BANK ACCOUNTS
PHYSICAL CASH AT SITES
9 ceases Gemete fewetonen
INTRANSTr
iNCLEARNG
‘BORROWINGS AND INVESTMENTS,
2 ee Si
rey Mae Fd
itl aan Ft
3 Det Manager Once
“A ea Astor Desa
ont
hs a i wt
Suk re
od ig
BALANCING FIGURE
Version 2.0
fe nie toe cata Pare. Cebbe Sv
te are QUE nh et Acne POL Boks
Conta Peerage TP
Es ceed Som Si nso bled oF aloe wala ban ate
oni ceva ton Sve anos stlenert ol areca Ole Ne Buse
i oe air Wasi
‘as SH mate, cus NS ch hb price wal be a
‘Re SH eqaectenogh et ate wale rate 9 obec
Sipe eile ate orn excarge
a ak ileal
‘es nga sacks oe 20. etal
Mow a ned HSF et ppt ah cr akc ae ot encgonA
Site swag a ey scare wha I
havo ade pt Bad Use cae 1
Spe tree mere ely marl natin wt 3 ty,
Spat cu nay a ete oh oe
hs on ark circ nun et on fe ad ne
Tena ane 2 rere oan cae man eoe
i in uma acing ra ie al pay tl car a a ome
Sip sbi aes ones PL ATMe wth ae 7 PAPE un
Poin se sie sanesen se es ena
race Sse ee zeae
POkte poe the dt a
Sie emt a i i ir ae
Uae ean 5 i a Bice
inal 8 ait
tae,
1k sia ee cod ete 2 sewn lnm ope
i
“reamed ef UPR acta eg ees
Otte poe te ti toate
sf tea ay set sn ni nea Reh
a
Page 90 of 90