FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
PO Ltd Financial Systems
Conceptual Design
ROLE NAME AREA OF SIGNATURE Date
RESPONSIBILITY
AUTHORS PHILIP GODDEN Business
ARCHITECTURE
BDA SiGN-OFF I KAREN HILLSDEN Business
(PEER REVIEWER) I CHRIS P ALLEN ARCHITECTURE
TDA Sicn-ofF I CLive READ TECHNICAL
(PEER REVIEWER) ARCHITECTURE
DELIVERY PROJECT
MANAGER DELIVERY
Version 1.0 Page 1/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Table of Contents
1 Document Control. 4
1.1 Document Informatiot 4
1.2 Document History.. 4
4.3 Change Process. 5
1.4 Changes in this Version. 5
1.5 6
1.6 7
17 8
1.8 9
2 _ Introductio 4
241
2.2
2.3
2.4 Document Explanations.
3 Overvie 13
3.1. Business Proposition..
3.2 Functional Summary..
3.3. Systems summary.
3.4 Potential for Change.
4 Constraints...
4.1 High Level Functional.
4.2 Dependencies and Assumptions.
4.3 Legal & Regulatory.
44 Audit...
4.5 Architectural Framework & Building Blocks.
4.6 Supplier...
5 Design Principles.
5.1 Programme:.
5.2 Project:.
6 Functional Requirements.
6.1 General.
6.2 General
6.3 Client Ledger
6.4 Debt Recovery.
6.5 Cash Centre Management
6.6 Stock Recording & Accounting.
6.7 Foreign Exchange..
6.8 New Reference Data System..
7 _ Process Models......
7.1 Post Office Processes in Scope..
7.2 A4- Accounts and Settlement.
7.3 A442 Summarise Client Data.
7.4 A45 Client Settlement from Client.
7.5 A46 Verification...
7.6 A47 Debt Recovery.
7.7 A48- Produce POL Ledger.
8 Business Processes..
8.1 A3 Stock Management..
8.2 A43 Summarise Transaction Data:
8.3 Client Settlement to Clients A44.....
8.4 A45 Client Settlement from Clients
8.5 A46 Verification...
8.6 A47 Debt Recovery.
8.7 A48 Produce POL ig
8.8 A489 General Ledger Processing.
8.9 Management & Accounting Information.
8.10 New Reference Data System.
Information Flow:
9.1 Branch Data from Horizor
9.2 Cash Centre Data From SAP ADS
9.3 Financial Results to ESFS...
9.4 Transaction Corrections to Horizon.
Version 1.0 Page 2/141
©
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
9.5 Reference Data From NRDS.
9.6 Reference Data To NRDS..
9.7 Reference Data NRDS to Horizon.
9.8 NSSC Stock movements from WCS.......
9.9 Summary Transaction Information to Girobank..
9.10 Summary Transaction Information to NS&I
9.14 Remittance Advices to Client
9.12 Statements to Clients
9.13 Stock Statements to
9.14 Statements to Agents..
9.15 Payments file to BACS.
9.16 Enhancement to ESFS to NRDS Interface.
10 Non-Functional Requirements.
10.1 Volumetiics.....
10.2 Sizing Assumption:
10.3 Service Levels...
10.4 Problem Management & Tracking
10.5 Business Continuity.
10.6 Training...
11 Technical Requirement:
11.4 End-to-End Architecture Diagram (Example shown below).
11.2 Architecture Principles.
11.3 Integration & Interface.
11.4 Other Technical Requirement:
12 Security Requirements.
12.1 Security Testing..
13 Deliverables / Work P;
13.1 Post Office™.
13.2 Prism Alliance
13.3 Fujitsu Services.
14 Planning.
14.1 Timescale:
14.2 Dependencies.
15 Acceptance.
16 Testing.
17 Implementation & Migration...
17.1 Co-ordination of the feeds into POL F:
18 Appendix A — Requirements Catalogue...
19 Appendix B — Impact Stakeholder Forum Design Principle:
20 Appendix C: Transaction example:
20.1 Process: Sale of a Service in Branc!
20.2 Process: Sale of Non Balance Sheet Stock Product
20.3 Sale of Balance Sheet Stock Product.
20.4 Transaction Corrections.
20.5 Sale of Service in Cash Centre.
20.6 Delivery of Cash to Branch — S6
20.7 Delivery of Stock to Branch...
20.8 Foreign Currency Remittance — Cash Centre to Branch.
20.9 Sale of Foreign Currency in Branch..
lien
Version 1.0 Page 3/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
1 Document Control
1.14. Document Information
Document Title: PO Ltd Financial Systems — Release 3
Document Type: Conceptual Design
Abstract: This document details the Business & Operational Requirements
for PO Ltd Financial Systems. It shows the High Level Business
Process Model, Details the Technical Requirements and
describes the Architectural End-to -End scope and Principles that
should be employed in the implementation of the solutions for the
PO Ltd Financial Systems Project.
Document Status: Draft
Originator & Karen Hillsden — Business Solutions
Department:
Contributors: Fujitsu Services, Prism Alliance
Post Office Ray Jackson; David Parnell; Karen Hillsden;; Chris P Allen
Distribution:
Supplier Bob Cragg; Tony Brain; Peter Flood; Philip Godden; (Prism)
Distribution: Gareth Jenkins; Bill Reynolds; (Fujitsu);
1.2 Document History
Version. Date. Reason for Issue. Associated
_WP/ CT Nos
0.01 16/01/04 _ First Draft
0.02 7102/04 Second Draft for Project review
0.03 19/02/04 I Version for Baseline
0.04 24/03/04 I Revised after comments from Project teams
Issue to Post Office Business
0.05 31/04/04 I Review for final sign off.
1.0 01/06/04 I Formally baselined
Version 1.0 Page 4/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
1.3. Change Process
Any changes to this issued version of this document will be made, controlled and
distributed by: -
Business Solutions
Post Office Ltd
80 Old Street
London
1.4 Changes in this Version
Version I Changes
0.1 e None, First draft template.
0.2 « Updates to sections 7 & 8 with all relevant swimlanes and process
descriptions.
0.3 « Assumptions & dependencies section 4.2
¢ Additional information in Information Flows in lieu of AIS’s section 9
¢ Additional Requirements for NRDS section 8.10
e Additional information relating to Management Information Sect 8.9
e Update to Non-functional requirements re R3/S80 Sect 10
0.4 ¢ Client Ledger requirements revised (S6.3)
e Foreign Exchange related requirements added (S6.7)
¢ Impact Stakeholder Forum Design Principles added (Appendix B)
¢ Transaction examples added (Appendix C)
0.5 e Updates following feedback from POL Business particularly to:
« Requirements
e Swimlanes and Process Descriptions.
Version 1.0 Page 5/141
© Post Office™ 2003
FUJ00090148
on requirements are as follows:
$4.2 — more clarity on treatment of legacy systems used for client data
capture.
$6.6.- more clarity on stock movement control
S6.7 — further foreign currency requirements
S6.8 — WCS:POL FS reference data requirement added
$7.1 — Foreign currency reporting added as an specific function
$10.4 — problem management requirements added
References to Yantra replaced by the WCS (Warehouse Control
System)
MI Requirements clarified:
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
1.0 e¢ Updated for comments provided with approval of V0.5 — those impacting
S 8.9.3- Requirements 1001, 1003, 1009, 1011, 1112, 1113,
1114, 1115 added to reconcile from Programme CD.
S 8.9.3 — Requirements 1005 and 1016 moved to POL FS with
reference: 173 and 174 respectively (KPIs and Rota Checking)
S 8.9.3 — Requirements 1101 and 1102 amended — P&L for Outlet
and Product
1.5 Key Contacts
Name
Position pions Sombeueae
Karen Hillsden
Business Process Architect
Chris Allen
Business Process Architect
Neil Fagan
Gareth Jenkins
Principle Solutions Architect
(Management Information)
Fujitsu Applications TDA
Peter Flood Prism Alliance Project Manager
Ray Jackson S60 Release Manager
Philip Godden Prism Alliance Application Lead i I
© Post Office™ 2003
Version 1.0 Page 6/141
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
1.6 Review Details
Review Comments to: Chris Allen — chris.p.allen@royalmail.co.uk
I Mandatory Review I Name _
Authority
Post Office Ltd:
Head of Technical Clive Read/Torstein Godeseth
Architecture
Head of Business
Architecture Paul Homan
Impact Programme
Manager Sue Harding
Technical Design Authority I Adrian Batt
Business Design Authority I Karen Hillsden, Chris Allen, David Parnell, Neil Fagan
Business Change Ann A Clarke, Sheena Patience, Ben Gildersleve,
Release Manager Graeme Seedall
Business Stakeholders Vicky Noble, Ruth Holleran, Martin Box, Debbie R Brown,
Alvin West, Jill Camplejohn, Richard Wardle
Fujitsu Project Manager _ Bill Reynolds
Fujitsu RASD Gareth Jenkins, Phil Boardman
Prism Alliance Project Tony Brain; Peter Flood
Manager
Prism SAP ADS Bob Cragg
Optional Review/Issued for Information
Version 1.0 Page 7/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
1.7 Associated Documents
Reference Ver’n Date Title
CR/CDE/006 3.4 Sept03 I E2E Programme Conceptual Design.
POL/E2E/DES/006 14 Jan 04 Automated Cash Bank Ledgers Conceptual
jesign
AIS Transaction 1.30 Feb 04 __ AIS for transaction corrections from POL Ledger to
Corrections 0.04 Horizon
AIS_BranchLedger 0.03 26/04/04 I AIS for Horizon to POL Ledgers
Entry R3 V0.03
PO Ltd IS Security approach
quest_retail_Prod Na 18/12/03 I Sizing document for SAP POL FS
R3_260204
VIISTR/064 1.0 15/08/03 I Testing Approach for The Horizon System
Settlement Process 05 Feb 04 __ Settlement Swimlanes v05.ppt
Design pack A442_001 IMPACT Finance Summarise sales and
calculate payment support.doc
A443_001 IMPACT Finance Calculated and settle
on estimated amounts.doc
A444_001 IMPACT Client Discrepancy.doc
A444_002 IMPACT Errors Identified by client.doc
A446_001 IMPACT Finance authorise and make
payments.doc
Debt Recovery 05 Feb Debt Recovery Swimlanes V05.ppt
POL Strategic Data POL Strategic Data Model
Model
AIS_R3_ADS to 0.01 April 04 AIS for interface between SAP ADS and POL FS,
POIFS_V0.1 and MIS.
POL FS to ESFS 0.02 Mar 04 __ AIS for the interface between POL FS and ESFS
Interface AIS V0.2
AIS_NRDS to POL FS 0.01 Mar04__ AIS for the Vendor Data interface between NRDS
Vendor Data Interface and POL FS
V0.1
AIS POL FS to NRDS 0.01 Mar04__ AIS for the GL Data interface between POL FS
GL Master Data and NRDS
Interface v0.1
NRDS to POL FS 0.01 Apro4 AIS for the Branch Hierarchy Data interface
Branch Hierarchies AIS between NRDS and POL FS
V0.1
NRDS to POL FS 0.02 Maro4 AIS for the Customer Data interface between
Customer Data NRDS and POL FS
Interface AIS V0.2
NRDS to POL FS 0.01 Mar 04 __ AIS for the Product Data interface between NRDS
Product Data Interface and POL FS
AIS V0.1
Version 1.0 Page 8/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
NRDS to POL FS Site 0.02 Apr 04 __ AIS for the Site Data interface between NRDS and
Data Interface AIS V0.2 POL FS
Unless a specific version is referred to above, reference should be made to the current version
1.8 Abbreviations/Definitions
Abbreviation I Definition
Agent An individual or company who does or has in the past been a sub-postmaster
under the normal PO Ltd agency agreements
AIS Application Interface Specification
Alc or alc Account - relating to either bank or general ledger as specified
BACS Bank Automated Clearing Service — form of payment to/from third parties
BCV Batch Control Voucher — used for batching cheques sent to EDS
BoE Bank of England
CBDB Counters Business Database
CLASS Client Ledgering & Settlement System (part of the CBDB)
Client Client is the corporation that is using the Post Office network as a route to
market for their services and products
CLS Cash Logistics and Security
COA Chart of Accounts
Customer Customer means the general public, (or occasionally companies), who use
service or buy products offered through the Post Office Network.
EPOSS Electronic Point of Sale Service
ESFS Royal Mail Group’s Enterprise Finance System
FAD Financial Accounts Division (FAD Code)
LFS Logistics Feeder Service
Horizon EPOSS Counter system
MIS Management Information System
MM Materials Management module of POL FS
NRDS New Reference Data System
NSF Notes Sorting Facility
NSSC National Secure Stock Centre, Hemel Hempstead
OLA Operational Level Agreement
ONCH Overnight Cash Holding
POL Post Office Ltd
POL FS Post Office Ltd Finance Systems — refers to the new SAP system to be built.
This includes cash & bank ledgers, AR, AP, stock module etc.
POL Ledgers I Cash & bank ledgers, as part of POL FS
Version 1.0 Page 9/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Product A service or stock item to be transacted with the public/ousiness in branch or
cash centre.
E.g.: MVL disc; A&L banking withdrawal, A&L banking deposit, US$ currency,
Euro Currency
S60 S60 Release of Horizon that fits with Release 1 of POL FS
$70 S70 Release of Horizon that fits with RDS and MI release
S80 S80 Release of Horizon that fits with Release 3 of Impact, and the POL FS
project
SAP ADS SAP Advanced Distribution System
SLA Service Level Agreement
REM's Remittances/movements of cash & stock between branches & cash
centres/NSSC;
STAMPS. Stock Transfer and Movements Planning System
TIS Technical Interface Specification
TPS Transaction Processing Service
Trading Date I The date a transaction occurs in either the branch or cash centre.
Trading Day I A trading day is defined for each branch as the trading period between each
day end process.
Transaction _I Instruction to Branch, Cash Centre or Client to correct some transaction data.
Correction (This replaces the Error Notice)
Type A Type A Reference data relates to reference data that is controlled in the
application systems and may be controlled via NRDS. Type A data is not hard
coded.
Type C Type C Reference data relates to hard coded reference data that will only be
changed through the change management system.
WCS Warehouse Control System that is being implemented in the NSSC. (Planned
Go live date June 2004)
Other generic IT terms can be looked up at: http://www.whatis.com/
Version 1.0 Page 10/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
2 Introduction
2.1 Purpose
The content of this document is intended to outline the requirements and process design
for the Deployment of the PO Ltd Financial Systems project. It is intended to act as a
reference for those involved in the various stages of design, development, deployment
and support for the PO Ltd Financial Systems project. It is also intended to support the
concurrence and approval process required for this system to be implemented.
This Conceptual Design will inform, and be updated by, the detailed system design and
build stage of POL FS. During this stage, more detailed analysis will be undertaken to
inform:
The build of POL FS to ensure accurate and timely product accounting, settlement
and reporting to clients;
The requirement for other systems to meet POL product or service related
requirements that cannot be met by the POL FS generic design (e.g. reporting to
clients of information not held in POLFS or Data Warehouse);
Specific reporting requirements; and
Migration plans and activity.
In support of the Detailed Design stage, POL's products and services will need to be
analysed in the context of the sales and stock reporting enhancements available as part
of the overall Impact Programme design. Business decisions will need to be taken so that
individual product offerings can be revised and proposed to clients that provide a
commercially balanced approach to ensuring:
Materially accurate product accounting, client settlement and achievement of
agreed client reporting commitments (as revised); and
Minimal overall cost of reporting and any product verification activity
2.2 Scope
The scope of Release 3 builds on all the requirements and functionality delivered during
Release 1. See Reference document.
The scope of this project is: -
Replacing the auditable financial ledgers of the Post Office Network of Branches, and Cash
and Stock centres currently provided by Class. These ledgers will also hold volumes of
transactions/stock where required.
This will include the following:
« Daily interface from SAP ADS to pick up all financial information from SAP ADS and
hence replacing the current weekly cash account.
« Daily interface files from Horizon that will supply the financial ledgers with branch
activity that has an impact on either financial or stock positions, and hence replace the
weekly cash account.
« Daily interface from WCS to pick up all stock movements to and from the NSSC, to
support control of stock movements and holdings within the POL Network. The
intention is to minimise manual stock reporting
Version 1.0 Page 11/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
2.2.1
* Daily interface from STAMPS (manual) /SAP ADS to pick up all Bureau Foreign
Exchange movements in Hemel Cash Centre.
e Periodic interface of Post Office Network financial results to RMG Financial Systems
(ESFS).
« Accounting for, reporting and settlement of client funds in line with contractual
agreements.
« Accounting for amounts to be recovered from current and former Agents and a tool for
effectively managing debt recovery.
« Changes to NRDS to provide reference data to POL FS, and control interfaces
between POL FS and other systems.
« Changes to MIS that are required due to the replacement of the legacy systems.
Exclusions
Amounts that relate to Business income or expense, or assets or liabilities are generally
excluded from these ledgers, and hence this project. Exceptions to this rule are where
these amounts are recorded at Branches on Horizon, or at the cash centre on SAP ADS,
or entered into POL FS due to contractual requirements.
2.3 Background
This document has been produced by Post Office Ltd with the assistance of Fujitsu
Services and Prism Alliance.
The overall IMPACT opportunity was assessed by Post Office, Fujitsu Services and Prism
Alliance as part of the 'Working Together' joint working initiative. This initiative comprises
part of the IMPACT programme and is intended to deliver new Financial Ledger
processes to enable a more accurate reflection of the results and position of Post Office
network.
2.4 Document Explanations
2.4.1
Business Process Models
Post Office's High Level functional requirements are represented in the form of IDEF
Process models using Business functions and information flows. The common tool used
for creating these Process Models is Popkin Systems Architect.
Detail Processes are represented in the form of Swimlanes, showing roles, business
process, information flows and relevant technologies. The tool used for creating
Swimlanes is IGRAFX.
Process Models and Detailed Processes are both show in sequence in section 7.
Version 1.0 Page 12/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
3 Overview
3.1 Business Proposition
The main business proposition is the replacement of CLASS financial Ledgers with more
effective and flexible financial ledgers.
The business drivers behind this are:
General Accounting:
¢ Rationalise systems in place to report client and business information.
Adopting standardised business processes around best practice
To report Business and Client information separately and accurately.
Alignment of management and accounting information
Accounting period alignment — branch currently Wednesday, business Sunday.
Improve timing, accuracy, granularity and summarisation levels.
Establish an appropriate and flexible accounting hierarchy
Performance measures of throughputs and the actual financial debt
Enable proper accounting of cash and stock
To increase accounting control of branches
Cash centre accounting is manual, weekly, therefore no through view from
transaction to settlement.
Client Settlement:
e Significant reduction of losses from remittances and client settlement. Cash
remittance errors will be significantly reduced with the introduction of automated
rems at S60. In the case of stock rems, S80 will provide more timely discrepancy
information, with facilities to enable any subsequent change to automated rems for
these items.
e Long term aim to account and settle on our data, not clients. It is envisaged that
the availability of more timely transaction data will provide benefits for both POL
and its clients to move to settlement based on daily transaction data. Any changes
to settlement arrangements will be made in consideration of the overall Business
benefit, through the involvement of appropriate Business stakeholders.
e Optimisation of cashflow
Exception Handling:
e Reducing resolution time and automating exception handling
¢ Identification of individual discrepancies
Debt Recovery
e Improved Debt Recovery (financial recovery of money), target 95% of debt incurred
e For 2005 the target is reduction of aged debt from 42 to 35 days
¢ Establish a central debt monitoring environment, for both business and transaction
debts, to enable the identification of debt with a high degree of accuracy.
¢ To modify the method of recovering debt by balance rather than each individual
item.
Stock Ledger
Version 1.0 Page 13/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
e Increased visibility of stock & foreign exchange in the network
* Increase accountability on Postmasters for stock leading to reduced losses
e Support future inventory management practice
3.2. Functional Summary
The following depicts the high level processes and information flows involving these
processes. See Section 7 for High Level Process Diagrams.
3.2.1 General Accounting
The General Ledger will show the balance sheet position of the PO Network. There will be
control accounts linked to the “Client” ledger, “Agent” ledger, and “Stock ledger’. These
control accounts will provide summarised real time information of activity controlled within
these integrated ledgers.
As well as these control accounts the General Ledger Balance Sheet will also show Inter
Company, and “suspense” accounts. There will also be a small element of P&L accounts
for items of Business income and expense that need to be recorded in POL FS.
All this is in addition to the Cash and Bank accounts from Release 1.
3.2.2 Client Ledger
The client ledger will record all activity by product settlement group, branch/cash centre
and trading date. This information will be interfaced from Horizon or SAP ADS as
appropriate.
The product settlement group is a group of client products that are settled under the same
contractual terms, and such that the client does not need additional analysis at time of
settlement.
Where settlement is based on estimated or client data this information will be entered into
the client ledger at an appropriate level of detail.
The client ledger will provide basic matching/comparison functionality between estimated
or client data, and actual data interfaced from Horizon. The ability to match data from
clients is limited to branch and trading day for each client product, subject to POL FS
recording daily summarised transactions by the individual product.
The client ledger will also provide control and management of the settlement process and
reconciliation (including transaction volumes) of contractual client documents such as
National Audit Office statements.
3.2.3. Agent Ledger
The Agent Ledger will provide a permanent account for each current and former PO
Agents including the ability to group branches under a single franchise or a multiple
contract.
Branch Transaction Corrections will be entered in the Agent ledger and interfaced to
Horizon for action by the Agent.
The Agent ledger will facilitate reporting and management of debt recovery from all
Agents.
Version 1.0 Page 14/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
3.2.4 Stock Recording and Accounting
Stock is recorded in Materials Management (MM) module of POL FS. Where stock has a
balance sheet value this value will also appear in the relevant stock control accounts in the
General ledger.
Most of the stock quantity activity will be interfaced from Horizon daily as part of the
financial activity in each branch. Stock activity incorporates remittances into and out of
branches, “sales”, and adjustments/write offs.
Activity of stock from NSSC, Hemel, will also be input into MM. It is planned that the new
WCS system will provide an electronic interface of this information. If this does not occur
then this information will be input manually as it is today.
Version 1.0 Page 15/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
3.3 Systems summary
The diagram below shows the IMPACT Release 3 system architecture
Representing Transaction Data Flows
Manageme
Infortha
Horizon Transactio
Manageme
NSS
(YANTRA)
Referenc
Dat
Version 1.0 Page 16/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Representing Reference Data Flows
3.4 Potential for Change
Significant design revisions could arise from any changes in the status of the dependencies
and assumptions dependencies listed in Section 4.2.
Version 1.0 Page 17/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
4 Constraints
The requirements throughout this document are generic to all suppliers unless stated
otherwise. Gaps in the requirement numbers represent requirements that have been
removed, and the numbering has been retained for clarity.
4.1 High Level Functional
Ref 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, Agent Ledger, Stock 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 with a stream of data from branches and
cash centres
FIH 004 The Cash and Bank account values, from ledger implemented in S60, will not be
overwritten with CLASS values at S80 implementation. A reconciliation will be
undertaken between POL FS and CLASS as part of cutover activities
4.2 Dependencies and Assumptions
Ref Description
ASS 001 I Supplementary document matching will not take place in POL FS and will largely be
stopped.
ASS 002 I Matching of client transaction data to POL FS data will not take place on POL FS.
This will take place in MI where necessary.
ASS 003 I Matching of client summary data to POL FS data will be done on a risk based
approach.
ASS 008 I Reporting of data to clients from POL FS will be at the maximum level of Branch,
Trading Day & Product.
ASS 004 I Reporting of transaction data to clients will not take place on POL FS. This
information will either be fed to clients directly (e.g. AP/Banking), or is available from
MI.
ASS 005 I Depending upon where it resides at the time of S80 implementation, Foreign
Exchange movements to/from cash centres will be received by POL FS either by an
automated feed from SAP ADS or by the manual input of output from STAMPS.
ASS 006 I Client managers will be involved in establishing revised product propositions in
response to changes being introduced by Impact. Legacy systems may need to be
retained if they provide non POL FS related services to clients that cannot be
managed away.
ASS 007 I It is assumed that an electronic feed of stock movements to/from the branch network
will be provided by the WCS System that should have replaced the STAMPS
System before S80 implementation.
ASS 009 I Dependency on Client Managers to ensure clients accept changes to client reporting
of POL data — in particular Girobank and NS&l.
4.3 Legal & Regulatory
Version 1.0 Page 18/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Req ID Description
_POFS 001 _I POL FS will be the auditable financial ledgers for Post Office Ltd Network.
4.4 Audit
I ReqiD I ———Ss—S———CCecription = Cis
POFS 002 I It shall be possible to audit movements within POL FS by branch back to
Horizon
POFS 003 I It shall be possible to reconcile movements within POL FS by cash centre
back to SAP ADS
POFS 004 I Technical requirement: to keep a copy of all bulk data files exchanged
between Horizon domain and Prism domain. The data should be the raw
(unprocessed) data.
POFS 005 I Technical requirement: audit records of user activity within the SAP
application should be created by standard SAP functions.
POFS 006 I Technical requirement: audit records of support activity on the POL FS
host platforms should be created by standard Horizon functions and then
stored in line with current Horizon practices
4.5 Architectural Framework & Building Blocks
4.5.1 Integration with Other Systems
Ref Requirement Description
TEC 023 Integration with SAP ADS
TEC 025 Integration with ES-FS
TEC 025a Integration with Horizon
TEC 026 Integration with NRDS
TEC 027 Integration with WCS
TEC 028 Interface with Girobank
TEC 029 Interface with DNS
TEC 030 Interface with NS&l
TEC 031 Interface with BACS
See section 9 for details on information flows
4.5.2 Post Office™ Strategic Direction
Ref Requirement Description
TEC 001 I 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
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
Version 1.0 Page 19/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
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
4.5.3 Post Office™ Approved Technology
4.5.4 Not applicable Post Office™ Approved Components
Not applicable
4.6 Supplier
4.6.1 Fujitsu Services / PRISM Alliance
__ReqID ee Description
POFS 007 The POL ledgers will be built in addition to and independent of other SAP
systems.
Version 1.0 Page 20/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
5 Design Principles
5.1 Programme:
Solutions are to be developed in accordance with the design principles established by the Impact Stakeholder
Forum, as shown at Appendix B
Ref Requirement Description
ACM 001 I Any individual component of the programme must conform to the POL Strategic
Data Model
5.2 Project:
Req ID Description
1. The intention is to set reasonable service level targets, with reasonable compensation for
failure to meet the service. (The definition of reasonable will be determined during the
contractual negotiations)
2. The new POL FS system should (wherever possible) fit in with existing processes and
management systems.
3. The SAP installation should be a "vanilla" installation, except for the bespoke interfaces
required to load data from Horizon and SAP ADS.
Version 1.0 Page 21/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
6 Functional Requirements
6.1 General
Ref Requirement Description
Fl 021 Monitoring of system rejections to ensure that data is resent and processed or
accepted successfully
FI 022 System Management controls e.g. access levels, user ID’s, passwords etc.
Fl 023 Ability to monitor interfaces received and processed or rejected, and extracts
produced including reconciliation of file interfaces across systems. Where rejections
occur, error messages should be produced, indicating reason, to aid investigation.
Fl024 The capability to action discrepancies identified by the DRS process.
6.2 General Accounting
Ref Programme Requirement Description
FI015 To produce a set of auditable accounts within the framework of the Chart of
Accounts specified
FI016 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)
Fl018 To consolidate information from SAP ADS financials to report the POL accounts
FL019 To account for business transactions which will populate the trading ledger
Fl020 To have visibility of branch transactions by day (this will cover the Branch Ledger)
6.3 Client Ledger
CSH 001 I To implement a client ledger that accurately identifies PO Ltd’s liability to and from
clients and enables accurate, auditable, and timely settlement in accordance with
contractual requirements.
CSH 002 I To receive a daily interface of summarised transaction data, from Horizon, by client
or product.
CSH 005 I To calculate, pay / receive and account for Client settlements based on the
contractual data stream, being any combination of:
¢ Horizon
SAP ADS (e.g. Corporate deposits)
Client data (e.g. Camelot)
Other existing contractual stream (e.g. BBC non bar coded licences)
Stock adjustments from NSSC
CSH 006 _I To pay / receive settlements based on estimates and / or including standing deposits
CSH 007 _I Settlement facility to be available by 7:30 am in support of client settlement terms
CSH 003 I To refer to information about transactions from clients in order to resolve any
disputed items and determine true liability. Summary available from POL/FS detail
from Data Warehouse
Version 1.0 Page 22/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
CSH 004 I To receive a daily interface of summarised transaction data, from SAP/ADS, by
client or product.
Programme Requirement Description
CS 001 A daily view of summarised balance (value and volume) by client, by product, by
branch or cash centre, and by day.
CS 002 Ability to split client balances, when a client has several products or contracts with
different terms of payment, in order to map into different sub accounts in the ledger.
CS 003 The ability for each trading day to have a unique document entry
CS 004 The ability for non-polled offices transaction data, once received, to be:
¢ Accounted for in the current accounting period based on posting date
e Recorded against the appropriate trading dates
¢ Settled to clients based on trading date
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. These reports will not be on POL FS.
CS 007 A mechanism to be able to trace disputed totals back to transaction level, on MIS, in
order to resolve and correct information at the appropriate point to amend ledgers,
and reporting or management information.
Cs 009 Ability to compare the values of settlement made based on client against actual data
from Horizon for the equivalent period. POL FS will enable comparison at a daily
branch and product level for all such clients. There will be the ability to perform
detailed transaction comparison but this will not be on POL FS.
cs 015 The ability to adjust settlement and account for discrepancies identified from:
Client invoices or data mismatches with Horizon transactions
Transaction Corrections (covering customer, supplier and branch queries)
Banks (unpaid cheques & Data Reconciliation Service adjustments)
.
.
.
e Estimating differences
CS 010 The ability to provide a generic solution for the main proportion of clients and only
build exception processes when necessary
CS 016 Settlement process, to include adequate control procedures, and to pay amounts
due in accordance with clients individual settlement terms
cs 011 To be able to settle (pay and receive) by contractually required methods of payment:
« BACS
« CHAPS
° «Swift
e Cheque
¢ Direct Debit (payment receipt only)
CS 012 I The ability to track payments made on estimates to compare actual to estimates, via
a holding account or similar solution for client related data.
CS 017 The ability to amend settlement for non core charges such as commission and
interest charges and account for these accordingly.
CS 013 I The ability to provide client reports based on summary volume and value for each
defined product.
CS 014 The ability to provide contractual client reporting. This may be achieved by a mixture
of POL/FS and Data Warehouse reporting.
CS018 I To be able to determine the amount due to a client using payment terms agreed with
client
Version 1.0 Page 23/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
CS019 I To enable payments to/from clients with functionality for matching and closing paid
items to leave open items for management of debtors/creditors
6.4 Debt Recovery
Ref Requirement Description
DRH 001 I To implement a debtor's ledger (accounts receivable), which accurately identifies
amounts owed to PO Ltd 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 To receive, as part of the Horizon daily interface, details of debt recovery items and
results of debt recovery action e.g. cash receipts by debtor from the POL ledger
entries.
DRH 003 I To be able to record debt recovery plan decisions, and action taken so as to
manage debt recovery and document stages of escalation taken.
DRH 004 I To be able to refer to information about transactions both in MIS and directly entered
trading transactions with debtors, in order to resolve any disputed items and
determine true amount recoverable
NB If amounts owed to the PO but still under investigation are recorded outside of
the debtors ledger but within the Transaction Correction area of POL FS, to be able
to manage these as if they were on the debtors ledger i.e.
e to accurately identity to branch,
« to know which date they relate to and therefore which agent and the time
outstanding i.e. age,
¢ to refer to information for investigation purposes and
e to record action taken by individual operator
DRH 005 I To be able to generate identified transaction errors, to be fed back electronically to
Horizon, if, as a result of investigation, debts need to be transferred and corrected
within a branch liability statement.
DRH 006 To be 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 debt items e.g. 30 days for
counter transaction errors, 45 days for loans to SPMs
DRH 008 To be able to assign different agents/branches to a central “head office” payment
point in the instance of multiples who require their own central authorisation for
settlement to POL.
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 debt (or suspense items) so as to manage over due items.
Version 1.0 Page 24/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
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, and may this
may be reported on. The information will come from NRDS.
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, and may this may
be reported on.
DR 006 To be able to produce debt recovery reporting such as —
Debt Recovery Case Management By branch, by branch type, by Agent name, by
product (by client), by age of debt
High value debt (e.g. all outstanding debt which exceeds a defined limit, by branch)
Debt Recovery repeat offenders (problem offices)
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
Former Subpostmasters accounts held including Branch, Agent name, Age of debt,
Dispute details, Losses (write off)
Disputed debt by branch, by client (e.g. Giro)
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
DR 007 Ability to search on a particular field (ie. Agent name) and be able to track status,
audit log entries
DR 008 Ability to produce invoices for transaction corrections to be sent to central “head
office” for multiples in order for central settlement
DR 009 Ability to record details against individual exception (Debt Recovery Case
Management) to track progress through investigation and towards resolution.
Freeform text field plus CACM operator details, time and date stamp for audit
requirements. Measurement against agreed timescales.
DR 010 Ability to record Agent’s debt from:
¢ Actioned Transaction Corrections — automated from Horizon interface
¢ Other debts as identified - manually entered
DR O11 Ability to record reductions in debt on agent's account based on:
e« Payment by Credit Card
« Deductions from payroll
DR 012 To be able to produce correspondence to chase outstanding items e.g. statements,
reminder letters.
DR 013 To provide information of aged balances
6.5 Cash Centre Management
Ref
Requirement Description
CHH 001
SAP/ADS to make available, by cash centre, to the POL Financial System the daily end
of day cash position for entry into the cash ledger (Release 1)
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 (Release 1)
Version 1.0 Page 25/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
CHH 003 I SAP/ADS to make available, by cash centre, to the POL Financial System the
summarised daily client related transactions, (value and volume), by client for entry into
the client ledger
CHH 004 I SAP/ADS to undertake the summarisation of required data, to an agreed level, prior to
entry into the cash and client ledgers.
CHH 005 I The interface will provide all transactions which affect cash and near cash values of the
cash centre. For example: -
Inward and Outward to POL
Inward and Outward to FI’s
Inward and Outward to Customers/Clients
Inward and Outward to 3 Party
Cash centre adjustments
Cash centre discrepancies
Cheque remittances
Cheques on hand
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:30 the following day
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.
The Trading Statement is being developed independently of POL FS by CL&S.
6.6 Stock Recording & Accounting
Ref High Level Requirement Description
SRH 001 I To provide end to end visibility of the stock movements from point of entry (whether
direct to branch or via the National Secure Stock Centre) until sale, loss or return.
SRH 002 I POL FS MM module to accept a daily interface of stock sales in order to maintain
accurate link between stock movements and stock sales.
SRH 003 I POL FS MM module to accept a daily interface of stock adjustments at the
branches, from stock declaration process.
SRH 007 I POL FS will provide a way of reporting stock remittance discrepancies (i.e. volumes
rem'd out to volumes notified as received), that supports their easy identification for
fesolution purposes
SRH 004 I To provide an interface of stock at National Secure Stock Centre, identifying stock
discrepancies, for recording to POL FS MM module.
Version 1.0 Page 26/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
SRH 005 I To provide auditable balances of stock throughout the network for probity and audit
purposes
SRH 006 I Provide a means of controlling holdings and movements of stocks that have an
intrinsic value (both POL and client owned) without adding additional complexity to
operational procedures.
Ref Programme Requirement Description
SR 001 The Horizon system to make available to the POL FS MM module details of
identified stock discrepancies by volume, and value, (where relevant).
SR 002 The Horizon system to make available to the POL FS MM module the daily
movements of stock into and out of branches by volume. 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 POL FS MM module the daily sales of stock.
SR 004 The National Secure Stock Centre to interface identified stock discrepancies by
volume, and value (where relevant) in order to identify stock adjustments in the POL
FS MM module.
SR 005 The National Secure Stock Centre to make available to the POL FS MM module 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 POL FS MM module to hold information by stock type in order to inform POL FS
of all balance sheet impacts.
SR 007 POL FS MM module to hold value of all stock, which has a balance sheet impact, by
stock item.
6.7 Foreign Exchange
Ref Programme Requirement Description
BDC 001 I Individual calculated stock values to be held on POL FS by Branch, on Day B:
¢ Day A's individual currency value (quantity, e.g. $500) — these can be up to
14 characters long; and
e Day A's Sterling equivalent value (e.g. £250) at Day A Spot Rate. POL
Finance and Audit will approve the solution for achieving this.
The daily movement in foreign currency held by individual currency will be received
as part of the daily interface from Horizon.
BDC 002 I Stock quantities (e.g. $300) of Travellers cheques, by currency and branch to be
held within POL FS in MM module (not valued)
BDC 003 I Margins and Commissions on transactions (Sell and Buy) are to be posted to an
appropriate settlement account for the Bureau Joint Venture.
BDC 004 I Stock revaluations to be recorded separately in POL FS.
BDC 008 I Stock adjustments to be recorded separately in POL FS.
BDC 005 I Currency transfers between the Cash Centre Network and the Client are to be
included within the POL FS Balance Sheet, with postings to a Client Settlement
Account where appropriate.
Version 1.0 Page 27/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
BDC 006 I Management information in support of individual inventory management capability
will be available within POL FS (e.g. stock : sales ratios by Branch; stock holdings by
branch or branch hierarchy)
BDC 007 I POL FS reporting capability to be accessible within the Cash Centre Network.
BDC 009 I Currency return movements from the NSSC to First Rate will be used to adjust
settlement to this Client.
BDC 010 I To support the future inventory management of foreign currency, individual branch
holdings of individual foreign currencies will be able to be provided to SAPADS on a
daily interface. If constraints, this could be for selected currencies (e.g. Dollar and
Euro) and/or branches.
6.8 New Reference Data System
Ref Project Requirement Description
NRDS NRDS to provide reference data shared by multiple systems to POL FS
001
NRDS NRDS to accept reference data mastered in POL FS that is required for interface
002 data mapping
NRDS. NRDS to provide a data mapping facility to enable interfaces between significant
003 systems to be controlled using reference data rather than hard coding
NRDS NRDS interface to Horizon to be enhanced with various data objects including
004 interface data mapping logic.
NRDS A process will be developed to ensure that WCS and POL FS reference data are
005 consistent or comprehensively mapped in support of the complete interface of stock
movements.
Version 1.0 Page 28/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7 Process Models
Process models are broken into two types:
High Level: Defined using IDEF showing the existence of particular process activities
Detailed: Defined using Swimlanes process diagrams showing the breakdown of activities by role
and technologies. Descriptions of each swimlane process are provided in section 8, and these
should be read together.
This section is aimed at several audiences:
Supplier project teams: To ensure understanding of the design requirements
Post Office Change Management: To assist understanding of new processes and potential for
organisation changes
Post Office Business: To ensure understanding of new business processes.
To help understanding of these diagrams, some transaction examples are shown at Appendix C.
Version 1.0 Page 29/141
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL FS
POL/IMPACT/DES/R3029
Product Marketing Knduledge
ner Fuitumenth
Cash Usages Thrfigh Transactions
pening Gash $7 Cash
I
AS
Cash Receips. Management:
AS
_— eT TS
case ears
‘Cash Despatched to Financial instivigns
[Management Report
I___Non-Conformance Reports _y,
I _ Foreign currency Reporting ig.
I__eoreign Currency Reporting __
7.1 Post Office Processes in Scope
Provide I
pr
[Reference Daig Stock Revaluation Informatiot I
I Management 5
I 1 Tasos tansacions 7h MR nearness
7a "agate [sed Tamanho»
Reference Data & Businebs Rules Transaction Documentation, ee ae
Coaaues racessad [cen Transaction Data Regt
_———Sireamiline Settlements _», I__Branch Liability Statemeng,
— Tranafcten Dacamenni Branch Closure Notice I__Payment Request to Client,
Fipiry Reasonse/Ater Sales Enonipy ——Gieent Authorisations I__Identifed Transaction Errogs
A [ arest Reno
rd —___seartoronents [casing anatis
Mandatory Data _»
I srenchcarh Heng (—"aatngForcasia
I___ Seasonal Data,
eee Cah Bes Eoecani—S ea
‘Management supplier Orders Aa
eee Remaceentsaae —*) siunect Ais >
Forecast Performance Repgfts
Version 1.0
© Post Office™ 2003
Page 30/141
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.2 A4- Accounts and Settlement
—
ga oe Vasa aes
Version 1.0
© Post Office™ 2003
FUJ00090148
FUJ00090148
Page 31/141
comntamoanent
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3 A442 Summarise Client Data
Version 1.0 Page 32/141
© Post Office™ 2003
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
A442 Summarise Client Data
Client 442010: Sena
442021: Notify
442020; Genurte 442020; Baw Cline ro
Settlement ed eh ee Duta hto Chiat authorise &
Duty Owner Imation, con Hoing Accomt a7
=
442040; Load Detail Frm
Transaction edermation (neo ne rain Dupe
Processing Clerk Discrepancy Database Cle. axpmey
Discs
o i
be
Various
Role 2
Role 1
© Xansa 2002
Version 1.0 Page 33/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.1 A443 Calculate Estimated Settlement to Clients
Version 1.0 Page 34/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
A443 Calculate Estimated Amounts For Settlement
6:
“Neutotioel 442020; Use Load e200; concise g] 442050:cataase I_I 142060: cat ‘waoe0:Diccws ma] I 443000: mer Aged toe
Settlement orase Fenreted ‘onsol Agree Settlement Settlement eto Client Account for
Duty. Cwmer I Butane Business Knowledge Eximate Ieornation [PI Settmere Bomar [I ofRemmated Seclemee a hes M
T =
:2EDI
443020: Prowite
Sales & Marketing e€ Product Change
SEDI]
443070; Dicure md
Client Agree Settlement
Amowe
Role 3
Role 2
Role 1
© Xansa 2002
Version 1.0
© Post Office™ 2003
Page 35/141
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.2 A444 Discrepancy Process -— Errors identified by Client
Version 1.0 Page 36/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
A444 - Errors Identified By Client
446110: Receire 444130; Moech Eran 444230: Check 444240: Lowe a hare
Client Paperwotk ‘hfeemation against senso: wewity II Set Bro 8) I gagros pane I MA Mn Br I pa weak Rescue Chin Bor Notice
Weeky/Daily ‘Wek Daily Discepanciee Sepparting Settlanet values Presta #Disaxpancy yee Discrepancy
Agareeuts Dats Aggwote Dat Pocmerition jpomertation Comet dn Ber
* = =
444151 1k
Settlement Foe ye
Duty Owner (Phare Appopite)
/
P
44200; Send
s4195:3008
Exceptions Handling Summary Exons to Paperwork Back To
Clie - Brot Not
Team Chine Thocmes
XY T =
446100: Sena
Branch P Daly M6
s44120:Send pa
Role emote ass
1 Boe ;
Role I
© Xansa 2002
Version 1.0 Page 37/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.3 A444 Exceptions Handling - Compare Settlement Data With Transaction Data
Version 1.0 Page 38/141
© Post Office™ 2003
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
A444 - Compare Settlement Data With Transaction Data
cc
444030: Review 0 444040: Cary Ot 050: Re
Exceptions Handling Holding Accowe (at Tolennce Checks Oe ee
Product Team. ‘usinwss Total Level) ‘Businwss Total Level) seepanicy
Client
Branch LL
Debt Recovery
Role 2 a4 M46 453-8654 483 a5
Role 1
© Xansa 2002
Version 1.0 Page 39/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.4 A445 - Resolve Exceptions
Version 1.0 Page 40/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
A445 - Resolve Exceptions
445002: Renn
Disrepmcy
Branch aad
Bror Wdatified By
Ermch
4
I
ssceptions [acs fof steht [evo sae dwsomsirioe Ig} tsomcenete I J aasro:mentac I I asoocaaax I gf {st5:sane Taatin
Reception he a Beqtin tar Degman I I new Beeetet extn cance
Exceptions Handling
Team Leader
ANS EH.
oD
=o
445056: Cemry Out
Periodic Review of ‘tens Write OF
Adjustmants Dueto
Beeptions
445000: Renn
Cash Centre Discrepancy Metitied
By Cach Caare
Role 2
Role 1
version tu
© Post Office™ 2003
© Xansa 2002
Faye +1141
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Version 1.0 Page 42/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.5 A445 Transaction Corrections (Singletons/Franchises)
Version 1.0 Page 43/141
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL FS
POL/IMPACT/DES/R3029
A445 - Transaction Corrections (Singletons / Franchised)
Muttiptes
Branch
$i uy 0
SOE EOE LF seasrunte or
Exceptions Handling aaa ive be
Team Leader “ 7 *
B h 4s090: Receive sto Pi be 445095: Discuss 445120: Accept 445121; Make Good 445125: Accept But
- —! oa su meet I I gots cre
Tete e sina Comections ‘Trnsaction Correction} Correction. Collection
Exceptions I Resolve ese Rei Le Tresecion Canctnts ooabe Gass
pl Beare re aie a meine onI I acerca
ay y
Debt
Recovery
Role 1
Version 1.0
© Post Office™ 2003
© Xansa 2002
Page 44/141
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.6 A445 Transaction Corrections (Multiples)
Version 1.0 Page 45/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
A445 - Transaction Corrections (Multiples)
44510: Diguee
asics I [ s4s02s-Dieus 45125: Act
Multiples Trees cen en I I mete com
Multi nea sng sr ca
45056 omy 0
Pawai teteeet Ig] 45057-veae or
Exceptions Handting I yyy eve od
Team Leader Deetions
14510: igs ons
L 443002; Ain ‘pwewtin
Nominee ee ce (Fire Te seca Treexcien
Ondy)
=—s
ts = =I = az
445110: Review
Disputed Traction I ),]445001: Issue Mukiple
Coarection (& Obtain. Sokmuatsoice
‘More Bridexce)
Let! OO
Debt Debt
Recovery Reconey
a
Role 1 Resolve
Beepticne
© Xansa 2002
Version 1.0 Page 46/141
445055: Adjust 445000: Raise 445085: Rewiewr
Ledger Pending Trneaction
Review ‘Comection, Conections
>
Exceptions pom
Handling Beans
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.7 A445 Transaction Corrections (Directly Managed Branches)
Version 1.0 Page 47/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
A445 - Transaction Corrections (Directly Managed Branches)
Muttiples
Branch
Exceptions Handling ase “Adjustments Dur to ‘Exceptions (to P & L)
Team Leader ‘Brceptions
Branch ‘Tasution Trans:
Comection ‘Comections Banonction ComncticnI
a =a 2 ald
; i
Exceptions I _Recie ‘4:0: traits He Peng Davwcsn xxi
Handling Brceptions ‘tions Review Correction. Comections
Debt
Recovery
Central Finance
Version 1.0
© Post Office™ 2003
Page 48/141
© Xansa 2002
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.3.8 A446 Authorise, Make & Account for Payments
Version 1.0 Page 49/141
© Post Office™ 2003
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
A446 Authorise, Make & Account for Payments
n
Baeptions
Hmdlmg Clie
fre Dis
3
Estimated
Settlements
FUJ00090148
FUJ00090148
7
Summarised 2
Cliera Data 446010 446020: Raise
Settlement Commission Details Paymat Proposal
Duty Owner ‘nao Clint Ledger
446025: Review, 446030: Cary Our 446070: Di 446080; Adjust
Team Leader and Suthoriee Detailed Contract. ‘seuss Amounes Aster
lier Semding Data Checks Amore Disoussicne
4 +
Manager 446050: Cry Out Top] 446060: Discuss 446090: Approve
Bi Level Checks Due ‘Payment
46095: Receive Detail
Cashier o¢ Paring Required eee
(By Payment Method)
2
44460980; leew
Payment ‘worn pamerie Ig} Hotr7 SionB Se pate nies
Authorisers “mee Clierte
i Lys.
BacsI
Role 1
© Xansa 2002
Version 1.0 Page 50/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Version 1.0 Page 51/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.4 A45 Client Settlement from Client
The High level process shown here reflects current practice relating to Pre-funding from DWP / Inland Revenue.
identify
Settlement __I_ Settlement Terms
Terms
‘Adjustments to Future Settlements
1 I
Estimaie and —
fate Anatett UStistivel Payment Request to the Gent
Due fom Clients I Payment tam I Payment Request he he
is Persia]
Arana Updated Ledger Enty Information
‘Amounts in Bank Account Received
Poe eanpae Sa
Data with Tan Data
Client Ledger Adjustments
tank statements _____p I "Recened Cent Summary Revon . I
Aerteston Settlement Discrepencies
‘Aetvies)
Ledger Entry information wet Debt Recovery items
Resove
Discrepancies
I ——Taentiied Transaction Evors SSS
Finance
Version 1.0 Page 52/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.4.1 A453 — A454 Settlement from Client (Personal Banking)
Version 1.0 Page 53/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL FS
POL/IMPACT/DES/R3029
A453 - A454 Settlement From Client (Personal Banking)
I
Client 452030: Pay Amowne 453070: Roestignte ‘foe: Aaa
Dus (Day Bam.) Difirance (Day Bpm) Required (Day Bpm.)
453100: Monch & Cle
Settlement 452010: Pamet I eee pus (Der 453060: Rmestignte 433090: Record Chie Ledger hems ate
Clerk ‘Receipt Fall Due am) Ditherence (Day Bp m.) Receipt (Day Bpm.) ‘Where Amounts Agree Discrepancy
(DayBpm) Process
=I 4a a 1
4453050: Report
Cashier $52040: Compe Discrepancy if Amoune I
creraahl Due & Paid Dikret
(Day Bam)
/
Various
Role
Role 1
© Xansa 2002
Version 1.0 Page 54/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.5 A46 Verification
Only two areas of this functionality exist in the back office
‘Transaction Data
Range Checks Business Rules
‘Transaction Data
‘Set Criteria
Ledger Entry Information
Vouchers Despatched
Checks
Rota Checks dusiness Rules
Rota Checks ‘Sufrmary Level Discrepencies
Activity Exception Reports
Transaction’
‘Actiity Level
Customer & Branch Enquiries
Tinvestigate
Transaction
Data
Discrepencies
Checks
cheque
* Vertication
Cheques Processed
“Rutomated
Transaction Data Reconeiliation
Glient Authorsations
i
Version 1.0 Page 55/141
© Post Office™ 2003
Identified Transaction Errors
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Version 1.0 Page 56/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
7.5.1 A466 Exception Identified by Client or Customer
A466 - Exceptions Identified By Client or Customer
{ 466010: Check
A445: Reco
Exceptions Handling Tridence I =I Discrepanciee
4
¥
T !
>
66001: aeety 466003; Sen
Client Baception Bridance
J
7
466002: aeessy 466004; Sent
Customer a Ditaee
/
Branch
Role 2
Role 1
© Xansa 2002
Version 1.0 Page 57/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.6 A47 Debt Recovery
Agent Creat story tomaton
Dest Proviteing Busnes Rules
> REE at
Deot Recover ome Tonbeot” I Dent Recovery Pan ie, Del Lager Enron
‘ores beste
SSNS arena
ey
. ee
lk Seed eae
7
- panty sented Transaction Efors
fcncel ate ‘Debt Recovery Amounts Through Payroll
cau lea red
i
poe
carne ber
ee
tod et nee Bann hn =
santo
Version 1.0 Page 58/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Version 1.0 Page 59/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.6.1 A47 Debt Recovery (Deduction From Remuneration) 1/3
Version 1.0 Page 60/141
© Post Office™ 2003
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
A47 - Debt Recovery (Deduction From Remuneration) - Page 1 of 3
470010: Review Agee
‘A470000:Debe ‘Debt History & 470030; Kus 470060: Agree 470100; Aaringe
DebtRecoveryI 3\’wavae ee Sete of Collection Method, Deductin Prom
Section re Accomt sexes and Be Remmention
Retail Line $0045: Receive 470090: Assess
Statement Deals Brmch
Manager Viability
— f
470050: Agree
470040: Races ro Collection. —!
Branch . s, .
Page Requncy
t t
M45.
Exceptions
Handling
M5
mein,
70110: Netty
HR Dedutin From
Rasnuntion
Nominee
© Xansa 2002
Version 1.0
© Post Office™ 2003
Page 61/141
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.6.2 A47 Debt Recovery (Repayment by Card or BACS) 2/3
Version 1.0 Page 62/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
A47 - Debt Recovery (Repayment via Debit / Credit Card or BACS) - Page 2 of 3
r
470163: Pamet
470160: Tike Pomme 470120: Adjust Aga] 470170: Conte,
cerey Deel win Seems Ledger Cleared Ba Prymert Made
fl a =
470165: Receive
Retail Line Notification of
Manager Pema Made
470195: Receive
‘70040: Raceine I [470130:Pay ia cea
Branch La: Dey Wa iter Condition
Somes cfPaymat Made
J
Exceptions
Handling
HR
470175: Recene
Nominee = 470130: Pay Via Ce er031- Pap ma Bacs 470132 Nouiy DOL. of
or Debit Curd
Comections
Paymat By BACS
i
Version 1.0
© Post Office™ 2003
Page 63/141
FUJ00090148
FUJ00090148
FUJ00090148
FUJ00090148
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.6.3 A47 Debt Recovery (Deferment) 3/3
Version 1.0 Page 64/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
A47 - Debt Recovery (Deferment)- Page 3 of 3
c
470180: Conan.
470095: Pte OF
Postmaster YNo 470210: Record arom: Mouty RLM Ig] 470230:senaDee
Debt Recovery Responseto Issued Defament of Defers, ‘Bridence to RLM Unaecowersble Debt
Section ‘Statement. Amounts
L 470090: Assess 470091: Assess
Retail Line I Brinch Viability Contract ContiraticnI
Manager
470060: Agee
Branch 470040: Racene 70081 470190: Diseus 470200; Plea colton tated,
Sumas Sumas Dede Hattip A in a
Exceptions
Handling
470093: Autborse
Head of Area 470092: Rese Det tier Dae
‘Anointe
aT ‘aT
Role t I Page 2
© Xansa 2002
© Post Office™ 2003
Version 1.0
Page 65/141
FUJ00090148
FUJ00090148
© Post Office™ 2003
Investments & Bowowings _
Version 1.0
Page 66/141
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
7.7 A48 - Produce POL Ledger
Produce Grant
Ledger Eny infomation Ledger
1 edt information
“Trading Transactons
Predvee Frode Worl econcle7
Produce Branch Personal POL Business Ledger (ES-FS) Ledger Nominal Ledger_ Consolidate / POL Business Ledger (ES-FS)
edger Branch Ledger Aen Ledger Review and Reper
3 3 10
mae Branch Debt Recovery ems
Discrepancies —p) Listy [neve Nery
“Been Gosue Notcey] ManapeMet I dened Transacton Eons
4
ro
Bark Statoments__ peace Cah
& Bank Leoger
cheques Processes [21 )
‘Streamline Settlements Aa85
Prades
ushess Tradng
Ledger
c)
Investments & Borovings Peace
Borrowings and
tederI
Produae Stock
J
France
FUJ00090148
FUJ00090148
COMMERCIAL IN CONFIDENCE
Conceptual Design
Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
7.7.1 A484 Branch Lial
Branch Ledger
ity Management
Investigate
Identified Transaction Errors.
FUJ00090148
FUJ00090148
‘Suspense Items
Debt Recovery tems
Branch Closure Notice
Branch Closure Notice I
© Post Office™ 2003
"I 1
Debt Recovery tens
investigate Debt Recovery Items
Discrepencies
Discropencios Identified Transact Errors
2
Tnvesigaie Unusual
(Guside Norms)
Giioccrbranch I Debt Recovery tems
Tiabity
3
Branch closing Josing Branch Suspense ter
arch sing I_Cosing Branch Suspense hems
Debt Recovery ems
4
Version 1.0 Page 67/141
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Conceptual Design
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
8 Business Processes
8.1 A3 Stock Management
POL FS is a recording and accounting system for stock management that occurs on systems
outside POL FS.
The NSSC is currently going through a project implementing a stock warehouse system called
Yantra. The associated Warehouse Control System (WCS) will provide information on stock
movements to/from the NSSC and holdings at the NSSC.
Stock at Branches is controlled on Horizon.
POL FS will receive stock receipt, despatch and write off information from WCS. The assumption
is that there will be a daily electronic feed of cash centre stock movements from WCS.
If the
electronic feed out of WCS is not developed then this information will be entered into POL FS
manually.
All stock information from Horizon will be passed in the Summarised Branch Data process below.
8.2 A43 Summarise Transaction Data
8.2.1. Summarised Branch Data
The process feeding into POL Ledgers is by a daily interface from Horizon.
The data for each Branch may provide the following components subject to branch activity:
Summary Movements in:
Branch Transaction
POL FS Account/Record
(all by branch)
Subsequent Action on POL
FS
Cash in hand
¢ To Cash in hand
e None
Cheques in hand
¢ To Cheques in hand
« None
Remittance out of Cheques
¢ To Cheques in transit
« Match to data from EDS
Payment by cards
¢ To Cards for clearing
« Match to Bank Statement
Forex in hand
« To Foreign Exchange in
hand by currency
« None
Forex revaluations
¢ To Foreign Exchange
revaluations
« None
Client product/service
transactions with customers
including quantity and value,
when value can be £zero
(and quantity 1) as distinct from
an item which is not recorded
e.g. blank form
¢ To Client ledger
¢ To MM Stock by product
where relevant
Settlement Process
« None
Remittances in and out of Stock
¢ To Stock accounts (if
balance sheet stock)
¢ To MM Stock by product
« Match to value from NSSC.
« Match to Quantity from
NSSC
Adjustments to stock & Foreign I ¢ To Stock accounts (if « None
Exchange (from stock balance sheet stock)
declaration process) ¢ To MM Stock by product * None
Sundry costs & revenue ¢ Appropriate sundry « None
incurred by branch
revenue and cost accounts
Version 1.0
© Post Office™ 2003
Page 68/141
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
NB: Subsequent actions do not include reporting of information, which is implicit.
Individual Transactions for:
Branch Transaction POL FS Account/Record (all I Subsequent Actions on
by branch) POL FS
Remittances in and out of ¢ To Cash in Transit « Match to data from Cash
Cash Centre/ADS
Remittances in and out of ¢ To Stock accounts (if balance I Match to value from
Foreign Currency — by sheet stock) STAMPS/ADS.
individual currency — volume
and value
¢ To MM Stock by product
« Match to Quantity from
STAMPS/ADS
Discrepancies put into or ¢ To Discrepancies (may be a_ I e Exception Handling
removed from Suspense subset of the Agents ledger) process
Remittance Discrepancies ¢ To Remittance Discrepancies I « Remittance Discrepancy
put into or removed from process
Suspense
Transaction corrections
actioned or rejected
To Agents ledger
« Exception Handling
process
Recoveries relating to
Transaction Corrections
« To Agents ledger
« Debt recovery process
8.2.2 Summarised Cash Centre/ Forex Transactions
The Cash Centre Transactions will be interfaced daily from SAP ADS.
Any Foreign Exchange transactions recorded on SAP ADS will also be interfaced.
The data for each Cash Centre may provide the following components subject to activity in each
cash centre
Summary Movements in:
Cash Centre
Transaction
POL FS Accounting all by
cash centre
Subsequent Action on POL FS
Cash in hand To Cash in hand None
movements
Receipt of Cheques To Cheques in hand None
from clients
Giro Bank a/c To Joint stock bank a/cs Need to contra off the
movements funding/defunding movements from
POL FS controlled bank accounts
Joint Stock Bank
movements
To Joint stock bank a/cs
Need to contra off the
funding/defunding movements from
POL FS controlled accounts
Remittance out of
Cheques to EDS
To Cheques to EDS
Match to data from EDS
Remit in NI Cheques
from Branch
To Cheques in transit
Match to NI Cheques from Branch
Girobank Change
Sales & Purchases
To Cash Centre Bank clearing
accounts
None as all banking is controlled in
ADS.
Sale of foreign coin to
Coin co — issue and
invoice
To summary movement and
client ADS debtor a/cs
None all banking in ADS
© Post Office™ 2003
Version 1.0
Page 69/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doe POL/IMPACT/DES/***
Loss on sale of foreign I To Loss account None — interfaced as a business loss
coin to ESFS
Sale of counterfeit/ To summary movement and None - Clearing of debtor is to
mutilated notes ADS client debtor a/cs Cheques to EDS.
Cash centre To Loss account None — interfaced as a business loss
losses/gains to ESFS
Girobank Deposits To Girobank client creditor a/c I Compare to Estimates paid to
Girobank
Girobank Deposit To Girobank Client debtor a/c None all control on ADS
shortages not settled
Girobank Deposit To Girobank client creditor a/c None all control on ADS
surpluses no settled
Unidentified pouches To Unidentified pouch a/c None all control on ADS
Foreign Exchange on To Foreign Exchange in hand None
Hand by currency by currency
Foreign exchange To Foreign Exchange None
revaluations revaluations
Foreign exchange To Foreign Exchange Match to settlement to First Rate
Wholesale remittances I Purchase/sale control
in & out
Sundry costs & Appropriate sundry revenue and I None
revenue incurred by cost accounts
branch
Individual Transactions for:
Cash Centre POL FS Accounting Subsequent Action on POL FS
Transaction
Remittances in and out of I To Cash in Transit Match to data from Horizon
Cash to Branches
Remittances in To Agent account Send to Horizon as Transaction
Discrepancies Correction
Coin Club & Customer To BoE Incoming CHAPS Match to transactions on BoE
bulk cash sale clearing Statement
Coin Club & Customer To BoE outgoing Chaps Match to transactions on BoE
bulk cash purchase clearing Statement
Cash In and out of Bond__I To Cash in Bond clearing Match to BoE Bank Statement
Bank Machine ATM To Bank Machine “debtor” a/c_I Bank Machine ATM Process (TBD)
cassette remit out
Bank Machine ATM To Bank Machine “debtor” a/c I Bank Machine ATM Process (TBD)
cassette remit in
Repatriation of Scottish I To BoE Incoming Match to transactions on BoE
Notes CHAPS/BACS clearing Statement
Remittances in and out of I ¢ To Stock accounts (if « Match to value from Horizon.
Foreign Currency — by balance sheet stock)
individual currency —
volume and value « To MM Stock by product Match to Quantity from Horizon
The current process of providing Pension cheques from cash centres for nursing homes is to be
phased out by March 2005 and hence is not included in this document.
8.2.3 NSSC Stock Transactions
This includes all NSSC stock transactions that are not recorded on SAP ADS. It is a working
assumption that this includes all Post Office Network stock transactions that are not Foreign
Exchange.
Version 1.0 Page 70/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
Summary Movements in:
NSSC Transaction
POL FS Accounting all by
NSCC
Subsequent Action on POL FS
Receipts of Balance Sheet To Stock Account None
Stock from suppliers To MM Stock by product
Returns of Balance Sheet To Stock Account None
Stock to suppliers
To MM Stock by product
Despatch of Balance Sheet
Stock to Branches
Move from Stock to Stock in
Transit a/c
Remove from MM Stock by
product
Match to Receipt of stock by
branch
Return of Balance Sheet
Move from Stock in transit to
Match to despatch of stock by
Stock by branches Stock branch
To MM stock by product
Write off To Write/off adjustments None
/adjustments/destruction to I accounts
balance sheet stock
Receipt of other trading To MM Stock by product None
stock from suppliers
Return of other trading stock I To MM Stock by product none
to suppliers
Despatch of other trading to
Remove from MM stock by
Match to Receipt of stock by
Branches product branch
Return of other trading stock I To MM Stock by product Match to despatch of stock by
by branches branch
Write off Remove/add to MM stock by None
/adjustments/destruction to
other trading sheet stock
product
8.3 Client Settlement to Clients A44
The following process descriptions relate to the Swimlane maps in section 7.
8.3.1 A442 Summarise Client Data
Activity Description
442010 Client sends transaction information to POL. This is at a low level of detail. This
can be sent by email, fax or disc/tape.
442040 I Transaction information is received. Transaction Processing require detailed
data for comparing client data to data recorded on Horizon. The data is loaded
onto Management Information system.
Where discrepancies are identified, this will be a trigger into the Discrepancy
Process to determine whether the tolerance /threshold levels have been
exceeded and, if so, the action to be taken
442020 I From the data received from the client, summarised information is generated and
loaded onto POL/FS. Settlement team does not require detail information for
settlement to clients
442021 I The information provided by the client may include a summary total. Where this
is the case, the Settlement team compare summarised data total (generated
above) and compare to the client-provided summarised total. If there is a
mismatch, then the client is notified.
Version 1.0 Page 71/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
442030 I Summarised totals (By Settlement Group By Period) are entered into Client
Holding Account. This sets up the amounts due on a particular day to each
client.
However, this will be a trigger into the Discrepancy and Resolve Discrepancy
Processes to determine whether the tolerance/threshold levels (at business total
level) have been exceeded and, if so, the action to be taken
The precise requirements of client data feeds will be defined during the system design phase.
8.3.2 A443 Calculate and Settle on Estimated Amounts
Activity Description
443010 Estimate falls due. The estimation cycle and period is different for
each client — e.g. Girobank estimates on a monthly cycle; BBC.
estimates are on a 3 — 4 day cycle.
443020 Local Business Knowledge. This activity involves the ongoing
collection of information relating to an individual client. This includes
knowledge of business cycles, public holiday effects, and trend in
business.
443030 Product change Process. This process is outside the scope of this
swimlane but specifically feeds into the local business knowledge in
the settlement dept.
443040 Combine inputs is the activity of bringing together all the information
that is used to calculate the estimate(s)
443050 Calculate estimate(s)
443060 Inform client in advance. The estimated payments are communicated
to the client. This is currently manual.
443070 Agree Payment amount. The estimated payments are mutually
agreed between POL and client. Some clients are more proactive
than others in agreeing the estimates.
443080 Negotiate payment value
443090 Enter into Client Ledger on POL FS to generate payments.
This will involve a journal with both sides going to the Client a/c.
The payment value will be posted to the payment area of the Client a/c
and the balancing entry will be posted to the comparison area of the
Client a/c.
8.3.3 A444 Discrepancy Process — Errors identified by Clients
Activity Description
444100 Paperwork is sent by each branch on a daily/weekly basis to clients
444120 Client is sent electronic summary information based daily transaction
summaries. (Currently sent weekly)
Version 1.0 Page 72/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE poe POL/IMPACTIDES/***
ef
444110 On receipt of the paper work and the electronic information, the client
444130 carries out their own matching and verification (using their own systems)
444140 Where errors are identified, then the client notifies POL of errors and send
any appropriate supporting evidence to POL (Girobank also adjusts
444150 settlement)
The errors are investigated as part of the A45 Resolve Discrepancies
process
444185 The investigation undertaken in the Resolve Discrepancies process may
result in there being errors in the errors summary provided by the client. In
this case, the summary errors are sent back to the client (via fax, e-mail or
disc/tape) with the reason for return
444220 The investigation undertaken in the Resolve Discrepancies process may
result in the error not being identified and necessitate the paperwork being
returned to the client with the reason for return
444190 On receipt of the returned summary errors (from 444185), the client
investigates and makes adjustments to the errors and supporting
documentation. If necessary, the client re-issues the error(s) (via 444150)
444193 Client (Girobank) adjusts settlement expected.
444230 On receipt of the returned paperwork, the client investigates and reissues
the error (via 444150) if the discrepancy is correct.
444240 Where the client investigation results in the acknowledgment that the error
should not have been issued, then a charge or claim error notice is issued to
POL
8.3.4 A444 Client Discrepancy
Activity Description
444010 Actual Horizon data is received into SAP — the data is summarised by
Branch by Settlement Group By Period
444020 Client data is received into SAP
444030 The Client holding account is reviewed at business total level.
444040 This includes looking at the tolerance / thresholds set and determining
whether these have been exceeded or not (at a business total level).
Where the differences are within the tolerance / threshold level, then
no further action needs to be taken.
However, where they have been exceeded, then the process moves
onto activity 444050
444050 A check is made on the client discrepancy information held (this
information is not held on POL-FS — see process A443 and associated
support swimlane document)
The detailed client discrepancy information is held by branch by
product by period. This is investigated and the process may then move
into the Resolve Discrepancies process
Version 1.0 Page 73/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
Ref:
8.3.5 A445 Resolve Exceptions
The key feature of the Resolve Exceptions process is the Transaction Correction. This is the
electronic version of the Error Notice. The Transaction Correction will be raised against the
Agent Accounts Receivable account with sufficient information to identify:
Client product being adjusted
Suspense type being adjusted
Requirement for any write off
Options for resolution by the Agent — make good, request hardship, request more
evidence
Information for the Agent so that they are aware of the impact of each option
Horizon will interpret this information to provide an intelligent interface at the branch to carry the
appropriate transactions based on the option chosen by the agent.
Definitions
The term “branch” is used here to cover all the different types of branches — directly-managed,
franchised, community, singleton, local multiples, national multiples.
The process covers all these types of branches — however, there is a difference in the way
Transaction Corrections are handled for Multiple branches and this is reflected in the swim lane
document and the activity descriptions below.
8.3.5.1 Resolve Exceptions
Activity Description
445000 Discrepancies identified at the Cash Centres (for example, through mismatch on
Girobank deposits or pouches received from branches) are recorded onto SAPADS.
The information is then sent to POL-FS
445001 A discrepancy has been identified (and this can be by POL, the branch, the client or a
customer)
445002 Identification at the branch of Rem-Iin discrepancies which has occurred in Cash
Delivery between the branch and Cash Centre
445005 Acheck is made on the client discrepancy system (see process A442 and associated
swimlane support document).
This is a “threshold investigation” to identify any branches which have exceeded the
tolerance/threshold level
N.B. This is a review which takes place on an on-going basis
445010 This involves looking at the past history of the agent in terms of exceptions already
identified (and possibly written-off or currently being progressed by Debt Recovery) —
445020 plus the trend and history for the particular branch, client, product or service.
N.B. This is a review which takes place on an on-going basis
445030 If the exception is a “surplus” then it may be required to net this off against outstanding
“shortages” if a Transaction Correction is eventually raised.
445040 Record exception against Branch/Agent — precise method of recording to be
determined.
Version 1.0 Page 74/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
445050
Accheck is made on whether the exceptions identified result in the threshold being
exceeded (this takes into account previous exceptions and Transaction Correction
outstanding).
445055
Where the discrepancies are not sufficient to exceed the threshold level, then
adjustments are made to the agent ledger to indicate that the discrepancy has been
investigated and is below the threshold level
445056
445057
A periodic review is undertaken of adjustments due to discrepancies and these may be
written off
8.3.5.2
Transaction Corrections — Singleton/Franchise Branches
445060
Where threshold levels have been exceeded, then these need to be investigated (via
A444 - Discrepancy Process)
Where initial investigations result in determining that the initial findings were incorrect,
then the process may move onto 445055, 445056, and 445057 (described in the above
2 rows)
This process is also appropriate where the branch or Nominee dispute the Transaction
Correction, by using the Request More Evidence option. This may result in the process
moving onto 445055, 445056, and 445057 (described in the above 2 rows) or a new
(amended) Transaction Correction being issued
445080
Investigations result in a Transaction Correction being issued to the Branch. This is
issued electronically via POL-FS to Horizon
The Transaction Correction will include the appropriate instructions for the branch
manager (as is the case currently for Error Notices)
445085
Unresolved Transaction Corrections will also be regularly reviewed. This should not be
left to the end of Branch Trading Periods or Financial Period ends.
This activity will lead to Exceptions Handling chasing up Branches who have substantial
outstanding Transaction Corrections. (May involve Retail Line)
445090
The Branch manager (at non-Multiples and Multiples) checks on Horizon each day for
the receipt of any Transaction Corrections
445100
The Branch Manager (non-Multiples) or the Nominee (Multiples) dispute the Transaction
Corrections
Transaction Corrections can only be disputed once (on initial issue)
Non-Multiples indicate this via Horizon — Nominees will do so via post/mail.
Where the Nominee accepts the Transaction Correction, then the Nominee can make
the appropriate payment (via Debit or Credit Card or BACS). This is via the process
outlined in process A47 (see swimlane for this process plus the associated swimlane
support document)
445110
Where the Transaction Correction is disputed, more evidence is obtained and further
investigations are undertaken.
Where necessary, further evidence is obtained and the Transaction Correction issued
However, investigations may also result in the Transaction Correction being
cancelled/withdrawn and the process moving onto 445055, 445056, and 445057 (see
above) or a new (amended) Transaction Correction being issued
445120
The Branch Manager accepts the Transaction Correction
For non-Multiples, acceptance is indicated on Horizon via one of the following two
activities.
Version 1.0 Page 75/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
445121 Accept and Making good the amount of the Transaction Correction. This assumes that
the agent will put the Cash amount of the Transaction Correction in the Branch Till.
445125 Transfer to Central Collection. This sets up the Transaction Correction amount Debt
due for collection in the Agents Debtor account.
The process moves into the Debt Recovery process (A47)
8.3.5.3 Branches Run as Multiples
445060 Where threshold levels have been exceeded, then these need to be investigated (via
A444 - Discrepancy Process)
Where initial investigations result in determining that the initial findings were incorrect,
then the process may move onto 445055, 445056, and 445057 (described in the above
2 rows)
This process is also appropriate where the branch or Nominee dispute the Transaction
Correction, by using the Request More Evidence option. This may result in the process
moving onto 445055, 445056, and 445057 (described in the above 2 rows) or a new
(amended) Transaction Correction being issued
445080 Investigations result in a Transaction Correction being issued to the Branch. This is
issued electronically via POL-FS to Horizon
The Transaction Correction will include the appropriate instructions for the branch
manager (as is the case currently for Error Notices)
445085 Unresolved Transaction Corrections will also be regularly reviewed. This should not be
left to the end of Branch Trading Periods or Financial Period ends.
This activity will lead to Exceptions Handling chasing up Branches who have substantial
outstanding Transaction Corrections. (May involve Retail Line)
445090 The Branch manager (at non-Multiples and Multiples) checks on Horizon each day for
the receipt of any Transaction Corrections
445100 The Branch Manager (non-Multiples) or the Nominee (Multiples) dispute the Transaction
Corrections
Transaction Corrections can only be disputed once (on initial issue)
Non-Multiples indicate this via Horizon —- Nominees will do so via post/mail.
Where the Nominee accepts the Transaction Correction, then the Nominee can make
the appropriate payment (via Debit or Credit Card or BACS). This is via the process
outlined in process A47 (see swimlane for this process plus the associated swimlane
support document)
445110 Where the Transaction Correction is disputed, more evidence is obtained and further
investigations are undertaken.
Where necessary, further evidence is obtained and the Transaction Correction issued
However, investigations may also result in the Transaction Correction being
cancelled/withdrawn and the process moving onto 445055, 445056, and 445057 (see
above) or a new (amended) Transaction Correction being issued
445125 Transfer to Central Collection. This sets up the Transaction Correction amount Debt
due for collection in the Agents Debtor account.
For multiples this records the Transaction Correction as a debt against both the Branch
and Nominee Agent accounts.
Version 1.0 Page 76/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
445081
For Multiple Branches only, there will be a monthly Multiples Statement produced which
will detail all the Transaction Corrections issued since the last report plus any that are
still outstanding (for example, under investigation, cancelled) or cleared (i.e. made
good).
The report (a physical hard-copy) is issued to the Nominee and includes an Invoice
detailing the amount payable to POL
445082
The Nominee receives the monthly Multiples Statement and decides on whether to
dispute some or all of the Transaction Corrections or make the appropriate payment
445115
The Agent Nominee accepts the Multiples Statement & new Transaction Corrections
accepted by individual branches.
Acceptance of new Transaction Corrections will normally be indicated by payment of
amounts due in agree terms.
8.3.5.4
Directly Managed Branches
445060
Where threshold levels have been exceeded, then these need to be investigated (via
A444 - Discrepancy Process)
Where initial investigations result in determining that the initial findings were incorrect,
then the process may move onto 445055, 445056, and 445057 (described in the above
2 rows)
This process is also appropriate where the branch or Nominee dispute the Transaction
Correction, by using the Request More Evidence option. This may result in the process
moving onto 445055, 445056, and 445057 (described in the above 2 rows) or a new
(amended) Transaction Correction being issued
445080
Investigations result in a Transaction Correction being issued to the Branch. This is
issued electronically via POL-FS to Horizon
The Transaction Correction will include the appropriate instructions for the branch
manager (as is the case currently for Error Notices)
445085
Unresolved Transaction Corrections will also be regularly reviewed. This should not be
left to the end of Branch Trading Periods or Financial Period ends.
This activity will lead to Exceptions Handling chasing up Branches who have substantial
outstanding Transaction Corrections. (May involve Retail Line)
445090
The Branch manager (at non-Multiples and Multiples) checks on Horizon each day for
the receipt of any Transaction Corrections
445100
The Branch Manager (non-Multiples) or the Nominee (Multiples) dispute the Transaction
Corrections
Transaction Corrections can only be disputed once (on initial issue)
Non-Multiples indicate this via Horizon — Nominees will do so via post/mail.
Where the Nominee accepts the Transaction Correction, then the Nominee can make
the appropriate payment (via Debit or Credit Card or BACS). This is via the process
outlined in process A47 (see swimlane for this process plus the associated swimlane
support document)
445110
Where the Transaction Correction is disputed, more evidence is obtained and further
investigations are undertaken.
Where necessary, further evidence is obtained and the Transaction Correction issued
However, investigations may also result in the Transaction Correction being
cancelled/withdrawn and the process moving onto 445055, 445056, and 445057 (see
above) or a new (amended) Transaction Correction being issued
Version 1.0 Page 77/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
445120 The Branch Manager accepts the Transaction Correction
For Multiples, this is the only choice. Any disputes or payments are handled by the
Nominee (see 445100)
For non-Multiples, acceptance is indicated on Horizon via one of the following two
activities...
445130 Review write offs to ensure values are understood and controlled by branch.
8.3.6 A446 Authorise and Make Payments
Activity Description
The trigger points for this process are from the following processes:
« A442 —Summarise Client Data
« A443 - Calculate Estimated Amounts For Settlement
« A444 - Exceptions Handling — Client Discrepancy
e A445 - Resolve Discrepancy
e A47 - Debt Recovery
POL data will include any adjustments made during the above processes
446010 Review balance outstanding on client ledger to obtain settlement value (actual or
estimated) and if necessary, enter values into client ledger to deduct commission
or make other adjustments.
446020 Create system (on-line) payment proposal(s) for the payment(s) due. The
creation is controlled by client standing data (see below for the types of
information for inclusion in the standing data which will enable this to be
controlled)
446025 This is an on-going process and one which includes making changes to client
standing data. The client standing data contains the following types of
information for each client:
¢ Client name
¢ Client Product
¢ Client Bank Details
e Payment Method (currently, this is I for CHAPS, E for BACS and C for
Cheques, Swift, Direct Debit (receipts))
e Settlement Terms — (e.g. Next Day; Week in arrears etc)
« Source of Settlement (e.g. POL Data, Client Estimate, Client Actual)
The Client standing data then is a control for the raising of the payment
proposal(s) (see 446020 above) and the detailed contract checks (see 446030
below)
Version 1.0 Page 78/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
446030
Payment proposal to be checked on line — this check is to ensure, for example,
that the payment is in line with the contract, settlement is due, that the payment
proposal contains the correct standing data, etc. Refer to business rules being
determined
446050
Payment proposal to be verified on-line — this check is to ensure that the
settlement amount is reasonable and any deviation from the normal amounts is
acceptable and explainable. Refer to business rules being determined.
446060
446070
Amounts due to be paid are discussed between the Team Leader and Manager
where necessary and fully verified. This may be because the amounts vary
drastically from the “normal” trend / range.
446080
Where the team Leader deems the amount to be unreasonable or “beyond the
norm”, then the payment proposal will need to be adjusted as agreed during the
discussions above
446090
Approval of payment allows the payment to be made
446095
Information is received by the Cashiers section on the funding required for the
approved payments. This is provided by payment method
(There is a break-out here into the “Funding Process” (which is out-of-scope).
This process is where the cashiers ensure that the funding to make the
approved payments is in place)
446096
The Payment Authorisers authorise the payment. This allows the payment to be
sent electronically via BACS or CHAPS, Swift. Receipts may be by Direct
Debit.
For Cheque payments (which should be the exception), the cheques are printed
(via a Cheque Printer)
Current authorisation procedure is as follows:
e Where the payment amount is less than £50,000, there is a one-step
authorisation
« Where the payment amount is £50,000 or greater, there is a two-step
authorisation
It is assumed that this will procedure will remain in POL-FS
446097
The printed cheques are then checked for correctness and accuracy and signed
and sent to the client
446098
Remittance advices, showing volume and value by product, are printed and sent
to the client — where the payment is by cheque, the remittance advice is sent
with the cheque.
Version 1.0 Page 79/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
8.4 A45 Client Settlement from Clients
Settlement from clients has historically always relied on the pre-funding based on estimated data.
This is shown by the high level process map A45. The process of calculating estimated amounts
due from clients is the same process map A443.
The new Personal Banking process provides some differences, as this is based on actual data,
and so has been mapped individually.
8.4.1 A453 Personal Banking process
Activity Description
453010 Collection of monies falls due based on payment terms of client
453020 Cashiers are informed of amount to be received — based on daily data
from Branch fed into POL FS
453030 Client pays amount based on electronic information received from
banking system (or based on information supplied by POL to support
request).
453040 Amount paid should agree to expectations
453050 Discrepancy reported
453060 Investigations of discrepancy may conclude same day as original
453070 Payment
453080 Adjust payment if required as soon as possible
453090 Actual payment amount entered into POL-FS.
453100 The Client Ledger is checked and where the amount expected and the
amounts paid agree, then these are matched and cleared.
Where there are differences, then there is a link out to A444
(Discrepancy Process) to ascertain whether tolerances / thresholds
have been exceeded.
Version 1.0 Page 80/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
Ref:
8.5 A46 Verification
Verification was identified as a specific process stream at the high level design phase. It was
established during a detailed design scoping period that verification is individual activities that are
part of all the other process streams, such as settlement, and product POL Ledger.
The process illustrated as process A466 was covered as part of the debt recovery process.
8.5.1 Exceptions Identified by Client or Customer
Activity Description
466001 This is the start point of the process. The exception is identified by
466002 either the client or the customer.
466003 Evidence is submitted by the client or the customer — for the customer,
466004 this may be, for example, a till receipt or a utility bill stamped and
initialled by the branch
466010 Exceptions handling review and check the evidence
466015 There is also a check made on the customer — for past history and
incident history
8.6 A47 Debt Recovery
8.6.1.1 Deduction From Remuneration
Activity Description
470000 This is the start point of the process. A Transaction Correction has been actioned in a
Branch and the amount due will be collected centrally.
470010 The debt is not considered in isolation. Previous debts and debt history is taken into
account to determine the total amount owing at this time. Additionally, consideration is
also given to the following:
«The level of difficulty experienced in the past to recover money;
e Previous hardship cases;
e Problems with making payments or payments made
470030 Debt Recovery section issue a statement of account of outstanding debt.
This is not a one-off activity at the start of the debt recovery process. The statement of
debt will be issued on a regular basis/frequency to notify the Postmaster or the Nominee
of the current outstanding debt amount (level of itemisation is to be determined — current
thinking is that it is a summary of each debt total).
N.B. For the Nominee, the statement is a Multiples Statement (see swimlane
process A455 — Resolve Exceptions plus the associated swimlane support
document)
470040 The Postmaster or Nominee receives the statement of debt, via the Post service.
Acknowledgement of receipt is required.
470045 Retail Line will receive statements from SAP.
Version 1.0 Page 81/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: — Automated Ledgers
COMMERCIAL IN CONFIDENCE poe POL/IMPACTIDES/***
ef:
470050 Acknowledging the statement of debt, a series of dialogues takes place between the
470060 Postmaster /Nominee and the Debt Recovery Team to determine how the debt is going
to be cleared (in full, by instalments, via remuneration, via credit or debit card, etc.)
If amount to be deducted is more than 25% of pay then DR will automatically arrange
deductions using 25% as max per month and advise postmaster.
470090 Retail Line review Branch positions to ensure they remain viable. (This activity will feed
into other processes that are out of scope of IMPACT).
470100 Debt Recovery arranges for the amount (whether agreed or not) to be deducted for
remuneration.
470110 Once deductions have been made from postmaster or nominee remuneration, then
Payroll Section notify Debt Recovery of the deduction made
470120 The amount owing on the Agent Ledger is adjusted by the amount paid.
8.6.1.2 Collection via Debit/Credit Card or BACS
Activity I Description
470040 The Postmaster or Nominee receives the statement of debt, via the Post service.
Acknowledgement of receipt is required.
470130 The Postmaster or Nominee elects to pay off the amount due via credit or debit card.
470160 This is via a telephone call to Debt Recovery who take the details and process the
payment via Streamline
470131 The Nominee may elect to make the payment via BACS
470132 The Nominee notifies POL of payment made via BACS
470120 The amount owing on the Agent Ledger is adjusted by the amount paid.
This journal will also update either the Streamline awaiting clearing account or the BACS
receipts clearing account as appropriate.
470163 Once payment has been banked, as confirmed by Cashiers, Debt Recovery may report
470165 on the amounts cleared. RLM may receive notification of payment made/or not made as
appropriate.
470170 Debt Recovery confirm the repayment to the Postmaster or Nominee
470175
8.6.1.3 Deferment of Payment
Activity Description
470040 The Postmaster or Nominee receives the statement of debt, via the Post service.
Acknowledgement of receipt is required.
470041 If there is no response to the Statement of debt, then after a time-lapse (proposal is that
4 this should be set to 2 weeks — i.e. 10 working days). Debt Recovery contact the
70180 Postmaster or Nominee and initiate discussions on repayment
470190
470200 The Postmaster or Nominee pleads hardship and maintains that he cannot pay off the
debt either in whole or buy instalments and indicates that there will be an adverse effect
on the business
Version 1.0 Page 82/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef
470210 Debt Recovery note the hardship plea and categorise the debt as deferred
470060 Debt Recovery Team to determine how the debt is going to be cleared (in full, by
instalments, via remuneration, via credit or debit card, etc.)
If amount to be deducted is more than 25% of pay then DR will automatically arrange
deductions using 25% as max per month and advise postmaster.
470220 The deferment is notified to the RLM for further investigation and action
470230 The evidence of the debt is sent to the RLM for further investigation and action
470090 The RLM assesses branch / multiple viability and also whether the contract should be
470091 allowed to continue
470092 The debt is reviewed by the Head of Area who may decide to authorise write-off the
470093 unrecoverable debt amount
470095 Unrecoverable debt written off will update the Agent’s account and be shown against
appropriate Profit and Loss account.
8.7 A48 Produce POL Ledger
The majority of Processes are covered in detail design by other processes:
A481_I Produce POL Ledger Covered by Settlement Processes
A482 I Produce Branch ledger Covered by Summarise Data from Branches —
Data Flow
A483 I Produce Agent Ledger Covered by Debt recovery Process
A485 _ I Produce Cash & Bank ledger Release 1
A486_I Produce Business Trading Ledger Covered by summarise data —- Data Flow
A487 I Produce Borrowings & Investments Release 1
Ledger
A488 I Produce Stock Ledger Covered by summarise data — Data Flow
8.7.1 A484 Branch Liability Management
The process of managing Branch Liability as part of POL FS is largely a reporting and monitoring
process.
All financial information that relates to a branch will be recorded such that the branch is identified
as a parameter in the financial ledgers. A full balance sheet by branch will be available.
This will allow the Retail Line Managers to report on Branch Liability with information that is only a
day old. Where this coincides with the end of a Branch Trading Period then there will be close
correlation between the Branch Trading Statement created on Horizon and any information
reported from POL FS.
The information that is recorded in POL FS is based on a particular end of day cut off and, since,
this is not necessarily the same as the cut off point as for the Branch Trading Statement the two
reports will also have some timing differences. It is therefore recommended that no reconciliation
is attempted between the Horizon and POL FS versions of the Liability Statement.
8.8 A489 General Ledger Processing
Version 1.0 Page 83/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef
Step Who When
1. Clear all GL accounts set up as open item managed Automatic I Daily
Job
2. Exception reporting for open items Automatic I Daily
Job
3.__Investigate open items POL. Daily
4. Inform branches/cash centre/EDS/Streamline of I POL Daily
exceptions where necessary so they can make
adjustments
5. Journal any central adjustments into POL Ledger as I POL Daily
required. This will include postings to give visibility of
the contingent liability of cash in bond.
6. Reporting for DT! Securisation Report POL Weekly
Period end
7. POLFS interface to ESFS POL Monthly Period end
8.9 Management & Accounting Information
8.9.1 Standard Within POL FS
All Management/ Accounting information in POL FS is limited based on the granularity of data
recorded in POL FS.
Although POL FS will capture summary level information of Branch and Cash Centre client
transactions, it is not the key role of POL FS to provide Management Information relating to client
activity. This is the role of MIS. POL FS will provide reports suitable to an auditable standard but
this is not Management Information.
POL FS key role relating to the recording of client data is for settlement.
POL FS will provide a variety of reports that are standard within the SAP system. There will also
be some specific reports that will be built based on POL requirements. The standard reports
are listed below are anticipated as being useful to the business. Also listed are other reports that
will have to be developed specifically to business requirements.
Client Related:
«Value of indebtedness to clients both individually and in total Standard
« Value of client indebtedness to POL both individually and in total Standard
« Age of indebtedness both individually and in total Standard
« Payment History Standard
* Overall difference between settlements on client or estimated data I Standard
and actual value of transactions recorded in Branches
« NAO requirements Requirements
to be defined
Agent Related:
« Value of agent indebtedness to POL both individually and in total Standard
« Age of indebtedness both individually and in total Standard
« Outstanding Transaction Corrections by Agent and in total Standard
« Value and age of “suspense” items by agent (or branch) and in I Standard
total
Branch Related:
Version 1.0 Page 84/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE poe POL/IMPACT/DES/***
ef
« Full Balance Sheet by branch Standard
« Full Balance Sheet by branches in RLM / Retail Area Heads I Standard
hierarchy
« Value of items expensed or written off by branch Standard
e Value of P&L Revenue transacted by branch Standard
Cash Centre Related:
« Full Balance Sheet by Cash Centre Standard
e Full Balance Sheet for all Cash Centres, reconcilable to SAP ADS Standard
« Value of items expensed or written off by Cash Centre Standard
« Value of P&L Revenue transacted by Cash Centre Standard
Post Office Network:
¢ Full Balance Sheet Standard
¢ Full P&L based on items recorded in Branch/Cash centres Standard
¢ Exception reporting of unmatched items — e.g. remittances, I Standard
cheques, payments to and from POL bank accounts etc.
¢ DTI Securitisation Report (defined in Release 1) Standard
Stock Reporting
e Volumes for non balance sheet stock Standard
« Volume and value for balance sheet stocks Standard
e Sales versus Holdings branch/hierarchy/business for various Bespoke Report
time periods
e Stock holdings by client, by product and denomination Bespoke Report
Foreign Exchange Reporting
e Foreign exchange quantities by branch with sterling equivalent_I Standard
e Sales versus Holdings by branch/hierarchy/business for Bespoke Report
various time periods
Version 1.0 Page 85/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
8.9.2
Client Reporting (Contractual Agreements)
Reporting Requirements From POL FS
The following requirements were identified in the Programme CD relating to data available
in POL FS
These requirements were based on extracting the current information requirements from
the reports that are currently run on CBDB/OPTIP.
Further work needs to be done to establish how these requirements translate into
requirements against new processes and data. It is therefore probable that not all details
of these information requirements will be delivered in the way described below.
Ref
Requirements Description
Business Area
Category
Report! Proposed
Functionality I Application
Area
MI
100
Information required by Audit
for issued error details, errors
BTA and errors not Network
Reinvention offices
Data Exceptions
Client
Report POL FS
MI
101
Information to Multiples
Partners regarding
outstanding, issued and BTA
errors.
Data Exceptions
Client
Report POL FS
MI
104
Ability to produce data files or
reports for clients as defined
within contractual
agreements. For example
volume and value of
transactions, customer details
if applicable, product
breakdown by volume and
value, details of adjustments
made, data mismatches
between client supporting
document stream and
transaction stream, method of
payment details. Example
clients are Local Schemes,
Department of Work and
Pensions, Girobank, NSB,
UKPS, AON, First rate,
DVLA, Department of Health,
Inland Revenue.
Data
Preparation/
Data Exception
Client
Report TMS/POL
FS
Version 1.0
© Post Office™ 2003
Page 86/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE poe POL/IMPACTIDES/***
ef
Management Reporting
Ref I Requirements Business Category Report/ Proposed
Description Area Functionality I Application
Area
MI I Volume and value of I Data Management I Report POL FS
114 I outstanding exceptions I Exceptions
by branch, by age, by
value
MI I Volume and value of I Data Management I Report POL FS
115 I issued errors by product I Exceptions
or branch
MI Number and value of I Data Management I Report POL FS
117 I maintained errors and I Exceptions
write offs by product
MI I Ability to pull off statistics I Data Management I Report POL FS
118 I regarding team I Exceptions/
performance (exceptions I Debt Recovery
created, exceptions
issued, 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 Debtor days by client I Debt Recovery I Management I Report POL FS
122 I and product and trend
analysis monitoring
MI I Creditor days by I Debt Recovery I Management I Report POL FS
123 I organisation and product
and trend analysis
monitoring
MI Errors produced for I Debt Recovery I Management I Report POL FS
124 I creditors and debtors —
issued or resolved,
number and value, by
client and product.
MI Progress of exception I Debt Recovery I Management I Report POL FS
125 I handling measured
against target (failures to
issue or clear in x
number of days)
MI I Aged debt profile by I Debt Recovery I Management I Report POL FS
126 I number and value
MI I Debt as a percentage of I Debt Recovery I Management I Report POL FS
Version 1.0 Page 87/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: — Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
127 I sales/transactions by
product
MI Monitoring of percentage I Debt Recovery I Management I Report POL FS
128 I of debt recovered and
outstanding
MI Bad debt provision I Debt Recovery I Management I Report POL FS
129 I monitoring
MI I Ability to track KPIs for I Performance I Management I Report POL FS
173 I the Cash Accounting I Management
and Cash Management
teams, against (3 levels
of summarisation)
« individual target,
e team target and
* group target.
Broken down by
« Exception type.
e By product,
« Resolution
reason
In addition it must be
possible to determine
the
«Error clearance
rate (per person
per week)
« Average time
spent at each
stage of the
process by
product by the
individual.
The targets must be
parameter driven and it
must be possible to
group products together
and report as above
against targets
Version 1.0 Page 88/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc
Ref:
FUJ00090148
FUJ00090148
Automated Ledgers
POL/IMPACT/DES/***
Operational Reporting (What we need to do our day jobs)
Ref
Requirements Description
Business
Area
Category
Report/
Functionality
Proposed
Application
Area
MI
130
Ability to pull off ad hoc
reports selecting required
data fields from available list
and defining format as
required.
All
Operational
Functionality
Data
Warehouse
POL FS
MI
134
Ability to run batch reports to
defined timescales and
formats as required.
All
Operational
Functionality
Data
Warehouse
POL FS
MI
132
Volume and value of
transactions and sup doc
information to be 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).
Data
Exceptions
Operational
Report
Data
Warehouse
MI
133
All created exceptions to be
reported by transaction, by
product, by branch. All
outstanding exceptions to
be reported by transaction,
by product, by branch.
Data
Exceptions
Operational
Report
Data
Warehouse
MI
134
Details of cleared
exceptions to be archived
but still accessible to provide
a rolling 12 month view.
Data
Exceptions
Operational
Report
POL FS/
Data
Warehouse
MI
136
Ability to flag branches on
exception reports that
require priority attention or
specific action (e.g. A =
Network 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.
Data
Exceptions
Operational
Functionality
POL FS
MI
139
Ability to
Recovery
Debt
Case
report
Debt
Recovery
Operational
Report
POL FS
Version 1.0
© Post Office™ 2003
Page 89/141
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
FUJ00090148
FUJ00090148
Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
Management By branch, by
branch type, by Agent
name, by product (by
client), by age of debt.
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
MI
142
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
(i.e. 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
MI
145
Disputed debt by branch, by
client (e.g. 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
MI
147
Data archiving ability
Support
System
Functionality
POL FS
Data
Warehouse
MI
148
Ability to access archived
data easily and run reports
by transaction, by branch,
by product, by client as
Support
System
Functionality
POL FS
Data
Warehouse
Version 1.0
© Post Office™ 2003
Page 90/141
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
required
MI
151
Ability to schedule regular
report production. Ability to
monitor production of
scheduled reports.
Support
System
Functionality I POL FS
Data
Warehouse
MI
152
Report showing transaction,
supporting document or
client level adjustments. By
branch, by product, by
value, by number. To
include date of adjustment,
user details and reason
code for adjustment.
Data
Exceptions
Operational
Functionality I TMS/POL FS
& Report
MI
174
Ability to carry out Rota
Checking. The rota checks
must be data driven and the
outlets selected will vary
over time. This is in support
of Rota Checking Process.
Exceptions
Report POL FS
Cash Management Requirements
Ref
Requirements Business
Description Area
Category
Report/ Proposed
Functionality I Application
Area
MI
153
Ability to undertake trend I Cash
analysis in order to aid I Management
forecasting of the future
value of transactions
(e.g. DNS, Girobank,
DVLA)
Operational
Functionality & I POL FS
Report
MI
154
Ability to undertake trend I Cash
analysis in order to aid I Management
prediction of client for
ESFS
Operational
Functionality & I POL FS
Report
MI
155
Ability to identify and I Cash
report the current I Management
outstanding balance
within each ledger.
Operational
Functionality & I POL FS
Report
MI
157
Ability to identify and I Cash
report stock holdings by I Management
client, by product, by
denomination (e.g.
Vodaphone phonecards,
£5, £10 etc.)
Operational
Report POL FS
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
MI Ability to produce reports I Cash Operational I Functionality & I POL FS
159 I to aid reconciliation of I Management Report
ledgers and substantiate
ledger balances
MI I Ability to provide I Cash Operational I Functionality POL FS
161 I verification of accounts — I Management
Ernst & Young Audit
requirement
MI I Ability to identify cash I Cash Operational I Functionality) I POL FS
164 I and stock holdings by I Management Report
product, by branch
MI I Ability to produce I Cash Operational I Functionality) I POL FS
165 I statement of accounts for I Management Report
each client — including
brought forward figures,
sales, settlements made
and a closing balance.
MI I Ability to identify cash I Cash Operational I Functionality & I POL FS
167 I remittance in transit I Management Report
values by product.
MI I Summary report of data I Cash Operational I Report POL FS
168 I posted to ledgers and I Management
interfaced to ESFS by
value of debits/credits
against each ledger
code.
MI Daily, National summary I Cash Operational I Report/ POL FS
171 I of transactions, by client, I Management Functionality
by product, by method of
payment. Split by
deposits and withdrawals
(rather than net position).
MI Updated transaction data I Cash Operational I Functionality & I POL FS &
172 I received from Non polled I Management Report Data
offices to have indicator Warehouse
flag applied.
Version 1.0 Page 92/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE poe POL/IMPACTIDES/***
ef
8.9.3. Data Warehouse reporting
8.9.3.1 Requirements from the Programme CD
No. Revised Description
MI 1001 Ability to produce reports of volume and value
« by organisation,
e By product,
«by client,
« by time
¢ By branch
« By group of branches
* By cash centre area
e Method of payment
The reports should be capable of delivery at the transactional data
level
MI 1002 Ability to identify top sellers, worst sellers write-off, wastage for
particular products by time and organisation.
MI 1003 Ability to pull off adhoc reports by selecting required data fields and
defining required format
MI 1004 Provision of information regarding office opening hours, closures and
relocations to various internal parties and clients, replacing report ‘TP
129°
MI 1006 Ability to produce value and volume of exceptions (transaction
corrections) for historic reporting and trend analysis.
* By transaction type
e By product,
¢ By organisational unit,
e By exception status (e.g. created, cleared, outstanding),
« Period
Against total
MI 1009 Ability to run batch reports to defined timescales and formats.
MI 1010 Ability to identify and report on multiple transactions (e.g. multiple AP
transactions carried out against the same customer reference). Based
on an OPTIP report that provides information of this nature (1958 -
Multiple Transactions Report).
MI 1011 The ability to archive detailed transaction data after 3 months and
summary data after 5 years. Archived data should be held for up to 4
financial years.
MI 1012 The ability to retrieve both transaction and summary level archived
data in-line with the current data retrieval SLA for OPTIP.
MI 1013 The ability to hold transaction data for up to 3 months on line.
MI 1015 Ability to browse details of all products and all clients including
mapping of products to clients.
MI 1016 Ability to carry out Rota Checking. The rota checks must be data
Version 1.0 Page 93/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
driven and the outlets selected will vary over time. This is in support
of Rota Checking Process.
MI 1017 Ability to carry out Range Checking of aggregate total. This is in
support of the Range Checking process.
MI 1018 Interface to allow investigation of transaction data by the Cash
Accounting and Cash Management teams in support of the following
processes:
« A44 Client Settlement to Client
+ A45 Client Settlement from Client
It must be possible to load client transaction level data for
investigation and compare to the POL transaction data stream for that
client.
8.9.3.2 Intellect Standard Report
Working assumption: None of the standard intellect reports will be migrated to work against the
new MI system.
(Note: A review will be carried to out by the Business Change team to identify which, if any, of the
standard reports will be migrated, in either their current form or a new form to run against the POL
Data Warehouse. This work is still outstanding.)
8.9.3.3 Deferred S70 reporting requirements
No. Original Description
MI 1101 To report on Product P&L where all income (volume and Value —
Horizon), and cost (ESFS, SAP HR), can be apportioned across the
product range to defined drivers.
MI 1102 To report on Branch P&L where all income (volume and Value —
Horizon), and cost (ESFS, SAP HR), can be apportioned to defined
drivers across the organisation hierachy
MI 1103 Data feed required to produce the Recall report. This is based on an
existing AIS.
MI 1104 Data feed required to produce the NRM report. This is based on an
existing AIS.
MI 1111 Data feed required to existing Horizon MIS
MI 1112 To be able to perform an analysis across both Outlet and Product
P&L
MI 1113 Data feed required to Martins (Would also require interface from
Camelot)
MIL1114 Data feed required to DPI
MI 1115 Ability to pull cash holding data and transaction data from a single
source.
© Post Office™ 2003
Version 1.0 Page 94/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
8.9.3.4. Branch trading workshop requirements
No.
Original Description
MI 1106
Data feed required to support Risk Model
MI 1107
Ability to monitor and take action on the completion of Branch
Trading Statements
There is a requirement to produce summary reports based on the
existence and data contained within the following events flowing
from the Horizon system; “Trading Statement Created”, “Trading
Statement Period Rolled”, “Trading Statement Period Roll
Abandoned”. The reports will also use Trading Statement Calendar
information from NRDS to summarise those branches which have
not completed their Trading Statement within the correct timescales.
There is a further requirement to enquire on existence and data
contained within these events, to allow further investigation of
Branch Trading Statement production activity.
MI 1108
Ability to monitor and take action on amounts made good and/or
amounts removed with associated values
There is a requirement to produce summary reports based on the
existence and data contained within the following events flowing
from the Horizon system; “Excess Cash Removed”, “Cash Shortage
Made Good”. The reports will summarise the activity by branch and
by volume of events and value of amounts made good, over defined
time periods.
There is a further requirement to enquire on existence of and data
contained within these events, to allow further investigation of Cash
Make Good activity.
MI 1109
Ability to monitor the usage of Cash Variance reports
There is a requirement to produce summary reports based on the
existence and data contained within the following events flowing
from the Horizon system; “Cash Variance Report Previewed”, “Cash
Variance Report Printed”. The report will summarise the existence of
such events over defined time periods.
There is a further requirement to enquire on existence of and data
contained within these events, to allow further investigation of Cash
Variance Reporting activity.
MI 1110
Ability to monitor and take action the number of outstanding
Transaction Corrections at a branch
There is a requirement to produce summary reports based on data
from POL-FS and on the existence and data contained within the
“Outstanding Transaction Correction Reminder Displayed” event
flowing from the Horizon system. The report will summarise and
highlight, transaction corrections by branch, by age outstanding and
© Post Office™ 2003
Version 1.0 Page 95/141
FUJ00090148
© Post Office™ 2003
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE poe POL/IMPACTIDES/***
ef
by volume and value.
There is also a requirement to enquire on existence of and data
contained within the “Outstanding Transaction Correction Reminder
Displayed” events, to allow further investigation of Transaction
Correction activity
Version 1.0 Page 96/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
8.10 New Reference Data System
The NRDS has jurisdiction over the following systems:
Horizon; POL FS; SAP HR.
It is not in the scope of the NRDS to control reference data on SAP ADS, WCS, or ESFS
The interfaces between these systems and POL FS will be controlled by use of mapping tables.
8.10.1 Shared Data
POL and NRDS have common data that requires interfacing from R3/S80.
The common data entities are:
Master System Data Entities
NRDS Branches
Clients
Products
Agents
Branch Hierarchy
POL FS Chart of Accounts
The maintenance process on NRDS may need some additional changes for S80 subject to a full
understanding of the components of the data that will be maintained on NRDS.
Version 1.0 Page 97/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
8.10.2 Interface Control
NRDS needs to provide the Reference Data control and mapping for the interfaces between
Horizon and POL FS.
There are two components to this:
1) A logical database linking the various components of the data entities.
2) An Interface to pass this logical database to Horizon where the mapping will take place.
There is a requirement for the logical database to be updated directly in NRDS.
Logical Data Map
HORIZON POL FS
Product Article
[ Dummy
Quantity (O)
“Article POL FS
Mode” [> I Account (0)
+-——Settlement Type (O)
[Ledger Indicator (O)
HORIZON t——Summarisation
Mode
L_ Transaction Reference (O)
‘Movement Type (O)
Map of Data Entities in Logical Data Map to POL Data Model
Logical Data Map POL Data Model
Horizon Product. Product
Horizon Mode Movement Type
Article Product
Ledger Indicator No exact equivalent but indicates difference
between Client Ledger; Personal Agent Ledger;
other ledgers
Account Ledger Account
Movement Type Movement Type
Version 1.0 Page 98/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
9 Information Flows.
9.1 Branch Data from Horizon
Attribute
Description
Description
The files will contain all branch activity that has an impact on the
financial ledgers or the stock quantities.
Logical data items
* Movements in Cash/near cash in hand
« — Sales of stock items quantity and value
* — Client transactions number and value
* REM in and out of cash/near cash and stock
* — Adjustment/suspense item values
«Foreign currency revaluations
Special requirements
The link between the Horizon definitions of client products and the
POL FS definitions of materials, clients will be controlled using
Type A reference data.
Time constraint
File will be received & processed by 07:30 on day B where day A =
Trading day
Type of Object Electronic Data File
AIS Issued
Source Horizon
Destination POL FS
POL Data Model
All logical data items above equate to either:
Ledger Posting: For all value transactions
Inventory Item: For all stock transactions
© Post Office™ 2003
Version 1.0 Page 99/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
9.2
9.3
Cash Centre Data From SAP ADS
Attribute
Description
Description
The file will contain all activity in cash centres that have a
financial effect on PO Ltd.
Logical data items
* Cash & Bank balances
= Client Transactions initiated in cash centres & completed in
liquidity team managed bank accounts
= Cash/Foreign exchange Rem in/out data.
= NI Cheques remittances
« Write offs and adjustments.
* Foreign currency revaluations
= Wholesale foreign currency movements
Special requirements
The link between the SAP ADS and POL FS definition of GL
accounts will be controlled using Type A reference data
Time constraint
File will be received & processed by 07:30 on day B where day
A= Trading day
Type of Object
Electronic Data File
Outstanding Items for
Als
It is unclear if information relating client related transactions will
be recorded such that TMS can pass this data to MI. The
design of this interface will assume that a base level of
information relating to client transactions will be required such
that MI can pick up this information if required.
AIS Issued V0.1
Source SAP ADS
Destination POL FS
POL Data Model
All logical data items above equate to either:
Ledger Posting: For all value transactions
Inventory Item: For all stock transactions
Additional details relating to this information flow is in section 8.2.2.
Financial Results to ESFS
Version 1.0 Page 100/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef:
Attribute Description
Description The file will contain the summarised financial results of PO Ltd
Network as required by ESFS
Logical data items
* Movements on GL accounts, possibly split by branch and
cash centre if required.
Special requirements
None
Time constraint
File will be created on Day 1 of each period end
Type of Object
Electronic Data file
Outstanding for AIS
The current feed to ESFS is constrained by the level of detail
held on the current ledgers. The design of POL FS will provide
greater flexibility to record information in a way that fits ESFS
better. The precise requirements are still being investigated.
Source
POL FS
Destination
ESFS
POL Data Model
All logical data items above equate to either:
Ledger Posting: For all value transactions
Inventory Item: For all stock transactions
9.4 Transaction Corrections to Horizon
Attribute
Description
Description
The file will contain transaction corrections from the agents ledger.
Logical data items
= Individual transaction corrections incorporating Branch,
client/material, and instructions
Special requirements
The link between the Horizon definitions of client products and the
POL FS definitions of materials, clients will be controlled using Type
A reference data.
Time constraint
The file will be processed Daily and will be sent to Horizon for
processing each evening by 24:00
Type of Object Electronic Data file
Als Issued
Source POL FS
Destination TMS/Horizon
POL Data Model
All logical data items above equate to either:
Ledger Posting: For all value transactions
Inventory Item: For all stock transactions
Version 1.0 Page 101/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Conceptual Design
Doc POL/IMPACT/DES/***
Ref:
COMMERCIAL IN CONFIDENCE
9.5
9.6
Reference Data From NRDS
Attribute Description
Description Reference data controlled by NRDS
Logical data items
* Branches
"Clients
= Products
= Agents
= Branch Hierarchies
Special requirements
It is probable that the flow from NRDS for each of these data items
will only provide part of the data required by POL FS. POL FS will
then use internal rules or manual process to add the rest of the
data.
Time constraint
Daily
Type of Object
Electronic Data file
Outstanding for AIS
The logical data items have been identified but the components of
each data item still needs to be defined.
Als Issued — one for each logical data item
Source NRDS
Destination POL FS
POL Data Model
All Logical items map to POL Data Model entities of the same
name, except for Branch Hierarchies where there is no apparent
entity.
Reference Data To NRDS
Attribute Description
Description Reference data controlled by POL FS
Logical data items
= Chart of Accounts
Special requirements
Time constraint
Daily
Type of Object
Electronic Data file
Outstanding for AIS
The logical data items have been identified but the components of
each data item still needs to be defined.
AIS Issued
Source POL FS
Destination NRDS
POL Data Model
Chart of accounts map to Ledger Account entities
Different accounts will map to either: P&L Item account; Branch
Ledger Account; Cash & Bank account; Borrowing Investment
Account; Other accounts not specified in POL Data Model
Vel
© Post Office™ 2003
rsion 1.0 Page 102/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
9.7
9.8
9.9
Reference Data NRDS to Horizon
Attribute
Description
Description
Interface Mapping tables to control interfaces between Horizon and
POL FS.
Logical data items
Mapping database
See logical data map section 8.10.2
Special requirements
The control over the mapping table must be within NRDS.
Time constraint
Daily
Type of Object Electronic Data file
Outstanding for AIS The definition of the interface is still to be agreed and understood
by all parties.
Als Unknown
Source NRDS
Destination Horizon
POL Data Model See 8.10.2
NSSC Stock movements from WCS
Attribute
Description
Description
The file will contain stock movements from the NSSC
Logical data items
* Goods receipts and returns of stocks from/to vendors/clients
= Goods issues and returns of stocks to/from branches
»__ Write off/adjustments of stock in NSSC
Special requirements
The link between the WCS and the POL FS definitions of materials
will be controlled using Type A reference data.
Time constraint
Daily file to be processed by 7.30am on Day B where Day A is
trading day
Type of Object
The above time constraint assumes Electronic Data file
Outstanding for AIS
The component parts of the logical data items need to be defined.
Als
Issued
Source
WwCS
Destination
POL FS
POL Data Model
Logical data items will all be Inventory Item Movements
Summary Transa
ction Information to Girobank
Version 1.0 Page 103/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef:
Attribute Description
Description The file will contain the summary of transaction information relating
to Girobank.
Logical data items
« Summarised transactions quantities and values by branch, day
and product as required.
Special requirements
Currently Girobank have their specific file layouts.
Time constraint
Currently weekly
Type of Object
Electronic Data File
Outstanding for AIS
The current feed of data to Girobank is based on Cash Account
concepts and relevant reference data. This information is going to
change and discussions are required with Girobank to establish
requirements.
AlS Outstanding
Source POL FS
Destination Girobank systems
POL Data Model Ledger postings
9.10 Summary Transaction Information to NS&I
Attribute
Description
Description
The file will contain the summary of transaction information relating
to NS&l
Logical data items
* Summarised transactions quantities and values by branch, day
and product as required.
Special requirements
Currently NS&I have their specific file layouts.
Time constraint
Currently weekly
Type of Object
Electronic Data File
Outstanding for AIS
The current feed of data to NS&I is based on Cash Account
concepts and relevant reference data. This information is going to
change and discussions are required with NS&l to establish
requirements.
AlS Outstanding
Source POL FS
Destination NS&l systems
POL Data Model Ledger postings
Version 1.0 Page 104/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
9.11 Remittance Advices to Clients
AIS not being produced — not an electronic data flow
Attribute
Description
Description
The file will contain the detail of collections from or payments to
clients
Logical data items
* Summarised transactions quantities and values by branch, day
and product as required.
Special requirements
The remittance advice will be of the same layout for all clients
Time constraint
Based on settlement terms
Type of Object
Likely to be mainly paper, but can be sent electronically or by fax.
9.12 Statements to Clients
AIS not being produced — not an electronic data flow
Attribute
Description
Description
The file will contain the details of outstanding items owed to or
owing from clients
Logical data items
= Summarised outstanding transactions quantities and values by
branch, day and product as required.
Special requirements
The aim is to standardise statements to be the same layout for all
clients
Time constraint
As required — may be weekly or monthly or adhoc
Type of Object
Likely to be mainly paper, but can be sent electronically or by fax.
9.13 Stock Statements to Clients
AIS not being produced — not an electronic data flow
Attribute
Description
Description
The file will contain the details of stock movements
Logical data items
s Summarised transactions quantities by product
Special requirements
The aim is to standardise statements to be the same layout for all
clients
Time constraint
As required — may be weekly or monthly or adhoc
Type of Object
Likely to be mainly paper, but can be sent electronically or by fax.
9.14Statements to Agents
AIS not being produced — not an electronic data flow
Version 1.0 Page 105/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef:
Attribute Description
Description The file will contain the details of outstanding items owing from
agents
Logical data items
* Transaction Corrections
= Other amounts
Special requirements
The statements will be of the same layout for all agents
Time constraint
As required — may be weekly or monthly or adhoc
Type of Object
Likely to be mainly paper, but can be sent electronically or by fax.
Version 1.0 Page 106/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
9.15 Payments file to BACS
Attribute Description
Description The file will contain payment information
Logical data items * Third party bank information
* Post office bank information
s___ Payment references and values
Special requirements _I None at this time
Time constraint None
Type of Object Electronic file
AlS Outstanding
Source POL FS
Destination BACS via Prism BACS gateway
POL Data Model Ledger Postings
9.16 Enhancement to ESFS to NRDS Interface
Attribute Description
Description Reference data controlled by ESFS
Logical data items = Cost Centres
__ Internal Orders
Special requirements
Time constraint Daily
Type of Object Electronic Data file
Outstanding for AIS Definition of requirements from MI and POL FS for their
requirements from Cost Centres and Internal Orders.
AIS Outstanding
Source ESFS
Destination NRDS
POL Data Model Cost Centres & Internal order — Represent Organisation Units — in
particular Branches
Version 1.0 Page 107/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
10 Non-Functional Requirements
10.1 Volumetrics
10.1.1 Peak Day figures
Source Contracted Volume I Contracted Volume
Documents line items
Horizon 54,000 3,600,000
SAP ADS 27 24,000
WCS 4300 365,000
Bank Statements 15 1200
Clearing Transactions* 200,000
Other Manual 1000 3000
* Clearing transactions in SAP GL do not create new line items but do create a header
document.
10.1.1.1 Audit and archive
The audit requirement for business data is to keep monthly summary records for 7 years
FUJ00090148
FUJ00090148
It is not desirable from a sizing perspective to keep all this data online within the SAP database
and data archiving of the following objects will be required.
DocumentsILines ILine Items IRetention)Comments
per period
doc months
ICCA Cost Centre 10,000 15] 150,000 13INeeds to be held
[Accounting for 1 yr
IPCA Profit Centre} 10,000,000 10] 100,000,000 3INeeds to be heldI
Accounting for 1 yr
Fl (fb01) IFinance Documents} 8,320,000) 139] 1,156,480,00 13)
ie)
IMM Material Movements] 7,346,000} 137] 1,006,402,00 3
(mb01) 0
SD Sales invoices 5,320,000) 160] 851,200,000 48' 3 > MONTHS
(va01) ONLY
Storage of the archived data must be on a media that is reliable over a 7-year period.
Data that has been archived should be retrievable:
«by the end user within 5 minutes for documents that are less than 2 years old
* upon request for documents that are more than 2 years old.
The audit requirements from a technical perspective are:
e to keep a copy of all bulk data files exchanged between the POL FS domain and other
domains. The data should be the raw (unprocessed) data and be kept for 18 months.
¢ audit records of user activity within the SAP application should be created by standard SAP
functions and then stored within the SAP system
Version 1.0 Page 108/141
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
¢ audit records of support activity on the POL FS host platforms should be created by standard
Horizon functions and then stored in line with current Horizon practices
© Post Office™ 2003
Version 1.0
Page 109/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
10.1.2 Numbers of Users
For release 3 there will be 350 named users with a concurrency of 20%, where concurrency is
defined as users logged onto the system and have been active within the last 30 minutes. Users
that have been inactive for more than 30 minutes will be automatically logged off.
The end-to-end POL FS system should be designed to cater for this population of users, including
presentation, wide area network and hosting.
10.2 Sizing Assumptions
17000- 18000 documents will be received nightly, in approximately 60 files, from Horizon.
Approximately 20 documents will be received nightly in a single file from SAP ADS.
Both these must be processed by 0730 on day B; where day A = Trading day
10.3 Service Levels
Reviews of this service will be held at agreed intervals, typically monthly. The reviews with
each of Prism Alliance and Fujitsu Services, will be attended by the service managers from
POL, together with appropriate operational and technical managers. The reviews will
consider the service performance against the OLA and SLA; the impact of any forecast
service changes; open problems and any service improvements.
Availability and Reliability
The availability of the online SAP service is to be measured between 07:30-19:30 on
Monday-Friday (excl. Bank Holidays).
The service will be measured in 2 parts:
«the host service
« the presentation service
Host Service
«The host service is defined as being available if the SAP host system is available to be
logged into and there are no overnight data load jobs still processing.
« The target availability is to be 98.5% (this equates to an average of 4 hours outage per
month)
« The maximum downtime permitted during a single outage is 4 hours.
This service level target is to be measured over a period of 1 quarter
« Although the service is not measured at the weekends or bank holidays, it is expected that
the service should be available 7 days per week (07:30-19:30), except by agreement. The
windows between 19:30 to 07:30 is available for batch processing
« Support for the Service should be available during the hours of service measurement i.e.
07:30-19:30 Mon-Fri (excl. Bank Holidays)
«lt is expected that the host service should be monitored using standard SAP functionality
and that the reporting should fit in within the reporting framework for Horizon.
Client/Network Service
' The service boundary will be defined during contractual discussions
Version 1.0 Page 110/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
The client/network service is defined as the SAP client and the associated local area
networking to reach access to the service boundary’ at Huthwaite. This is covered with
another agreement.
Data Delivery Times
It is envisaged that the data delivery times will align with current LFS delivery times,
although this needs to be confirmed. Reference the SLA and associated liquidated
damages where relevant are stated in Schedule 15.
In particular, the feed from Horizon of daily cash on hand details may require some
strengthening to the current data delivery times which exist for transaction data to TIP. It
may be necessary to strengthen this (for example, utilising the current cash on hand
delivery SLA with Fujitsu supplemented by a further SLA with PRISM to ensure the end to
end processing time is met to match the standards of delivery to SAP ADS) in order to
deliver the benefits of increased control over cash movements on a daily basis. This needs
to be confirmed.
The end to end delivery time to the ledgers must also be reviewed to ensure that both the
delivery of data by Fujitsu and any subsequent processing necessary within the POL FS
ledger is completed by the time reliable ledger information is required.
The resulting reliability of the ledger entries must be maintained, i.e. the completeness of
the daily cash figures arising from the percentage delivery of transactions must be
consistent with existing levels of completeness of the current weekly cash figures.
The working assumption is that file deliveries will be in line with current deliveries:
« SAPADS file to be available to POL-FS to enable process completion by 07:30
« Horizon file to be available on the SAP host at 03:00
« All other data to be loaded into POL FS to be made available by 03:00
¢ New reference data to POL FS.
¢ Stock movements from WCS to POL FS
It is a requirement to have all the data loaded by 07:30.
The service level target is that no more than 3 failures to meet this criteria should be allowed
in any quarter.
This measurement will exclude failures caused by:
>» SAPADS files being made available after 04:00
> Failures caused by incorrect functioning of Prism application code or incorrect
configuration of the POL FS application (e.g. missing FAD)
The service level will be reviewed during the service level discussions on network banking,
where service targets may be moving to annually rather than quarterly
The following files should be produced on POL FS by midnight to enable data to be sent to
the target systems and loaded by 07:30:
>» From POL FS to ESFS
Transaction information from POL FS to clients
Transaction information from POL FS to NS&l
From POL FS to new ref data
Transaction correction files to TMS
VVVV
The BACS interface will be scheduled to run during the on-line day.
' The service boundary will be defined during contractual discussions
Version 1.0 Page 111/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
Help desks
Helpdesk support for POL FS will need to be agreed, and where necessary links between
all three systems for Helpdesk support should be established.
Service level reports
Service Level reports should be produced in line with current service level and operational
level reporting, and will be discussed at a relevant forum.
NB The resulting solution (end to end across all boundaries and suppliers, from initial data
capture to final data delivery) should not significantly impact the run times of the current
batch process, and Current operational achievements should still be met.
Service Fault Diagnosis
Key components of the system should be monitored and alerts raised if there are problems.
Diagnostic tools should be created, so that in the event of a failure, it will be possible to
identify where problems are occurring in the end-to-end service.
The boundary between Fujitsu managed systems and Prism managed systems needs to be
monitored to enable the cause of problems to be swiftly diagnosed
10.3.1 Post Office™
No Additional requirements
10.3.2 Fujitsu Services
See service levels for the Host Service under section 10.3 I
10.3.3 Prism Alliance
Same as current LFS service levels I
10.4Problem Management & Tracking
10.4.1 Incident Management
Whilst the details of incident management need to be worked through, the principle is that
PRISM will remain first port of call for end-user SAP problems, passing any calls onto
Fujitsu where appropriate.
Help desk scripts should be updated to reflect any new components introduced in
Release 3.
10.4.2 Failure Recovery
Covered in section 10.5
Version 1.0 Page 112/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
10.4.3 Backup & Recovery
All business data must be backed up daily. Backups should be kept for 4 days before
being overwritten.
10.4.4 Problem Management
PM 001 I Any known problems will be explained prior to go live and
subsequently formally handed over to POL’s Problem
Management Team.
PM 002 Problem Management requirements will be worked up and
documented within Prism OLA’s/SLA’s, with related procedures
documented
10.5 Business Continuity
Host Service
There must be contingency arrangements in place for the POL FS service.
The maximum outage during failover is 48 hours
At the end of failover the data must be fully restored, but the system can run with a reduced
service in terms of:
¢ the number of supported users
*® end-user response times
« — the time by which data loads have to be complete
Presentation Service
A disaster affecting the Huthwaite site will require failover of the presentation service (ITS and
workplace servers). During failover the presentation service should be capable of supporting 30
users, and printing may be required.
10.6 Training
Additional training is required for all POL Central finance and Transaction processing staff
who are identified as users on the POL Ledgers.
In addition to technical training it is important that these staff are given process awareness
training so they understand how their roles fit into the end to end process and what the
dependencies are.
Training will be carried out by POL, but there is a requirement on Prism to provide
Knowledge Transfer of the new system and processes.
11 Technical Requirements
The following generic architectural principals apply:
e The applications should be data driven
Version 1.0 Page 113/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
© Post Office™ 2003
The applications should be module wherever possible thereby
allowing components, such as the presentation layer, to be easily
swapped out as more suitable modules become available.
Minimisation of duplicate functions
Consolidation of related processes, to minimise movements of
data, reduce audit and reconciliation points
Adoption of commodity platform products to minimise hardware
and associated support costs and to maximise availability of
skilled resources
Usage of packages, where business requirements can be mapped
onto generic product capabilities
Clear separations of functional boundaries to retain flexibility in the
future
Version 1.0 Page 114/141
Conceptual Design
COMMERCIAL IN CONFIDENCE
FUJ00090148
FUJ00090148
Project: Automated Ledgers
Doc POL/IMPACT/DES/***
Ref:
11.1 End-to-End Architecture Diagram (Example shown below)
BRANCH
Counter
Application
Riposte
NT
Fujitsu-Siemens H/W
Fujitsu Domain
Physical View
RMG Domain
PRISM
Horizon Data Centre Domain
Huthwaite
Management Inform:
Oracle(s), HP UNIX
SAP R/3 Oracle(s) SAP R/3 Oracles) HP Hw
Solaris Solaris
Fujitsu-Siemens Hav Fujitsu-Siemens Hw
Stock
Warehouse
Oracle(s)
ses Management
Logistics ‘Transaction = HP UNIX
Feeder Management YANTRA HP Haw
Service (ine Adjustment
Oracles) Notification)
Solaris Oracle(s) Cash Mgt [XevRos]
Fujitsu Siemens Hiw Solaris Oracle(s) SAP ADS Gace
Fujitsu Siemens HAv Solaris mies
Fujitsu Siemens H/w SG)
a IBM X47
Mainframe
© Post Office™ 2003
Version 1.0
Page 115/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
11.2 Architecture Principles
11.2.1 Application
POL FS is to be built using SAP R3 V4.7 Enterprise with a based of the Retail Industry
Solution.
11.2.2 Resilience
The solution should be resilient to a single point of failure.
11.2.3 Performance
The requirement is for the ability to monitor the response times of a limited number of OLTP
transactions at the back end. When combined with monitoring of network response times this will
provide Post Office with a view of the overall response times. It is expected that standard SAP
functionality should meet the SAP back-end monitoring requirements.
There are 2 specific performance requirements:
e The service level target is for the average response time of the agreed transactions to be
completed within:
"1.5 - <WAN latency>" seconds.
where this measure is taken within the hosting environment (excluding WAN and
presentation layers).
« loading of data files as defined in the data delivery section of 10.3
Capacity management of the platform should be brought into the standard Horizon capacity
management regime.
11.2.4 Communications
Connectivity of the end-user presentation layer to the POL FS hosting service is to be channelled
through Post Office's Northern Data Centre
11.2.5 Scalability
The solution must be scalable to cope with release 3, specifically in the following areas:
e Audit - For release 3 it is expected that there will 90 days worth of online details, with records
being archived periodically
« Volumes - See section 10.1
« Numbers of users - 350 users at release 3 with 20% concurrency
The design proposal should explain how the solution will cope with an increase in the following:
« number of end users
* number of concurrent end users
¢ input data volumes
* online data volumes
whilst maintaining the contracted service levels. These will constitute the design limits in
accordance with the approach defined in PA/PER/033.
Version 1.0 Page 116/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
Ref:
Any ceiling in the solution design should be identified in the design proposal
11.2.6 Systems Management
POL FS infrastructure is expected to be part of Horizon domain and managed as such, including
initiation and control of batch jobs.
Bespoke processes such as the jobs that process the files fed from Horizon should be monitored.
It is not expected that test systems will need to set date/time to be something different from the
current date/time.
The following service level monitoring is required
« the ability to monitor the response times of a limited number of OLTP transactions at the back
end. When combined with monitoring of network response times this will provide Post Office
with a view of the overall response times. It is expected that standard SAP functionality should
meet the SAP back-end monitoring requirements.
e the availability of the service
e successful loading of the inbound interface files
« successful production and delivery of the outbound interface files
Version 1.0 Page 117/141
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc
Ref:
FUJ00090148
FUJ00090148
Automated Ledgers
POL/IMPACT/DES/***
11.3Integration & Interface
Horizon to POL/FS interfaces
SAP/ADS to POL/FS interface
POLI/FS to Horizon interface
NRDS to POL FS interface
POL FS to NRDS interface
POL FS to ESFS interface
Summary Transactions to Clients (Girobank & NS&l) interface
Payments Data to BACS interface
WCS to POL FS interface
NRDS to Horizon interface Enhance existing interface.
The types of interfaces will be defined in the associated AIS’s for each interface
11.4Other Technical Requirements
SAP Help should be made available to development and test users from within the SAP client
domain?
The SAP host must be able to communicate with the network printers in use within the SAP client
domain
All production and test end-user access will be via ITS and workplace.
Development access will be via SAP GUI (on citrix servers)
File transfer access to development and test is required for developers.
12 Security Requirements
The principle is that Horizon data centre and Huthwaite are both trusted domains and should be
operating to ISO 17799. The SAP host should be integrated into the Horizon domain as per the
principle defined in Section 5.
The requirements for security then focus on the changes brought about by the introduction of the
new SAP service and the interfaces between the 2 secure data centres. For each of these areas
consideration should be given to Identification and Authentication, Access Controls, Audit and
Alarms.
¢ SAP Application
> All persons requiring access to the POL ledgers will have individual user ID with specific
access suitable for their requirements.
>» User roles will be set up and administered in line with Consignia's "Security Operating
Standards"
» There is no requirement for secondary authentication; standard SAP passwords will be
adequate.
>» Auditing of who has done what within the application will be provided by standard SAP
functionality
? By SAP client domain this means the end user components of the SAP solution that are managed by Prism.
Version 1.0
© Post Office™ 2003
Page 118/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
¢ Support access to POL FS hosting systems should be controlled as per current Horizon
support access standards
e Support access to presentation layer systems should be controlled as per current Prism
standards
« Network
>» Access to data centres systems will be protected through Firewalls
>» Firewall logs should be monitored to detect attempts to gain unauthorised access
» IPSEC encryption to be provided by the routers between Horizon data centres and Post
Offices Northern Data Centre
12.1 Security Testing
User ID profiles will be tested as part of system and User Acceptance testing.
13 Deliverables / Work Packages
13.1 Post Office™
The conceptual design document.
Associated work packages.
AIS for Horizon to POL/FS Interface
AIS for SAP ADS to POL/FS Interface
AIS for POL FS to Horizon
AIS for NRDS to POL FS
AIS for POL FS to NRDS
AIS for POL FS to ESFS
AIS for WCS to POL FS
AIS for NRDS to Horizon — enhancement to existing interface
AIS for Summary Transactions to Clients (Girobank & NS&l) interface
13.2 Prism Alliance
13.2.1 POL FS Development
Prism Alliance should develop a design proposal to meet the requirements set out in this
document and provide the post office with a commercial proposal which will specify the
costs, time-scales and resource implications for progressing to the solution build and test
stage, and the implementation and rollout stage.
13.2.2 SAPADS Development
There was an initial assumption that there would be no changes required for SAP ADS.
Since several processes start on SAP ADS and finish outside SAP ADS it is necessary to
pick up these transactions individually. It is not easy to do this and keep the financial
integrity of an interface without making some changes to SAP ADS.
Prism Alliance will investigate and recommend changes to SAP ADS that do not effect the
key operation of the Cash Centres but will ensure financial integrity of SAP ADS and the
interface to POL FS.
Version 1.0 Page 119/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
Prism Alliance should develop an interface from SAPADS to POL FS for cash centre
related data
13.2.3 End to End Integration, Testing and Approach
Post office will determine how this task is carried out.
See Section 17
13.2.4 Managed Service
Prism Alliance shall provide service support for the SAP elements of the POL FS
application
13.2.5 Documentation
Prism Alliance shall update relevant current and produce any new contract controlled
documents in support of the SAP/ SAP elements of the POL FS application
13.2.6 Internal Processes & Procedures
Prism Alliance shall update where necessary, any internal processes & procedures, in
order to support the SAP elements of the POL FS application.
13.3 Fujitsu Services
13.1.1 Financial Ledgers Development
Fujitsu Services will develop the extract file for the daily feed from Horizon to POL FS
Fujitsu Services will develop a solution on TMS and Horizon to receive and present the
transaction correction files to the branches in line with AIS and Branch Trading
Processes.
13.1.2 End to End Integration, Testing and Acceptance
Post office will determine how this task is carried out.
See Section 17
13.1.3 Managed Service
Fujitsu Services shall provide service support for hosting the POL FS application.
13.1.4 Documentation
Fujitsu Services shall update relevant current and produce any new contract controlled
documents in support of the Horizon elements of the POL FS application.
13.1.5 Internal Processes & Procedures
Fujitsu Services shall update where necessary, any internal processes & procedures, in
order to support the Horizon elements of the project.
Version 1.0 Page 120/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
14 Planning
14.1 Timescales
Refer to Release 3 and S80 project plans
14.2 Dependencies
The Financial ledgers are dependent on the completion of the Branch Trading Development
in order to provide accurate data and enable effective operation of the Transaction
Correction process.
There is a dependency on SAPADS to ensure that there is a feed of cash centre related
data
There is a dependency on the New Reference Data System to provide an interface
mapping tool to control the interfaces between Horizon and POL FS. The majority of
mapping relating to this interface will take place in Horizon.
Version 1.0 Page 121/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
15 Acceptance
Acceptance takes place upon determining that the Automated Cash & Bank ledgers solution is fit
for purpose. Acceptance for each Requirement will be conducted by one or more of the following
methods: -
1. Document review
This method will comprise a document review by Post Office Ltd. of the relevant section
of a document or documents. The classification and contractual status of any documents
used for this purpose will remain unchanged.
2. Post Office Test
This method will comprise tests that run and managed by Post Office Ltd. The actual
method of testing, which may utilise the Post Office Ltd. End-to-End test environment, will
typically be used for those aspects of the solution that can only be verified as part of an
overall Post Office End-to-End environment. The Post Office Test could also include
document review.
3. Statement of fact or obligation
This classification will be used for those Requirements that represent an existing Prism
obligation, or where the solution to a Requirement is self-evident and does not lend itself
to formal proving.
16 Testing
NB: E2E references within this section refer to E2E testing and not the E2E Programme.
16.1.1 Testing Statement
The testing plan will be based around the following PO Ltd testing statement
Testing will be able to confirm the acceptance criteria for some requirements have been
met during the various test phases. The criteria and the targeted test phase should be
identified during the requirements analysis phase. The testing team should assess the
testability of the acceptance criteria during the Requirements reviews.
An appropriate Test Strategy will be developed to reflect the release contents.
This will include some or all of the following testing phases.
16.1.2 Internal Functional Testing
Gaining assurance of main suppliers internal functional testing via: -
o Review suppliers internal test plans/ scripts for completeness
o Review suppliers internal test results / progress reports
o Review suppliers internal testing fault logs for impact
Version 1.0 Page 122/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
16.1.3 Non Functional Testing
Due to the nature of this type of testing the aim would be to achieve this via engagement
with the supplier in: -
Supplier document reviews
Review of supplier test plans / scripts for completeness
Witness specific key tests during a supplier testing cycle
Review supplier test results
Review supplier test fault logs for impact
00000
16.1.4 Interface Testing
Lead or Support Suppliers through the execution of Direct Interface testing between two
suppliers e.g. Lead - Horizon to SAP/ADS
o Review or develop and agree Interface scripts between two supplier domains
Support or coordinate set — up of test environments
Support or coordinate the provision of Required Ref Data
Support or execute where appropriate the tests
Review the test results including any faults
0000
16.1.5 E2E Integration Testing
This phase is where POL would lead, supported by suppliers, in demonstrating the
successful connection of all the appropriate systems (test versions) in the releases E2E
solution including carrying out some E2E test transactions to confirm the readiness to
enter the POL E2E functional testing cycles.
16.1.6 E2E Functional Testing
This phase is where POL would lead, supported by suppliers, in demonstrating through
short “days in the life of the POL business” cycles that the revised systems interact
correctly in an E2E manner and with the revised business process and procedures.
This is also to assure POL that the changes to current systems and the introduction of
new systems has not impacted upon the businesses operation including E2E financial
aspects (accounting, reconciliation, settlement, remuneration) have been and can
maintained during live operation. E2E Management Information is maintained or new
information reflects the requirements and business needs.
Successful completion of this phase would lead to the introduction into the live
environment via one or more of the following: -
© apre-pilot (transactions carried out in the passive Post Office)
© pilot (small number of outlets)
© go-live.( rolled out to the full estate)
16.1.7 Pre-Pilot
This final testing phase is whereby a “live” Post Office is used to test that the connectivity
of the live E2E systems has been achieved and that a small number of transactions
representing the changes can be carried out and report correctly in accounting and
management information terms. Completion of this final phase should be the point of
handover to the Implementation team / phase.
Version 1.0 Page 123/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
16.1.8 Counter & Interface Testing
« E2E non-functional tests for performance, availability, reliability, volumes etc
« Counter sales tests that affect the transactions, to ensure that appropriate data is
transferred to back office systems.
16.1.9 Design / Process Walkthroughs
e E2E Design and Process walkthroughs may be used.
An approved test strategy covering all test stages from component testing
to direct interface testing must be agreed between all parties.
Up to date results from the various testing phases must be shared
promptly with the Post Office, in order to confirm in the phases leading up
to the completion and implementation, that the solution is fit for the live
environment, and that any risks are known and can be assessed.
Fujitsu Services and Prism Alliance must support the various test phases
before the POL FS solution is implemented.
Version 1.0 Page 124/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
17 Implementation & Migration
17.1 Co-ordination of the feeds into POL FS
General
The migration of the financial ledgers from CBDB to POL FS must occur as at the end of
a financial period. The start of all feeds into POL FS must be consistent with this
chosen date.
Horizon
The roll out approach of S80 Horizon will govern the cutover strategy required to ensure
that reconciling items are not investigated unnecessarily.
SAP ADS
The feed from SAP ADS will be turned on as a single event rather than cash centre by
cash centre. It is important to co-ordinate this financial period end.
Version 1.0 Page 125/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
18 Appendix A — Requirements Catalogue
Details of the acceptance method can be found in section 16.
Program Req ID Supplier IX Ref to I Description
Req ID This CD
FIH-001 FIH 001 Prism 44 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
I reduced duplication and requirement for reconciliation I
FIH-002 FIH 002 Prism 44 . Introduction of a Client Ledger, Agent Ledger, Stock Ledger to enable standard procedures
for Debt Recovery and monitoring. To enable the capture, validation, verification and
7 I _ I _ __I correction of client transaction data.
FIH-003 FIH 003 Prism 44 I Produce POL Ledgers to report P&L and BS for POL in so far as the transactions are handled
po I_I within the POL environment with a stream of data from branches and cash centres
FIH 004 I Prism 44 The Cash and Bank account values, from ledger implemented in S60, will not be overwritten I
with CLASS values at S80 implementation. A reconciliation will be undertaken between POL
- I LFS and CLASS as part of cutover activities
ASS 001 POL 4.2 I Supplementary document matching will not take place in POL FS and will largely be stopped.
ASS 002 I POL 4.2 Matching of client transaction data to POL FS data will not take place on POL FS. This will
take place in MI where necessary. ee ee __ I
ASS 003 I POL 42 Matching of client summary data to POL FS data will be done on a risk based approach.
ASS 004 I POL 4.2 Reporting of transaction data to clients will not take place on POL FS. This information will
I _either be fed to clients directly (e.g. AP/Banking), or is available from MI. I
ASS 005 I Prism 4.2 Depending upon where it resides at the time of S80 implementation, Foreign Exchange
movements to/from cash centres will be received by POL FS either by an automated feed
I I from SAP ADS or by the manual input of output from STAMPS.
ASS 006 I Prism 4.2 Client managers will be involved in establishing revised product propositions in response to
changes being introduced by Impact. Legacy systems may need to be retained if they provide
non POL FS related services to clients that cannot be managed away.
ASS 007 I Prism 42 It is assumed that an electronic feed of stock movements to/from the branch network will be
provided by the WCS System that should have replaced the STAMPS System before S80
I__I implementation. ___ a — I
ASS 008 I Prism 4.2 Reporting of data to clients from POL FS will be at the maximum level of Branch, Trading Day
L I ee &Product. ee ee ee
Version 1.0 Page 126/141
© Post Office™ 2003
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
POFS 001 I Prism 43 POL FS will be the auditable financial ledgers for Post Office Ltd Network. I
POFS 002 I Prism/ 4.4 It shall be possible to audit movements within POL FS by branch back to Horizon
Fujitsu I
POFS 003 I Prism 4.4 It shall be possible to reconcile movements within POL FS by cash centre back toSAP ADS __
POFS 004 I Prism/ 4.4 Technical requirement: to keep a copy of all bulk data files exchanged between Horizon I
Fujitsu domain and Prism domain. The data should be the raw (unprocessed) data. I
POFS 005 I Prism 4.4 Technical requirement: audit records of user activity within the SAP application should be I
created by standard SAP functions and then stored in line with current Horizon practices I
POFS 006 I Prism/ 4.4 Technical requirement: audit records of support activity on the POL FS host platforms should I
Fujitsu be created by standard Horizon functions and then stored in line with current Horizon I
practices I
POFS 007 I Prism 46.1 The POL ledgers will be built in addition to and independent of other SAP systems I
I
TEC-001 I TEC 001 I All 45.2 I The applications should be data driven
TEC -002 I TEC 002 I All 4.5.2 The applications should be modular were ever possible thereby allowing components, such as I
the presentation layer, to be easily swapped out as more suitable modules become available. I
TEC - 003 I TEC 003 Prism 4.5.2 Minimisation of duplicate functions I
TEC -004 I TEC 004 Prism 4.5.2 Consolidation of related processes, to minimise movements of data, reduce audit and I
- - [reconciliation points I
TEC -005 I TEC 005 I Prism Adoption of commodity platform products to minimise hardware and associated support costs I
es ee ___I and to maximise availability of skilled resources
TEC -006 I TEC 006 I Prism Usage of packages, where business requirements can be mapped onto generic product I
Capabilities I
TEC -007 I TEC 007 Prism 4.5.2 Clear separations of functional boundaries to retain flexibility in the future I
TEC -023 I TEC023 I Prism I45 _I Integration with SAP ADS I
I
TEC -025 I TEC 025 I Prism 45 Integration with ES-FS I
TEC - I TEC 025a I Prism 4.5 Integration with Horizon
o25a I I its I
TEC-026 I Prism 4.5 Integration with NRDS I
TEC 027 Integration with WCS I
TEC 028 Interface with Girobank I
TEC 029 Interface with DNS I
Version 1.0 Page 127/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
TEC 030 Interface with NS&I
TECO31 Prism 45 I_ Integration with BACS _ ee __
ACM-001 ACM 001 _I Prism 5.1 Any individual component of the programme must conform to the POL Strategic Data Model
CSH-001 CSH 001 Prism 6.3 To implement a client ledger that accurately identifies PO Ltd’s liability to and from clients and
enables accurate, auditable, and timely settlement in accordance with contractual
requirements.
CSH-002 CSH 002 I Prism 6.3 To receive a daily interface of summarised transaction data, from Horizon, by client or product.
CSH-003 CSH 003 I Prism 6.3 To refer to information about transactions from clients in order to resolve any disputed items
and determine true liability. Summary available from POL/FS detail from Data Warehouse
CSH-004 CSH 004 I Prism 6.3 To receive a daily interface of summarised transaction data, from SAP/ADS, by client or
es ee ee product,
CSH005 I Prism 6.3 To calculate, pay / receive and account for Client settlements based on the contractual data
stream, being any combination of:
¢ Horizon
¢ SAP ADS (eg Corporate deposits)
e Client data (eg Camelot)
e Other existing contractual stream (e.g. BBC non bar coded licences)
¢ Stock adjustments from NSSC
CSH 006 _I Prism 6.3 To pay / receive settlements based on estimates and / or including standing deposits
CSH 007 _I Prism 6.3 Settlement facility to be available by 7:30 am in support of client settlement terms
Cs 001 CS 001 Prism 6.3 . A daily view of summarised balance (value and volume) by client, by product, by branch or
cash centre, and by day.
CS 002 CS 002 Prism 6.3 Ability to split client balances, when a client has several products or contracts with different
7 I terms of payment, in order to map into different sub accounts in the ledger
CS 003 CS 003 Prism 6.3 The ability for each trading day to have a unique document entry
Version 1.0 Page 128/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
CS 004 CS 004 Prism 6.3 The ability for non-polled offices transaction data, once received, to be:
e Accounted for in the current accounting period based on posting date
e Recorded against the appropriate trading dates
Settled to clients based on trading date
CS 005 CS 005 Prism 6.3 The ability for differentiation between trading date and posting date.
CS 006 CS 006 Prism 6.3 The ability to receive client summary reports, by volume and value, for Automated Payment
I I clients. These will not be held in POL FS.
CS 007 CS 007 Prism 6.3 A mechanism to be able to trace disputed totals back to transaction level, on MIS, in order to
resolve and correct information at the appropriate point to amend ledgers, and reporting or
I_management information.
CS 009 Prism 6.3 Ability to compare the values of settlement made based on client against actual data from
Horizon for the equivalent period. POL FS will enable comparison at a daily branch and
product level for all such clients. There will be the ability to perform detailed transaction
I comparison butthis willnotbeon POLFS.
CS 010 Prism 6.3 The ability to provide a generic solution for the main proportion of clients and only build
exception processes when necessary
cs 011 Prism 6.3 . To be able to settle (pay and receive) by contractually required methods of payment:
« BACS
¢ CHAPS
« Swift
e Cheque
Direct Debit (payment receipt only)
CS 012 Prism 6.3 The ability to track payments made on estimates to compare actual to estimates, via a holding
account or similar solution for client related data.
CS 013 Prism 6.3 The ability to provide client reports based on summary volume and value for each defined
es ee I product,
CS 014 Prism 6.3 The ability to provide contractual client reporting. This may be achieved by a mixture of
POL/FS and Data Warehouse reporting.
Version 1.0 Page 129/141
© Post Office™ 2003
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
FUJ00090148
FUJ00090148
CS 015
I CS 017
Prism
Prism
6.3
16.3
The ability to adjust settlement and account for discrepancies identified from:
¢ Client invoices or data mismatches with Horizon transactions
e Transaction Corrections (covering customer, supplier and branch queries)
¢ Banks (unpaid cheques & Data Reconciliation Service adjustments)
¢ Estimating differences
accordance with client’s individual settlement terms.
I Settlement process, to include adequate control procedures, and to pay amounts due inI
CS 018
Prism
6.3
The ability to amend settlement for non core charges such as commission and interest
charges and account for these accordingly.
DRH- 001
DRH- 001
Prism
6.4
To implement a debtor’s ledger (accounts receivable), which accurately identifies amounts
owed to PO Ltd 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
DRH 002
Prism
6.4
To receive, as part of the Horizon daily interface, details of debt recovery items and results of
debt recovery action e.g. cash receipts by debtor from the POL ledger entries.
DRH - 003
DRH 003
Prism
6.4
To be able to record debt recovery plan decisions, and action taken so as to manage debt
recovery and document stages of escalation taken.
© Post Office™ 2003
Version 1.0
Page 130/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef:
DRH- 004 I DRH 004 I Prism 6.4 To be able to refer to information about transactions both in MIS and directly entered trading
transactions with debtors, in order to resolve any disputed items and determine true amount
recoverable
NB If amounts owed to the PO but still under investigation are recorded outside of the debtors
ledger but within the Transaction Correction area of POL FS, to be able to manage these as if
they were on the debtors ledger i.e.
« to accurately identity to branch,
e to know which date they relate to and therefore which agent and the time outstanding
ie age,
e to refer to information for investigation purposes and
¢ to record action taken by individual operator.
DRH-005 I DRH 005 I Prism 6.4 To be able to generate identified transaction errors, to be fed back electronically to Horizon, if,
as a result of investigation, debts need to be transferred and corrected within a branch liability
DRH-006 I DRH 006 I Prism 6.4 To be able to view debtor credit history in order to assess credit worthiness.
DRH - 007 I DRH 007 I Prism 6.4 To be able to assign appropriate credit terms to different debt items e.g. 30 days for counter
transaction errors, 45 days for loans to SPMs
DRH - 008 I DRH 008 I Prism 6.4 To be able to assign different agents/branches to a central “head office” payment point in the
instance of multiples who require a central authorisation for settlement to POL.
DR 001 DR 001 Prism 6.4 A daily view of outstanding debtor balances (or suspense items) and the history of
I I_management for live items
DR 002 DR 002 Prism 6.4 Ability to age debt (or suspense items) so as to manage over due items.
I DR 003 ‘DRO0O3 I Prism I 6.4 IA 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. DR 004 Prism 64 A flag needs to be set when it is known that an office is to be closed, and may this may be
bo I reported on. The information will come fromNRDS.
Version 1.0 Page 131/141
© Post Office™ 2003
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
FUJ00090148
FUJ00090148
DR-005
DR 005
Prism
6.4
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, and may this may be reported on.
DROO6
DR 006
Prism
6.4
To be able to produce debt recovery reporting such as —
Debt Recovery Case Management By branch, by branch type, by Agent name, by product (by
client), by age of debt
High value debt (e.g. all outstanding debt which exceeds a defined limit, by branch)
Debt Recovery repeat offenders (problem offices)
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
Former Subpostmasters accounts held including Branch, Agent name, Age of debt, Dispute
details, Losses (write off)
Disputed debt by branch, by client (e.g. Giro)
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
DROO7
DR 007
Prism
6.4
Ability to search on a particular field (i.e. Agent name) and be able to track status, audit log
entries
DROO8
I DROO I
DR 008
DR 009°
Prism
Prism
6.4
6.4
Ability to produce invoices for transaction corrections to be sent to central “head office” for
I multiples in order for central settlement
Ability to record details against individual exception (Debt Recovery Case Management) to
track progress through investigation and towards resolution. Freeform text field plus CACM
operator details, time and date stamp for audit requirements. Measurement against agreed
timescales.
DR 010
Prism
6.4
Ability to record Agent's debt from:
¢ Actioned Transaction Corrections — automated from Horizon interface
Other debts as identified - manually entered
DR 011
Prism
6.4
Ability to record reductions in debt on agent’s account based on:
e Payment by Credit Card
« Deductions from payroll
CHH-001
CHH 001
© Post Office™ 2003
Prism
Version 1.0
6.5
_cash position for entry into the cash ledger (Release 1)
SAP/ADS to make available, by cash centre, to the POL Financial System the daily end of day
Page 132/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
CHH-002
CHH-003 —
CHH-004
CHH 002
CHH 003 ~
CHH 004
Prism 6.5
‘Prism =I 6.5
Prism I 6.5
5 I SAP/ADS to make available, by cash centre, to the POL Financial System the summarised I
I daily client related transactions, (value and volume), by client for entry into the client ledger
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 (Release 1)
SAP/ADS to undertake the summarisation of required data, to an agreed level, prior to entry
into the cash and client ledgers.
CHH-005
CHH 005
Prism 65
The interface will provide all transactions which affect cash and near cash values of the cash
centre. For example: -
Inward and Outward to POL
Inward and Outward to Fl's
Inward and Outward to Customers/Clients
Inward and Outward to 3 Party
Cash centre adjustments
Cash centre discrepancies
Cheque remittances
Cheques on hand
CHH-006
CHH 006
Prism 6.5
The interface will provide a snapshot of all transactions at approx midnight and must be
available within the POL FS by 07:30 the following day
CHO01
CH 001
Prism 6.5
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.
The Trading Statement is being developed independently of POL FS by CL&S.
© Post Office™ 2003
Version 1.0
Page 133/141
FUJ00090148
FUJ00090148
© Post Office™ 2003
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef:
SRH-001 SRH 001 I Prism 6.6 To provide end to end visibility of the stock movements from point of entry (whether direct to
branch or via the National Secure Stock Centre) until sale, loss or return.
SRH-002 SRH002 I Prism 6.6 POL FS MM module to accept a daily interface of stock sales in order to maintain accurate
link between stock movements and stock sales.
SRH-003 SRH 003 I Prism 6.6 POL FS MM module to accept a daily interface of stock adjustments at the branches, from
stock declaration process
SRH-004 SRH 004 I Prism 6.6 To provide an interface of stock at National Secure Stock Centre, identifying stock
discrepancies, for despatch to POL FS MM module. _
SRH-005 SRH 005 I Prism 6.6 To provide auditable balances of stock throughout the network for probity and audit purposes
SRH 006 I Prism 6.6 Provide a means of controlling holdings and movements of stocks that have an intrinsic value (both POL
ee _I and client owned) without adding additional complexity to operational procedures.
SRH 007 Prism 6.7 POL FS will provide a way of reporting stock remittance discrepancies (i.e. volumes rem'd out to
volumes notified as received), that supports their easy identification for resolution purposes
SR 001 SR 001 Prism 6.6 The Horizon system to make available to the POL FS MM module details of identified stock
discrepancies by volume, and value, (where relevant).
SR 002 SR 002 Prism 6.6 The Horizon system to make available to the POL FS MM module the daily movements of
stock into and out of branches by volume. These must include both internal and external
remittances.
SR 003 SR 003 Prism 6.6 . The Horizon system to maintain link between stock movement and stock sales and make
available to the POL FS MM module the daily sales of stock.
SR 004 SR 004 Prism 6.6 The National Secure Stock Centre to interface identified stock discrepancies by volume, and
value (where relevant) in order to identify stock adjustments in the POL FS MM module.
SR 005 SR 005 Prism 6.6 IThe National Secure Stock Centre to make available to the POL FS MM module 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.
Version 1.0 Page 134/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
SR 006 SR 006 Prism 6.6 The POL FS MM module to hold information by stock type in order to inform POL FS of all
balance sheet impacts.
SR 007 SR 007 Prism 6.6 POL FS MM module to hold value of all stock, which has a balance sheet impact, by stock
item.
SR 008 Not To identify instances of obsolete stock which should have been returned to National Secure
included Stock Centre
in S80 CD
BDC 001 Prism 6.7 Individual calculated stock values to be held on POL FS by Branch, on Day B:
e Day A’s individual currency value (quantity, e.g. $500) — these can be up to 14
characters long; and
¢ Day A's Sterling equivalent value (e.g. £250) at Day A Spot Rate. POL Finance and Audit
will approve the solution for achieving this.
The daily movement in foreign currency held by individual currency will be received as part of
the daily interface from Horizon.
BDC 002 I Prism 6.7 Stock quantities (e.g. $300) of Travellers cheques, by currency and branch to be held within
POL FS in MM module (not valued)
BDC 003 I Prism 6.7 Margins and Commissions on transactions (Sell and Buy) are to be posted to an appropriate
settlement account for the Bureau Joint Venture.
TOY BDC 004 I Prism 6.7 Stock revaluations to be recorded separately in POL FS. balance.
BDC 005 I Prism 6.7 Currency transfers between the Cash Centre Network and the Client are to be included within
the POL FS Balance Sheet, with postings to a Client Settlement Account where appropriate.
BDC 006 I Prism 167 I Management information in support of individual inventory management capability will be
available within POL FS (e.g. stock : sales ratios by Branch; stock holdings by branch or
branch hierarchy)
BDC 007 ‘I Prism [67 I POLFS reporting capability to be accessible within the Cash Centre Network.
BDC 008 I Prism 167 I Stock adjustments to be recorded separately in POL FS.
Version 1.0 Page 135/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
BDC 009 Prism 6.7 Currency return movements from the NSSC to First Rate will be used to adjust settlement to this Client.
BDC 010 I Prism 6.7 To support the future inventory management of foreign currency, individual branch holdings of individual
foreign currencies will be able to be provided to SAPADS on a daily interface. If constraints, this could
be for selected currencies (e.g. Dollar and Euro) and/or branches.
NRDS 001 I Prism 6.8 NRDS to provide reference data shared by multiple systems to POL FS
NRDS 002 I Prism 6.8 NRDS to accept reference data mastered in POL FS that is required for interface data
mapping — — — I
NRDS 003 I Prism 6.8 NRDS to provide a data mapping facility to enable interfaces between significant systems to
_ I be controlled using reference data rather than hard coding 7 _
NRDS 004 I Prism 6.8 NRDS interface to Horizon to be enhanced with various data objects including interface data
mapping logic.
NRDS 005 I Prism 6.8 A process will be developed to ensure that WCS and POL FS reference data are consistent or
comprehensively mapped in support of the complete interface of stock movements.
FI-001 Covered Prism 6.3 A daily view of summarised balance by client, by branch or cash centre, and by day.
by CS001
Fl-002 Covered Prism 6.3 Ability to split values, when a client has several products with different terms of payment, in
by CS002 order to map into different accounts in the ledger.
Fl-003 Covered Prism 6.3 The ability for each trading day to have a unique line.
by CS003
Fl-004 Covered Prism 6.3 The ability for non-polled offices transaction data to be summarised into the relevant trading
by CS004 day when next polled.
FI-005 Covered Prism 6.3 The ability for differentiation between trading date and posting date.
by CS005
FI-007 —'I Covered I Prism 63 To be able to determine the amount due to a client using payment terms agreed with client
by CS 018
Fl-008 Covered Prism 6.4 To provide information of aged balances
by DR 013
Fl-009 Covered Prism 6.3 To enable payments to/from clients with functionality for matching and closing paid items to
by CS19 leave open items for management of debtors/creditors
FI-010 Covered Prism 6.4 To be able to produce correspondence to chase outstanding items e.g. statements, reminder
by DR012 letters
Fl-011 Covered Prism 6.4 To process agent debt items
by DROO1
Version 1.0 Page 136/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
FI-012 Covered I Prism 6.4 Allow matching to enable management of open items
by DROO4
FI-013 Covered I Prism 6.4 To be able to produce correspondence to chase outstanding items e.g. statements, reminder
by DROO9 letters
Fl-014 Covered Prism 6.4 To provide information of aged balances
by DRO15
FI-015 FIL015 Prism 6.2 To produce a set of auditable accounts within the framework of the Chart of Accounts
specified
Fl-016 FLO16 Prism 6.2 To enable matching of suspense items for debt recovery purposes and error handling
FI-017 FI017 Prism 6.2 To enable the reporting of stock values in the relevant balance sheet accounts (this will cover
the Stock Ledger)
FI-018 FL018 Prism To consolidate information from SAP ADS financials to report the POL accounts
F019 I FL019 I Prism _ _____I To account for business transactions which will populate the tradingledger
FI-020 F1020 Prism To have visibility of branch transactions by day (this will cover the Branch Ledger)
FI 021 Prism Monitoring of system rejections to ensure that data is resent and processed or accepted
successfully
FI 022 Prism 61 System Management controls e.g. access levels, user ID’s, passwords etc.
FI 023 Prism 61 Ability to monitor interfaces received and processed or rejected, and extracts produced
including reconciliation of file interfaces across systems (i.e. data received by POL FS from
TMS also received by Data Warehouse). Where rejections occur, error messages should be
produced, indicating reason, to aid investigation.
MI 100 Prism 8.9.2 Information required by Audit for issued error details, errors BTA and errors not Network
Reinvention offices
MI 101 Information to Multiples Partners regarding outstanding, issued and BTA errors.
MI 104 Ability to produce data files or reports for clients as defined within contractual agreements.
For example volume and value of transactions, customer details if applicable, product
breakdown by volume and value, details of adjustments made, data mismatches between
client supporting document stream and transaction stream, method of payment details.
Example clients are Local Schemes, Department of Work and Pensions, Girobank, NSB,
UKPS, AON, First rate, DVLA, Department of Health, Inland Revenue.
© Post Office™ 2003
Version 1.0
Page 137/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
MI 114 Prism 8.9.2 Volume and value of outstanding exceptions by branch, by age, by value I
I
MI 115 Prism 8.9.2 Volume and value of issued errors by product or branch I
I
MI 117 Prism 8.9.2 Number and value of maintained errors and write offs by product
I
MI 118 Prism 8.9.2 Ability to pull off statistics regarding team performance (exceptions created, exceptions I
issued, exceptions cleared, exceptions outstanding etc). Ability to remove from one teams
statistics and add to another team as the exception passes through the process. I
I
MI 122 Prism 8.9.2 Debtor days by client and product and trend analysis monitoring I
I
MI 123 Prism 8.9.2 Creditor days by organisation and product and trend analysis monitoring I
MI 124 Prism 8.9.2 Errors produced for creditors and debtors — issued or resolved, number and value, by client I
and product.
I
MI 125 Prism 8.9.2 Progress of exception handling measured against target (failures to issue or clear in x number I
of days)
OS [MI126 I Prism IAgeddebtproflebynumberandvalue = ss sss—sSSC
I
MI 127 Prism 8.9.2 Debt as a percentage of sales/transactions by product I
I
MI 128 Prism 8.9.2 Monitoring of percentage of debt recovered and outstanding I
I
MI 129 Prism I 8.9.2 Bad debt provision monitoring I
I
MI 130 Prism 8.9.2 Ability to pull off ad hoc reports selecting required data fields from available list and defining I
format as required.
I
MI 134 Prism 8.9.2 Ability to run batch reports to defined timescales and formats as required.
J
Version 1.0 Page 138/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
MI 132 Prism 8.9.2 Volume and value of transactions and sup doc information to be 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 Prism 8.9.2 All created exceptions to be reported by transaction, by product, by branch. All outstanding
exceptions to be reported by transaction, by product, by branch.
I MI134-——«I Prism=—*I 8.9.2. -_—_—I_ Details of cleared exceptions to be archived but still accessible to provide a rolling 12 month I
view.
MI 136 Prism 8.9.2 Ability to flag branches on exception reports that require priority attention or specific action
(e.g. A = Network 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 139 Prism 8.9.2 Ability to report Debt Recovery Case Management By branch, by branch type, by Agent name,
by product (by client), by age of debt.
MI 140 Prism 8.9.2 Report on high value debt (e.g. all outstanding debt which exceeds a defined limit, by branch)
MI 141 Prism 8.9.2 Report on Debt Recovery repeat offenders (problem offices)
MI 142 Prism 8.9.2 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
MI 143 Prism 8.9.2 Former Subpostmasters accounts held including Branch, Agent name, Age of debt, Dispute
details, Losses (write off). Ability to search on a particular field (i.e. Agent name) and be able
to track status, audit log entries
MI 144 Prism 8.9.2 Ability to identify specific types of debt e.g. Invoices debt — Licence fee, ISIS, Shortages, by
agent, by branch, by age of debt
MI 145 Prism 8.9.2 Disputed debt by branch, by client (e.g. Giro)
Version 1.0 Page 139/141
© Post Office™ 2003
FUJ00090148
© Post Office™ 2003
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
MI 146 Prism 8.9.2 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
MI 147 Prism 8.9.2 Data archiving ability
MI 148 Prism 8.9.2 Ability to access archived data easily and run reports by transaction, by branch, by product, by
client as required
MI 151 Prism 8.9.2 Ability to schedule regular report production. Ability to monitor production of scheduled
reports.
MI 152 Prism 8.9.2 Supporting document or client level adjustments. By branch, by product, by value, by number.
To include date of adjustment, user details and reason code for adjustment.
MI 153 Prism 8.9.2 Ability to undertake trend analysis in order to aid forecasting of the future value of transactions
(e.g. DNS, Girobank, DVLA)
MI 154 Prism 8.9.2 Ability to undertake trend analysis in order to aid prediction of client for ESFS
MI 155 Prism 8.9.2 Ability to identify and report the current outstanding balance within each ledger.
MI 157 Prism 8.9.2 Ability to identify and report stock holdings by client, by product, by denomination (e.g.
Vodaphone phonecards, £5, £10 etc.)
IMl159 I Prism I _ Ability to produce reports to aid reconciliation of ledgers and substantiate ledger balances __
MI 161 Prism Ability to provide verification of accounts — Erst & Young Audit requirement
MI 164 Prism 8.9.2 Ability to identify cash and stock holdings by product, by branch
MI 165 Prism 8.9.2 Ability to produce statement of accounts for each client including brought forward figures,
sales, settlements made and a closing balance.
MI 167 Prism 8.9.2 Ability to identify cash remittance in transit values by product.
Version 1.0 Page 140/141
Conceptual Design Project: — Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
FUJ00090148
FUJ00090148
MI 168
Prism
8.9.2
Summary report of data posted to ledgers and interfaced to ESFS by value of debits/credits
against each ledger code.
MI 171
MI 172
Prism
Prism
8.9.2
89.2
Daily, National summary of transactions, by client, by product, by method of payment. Split by
deposits and withdrawals (rather than net position).
I Updated transaction data received from Non polled Offices to have indicator flag applied.
MI 173
Prism
8.9.2
Ability to track KPIs for the Cash Accounting and Cash Management teams, against (3 levels
of summarisation)
«individual target,
e team target and
¢ group target.
Broken down by
e Exception type.
e By product,
¢ Resolution reason
In addition it must be possible to determine the
e Error clearance rate (per person per week)
e Average time spent at each stage of the process by product by the individual.
The targets must be parameter driven and it must be possible to group products together and
report as above against targets
MI 174
Prism
8.9.2
Ability to carry out Rota Checking. The rota checks must be data driven and the outlets
selected will vary over time. This is in support of Rota Checking Process.
© Post Office™ 2003
Version 1.0
Page 141/141
Conceptual Design Project: — Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
FUJ00090148
FUJ00090148
MI 1001
Prism
8.9.3
Ability to produce reports of volume and value
e by organisation,
By product,
by client,
by time
By branch
By group of branches
By cash centre area
Method of payment
The reports should be capable of delivery at the transactional data level
MI 1002
Prism
8.9.3
Ability to identify top sellers, worst sellers write-off, wastage for particular products by time and
organisation.
MI 1003
Prism
8.9.3
Ability to pull off adhoc reports by selecting required data fields and defining required format
MI 1004
Prism
8.9.3
Provision of information regarding office opening hours, closures and relocations to various
internal parties and clients, replacing report ‘TP 129”
M1006 I
Prism
8.9.3
Ability to produce value and volume of exceptions (transaction corrections) for historic
reporting and trend analysis
e By transaction type
e By product,
¢ By organisational unit,
e By exception status (e.g. created, cleared, outstanding),
« Period
Against total
MI. 1009
8.9.3
Ability to run batch reports to defined timescales and formats.
MI 1010
8.9.3
Ability to identify and report on multiple transactions (e.g. multiple AP transactions carried out
against the same customer reference). Based on an OPTIP report that provides information of
this nature (1958 - Multiple Transactions Report).
I MI1011
8.9.3
Archived data should be held for up to 4 financial years.
© Post Office™ 2003
Version 1.0
Page 142/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/**
ef:
MI 1012 Prism 8.9.3 The ability to retrieve both transaction and summary level archived data in-line with the current
data retrieval SLA for OPTIP.
MI 1013 Prism 8.9.3 The ability to hold transaction data for up to 3 months on line.
MI 1015 Prism 8.9.3 Ability to browse details of all products and all clients including mapping of products to clients.
MI 1017 Prism 8.9.3 Ability to carry out Range Checking of aggregate total. This is in support of the Range
Checking process.
MI 1018 Prism 8.9.3 Interface to allow investigation of transaction data by the Cash Accounting and Cash
Management teams in support of the following processes:
¢ A44 Client Settlement to Client
¢ A45 Client Settlement from Client
It must be possible to load client transaction level data for investigation and compare to the
POL transaction data stream for that client.
MI 1101 Prism 8.9.3 Ability to work out a notional cost for recorded errors for each branch by applying ABC (Activity
Based Costing). To support product P & L analysis
MI 1102 Prism 8.9.3 Daily reporting by value, volume and margin (all products) as provided by ABC, giving Product
Profit & Loss. To support branch P & L analysis
MI 1103 Prism 8.9.3 Data feed required to produce the Recall report. This is based on an existing AIS.
MI 1104 Prism 8.9.3 Data feed required to produce the NRM report. This is based on an existing AIS.
MI 1111 Prism 8.9.3 Data feed required to existing Horizon MIS
MI 1112 Prism To be able to perform an analysis across both Outlet and Product P&L
MI 1113 Prism Data feed required to Martins (and therefore Camelot)
po MI1114 I Prism _ isti
MI 1115 Prism
Version 1.0 Page 143/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
MI 1106 Prism 8.9.3 Data feed required to support Risk Model
MI 1107 Prism 8.9.3 Ability to monitor and take action on the completion of Branch Trading Statements
There is a requirement to produce summary reports based on the existence and data
contained within the following events flowing from the Horizon system; “Trading Statement
Created”, “Trading Statement Period Rolled”, “Trading Statement Period Roll Abandoned”.
The reports will also use Trading Statement Calendar information from NRDS to summarise
those branches which have not completed their Trading Statement within the correct
timescales.
There is a further requirement to enquire on existence and data contained within these events,
to allow further investigation of Branch Trading Statement production activity.
MI 1108 Prism 8.9.3 Ability to monitor and take action on amounts made good and/or amounts removed with
associated values
There is a requirement to produce summary reports based on the existence and data
contained within the following events flowing from the Horizon system; “Excess Cash
Removed”, “Cash Shortage Made Good”. The reports will summarise the activity by branch
and by volume of events and value of amounts made good, over defined time periods.
There is a further requirement to enquire on existence of and data contained within these
events, to allow further investigation of Cash Make Good activity.
MI 1109 Prism 8.9.3 Ability to monitor the usage of Cash Variance reports
There is a requirement to produce summary reports based on the existence and data
contained within the following events flowing from the Horizon system; “Cash Variance Report
Previewed”, “Cash Variance Report Printed”. The report will summarise the existence of such
events over defined time periods.
There is a further requirement to enquire on existence of and data contained within these
events, to allow further investigation of Cash Variance Reporting activity.
© Post Office™ 2003
Version 1.0
Page 144/141
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
FUJ00090148
FUJ00090148
MI 1110
“PM 001
Prism
8.9.3
Ability to monitor and take action the number of outstanding Transaction Corrections at a
branch
There is a requirement to produce summary reports based on data from POL-FS and on the
existence and data contained within the “Outstanding Transaction Correction Reminder
Displayed” event flowing from the Horizon system. The report will summarise and highlight,
transaction corrections by branch, by age outstanding and by volume and value.
There is also a requirement to enquire on existence of and data contained within the
“Outstanding Transaction Correction Reminder Displayed” events, to allow further
I investigation of Transaction Correction activity.
Any known problems will be explained and formally handed over to POL’s Problem Management Team.
PM 002
© Post Office™ 2003
Version 1.0
Problem Management requirements will be worked up and documented within Prism OLA’s/SLA’s, with
related procedures documented
Page 145/141
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
19 Appendix B - Impact Stakeholder Forum Design Principles
Principles/ Working Assumptions for discrepancies
« All discrepancies under £250 should be made good at point of identification. It should not
be possible to key a value of less than £250 into the suspense account. Therefore the
quantity of discrepancies flowing up to the ledger should be significantly reduced
« Transaction corrections required by the branch will be automatically sent to Horizon via a
flat file from POL/FS. This will contain information regarding the correction to be made and
how to carry out the correcting transaction
« The correction should be automatic or with minimal intervention (this needs to be
confirmed with FJS and may not be possible)
« Transaction corrections which are not undertaken within stipulated timescales will create
an exception report from POL/FS in order to aid any further investigation
« Transaction corrections supplied by client e.g. Girobank should be automatically
communicated to branch irrespective of value if evidence is available
e Errors identified by client, such as gas bill not paid, should be automatically communicated
to branch irrespective of value if evidence is available
e If the agent request for the value to be taken from salary the Horizon system should have
an icon which would move into “recovery account” therefore clearing the agent suspense.
This would flow into agent debt in the ledger and remove from suspense in the ledger
e For multiples it should be possible to “clear” the error in the same way as above in order
for the debt recovery teams to invoice the “nominee” direct.
e For directly managed branches the transaction correction will always adjust from suspense
to recovery account and then be written off in the ledger.
« The use of a recovery account within Horizon will reduce, or potentially remove, the need
for write off vouchers and REM vouchers. This will lead to efficiencies.
« The differing scenarios for transaction corrections e.g. multiples, directly managed will be
managed by reference data.
« Former subpostmaster debt will be held as agent debt in the ledger. At the point of
resignation any value in suspense will be moved to agent debt.
Principles/ Working Assumptions for stock
¢ Horizon will record volumes/ quantities only for all transactions, except on sale, or loss,
transactions when it will additionally record value.
Version 1.0 Page 146/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POU/IMPACT/DES/***
Ref:
e For Balance Sheet Stock — SAP will record data at lower level product information
(example Orange £ 5, £ 10...) whereas for Non-Balance Sheet Stock — Higher level
product information should suffice. Hence, Horizon will need to provide this level of
information. (Yet to investigate this for Hemel)
e« We have assumed rem-in and rem-out for all products and no products/ stock items will
be excluded.
« Line item (product level) details will be available (yet to investigate this for Hemel) to report
on stock in transit (both -stock from Hemel and stock to branches) Tracking of stock in
transit is out of scope for Impact programme.
«Unit of Measure for all transactions on Horizon will be the retail sales unit of measure.
Principles/ Working Assumptions for settlements
« Vendor accounts should be set up using standard SAP functionality
e For clients paid on estimates the principle of a “holding” account will apply
« For client paid on their data, currently matched via OpTip, will only be matched if deemed
high risk eg Lottery. Low risk clients will be paid on their data however the variances will
be recorded at a high level and if variances reach tolerance limit further investigation will
take place
e Any client data matching will take place outside of POL/FS
Principles/ Working Assumptions for verification
¢ Verification will take place at the branch and within MI not within POL/FS
Version 1.0 Page 147/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACTIDES/***
Ref:
20 Appendix C: Transaction examples
Branch Processes:
+ Sale of a Service in Branch — e.g. Alliance & Leicester withdrawal
* Sale of Non Balance Sheet Stock Product — e.g. MVL
+ Sale of Balance Sheet Stock Product — e.g. Orange Phone card
Transaction Corrections
» Agent “Discrepancies”
+ Cheque Process Errors
+ Unpaid Cheques
+ Client/Customer Discovered Errors
Cash Centre Process:
* Sale of Service in Cash Centre - e.g. Giro Deposit
Other Processes:
* Delivery of Cash to Branch
* Delivery of Stock to Branch
20.1 Process: Sale of a Service in Branch
+ Joe Public withdraws £100 from A&L account
+ Recorded on Horizon as A&L Withdrawal and reduction in Branch Cash value
+ Information also sent to A&L electronically
+ Nightly interface summarises transactions — sent to POL FS
+ Effective Accounting on POL FS - Withdrawal Service
+ Debit A&L Client a/c; service Withdrawal £100
* Credit Cash in Hand GL a/c £100 (Totalled by branch)
20.1.1 Settlement to/from Client
+ Settlement to/from A&L
+ When settlement due Payment Process subtotals Withdrawals & Deposits and
totals to a final settlement value — based on Horizon feed
+ Accounting from Settlement — Assume Net Receipt from A&L
+ Credit A&L Client a/c
+ Debit Bank Receipts Clearing GL a/c
+ Accounting from Bank Statement — receipt from A&L
* Credit Bank Clearing GL a/c
+ Debit Bank GL a/c
20.2 Process: Sale of Non Balance Sheet Stock Product
+ Joe Public buys a M.V.L. with a cheque
+ Recorded on Horizon against MVL product and cheque payment.
+ In Branch the number of MVL’s is reduced by 1
+ By end of day cheques sent to EDS for Processing
Version 1.0 Page 148/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
ef
+ Cheques “Remmed-out” of Branch
+ Nightly interface summarises data and sends to POL FS
+ Effective Accounting on POL FS — MVL sale
* Cr DVLA Client a/c “Comparison a/c”
* Dr Cheques to EDS GL a/c value per branch & day
+ Stock Recording
+ Stock document reduces stock of MVLs in Branch
+ Stock document identifies movement as a sale
+ No finance impact
20.2.1 Cheque process
+ Accounting for Cheques — processed by EDS
* Cr Cheques to EDS GL a/c Value by branch and day
+ Dr Cheques in Clearing GL a/c Daily value
* Clear Cheques to EDS GL ajc by branch, day and value — identify differences by
branch.
+ Accounting for Cheques Banked
* Cr Cheques in Clearing GL a/c Daily value
+ Dr Bank Account GL a/c
* Clear Cheques in Clearing GL a/c by day and value — identify differences by day
20.2.2 Settlement to Client
+ When settlement due
+ Payment Process subtotals all DVLA products due and totals to a final settlement
value — Based on Estimated data
+ Accounting from Settlement — Payment to DVLA
+ Debit DVLA Client a/c
+ Credit Bank Payments Clearing GL a/c
+ Accounting from Bank Statement Processing
+ Debit Bank Payments Clearing GL a/c
+ Credit Bank GL a/c
+ Comparison Estimate to Actual
+ Adjust future estimates based on differences
20.3 Sale of Balance Sheet Stock Product
+ Joe Public buys Orange Phone card for cash
+ Recorded on Horizon - sale of Orange Phone card
* In Branch the number of Orange phone cards is reduced by 1
+ Nightly interface summarises data and sends to POL FS
+ Effective Accounting on POL FS - sale of phone card
+ Credit Card Revenue GL a/c
+ Debit Cash
+ Recording and Accounting for Stock
» Stock document reduces stock of Orange Cards in Branch
+ Stock document identifies movement as sales and creates a finance document
+ Debit Cost of Sales; Orange Cards GL a/c
+ Credit Stock GL a/c
Version 1.0 Page 149/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACTIDES/***
Ref:
20.4 Transaction Corrections
20.4.1
20.4.2
Replaces the Error Notice
Electronic Message to Horizon
“Intelligent” Interface on Horizon
Processing control from Chesterfield
Monitor status — actioned or not
Agent “Discrepancies”
General Suspense no longer used for Cash Discrepancies
Loan Applications
Transaction Correction to move Cash Discrepancy to Agent Debtor
Create Transaction Correction journal on POL FS against Agent account —
references Cash
Scenario: £1000 Cash shortage in Branch.
+ Dr Agent £1000 Agent owes PO difference
* Cr Transaction Correction a/c ;Product Cash; Branch Code £1000
+ + Text Instructions
Nightly interface extracts new Transaction Corrections and sends to Horizon.
Horizon sends to identified branch.
Agent “Accepts with Hardship”
Horizon reduces cash in hand by £1000 and shows £1000 against a “Hardship”
product
Actioned Transaction Corrections flow up the nightly interface from Horizon to POL
FS
Correct Cash Position & set up debtor for collection
» DrAgent £1000
+ Cr Cash in Hand £1000
Reverse Transaction Correction because actioned
+ Dr Transaction Correction a/c £1000
+ Cr Agent £1000
Errors From Cheque Process
Difference between value of cheques processed by EDS and value remmed
out of a Branch
Identified by unmatched items in Cheques to EDS GL alc
Scenario:
+ Branch Remmed out £1000
+ EDS processed £1100
Potential effect in Branch
* Cheque Rem out value understated by £100
+ Agent/Manager transferred £100 too little out of cash to cover cheque rem
out.
* Cash in branch overstated by £100
Version 1.0 Page 150/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACTIDES/***
Ref:
20.4.3
Create Transaction Correction on Agent/Branch
* CrAgent £100 PO “owes” agent surplus
» Dr Transaction Correction a/c ;Product Cheques to EDS; Branch Code £100
+ + Text Instructions
Nightly interface extracts new Transaction Corrections and sends to Horizon.
Agent/Manager is given option to “Make Good”
* Action on Horizon will reduce Cash in Hand and move value to a “Product”
represent Cheques to EDS
Actioned Transaction Corrections flow up the nightly interface from Horizon to POL
FS
Correct Cash Position & EDS Cheque a/c
+ Dr Cheques to EDS GL a/c £100
+ Cr Cash in Hand GL a/c £100
Reverse Transaction Correction because actioned
+ Dr Transaction Correction a/c £100
* CrAgent £100
Clear Open items for Branch in Cheques to EDS GL a/c
+ DrBranch Rem Out £1000
+ CrEDS Processed £1100
+ Dr Branch TC £100
Unpaid Cheques
Unpaid Cheque in Bank Account
* Credit Unpaid Cheques Bank GL A/c £100
+ Debit Unpaid Cheques Recoverable GL A/c £100
Unpaid Cheques may be the liability of the Agent
Agent owes Post Office for value of cheque
Assumption that Agent will Make Good value of cheque
Create Transaction Correction journal on POL FS against Agent account —
references Cheque
» Dr Agent £100 Agent owes PO
* Cr Transaction Correction a/c ;Product Unpaid Cheque; Branch Code £100
+ + Text Instructions
Horizon sends to identified branch.
Agent has opportunity to Accept & Make Good; Accept & Plead Hardship; Request
Evidence.
Agent/Manager must action all Transaction Corrections before completing Trading
Period
Actioned Transaction Corrections flow up the nightly interface from Horizon to POL
FS
Scenario: Agent Accepts & Makes Good
* Correct original error
* Cr Unpaid Cheques Recoverable GL A/c £100
+ Dr Cash in Hand £100
+ Reverse Transaction Correction debtor on Agent
+ Dr Transaction Correction a/c £100
* Cr Agent £100 Agent no longer owes PO
Version 1.0 Page 151/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACTIDES/***
Ref:
20.4.4 Client/Customer Discovered Error
+ Error identified by Client/Customer/POL
+ Verification of error from data on Management Information System and any other
sources available
+ Create Transaction Correction journal on POL FS against Agent account -
references appropriate client Product/Service
+ Scenario: Miss-keying of Gas bill payment on Horizon — typed £300 instead of £30.
Appears as if there is a cash shortage in Branch.
+ Dr Agent £270 Agent “owes” PO difference
+ Cr Transaction Correction a/c ;Product Gas Bill; Branch Code £270
+ + Text Instructions
+ Nightly interface extracts new Transaction Corrections and sends to Horizon.
+ Horizon sends to identified branch.
+ Agent/Manager has opportunity to Accept & Make Good; Accept & Plead Hardshi
Request Evidence.
+ Agent/Manager must action all Transaction Corrections before completing Trading
Period
+ Actioned Transaction Corrections flow up the nightly interface from Horizon to POL
FS
+ Scenario: Agent Accepts & Makes Good
* Correct original error
+ Dr Gas Client £270 corrects future settlement
+ Cr Cash in Hand £270
+ Reverse Transaction Correction debtor on Agent
+ Dr Transaction Correction a/c £270
* Cr Agent £270 Agent does not owe PO
20.5 Sale of Service in Cash Centre
+ GIRO Bank Customer Deposits Cash in Cash Centre
+ Deposit recorded in SAP ADS against Customer
+ Nightly interface summarises data and passes to POL FS
+ Accounting on POL FS
* Credit Girobank Client a/c (this may also identify customer)
+ Debit Cash in Hand GL a/c
+ Settlement to GIRO bank is based on Estimated Values
* Credit from SAP ADS interface is not to same part of Client a/c as Estimated
Values for settlement
* Compare estimated values to actual values
+ Adjust future estimates to correct for previous differences
20.6 Delivery of Cash to Branch - S60
Cash Centre makes up pouch of cash and sends to Branch
+ Despatch of cash recorded on SAP ADS & pouch info sent to Horizon
* Nightly interface sends information to POL FS
Accounting on POL FS — Cash Centre Despatch
Version 1.0 Page 152/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
* Credit Cash in Hand GL a/c by cash centre
* Debit Cash in Transit GL a/c by pouch
Branch receives pouch and scans in
+ Auto remittance of cash (new at s60); Cash in branch increases
* Nightly interfaces sends information to POL FS
Accounting on POL FS - Branch Receipt
* Credit Cash in Transit GL a/cby pouch
* Debit Cash in Hand GL a/c by Branch
Clear Cash in Transit GL a/c
+ Match by pouch and value to identify missing pouches
20.7 Delivery of Stock to Branch
+ Hemel NSSC creates a stock pouch and sends to Branch
* Stock pouch information recorded on WCS.
* Nightly interface to POL FS
+ Recording and Accounting for Hemel Stock in POL FS
* Stock document reduces stock of products in Hemel
+ Stock document identifies movement as a despatch to Branch
+ If Product has an intrinsic value
* Credit Credit Stock GL a/c by Hemel
+ Debit Stock in Transit GL a/c by pouch
Branch receives pouch
+ Not Automatically remitted in; manually entered onto Horizon
* Nightly interface to POL FS
Recording and Accounting for Branch Stock in POL FS
* Stock document increases stock of products in Branch
+ Stock document identifies movement as a receipt from Hemel
+ If Product has an intrinsic value
* Credit Stock in Transit GL a/c by pouch
+ Debit Stock GL a/c by Branch
20.8 Foreign Currency Remittance —- Cash Centre to Branch
« Hemel Cash Centre creates pouch/envelope of $2000
¢ $2000 in pouch valued at £1330
« Accounting on POL FS
* Stock Document indicating outward Remittance
+ Reduce volume of $ in Hemel by 2000 and value of £1330
+ Debit Forex in Transit £1330
+ Credit $ in hand £1330
« Branch accepts Pouch and scans in. (No Auto Rem)
e Branch enters quantity and value of product received in pouch
« Accounting on POL FS
* Stock Document indicating inward Remittance
+ Increase volume of $ in Branch by 2000 and value of £1330
+ Credit Forex in Transit £1330
+ Debit $ in hand £1330
Version 1.0 Page 153/141
© Post Office™ 2003
FUJ00090148
FUJ00090148
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc POL/IMPACT/DES/***
Ref:
20.9
Sale of Foreign Currency in Branch
Joe Public wishes to buys $1000
Rates in Branch on day of transaction are: Sell £1: $1.60 ; Mid-market Rate: £1:$1.55
Record on Horizon as:
= Sell 1000 product $ value 1000/1.60 = £625
= Margin on sale £20.16
« Joe Public pays £645.16 recorded as increase in Cash in hand
Effective Accounting on POL FS
= Credit Revenue on Bureau £625
= Credit First Rate Client a/c (margin) £20.16
= Debit Cash in hand £645.16
Recording and Accounting for Stock
o Stock document reduces stock of $ in Branch
© Stock document identifies movement as sales and creates a finance document
= Debit Cost of Sales; $ £625
= Credit Stock GL a/c $625
Version 1.0 Page 154/141
© Post Office™ 2003