POL00038870
POL00038870
Accounting & Cash Management
Programme
Conceptual Design
DAVID PARNELL
DANIEL HAWTHORNE
[DATE \@ "dddd, dd MMMM yyy" ]
Version 3.4
Page 1 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Table of Contents
4.PROGRAMME CONSTRAINTS.
Integration with Other Systems
4.1.3. Post Office™ Approved Technology
4.1.4. Post Office™ Approved Components
DESIGN PRINCIPLES ...
S.1. BUSINESS REQUIREMENT
5.2. OVERVIEW . 24
REQUIREMENTS ~ 24
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 2 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Automated ONCH....
Cash & Bank Ledgers
Automated Remittances.
Reference Data.
Management Information and Reporting.
‘SS REQUIREMENTS — RELEASE 2 & 3.
Branch Liability Management and Central Reporting.
Reporting Customer Data...
Client Settlement
Verification
Debt Recovery
Cash Centre Cash Management.
Stock Reconei
Financials .
9. Decommissioning and Fujitsu Rationalisation
54.10. Management Information — Additional to Release 1
EXCLUSIONS
Process Descriptions ~ Release 1...
Process Descriptions — Releases 2 & 3.
Information Flows ~ Release 1...
Information Flows ~ Releases 2 & 3.
User Interfaces...
Reconciliation
Blueprint Implication:
Business Ri:
6
ARCHITECTURE PRINCIPLES
Application 150
Resilience 150
ARCHITECTURE BUILDING BLOCKS
. PROGRAMME SECURITY REQUIREMENTS
IZ
Ie
5 CURRENT PHASE DELIVERABLES...
8.1.
a HIGH LEVEL PROGRAMME PLANNING...
TIMESCALI
DEPENDENC! 164
10, PROGRAMME ACCEPTANCE STRATEGY. 165
li, PROGRAMME IMPLEMENTATION & MIGRATION STRATEGY
11.1. CONSIDERATIONS FOR_ MIGRATION OF FINANCIALS AND REL
Idd. Migration considerations Releases 1 & 2
11.1.2. Parallel running during Release 2...
[DATE \@ "ddd, dd MMMM yyyy" ]
1D INTERFACES
Version 3.4
Page 3 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
1.1.3. Decommissioning of legac ems in Releases 2 &
2. SYSTEM DECOMMISSIONING.
APPENDIX A — CHART OF ACCOUNTS....
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 4 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
1 Becament Information
Horizon Release No: $60,S70,S80,S90 + Back End Release to be determined
Document Title: Accounting & Cash Management Programme Conceptual Design
Document Type: Programme Conceptual Design
Abstract: This document details the Business, & Operational Requirements for Accounting
& Cash Management . \t 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
Document Status: Draft
Originator & Department: I David Pamell - Business Solutions.
Contributors: Karen Hillsden, Helen Pedley, Luxmi Selvarajah, Paul Antunes, Gareth Jenkins,
Jamie Dixon, Phil Boardman, Bob Gurney, 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: I As per review details
‘Supplier Distribution: As per review details
Client Distribution: None
Table 1: Document Information
12 Becament History
0.1 July 2003 I First draft cT0044a
02 "July 2003 I Second draft after review of Reference Data
requirements
03 July 2003 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
24 July 2003 —_ Inclusion of Releases 2 & 3 I
3.0 Aug 2003 _ Including Releases 2 and3 for formal review
3.4 Aug 2003 Minor additions
3.2 Aug 2003 Version sent for review — minor changes
34 Sep 2003 __ Following formal review of versions 2.0 and 3.2
Table 2: Document History
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 5 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
hange Process
Any changes to this issued version of this document will be made, controlled and distributed by: -
Business Solutions
Post Office Ltd
80 Old Street
London
A. Changes in this Version
0.1 « None ~ first issue
0.2 « Reference Data changes
0.3 * 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)
24 « Releases 2 & 3 added
3.0 « Document separated into Release 1 and Releases 2 & 3. Minor Changes made to
introductory paragraphs 1 — 4 to reflect the totality of scope. Minor changes also to
sections 3.3, 5.4, 5.7.2, 5.7.4, 11.1 & 11.2. Other sections are new
3.41 « Amendments to information flows — 5.7.4.1 & 5.7.4.2
* Addition of an extra dependency : no 4.
« Changes to high level plan to reflect current dates
3.2 * Deletion of benefits paragraph on instruction from Keith Baines
3.4 « Adoption of review comments to Versions 2.0 and 3.2
Table 3: Changes in this Version
David Parnell Business Process Architect
Table 4: Key Contacts
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 6 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
Post Office Ltd:
E2E Design Authority
Programme Manager
Technical Design Authority
Business Design Authority
Clive Read
Sue Harding
Daniel Hawthome
David Parnell, Karen Hillsden
Supplier Review
Gareth Jenkins, Bob Gurney, Bob Cragg
Project Managers
Bill Reynolds, Peter Flood
Business Review
POL
Stephen Hirst, Ruth Holleran, Vicky Noble, Ann Cruttenden, Ann Clarke,
Bob Lammin, Neil Salter, Jack MacKenzie
Table 5: Review Details
0.1
AIS BPDES023.
February Business Requirements - End to End Re-
2001 Architecting Post Office Product, Branch, Client,
Cash and Stock Processes & Systems Feasibility
Study
LFS Application interface Specification
Unless a specific version is referred to above, reference should be made to the current approved ver
of the documents.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Table 6: Associated Documents
ions
Page 7 of 174
POL00038870
© Post Office™ 2003
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
18. Abbreviations/Definitions
Abbreviation Definition
ACT Automated Credit Transfer
AP Clients Automated Payment Clients
BA Funding Benefits Agency Funding
BOE Bank of England
BDeCMIS Bureau de Change Management Information System
BS Balance Sheet
BTA Brought To Account
CACH Cheque Authority Card Holders
Capita TV Licensing (Formerly Subscription Services Ltd)
Cashiers (FICS) Financial Information Cashiers System
CBDB Counters Business Database
CLASS Client Ledgering & Settlement System
CREDO Redirections Mainframe System
CTT Counter Transaction Timing
DAVROS Settlement control system used to summarise payments
DNS Department of National Savings
DPU (Route 3) Data Processing Unit
oT! Department of Trade and Industry
EDS Card Account Interface
ES-FS Royal mail Group SAP Financial Ledger System
FAD Financial Accounting Department
FICHE Data archiving facility
FOSACS FOrmer Subpostmasters ACcounting System
FS Fujitsu Services
FX Foreign Exchange
Girobank Errors I Database which receives error details from client
Application
HMIS Helpline Management Information System
Holding Account I Used to hold details of unresolved errors
database
HORIZON MIS Horizon Management Information System.
HRSAP System which manages Subpostmaster Remuneration
Intellect Ad hoc on-line query facility
IRIS Used to monitor stock returned to Hemel Hempstead
Issued Errors I Used to track progress towards error resolution
Database
KLASS003 CLASS download containing details of error situations
LFS Logistics Feeder Service
UD Local Information Database
Local Schemes System used to record supporting document information
Lotprize Used to record details of cheque serial numbers for prize payment
MI Management Information
MM Materials Management - SAP module
NBSC Network Business Support Centre
NNDB National Network Database
NRDS New Reference Data System
NRM Network Reinvention Model
OBC Operational Business Change
OBCS IR Order Book Control Service Inland Revenue
ONCH Overnight Cash Holdings
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 8 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
OOH Out of Hours
OPTIP. Operational TIP
P&L Profit and Loss
PACSYS Pensions Administration Centre SYStem
PAF Postal Afddress File
PIVOT Postmaster Information on Volume Of Transactions
POCA Post Office Card Account.
POCM Post Office Customer Management
POL Post Office Lid
POLC Post Office Local Collect
POLFS Post Office Ltd Financial System
PPOP Payments Processing Outsourcing Project.
RDMC Reference Data Management Centre
RDS Reference Data System
RECALL Regional Electronic Cash And Logistics Link
RFLS Rod Fishing Licensing System
RLM Retail Line Manager
RNG Royal Mail Group
RMMI Royal Mail Management Information
Sales MIS Sales Management Information System
SAPADS ‘Systems Applications and Products Automated Distribution System
SPMR Sub Postmasters Remuneration System
STAM System for Transaction Accuracy Measure
TMS Transaction Management System
UKPA United Kingdom Passport Authority
WP Work Package
WRDS: Warehouse Reference Data System
Other generic IT terms can be looked up at: http://www.whatis.com/
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
© Post Office™ 2003
Table 7: Abbreviations/Definitions
Page 9 of 174
POL00038870
POL00038870
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 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 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
© Release 2 October 2004
« — Release 3— March 2005
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 3.4
Page 10 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038870
POL00038870
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
21 Purneso
This document is intended to detail the design for the whole of the Accounting and Cash Management Programme. It is intended to act as
a reference for those involved in the various stages of design, development, deployment and support for the Accounting 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. = Scope
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 a Decommission
© Personal Agent Ledgers (Project 8)
Simplification & Improvements Transaction Processing (Project 9)
Reference Data
* Reference Data (Project 10 & 18)
Management Information
— Management Information (Project 12)
Release 1 of the programme focuses on the Cash Ledgers, Reference Data and Management Information
Releases 2 & 3 of the programme focus on Branch Liability, Branch, Client and Stock ledger plus stock reconciliation, further management
information and decommissioning of the legacy estate.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
© Post Office™ 2003
Page 11 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
221. Exclusions
None
23. Becamont 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
Cash and Logistics Supplies - Bob Lammin
Management information — Neil Salter
Sales and Marketing - Jacky MacKenzie
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 information flows together with Processes 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]
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 12 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
This depicts process boxes and information flows where inputs to the process go into the left hand side and ouputs come out of the right
hand side Any vertical arrow pointing down to a process is a control and any vertical arrow pointing up into a process is a user role.
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 red are part of the overall process but deemed out of scope for the current E2E Programme.
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: -
277-xxx - where ?77 is a fixed label corresponding to the project and xxx is the requirement number, starting at 001
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 13 of 174
© Post Office™ 2003
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL00038870
POL00038870
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
3. Programme Gverview
31. Business Propesition
The overall business proposition covers
» — Cash and Funds Management
Branch, Client and Stock accounting - including branch liability
Reference Data
Management Information
Decommissioning
VVVY
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:
© Cash flow
© — Borrowings
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
To clearly show the overall indebtedness of clients.
as cheques.
To have a single, comprehensive view of cash (funds) in one place
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
© Post Office™ 2003
Bring together all the elements of cash flow and provide cohesive management to deliver cash flow 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 be able to accurately identify physical cash at branch rather than overall cash which can include cash equivalents such
To be able to forecast and manage cash flow within the DTI target (£330m for 2002/03)
Page 14 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
iF
To improve the integration of cash centre holdings into cash flow management
Accounting, Receaciliatien and Settlement, including Bebt Recevery and Branch
Scone
Interface of data to RMG financial systems
Management of PO Ltd Bank Accounts
Capture, Validation, Verification and Correction of client transaction data from any channel where applicable
Provision of validated client transaction data to int and ext recipients
Responding to client/branch enquiries concerning transaction data
Accounting at branches
Branch control
Recovering debt from branches, clients etc (ine non-transaction)
Key Prierities
Make the identification of debt easier
Reduce the amount of reconciliation required
Increase the amount of debt recovered
Put the emphasis on clients and customers to validate the data
‘Simplify branch processes by reducing the amount of paper
Centralise/consolidate agents debt
Enable matching of cash at branches with settlement with
Re-focus on Debt Recovery (financial recovery of money), target 95%
Only 10% of discrepancies are actually debt
Establish a central debt monitoring environment to enable the identification of debt with a high degree of accuracy.
To report Business and Client information separately and accurately.
To increase accounting control in branches
Alignment of management and accounting information
Establish an appropriate and flexible accounting hierarchy
Performance measures of throughputs and the actual financial debt.
Rationalise systems in place to report client and business information.
To modify the method of recovering debt e.g. using payroll for agents.
Enable proper accounting of cash and stock
Improve timing, accuracy, granularity and summarisation levels.
Avoidance of losses from remittances and client settlement
Accounting and settlement on our data, not clients
Manual journal documents and human intervention produce errors
Accounting period alignment — branch Wednesday, business Sunday.
Settlement estimating can produce positive or negative interest position
Cash centre accounting is manual, weekly, therefore no through view from transaction to settlement.
[DATE \@ "dddd, dd MMMM yyy" ]
Version 3.4
Page 15 of
© Post Office™ 2003
debt
client
174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
3A. Reference Data
3A1. 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 that 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
342. Koy Prierlties
© — Toensure consistency in reference data usage within Post Office and Fujitsu
© — To simplify the current processes
© — Toallow changes, such as organisational changes, to be implemented in a more timely fashion
343. 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.
35. Management Iafermation
35.1. Scone
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 faclty 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
352. Key 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 3.4
Page 16 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AceCM-PCD
353. Business Drivers/issues
© Sales MI 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 eg. 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 eg. 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 3.4
Page 17 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
The following depicts the high level processes and information flows between these processes.
nen Management infration
vnormation
[ Relwence baie St0ck Revelation inrmation
Management
Product Change Ifo a5 I asc oma aacounis and I_POL Business Ledger S-F5)
_ adig Tarsacians Serene vsteo Vansestone
el ——esng basis) Agente Tansee
Reference Deta & Business Rules I Debt Recovery Amounts Through Payrel!
Cheques Processed lent Transaction Data Resor
‘Sieamine Settements Branch Labity Statement
mer Requirererts! ¥ ‘SiGe Revaluation Wiermation >] Ce
stoma Regemers! -— sa _ aon Tetoment Paynes Cie
—— Branch Closure Notice Payment Request fo Clert
a Engufy Response! After Sales Engury Glen Authorsations >) ‘dented Wansaction Eros
> inert Repor
3 Transaction Data ————————————— < .
#7 - Tahtioman Contra nays
I sh Cente Cash Holding fpamat Maneater Data
Branch Gash Holding i Marketieg Forecasts
Stock Usages Though Trarsaions (ek Rae ‘Seosunl Dat
[sto Hotting rermation a I I" arestnents & Boronngs
; ee park Stalemeris
aqua Herons Perormarce Dae
I I
I <p Cash Fiow Forecasts 4
=F) management ‘Supplier Orders ma
‘Stock Receipts
Toca Requirement Krawleaie
Product Marketing Knowledge
‘Other Fuliments
[Stock Despatches
Pouch Delivery Confirmation to Cash Centre
ash Centre Transaction Data
AB
Joubhers Despatched
(Cash and Near Cash Usages Through Transactions bdgan ond Voucher Values
Opening Cash, Cheques and V' Cah heaves Despatched
Cash Revelsts a Consignment Note
Gash Revelpts tom Financial nstiuions
Local Cash Requirements Information
‘Cosh Despatches
Cistomer Transactions Cash Ones
eascnal Data 7 Cosh Despatched to Financial Insitutions
Herta Freese [ete
Cash Centre Cash Holding nommaton Ner-Corfomance Reports
‘Gash Fiow & Haldngs Perlrmance Data
>
76 Forecast Pertrmance Reports
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 18 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
31. Systems summary
The following diagram depicts the end state architecture:
Target Application Architecture
I aus he RMG
I : 4 : Financials
sappy I) "Information I ESFS)
Figure 1 - End State Architecture
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.
In the following diagram:
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 3.4
Page 19 of 174
© Post Office™ 2003
POL00038870
© Post Office™ 2003
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Release 1 Changes
RMG
I Financials
/ I_ES-FS)
i / RMG
] oprip CBDB ith
an /
a
Clients — ‘Trensaction
Management
Stock
Counter Logistics Feeder fy Warehouse
Application Service Management
_ " Reference
Data
Figure 2 - Architecture at Release 1
Release 2 Changes
RMG i
Financials I
(ES-FS
RMG
HR
SAP/HR)
‘Cash
Management
(SAP/ADS)
Stock
Warehouse
‘Management
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 20 of 174
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AccCM-PCD
POL00038870
POL00038870
Release 3 Changes
‘Management
Information
Counter
Application
I_GS-FS)
RMG
x» Financials
41 Architectural
41L Pest Office™ Strategic Direction
Ref Requirement Description
TEC - 001 The applications should be data driven
TEC -002 I The applications should be modular 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
points
TEC - 004 I Consolidation of related processes, to minimise movements of data, reduce audit and reconciliation
maximise availability of skilled resources
TEC -005 I Adoption of commodity platform products to minimise hardware and associated support costs and to
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
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
© Post Office™ 2003
Page 21 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AceCM-PCD
412. Integration with Other Systems
Ref Requirement Description
TEC - 023 I Integration with SAP ADS
TEC - 024 I Integration with SAP HR
TEC -025 Integration with ES-FS
TEC — 025a I Integration with Horizon
413. Pest Office™ Appreved Technology
Ref Requirement Description
TEC - 026 I Refer to Royal Mail Group list of Approved Technology
au. Pest Office™ Appreved Compenents
Ref Requirement Description
TEC - 027 I Refer to Royal Mail Group list of Approved Components
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
Page 22 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5. Design Principles
Ref Requirement Description
ACM-001 Any individual component of the programme must conform to the POL Strategic Data Model
ACM-002 The solutions should meet the business design assumptions as stated in the Business Requirements
Specification (Feasibility Report) vsn 0.1
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 3.4
Page 23 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
SL Business Requirements
52. Overview
The business requirements are separated into their current component projects. Within these component projects there is:
— Asmail number of high level requirements which define the scope — prefixed XXH-XXX
— More detailed individual requirements to support that scope
53. Business Roquiromonts — Release 1
531. ONCE
Ref High Level Requirement Description
‘AOH-001 I To provide a system generated daily declaration of cash for despatch to SAPADS and movements of
cash and near cash 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
AQ 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 branch 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 generated figure.
AO 005 ‘SAPADS to receive both daily system generated figure and daily denominational figure (if entered) - SAPADS to use the
daily denominational figure as an override to the system generated figure
AO 006 Horizon to make available to the POL Financial System the daily movements which make up the system generated
declaration for entry to the cash ledger. The daily movements must reconcile to the system generated cash declaration
figure.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 24 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
532. 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 I 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
533. 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 branch.
AR 006 Central Inventory Management must be aware of branchs 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 Deleted
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 branchs and Central Inventory Management must be timely i.e. Delivery note should arrive at branch
prior to the pouch.
AR 013 Aconfirmation of order details will be transmitted to the branch 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 branch
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 branch on delivery
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 25 of 174
POL00038870
POL00038870
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 from Horizon
AR 021 Confirmation of the order receipt will be transmitted to Central 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 Deleted
AR 024 Branches will be liable for discrepancies in unchecked orders after expiry of the checking period
AR 027 Pouch total 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, i.e. 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. Authorised Collectors Card
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 Deleted
534. Reference Data
Ref High Level Requirement Description
RDH-001 To provide one new system which allows for the decommissioning of RDS, WRDS and NNDB
RDH-002 I 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 I To provide new business processes which allow for the capture of data at source
RDH-005 To migrate existing data from the current reference data systems within POL to the new Reference data
system
RDH-006 I To migrate existing data extracts from the current reference data systems within POL to the new
Reference data system
RDH-007 To support all reference data changes within the S60 release
RDH-008 I To support the new reference data business process
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 26 of 174
POL00038870
POL00038870
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 authorized 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 buik 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 logical 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.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 27 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
RD-020 Must ensure that the implementation technology does not impose technical limitations on the
implementation of business change.
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.
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 new RDS interface must pass a complete, accurate data set to all current interfaces which will
exist at the time of migration.
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
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 28 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
RD-040 It should be possible to rationalize the system with NSBC data bases that duplicate the same
information, thereby removing the need for a separate NSBC
RD-041 Increase the scope of data held in the in the system, particularly :
¢ — toreplace the shared reference data elements of Smartpost
© — to replace 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.
© — to replace any other reference data update that is carried out independently of the system.
RD-042 NBSC require data, such as 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. )
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 (c.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 Fujitsu Services.
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-058a Addresses held in the database should be generated by the same PAF facility being used for Advanced
Data Capture
RD-058b 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 be maintained within the New Reference Data System
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 29 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038870
POL00038870
‘Accounting & Cash Management
Programme
‘AcoCM-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 i.e. process performance monitoring
RD-063 Access to the system will be by roles and users will be assigned to roles
RD-064 Both internal and external access will be required — eg 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
RD-067 The following interfaces will need to be migrated from the existing reference data systems to the new
reference data system:
1,
aweYN
eon
Feed to AP Clients (Mandatory)
Feed to ReCall (Mandatory)
Feed to RDMC (Mandatory)
Feed to EDS (Mandatory)
Feed to SAP HR (Mandatory)
Feed to SAP ADS (Mandatory)
Feed to Local schemes (Mandatory)
Feed to POLC (Mandatory)
Feed to POL Data Warehouse (Mandatory)
The following feeds are also required:
10.
ll.
. Feed to NRM (Desirable)
. Feed to Parcel Force (Desirable)
. Feed to Pivot (Desirable)
Feed to NBSC (Desirable)
Feed to SPMR (Desirable)
Feed to National Savings (Desirable)
. Feed to Class (Desirable)
Feed to RMMI (Desirable)
Feed to Local schemes (Desirable)
. Feed to POCM (Desirable)
. Feed to TIP (Desirable)
. Feed to POL A (Desirable)
Feed to Regional Reference Data (Desirable)
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 30 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
RD-068
The following processes as defined within the process maps need to be supported by the system.
Al Make Product Changes
. Enter data Items
A12 Make Branch and Organisation Changes
Initiate non-advance change
Initiate advance change
Log in branch/org. change
Perform impact assessment
Agree change
Enter data items
Send to Fujitsu
eee eceee
A13 Reference Data Verification
Verify for completeness
Prioritise
Enter extra data items to send
Verify and authorise data
Update system
Provide reports
A14 Data Verification
e Perform validation and verification stage
e Authorise release to live
Ref.
High Level Requirement Description
MIH-004
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
To provide the mechanism for a single view of management information irrespective of the number of sources
MIH -005
To capture the current outputs of the various legacy systems, assess their usage and, if still required, determine their
new source
MIH-006
To provide performance based analysis
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.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 31 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
MI-003 The system must be able to generate error reports, for example
{branch concerned, type of error, cash account week, number of errors of that type} from the following sources: -
DVLA (around 4000 per month) (Presently supplied on paper. So details are keyed in.)
“OBCS" (700 per month) (Supplied on disc.)
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 BA11’s a month.)
GIRO (Around 1000 per month.) (Supplied on disc.)
National Savings and Investments (although we do not currently receive data from NS&l)
MI-004 Removed
MI-005 Removed
MI-006 Removed
MI-007 Be able to supply the organization with appropriate summary details of the errors in their area.
MI-008 Removed
MI-009 To work out a notional cost for recorded errors for each branch by applying ABC.
MI-010 Removed
MI-O11 Removed
MI-012
LID (Mandatory)
MI-013 The business requirement is to be able to produce branch 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 branch based sales.
“Notional” income. (i.e. “Income” calculated by multiplying branch value or volume of sales by a standing factor.)
Network costs.
Contribution. (i.e. Difference between notional income and costs.)
MI-015 It needs to be possible for reports to be able to show actual to budget or actual to plan comparisons. In addition, it
must be possible to compare the results shown to the previous year.
M016 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>CTT>Items
Client: Market> client group> client
Network: National Network>Executive Director> Head of Segment> Head of Area>RLM>Branch
Periodicity: (a) Year>Accounting Period>Day (b) Year>Cash Account Period>Cash Account Week> Day
Branch Type is in addition to the 4 main dimensions: (i.e. be able to analyze results into branch types such as large,
medium and small sub scale payment offices.)
MI-017 The system will provide the following report types
On screen
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
Paper
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.
M018 The system must provide the flexibility around reporting dimensions. It should be possible fo “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 outlets not included e.g.
non-polled offices.
MI-020 The system must hold for an appreciable time (35 days) a base record, compressed from the original transaction
data, but still holding enough details to provide extensive and flexible analysis
MI-021 Removed
MI-022 Removed
MI-023 Detailed (item/branch/date) historic data will need to be available for at least 12 months. Summary level data may
be held for up to 5 years.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 32 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
MI-024 The system should be capable of reporting “flash” reports within next working days of the original transactions. Users
should be aware of: -
Level of missing offices, if material, when reports are run.
Missing data streams when reports are run
MI-025 Removed
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.
M028 ‘System reporting parameters must deal with the historic changes in reference data.
MI-029 Removed
MI-030 The system will provide a mixture of ovemight reporting and ad-hoc enquiry to 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)
MI-032 Removed - The Operation MIS reporting requirements as specified in the MI Workshop should be used as further
detailed analysis.
will be provided under the 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 required
MI-036 'CTT Group Desc’ table need to be renamed ‘Sales Reporting Group’
MI-037 The option (for users) to 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 Parity
carrying out reporting. We need to understand the feasibility/costs of bringing 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-041 Development of portal for access of results by retail line
SALES & MARKETING ANALYSIS (Mandatory)
MI-042 Removed
MI-043 Removed
MI-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 that sit within E2E
M046 Daily reporting by value, volume and margin (all products) as provided by ABC.
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.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 33 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
M049 Identify the progress of the business agains! target — volume, value, margin, mix for all products
MI-050 Provide the ability to carry out session analysis on products purchased within a session.
Intellect (Mandatory) t. b. c.
MI-051 The system must provide functionality to analyze transactions and cost by the following 4 main hierarchical reporting
dimensions:
© Product
Client
Organization
© Time
Performance Indictors (Desirable)
MI-052 Development of the system to capture additional P! data to enable the system top become the one access point
black box
The key areas of performance that are currently being measured by the operations team in PO Ltd are:
Sales
Income
Overheads
Profit reporting
Network Reinvention Migration - Data not yet available
Have Your Say survey results - data is available from Group
Customer Satisfaction Survey - This is currently under development and no details are available as yet
PO Card Account - Data is received daily from EDS
Mystery Shopper data - Covering Q of S, CSI and PK. Data from NOP monthly. Long term future of this reporting is
under review.
ONCH - Not sure how this will interface with the rest of E2E
PISCES - Data on Post shops
In addition there is a requirement captured at the feasibility stage re the reporting that takes place via NSBC. This is
mainly around debt recovery so the question arises as with ONCH as to how this aligns with the rest of E2E.
GA Besiness Requirements — Release 22.3
SAL Branch Liability Management and Central Reporting
Ref High Level Requirement Description
BLH-001 I There must be a legally acceptable declaration of Business undertaken incorporating
- Business transacted
- — Holdings
- Discrepancies
BLH-002 It must be possible to take a snapshot at a stated point at time
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
Page 34 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
BLH-003 I There must be a point in ime where the whole office is balanced off
BLH-004 Confirmation of volume and value of business on which subpostmaster gets paid should be possible
BLH-005 There must be the ability to confirm liability to PO Ltd
BLH-006 There will be a set period of time to do the declaration — forced by the system.
BLH-007 There should be the ability to have override controls to be able to continue selling (if person responsible not available)
BLH-008 I There should be a blind declaration but provide easier means of tracing discrepancies (semi-sighted)
BLH-009 There will be greater granularity of data to assist ease of operation
BLH-010 I Itmustbe possible to feed in non-customer facing data (Ideally) on a daily basis
BLH-011 There will be the ability to capture non-accounting data (remuneration implications and management fees)
BLH-012 There will be the ability to identify loss by stock unit
BLH-013 I Reporting from the system should not lose those useful reports which might now exist which aid the sub-posimaster
BLH-014 I Deleted
BLH.015 _ I Declaration/iability to be at close of business
BLH-016 I Controls are required to instigate the process
BLH.017 I Cutoff mes will allow for trading days
BLH-018
There is a requirement to report the following information from the branch for the central systems. It can be broken
down into a number of categories:
@ Transaction Data (to support enquiry, reconciliation and for passing to MIS)
= Summarised Transactions Values (for posting to POL FS)
=~ Summarised Transaction Volumes (for passing to SAP HR for Postmaster Remuneration)
Ref Programme Requirement Description
BL-001 Accounting arrangements must use open item ledger principles.
BL-002 Transactions carried over should have the correct transaction date even if the posting date is recorded as the next
period.
BL-003 To record counter transactions such as to create consistent views of the liability of agents to the Post Office and the
Post Office to its clients by products.
BL-004 To record transactions such that views can be generated in arrears for any period. ( ¢.g. daily, weekly, monthly,
quarterly, annually.)
BL-005 Adjustments for errors need to be identified as a adjustment for a specified reason so settlement can be itemised
accordingly. The date of the transaction needs to be captured as well as the posting date.
BL.006 I The system must be able to give “instantly” accessible reports that show the total client debt view.
BL-007 Error corrections and adjustments need to be fed into the process at the same point as the originating error
BL008 I Branch liability to enable clerk, Branch & centre fo have a common view of branch liabilly.
BL-009 Liability data to be available quickly at all levels
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 35 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Provide a traceable/audit trail of transactions to confirm balance and track errors.
BL-010
BL.11 I Atstook check, a loss affects branch liability ~ depending on the product & agent & client contraci details.
BL-012 Record gains/losses by product, which enables the liability to be derived and posted to a stock gain/loss suspense
account, with a time & date stamp.
BL-013 Stock gain/losses and their quantity recognition at the branch is recognised/posted at stock declaration
BL.014 I Value at loss may be different from sales value
BLO15 Discrepancy arising from stock declaration is not immediately converted to cash equivalent gain/loss in suspense
account, (defined by business rules — product/total value).
BL.016 I Stock check confirmation posts discrepancy quantity to stock gain/loss suspense acoount
BL-017 Branch data should also be available at a national level for client losses / provisioning and probity purposes.
BL-018 Branches to be able to see sales and loss or gain values on stock declaration discrepancies, so they know their
liability(loss) and can investigate value discrepancies (sales)
BL-019 Clear set of business rules for reversals & corrections which are able to be enforced
BL-020 System facilities must support putting notices to the right account - must be able to record transactions against different
owners for the same branch.
BL-021 Retain accounting data at branch level for 6years for legal purposes - method to be defined.
BL-022 I To record errors identified by verification routines or by other system procedures ( e.g. remittance errors/ stock take
discrepancies) such as to create consistent views of the liability of agents to the Post Office for those errors and of the
Post Office to its clients by product.
BL-023 To account for errors by date of original transaction as well as by posting date.
BL-024 To provide a means of adjusting errors that is compliant with the operating process.
BL-025 Deleted
BL-026 I Tobe able to re-instate “excused” net losses
BL.027 I Reporis must be available to provide individual and branch accountabilty
5A Benorting Customer Data
Ref High Level Requirement Description
CUH-001
To continue the functionality unchanged form the current system —
This is the passing of AP Client Data to the AP Clients.
NB this also includes any reporting to Banks (via NBE), Streamline and E-Pay.
5A3. at Settlement
Ref High Level Requirement Description
CSH-001 I To implementa client ledger which accurately identifies PO Ltd liability to clients.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 36 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
CSH-002 I To receive a daily interface of summarised transaction data, from Horizon, by client
or product
CSH-003 I [0 refer to information about transactions from clients in order to resolve any disputed items and determine true liability
CSH-004 I To receive a daily interface of summarised transaction data, from SAP/ADS, by client
or product
Ref Programme Requirement Description
CS 001 Adaily view of summarised balance by client, by branch or cash centre, and by day.
cs 002 Ability to split values, when a client has several products with different terms of payment, in order to map into different
accounts in the ledger.
CS 003 The ability for each trading day to have a unique line.
CS 004 The ability for non-polled offices transaction data to be summarised into the relevant trading day when next polled
CS 005 The ability for differentiation between trading date and posting date.
CS 006 The ability to receive client summary reports, by volume and value, for Automated Payment clients
CS 007 A mechanism to be able to trace disputed totals back to transaction level in order to resolve and correct information at
the appropriate point to amend ledgers, and reporting or management information
SAA Verificatien
Validation/Verification - Range Checks
Ref Programme Requirement Description Proposed
Application Area
VER 001 The requirement is for different levels of range checks to be applied to different types of branches I TMS
(e.g. Main branches, Sub post offices & Cash Centres - exact spilt to be defined) to match current
structure & be flexible enough to meet future organisational structures.
VER 002 Open/closure of products Counter/NRDS.
e Eg. transaction data/remittance activity not expected before X date
« Eg. transaction data/remittance activity not expected after X date
(Investigate current relationship between RDS and CBDB)
VER 003 Volume of expected transactions per branch TMS
— Upper limit
¢ — Lower Limit
VER 004 Value of expected transactions per branch TMS
© — Upper limit
© Lower Limit
VER 005 Divisibility checks (front end driven by Reference data where possible). E.g. total value of sales of I Counter
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 37 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
product per branch must be divisible by unit price
VER 006 Geographical product checks — transactions received out of area. E.g. For a Reference Data I Data Warehouse
core product where we are only expecting sales to be transacted within a certain geographical
area (currently individual offices are not always defined).
VER 007 Negative sales prompt TMS
¢ — Front end driven check to ensure that the office has stock holdings of a particular value
stock product to enable them to sell (currently Horizon enables an office to sell an item
that they are not holding on their stock declaration - the result is a negative sale)
¢ — Ability to identify stock holding movements across products as part of stock declaration
process
VER 008 Cross checks Data Warehouse
¢ Check to ensure that for a particular product both volume and value figures have been
recorded (Front end driven by Reference Data driven if possible)
Validation/Verification - Rota Checks
Rota checks involve the physical checking of ‘foils’ against total volume/value of transaction sales recorded for a particular branch. This
process acts as a deterrent against fraudulent activity by agents and branches and is a Security and Audit requirement. It is likely in future
that the number of these checks may reduce compared to those currently undertaken however from the system point of view the
functionality is required regardless of the volume of checks required and products applied to.
Rota checks are currently applied to the following products within TP:
Money Orders
Postal Orders
Savings Stamps Redeemed
Vouchers to TP
Inland Revenue
As an example, currently 1,500 branches are picked per week and all rota check products are checked against these branches for 3
consecutive weeks. Then a new set of 1,500 branches is identified. This is not a random selection process, there is some logic applied to
ensure that over a defined period of time all branches have been rota checked.
Ref Requirements Description Proposed
Application Area
VER 009 The System should generate the list of rota check offices and then produce a summary report I TMS
detailing each rota check branch and the volume and value of transactions to be checked against
the physical ‘foils’.
VER 010 Rota checks are also currently applied to Pensions & Allowances although the Client defines the I TMS
exact offices each week (electronic feed received). Ability to receive the list of rota checks offices
into the system and produce a summary report detailing each rota check branch and the volume
and value of transactions to be checked against the physical ‘foils’.
Validation/Verification - Other Exception Checks
Ref Requirements Description Proposed
Application Area
VER O11 Supporting Document Matching TMS
System functionality to match two streams of data, identify exceptions and provide details to
enable investigation. For example matching a client supporting document stream against
transaction information in terms of total volume and value of transactions per branch. Data
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 3.4
Page 38 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
for matching could be received daily or weekly,
Other Validation/ System Functionality
Ref Requirements Description Proposed
Application Area
VER 012 Ability to perform data validation on files produced by TMS and supporting document files received I TMS
into TMS. (e.g. data received from clients must be validated against a list of recognised branches).
VER 013 Aunique ID to be automatically assigned to each exception identified. TMS
VER 014 Workflow capability (Debt Recovery Case Management)- ability to pass exceptions across teams. I Identified in TMS
Ability to identify from which area/ team the exception was issued to aid disputes process. Managed in POL
FS.
VER 015 Ability to define and apply stages to exceptions to enable tracking through process and area to I POL FS
which area or team the exception is currently assigned
VER 016 Ability to apply matching between data streams and create exceptions TMS
VER 017 Ability to apply data validation/verification checks and create exceptions TMS
VER 018 Ability to identify exceptions and gain access to relevant level of information to be able to I TMS/ POL FS/
investigate discrepancies. Data Warehouse
VER 019 Process to allow TP to manually make adjustments to transaction data (volume or value) or for TP I Txn level data -
to have the ability to send adjustment notices to branches. This information needs to flow into TMS I via TMS
in order to ensure that the amendments are reflected in POL FS - for debt recovery & client I Client level data -
settlement, in HR SAP — for Agent Remuneration, and in Data Warehouse for Management I POL FS
Information capability. May need a separate process for closed offices.
VER 020 Ability to make supporting document adjustments (where a matching exception has been identified I Txn level data -
between supporting document information and transaction data stream). via TMS
Client level data -
POLFS
VER 021 Where a matching exception has occurred one of the streams of data must be amended in order to I Txn level data -
clear the exception. via TMS
Client level data -
POL FS
VER 022 Where a range check exception has occurred, TP must have the ability to clear the exception I Via TMS
without making adjustments if the investigation has concluded that although the range was
exceeded the information recorded is correct.
VER 023 Ability to apply wait times on supporting documents. This means that where supporting document I TMS
information is received from the client and is known to be received late, the matching should not
take place between the supporting document and transaction stream until a defined period of time
has passed. This will avoid creation of exceptions that in reality are not true exceptions and
therefore do not require investigation.
VER 024 Ability to make corrective adjustments across multiple branches by making adjustments within the I POL FS
ledgers for feeding back to branches
VER 025 Ability for system to adjust discrepancies/ exceptions below a defined threshold for feeding back to I TMS/POL FS
branches, negating the need for TP to investigate and resolve.
VER 026 Ability for system fo recognise and correct exceptions where data is received late. (E.g. supporting I POLFS
document stream has been received, but transaction data is received late due to non-polling).
Exception will have been created which can now be cleared. Functionality to Include comparison
across accounting periods.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 39 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
VER 027 Ability to record details against individual exceptions (Debt Recovery Case Management) to track I POLFS
progress through investigation and towards resolution. Freeform text field plus TP operator details,
time and date stamp for audit requirements. Measurement against agreed timescales.
VER 028 Process to allow TP to manage debt via direct link to branch (i.e. electronic flow of data rather than I POL FS/TMS
paper generated)
VER 029 Monitoring of system rejections to ensure that data is resent and processed or accepted I POLFS
successfully Data Warehouse
VER 030 System Management controls e.g. access levels, user ID's, passwords etc. POL FS
Data Warehouse
VER 031 Ability to monitor interfaces received and processed or rejected, and extracts produced including I TMS
reconciliation of file interfaces across systems (i.e. data received by POL FS from TMS also I POLFS
received by Data Warehouse). Where rejections occur, error messages should be produced, I Data Warehouse
indicating reason, to aid investigation.
VER 032 Systems to record details of adjustments and hold within an audit log, Ability to view details on I Via TMS
soreen or produce reports by selecting specific criteria POLFS
Automated Reconciliation
Ref Requirements Description Proposed
Application Area
VER 033 Ability to amalgamate the DRS reconciliation processes with POL Reconciliation TMS
processes
VER 034 To reconcile data against the accounting flows being ledgered by trading day TMS
5A5. Bebt Recevery
Ref High Level Requirement Description
DRH-001 I To implement a debtors ledger (accounts receivable) which accurately identifies amounts owed to PO Lid liability from
agents, former sub postmasters, customers and clients in relation to transaction balances. If client balances are on an
accounts payable ledger then to be able to identify and manage debit items within the overall creditor.
DRH-002 I Deleted
DRH-003_ I [0 be able to record debt recovery plan decisions, and action taken so as to manage debt recovery and document
stages of escalation taken.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 40 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
DRH-004 I To be able to refer to information about transactions both in Horizon and directly entered trading
transactions with debtors, in order to resolve any disputed items and determine true amount recoverable
» NB Ifamounts owed to the PO but still under investigation are recorded outside of the debtors
ledger but within the suspense area of POL FS (could be named discrepancies under
investigation), to be able to manage these as if they were on the debtors ledger ie
» toaccurately identify to branch,
> to know which date they relate to and therefore which agent and the time outstanding ie age,
> to refer to information for investigation purposes and
> torecord action taken.
DRH-005 To be able to generate identified transaction errors if as a result of investigation debts need to be
transferred and corrected within a branch liability statement.
DRH-006_ I Tobe able to view debtor credit history in order to assess credit worthiness.
DRH-007_ I To be able to assign appropriate credit terms to different products eg 30 days for trading transactions, monthly
instalments by deduction
DRH-008 I To be able to assign different agents to a central “head office” payment point in the instance of multiples who require a
central authorisation for cash to be sent to the PO.
Ref Programme Requirement Description
DR 001 A daily view of outstanding debtor balances (or suspense items) and the history of management for live
items
DR 002 Ability to age debi (or suspense items) so as to manage over due items.
DR 003 A mechanism to be able to trace disputed totals back to transaction level in order to resolve and correct information at
the appropriate point to amend ledgers, and reporting or management information.
DR-004 A flag needs to be set when it is known that an office is to be closed. The information will come
from the branch closure notice
DR-005 A flag needs to be set when a branch (or in the case of multiples the total of branches) has a debt
of more than £5,000 this includes all debt
5A6. Cash Centre Cash Management
Ref High Level Requirement Description
CHH-001 ‘SAPIADS to make available, by cash centre, to the POL Financial System the daily cash movements by for entry into the
cash ledger
CHH-002 SAP/ADS to make available, by cash centre, to the POL Financial System the detailed cash pouch data,
for remittances into the cash centre, for entry into the cash ledger to enable Cash In Transit matching
within the ledgers
CHH-003 SAP/ADS to make available, by cash centre, to the POL Financial System the summarised daily client
related transactions by client for entry into the client ledger
CHH-004 I SAPYADS to undertake the summarisation of required data, to an agreed level, prior to entry into the cash and client
ledgers.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 41 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
CHH-005 I The interface will provide all transactions which affect cash values of the cash centre. For example = Inward
and Outward to POL
Inward and Outward to F's
Inward and Outward to Customers/Clients
Inward and Outward to 3" Party
Cash centre adjustments
Cash centre discrepancies
CHH-006 I The interface will provide a snapshot of all transactions at approx midnight and must be available within the POL FS by
07:00 the following day
Ref Programme Requirement Description
CH -001° The Cash Centre Trading Statement will replace the current cash account process.
The statement is an internal document for the cash centre only and will not be forwarded to an independent area unless
security and audit determine that that is essential. The actual data within the trading statement will have already
populated the ledgers by the daily interface outlined above and therefore no data from the statement will populate the
interface.
The trading statement will encompass a snapshot of cash and stock and also any current discrepancies or suspense
items. It will also enable the cash centre to view what business has been transacted over the last period. The cash
centre manager will be required to “sign off’ the trading statement as a true and accurate position at specified points in
time.
It is possible that the SAP/ADS system can produce the level of information required which would satisfy both control
issues and security and audit requirements.
There is workshop being planned to establish the actual requirements, and the SAP/ADS capability, which will feed into
the detailed requirements phase of end to end.
SAI. Steck RecencHiation
Following the removal of the cash account it is essential that stock control is maintained and enhanced where possible.
There are several si
stock types held within the branch and the central stores locations
1. Transaction stock - this is stationery and is out of scope
2. Purchased stock ~ This is stock which is purchased prior to distribution. The point of purchase of the stock creates a balance
sheet entry (Dr Stock, Cr Bank) and the point of sale creates cost of sale (Dr Cost of Sales, Cr Stock). The stock of these items
will be held within the balance sheet.
3. Sale or Return - This stock is not purchased and therefore has no value until sold or lost. There is no balance sheet value and
no cost of sales attributed to these items when sold. If stock item is lost there may be a penalty payable to the client which may or
may not equal the sale value.
4. Hybrid (kt
the point
nown as consignment stock in SAP) ~ This stock is a combination of 2 and 3 above as the stock is purchased later than
of receipt but paid for prior to the sale of the stock item. For example on activation of phone card packs.
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 42 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
All the above
items of stock(except 1) must be monitored in order to maintain end to end control and integrity. This must include
movements of stock such as receipt from supplier into the National Secure Stock Centre remittances into and out of branches and the
sale of stock in order to establish the current stock holdings within the Business.
To gain an end to end view of the stock within PO Ltd an interface with the central stock system will be required. Currently the National
Secure Stock
Currently Hori
includes. This
There is a
Centre produces a stock account which is similar to the branch cash account and P16/P20D equivalents for remittances.
izon provides a feed to OpTip and SAP/ADS with details of some stock items however itis not clear which items this
needs further investigation during the detailed requirement gathering stage.
requirement during detailed requirement gathering and solution design to investigate
the most effective way to ensure that this data is captured correctly and for investigations to be
undertaken on that data at branch and stock item level.
Ref High Level Requirement Description
SRH-001 I To provide end to end visibility of the stock movements from point of entry (whether direct fo branch or via the National
Secure Stock Centre) until sale, loss or return.
SRH-002 I To provide a daily feed to the stock control system of stock sales in order to maintain accurate link between stock
movements and stock sales.
SRH-003 I To provide a system generated periodic declaration of stock at the branches, identifying stock discrepancies, for
despatch to the stock control system
SRH-004 To provide an interface of stock at National Secure Stock Centre, identifying stock discrepancies, for despatch to the
stock control system
‘SRH-005 _ I To provide auditable balances of stock for probity and audit purposes
Ref Programme Requirement Description
SR oor The Horizon system fo make available details of identified stock discrepancies by volume and value , where relevant, at
a given point in time, as defined by the Branch Trading Statement.
SR 002 The Horizon system to make available to the stock control system the daily
movements of stock into and out of branches by volume and value. These must include both internal and external
remittances.
SR 003 The Horizon system to maintain link between stock movement and stock sales and make available to the stock control
system the daily sales of stock.
SR 004 The National Secure Stock Centre to make available details of identified stock discrepancies by volume and value,
where relevant, at a given point in time in order to identify stock to the stock control system.
SR 005 The National Secure Stock Centre to make available to the stock control system the daily movements of stock into and
out of the central stock unit by volume and value, where relevant. These must include both internal and external
movements.
SR 006 The stock control system to hold information by stock type in order to inform POL FS of all balance sheet impacts.
SR 007 POL FS to hold value of all stock, which has a balance sheet impact, by stock tem.
SR 008 To identify instances of obsolete stock which should have been returned to National Secure Stock Centre
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 43 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
548. Financials
Ref High Level Requirement Description
FIH-001 Introduction of a new financial system (POL FS) to produce the financial ledgers for Post Office Ltd (POL) to report to
Royal Mail Group using simplified business processes and reduced duplication and requirement for reconciliation
FIH-002 Introduction of a Client Ledger and Agent Ledger to enable standard procedures for Debt Recovery and monitoring. To
enable the capture, validation, verification and correction of client transaction data.
FIH-003 Produce POL Ledgers to report P&L and BS for POL in so far as the transactions are handled within the POL
environment wit a stream of data from branches and cash centres
Ref Programme Requirement Description
Create client ledger
FI-004 Adaily view of summarised balance by client, by branch or cash centre, and by day.
FI-002 Ability to split values, when a client has several products with different terms of payment, in order to map into different
accounts in the ledger.
FI-003 The ability for each trading day to have a unique line.
F004 The ability for non-polled offices transaction data to be summarised info the relevant trading day when next polled
FI-005 The ability for differentiation between trading date and posting date.
FI-006 Auditable transaction postings
FL-007 To be able to determine the amount due to a client using payment terms agreed with client
FI-008 To provide information of aged balances
FI-009 To enable payments to/from clients with functionality for matching and closing paid items to leave open items for
management of debtors/creditors
FI-010 To be able to produce correspondence to chase outstanding items e.g. statements, reminder letters
Create agent ledger
FI-011 To process agent debt items
FL-O12 ‘Allow matching to enable management of open items
FI-013 To be able to produce correspondence to chase outstanding items e.g. statements, reminder letters
F014 To provide information of aged balances
Create POL Accounts
FI-015, To produce a set of auditable accounts within the framework of the Chart of Accounts specified in the appendix
FI-016 To enable matching of suspense items for debt recovery purposes and error handling
FI-017 To enable the reporting of stock values in the relevant balance sheet accounts (this will cover the Stock Ledger)
FI-018 To consolidate information from SAP ADS financials to report the POL accounts
FI-019 To account for business transactions which will populate the trading ledger
F1-020 To have visibility of branch transactions by day (this will cover the Branch Ledger)
548. Becemmlssioning and Fajitsa Rationalisation
Ref High Level Requirement Description
DEH - 001 I There is a requirement to ensure that where functionality and outputs exists in current legacy systems which are required
in the future that they should be catered for in the new systems environment.
DEH - 002 I There is a requirement to simplify the Horizon estate as a result of the changes made to business processes contained
within this document
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 44 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
DE-001 I Each interface, function and output contained in POL legacy systems due for decommissioning will be catered for in the
future where this is justified. Section 11.2 describes this in greater detail
DE-002 There is a requirement to simplify the reconciliation processes performed within the Horizon central host systems by 31st
March 2005.
Verification that this requirement has been met will be evidenced by the removal of support for the processes handling
reconciliation between TPS/DRS and TPS/APS such that Fujitsu Services can realise the SI cost savings detailed in
Schedules 10 and 12 of the Post Office/Fujitsu Services
Agreement.
DE-003 I There is a requirement to simplify the Horizon estate to reflect the removal of support for legacy accounting processes
(e.g. those involving Cash Account) and legacy systems by 31st March 2005. Verification that this requirement has been
met will be evidenced by simplification of the Horizon estate such that Fujitsu Services can realise the SI cost savings
detailed
in Schedules 10 and 12 of the Post Office/Fujitsu Services Agreement.
DE-004 There is a requirement to remove the Horizon data warehouse, which is currently used for the maintenance of
transaction data, by 31st March 2005. Verification that this requirement has been met will be evidenced by the removal
of support for the Horizon data warehouse such that Fujitsu
Services can realise the SI cost savings detailed in Schedules 10 and 12 of the Post Office/Fujitsu Services Agreement
DE-005 There is a requirement to simplify Post Office requirements relating to Horizon system boundaries by 34st March 2005
as detailed in Schedule 12 of the Post Office/Fujitsu Agreement. Verification that this requirement has been met will be
evidenced by Fujitsu Services being able to reduce
their operational costs sufficiently to enable Post Office to realise the savings in Operational Charges detailed in
Schedules 10 and 12 of the Post Office/Fujitsu Agreement
5410. Management Information — Additional to Release 1
Client Reporting (Contractual Agreements)
Ref Requirements Description Business Area Category Report! Proposed
Functionality Application
Area
MI 100 Information required by Audit for I Data Exceptions Client Report POLFS
issued error details, errors BTA
and errors not Network
Reinvention offices
MI 104 Information to Multiples Partners I Data Exceptions Client Report POL FS
regarding outstanding, issued
and BTA errors.
MI 102 Ability to produce data reports I Data Preparation Client Report Data Warehouse
for Sales and Marketing.
Volume and value of
transactions by branch, top
sellers and worst sellers for a
particular product, write off and
wastage details.
MI 103 Ability to pull off a full list of I Data Preparation Client Report Data Warehouse
available data fields to enable
clients to define specific
reporting requirements.
MI 104 Ability to produce data files or I Data Preparation/ I Client Report TMS/POL FS
reports for clients as defined I Data Exception
within contractual agreements.
[DATE \@ "ddd, dd MMMM yyyy" ]
Version 3.4
Page 45 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
adjustments
mismatches
of payment details.
For example volume and value
of transactions, customer details
if applicable, product breakdown
by volume and value, details of
made,
between
supporting document stream
and transaction stream, method
data
client
Example
clients are Local Schemes,
Department of Work and
Pensions, Girobank, NSB,
UKPS, AON, First rate, DVLA,
Department of Health, Inland
Revenue.
MI 105
Information
openings,
Provision of
regarding office
closures and relocations to
various internal parties and
clients (current TP 129 process)
Support
Client
Operational
&
Report
RDS
Management Reporting (Performance Control)
Ref
Requirements Description
Business Area
Category
Report!
Functionality
Proposed
Application
Area
MI 106
Budget and performance information
in order to calculate real unit cost.
Includes capacity planning
capabilities
All
Management
Report
Data Warehouse
MI 107
Total volume and value of
exceptions produced
Data
Exceptions
Management
Report
Data Warehouse
MI 108
Volume and value of exceptions
produced against data matching
(supporting document stream
against transaction stream)
Data
Exceptions
Management
Report
Data Warehouse
MI 109
Volume and Value of exceptions
produced against data
validation/verification checks
(ranges checks etc.)
Data
Exceptions
Management
Report
Data Warehouse
MI 110
Exceptions by product or client as a
percentage of total transactions
Data
Exceptions
Management
Report
Data Warehouse
Mi 111
Volume and value of exceptions
cleared to be reported by product,
client or all exceptions.
Data
Exceptions
Management
Report
Data Warehouse
MI 112
Volume and value of exceptions
cleared split between system
cleared and manually cleared (TP
intervention/adjustment)
Data
Exceptions
Management
Report
Data Warehouse
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 46 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
Mi 113 Volume and value of exceptions I Data Management Report Data Warehouse
cleared by TP by individual team I Exceptions.
member
Mi 114 Volume and value of outstanding I Data Management Report POL FS
exceptions by branch, by age, by I Exceptions
value
MI 115 Volume and value of issued errors I Data Management Report POL FS
by product or branch Exceptions
MI 116 Ability to pull off statistics to enable I Data Management Report Data Warehouse
identification of trends for exceptions I Exceptions
produced and their causes. Historic
data will need to be retained for up
to 2 years.
MI 117 Number and value of maintained I Data Management Report POL FS
errors and write offs by product Exceptions
MI 118 Ability to pull off statistics regarding I Data Management Report POL FS
team performance —_ (exceptions I Exceptions!
created, exceptions _issued, I Debt Recovery
exceptions cleared, —_ exceptions
outstanding etc). Ability to remove
from one teams statistics and add to
another team as the exception
passes through the process.
MI 119 Ability to measure individual TP staff I Data Management Report Data Warehouse
and whole unit (TP) against process I Exceptions/
set timescales Debt Recovery
MI 120 Measurement of manually keyed I Data Management Report DPU/ TMS.
supporting documentation including I Preparation
keyed to timescale and keying
errors.
MI 121 Information on data entry failures I Data Management Report DPU/ TMS.
(file interfaces and data rejections), I Preparation
reasons for failure or rejection,
identification of interfaces received
and not expected, and identification
of interfaces expected but not
received. Including transaction or
sup doc data not received, by
branch,
MI 122 Debtor days by client and product I Debt Recovery I Management Report POL FS
and trend analysis monitoring
MI 123 Creditor days by organisation and I Debt Recovery I Management Report POL FS
product and trend analysis
monitoring
MI 124 Errors produced for creditors and I Debt Recovery I Management Report POL FS
debtors - issued or resolved,
number and value, by client and
product.
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 47 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
MI 125 Progress of exception handling I Debt Recovery I Management Report POL FS
measured against target (failures to
issue or clear in x number of days)
MI 126 Aged debt profile by number and I Debt Recovery I Management Report POL FS
value
MI 127 Debt as a percentage of I DebtRecovery I Management Report POL FS/Data
sales/transactions by product Warehouse
MI 128 Monitoring of percentage of debt I DebtRecovery I Management Report POL FS
recovered and outstanding
MI 129 Bad debt provision monitoring Debt Recovery I Management Report POL FS
Operational Reporting (What we need to do our day jobs)
Ref Requirements Description Business Area I Category Report! Proposed
Functionality Application
Area
MI 130 Ability to pull off ad hoc reports I All Operational Functionality Data Warehouse
selecting required data fields from POL FS
available list and defining format as
required.
MI 134 Ability to run batch reports to defined I All Operational Functionality Data Warehouse
timescales and formats as required. POL FS
MI 132 Volume and value of transactions I Data Operational Report Data Warehouse
and sup doc information to be I Exceptions
reported in a variety of ways (e.g. by
transaction, by product, by product
breakdown (e.g. postal order bands)
by branch, by client, by group of
branches, by method of payment).
Require the ability to identify
negative sales (volume and value,
by branch, by product).
MI 133. All created exceptions to be reported I Data Operational Report Data Warehouse
by transaction, by product, by I Exceptions
branch. All outstanding exceptions
to be reported by transaction, by
product, by branch.
MI 134 Details of cleared exceptions to be I Data Operational Report POL FS/
archived but still accessible to I Exceptions Data Warehouse
provide a rolling 12 month view.
MI 135, Non polled data - missing I Data Operational Report TMS
transactions from branches shown I Exceptions
by branch and days since last
polled, also shown as percentage of
overall network
Mi 136 Ability to flag branches on exception I Data Operational Functionality POL FS
reports that require priority attention I Exceptions
or specific action (e.g. A = Network
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 48 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AccCM-PCD
Reinvention Office). Ability to
increase the number of flags applied
at any one time (max 10) and
redefine criteria as necessary to
enable prioritisation of exception
handling
MI 137
Error/exception information to
branches - currently produced by
STAM
Data
Exceptions
Operational Report Data Warehouse
MI 138
Ability to identify = multiple
transactions (e.g. same barcode
scanned twice)
Data
Exceptions
Operational Report Data Warehouse
MI 139
Ability to report Debt Recovery Case
Management By branch, by branch
type, by Agent name, by product (by
client), by age of debt.
Debt Recovery
Operational Report POL FS
Mi 140
Report on high value debt (e.g. all
outstanding debt which exceeds a
defined limit, by branch)
Debt Recovery
Operational Report POL FS
Mi 141
Report on Debt Recovery repeat
offenders (problem offices)
Debt Recovery
Operational Report POL FS
M142
Value of debt or credit by number, by
branch, by branch type (to meet
current organisational structure), by
product, by method of payment, by
age of debt
Debt Recovery
Operational Report POL FS
MI 143.
Former Subpostmasters accounts
held including Branch, Agent name,
Age of debt, Dispute details, Losses
(write off). Ability to search on a
particular field (ie. Agent name) and
be able to track status, audit log
entries
Debt Recovery
Operational Functionality POL FS
MI 144
Ability to identify specific types of
debt e.g. Invoices debt - Licence
fee, ISIS, Shortages, by agent, by
branch, by age of debt
Debt Recovery
Operational Report POL FS
M145
Disputed debt by branch, by client
(eg. Giro)
Debt Recovery
Operational Report POL FS
MI 146
Non-recoverable debt - e.g. as a
result of fraud or client negotiations,
details to be held until written off. By
network (national total of all
branches), by branch, by product, by
client
Debt Recovery
Operational Report POL FS
M147
Data archiving ability
Support
System Functionality POL FS
Data Warehouse
Mi 148
Ability to access archived data easily
Support
System Functionality POLFS
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 49 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
and run reports by transaction, by Data Warehouse
branch, by product, by client as
required
MI 149 Where a file has been interfaced I Support System Functionality & I TMS
‘successfully (e.g. data received from Report
client), the system should identify
details of any invalid records (e.g.
unknown FAD code) and be able to
produce a report to aid investigation
of the invalid records requiring
correction
MI 150 Transaction level data to be held for I Support System Functionality Data Warehouse
2 years
Mi 151 Ability to schedule regular report I Support System Functionality POLFS
production. Ability to monitor Data Warehouse
production of scheduled reports.
MI 152 Report showing _ transaction, I Data Operational Functionality & I TMS/POL FS
‘supporting document or client level I Exceptions Report
adjustments. By branch, by product,
by value, by number. To include
date of adjustment, user details and
reason code for adjustment.
Cash Management Requirements
Ref Requirements Description Business Area I Category Report! Proposed
Functionality Application
Area
MI 153 Ability to undertake trend I Cash Operational Functionality I POL FS
analysis in order to aid I Management & Report
forecasting of the future value
of transactions (e.g. DNS,
Girobank, DVLA)
MI 154 Ability to undertake trend I Cash Operational Functionality & I POLFS
analysis in order to aid I Management Report
prediction of client for ESFS
MI 155. Ability to identify and report the I Cash Operational Functionality & I POLFS
current outstanding balance within I Management Report
each ledger.
MI 156 Ability to report the total volume and I Cash Operational Functionality & I Data Warehouse
value of transactions by client I Management Report
including product ~—_ breakdown.
Ability to adjust settlement figures
for some clients to account for
payment net of commission
(management fees) and VAT.
MI 157, Ability to identify and report stock I Cash Operational Report Data Warehouse
holdings by client, by product, by I Management
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 50 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AccCM-PCD
denomination (e.g. Vodaphone
phonecards, £5, £10 etc.)
MI 158
Volume and value of transactions
required by Sales and Marketing to
inform management
fees/commission charged to clients
Cash
Management
Operational Report Data Warehouse
MI 159
Ability to produce reports to
aid reconciliation of ledgers
and substantiate ~—_ ledger
balances
Cash
Management
Operational Functionality & I POLFS
Report
MI 160
Deleted
MI 161
Ability to provide verification of
accounts - Erst & Young Audit
requirement
Cash
Management
Operational Functionality POL FS
MI 162
Ability to identify details of new
products and new clients including
mapping of products to clients
(browse access to Reference Data
information)
Cash
Management
Operational Functionality / I Data Warehouse
Report
MI 163
Ability to settle on sales for some
clients (current contractual
agreements)
Cash
Management
Operational Functionality/ POL FS ?
Report
MI 164
Ability to identify cash and stock
holdings by product, by branch
Cash
Management
Operational Functionality! POL FS ?
Report
MI 165
Abily to produce statement of
accounts for each client including
brought forward figures, sales,
settlements made and a closing
balance.
Cash
Management
Operational Functionality’ I POLFS
Report
MI 166
Access to transaction data (volume
and value) for all products on a
daily basis by product (RDS item
codes) grouped into clients -
extension of current CTS report.
Information to be spilt into Giro and
non giro clients, including country
split where applicable. Exact
content and format to be defined
but to include product descriptions
and summarised totals by product
and client for settlement purposes
(including late —_ transactions).
Preferred option would be for a file
to be produced and FTP’d to Future
Walk server by 07:30 on a daily
basis. Ability to pre-define daily,
weekly and monthly file contents
and specify clients to match
settlement agreements.
Cash
Management
Operational Functionality/ TMS/Data
Report Warehouse
ML167
Ability to identify cash remittance in
Cash
Operational Functionality & I POLFS
[DATE \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 51 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
transit values by product. Management Report
MI 168 Summary report of data posted to I Cash Operational Report POL FS
ledgers and interfaced to ESFS by I Management
value of debits/credits against each
ledger code.
MI 169 Summarised transaction data at I Cash Operational Report Data Warehouse
branch level, by cash centre area I Management
Ability to produce comparisons
across periods/years.
MI 170 Deleted
M171 Daily, National summary of I Cash Operational Report! POLFS
transactions, by client, by product, I Management Functionality
by method of payment. Split by
deposits and withdrawals (rather
than net position).
Mi 172 Updated transaction data received I Cash Operational Functionality & I POLFS &
from Non polled offices to have I Management Report Data Warehouse
indicator flag applied.
MI 173 Ability to pull cash holding data and I Cash Operational Functionality & I POL FS/ Data
transaction data from a_ single I Management Report Warehouse
source.
55. Exclasions
Anumber of facilities or implementation methods are described in the Feasibility Study ref: . E2E Simplification - Business Requirements
Specification (Vsn 2.0) Post Office confirms that the following items are not required in the Accounting & Cash management Programme
solution: -
Feasibility Study ref: E2E Simplification - Business
Requirements Specification (Vsn 2.0) Process Area
Comment
Sales
Allreferences to Prompts and Help in the sales process are not included
Inventory Management
All references to 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 \@ "ddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 52 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.6. High Level Process Models
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 53 of 174
© 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 3.4
Page 54 of 174
POL00038870
POL00038870
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 3.4
Ref Data File
Page 55 of 174
Data
Verification
4I
Al4
Live Ref Data
POL00038870
POL00038870
POL00038870
POL00038870
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 3.4
Page 56 of 174
© Post Office™ 2003
POL00038870
POL00038870
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)
I ‘Agree Change I_I Bc 20 ‘Send to Fujitsu
—_——
‘Stakeholders Change Definition d Initial Data Items oI
Enter Data I}—*
tems INew Data Triggers
OBC 20 Source I
MI Team ft f NIET
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 57 of 174
© 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 3.4
© Post Office™ 2003
aptured Data
Verify and
puthonise Datal
)
Change Originator
Verification Report
Authorised Data
RefData File
Data Feeds
Network Change Team
Page 58 of 174
>
‘Automated Advice of Changes (OBC 2 data)
Updated System
Reports
User Access,
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A14 Reference Data Authorisation
>
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 3.4
Page 59 of 174
© Post Office™ 2003
POL00038870
POL00038870
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 3.4
Page 60 of 174
© Post Office™ 2003
POL00038870
POL00038870
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 3.4
Page 61 of 174
POL00038870
POL00038870
POL00038870
POL00038870
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 3.4
Page 62 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A41 Create / Verify Branch Liability Statement
Transaction Data Balance Stock AdjustmentTransactions >
Branch Cash Holding i Units
Stock Transaction Information >
Ending Balances Balance Outlet
> 1 Branch Liability Statement >
2I
Opening Balances
Identified Transaction Errors pI Unknown Process
Stock Revaluation Information >
Stock Adjustments I
Cash Adjustments >
Cheque and Voucher Values
Lal
4
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 63 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
A43 Summarise Transaction Data
Transaction Data Scan
—TersactionData__
Transactions for
Stock Transaction Information Day
Accumulate ‘Summaries for SAP HR
Daily Transactions Transactions for
Adjust mentTransactions
‘Summarisation
Explicit Transactions
‘Summarised Transactions
Cash Centre Financial Transaction Data ‘Summarise
_ cash Contre
Transactions
Pouch Details (Electronic)
Ledger Entry Information
Unknown
Cash Adjustments Process 2
—LashAdusiments gs
Cheque and Voucher Values
Branch Cash Holding
Stock Revaluation Information
>
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
© Post Office™ 2003
Page 64 of 174
POL00038870
POL00038870
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
A44 Client Settlement to Client
Clanton Oat
[DATE \@ "dddd, dd MMMM yyyy"
ai ae setteretPayrert te Cent
Glen Surman/Repat 7 Speco
Lasgu Pot oratin
cst a
— Acjusted Future Settervent Payments
I o atin tanec
— +. 3 + OM tpi nan ita ata { a
face
Version 3.4
Page 65 of 174
© Post Office™ 2003
Upsate Leger formation
POL00038870
POL00038870
CetLesger Austen
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
‘Accounting & Cash Management
Programme
AccCM-PCI
D
A446 Authorise, Make & Account for Payments
Vendor Down
Payments
Settlement Amounts
Glient renters Data
Downpayments Info
Vendor
Settlement Payment to the Client
Settlement Amounts.
Payments
Invoices and
Credit Memos
Payments Info
Client invoices
2I
[DATE \@ "dddd, dd MMMM yyyy"
© Post Office™ 2003
Invoices Info
Account
Clearing [AP]
Ledger Entry Information
4l
Vendor Payments Info
Vendor
Account
Vendor Account Reports
Analysis
Correspondence:
with Vendors:
Version 3.4
Page 66 of 174
POL00038870
POL00038870
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
A465 Client Settlement from Client
identify
Settlement 1 Terms
Terms
4
Adjustments to Future Settlements
Ly agree Amounts {ajent Summary Report pl passives, I_Payment Request tg the Client
Due ftom Clients hell a”
——
2 3
Amen ue Updated Ledger Entry Information
Bank Statements __») Received [___Glient Summary Report
Amounts in Bank Account Receved
4
fiat an Sat Cent niger Aahatments
(Vertation ttement Discrepencies
Ledger Entty Information al Debt Recovery items
Resove
Discrepancies -————" J
SI Identified Transaction Errors: e
Finance
[DATE \@ "dddd, dd MMMM yyyy"
Version 3.4
Page 67 of 174
© Post Ofice™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project Accounting &
Programme
Doc Ref:
‘AcoCM-PCD
Cash Management
A455 Compare Settlement Data with Txn Data (Verification Activities)
Amounts in Bank Account Receved
Customer Info of Downpayments — Tmvoices and
own Credit Memos
Payments
1 EI
Upload of Bank
‘Statements
3
Bank Statement Info
Invoices/Credits Info
Customer
Payments I—
Settlement Amounts
[DATE \@ "dddd, dd MMMM yyyy"
Version 3.4
© Post Office™ 2003
4I
Incoming Payments info
‘Account
Clearing [AR]
E
‘Customer Payments Info
With Customers
Page 68 of 174
‘Conrespondence
Adjustments to Future Settlements.
Account
Analysis [AR] >
4] Customer Account Reports
4
POL00038870
POL00038870
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
Doc Ref:
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
A46 Verification
‘Transaction Data
Ledger Enty infomation
"Fransaction Data]
Range Checis Business Rules
‘Set Criteria
‘Checks
Rota Checks Ausiness Rules
[DATE \@ "dddd, dd MMMM yyyy"
Rota Checks Sufpmayy Level Discrepencies.
—_—__ Vouchers Despaiched
E} Customera Branch Enguites
Aatvty Exceptioh Reports I
\ of ARIES I _Oscepenin
Data
Transaction
Activity Level
‘Checks: I
4
Gheque
Verication )
I
3
Cheques Processed
‘atomaied
Transaction Data Reconciliation
‘GiientAuthorations
1
Version 3.4
Page 69 of 174
© Post Office™ 2003
Identified Transaction Emons
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A47 Debt Recovery
‘Avent Cre History teem et Prouenna eines es
toma Ds Racovary Business Res
ee Recon Arnounis howsh Paya
tomate Recowy Buses os
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 70 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
Doc Ref:
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
A48 - Produce POL Ledger
Ledger Entry Information
Produce Ciieqt
Ledger
(Produce Bran
Ledger
F
‘age
Diserepencies
Branch Ledger
‘Trading Transactons
Produce
Personal
Debt Information
Produce Nominb!
POL Busnes Ledger (ESS) I Leag
Nominal Ledger
Reconcile 7
Consolidate /
POL Busine:
Agent Ledge
> Memes
Branch I __Debt Recovery ems
Labiity -—PeetRecoven Nee
Branch Closure Nowe Managemen! Identified Transaction Engrs
BankStatements
ent __ Produce Cas
Cheques Processed fF
Sreamling SeWTements, mes
_Sisaniine Setlements)
Invesments& Borrowings
+ “invesments
Rabe
Wa Banktedade
Pradce
p{Busnes Trading
Ledger
d
of 2 Frediee
BoromngsandI
vedger I
Produce Sioa]
Ledger
gf
Revew and Reps
rr
[DATE \@ "dddd, dd MMMM yyyy"
© Post Office™ 2003
Finance
Version 3.4
Page 71 of 174
POL00038870
POL00038870
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
A482 Produce Branch Liability Ledger
Ledger Entry Information
[DATE \@ "dddd, dd MMMM yyy" }
© Post Office™ 2003
Branch Ledger
Actual
Cost/Revenue
> Capture
2
Version 3.4
Page 72 of 174
Period-End
Closing
(Controlling)
3
Branch Ledger
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A484 Branch Liability Management
I “ Latatty
[DATE \@ "dddd, dd MMMM yyyy"
Version 3.4
Page 73 of 174
© Post Office™ 2003
yw?
POL00038870
POL00038870
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 I Accounting
Bank Statements
i 1
A4851
Bank Account Info
General Ledger
POL Business Ledger (ES-FS)
Processing
Ledger Entry Information
[DATE \@ "dddd, dd MMMM yyy" }
Version 3.4
© Post Office™ 2003
2
A4852
Page 74 of 174
>
POL00038870
POL00038870
POL00038870
POL00038870
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
> Management J
>
Cheques Processed 2I
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 75 of 174
© 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 3.4
Payments and Receipts Info
General Ledger
Account Analysis
3]
Accounts Reports
Page 76 of 174
Closing Operations.
(Period End
Closing)
POL00038870
POL00038870
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A6 - Cash Management
‘rach Camara
‘Paes Order Charge Regus
1
: omnF secant & stg Pane
I
Cumann com vn Tah enna FAC = J pxcnoanarycntatin agent -
te Com Ragareer tren Mar = .
“ ‘Cash Receied trom Financial institutions > 5)
‘comm espacins I .
me
CanagrmertNa
coancores canna oratin
{__pacrownycomatos com come
cannecats I
. L
PO
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 77 of 174
© Post Office™ 2003
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 3.4
Page 78 of 174
© Post Office™ 2003
POL00038870
POL00038870
POL00038870
POL00038870
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 3.4
Page 79 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A614 - Barcode Scan Carrier
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 3.4
Page 80 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A615 - Receive and Scan Pouch from Carrier
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 3.4
Page 81 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
A63 Branch Central Cash Management
Marketing Forecasts
Branch Cash holding for Cash Planning
Planning
I
I
+f Wanaai Agreed Cash Orters
Planned Order Chay uests I Adjustments:
Specials ia 4
waar Non-Corformance Reports
Despatch
contermance
Montorng 4)
Cash Management
[DATE \@ "dddd, dd MMMM yyyy" ]
Version 3.4
Page 82 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
S7. Business Area Precesses
S11 Process Descriptions — Release 1
5.7.11 Receive and scan pouch from carrier
Process Map Reference: A 615
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 pouch details 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 on a daily basis) 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 solutions design
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 pouch details, 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 and to POL FS to allow for Cash In Transit tracking
= 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 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
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 yyy" J
Version 3.4
© Post Office™ 2003
Page 83 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.1.2 Barcote Scan Carrier
Process Map Reference: A614
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 liabilifies 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 Pouch
Collection Confirmation 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 twice a week.
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
= Pouch Collection Conformation - 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 yyy" J
Version 3.4
© Post Office™ 2003
Page 84 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
5.1.1.3 Cash Verification and Declaration
Process Map Reference: A612
Description: This process provides the accounting system (POL_FS) with a ‘generated’ 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 generated figure along with the currently declared ONCH
figures, and should enable them to more accurately plan cash deliveries to the branches and POL-FS will recive the
movements which have created the genereated figure
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;
= Agenerated cash figure for each branch for use in POL financials. (may be a cash movement figure, as
oppose to a total figure)
= Agenerated 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 generated the previous day
should be used. If the generated 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 will use the figure for its cash
planning activity
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 85 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
5.1.14 Summarize Transaction Data
Process Map Reference: A43
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 really 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 financial 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 branchs are held within Fujitsu's domain, and may be used for
information.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 86 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.1.5 Bank Accounting
Process Map Reference: A4851
Description: This process aims to capture all transactions contained in the Bank Statements into POL Financials.
Bank Statement processing
POL uses five 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.
Cheque Management
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 EDS daily.. 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
1. The cheques are remmed out the branch to EDS who clear the cheques on behalf of POL
2. _ EDS inform POL of the cheques — quantities and values which have been presented to the bank
3. The bank statement is checked against the value of cheques reported to POL by EDS that
are due to clear that day”
Further detailed analysis is required , to tie up the entire process from Counter to EDS and SAP Financials.
Streamline Settlements
Debit Cards are used in certain Branches to pay for transactions eg. DVLA. This is captured into Horizon at the Counter
and submitted to POL Financials via the Ledger Entry Flow information
The current point of discussion is the treatment of this transaction. Currently it is being treated as cash, when in fact the
monies are not physically transferred into POL’s account until the next business day.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 87 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
The requirement is to show Streamline amount if process in the ledger as a debtor 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.
Further detailed analysis is required, to ensure business is in agreement with proposed process including the
reconciliation between Streamline and the Banks, Streamline ( Emis File ) and the Fujitsu Systems of “DRS and EPOS'
, efor 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
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
e — 1stRate 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.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 88 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
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.
Fall back procedures: Manual process. No fallback.
5.1.1.6 Produce Borrowings and Investments Ledger
Process Map Reference: A487 (not shown)
Description:
This process is required in order to input the necessary information to produce the Borrowings and Investments Ledger
from the POL financials.
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)
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 89 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
- 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 1
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.
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.
5.1.1.7 General Ledger Processing
Process Map Reference: 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.
Gash 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.
Frequency of operation: Daily/Weekly/Monthly reviews depending on the accounts being reviewed.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 90 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
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.
5.1.1.8 Make Product Changes
Process Map Reference: A 11
Description: This process defines the introduction of a new or changed product. This enters the PACE process for
impact assessment and, if approved through this process the initial data items are entered into the system by the
Product Deployment Team.
Triggers: It is triggered by a client requirement being generated and by entering the PACE process (which is outside the
scope of Reference Data Change but initiates the necessary data for it)
Frequency of operation: Every time a new product is introduced or an existing one is changed
Volumes:
Automation: This will commence after the PACE process and the data items are entered into the system. Validation
routines will support this data entry and once entered automatic triggers will alert the Reference Data Verification
process.
Locations: Product Deployment Team (London)
Input requirements at the WP boundary: The only input is client requirements for a new or changed product
Output requirements at the WP boundary: The outputs are the triggers from the entered data to alert
Time Constraints: None
Fall back procedures: None
5.1.1.9 Make Branch and Organisational Changes
Process Map Reference: A 12
Description: This process defines the introduction of new or changed branch details including organisational
hierarchies. A new process operates for branch and organisational change which is similar to the PACE process for
products. Once the change is agreed initial data items are entered into the system by either the Ml Team (for
organisational hierarchy change) or the National Implementation Equipment Team for branch details.
Triggers: Every time new or changed branch details are required or organisational hierarchies are changed.
Frequency of operation: As required
Volumes:
Automation: This will commence after the branch change approval process and the data items are entered into the
system. Validation routines will support this data entry and once entered automatic triggers will alert the Reference
Data Verification process.
Locations: MI Team (Bristol) and NIE Team (Chesterfield)
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 91 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Input requirements at the WP boundary: Requests from field project managers to request changes to data into both
the MI team and the NIE Team
Output requirements at the WP boundary: The outputs are the triggers from the entered data to alert
Time Constraints: None
Fall back procedures: None
5.1.1.10 Reference Data Verification
Process Map Reference: A 13
Description: This process is operated by the Network Change Team acting as reference data administrators. The
process commences when the system is alerted with new or changed data items and allows for the entry of further data
items (where required) to build on those already previously entered. It also allows for a feedback loop to change
originators for verification purposes prior to authorising the data to update the system. The process also allows for wide
user access to the data.
Triggers: New data items entered into the system
Frequency of operation: As required.
Volumes:
Automation: Workflow is used to move the data items into this process where further data items are required.
Validation will support that data entry process. Automation will also support the verification process and the user access
to information
Locations: Network Change Team (currently Farnborough — but likely to move)
Input requirements at the WP boundary: New data items entered in previous processes.
Output requirements at the WP boundary: Reference data files and data feeds to wherever required plus reports
where appropriate
Time Constraints: Driven by when data elements are required
Fall back procedures: None
5.1.1.11 Reference Data Authorisation
Process Map Reference: A 14
Description: This is a joint process to be performed by the Network Change Team and Fujitsu to ensure that the data is
suitable for release into the live environment. This process will only operate where the data items indicate that the
process required authorisation as some items are pre-authorised.
Triggers: Update reference data items which require this type of validation and verification
Frequency of operation: As required
Fall back procedures: None
Volumes:
‘Automation: This should be a fully automated process where possible from the identification of those items requiring
this process through to the validation and verification
Locations: To be determined
Input requirements at the WP boundary: A file of reference data
Output requirements at the WP boundary: A file of reference data which is now authorised for distribution to the live
environment
Time Constraints: Driven by effective dates of the data items
Fall back procedures: None
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 92 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
612. Process Descriptions — Releases 2 2.3
5.1.2.1 Branch Liability At Branch
Process Map Reference: not shown
Description:
The purpose of Branch Liability Management is to enable the Postmaster to assess his / her overall liability to POL and
ensure that any necessary checks have been carried out and discrepancies have been resolved or recorded as
‘suspense items.
This is currently handled with the Function “Create / Verify Branch Liability Statement” within “A4 - Accounts and
Settlement
There are actually two separate purposes for the BLS and if we separate them and perhaps have two separate
processes and reports, then we may end up with a much simpler system. The purposes are:
= To force the Postmaster to accept the current position regarding his Liability based on a snapshot
holding of Cash and Stock and also any current Discrepancies / Suspense items. (This is in effect a
Balance Sheet.)
= To enable the Postmaster to see what business he has transacted over the last period and thus predict
his pay. (This is in effect a Receipts and Payments or Trading report.)
In order for the Branch Liability Statement (BLS) to have any meaning, then it is necessary to go through a Balancing
Process similar to that which is used for the current Cash Account. This is represented in the diagram as “Balance Stock
Units”. In particular it is necessary to Balance each Stock Unit within the Branch and then when all Stock Units have
been Balanced it is possible to see the overall picture of the Branch and so produce the BLS. This is represented in the
diagram as “Balance Branch”. The current process for Balancing (either a Stock Unit or the Branch) often involves
producing a Trial Balance which is then checked and then a number of adjustments (ie AdjustmentTransactions) are
made and another Trial Balance is produced
In particular, there is no direct flow to the POL FS except in the summarised transaction flows - albeit that the
Adjustment Transactions will be captured within these summarisations.
A separate sub-process “Handle Error Transactions” has also been included. This represents the process by which a
Postmaster is informed of a centrally identified error and is requested to create a correcting transaction in the Branch
which is then handled in the same way as any other Transaction in the Summarisation and Balancing processes. This is
the equivalent of the current “Error Notice” process.
Triggers.
It is expected that an End of Day trigger will be required in the future. The current assumption is that the rules for
defining the time at which it takes place would not change, however changing the rules should not be too difficult. The
reason for the 19:00 override is to ensure that Fujitsu can meet its current SLAs for delivering all AP data to clients and
transactional data to OPTIP. Changing those SLAs might allow the EOD time to be moved back (though there are other
considerations on the overnight schedule too)
It is anticipated that the EOD event will result in a change of Trading day in the Branch and also be used to trigger the
Summarisation Processes and any period reporting. It is possible within the current system to run various processes as
part of the EOD task including weekly processes (these are currently used for Cash Account reconciliation for example),
so a weekly Trading Report could be triggered or delimited by EOD once per week.
[DATE \@ "dddd, dd MMMM yyy" ]
Version 3.4
© Post Office™ 2003
Page 93 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Frequency of operation
Potential daily cash declaration process to ensure accurate daily position is reported with periodic production of trading
‘statements (to be defined)
Volumes:
To be determined
Automation:
The declaration process and production of trading statements will be fully automated through the selection of appropriate
parameters by the user
Locations
Every branch
Input requirements at the WP boundary:.
The Inputs are:
= Transaction Data
A number of the other flows can be considered to be specialisations of this. They are:
Cheque and Voucher Values
2 Stock Transaction Information
5 Stock Revaluation Information
co Stock Adjustments
a Cash Adjustments
c Branch Cash Holding
o Identified Transaction Errors
Output requirements at the WP boundary’
The Outputs are:
= Branch Liability Statement
= Adjustment Transactions
Note that this is treated just as if it is a flow of Transactions.
Time Constraints.
Current time constraints are as follows which need to be assessed in more detail in the new regime:
The time at which EOD occurs varies between Branches. It is intended that EOD will normally happen when the Branch
is inactive. The rules for deciding when EOD should occur are as follows:
m Read the Branch Reference Data for the scheduled Closing Time of the Branch for the given day of the
week
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 94 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
If there is no scheduled closing time (which is normal on a Sunday when the Branch is closed all day),
then EOD is 19:00 (ie 7pm)
m If the scheduled closing time is 18:30 or later, then EOD is 19:00
™ Otherwise EOD is 30 mins later than scheduled closing time (in most branchs this means 18:00 except
Wednesdays and Saturdays when it is likely to be about 13:30)
Fall back procedures
In the event of the system being unavailable at balancing and trading statement production time it must be possible to
recover to the position immediately prior to unavailability.
It must be possible for the user to pull off reports to assist in manual balancing processes. However, there is no
specific fallback if the system is down.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 95 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
5.1.2.2 Central Reporting from Branch
Process Map Reference: not shown
This is currently handled with the Function “Summarise Transaction Data” within “A4 - Accounts and Settlement’.
Note that this document is only concerned with summarisation of Branch
transactions. Summarisation of Cash Centre Transactions is covered elsewhere. In
particular it has been agreed that any such summarisation will be done within SAP
ADS.
Description
For Branch Transactions there is a two stage process, namely finding the relevant Transactions and then Summarising
those Transactions that need to be summarised into “Summarised Transactions’ and retaining those Transactions that
don’t require Summarising as “Explicit Transactions”. These are both sub-flows of “Ledger Entry Information’
5.1.2.3 Report Customer Data to Client#
Process Map Reference: A42
This is currently handled with the Function “Report Customer Data to Client’ within “A4 - Accounts and Settlement”.
The process is the current process
5.1.24 Client Settlement to Client
Process Map Reference: A44
Description: This process is the process by which clients are paid based on the value of their inpayments taken over
the branch counters as a result of customer transactions or based on agreed estimates or on client derived data. In
some cases this may be a net payment where the client products include outpayments e.g. National Savings and
Investments deposits and withdrawals are paid net each day.
For Girobank only values are paid on a Day A basis therefore paid prior to the transactional data being available.
There are several types of settlement to client based on individual client contract.
© Settlement on client data
© Settlement on transaction data
© Settlement on mixture of client and transaction data
© Settlement on estimates followed by corrections when transaction data is available
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 96 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
© Settlement based on AP report
Once value of payments are calculated they are checked at various stages throughout the process before the funds are
transferred to the client bank account. Payments are made via the banking system usually by BAC’s or CHAP's and
occasionally by cheque.
Differences between the settlement data and transaction data need to be resolved by determining which stream is
correct. This may entail making enquiries of the branch or the client from where the alternative source was derived.
Corrections will be made to the transaction data stream or the client data stream (and thereby settlement) if the cause
can be determined. If not this may result in a loss or a gain to the Business,
Triggers: Process triggered by the settlement terms within each client contract. Most clients are paid either daily or
weekly.
Frequency of operation: Daily
Volumes: 30 - 40 payments per day using BAC’s and CHAP’s transfer. Occasional cheque payment
Automation: Both automatic via client ledger and manual journal vouchers where payments are made on estimates and
subsequently corrected when transaction data is known
Locations: Centrally in the client settlements team in Chesterfield
Input requirements at the WP boundary
o Summarised transaction data from ledger
o — Client Summary report
© Client Settlement data
o Agreed estimated values
Output requirements at the WP boundary:
© — Ledger entry information
o Settlement payment to client
© Identified transaction errors
© Client ledger adjustments (feeds into ledger entry information)
° Client settlement forecasts
Time Constraints: Payments must be made by 12 noon or penalties may be invoked dependant on client contractual
terms
Fall back procedures;
5.12.5 Client Settlement from Client
Process Map Reference: A45
Description:
Receive payments from clients who prefund the value of outpayments to be made to customers made on their behalf
over the branch counters. For example Dept. of Work and Pensions and Asylum Seekers payments. Prefunding involves
using estimates in the first instance. The estimate is negotiated and agreed with the client based on historic trends,
current market and seasonal factors and results in PO Ltd sending the client a request for payment.
The request for payment is in the form of a statement of account, rather than a traditional sales invoice, containing the
following months agreed estimates.
The cashier function is informed of the value of expected payments and monitors whether the value has been received.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 97 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Differences between the settlement data and transaction data need to be resolved by determining which stream is
correct. This may entail making enquiries of the branch or the client from where the alternative source was derived.
Corrections will be made to the transaction data stream or the client data stream (and thereby settlement) if the cause
can be determined. If not this may result in a loss or a gain to the Business.
Triggers: Process triggered by the settlement terms within each client contract.
Frequency of operation: Daily
Volumes: 2-5 payments received per day
Automation: Both automatic via client ledger and manual journal vouchers where payments are made on estimates and
subsequently corrected when transaction data is known
Locations: Centrally in the client settlements team in Chesterfield
Input requirements at the WP boundary
© Bank Statements
o Summarised transaction data from ledgers
o Agreed estimated values
Output requirements at the WP boundary:
© Payments request to clients
© Updated ledger entry information
© Identified transaction errors
© — Client ledger adjustments (feeds into ledger entry information)
° Client settlement forecasts
Time Constraints: Payments must be received by 12 noon or penalties may be invoked dependant on client contractual
terms
Fall back procedures
5.1.2.6 Rota Checks (possible rem out tin)
Process Map Reference: A463
There are currently a number of cut-off reports that are produced each week as part of the Cash Account Rollover
process. These are passed together with the supporting evidence to Chesterfield where some are checked by the Rota
Checks. Currently the electronic values are derivable from the Cash Account report, however with the move to the
Branch Liability Statement, there will no longer be this information available centrally.
An alternative approach is to allow the supporting documents to be “Remmed Out” of the Branches periodically and the
Rem Out Transactions can be used to check the supporting documents if required.
[DATE \@ "dddd, db MMMM yyy" ]
Version 3.4
Page 98 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
To ensure that this mechanism works, it is also necessary to ensure that the amounts Remmed out match those of the
Transactions undertaken. This check could be made as part of the production of the Branch Liability Statement.
5.1.2.7 Investigate Transaction Data
Process Map Reference: A465
Description
The purpose of this process is to allow users to trace information back to the individual transaction component. This is
for a number of reasons eg. responding to a number of internal or external enquiries for various reasons.
Triggers
On a day-to-day basis, Transaction processing receives transaction enquiries from various sources that require them to
investigate transaction data in order to resolve the enquiries. These can be received from Clients, Customers, or
Branches and can be in relation to a variety of different products
Volumes
The main product areas that receive enquiries are Personal Banking, Automated Payments, TV Licencing and Cheques.
On average, Transaction processing deals with approximately 950 enquiries per week relating to these products. The
breakdown can be summarised as follows:
« — Automated Payments average 500 per week
¢ Personal banking average 200 per week
«TL Licensing average 150 per week
¢ Cheque average 100 per week
Transaction processing may also need to investigate transaction data when investigating exceptions that have been
created. This includes mismatches between transaction data and supporting documents and range check thresholds
that have been exceeded.
Currently, on average approximately 11,000 exceptions are created each week that require investigation. In order to
investigate these, Transaction Processing refer to either summary level transaction data by Branch, or if the query is
relating to a product where we capture customer specific details, (e.g. Automated Payments & Personal Banking
transactions where we capture customer reference number or account details), TP will use transaction level data to
investigate
Transaction Processing also acts as an enquiry point for the Human Resources Service Centre for queries relating to
Subpostmaster Remuneration. Summary transaction data by branch is used to investigate these queries.
On average, Transaction Processing receive approximately 10 to 15 Subpostmaster Remuneration queries (re-checks)
each month. The majority of these are received within the first few days following payment of monthly remuneration
They can be for multiple products across varying periods of time. For example a simple re-check may consist of a query
for a branch for one product for one week. Transaction Processing have also received queries across multiple products
going back across a period of 12 months.
Automation
The proposal is for Transaction Processing to use a combination of sources for investigation purposes in future. If
enquiries are relating to client level data then POL FS could be utilised. If enquiries are relating to transaction level data
then the Data Warehouse could be utilised.
5.1.2.8 Cheque verification
Process Map Reference: A466
Description :
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 99 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
This process provides a control to ensure that cheques used to pay for transactions do actually deliver funds for the full
value into the PO Ltd bank account. It is designed to remove the possibility that a customer's account with a client can
be regarded as paid when the customer's cheque is lost prior to processing. NB If after processing the cheque is
returned from the bank unpaid eg due to lack of funds, the issue will be identified in the cheque management process
within the Banking process, when the bank statements are received. It minimises the cash flow impact when PO Ltd has
settled the cash to the client but has not received value from the customer's cheque.
Cheques are sent by branches to EDS for processing at the end of each day. The details of the transactions to which the
cheques relate are recorded on the Horizon terminal, and the summarised total amount sent to EDS flows through at the
end of day processing. The ledger receives the total value of the batch whilst the detail of individual transactions stays
in Horizon. EDS process the cheques and advise TP of the value passed to the bank daily, via a spreadsheet electronic
format. This gives total values by branch by day, which can be matched against the total value of cheques sent by
branch by day in the ledger. Differences identified can then be resolved by office eg missing mail bags, missing cheques,
inaccurate values recorded, timing differences. This information is then passed to the investigate transaction data
process.
Triggers:
The branches despatch cheques to EDS daily ie. a six day week.
Frequency of operation: Once per despatch, usually daily but only 5 processing days. Saturday cheques are processed
with Fridays’ and the two day figure is sent as the fifth day.
Volumes :
Usually each office despatches once per day, the number of cheques per office varies and can be cyclical, dependent on
transaction eg more at month end for items such as licence renewal. Approx 280k per day but peaks at 560k for the two.
day figure. Equates to value of £110m.
Automation:
Once the information has been received from EDS comparison of the two branch daily totals ie that processed by EDS
against the ledger entry information of that sent to EDS by the branch , should require no intervention from the TP clerk.
The system should highlight those branch days which do not match.
Locations: The team in TP dealing with cheque processing from EDS is based in Chesterfield.
Input requirements at the WP boundary:
The information flows are Cheques processed, and ledger entry information
Output requirements at the WP boundary:
The process outputs summary level discrepancies by branch to the investigate transaction data process
Time Constraints:
Daily, to predict bank account movements and increase likelihood of successful resolution of investigation should
discrepancies occur.
Fall back procedures
If the electronic spreadsheet does not arrive the minimum fall back would be verbal or fax information from EDS of the
value. Individual office verification could be delayed until the input is received.
5.1.2.9 Debt recovery
Process Map Reference: A47
Description :
This process requires judgment to be made about the likelihood of existing action resulting in the receipt of cash to
recover the debt, and whether firmer action through a new debt recovery plan should be instigated. It is designed to
maintain momentum in the recovery of debt so that debtors pay their debts quickly with minimal additional
administration costs, so that the cash flow impact of the debt on PO Ltd is minimised.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 100 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
The debt recovery team in TP receive information on debts which have been assigned to agents, or customers, or
clients, and have not been cleared immediately when the initial notification “an identified transaction error” was sent.
The primary process is to assess action on the debt by reviewing the credit history of the debtor to determine total
outstanding liability, and previous payment records before deciding what additional action to take. NB It is assumed that
the need for total outstanding liability will result in the moving of debt currently residing on POL ESFS onto the new POL
FS system so that only one account for each debtor holds the total liability. This requires Operational Finance who
operate the debt recording and recovery function on POL ESFS on our behalf to instead perform the activity in POL FS.
This should be confirmed as part of detailed requirements analysis. This additional action could result in one of four
other processes being initiated and is described as a debt recovery plan which should be recorded to know which route
has been selected. The results of the debt recovery action are fed back to the update the debtor history. If the debt is
paid then ledger entry information about the cash receipt will be generated and the item will no longer be included in the
next assessment. If it is not, the cycle repeats itself and a different option would be selected. This could result in the debt
being re assigned to a different debtor through an identified transaction error e.g if a client identified error can be refuted
by the agent as correctly treated at the original transaction. Ultimately if not recoverable, ledger entry information to write
off the debt will be generated to clear the accounts, record a loss and remove from the debtors ledger.
The four options resulting from the assessment described in more detail are;
Simple recovery: used when there is no adverse information about previous repayment and when there is no other
outstanding amount or other amounts are low. A reminder telephone call is made by the debt recovery team in TP to
prompt repayment of cash using the usual method of settlement. The content of the call varies depending on the debtor.
For existing agents this uses a script, which repeats the instruction to repay via the till, for customers of TVL and DVLA
to pay via credit card or debit card or cheque, for clients to pay by amendments to settlement. For former sub-
postmasters it is usually by letter. Amendments to client settlement is also used to clear customer debts due to unpaid
(bounced) cheques for all products except TVL and DVLA. Here we know the customer account but not their personal
details so deduction is made from the client who then reinstates their own debt from the customer. For lost cheques
letters are sent to customers via the client, again because we have an account number but not their address. These
again request repeat payment.
Internal debt recovery: used for existing agents when simple recovery has failed. A second telephone call is made by
the debt recovery team in TP, using a script that informs the agent that recovery will be achieved via deduction from pay.
This can either be in the next month, or, if the retail line agree, it may be partially deferred for a period and paid through
a series of instalments over several months. Different terms are set as appropriate for different segments of the network
eg commercial and community. Some of these may require VAT or NI to be charged and accounted for too. If the debt is
for transaction related errors the contract permits deduction from pay without agreement. If the debt is for trading
transactions, by law, the agent's agreement must be obtained for the deduction to proceed.
External debt recovery: used particularly for trading transactions and when the agent is no longer under contract i.e.
former subpostmasters. TP instruct solicitors to take civil or criminal proceedings up to a certain cost ceiling, before
referring back for new instruction. In cases of fraud or robbery it can be from former employees too, and can take
several years for cases to be heard. Costs may be awarded, attachment of earings orders may be gained which would
generate further ledger entries but in general the information is used to assist in debt provisioning process. Eg tracing
agents could be used to identify whereabouts of debtors but would not be cost effective for debts under £500. The debt
could also be sold to factors who would then recover the debt. This would involve ledger entries depending on the terms
of the service provided e.g with or without recourse, and method of charging for fees or costs.
Provision for debt : used whenever 100% recovery is thought doubtful. Usually this is when simple and internal actions
have failed, and almost always in parallel when external debt recovery is chosen. Provision can be partial and
temporary, reassessed regularly or in litigation cases at half year and year end according to business rules. It is initially
formulated by the debt recovery team in TP but can be varied by subsequent judgment from the Finance team as part of
the probity process which ensures debts are legitimate assets to be recorded in the balance sheet. This results in entries
‘on the business trading ledger but the debt on the accounts receivable personal account remains. Ultimately a
permanent write off decision of the unrecoverable amount in the accounts receivable personal account would be made
by TP when debt recovery action would finally cease.
Triggers:
The accounts receivable ledger should identify items which are overdue compared against the assigned credit terms for
the various types of transaction. For an identified transaction error on line this could be “next day’, or day after normal
credit terms expire for trading debt. Debt recovery team in TP periodically review overdue reports and aged debtors
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 101 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
listings, this could be daily or within a week, and/or check on debtors credit history using diary triggers if a particular
action was agreed eg agent on holiday for two weeks, so chase as soon as return to work date is reached. If previous
action has not resulted in payment this triggers the process. Unfavourable advice from external debt recovery on the
progress of litigation would trigger the process as soon as it was received.
Frequency of operation:
Daily
Volumes:
Transaction related debts are currently measured by issued error notices not yet brought to account. There were 8723 of
these debts which had not been repaid three weeks after issue. There is no information on how these are spread
amongst the offices eg what proportion of agents do not have an error notice, and how many have more than one at any
point in time.
There are also approximately 1600 agents with debts relating to trading transactions, where debt is mainly just one
invoice. There is no information as to whether these are different agents to those with transaction related debts. These
debts currently reside on POL ESFS, (using SD - Supply & Distribution -functionality not AR - Accounts Receivable) and
are managed on behalf of POL by Operational Finance in Farnworth
Currently there are approximately 1200 former subpostmaster accounts, but with network reinvention programme this
could increase in the short term, and will vary dependent on rate of turnover in offices.
The number of customer debtors for each of TVL and Vehicle Excise unpaid cheques varies but is consistently in the
hundreds rather than thousands.
The number of customer debtors due to cheque losses varies eg a missing mail bag from a city centre could have the
cheques from a large number of offices, each having say 100 cheques.
The upper number of overdue debts would therefore be in the order of 20000 accounts; the lower say 13000.
Automation:
Once the debt recovery plan has been decided, the process to initiate recovery from payroll, or to make provision should
operate with minimum intervention from TP. Instructions to/advice received from extemal debt recovery parties would
probably be in letter format and required to be manually entered onto the credit history information
Locations:
To be performed by TP in Chesterfield, and also Leeds. It is not yet determined whether Operational Finance, who
currently recover trading transactions on behalf of TP through the ESFS ledger will continue to provide this service. They
are based in Farnworth. This should be confirmed as part of detailed requirements analysis.
Input requirements at the WP boundary:
Apart from the triggers the only information flows into the process are
the debt provisioning judgments both in the form of business rules and reporting judgments on asset recovery.
the judgments of the retail line on the terms to apply for internal debt recovery management. These are both in the form
of business rules for debt recovery but could be individual decisions in certain circumstances.
Output requirements at the WP boundary:
The process outputs the following information
Letters requesting payment to customers by name, customers identified only as account holders of clients, former sub
postmasters.
Letters instructing external parties to commence legal proceedings and the terms on which they are to pursue, including
time and cost limits.
Instructions to the personnel and payroll department to make deductions from pay through HRSAP.
Ledger entry information —Value of debt to be written off against relevant losses code, or if provision is reversed written
back as a gain against the original losses code. Value of debt to be removed from debtor account
Identified transaction error - message to agent through Horizon terminal to make adjustments as instructed to correct
the debt recovery item or transfer it to another agent/client account.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 102 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Time Constraints:
Results of debt recovery action should be fed daily by end of day so that agent credit history is as accurate as possible.
This would avoid unnecessary calls if payment was received, and quicken further action if it is not.
Fall back procedures:
In the case of system unavailability in the short term, or failure to update cash received on any particular day, recovery
could be pursued from previous days information. If system remained unavailable for a lengthy period, another method
of updating balances for recent cash receipts, and new debt recovery items would need to be devised.
5.1.2.10 Cash Centre Cash Management
Process Map Reference: A62
Description
Planning of cash remittances to branches
Changes to planned orders.
Dispatch of cash remittances to branches
Receipt of cash remittances from branches
Cash replenishment from BOE
Cash disposal to BOE
External customer cash deliveries
External customer cash collections
Cash withdrawals at cash centre
Cash Deposits at cash centre
Warehouse management of the stock of cash
Discrepancy processing
Trading statement
VV VV VVVVVVYYY
These processes describe the physical cash management area defined in the process maps as cash centre cash
management. Not all areas are fully relevant for the E2E programme but have been included for completeness. It is not
considered a requirement to expand the process box further at this point.
Planning of cash remittances to branches
This automated process is run nightly, after the receipt of the Cash on Hand file from Horizon. The process is carried out
for the majority of the 18,000 branches. Only a small number are not eligible to be flexibly planned. The function is
provided by the central SAPADS system.
The planning system produces two outputs. The first is a file of planned orders, which contains the details of the planned
remittances that will be dispatched to branches. This is in the form of a text file, which is transmitted to FS, for onward
transmission to the branches. The second is a table of orders, which require picking, and packing, this is the actual
remittance, which is processed and dispatched to the branch.
The receipt process and transmission of the planned order file must be completed for the branches to see the planned
orders by 8:00 on the day before the planned rem. This gives time for the branch to request changes.
The Cash centres hold a copy of the standard remittance for each branch. This is used in the case of a total systems
failure.
Changes to planned orders.
The POL branch realising that the planned order does not meet their requirements triggers this process. The review of
planned orders is carried out at the branch whenever they receive notification of a planned order e.g. at some branches
this is daily. On average 7,000 changes are received per week. This process consists of a manual review and a phone
call and results in the system being manually updated. The process is carried out either in local inventory teams, Cash
Centres, or the help desk facility in Hull (soon to be moved to Newcastle). The information used in the process is as
follows: FAD code, delivery date and details of the amended planned order. The branch history is also utilised in the
decision making process.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 103 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
On saving the change a success message will be received. The document number created is recorded for reference.
The only time constraint will be the cut off time employed at the cash centre to ensure that there is sufficient time for the
order to be made up and despatched to ensure delivery is made on time. This varies from cash centre to cash centre,
and it will also vary within a cash centre. There are contingency programmes available for any system failures.
Dispatch of cash remittances to branches
This is a daily process, which is triggered by the printing of a bulk-picking list. This contains the details of all the orders
(rems) that are required for that day. These are picked and packed. The packing details are entered on the SAPADS
system. This process is carried out throughout the day. There are up to 8,000 rems to be processed each day. The
production of paper work is requested manually but the process is supported by the SAPADS system. This process is
carried out at each of the cash centres.
The process must be completed in time for the driver to commence the route. Fallback is to use the standard rem, which
is held as a hard copy at each of the cash centres.
At the point of packing it is occasionally necessary to split the packing between pouches. In this case it is necessary to
create a manual contents slip for each of the pouches. This is because the picking detail, which is printed on an advice
note, does not record the information down to individual pouch level. The advice note will be included in the last pouch
packed but will be stapled to the contents slip. Please note that the contents slip is only for use in the case of systems
failure.
Receipt of cash remittances from branches
This process is prompted by presence of a pouch for collection. Once received at the cash centre it will be scanned
which records the fact that the pouch has been received at the cash centre. The next step is to open and count the
contents. At this step it is scanned again and the system populated with the value of the pouch. The fall back at this
stage is to simply count the content. This process is carried out throughout the day. The majority of pouches received
are processed within one working day.
Cash Replenishment from BOE
This process is triggered by the forecast received from CFF (cash flow forecasting). The additional cash is requested 10-
14 days in advance. CFF is run weekly to forecast the cash requirements. The process is manual but utilises the stock
control functionality of SAPADS. The process is carried out centrally on behalf of each cash centre and the delivery is
direct to the affected cash centre. The delivery is by agreed carrier. On delivery the load is subject to authorisation and
checking and is booked into SAPADS stock.
Cash Disposal to BOE
This process is the reverse of the above, and is again triggered by CFF. The collection is again via agreed carrier and
utilises standard SAPADS functionality.
External customer cash deliveries
The receipt of the delivery into the cash centre triggers the process. This process operates very frequently (details of
frequency and volumes requested). The process operates in all cash centres. In the main, a pouch number, customer
details, and breakdown of the delivery, however there are variations within the process depending upon where it is
performed, and what is actually received. The output requirements vary, depending on where the process is performed
and what is actually received. Cut off times are used to ensure that same day processing is achieved. Each cash centre
will operate differently. There is a contingency programme available at all sites.
External customer cash collections
The process is initiated by a telephone call, fax or set order from the customer. The frequency of this will vary from cash
centre to cash centre but the vast majority will take place in coin centres. Although SAPADS is used to record the details
it is largely a manual process mainly operated at coin centres, but will also operate in cash centres. A clerk will input the
customer number, delivery date and order details. A sales order number is generated, which the input clerk records. The
orders must be received in time to meet the variety of cut off times utilised to ensure that it is delivered on time. Manual
contingency processes will be employed if necessary.
Cash withdrawals at cash centre
This process is only available for existing customers e.g. Giro customers. The trigger can be a phone request, a fax, or a
‘standing order. This happens throughout the week at each cash centre. The process is supported by standard SAP
functionality. The standard SAP system failure fallback procedures apply.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 104 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Cash Deposits at cash centre
This is the reverse of the above process and largely supports Giro change customers who are depositing cash into their
Giro A/C via the cash centres.
Warehouse management of the stock of cash
This contains all the normal warehouse management activities of stock movement and processing (including checking
processes). It is carried out by all the cash centres through out the working day (24hours). It should be noted that remote
coin stores (held at a dept) are considered to be remote stores and part of the parent cash centre. All transactions
however are communicated to the cash centre where they are entered onto the system.
Discrepancy processing
The reporting of Rem discrepancies is a manual process. This is an “as required” process that is carried out within 24
hours of receipt of a pouch at a branch. Discrepancies for cash centre receipts are raised “usually” within one working
day after receipt. The details are recorded manually on SAPADS. Suspense items are cleared, as issues are resolved.
The information is recorded manually within ESFS.
Trading Statement
The statement is an internal document for the cash centre only and will not be forwarded to an independent area unless
security and audit determine that that is essential. The actual data within the trading statement will have already
populated the ledgers by the daily interface outlined above and therefore no data from the statement will populate the
interface.
The trading statement will encompass a snapshot of cash and stock and also any current discrepancies or suspense
items. It will also enable the cash centre to view what business has been transacted over the last period. The cash
centre manager will be required to “sign off’ the trading statement as a true and accurate position at specified points in
time.
It is possible that the SAP/ADS system can produce the level of information required which would satisfy both control
issues and security and audit requirements.
There is workshop being planned to establish the actual requirements, and the SAP/ADS capability, which will feed into
the detailed requirements phase of end to end.
Triggers: There are numerous triggers for the above processes.
Frequency of operation: Daily
Volumes: Not relevant in this context
Automation: In the main the processes are automated within SAP/ADS however there are also manual flows such as
JV's and phone calls.
Input requirements at the WP boundary:
Pouch delivery confirmation
Pouch collection confirmation
Cash receipts
Output requirements at the WP boundary:
Cash centre transaction data
Cash centre financial transaction data
Pouch details (electronic)
Cash despatches
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
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 105 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Fallback procedures:
5.1.2.1 Produce POL Ledger
Process Map Reference: A48
Description:
This process encompasses the production of the POL FS P&L and BS, which combines the following information:
» Client Ledger
© Open items relating to outstanding client debtors and creditors
co — Aged debts and credits
> Personal Agent Ledger
© Open items relating to Agent Debt
o Aged debts
> Branch Ledger
o Cash balances by Branch
o Summarised Branch transactions
» Cash and Bank Ledger
Cash and near cash balances
» Business Trading Ledger
© This holds business transactions that do not relate to the client but do not include the fees relating
to client ‘sales’
> Borrowings and Investments
This holds the balances for Borrowings and Investments accounts
© This should be broken down by Business and Client
>» Stock Ledger
© Financial stock values in the balance sheet representing the value of purchased stock represented
in the financial ledger
The balances relating to these ‘ledgers’ go to make up the BS and P&L for POL to feed into the ES-FS accounts. These
are driven by the accounts specified in the release 2 skeleton chart of accounts, the detail of which will need to be
established during detailed analysis.
Triggers: There is no trigger as such, the accounts will be produced by regular reviews and a final monthly review
before the month end close.
Frequency of operation: Monthly
Volumes: N/A
Automation: Manual process to review and produce the final reporting.
Locations: Various - Chesterfield and London
Input requirements at the WP boundary: This relies on information flowing into the ledgers from the Horizon and SAP
ADS interfaces plus:
» — Trading Transactions
» BFPO accounts
» Discrepancies
» — Branch closure notices
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 106 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
Bank statements
Cheques processed
Streamline settlements
Investments and Borrowings
Other Stock information (TBC)
VY VYV
Output requirements at the WP boundary: Reports, which may be required.
balances at month end.
Time Constraints: None.
Fall back procedures: Manual process. No fallback.
[DATE \@ "dddd, db MMMM yyy" ]
© Post Office™ 2003
Version 3.4
Feed to ES-FS of closing ledger
Page 107 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.13. Informatien Flews — Release 1
5.1.3.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
5.1.3.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:
o Cash at branch summarised from the end of day cumulative transactions
© Cheques at branch showed on a separate line
© 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:
© 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 -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
Tequired 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
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 108 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
» Cash in transit transactions sourced from the LFS messages created in Branches and in the Cash Centres.
This will be summarised within the SAP/ADS interface.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 journalied 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 - to be confirmed how this is captured. (TBC)
o 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.
» — ATMinformation
© 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
o 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.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 109 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.3.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:
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 handling 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
(Finance Change). 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 branch 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.
5.1.34 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
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 110 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
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
8)
How many instances of the interface are likely to exist: We would expect this to be a single communication from
Frequency of use: Daily ( 5 days)
Data volumes: Unknown, this to be confirmed through detailed requirements analysis.
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
tisk.
5.1.3.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.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 111 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.3.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
» Generated 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:
Data volumes:
Time Constraints:
Fall Back Procedures:
Security risks:
Further analysis of the process required before alll risks are identified and a solution agreed.
5.1.3.7 Flow - Pouch Collection Confirmation
Description:
This remains the same as is from the Branch to the Cash Centre.
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 ttem ID
o Qty
o Value etc.
VYVYVY
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.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 112 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
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:
5.1.3.8 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
vVVVY
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.
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 safely of the delivery. All messages are
encrypted and the link between data centre and SAP ADS is encrypted.
5.1.3.9 Flow - Pouch Details
Description:
Contains actual delivery details which are picked and packed and sent to the Branch.
Pouch details - Electronic notification of the actual POL delivery details (per pouch)
Contains details:
» Value by denomination
» By pouch - unique barcode number.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 113 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
» — Branch ID
» Cash Centre ID
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
5.1.3.10 Flow - Reference Data to Branch Transactions and Management and
Transaction Management
Description:
This will remain broadly the same in the initial stages. However changes will be made in line with removing the cash
account at a later stage and ledger mappings will be required to allow for summarisation of data.
This is the main reference data required to run the Horizon system. Additionally there is other Type B data interfaced to
Horizon.
This interface contains:
» File Header
File Trailer
Change Request Header
Organisational Unit Type
Organisational Unit History
Organisational Structure Type
Organisational Structure
Org Unit Calendar
Branch Default Opening Times
Client Account
Item Type
Item History
Item Structure Type
Item Structure
Branch and Non-core Items
‘AP Token Type
Automated Payment Token
AP Token Element Type
AP Token Element
Check Digit Method
Item Additional Field
Organisation Financial Year
Accounting Day
[DATE \@ "dddd, db MMMM yyy" ]
VV VVVVVVVVVVVVVVVVVYY
v
Version 3.4
Page 114 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038870
POL00038870
‘Accounting & Cash Management
Programme
‘AcoCM-PCD
Accounting Period
Accounting Week
Accounting Node
Organisational Unit
Item
VAT Code
Look up Type
Look up Value
Transaction Mode
Item Transaction Mode
Cash Account
Cash Account Table
Cash Account Sub Table
Cash Account Table Line
Cash Account Code
Cash Account Line Code
Item Transaction Mode Code
VV VVVVVVVYVYVVVVYY
New Items
> Ledger Mappings
Nature of interface: Automated as per RDP/AIS/014 with minor amendment
How many instances of the interface are likely to exist:
Frequency of use:
Data volumes:
Time Constraints:
Fall Back Procedures:
Security risks:
[DATE \@ "dddd, db MMMM yyy" ]
© Post Office™ 2003
Version 3.4
Page 115 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.3.1 Flow - Reference Data to Physical Cash Management
Description:
The data will remains broadly the same as is with the addition of ledger mappings. However, this needs to become a
fully automated interface as opposed to the current situation.
This is the reference data required to run the SAPADS system
This interface contains:
> File Header
File Trailer
Organisational Unit Type
Organisational Unit History
Organisational Structure Type
Organisational Structure
Item Type
Item History
Item Structure Type
Item Structure
Transaction Mode
Item Transaction Mode
Branch and Non Core Items
Organisation Financial Year
Organisation Unit Calendar
VVVVVVVVVYVVVY
New Items
> Cash Centre Ledger Mappings
Nature of interface: Needs to be fully automated as per the content of RDP/AIS/009 with minor amendments.
How many instances of the interface are likely to exist: One refreshed interfaced for each group of data changes
within a given time period
Frequency of use
Data volumes:
Time Constraints:
Fall Back Procedures:
Security risks:
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 116 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.3.12 Flow - Branch Transactions and Management and Transaction Management
to MIS
Description:
This flow will be all transactions and components of transactions captured at the branch —_ For Release 1 this will
replicate the current feed to OpTIP. But thereafter the expectation is that there will be additional data required which is
not currently on the OpTIP interface but which is captured at the branch. Examples of this are:
» Banking
> Bureau de Change
> Mails
This data is required so that the data warehouse can become the one logical place where MI is derived from.
This interface contains:
Session Id
v
Transaction Id
Product Id
Sale value
vvv
Vv
Sale Quantity
Additional data items
Nature of interface: Automated as per with additional data items added
How many instances of the interface are likely to exist:
Frequency of use:
Data volumes:
Time Constraints.
Fall Back Procedures:
Security risks:
[DATE \@ “dddd, dd MMMM yyyy" ]
Version 3.4
Page 117 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.3.13 Flow - Reference Data to Accounts
Description:
This is a new flow of data of data to provide the SAP accounting system with reference data that is required by both the
accounting system and other systems. Some reference data which is accounts specific will be sourced within the SAP
domain eg. Chart of Accounts
This interface should contain the following entities but will require more work to finalise the exact nature of this interface.
Organisational Unit Type
Organisational Unit History
Organisational Structure Type
Organisational Structure
‘Agent Code
Agent Contract Type
Org Unit Calendar
Client Account
Client Type
Item Type
Item History
Item Structure Type
Item Structure
Bank Type
Bank Account
VVVVVVVVVYVVYVYVYVVY
Nature of interface: Automated interface sourced from Reference Data processes as and when requiredHow many
instances of the interface are likely to exist: One per day.
Frequency of use: Daily overnight.
Data volumes: Unknown at present. To be determined in detailed requirements analysis.
Time Constraints: The timings need to be driven by the data warehouse load schedules.
Fall Back Procedures: There is no fallback. Resilience needs to be built into the Reference Data system as this is
business critical,
Security risks:
None
5.13.14 Flow - Accounts to Reference Data
Description:
It is unclear whether any SAP specific reference data is required by other systems. The assumption is that if data is
required by more than one system then this should be held in the reference data system. Only parameters specific to a
particular application should be held in that application.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 118 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
The one exception to this MAY be the Chart of Accounts. As yet there is no requirement for this to be accessed
elsewhere. However, this flow leaves the possibility open for an extract of the Chart of Accounts to be lodged in
Reference Data. There is no intention to hold Chart of Accounts anywhere other than SAP.
SIA Information Flews —Roleasos 223
5.1.4.1 Flow - Central Reporting from Branch
Transaction Data
Description: Transaction data is a primary data flow detailing the interactions with a customer and is used
comprehensively throughout the process
The main attributes for each Transaction are:
= Session Id
= Transaction Id
There is currently a potential issue here as to what is a Transaction. The Desktop
currently considers the sale of a Postal Order and its associated fee as a single
Transaction (with a single Transaction ID) even though it gives rise to two separate
Transaction records for separate products. There are a number of additional
complexities in the current system to get around this.
= Product Id
= Sale value
= Sale Quantity
Some transactions also have additional data that identifies the Customer (eg AP, Banking and Debit Card Transactions)
Nature of interface: A file of Transactions passed from Horizon to MIS. Initially it will be based on the current OpTip
interface but may be enhanced as more detailed requirements are captured.
How many instances of the interface are likely to exist: One
Frequency of use: A single file of Transactions each day
Data volumes: Current peak is 20Million per day
Time Constraints: Current requirement is to deliver the data by 3am the following day.
Fall Back Procedures: None.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 119 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Security risks: None.
Cheque and Voucher Values
This is a flow out of Function “Cheques and Voucher Verification and Despatch” within A61 “Branch Cash Management’.
It is subsequently used by “Create / Verify Branch Liability Statement” and “Summarise Transaction Data’ within A4
“Accounts and Settlement’
Stock Transaction Information
This is a flow out of Function “Central Stock Management & Replenishment” within A3 “Stock Management’.
It is subsequently used by “Capture and Validate Transaction Data” and “Customer Enquiries” within A2 “Sales” and also
by “Create / Verify Branch Liability Statement” and “Summarise Transaction Data’ within A4 “Accounts and Settlement’.
This is a sub-flow of “Product Change Info” coming from “Reference Data Management’. It is subsequently used by
“Create / Verify Branch Liability Statement" and “Summarise Transaction Data” within A4 “Accounts and Settlement”.
Stock Revaluation result in transactions which will then look like normal Transaction Data
Cash Adjustments
Cash Adjustments result in transactions which will then look like normal Transaction Data
This is a flow out of Function “Branch Cash Management’ within A6 “Cash Management
It is subsequently used by “Create / Verify Branch Liability Statement’ and “Summarise Transaction Data” within A4
“Accounts and Settlement’.
Stock Adjustments
Stock Adjustments result in transactions which will then look like normal Transaction Data
This is a flow out of Function “Branch Stock Management" within A3 “Stock Management’.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 120 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
It is subsequently used by “Create / Verify Branch Liability Statement’ and “Summarise Transaction Data” within A4
“Accounts and Settlement’.
This is part of Release 1 and should be unchanged at Release 2
5.1.4.2 Flow - Customer Data to Client
Overall Description:
This flow comprises of transaction data plus a summarised report of that data informing the client of business
undertaken at the counter
Transaction Data
Description: Transaction data is a primary data flow detailing the interactions with a customer and is used
comprehensively throughout the process
The main attributes for each Transaction are:
= Session Id
= Transaction Id
There is currently a potential issue here as to what is a Transaction. The Desktop
currently considers the sale of a Postal Order and its associated fee as a single
Transaction (with a single Transaction ID) even though it gives rise to two separate
Transaction records for separate products. There are a number of additional
complexities in the current system to get around this.
= Product Id
a Sale value
a Sale Quantity
Some transactions also have additional data that identifies the Customer (eg AP, Banking and Debit Card Transactions).
Nature of interface: A file of transactions passed to individual clients on a daily basis
How many instances of the interface are likely to exist: One per client
Frequency of use: A single file of Transactions each day
Data volumes: Current peek is 20Milion per day
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 121 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Time Constraints: Current requirement is to deliver the data to client specifications
Fall Back Procedures: None.
Security risks: None.
Client Summary Report
This is a flow from “Report Customer Data to Client’ within A4 “Accounts and Settlement” and is used by “Client
Settlement to Client’ within A4 “Accounts and Settlement’
Description: The client summary report is currently a daily interface into OpTip which reports the value and volume of
the AP client data.
In order for Client Settlements and the client to have a consistent view of the settlement required each day the
information which is currently sent to OpTip must be sent to the client settlements team daily,
The current flow consists of the following information:
= Record Type Identifier
= Client Identifier Code
= Version Number of Client Identifier
= Item Id
a Version Number of Item
= Client Trading Date
= Total Number of Transactions
= Total Value of Transactions
This data must not be ledgered as the transaction management system will feed financial data daily therefore if this data
is ledgered there would be duplicate values within the financial ledger system.
Further investigation is required during the detailed requirements analysis to decide on the most suitable medium
however it is assumed that this will be via reporting direct to Client Settlements team.
How many instances of the interface are likely to exist: There is currently a record for each Client Product for each
Trading Day for which Transactions were carried out for the client.
The report sent on Sunday 13® July comprised 1977 records covering 812 products for 485 separate clients.
Frequency of use: Daily
Data volumes: Each record is currently 71 bytes. The file for Sunday 13" July comprised 1977 records and was 142Kb.
Time Constraints: Reports must be available daily at start of day - 07.30 at the latest
Fall Back Procedures: None
Security risks: None
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 122 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.4.3 Flow - Automated Reconciliation
Overall Description:
This flow comprises of transaction data plus authorisations to effect an automated reconciliation where required
Transaction Data
Description Transaction data is a primary data flow detailing the interactions with a customer and is used
comprehensively throughout the process.
The main attributes for each Transaction are’
a Session Id
= Transaction Id
There is currently a potential issue here as to what is a Transaction. The Desktop
currently considers the sale of a Postal Order and its associated fee as a single
Transaction (with a single Transaction ID) even though it gives rise to two separate
Transaction records for separate products. There are a number of additional
complexities in the current system to get around this.
= Product Id
a Sale value
= Sale Quantity
Some transactions also have additional data that identifies the Customer (eg AP, Banking and Debit Card Transactions)
Nature of interface: There is a requirement to match transactions against authorisations
How many instances of the interface are likely to exist: One
Frequency of use: A single file of Transactions each day
Data volumes: Current peek is 20Million per day
Time Constraints: Current requirement is to deliver the data by 3am the following day.
Fall Back Procedures: None.
Security risks: None.
This is an external flow into Function “Automated Reconciliation” within A46 “Verification”.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 123 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
However a flow with the same name is also used by “Authorise Transaction” and “Client Authorisation” within A2 “Sales”.
NB I don't believe that these are really the same flow.
The flow into “Automated Reconciliation” represents the information flows into the DRS from the NBE, Streamline or e-
Pay in order to perform reconciliation (NB each is different). They don't need to change as a result of E2E and so don't
need to be described further here.
5.1.44 Flow - Client Settlement Data
Description: This flow carries detail of the settlement to be paid to clients. This is solely for clients whom PO Ltd settle
with on the basis of their information rather than the transaction data via Horizon. The flow will include volume and value
of data by FAD code. There are approx 10 clients paid on client settlement data.
This flow will not update the ledgers.
Nature of interface: Manual either via e-mail, report or floppy disk. There are both daily and weekly interfaces.
How many instances of the interface are likely to exist: Up to 20 per week
Frequency of use: Daily
Data volumes: Up to 17,500 lines per interface
Time Constraints: Timings will vary according to individual client contract
Fall Back Procedures: If an interface does not arrive usually telephone contact is made.
Security risks: None
5.1.4.5 Flow: Identified transaction error
Description:
This flow carries information about transaction errors which have resulted from investigations and verifications. And will
also include transaction exceptions identified as a result of range check defined thresholds being
exceeded. The current assumption is that these errors reside in a suspense account which can be identified by cost
centre to a branch. An identified transaction error is therefore not the posting of a data discrepancy but relates to a
discrepancy which has been researched to understand why it occurred, how it can be corrected and carries the
necessary information to prompt actions to undertake correction. Identified transaction errors can flow from any one of
the following processes as seen on the accounts and settlement process model A4:
Verification - where differences have been found between individual transaction streams and summary totals
and the correction must be made in Horizon to update the branch liability statement and in the ledger
Client settlement from and to client - where differences can be found between PO Ltd data and client data
and the correction must be made in Horizon to update the branch liability statement and in the ledger
Debt recovery - where debt recovery items initially assigned to one debtor e.g an agent may be disproved
and need further verification or assigning to another party e.g a client, and the correction must be made in
Horizon to update the branch liability statement and in the ledger
Declaration adjustment - where a transaction has been logged in the financials as a result of a declared
difference in the branch and the resulting investigation requires an action in the branch to adjust the
transaction,
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 124 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Where an adjustment is needed to the ledgers, which does not require an adjustment to the branch liability and should
not result in a transaction flow to the client, then this may utilise a mechanism other than Horizon, and so avoid agent
input. Currently this is done by central adjustment in TP. However the need to ensure the client ledger and settlement
flows are adjusted and the MIS data for reporting value on client contracts etc is correct must be addressed in terms of
accuracy requirements and the cost/ benefit of the alternative mechanism and process. ' this also should include
the Subpostmaster remuneration process. This should be done as part of detailed requirements analysis.
The identified transaction errors flow to the process “create/verify branch liability statement.”
This interface is provided to enable the various functions above in the accounts system to request that a Postmaster
carries out a “correcting transaction” to resolve some earlier error / discrepancy. It is the equivalent of the current Error
Notice. The flow must be in a form so that the time spent by the agent to understand, decide on action and if accepted,
complete the error type processing on the Horizon till, is a minimum. The flow should minimise the possibility of
incorrect processing eg pressing the wrong buttons, or entering the wrong value, or not updating the theoretical cash
figure.
Currently for most clients it is not possible to settle items which have not been made good by the agent. If the agent is
able to accept the flow so making a transaction entry for a client, but does not make the subsequent cash or suspense
adjustment, this will result in cash flow implications for PO Ltd. Either this situation should be avoided so that the full
entries must be made or none at all, or to maintain current practice the item could be flagged so that it is not settled with
the client until debt recovery is made, or PO Ltd must manage the cash flow implications through other means eg debt
recovery.
The quantification of the impact on cash flow vs the cost of preventing the change in current practice must be carried out
as part of the detailed requirements analysis.
If the agent does not understand or decides not to accept the flow then the client data remains unamended and the
debit/credit entry is not on the client ledgers, nor is the debt from/due to the agent recorded. The current assumption is
that it remains as a suspense account entry recorded against the branch cost centre. This requires some functionality for
the exception team in TP to manage the age of suspense account entries and pursue if they are not cleared. E.g The
ability to report age of entries in suspense.
If suspense account items are then deemed debt recovery items they must be manually removed from suspense and
posted against the agents account in the accounts receivable ledger in order for debt recovery to be initiated.
The alternative to the current assumption is that discrepancies could be ledgered in the agents account automatically but
this would require increased reference data to map branch to agent, may result in unused agents accounts for those
agents who do not defer payment, and more complex mapping of accepted adjustment transactions. It would reduce the
need for manual posting of unpaid items to the agent's ledger.
The cost / benefits of the current assumption vs the use of the agent's ledger should be undertaken as part of detailed
requirements analysis, and may depend on expected volumes of disputed discrepancies.
The flow consists of the following information:
@ Branch
® Date of original transaction
Note that Identified Transaction Errors can only be routed to a Branch. if the Error is the
responsibility of an Agent who is no longer at the Branch (eg a former sub postmaster, or one
suspended), a separate mechanism is required to correct the ledgers and clear the error by
matching the identifier (including Branch if needed by client) without affecting the transactions and
subsequent branch liability statement of the new agent currently at the Branch. Errors requiring
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 125 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
cash collection from the former agent must have a separate mechanism to amend the former
agent's account in debt recovery to pursue the debt with the Agent wherever (s)he may be. The
date of original transaction is required in order to run against the reference data to determine
whether the agent is still in post and so determine which mechanism must be invoked..NB This
mechanism may also need to be invoked if for some reason the agent refuses to accept and action
the identified transaction error, in order to correct the ledgers and set up the debt recovery item
without his agreement.
= Error Type - This needs to map onto a Product or Button against which the Transaction is to be
recorded so as to subsequently affect the correct adjustment for the client ledger and the POL ledger.
= Adjustment value for each error type eg One orange phonecard £10, should have been two £5 02
phonecards. NB adjustment values could be either £value only, value and volume as above, or volume
only, but will all require adjustment.
Subsequent value of funding adjustment to correct the cash position. This should be a prompt to make a
physical cash movement (either put into the till or removed), or to check the suspense account and
match to a previous entry therein and remove it. NB if the agent does not make the subsequent funding
adjustment then this will result in the accounting package identifying a cash shortage at the next cash
declaration,
= Matching Identifier - This is an identifier that is to be associated with the Transaction to allow it to be
matched against the original error / discrepancy when it is processed in POL FS.
Nature of interface: This will be a daily file of Transactions generated from POL FS to be processed by Horizon and
distributed to the appropriate Branches. There must be a daily report of transactions not accepted by the branches by
the end of day. This should include both those transactions which were not received by the branch and those received
but not actioned/accepted in full. Dependent on design it could come either from POL FS eg report from suspense
account or TMS and costs vs benefits should be included in the detailed analysis of options.
How many instances of the interface are likely to exist: There will be a single Interface.
Frequency of use: Daily.
Data volumes: It is very difficult to quantify the data volumes for the new flow as many result from Cash account errors
which are paper discrepancies but will not require correction in the ledgers. Currently estimates of errors produced in an
average week are 20000 representing approx £90m value per week. These are expected to reduce, however the
number of issued errors remaining outstanding after 3 weeks (see debt recovery flow) is estimated at approx 9000 so it
is unlikely that the volume of identified transaction errors would fall below 10000 per week.
Further analysis of volumes including maximum peaks eg when new products are introduced, will be necessary as part
of the detailed requirements analysis. This could assist in determining whether the assumption of suspense account or
the alternative agent's ledger is most cost effective.
Time Constraints: Overnight Delivery. Although the time taken for investigation may result in delay in formulating the
identified transaction error, investigations are prioritised by value and seriousness. Once they are complete it is crucial
that delivery of the message is quick to avoid impacting on PO Ltd cash flow and to correct the client balances
Fall Back Procedures: None.
Security risks: None.
5.1.4.6 Flow: Debtrecovery plan and Results of Debt recovery action
Including debt recovery amounts through payroll
Description:
[DATE \@ "dddd, db MMMM yyy" ]
Version 3.4
Page 126 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
These flows both carry information about the decision resulting from the assess action on debt process to the various
options of the Debt recovery process. They carry instructions to a person as to action to take - often self contained in the
thought process of the clerk in TP operating the debt recovery process, but can be by letter to external legal advisors, or
by phone to agents. The plan of what to do, and result of action is recorded on the accounts receivable ledger to update
the credit history file of the relevant debtor with actions taken.
Nature of interface:
Not automatic interface from SAP. No new accounting entries are made. This is a documenting action: recording text
only into the Accounts Receivable module of SAP and instructing action through one of the following media:
Verbal - clerk personally makes simple reminder call to debtor
- clerk telephones retail line to initiate process of agreeing terms of repayment in instalments or defer
- clerk discusses with team leader the application of rules and initiates process of provisioning
Letter - clerk writes to debtor or external legal advisor to recover cash
-clerk writes to debtor confirming terms of repayment by instalments
Amend credit terms in AR ledger — if new terms are agreed eg by instalments through HRSAP the AR ledger could
record these as reference data to assist in aging and re classifying debt so that it no longer appears overdue if
repayment terms are met in future.
Spreadsheet — clerk records amounts per repayment and number of instalments with commencement date to provide an
upload into HRSAP, and sends to Operational Finance in Salford. If this could be done as a download report from SAP
AR of the amendments made to credit terms it would avoid miskeying errors: if not then keying the same information
twice would be the alternative.
How many instances of the interface are likely to exist:
Once per repetition of the “assess action on debt” process for each of plan and record result of action.
Frequency of use:
Ability to record an update to credit history as a result of decision should be available at any time of working day.
Data volumes:
As per debt recovery items - say 13000 to 20,000 accounts decisions to be recorded when taken.
Time Constraints.
Real time so as to avoid other clerks re assessing action without up to date knowledge.
Fall Back Procedures:
None long term. Short term, paper records could be used but would need to be input to update credit history as soon as
system was restored.
Security risks:
Personal information subject to Data Protection Act.
5.1.4.7 Flow: Agent Client Credit History information
Description:
This flow carries information to the Debt recovery process using functionality within the accounts receivable ledger. It
comprises the previous history of debt with the relevant debtor to use as background information when assessing the
particular debt recovery item which is now live in the process. For example, are there other debt recovery items still
outstanding currently being paid through extended terms? When was the last incidence of debt and was it cleared
promptly and in full, or did it take several repetitions of recovery and escalations of action to receive the cash? Was cash
received from deduction via HRSAP? Etc.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 127 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
For clients it will be in respect of transactions in dispute within the client settlement balances in the accounts receivable
or payable ledger.
Nature of interface:
This is a look up/ reference only. Visual either from screen of Accounts Receivable module of SAP, or from report out of
AR module. No entries are made.
How many instances of the interface are likely to exist:
Visual references should be available at any time of working day.
Frequency of use:
Once per debt recovery item in the “assess action on debt” process
Data volumes:
As per debt recovery items — say 13000 to 20,000 accounts available for view as required.
Time Constraints:
None
Fall Back Procedures:
None
Security risks:
Personal information subject to Data Protection Act.
5.1.48 Flow - Cash Centre Financial Transaction Data to Accounts
Description:
This flow carries information of the relevant transactions or summaries to POL FS via TMS from the Cash Centres. Any
summarisation that is required will be carried out within SAP/ADS or within the interface routine.
Movements at cash centres relating to the ‘Cash Ledger’ accounts specified in appendix A.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
© Extemal customers deposits. Currently held as an overall total in the SAPIADS F module. The overall total will
need to be broken down to client level by transaction for settlement purposes. If his is deemed necessary this
could be established by “driling down’ into the movement types within the MM module in order to capture the
client information by transaction.
‘© External customers withdrawals such as change giving. Currently held as an overall total in the SAP/ADS FI
balance sheet account, and not broken down by individual client account. Further analysis needs to be
undertaken as to whether each debtor needs to be identified separately within POL FS. If this is deemed
necessary this could be established by ‘drilling down” into the movement types within the MM module in order
to capture the client information by transaction.
©All other financial transactions, summarised by POL FS account, relating to adjustments and non-client
transactions and any other transactions which make up the financial postings in SAP ADS for each day.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 128 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
The content of the interface depends on the reporting requirement from the POL FS.
The requirement for Release 1 of the programme is for the cash and pouch information to feed into the POL FS. The
requirement for Release 2 is for the client related data to feed into the POL FS.
If the full interface can be addressed in release 1 for both sets of requirements this would be the preferred way forward.
The client related data would not be utilised until release 2 but by creating the full interface at release 1 there would be
cost savings.
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 overnight. Must be available by 07:00 following the day which the transactions relate to.
Data volumes: Total volumes of transactions for cash pouches are approx 10,000 per day.
Client based transactions will be summarised due to the volume of information approx 200,000 lines per day.
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,
5.1.4.9 Flow -Ledger Entry Information Release 2
Description: This flow carries information of the transactions processed in Horizon and SAP ADS and passed through
TMS into the POL FS. Some of these transactions are summarised and some are not. For release 2 the transactions
required to be processed are as follows:
> Summarised Information
© Cash transactions sourced from the Branches via Horizon The information required in this flow
includes:
= Transactions at branch summarised from the end of day cumulative transactions
including client information and other transactions mapped to the financials as
determined by the Chart of Accounts defined in appendix A The branch transactions are
summarised by branch by day by client (dependent on the product summarisation
requirements to the client ledger). Also described below under client ledger information.
"= Cheques at branch showed on a separate line, summarised by value
= — 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
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 129 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
°
what information is available throughout the cheque handling process (the process in
under development)
= Commemorative coins are treated as stock when reported from Hemel or Branches.
They are treated as Cash when reported from the Cash Centres. The value for
commemorative coins will be included in the summarised cash value.
Cash Centre Transactions summarised by day by account and passed to the accounts at the
appropriate level of detail:
External customers deposits. Currently held as an overall total in the SAP/ADS FI
module. The overall total will need to be broken down to client level by transaction for
settlement purposes. If this is deemed necessary this could be established by “drilling
down’ into the movement types within the MM module in order to capture the client
information by transaction.
= — External customers withdrawals such as change giving. Currently held as an overall total
in the SAP/ADS FI balance sheet account, and not broken down by individual client
account. Further analysis needs to be undertaken as to whether each debtor needs to be
identified separately within POL FS. If this is deemed necessary this could be established
by “drilling down” into the movement types within the MM module in order to capture the
client information by transaction.
= Allother financial transactions relating to adjustments and non-client transactions
Foreign Currency information
= — Foreign currency to be reported by branch in sterling
= There is a requirement to report FX in transit between Hemel and Branches -
investigation to be carried out to ensure that SSC captures Cash in Transit values on a
daily basis...to 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. How this gets into the system is yet to be established
~ is this a new flow or should this be included in the stock flow? The other option
is to input this as a journal. Does this include the balance of Stock in Hemel or just
the transactions? What about FX stock movements to and from branches (see CIT
requirement for FX).
ATM information
= ATM notes 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
Client Ledger information
= — Summarised balances by client, by branch, by day
= In the event that a single client has several products with different terms of payment then
the summarisation should be split accordingly to be mapped into different accounts in the
Client Ledger in POL FS
= Unique line by trading day
= For off-line branches this information is summarised into the relevant trading day when
the branch is back on line
= There should be differentiation between trading date and posting date to the ledgers
= Cash Centre Client transactions — level of detail required to be confirmed dependent on
the number of transactions for Girobank -summarised by Client by Day. Further analysis
Tequired in this area
Business Trading Ledger information
= This will hold information which are either sourced from automatic transactions from the
counter e.g. postal order fees — included in the summarised data from branches, or from
P&L affecting items e.g. debt write-offs which are sourced from manual journals
= — This holds business transactions that do not relate to the client but do not include the
fees relating to client ‘sales’
» — Detailed Information
[DATE \@ "dddd, db MMMM yyy" ]
© Post Office™ 2003
Version 3.4
Page 130 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
© Electronic pouch confirmations with the pouch number and value to enable matching of Cash in
Transit
o Error handling information to be processed into suspense accounts by item to enable matching of
errors on closure. Some error information requires product level information — further analysis
required
© 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
o Cash pouch information, for remittances into 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
» — Stock Ledger Information TBC
© — Stock Transaction Information from Horizon sales transactions
= — Including adjustments relating to error notices. All stock errors are treated as cash
discrepancies as is currently the case.
"Including adjustments due to stock losses (where cash from agent required)
= Rems in and out of stock at the branches volumes (and values) as appropriate need to
flow into the stock control and value for financials.
© — Stock Revaluation Information
The content of the interface depends on the reporting requirement from the POL FS chart of accounts and reporting
requirements to determine the level of detail required on the flow. 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 SAP.
ADS.
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 2 instances (Horizon and SAP ADS) producing several types of IDOCS in the POL financials in order to
produce the complete POL Ledgers.
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 and from the Cash Centres 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.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
© Post Office™ 2003
Page 131 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.14.10 Flow - Investments and Borrowings
Description: This flow carries information on Investments and Borrowings, which is a manual flow of information from
the RMG Treasury function into the POL FS Investments and Borrowings Ledger.
The information on this flow will be required to populate the following accounts in POL FS:
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 1
Nature of interface: Manual
How many instances of the interface are likely to exist: One
Frequency of use: Daily
Data volumes: Up to 10 journals per day
Time Constraints: The information being received from Treasury, but in order to get a daily position this should be
processed each day.
Fall Back Procedures: N/A
Security risks: The content of the information is sensitive, but as this is an internal flow within the group and is manual,
itis subject to the internal security risk of any e-mail or paper flow within the business. The appropriate level of security
should be put in place to protect this manual flow.
5.7.4.1 Flow—Accounts to MIS
Description:
This is a new flow of data from SAP into the MIS system via the TMS so that a total view of transactional information can
be lodged in the data warehouse
This data is required so that the data warehouse can become the one logical place where MI is derived from.
This interface should contain:
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 132 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
>» — Central Write Offs
>
Nature of interface: Automated interface sourced from the SAP end of day processes.
How many instances of the interface are likely to exist: One per day.
Frequency of use: Daily overnight.
Data volumes: Unknown at present. To be determined in detailed requirements analysis.
Time Constraints: The timings need to be driven by the data warehouse load schedules.
Fall Back Procedures: There is no fallback. A certain amount of resilience needs to be built and SLAs specified as to
recovery periods. The data warehouse is a business critical system but recovery times are not as critical as for
operational systems.
Security risks:
5.1.4.2 Flow - Cash Centre Cash Management to MIS
Description:
This is a new flow of data from SAPADS into the MIS system via the TMS so that a total view of transactional information
can be lodged in the data warehouse
This data is required so that the data warehouse can become the one logical place where MI is derived from.
This interface should contain
Session Id
Vv
Transaction Id
Product Id
vw
Vv
Sale value
Vv
Sale Quantity
Vv
Additional data items
Nature of interface: Automated interface sourced from the SAPADS end of day processes.
How many instances of the interface are likely to exist: One per day.
Frequency of use: Daily overnight.
Data volumes: Unknown at present. To be determined in detailed requirements analysis.
Time Constraints: The timings need to be driven by the data warehouse load schedules.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 133 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Fall Back Procedures: There is no fallback. A certain amount of resilience needs to be built and SLAs specified as to
recovery periods. The data warehouse is a business critical system but recovery times are not as critical as for
operational systems.
Security risks:
515. User Interfaces
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
516. Recenciliatien
Ref Requirement Description
ACM-005 I The solutions must be fully reconcilable where there is an explicit need for this
S11. Andit
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 \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 134 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
518. Business Bleopriat implications
5.1.8.1 Strategy
The Accounting and Cash Management Programme conforms to one of the key business focuses ~ simplification of our
processes
5.1.8.2 Organisation & 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.
5.1.8.3 Customer Experience
There will be no impact on the customer experience.
57.8.4 Facilities a Layout
There will be no impact on facilities and layout.
5.1.8.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
© Depending on chosen option - more accurate recording of MOP at time of customer session
© Removal of the cash account process and replacement with Trading Statements and Declaration processes
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:
The way cash is reported
© Information is accessed
Finance
© Changes to central accounting functions
Changes to the way TP and the new debt recovery function operate
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
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 135 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
5.1.8.6 Performance
There is likely to be an impact on performance, particularly in the initial stages to take account of
learning curves against new systems & processes as well as activity required during parallel run
etc.
5.1.8.7 Process a Data
There will be changes to business processes and the data required to operate:
o New central cash management processes
Changed processes at the branch to deal with automated remittances, cash holding declarations, removal of
the cash account processes
© New central management information processes for the access to data
o ~—Newreference data processes to ensure the capture of data at source
© New financial processes both at the branch and centrally
5.1.8.8 Application Software
The following systems will be modified:
o Horizon
o —SAPADS
o POL Data Warehouse
The following will be a new system:
o POL Financial System based on SAP
o Anewreference data system
5.1.8.9 Equipment
New hardware is required to run the SAP environment
New hardware will be required for the new reference data system
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 136 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
519. Business Risk
Ref Requirement Description
ACM-007 Itis essential that systems and connectivity have a high degree of resilience
ACM-008 Message between suppliers, Central Inventory Management and branchs must not be accessible by unauthorised
individuals
[DATE \@ "dddd, db MMMM yyy" ]
© Post Office™ 2003
Version 3.4
Page 137 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
6. Pregramme 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
RMG i
RMG
HR Management
7 I Financials
SAP/HR) ” Information A XESS)
he
Cast
_—-> Management
(SAP/ADS)
Stock
» Warehouse
Management
I ‘Transaction
* 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
« — Transaction Management
Counter Application
Management Information
Cash Management
Logistics Feeder Services
The following systems will be decommissioned as a result of the programme
UD
STAM
Intellect
OPTIP
CBDB
NNDB
RDS
[DATE \@ "dddd, db MMMM yyy" ]
Version 3.4
Page 138 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
WRDS
TP small systems
[DATE \@ “dddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 139 of 174
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
POL00038870
The following diagram shows a physical view of the above solution. Within the diagram the hosting domain is also clearly
shown.
BRANCH
Counter
Application
Riposte
NT
Fujitsu- jens H/W
Fujitsu Domain
Physical View
RMG Domain
SAP R/ Oracles) SAP R/3 Oracle(s)
Solaris Solaris
Fujitsu-Siemens Hav Fujitsu-Siemens H.
Horizon Data Centre
Business Systems
Domain
Huthwaite
Management Information
Oracte(s), HP UNIX
HP HAV
Logistics
RD! Feeder
Service
Oracle(s)
Solaris Oracle(s)
Solaris
Fujitsu Siemens H/w aris
Fujitsa Siemens H/w
Transaction
Management
{ine Adjustment
Notification)
Oracle(s)
Solaris
Fujitsu Siemens Hav
Stock EDG
Management Oracle(s)
HP UNIX
SAP R/3 DBs)
IBM X47
Mainframe
HP Hay
SAP R3 DBXS)
IBM X47
[DATE \@ "dddd, dd MMMM yyyy"
© Post Office™ 2003
Mainframe
Figure 3 : End-to-End Architecture Diagram
Version 3.4
Page 140 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
G1 Architecture Principles
GAL Apnilcatien
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
612 Resilience
Ref Requirement Description
TEC -008 I Itis essential that systems and connectivity have a high degree of resilience
6.13. Performance
Ref Requirement Description
TEC-009 I The new systems will at least match the performance achieved by the current system
G14. Communications
Ref Requirement Description
TEC-010 I TCP/IP is the predominant and strategic data communications protocol
TEC -011 I Checkpoint Firewall-t is the strategic firewall product.
62. Architecture Building Blocks
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 141 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccOM-PCD
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.
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 and also manages subpostmaster
remuneration
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.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 142 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
1. Pregramme 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
‘security requirements in the following systems:
Counter Application (Horizon)
Transaction Management
Logistics Feeder Service
SAPADS
Group systems (eg. SAPHR, ES-FS, Stock Warehouse Management)
eee oe
Security arrangements for Stock Reconciliation are to be determined.
[DATE \@ “dddd, dd MMMM yyyy" ]
Version 3.4
Page 143 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
Application/System Name:
POL Financiat
Application Scope
System freely available for use by all, including General Public
System available for use by Post Office Ltd/Royal Mail employees and agents only
System restricted to approved users only, including General Public
Application Type
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
System provides information to other applicatians/systems
Application Risks
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?
Could a compromise of the system cause legaliregulatory penalty?
Access Control
Nature of user base Internal Employee or agent
Third Party (existing contractual arrangement)
Third Party (no contractual arrangement)
Pubic
What access will users have to the system? Information Change:
Information Insertion
Information Browsing
Direct Access to DBMS /
Operating Systems
Js personalisation of content required?
Can users request access to personal information about themselves held on the system?
@ Reyathbel Group Pe 2008
HEAD
YES NO
HOOa
Aa
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Maintaining Data Security
Is access required by
Individuals
Groups of users
Are physical security measures low?
(eg LIW. offsite workers, laptop accessors) YES/NO
Is an access control systems available to control
access to permanent data? YES/NO
Is dia-up connectivity required? YES/NO
ls 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
Valume High or Medium or Low
Email fansmissions YES/NO
Recipients has Notes YES/NO I}
Source and destination trusted? YES/NO a
Binding non-repudiation required? YES/NO @
POL00038870
POL00038870
Programme Conceptual Design Project ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
Systems Classification SENSITIVE I
Result:
J
tSchenie Level} Identity Validation will be required by support staff requiring direct access to DBMS or Gpeniting System. No direct access at I
this level should be granted to uses of applications,
Standard User Identity
Validation Level:
I
pertonn face to face identity cheeks, secu
[publish the credentials in the Enterprise Directory,
User Access Authority:
Identity Validation
Required by Access
Level:
Controls:
Data Transmission
Controls:
Integrity Controls:
—!
I
i
Update/Delete insertiRead Insert
Level3 Level2 Levelt
Confi dentiality Confidentiality Services must be provided by Access Coatrol (Authorisation)
Strictly Confidential Bata should not be transmitted unless both Source and Destination are trusted.
Strictly Confidentiat may be trausmitted over tusted (infrastructure) networks without eneryplion
Totegnity services ust be provided by Awvess Control (Authorisation).
Adequate integrity contrals For data transmissions can be assumed
4
Royal Moll Group Ple 2008
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccCM-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 Post Office Ltd/Royal Mail employees and agents only @
System restricted to approved users only, including General Public ]
Application Type
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
System provides information to other applicationssystems
Application Risks
Is there a fraud risk?
Would a compromise of the system cause Pest 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 Internal Employee or agent
Third Party (existing contractual arrangement)
Third Party (no contractual arrangement)
Public
What access will users have to the system? Information Ghange
ER EEE
Information Insertion
Information Browsing
El
Direct Access to DBMS /
Operating Systems
Is persona on of content required?
Oo
a
In users raquest access to personal information about themselves held an the system?
POL00038870
POL00038870
Programme Conceptual Design Project: Poona Cash Management
COMMERCIAL IN CONFIDENCE Doe Ref:
AccCM-PCD
Maintaining Data Security
Is access required by
Individuals
Groups of users
Are physical security measures low?
{eq LIW, offsite workers. laptop accessors) YES/NO
Is an acvess control systems available to control
access to permanent data? YES/NO
Is diakup 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 YESINO
Recipients has Notes YES/NO
Source and destination trusted? YESINO
Binding non-repudiation required? YES/NO
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
Systems Classification SENSITIVE
Result:
Standard User Identity
Validation Level:
perlarm Face to face identity checks, securely record shared secret information, and issue Single Sign-on credentials on a hardware device aml
publish the eredentials in the Enterprise Directory.
User Access Authority:
Update/Delete insertiRead Insert
identity Validation
Required by Access Level3 Levai2 Level4
Level:
Confidentiality Confidentiality Services must be provided by Access Control (Authorisation)
Controls:
Data Transmission
Controls:
integrity Controls: Integrity services mast be provided by Access Control (Authorisation).
28 Royal Mal Group Ple 2003,
Trasted network provides snificient confidentiality controls for Confidential data - encryption nol necessary
Data modifications require audit logging
Read access requires aut logging
‘Adequate integrity controls for data transmissions can be assumed
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccCM-PCD
Application/System Name: 6
Reference Data System
Application Scope YES NO
System freely available for use by all, including General Public
System available for use by Post Office Lid/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
BOAnoHaA
BEEEEea
System provides information to other applications/systems
Application Risks YES NO
[Ea
[Ea]
\s thare a fraud risk?
Would 2 compromise of the system cause Post Office Ltd/Royal Mail public embarrassment?
Would a compromise of the systam cause severe business disruption?
Could 4 compromise of the system cause legal/requlatory 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
I
Information Insertion
Information Browsing
Direct Access to DBMS /
Operating Sysiems
Is personalisation of content required?
a I
Can users request access to persunal information about themselves held on the system?
© Royal Mall Secup Ple 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Maintaining Data Security
Is access required by
Are physical security measures low?
(eg LIW, offsite workers, laptop accessors)
Js an access control systems available to
access to permanent data?
\s dia-up connectivity required?
Is extranet connectivity required?
Data transmissions
Transmission nature
Frequency
Volume
Email transmissions
Recipients has Notes
Source and destination trusted?
Binding non-repudiation required?
Individuals
Groups of users
YES/NO
YESINO
YES/NO
YES/NO
Do data transmissions oscur
Over untrusted networks (eg Internet)
ver 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
YES/NO
& a
HAA
HEE @
BPHAOAARARASRABR
HHEHBOOt BEB
POL00038870
POL00038870
Programme Conceptual Design Project ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
Systems Classification SENSITIVE
Result:
Standard User Identity
Validation Level:
[perform thee to fice identity checks, securely record shared seowt information, and issue Single Sign-on credentials ou a hardware devine and
[publish the credentials in the Enterprise Directory:
User Access Authority:
UpdateiDelete insertiRead insert
identity Validation
Required by Access Level3 Level2 Levelt
Level:
Confidentiality [Confidentiality Services must be provided by Aeoess Control (Authorisation)
Controls:
Data Transmission
Controls:
integrity Controls: Inleyrity services must be provided by Access Control (Authorisation).
2 Real Wa ecu Pe 2003
Trusted network provides suificient confidentiality eonttnls for Confidential data - eneryption not necessary
‘Data modifications require audit logging
Read access requires audit loguing
Adequate integrity controls for data transmissisns ean be assumed.
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
&. Current Phase Deliverables
81. Post Offico™
1. Programme Conceptual Design
2. Detailed Project Conceptual Designs as a result of this document
ONCH/ Automated Remittances
Cash/Bank Ledgers
Reference Data
Management Information
Overall Financials
Branch Liability
Transaction Management
‘Systems Decommissioning
3. Work Packages to suppliers
za-enoe®D
82. Packages
The following work packages will be given to suppliers
83. Services
1. Project Conceptual Design — Professional Services to assist Post Office Ltd
a. ONCH/Automated Remittances
b. Reference Data
c. Branch Liability
d. Transaction Management
e. Decommissioning Fujitsu Estate
2. Detailed Project Solutions Designs
a. ONCH/Automated Remittances
b. Branch Liability
c. Transaction Management
d. Decommissioning Fujitsu Estate
64 — 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
e. SAP Financials
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 153 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
f. Prism Legacy System Decommissioning
2. Detailed Project Solutions Designs
a. ONCH/Automated Remittances
b. SAPADS changes to support Cash/Bank Ledgers
c. Cash/Bank ledgers
d. SAP Financials
65. ~—s_ Parity
1. Detailed Solutions Designs
a. Reference Data
b. Management Information
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 154 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
9. High Level Programme Planning
91. Timescales
The following plan depicts the whole of Accounting & Cash Management Programme milestones shown as based on the
business case and is being readdressed as part of the delivery programme
err? I ores I ores I ommi
2003 I 2003 I 2003 2004,
grr? I ores I ores I orri
2001 I 2008 I 2004 I 20035
I
I
Programme Analysis I
I
Release 1
Releases 23
Requirements
Anlaysis-Design
Release 1
Release 2
Release 3
Devclop/Tesvmptement
Rollout
Ratease1 [ ‘Apr I04
il Roll
Roll out
Mag 05
Release 3
ap
I
Accaunting/Cash) Management Programme I
T i}
Figure 4 - Programme
Plan
92. Dependencies
List the project dependencies both outside the project and within it.
1.
2.
3.
The Cash Ledger projects is dependent on changes made to branch processes - the combination of which gives
the overall visibility of cash
Reference Data is dependent upon having the detailed requirements of the Cash Ledger projects known
There is a dependency on Horizon release timescales not slipping and there being sufficient capacity in the
teleases at the appropriate times
There is a dependency on the overall POL delivery plan.
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 155 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
10. Pregramme Acceptance Strategy
Ref Description
‘ACM-008 A separate work strand will be initiated which defines the acceptance strategy and the detailed acceptance criteria including
where and how these will be proven
A. separate
work strand
will be
initiated
which
defines the
acceptance
strategy
and the
detailed
acceptance
criteria
including
where and
how these
will be
proven
‘ACM-010 I Acceptance tests must cover:
Document reviews
Procedural walkthroughs
Internal test phases
Functional and direct interface tests
Non-functional tests for disaster recovery, volume's, security, technical,
‘ACM.011 I Successful completion of the various test phases both internally and 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 document and 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.
TL. Pregramme implementation a Migration Strategy
Ref
Description
ACM-014
A separate work strand will be initiated which focuses on business and technical migration
[DATE \@ "dddd, db MMMM yyy" ]
Version 3.4
Page 156 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
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 Existing reference data feeds need to be maintained during migration until switched over to the new
source or no longer required
ACM-020 I There Will need to be a cutover strategy developed to move from CBDB accounting through to
accounting from SAP
ACM-021 There will need to be a cutover strategy developed to migrate a branch from the current cash account
process to the new Trading Statement
111. Considerations for Migration ef Financials and related interfaces
Introduction
This section deals with the considerations required for the migration between Releases 1 and 2 for the financials to POL
FS.
It should be noted that although the Cash Ledger will be implemented to establish more accurate cash reporting from
Release 1, it will not replace the legal reporting and monthly cycle reported from CBDB to ES-FS until after Release 2.
Branches
It should be noted that it takes at least 6 weeks to roll out new branch software and it has been decided that the ledger
will not be updated with the branch data until all branches are able to report via the interfaces. This is the soft launch
method whereby the branches received the functionality but it will not be used until the final branch is updated. The
initial load for Cash Balances at Release 1, will be facilitated by a data flow of summarised balances from the branches
using the same interface as for the on-going movements, but with different summarisation criteria for the initial load.
Thus enabling the balances to be established and be agreed back to Horizon from Release 1 for the Cash Balances.
From Release 2 the other balances will need to be uploaded in addition to the Cash. Assuming that the Cash balance
on POL FS is correct at the point of cutover for Release 2, there may be discrepancy in the closing balance for cash
registered on POL FS vs. that reported on CBDB. As this may not be reconcilable because of the nature of the
information on CBDB, preparation of the auditors is advised.
Branches should be prepared for cutover by completing all necessary transactions required to be included in the
‘opening balances by the close date. This should be communicated in adequate time for the branches to plan this
activity e.g. there should be no outstanding Rems to be processed.
SAP ADS
The initial load from SAP ADS will need to be planned separately. The interface will not be used for the initial load of
information for Release 1 or Release 2. In Release 1 the cash balances can be loaded manually using the declared
position at the agreed cutover date. The closing balances in CBDB will be used for Release 2, which is assumed to hold
the closing balances via the Cash Account flow as with all other financial data. This will need to be separately uploaded
due to the nature and timing of the updating of CBDB with the cash account information. This will need further
[DATE \@ "dddd, db MMMM yyy" ]
Version 3.4
Page 157 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
investigation and planning. The open items for Release 2 relating to SAP ADS balances for Debtors and Creditors will
be taken from CBDB and will need to be considered separately for reconciliation purposes,
Error handling
For errors open in debt recovery during the cutover for Release 2, these will need to be written off into the new ledgers
after the cutover and go-live. This is assuming that these items are not accounted for until the decision is made
whether to claim them back from the agent, the client or whether to write them off. It is assumed that the open errors
will not be entered into the suspense account as open items at the cutover and that they have not been accounted for in
the closing ledgers already. If the cutover happens over a year-end these will need to be input as prior year
adjustments.
TAL Migration considerations Releases 12 2
> Change management
© Ensure the roles and responsibilities of all staff are clear for the introduction of the new processes
o Ensure all staff are fully trained and prepared for the changes in their area and the new business
processes
> — Cutover plan
o Ensure the cutover plan fits with the overall programme
Establish detailed cutover plan by data type
Establish closing assumptions for all closing balances
Establish closing rules for all closing balances e.g. open items
Stock takes required for Release 2 cutover?
Contingency for non-year-end close — consider the implications on the P&L reporting for the year
for Release 2
Plan hardware preparation rollout for SAP GUI and technical preparation
© Agree reconciliation methodology, plan and document for cutover
© Establish ‘System Acceptance Criteria’ for go-live
> Data loads
o Establish closing balances on legacy systems and Horizon at specific planned close date
© Agree closing balances and open items to be migrated
o Prepare data load methodology to establish opening balances
o Release 1 will need to consider Cash and Near Cash in Branches, Cash Centres and at the
Centre, plus Cash in Transit
© Release 2 will need to consider Debtors, Creditors, Stock and other balance sheet items
» — Reconciliation
© List reports required for reconciliation of data loads
© Ensure any technical requirements are put in place in advance of the close for migration specific
reports
o Ensure staffing available to carry out reconciliation for closing and opening balances
co Reconcile balances relating to SAP ADS open items 2 ways? To CBDB and to SAP ADS?
> Auditors
co Request auditor approval for approach
o Request auditor involvement in closing balances sign-off
> Establish Productive system environment
o Ensure all necessary licences are in place
o Ensure all new users have been set up on SAP with the required, role-based authorisations
co Putin place system technical administration capability and procedure
o Establish helpdesk facility and handover for go-live
[DATE \@ "dddd, dd MMMM yyy" J
00000
Version 3.4
Page 158 of 174
© Post Office™ 2003
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
© Communicate support procedure to end users
» Go Live Sign Off
co Review system acceptance criteria and sign off
1112. Parallel running during Release 2
> — Bank statements processed in both new and old systems. (Assumed manual)
co Pragmatism required for new system processing - summarised as required by cash ledger entries
in POL FS. Detailed as required after Migration to Release 2.
> — Centrally made cash adjustments which are not captured in Horizon
> Loans and Investments journals - these are assumed to be reversing journals when posted into POL FS and
therefore should be straightforward,
T1113. Decommissiening of legacy systems in Releases 2.2.3
» — Identify systems to be decommissioned
o Ensure that any small systems are captured
» — Existing interfaces, extracts and reports
o Ensure all in-bound and out-bound interfaces are identified
© Identify which interfaces are required to be continued and which are redundant
© Ensure all required data flowing through legacy systems are either ‘redundant’ or captured by a new
system
> Archiving requirements
o Archiving
= What
= How
= When
= Where
= For how long
© Access to legacy data requirements
= — Nature of access
= Frequency of access
= Location of data
‘Assumptions
» Legacy data will not be migrated except where the detail is required in the new system of matching and
clearing of open items or monitoring of opening balances on the balance sheet
» — Systems will be decommissioned once the acceptance criteria for the system has been signed off and any
additional, critical reports have been put in place to cover the decommissioned systems
» No automatic loads have been assumed for the upload of opening balances from CBDB or SAP ADS. This will
need to be addressed during the detailed requirements gathering phase
[DATE \@ "dddd, db MMMM yyy" ]
Version 3.4
Page 159 of 174
© Post Office™ 2003
Programme Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038870
POL00038870
Project: ‘Accounting & Cash Management
Programme
Doc Ref:
‘AcoCM-PCD
[DATE \@ “dddd, dd MMMM yyyy" ]
© Post Office™ 2003
Version 3.4
Page 160 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AceCM-PCD
112. System Decommissioning
OPTIP
Current Interfaces into OPTIP & Proposed Future State
Fujitsu TMS Cash Account Files - numerous. Daily Transaction & CTS files sent from TMS direct to:
TMS Transaction Files - numerous « POLFS
CTS (Client Transmission Summary File) — one e Data Warehouse
RDS Details of applied reference data changes 1 file Mon to Fri Reference Data changes to be sent direct to:
« POLFS (via RDMC)
e Data Warehouse
DPC/EDS Supporting document information, 1 file for each of the I Mon to Fri DPC/EDS files to be sent direct to:
following: e TMS
Cheque
Personal Banking
TV Licensing
Camelot Supporting document information Camelot files to be sent direct to:
Daily file - 1 file 7 days a week e TMS
Weekly files
e Settlement file — 1 file Sunday night
e Retailer file — 1 file Sunday night
CBDB 2/3 Week C/A File Friday night Not required in future state
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 161 of 174
© Post Office™ 2003,
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD.
Weekly Error file (details of outstanding errors) Sunday night
Horizon MIS Details of offices to be reported within the Horizon MIS I 7 days a week Horizon MIS Details to be sent direct to :
extract ° TMS
Current extracts produced from OPTIP & Proposed Future State
English offices e POLFS
« Data Warehouse
CBDB Supporting document extracts Supporting document information to be sent from
Camelot Type 10 — weekly, Wednesday night 1 file for each I Camelot & DPC/EDS direct to:
TVL Type 10 — weekly, Wednesday night weekly e TMS
Chq Type 24 — weekly, Thursday night o TMS to forward to POL FS & Data
AP Type 23 — weekly, Friday night Warehouse
OBCS Details of OBCS transactions FTP’d to Network Support I 1 file weekly on I OBCS transaction file to be produced by TMS &
Server at Dearne Sunday FTP'd to:
e Network Support Server at Dearne
Horizon MIS Details of transactions for offices as received within file from I 6 days a week I Horizon MIS file to be produced by TMS & FTP'd
Horizon MIS FTP’d to server in Bristol (excluding Sat) to:
° Server in Bristol
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 162 of 174
© Post Office™ 2003,
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE
Programme
Doc Ref:
‘Accounting & Cash Management
AcoCM-PCD
POL00038870
POL00038870
RMMI Details of Royal Mail transactions extracted from transaction I 1 file weekly on I RMMI file produced by TMS and sent direct to
files received from TMS. File FTP’d to Future Walk Server & I Tuesday Royal Mail
System Support team then e-mail to a contact within Royal
Mail.
Martins Details of Camelot transactions for Martins branchs. File is I 1 file weekly on I Camelot transaction details received by TMS and
currently produced by OPTIP and FTP'd to Future Walk I Tuesday file produced by TMS to be sent direct to Martins
Server. The System Support team than e-mail file to Martins
and telephone to confirm that the file has been sent.
EPOSS To be implemented shortly — weekly report and csv file to be I Weekly Transaction details to be sent from TMS to Data
produced containing EPOSS transaction details for specific Warehouse. Access details via ad hoc query or
products (P & A, Inland Revenue, Promotions, Local set up production of scheduled report.
Schemes)
CTS Copy of CTS file is FTP’d to Future Walk Server to enable I 6 days a week I TMS to forward copy of CTS file direct to:
Cash Management Team to perform daily settlement with AP I (excluding Sat) e Future Walk Server
clients (Mon to Fri)
Fiche Supporting Document information received from DPC/EDS I Weekly on I TMS sends supporting document details to:
is accessible for users to view via Cendris Alchemy Web I Monday * Data Warehouse
once data reaches a certain age within OPTIP (used as data Retentions periods and archive facility to be defined.
archive facility)
Sales MI Copy of transaction files received from Fujitsu 7 days a week Date Warehouse to receive transaction files direct
from:
« TMS
OPTIP Reports
The current OPTIP reports have been reviewed and future requirements within this area for TP and Cash management have been captured within the Programme Management Information requirements.
[DATE \@ "dddd, dd MMMM yyy" ]
© Post Office™ 2003,
Version 3.4
Page 163 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AceCM-PCD
CBDB
Current Interfaces into CBDB & Proposed Future State
PIVOT
DNS Tapes received from DNS fo Tapes received from DNS and processed b'
e Bonds & Stock Transactions Wkly on Thurs TS
e National Savings bank Transactions Wkly on Friday TMS
DPU Supporting document details and manually keyed cash I Daily Mon-Fri Cash accounts will not exist. DPU to have a route
accounts into TMS for Supporting Document information.
Due to contractual requirements with Clients it is
likely that additional details will still need to be
captured via this route.
EDS Volume of Enlivened Card Accounts and volume and value I Monthly EDS send to TMS and TMS to feed details direct
of Card Account transactions to be forwarded to HR SAP for to HR SAP
Agent remuneration purposes
OPTIP. Supporting document information (TVL, Chq, AP, Camelot) I 7 days a week Received into TMS and details forwarded to POL
and Cash Account data FS & Data Warehouse
PACSYS Amended P & A pick list for PACSYS 6 days a week I Received into TMS or Data Warehouse from
(excluding Sun) PACSYS
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 164 of 174
© Post Office™ 2003,
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AeoCM-PCD
RFLS Supporting document details for RFLS transactions Wkly on Friday RFLS file to be sent direct to TMS
CLASS:
NA
Current extracts produced from CBDB & Proposed Future State
PIVOT
Output:
Capita
(excluding Sun) Transaction details from TMS or Data Warehouse
ESFS Ledger Postings Monthly Link from POL FS direct into ESFS. May still be a
need for some manual JV's.
Girobank Details of Co-op Bank Cheque encashments. File FTP’d to Details extracted from TMS or Data Warehouse &
Future Walk Server & System Support Team e-mail to sent to Girobank
Girobank.
HMIS Branch details and addresses Weekly on Sat File to be produced by NRDS
HRSAP Summarised sales details by branch (volume and value) Twice monthly TMS link direct to HR SAP.
Intellect Various tables copied to Intellect Weds & Sun Intellect to be de-commissioned in Release 1
Local Schemes Branch details Monthly File to be produced by NRDS
[DATE \@ "dddd, dd MMMM yyy" J
Version 3.4
Page 165 of 174
© Post Office™ 2003,
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AceCM-PCD
POL00038870
POL00038870
NRM Branch & Transaction details Monthly Branch details from NRDS
Transaction details from TMS or Data Warehouse
OPTIP 2/3 week cash account details Weekly on Fri OPTIP to be de-commissioned in Release 2
Details of outstanding cash account errors Weekly on Sun
PACSYS P & A Supporting document details 6 days a week Details extracted from TMS or Data Warehouse
(excluding Sun) and sent to PACSYS
DPI Parcelforce Transaction details Mon to Fri To be provided by TMS or Data Warehouse
RECALL Branch and cash account details Weekly on Sat Branch details to be provided by NRDS
Transaction details to be provided by TMS or Data
Warehouse
RFLS Branch details Monthly To be provided by NRDS
RMMIS. Sales details for Royal Mail Products Monthly RMMIS to be de-commissioned ?
SPMR Stock in hand values Weekly on Sat SPMR to be de-commissioned ?
STAM Average daily volume of transactions Monthly STAM to be de-commissioned ?
CLASS:
TP A number of CSV files showing CLASS errors over various I Monthly Information regarding exceptions to be available
periods within Data Warehouse and POL FS
DNS e Cash account values for DNS lines, current & Transactions details to be provided by TMS or
[DATE \@ "dddd, dd MMMM yyyy" }
© Post Office™ 2003,
Version 3.4
Page 166 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD.
previous week Data Warehouse (including late transactions ?)
«Late input cash account report (KLASS 101) FTP’d
to Future Walk Server & System Support e-mail to
DNS
e Cash Account Adjustment report (KLASS 022)
FTP'd to Future Walk Server & System Support e-
Adjustment details to be provided by POL FS or
Data Warehouse depending on level of data
adjusted.
mail to DNS
FOSACS Paper outputs - Journal Vouchers, KLASS 110 & KLASS 117 I Weekly, Sat FOSACS functionality to be replaced by POL FS
Late Account Adjustments/ Reversed Report and system de-commissioned
Girobank e Cash account values for Girobank lines Transactions details to be provided by TMS or
¢ Late input cash account report (KLASS 100 - paper) Data Warehouse (including late transactions ?)
¢ Cash account adjustment details. FTP'd to Future Adjustment details to be provided by POL FS or
Walk server & System Support team e-mail to Data Warehouse depending on level of data
Girobank adjusted.
Intellect Copies of various tables for use in Intellect Weds & Sun Intellect to be de-commissioned in Release 1
KLASS003 Error situations report M, T, W, Th, Sat KLASS 3 Download functionality regarding
exceptions to be replaced by POL FS and/or
Data Warehouse depending on level of detail
required.
SAPADS Cash account line values for Girobank, P & A & Inland I Weekly Transaction detail to be provided by TMS if
Revenue Tax Credit lines individual transaction detail required or Data
Warehouse if Summary level information
required
Settlement Various paper reports are used for settlement with clients Various Captured within MI requirements
DVLA Extract Volume and value of barcoded licence renewal transaction I Weekly Transaction details to be provided by Data
[DATE \@ "dddd, dd MMMM yyy" ]
© Post Office™ 2003,
Version 3.4
Page 167 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AcoCM-PCD
[ by office. File is FTP'd to Future Walk Server. l I Warehouse
CBDB Reports
The current CBDB (PIVOT and KLASS) reports have been reviewed and future requirements within this area for TP and Cash management have been captured within the Programme Management
Information requirements.
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
Page 168 of 174
© Post Office™ 2003,
Programme Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
‘Accounting & Cash Management
Programme
‘AccCM-PCD.
‘System Migration
The following table identifies those systems that currently exist and those that will be in place in April 2005.
1 AP Clients AP Clients External
2 Benefits Agency Funding Benefits Agency Funding Prism.
3 Bureau De Change MIS Bureau De Change MIS Prism.
4 CACH CACH Prism
5 Camelot Camelot External
6 Capita Capita External
7 Cashiers (FICS) POL FS Fujitsu
8 CBDB POLFS Fujitsu
9 CLASS POLFS Fujitsu
10 CREDO. CREDO PRISM
tt DAVROS POL FS Fujitsu
12 ONS DNS External
413 DPU (Route 3) Route into TMS Fujitsu ?
14 EDS EDS External
15 ES-FS ES-FS External (Group)
16 FICHE Data Warehouse PRISM
47 FOSACS POL FS Fujitsu
48 Girobank Girobank External
19 Girobank Errors Application POLFS ? Fujitsu
20 Holding Account database POL FS Fujitsu
il HORIZON MIS. Data Warehouse ? (ext to TP) PRISM
22 HRSAP HRSAP External (Group)
23 Intellect Data Warehouse PRISM
24 Internet Internet PRISM
25 IRIS POLFS ? Fujitsu
26 Issued Errors Database POL FS Fujitsu
27 KLASS003 POL FS Fujitsu
28 UD Data Warehouse ? PRISM
29 LINK LINK External
30 Local Schemes Local Schemes PRISM
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
© Post Office™ 2003,
Page 169 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
31 Lotprize Lotprize PRISM
32 Network Banking Network Banking IBM
33 NNDB NRDS PRISM
34 NRM NRM PRISM
35 OPTIP TMS Fujitsu
36 PACSYS PACSYS (Jointly owned with client) PRISM
37 PIVOT Data Warehouse & NRDS PRISM
38 POCA POCA PRISM
39 POCM Removed ? (ext to TP) Removed
40 POLC. POLC PRISM
441 Powerkeys Powerkeys PRISM
42 PPOP EDS External
43 RECALL RECALL PRISM
44 Regional Ref. Data NRDS PRISM
45 RFLS RFLS PRISM
46 Sales MIS Data Warehouse PRISM
47 SAP ADS. SAP ADS PRISM
48 SPMR Removed Removed
49 STAM Data Warehouse PRISM
50 UKPA UKPA. Fujitsu
54 WRDS NRDS PRISM
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
© Post Office™ 2003,
Page 170 of 174
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
Proposed Future System Architecture
POL00038870
POL00038870
Network
' Banking I LINK I I AP Clients I I Camelot I I DNS I [ Girobank I I EDS ] [ Capita I
Clients a
I Electronic Data Interchange I
ry ry
I_I ES-FS
DPU Martins PI
PoLFs I
PACSYS _p[ HR SAP
Horizon MIS TMS \ F
/
i CREDO
RMMI I ——+] bata Warehouse i
I I Recall POL
:
RFLS RDMC _ I Poca I Intemet
Horizon NRDS ABC
LFS
HMIS © I Local
I I Schomec
NBSC
SAPADS
OBCS IR PAF
KEY:
Fujitsu Services
Hosted
I Prism Alliance
Hosted
© Post Office™ 2003,
POL00038870
POL00038870
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AcoCM-PCD
The following Chart of Accounts divided into two parts - Release 1 (Cash elements) and releases 2/3
Release 1
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
Page 172 of 174
© Post Office™ 2003,
Programme Conceptual Design Project: ‘Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
‘AccCM-PCD
POL Chart of Accounts
iw
use .
iron Suro. im Can New Sou ota POL. Patna me, Grape nde mac edi M 1st : eras 588.
ert eax “ei ‘owe ‘se
cammrt c a ‘Acct ted: PUKE ‘Bee
Bin Se Sauer Bans 2 amcor ene bemsce ce Giza ist Serato aa Pr Gi Sey ‘bee
ES ecaamst ‘ton 2s fatves abe on tan conan MOA at ‘eth ton tak azteca bee
‘eee evel 2 cots, coy wena ove ign cpl
Dat bod OHS im Aran hPa
eet eau ‘aa iii is i eat Cent Brn Pl gen TP “
Eustis camer “Eoufie 17 rence arene uw arc ncaa Soviets ae
fon tie Samer ffi Go area uta cea Fa ncaa Senin tee oe alec it oe ee a
timc Ss" Ca Eu ast (7 ra eno cian Se
HooiSKP MCS REPCROTCATONT —NeuovSAP ADS > tagcomeban accu Coat Pele Wve Weal ao
Noneoisto aos can ‘tone ADS 8 abteaases bret, 08 296 N09 ‘As SSnpe is eh eh phe wee at
Cena Samat Sen Evereoramssten ‘2 Stentdi ete nod eae 9, ch ls
FomorSSo., rset Rees 2 Rrearecwee asc Sept wate men ol em rh
con ten nee So mace EPO a suse rey ok Cr, ib een ecu
Ee sores ‘ae gras bees cms at PO sls cee red
NEAR CASH AT siTES fi
eon abe” ea “isin 4 eur assert Se ek : ss
teseoutae ate” CRO ni i Someone a i i a a pla Be
INTRANST insted in POL
oR NaN
Hevea Cara
“is ia
SUP ADBCaih Acad
ee
Sap 0390 4
SAP ROBES Ch
Agree
een ADS
‘HosanSS01V
ciate ‘apios
Precast oreo
suai Ba ie
sep Iotnssignize <9 108
caMe neonSiaanine
iif
cams Hons
FEPUDITOSSOSIRTS Tobe howe. 82
Gamer sap sagissr ca
coca SOP RIBASE CA
Ce ace
Neagle CF Cea
Neeypeste —CHiCawal
Nate CFF
Naser CFP
Ne aepleee” CFBCaeat 9
Ne igpleil eFC wal
Ne dyes" CFEC
Nadya CFP eal
Nasepeete CFP eal
Neale
cannot “ae
‘Ace wa
‘ronan
oreo
ea
4S Rrageege ono
Ferssioovace some
G weancomn.crenues toes
i
one raceactaetetye ates
MAT UEME tote
3
4
Loew ast Ort,
saan
an,
hii ia in i)
9 Bak ao
3 Rap eng
BALANCING FIGURE
1, BLANOING ADCOUNT FOR Bt
Monty Act te Ped ete
Cra Acne
Sprite brew oo ty tet ns wth py
Seite lo ere mpg ane ceh eth cae.
Thistle rip eas vce done who uly lero Sark al on Sa,
opie owe peng wares a
Seni cna kul ce: sae ay ard he sm ce, RDABAR ine
Sapte ons tule at
Sopris erste eng Sass Ga Tse nt me pat bk
Separate oa wei eon POL ATM wih a
POL ope etc nae fsa aise
7. RDAPIAR naw
outs PY
OCs ene eas lms fnatcan ai soe ese eeu
‘Si ind isd kh iy a
‘Wd a an i
Und estima ils ni ha as nee
esd chat om Go dy
‘ae
iii ui ina a ei ng i ar
“Ths come narod 19 amet ska covolb ECE VorOb
Bh Ue ed ray br mo ye aot’ eae be moe 1 cote
Jf evens aston Se ess eon she
“estat of PR ren il bing eee
POL onde eh tan oleate tals
‘hese ura wes ses ged
‘Sie
en
geeegenee
POL00038870
POL00038870
POL00038870
POL00038870
Programme Conceptual Design Project: Accounting & Cash Management
Programme
COMMERCIAL IN CONFIDENCE Doc Ref:
AccCM-PCD
CLIENT LEDGER CODE HIFRARCHICAL STRUCTURE
“The following pages detail the current Ledger Code Hierarchy existing on the CLASS database sub-ledger as at
July 2003. ‘The lst is sub-divided in order to ilustrate the groups of codes relating to various sections of the
POCL Balance Sheet code structure forming part of the main Business Ledger
Fach page is split into various columns:
(a) The first column on the left shows allocated Cash Account Line numbers for Receipts/Payments and
CashiStoek tables.
() The second and third columns show the Posting Level 3 ledger code (to which any related Cash
Account line is linked).
(©) The fourth and fitth columns show the intermediate Summary Level 2 ledger code into which totals
from groups of Level 3 codes are summarised,
(@) The final two columns on the tight detail the Summary Level 1 ledger code to which Level 2 codes are
summarised to form the Balances for interface into ESFS.
INDEX TO PAGES
PAGE NUMBER ISECTION / CLASS INTERFACE CODE,
lEspected POL FS area
1 JAGENCY CASH AND BAMK BALANCES Jase 15000 (ESFS cule 000), Jost tedgee
2 lpusniess LOAN AccouNT Jase isse0 (ESF code 57503) flneeeaent deer
3 lconnetssion ner #ROM SETT JA58 15600 (ESAS ende 57508) finn code n Pe
‘ lcuiexT Loan account Jane 26650. (ESRS code 96011) finvenment ed:
6 IvaLue stocks JAB 16000 (SPS code £7505) _ [stock
2 Isunpky DEBTORS (CLASS) Jaze ron (@s#s code $9050) _ [oettns codes
29 lavrRasusINess EXPENDITURE Jaze 20000 (ESFS code $7502) Ietaied accouct mapped 11 to ES-FS
wt luvreasusiness INCOME i laze 2000 (ESPs code 9701) Deteied eccou mayped 11 ty ES-FS
ay IcLAss suspense accounts JASE 20950 (ESFS code 62420)
4 IsuwDRY CREDITORS (CLAS: Jase zison (GSR code 62051) Icredtore codes
15 h.errens ivTERBUSINESS Jane 22000 (SRS code 42425) _ [accounts payee
16 lpARCELFORCE INTERBUSINESS Jan622060 (ESRS code 62430) [Accounts payable
re JAGENCY CLIENT BALANCES JABE 22000 (ESFS code 62400) _ [accounts payee or sceietle
» REGIONAL REM UNIT voUCHERS Jae 20590 (ESS code e023)
[DATE \@ "dddd, dd MMMM yyyy"]
Version 3.4
Page 174 of 174
© Post Office™ 2003