POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
PO Ltd Financial Systems
Release 3
Conceptual Design
Version 0.4 Page 1/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Table of Contents
4 Document Control
Document Information
Document History......
Change Process
Changes in this Version.
Key Contacts ........... ceseuneeneenstneesetsstnnesntineineintiseisenisetsenigeieeineintineenenneeeeeneee
Review Details
leRisisreeisl
Associated Documents
Abbreviations/Definitions .....-..sccsccssesstineinetseeneeneene
2 Introduction ........ccsssssssesee
21 Purpose
22 Scope...
2.3 Background ..
24 — Document Explanat ions
3 Overview
3.4 Business Proposition
3.2 — Functional Summary.
3.3 Systems summary......
34 Potential for Change.
4 — Constraints .....
44 High Level Functional
4.2 Dependencies and Assumptions ...
43 Legal & Regulatory
44 Audit
4.5 — Architectural Framework & Building BlOCKS 0... ..cscccssssseessssessnsssseeeussseseeunssseeennansseeuae cessesssetetinsssetetesssseetsnsseseesnsnseee 1S
46 — Supplier
5 Design Principles.
51 Programme:..
$6.2 Project: eee
6 — Functional Requirements
61 General
6.2 — General Accounting...
63 Client Ledger
64 Debt Recovery. .
6.5 Cash Centre Management ...
6.6 — Stock Recording & Accounting ..
6.7 — Foreign Exchange ............
68 New Reference Data System
TZ _ Process Models....... 7
71 Post Office Processes in Scope... —
72 —A4-Accounts and Settlement .................
73 A442 Summarise Client Data
T4
TS AAG Verification ...cennnenncenenn
76 Ad7 Debt Recovery .
TT 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
84 — A45 Client Settlement from Clients..........
85 — A46 Verification
86 A47 Debt Recovery
87 — A48 Produce POL Ledger..............
88 A489 General Ledger Processing ..
8.9 Management & Accounting Information
8.10 New Reference Data Svsiem .
2 Information Flows. ... os
91 Branch Data from Horizon .
92 Cash Centre Data From SAP ADS
93 Financial Results to ESFS
94 Transaction Corrections to Horizon
Version 0.4 Page 2/124
© Post Office™ 2003
POL00038885
POL00038885
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 ve
97 — Reference Data NRDS to Horizon
98 NSSC Stock movements from YANTRA
9.9 Summary Transaction Information to Girobank
9.10 Summary Transaction Information to NS&1.............0000
944 Remittance Advices to Clients.
9.42 Statements to Clients
9.43 Stock Statements to Clients
944 Statements to Agents...
9.15 Payments file to BACS.... .
9.16 Enhancement to ESFS to NRDS Interface .
10 Non-Functional Requirements .....
40.4 Volumetrics.........
10.2 Sizing Assumptions ........
10.3 Service Levels
10.4 Problem Management & Tracking.
10.5 Business Continuity... we
10.6 Training ...... coccsnssseeee
ain Technical Requirements
tit End-to-End Architecture Diagram (Example shown below)
W2 Architecture Principles ... oo .
41.3 Integration & Interface.
14 Other Technical Requirements.
12 Security Requirements... .ceccocesesseneees sccssnnaneennnnnneeee
42.1 Security Testing.
43 Deliverables / Work Packages ....
13.4 Post Office™.......
13.2 Prism Alliance.......
13.3 Fujitsu Services ....
44 Planning............. vessel
444 Timescales .
14.2 Dependencies
45 Acceptanee.........
46 Testing,
ava Implementation & Migration
WA Co-ordination of the feeds into POL FS
418 Appendix A — Requirements Cataloque
19 Appendix B ~ Impact Stakeholder Forum Design Principles 132
20 Appendix C: Transaction examples ooo.o..o.cccccessccsssssssessssessssnesesssssseetusssenetnsssseesnanseeesee cesseesnseetinnnenetimnnsetennessseeeeenne LOM
20.1 Process: Sale of a Service in Branch. soosssesenesesusenesesee cocossssseesssuisssiunnsnnsessnenssoseeesesiissuanisnnsnsnnneseseseseeeseneeesee coon 134
20.2 Process: Sale of Non Balance Sheet Stock Product 134
20.3 Sale of Balance Sheet Stock Product 4135
204 Transaction Corrections ...........cccssssssssssesesseiiunsssnsesesssessseeesnssitsususnsnseseseseseeeeeeesesesense cecssseeeeeestutttinsennneseseeeeseeeesesssee 13
20.5 Sale of Service in Cash Centre. 138
20.6 Delivery of Cash to Branch - S60 138
20.7 Delivery of Stock to Branch..........scscssssscessmnusssssssssseeesesseeeessmmustsnrssesseeeeseeeeetisimnnnssnnssseeeeesseeceetiisnsssesssseeeeeeseseeeeesssee OQ
Version 0.4 Page 3/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACT/DESIR3029
1 Decument Control
1.1 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 & Department: I Karen Hillsden - Business Solutions
Contributors: Fujitsu Services, Prism Alliance
Post Office Distribution: I Ray Jackson; David Parnell; Karen Hillsden; Helen Pedley; Chris P Allen
Supplier Distribution: Bob Cragg; Tony Brain; Peter Flood; Philip Godden; Ras Chauhan (Prism)
Gareth Jenkins; Bill Reynolds; Luxmi Selvarajah(Fujitsu);
1.2 Document History
Issue to Post Office Business
0.05 31/04/04 Review for final sign off.
0.01 16/01/04 First Draft
0.02 7102/04 Second Draft for Project review I
0.03 19/02/04 Version for Baseline
0.04 24/03/04 Revised after comments from Project teams
Version 0.4
© Post Office™ 2003
Page 4/124
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
POL00038885
POL00038885
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
¢ Additional information in Information Flows in lieu of AlS’s section 9
e Additional Requirements for NRDS section 8.10
¢ — Additional information relating to Management Information Sect 8.9
e Update to Non-functional requirements re R3/S80 Sect 10
01 e None, First draft template.
0.2 « Updates to sections 7 & 8 with all relevant swimlanes and process descriptions.
0.3 e Assumptions & dependencies section 4.2
0.4 e — Client Ledger requirements revised (S6.3)
e Foreign Exchange related requirements added (S6.7)
e — Impact Stakeholder Forum Design Principles added (Appendix B)
e Transaction examples added (Appendix C)
0.5 e Updates following feedback from POL Business particularly to:
e Requirements
« Swimlanes and Process Descriptions.
1.5 Key Contacts
Karen Hillsden Business Process Architect
Chris Allen Business Process Architect
Gareth Jenkins Fujitsu Applications TDA
Peter Flood Prism Alliance Project Manager
Ray Jackson S60 Release Manager
Philip Godden I Prism Alliance Application Lead
Version 0.4 Page 5/124
© Post Office™ 2003
COMMERCIAL IN CONFIDENCE
POL00038885
POL00038885
Conceptual Design Project: POL FS
Doc Ref: POL/IMPACT/DES/R3029
1.6 Review Details
Post Office Ltd:
Head of Technical Architecture
Head of Business Architecture
Impact Programme Manager
Technical Design Authority
Business Design Authority
Release Manager
Business Stakeholders
Fujitsu Project Manager
Clive Read/Torstein Godeseth
Paul Homan
Sue Harding
Saunder Narayan
Karen Hillsden, Chris Allen, David Parnell
Graeme Seedall
Stephen Hirst, Vicky Noble, Ruth Holleran, Martin Box, Rod Ismay,
Bill Reynolds
Fujitsu RASD Gareth Jenkins
Prism Alliance Project Manager I Tony Brain; Peter Flood
Prism SAP Al
Optional Review issued for Information
Bob Cragg
POL
Torstein Godeseth, Ann Clarke, Debbie R Brown, Alvin West, Sheena
Patience, Tony Utting, Ben Gildersleve, Richard Wardle
© Post Office™ 2003
Version 0.4 Page 6/124
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POLFS
POL/IMPACT/DES/R3029
POL00038885
POL00038885
1.7 Associated Documents
Corrections 0.04
Horizon
CR/CDE/006 3.4 Sept 03 E2E Programme Conceptual Design.
POL/E2E/DES/006 1.1 Jan 04 I Automated Cash Bank Ledgers Conceptual Design
AIS Transaction 1.30 Feb 04 _ AIS for transaction corrections from POL Ledger to
AIS_BranchLedger
Entry R3 V0.03
0.03 26/04/04
AIS for Horizon to POL Ledgers
PO Ltd IS Security approach
quest_retail_Prod
Na 18/12/03
Sizing document for SAP POL FS
R3_260204
VI/STRIO64 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, and MIS.
POIFS_VO.1
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
Vendor Data Interface
v0.1
0.01 Mar 04
AIS for the Vendor Data interface between NRDS and POL FS
© Post Office™ 2003
AIS POL FS to NRDS 0.01 Mar 04 __ AIS for the GL Data interface between POL FS and NRDS.
GL Master Data
Interface v0.1
NRDS to POL FS 0.01 Apr 04 AIS for the Branch Hierarchy Data interface between NRDS
Branch Hierarchies AIS and POL FS
V0.1
NRDS to POL FS 0.02 Mar 04 __ AIS for the Customer Data interface between NRDS and POL
Customer Data FS
Interface AIS V0.2
NRDS to POL FS 0.01 I Mar 04 “AIS for the Product Data interface between NRDS and POL
Product Data Interface FS
AIS V0.1
Version 0.4 Page 7/124
POL00038885
POL00038885
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 POL FS
Data Interface AIS V0.2
Unless a specific version is referred to above, reference should be made to the current version
1.8 Abbreviations/Definitions
Abbreviation Definition
Agent An individual or company who does or has in the past been a sub-postmaster under the normal
PO Ltd agency agreements
AlS Application Interface Specification
Alcor 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
NSSCc. 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.
Version 0.4 Page 8/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACT/DESIR3029
POL Ledgers Cash & bank ledgers, as part of POL FS
Product A service or stock item to be transacted with the public/business 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
$80 $80 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 The date a transaction occurs in either the branch or cash centre.
Trading Day A trading day is defined for each branch as the trading period between each day end process.
Transaction Instruction to Branch, Cash Centre or Client to correct some transaction data. (This replaces the
Correction 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.
Yantra a Warehouse system that is being implemented in the NSSC. (Planned Go live date June
Other generic IT ee. can be looked up at: http:/Awww.whatis.com/
Version 0.4 Page 9/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
2 Introduction
This section describes the objective of the document, any history of its production and other background
information, but excludes material that is already contained in the preceding document control sections.
2.1 Purpose
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:
e Daily interface from SAP ADS to pick up all financial information from SAP ADS and hence replacing the
current weekly cash account.
eDaily 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.
e Daily interface from YANTRA to pick up all stock movements in NSSC.
eDaily interface from STAMPS (manual) /SAP ADS to pick up all Bureau Foreign Exchange movements in
Hemel Cash Centre.
Version 0.4 Page 10/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
e Periodic interface of Post Office Network financial results to RMG Financial Systems (ESFS).
e 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.
e Changes to MIS that are required due to the replacement of the legacy systems.
2.2.1 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.
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:
Version 0.4 Page 11/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
General Accounting:
e 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
e Long term aim to account and settle on our data, not clients
¢ 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
e Establish a central debt monitoring environment, for both business and transaction debts, to enable
the identification of debt with a high degree of accuracy.
e To modify the method of recovering debt by balance rather than each individual item.
Stock Ledger
e Increased visibility of stock & foreign exchange in the network
e 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.
Version 0.4 Page 12/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
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.
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.
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 Yantra 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 0.4 Page 13/124
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL00038885
POL00038885
POL FS
POL/IMPACT/DES/R3029
3.3. Systems summary
The diagram below shows the IMPACT Release 3 system architecture
Representing Transaction Data Flows
I Management
Information HR Clients
(SAP/HR)
Transaction
I Management
Horizon
RMG
Financials
(ES-FS)
NSSC_
Los
Feeder
Service
Cash
Management
Reference (SAP/ADS) I
Data
Version 0.4
© Post Office™ 2003
(YANTRA)
Page 14/124
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIIMPACT/DESIR3029
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 0.4 Page 15/124
© Post Office™ 2003
POL00038885
POL00038885
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
fequirement 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 Supplementary document matching will not take place in POL FS and will largely be stopped.
ASS 002 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 Matching of client summary data to POL FS data will be done on a risk based approach.
ASS 008 Reporting of data to clients from POL FS will be at the maximum level of Branch, Trading Day &
Product.
ASS 004 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 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 In order that some of the existing controls can be removed, there is a plan of migration of some
products/services to Automated Payments process. This piece of work is with Sales and Marketing. If
this is not completed then there are some controls, which currently exist in the legacy systems that are
not being designed within POL FS. These controls will be replicated in another system, to be defined.
ASS 007 Itis assumed that an electronic feed of stock movements to/from the branch network will be provided by
the YANTRA System that should have replaced the STAMPS System before S80 implementation.
ASS 009 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
ReqiD I . Description
001
Version 0.4 Page 16/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
4.4 Audit
Req ID I Description
POFS 002 _ It shall be possible to audit movements within POL FS by branch back to Horizon
POFS 003 _It shall be possible to reconcile movements within POL FS by cash centre back to SAP
ADS
POFS 004° Technical requirement: to keep a copy of all bulk data files exchanged between Horizon
I domain and Prism domain. The data should be the raw (unprocessed) data.
POFS 005 __ Technical requirement: audit records of user activity within the SAP application should be
created by standard SAP functions. L
POFS 006 _ Technical requirement: audit records of support activity on the POL FS host platforms
I 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 Yantra
TEC 028 Interface with Girobank
TEC 029 Interface with DNS
TEC 030 Interface with NS&
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
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
45.3 Post Office™ Approved Technology
4.5.4 Not applicable Post Office™ Approved Components
Not applicable
Version 0.4 Page 17/124
© Post Office™ 2003
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
POL00038885
POL00038885
4.6 Supplier
4.6.1 Fujitsu Services / PRISM Alliance
ReaD Description
POFS 007
Version 0.4
© Post Office™ 2003
IThe POL ledgers will be built in addition to and independent of other SAP systems.
Page 18/124
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
POL00038885
POL00038885
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 Any individual component of the programme must conform to the POL Strategic Data Model
5.2 Project:
Req ID
14. 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 0.4
© Post Office™ 2003
Page 19/124
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACT/DESIR3029
6 Functional Requirements
6.1 General
Ref Requirement Description
FL021 Monitoring of system rejections to ensure that data is resent and processed or accepted successfully
FI022 System Management controls e.g. access levels, user ID's, passwords etc.
FI 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
FL015 To produce a set of auditable accounts within the framework of the Chart of Accounts specified
FL016 To enable matching of suspense items for debt recovery purposes and error handling
FIO17 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 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 To receive a daily interface of summarised transaction data, from Horizon, by client or product.
CSH 005 To calculate, pay / receive and account for Client settlements based on the contractual data stream,
being any combination of:
© Horizon
e SAP ADS (e.g. Corporate deposits)
e Client data (e.g. Camelot)
e Other existing contractual stream (e.g. BBC non bar coded licences)
e Stock adjustments from NSSC
CSH 006 To pay / receive settlements based on estimates and / or including standing deposits
CSH 007 Settlement facility to be available by 7:30 am in support of client settlement terms
CSH 003 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 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.
Version 0.4 Page 20/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACT/DESIR3029
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:
e Accounted for in the current accounting period based on posting date
e Recorded against the appropriate trading dates
e — 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
e Transaction Corrections (covering customer, supplier and branch queries)
e 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:
e BACS
e¢ CHAPS
° Swift
e Cheque
¢ _ Direct Debit (payment receipt only)
cs 012 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 O17 The ability to amend settlement for non core charges such as commission and interest charges and
account for these accordingly.
CS 013 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.
CS 018 To be able to determine the amount due to a client using payment terms agreed with client
cS 019 To enable payments to/from clients with functionality for matching and closing paid items to leave open
items for management of debtors/creditors
Version 0.4 Page 21/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACT/DESIR3029
6.4 Debt Recovery
Ref Requirement Description
DRH 001 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 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 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 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.
eto 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 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 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.
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.
Version 0.4 Page 22/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Ref Requirement Description
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 (i.e. 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
e Other debts as identified —- manually entered
DR 011 Ability to record reductions in debt on agent's account based on:
e Payment by Credit Card
e 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 I 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 I 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)
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 F's
Inward and Outward to Customers/Clients.
Inward and Outward to 3¢ Party
Cash centre adjustments
Cash centre discrepancies
Cheque remittances
Cheques on hand
Version 0.4 Page 23/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
Ref Requirement Description
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 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 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 POL FS MM module to accept a daily interface of stock adjustments at the branches, from stock
declaration process hence identifying stock discrepancies. .
SRH 004 To provide an interface of stock at National Secure Stock Centre, identifying stock discrepancies, for
recording to POL FS MM module.
SRH 005 To provide auditable balances of stock throughout the network for probity and audit purposes
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.
Version 0.4 Page 24/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POL FS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACT/DESIR3029
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 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.
The daily movement in foreign currency held will be received as part of the daily interface from Horizon.
BDC 002 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 Margins and Commissions on transactions (Sell and Buy) are to be posted to an appropriate settlement
account for the Bureau Joint Venture.
BDC 004 Stock revaluations to be recorded separately in POL FS. Stock revaluations will be driven by sending
systems. The current build for Horizon triggers revaluation from the running of the trial balance.
BDC 008 Stock adjustments to be recorded separately in POL FS.
BDC 005 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 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 POL FS reporting capability to be accessible within the Cash Centre Network.
6.8 New Reference Data System
Ref Project Requirement Description
NRDS 001 I NRDS to provide reference data shared by multiple systems to POL FS
NRDS 002 _I NRDS to accept reference data mastered in POL FS that is required for interface data mapping
NRDS 003 I NRDS to provide a data mapping facility to enable interfaces between significant systems to be
controlled using reference data rather than hard coding
NRDS 004 I NRDS interface to Horizon to be enhanced with various data objects including interface data mapping
logic.
Version 0.4 Page 25/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/R3029
1 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 0.4 Page 26/124
© Post Office™ 2003
COMMERCIAL IN CONFIDENCE Doc Ref:
Conceptual Design Project: POLFS
POL/IMPACTIDES/R3029
7.1 Post Office Processes in Scope
Prowie
I managers Managemere Information
tnfmation
RaweRS Tats] St0ck Revaluation iormation
—ev—ee—
Management IS roduct Change Inf
I_ Product Change tr 7 I ascoaa of Recounis are I_POL Business Ledger S-FS}
4 Trading Transactions Settlement Adjusted Transactions
At Tpsing Debts Debt Re Amounts Through Payroll
Reference Data & Business Rules I Debt Recovery Amounts Througd Payrol
Cheques Processed Client Transaction Data Repor,
Streamline Satterents vanchLiabity Stateme
Customer Requirements! -———<-¥- jak Revaluation Iormation Sraren aeily Sicremet
Racept Client Settlement Data Series Paver tenet
Branch Closure Notice Payment Request to Client
st
ly Response/hiter Sales Enauiy ‘lent Authorsatons tdentifed Transaction Errors
Inferst Report
2 Transaction Data
A2 ‘Cash Movements id Costing Analysis
Mandatory Data
Branch CashHadng Marketing Forecasts
Stock Usages Through Transay _ Sisak Adjustineia ——
‘Stock Holding InformationI Investments & Borowings
4 a, >
as} dare Heras Panormarce Dae
Wf Fema POTTS UA) 4
Management Supplier Orders
Stock Receipts oe tock Despatches
Taal RSGUTSTTOTE RRS
Product Marketing Knowledge
Other Fulfiiments: Pouch Delivery Confirmation to Cash Centre:
4 tasin Centre Transaction Data
ra
‘Cash and Near Cash U: Through Tre ti [ouprers Despatched
aah and Near Cann Usageq Through Transactions ae eaves
Opening Cash, Cheques and V Cash Eheques Despatched
Cas ReeeIsS Management I————_—~ Consignment Note
Gash Receipts for Financial etaanore o
Local Cash Requirements Information cash Despatches
Customer Transactions Gash Orders
‘Seasonal Data Cash Despatched to Financial Institutions
Markering Forecasts
‘Specials ‘Management Report
Cash Centre Cash Holding Information Non-Conformance Reports
Cash Flow & Holcings Performance Data
¢I
ae Forecast Pertrmance Reports
Version 0.4
© Post Office™ 2003
Page 27/124
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.2 A4- Accounts and Settlement
Version 0.4 Page 28/124
© Post Office™ 2003
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIIMPACTIDES/R3029
7.3 A442 Summarise Client Data
A442 Summarise Client Data
Client 442010: Sed
Settlement ed Misnanch of ener Data lito Clint, dutherise &
Duty Owner Tioanation I ioereeinecomt I Holding Accomt se
7
= FT a
2
Processing Clerk Discrepancy Database foe
I O)
“hot
Various
Role 2
Role 1
© Xansa 2002
Version 0.4 Page 29/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.3.1 A443 Calculate Estimated Settlement to Clients
A443 Calculate Estimated Amounts For Settlement
saherie,
443010; Receive
Settlement ouitcation of 443020; Use Local 443040: Concolidare #43050; Calculate 443060: hifem Clie, \oeesetlonee ‘ovo: Bee Agu Bike do
Duty Owner I BtbdSecimae ‘Business Enowdge Exinite Riécaation I] Sittene Baumte I] of Rained Senter ne Seta et hao Accom
(=. (Sei a
442030; Provide Ds
Soles & Marketing Product Change
Process
442070: Dieoue nd
Client Agree Settlement.
Ama,
Role 3
Role 2
Role 1
© Xansa 2002
Version 0.4 Page 30/124
© Post Office™ 2003
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE. Doc Ref: POLIIMPACTIDES/R3029
7.3.2 A444 Discrepancy Process — Errors identified by Client
A444 - Errors Identified By Client
4
44110: Racine 444130: Mitch Brae 444230: Chek 444240: leue a Carey
Client Paperwork & Information agamct_ 444140: Identify 444150: Send Barons & 444193: Update 444190: Adjust Bron Paperwork & Reissue Claim Error Notice
ent Weekdy/Daily ‘Weekhy/Daily Discrepancies: Peaches ‘Settlement vabues: Ppcihaid ‘Discrepancy Vihere Discrepancy Ne
Aggregate Data Aggeate Dats joomation joomucatin, Comet du Bor
+
a I
444151: Make
Settlement fieamats To
Duty Owner ro )
tanssisaa I I, stiesod
Exceptions Handling ‘Summary Brozs to Gine, aoe Not
Team cute Teified
7
Fe
448100: Sed,
Branch pypawerh Dally 486, '
Role
Aggregate AMS
dBm }
Role 1
© Xansa 2002
Version 0.4 Page 31/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.3.3 A444 Exceptions Handling - Compare Settlement Data With Transaction Data
A444 - Compare Settlement Data With Transaction Data
wor raimcted —_[ wow.caron) _f
Exceptions Handling Holding Accomm Toke Checks 400: Rei
Product Team I poner naiten I nancies] I ecrpmcy
Client
Branch L_
Debt Recovery
Role 2 ca AMO A853. = ASE ass
Role 1
© Xansa 2002
Version 0.4 Page 32/124
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL FS.
POL/IMPACTIDES/R3029
7.3.4 A445 - Resolve Exceptions
A445 - Resolve Exceptions
445002: Rema
Branch I, Dmepmcy 441
Ernch
SS,
4 I
pT
445005 Review 445030: Consider 445055; Adjust
445010: Monitor 445020: Review 445040: Record As 44500: Check ‘Trnsaction
Exceptions A866 ranches Whure Nening of Supe" Ledger Pending
Hondine a Ledger ‘Breeption Rene fe Besption Ren ‘Tereehold Bcstded Cometionss
445056: Coy Oot
A448 EH. Periodic Reriew of 443057: Vine. Of
Exceptions Handling I “4 «
Team Leader ‘Bucepticns
=o
Ll
445000: Rem-in
Cash Centre Diccrpmucy etifed I
By Coch Centre
Role 2
Role 1
Version 0.4
© Post Office™ 2003
© Xansa 2002
Page 33/124
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE. Doc Ref: POLIIMPACTIDES/R3029
7.3.5 A445 Transaction Corrections (Singletons/Franchises)
A445 - Transaction Corrections (Singletons / Franchised)
Multiples
Branch
445056: Cony Ot
PasodicReviewrot I gI 445057. rte 0
Exceptions Handiing wn eof 057: We
Team Leader een, “ume
443095: Diseuss 445120 cept s4szaictake Good} I 445125: Arpt bt
Comvctions ‘Bmeaction Comection} Comection Collection
445090: Receive
Branch -— Tnneacin
Cometion
=
=
43110:2ew
‘s , tsass:aane ]{ avon 44208-terert
Exceptions I tsb 1560: tmatios Inigeredng I] "Sma bene Cheong
Having. I Besun ins eure cme mam] lain
BT J ij
Debt ast
Recovery
Role 1
© Xansa 2002
Version 0.4 Page 34/124
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
Doc Ref:
POL FS.
POL/IMPACTIDES/R3029
7.3.6 A445 Transaction Corrections (Multiples)
A445 - Transaction Corrections (Multiples)
443000: Receive
Muttiples Tansacien
Branch Comets
445095: Discuss
Tans
wso-pinae I gsis-secgtet
coments I I Tin Cott
443056: Cory Om
Exceptions Han Parodi Revit Ig) 445057: vino
dling I ages ‘Adpatmnts Dosto Beton
Team Leader Destine
445100: Dispute
esis
L Tsacion
Nominee Comrection (First Time cot Travan,
Only)
#45110; Revie
445085: Aju 45000: Rate 445095: Rare
445060: kere Dispoted Barton I] 45001: teue Min
Exceptions -— #0 Uedgr Paine Tesetin Tne Comcion(@ Ootin I») Sitmetsroice
Handling ue me Cosrectons ‘More Bridence)
Debt Debt
Recovery Recovery
a
7
Rolel I teow
ins
© Xansa 2002
Version 0.4 Page 35/124
© Post Office™ 2003
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.3.7 A445 Transaction Corrections (Directly Managed Branches)
A445 - Transaction Corrections (Directly Managed Branches)
Multiples
Branch
west I Lor meee
Exceptions Handling mu re Date [OY setter qo Past)
Team Leader ‘Beceptions
Branch ‘Traction I Ounstanding Tras?
[ ne sine lt te
= omen z yale
e
Exceptions 145060: keerione eigen Tenn arming ew
Handling tne Review Coerection Comections
Debt
Recovery
Central Finance
iene I © Xansa 2002
Version 0.4 Page 36/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/IR3029
7.3.8 A446 Authorise, Make & Account for Payments
A446 Authorise, Make & Account for Payments
n
Baceptione
[Handling Clit]
be Disc >
Summarised
5 446010: Breer
Settlement Eximated I I SHert Dua AAT PSX Lat commission Details a
Duty Owner I Settlements ind into Clint Ledger meet.
TT
446005: Review. 4446030: Cory Out 6070-0: 446080: dapast
Team Leader mend and duthorise Detailed Contract a ad mows ster
Cline Stmding Data hack Amouts Discusrione
+ 2.
Manager 446050: Camry Out Top} 446060: Discuss 446090: Approve
Be ‘Lewel Checks ‘Payment
Due
446095: Receive Ds
Cashier of Pmding Required. Cashiers Radin
(By Payment Method)
Payment 446096: Authorise 446097: Sign & Send ett 0 ee
Authorisers Poymer, Cheque Clients
(fe) Cee
BAcsI
Role 1
Version 0.4
© Post Office™ 2003
Page 37/124
© Xansa 2002
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIIMPACTIDESIR3029
7.4 A45 Client Settlement from Client
The High level process shown here reflects current practice relating to Pre-funding from DWP / Inland Revenue.
idenitiiy
Settlement I__Seitlement Terms
Terme
Adjustments to Future Settlements
Estimate and
Ly Agree Amounts Repat__pI payment irom I__Payment Request Ig the Cilent
Due from Clients pra
2 EB
Pa Updated Ledger Entry Information
Bank Statements _,I Received
“Amounts in Bank Account Recehed
4 Compare Settlement]
Data with Txn Data Client Ledger Adjustments
(ertication c_tiement Discrepencies
Ledger Entry Information -! Debt Recovery tems
Rese
Discrepancies }————~
sj Identified Transaction Errors,
Finance
Version 0.4
© Post Office™ 2003
Page 38/124
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.4.1 A453 - A454 Settlement from Client (Personal Banking)
A453 - A454 Settlement From Client (Personal Banking)
452000: Adjuet
Paymaa Due I
‘Required (Day Bpm.)
Client 453030: Pay Amowe, 453070: Rmestigate
Due (Day Bam) Difirence (Day Bpm}
310: ma cx)
Settlement 420010; 7emae_I I {822m oui 4520: resigns 200: ter Cnt Ledge an oie:
Clerk ‘Receipt Fall Due am.) nd [Difference (Day Bpm.) ‘Receipt (Day Bpm.) ‘Where Amounas Agree ‘Discrepancy
yore) Tre
T o L_f L_,&
Cashier 453040: Compare Discrepancy if Amount
art (bet Dora Pus Dire
m_ (DyyBam)
Various
Role
Role 1
© Xansa 2002
Version 0.4 Page 39/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POL FS.
Doc Ref: POL/IMPACTIDES/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
Checks
Rota Checks Gusness Rules
Identified Transaction Errors
Rota Checks ‘Sufpmary Level Discrepencies
Vouchers Despatched
3 ‘Customer & Branch Enquiries
Activity Exceptioh Reports
Invesigate I piscrependes
Transaction Pe
Data
"Transaction
Activity Level
‘Checks
4
cheque
Veiification
3
Cheques Processed
[ Rutomaied
Transaction Data Reconciliation
—_____Tansaction Data_
Gient Authorsations
fl
Version 0.4 Page 40/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project
Doc Ref:
POL FS.
POL/IMPACTIDES/R3029
7.5.1 A466 Exception Identified by Client or Customer
A466 - Exceptions Identified By Client or Customer
I 4665010: Check I
(eto: rece
Exceptions Handling, oo Gomoner Acsomebe 45: Hactg
Team I I I idea History iscrpancins
t t
>
66001: sueesy 466003:50
Client Beception: Bridence I
rs
>
Customer Der ‘Bridance J
Ps
Branch
Role 2
Role 1
© Xansa 2002
Version 0.4 Page 41/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project: POLS:
Doc Ref: POL/IMPACTIDESIR3029
7.6 A47 Debt Recovery
Agent/clent Cred History hfomation
Hewat Aetene
Debt Recovery tems 9) "on Debt I Ost Recowry Pian
Leger Entry Infermation
Sipia Rassias]
erties Transaction Era
Intamal Debt Recowry Busines Rules
‘ice Reco lett Racor Amounts Through Payrt
Extomal debt Recovery Business Rules
Ledger Entry nfermation
Version 0.4
© Post Office™ 2003
Page 42/124
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.6.1 A47 Debt Recovery (Deduction From Remuneration) 1/3
A47 - Debt Recovery (Deduction From Remuneration) - Page 1 of 3
470010: Revie.
Dett Recovery] M7n-Doe Det Hy pli calcio Ned, Peden I 7%°-Ashs Jou
Section aren Account [Amounts td Remmertion
f
Retail Line 470045: feeme Mares
Manager Sema Fon
{ AS
a Y
Branch i , : _I
} Page? Requancy
[te I
wi
Exceptions
Handling
on
470110: Notify
HR Dedhctces om
Rammencion
Nominee
© Xansa 2002
Version 0.4 Page 43/124
© Post Office™ 2003
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref:
POL/IMPACTIDES/R3029
7.6.2 A47 Debt Recovery (Repayment by Card or BACS) 2/3
A47 - Debt Recovery (Repayment via Debit / Credit Card or BACS) - Page 2 of 3
c
Devt Recovery 470160: PaymaeI__g] 470120: saat Agee 016: Pot 70170; contin,
Daan Staite ps het 010
Section tor Account ‘sym
® 2 =e =
470165: Racie
Retail Line ‘Notification of
Manager Payment Made
aro11s:taceine
sro040:Racdie I Ierorze:pey vaca
Brench Satenet or Debit Card ce
<fPymat Hate
Exceptions
Handling
HR
> 70175: Race
Nominee eeatio +7020, ay wa 20131: Poy ve Bacs sams POt ons
Comections none of Pryment Made
Version 0.4 Page 44/124
© Post Office™ 2003
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/IR3029
7.6.3 A47 Debt Recovery (Deferment) 3/3
A47 - Debt Recovery (Deferment)- Page 3 of 3
70160: Contact
470005; ie OF
. Pormicur Ne 470210: Record 47o220: Noni RLM Ig] 470230:SeaDen
en Recovery Bespanseto Esued Demat éDeiamet Bridenceto RLM Uroecovele Debt
; L 70090: Assess 70001: Aseee
Mews I rma Vaibey I *] corer Cotman]
¥-
470060: Agee
Branch 470040: Receive 70081 s70190:Divewse sromo:-pind I gd sn Ae LL
‘Statement Igurt Sutemet ‘Hardship: Amounts & Frequency
Exceptions
Handling
470093: bhorise
‘rte Of
Head of Area 470092: Rewiew Debt, ‘Unrecowamble Debt
‘mounts
‘MT ‘aT
Role 1 I en]
© Xansa 2002
Version 0.4
© Post Office™ 2003
Page 45/124
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POLIIMPACTIDESIR3029
7.7 A48 - Produce POL Ledger
Broduss Gilet
Ledger Enty Information Ledger
4 Debt information
Trading Transactions
Fedaee Produce Nomiapl Reonaie
Produce Branch Personal POL Business Ledger (E55) I “Lager Nominal Ledger ,I Consolidate I POL Business Ledger(ES-FS)
Ledger Branch Ledger Agent Ledoet Review and Rept
3 9 4
J I_1g
aon of Branch Debt Recovery items
Discropen Liability [eee
Franch Cloaire NouepMAnagement dentiied Transaction Engrs
4
aes
BonkSiatements yi psauice Gas
I& BankLedger
———s
Cheques Processed fp 3
SrsamIne SeWements aes
Produce
Business Tradin
Ledger
é
Investments & Borrowings [Produce]
eee — sonomings and
Tavesiments
Ledger
Produce Sioal
Ledger
Finance
Version 0.4 Page 46/124
© Post Office™ 2003
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: POLFS
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/R3029
7.7.1 A484 Branch Liability Management
Branch Ledger investigate Identified Transaction Errors
Suspense ltemsI
Debt Recovery Items
4
Debt RecoveryIitems
Investigate Debt Recovery Items
Discrepencies I SS
Identified Transaction Errors
2
investigate Unusual
(Outside Norms)
Values in Branch I Debt Recovery Items]
Tabi
3
Branch closing I Closing Branch Suspense Item:
ard tranetors
Branch Closure Notigg Dest Rocowny tome
4
raf
Version 0.4 Page 47/124
© Post Office™ 2003
Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038885
POL00038885
Project: Automated Ledgers
Doc Ref: POL/IMPACT/DES/***
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.
Stock at Branches is controlled on Horizon.
POL FS will receive stock receipt, despatch and write off information from Yantra. The assumption is that there will be a
daily electronic feed of cash centre stock movements from Yantra. If the electronic feed out of Yantra 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
¢ 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 inhand by I ¢ None
currency
Forex revaluations To Foreign Exchange revaluations I e None
Client product/service transactions with I e To Client ledger © Settlement Process
customers including quantity and value, I ¢ To MM Stock by product where e None
when value can be £zero
(and quantity 1) as distinct from an item.
which is not recorded e.g. blank form
relevant
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
Exchange (from stock declaration
process)
To Stock accounts (if balance
sheet stock)
To MM Stock by product
e None
¢ None
Sundry costs & revenue incurred by
branch
e Appropriate sundry revenue and
cost accounts
¢ None
NB: Subsequent actions do not include reporting of information, which is implicit.
Individual Transactions for:
Branch Transaction
POL FS Account/Record (all by
branch)
Subsequent Actions on POL FS
Remittances in and out of Cash
¢ To Cash in Transit
Match to data from Cash
Centre/ADS
Remittances in and out of Foreign To Stock accounts (if balance sheet I ¢ Match to value from
Currency — by individual currency — stock) STAMPS/ADS.
volume and value
© Post Office™ 2003
Version 0.4
Page 48/124
Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038885
POL00038885
Project: Automated Ledgers
Doc Ref: POL/IMPACT/DES/***
Branch Transaction
branch)
POL FS Account/Record (all by
Subsequent Actions on POL FS
¢ To MM Stock by product
Match to Quantity from
STAMPS/ADS
Discrepancies put into or removed
from Suspense
of the Agents ledger)
To Discrepancies (may be a subset
Exception Handling process
Remittance Discrepancies put into
or removed from Suspense
To Remittance Discrepancies
Remittance Discrepancy process
Transaction corrections actioned or
To Agents ledger
¢ Exception Handling process
fejected
Recoveries relating to Transaction To Agents ledger Debt recovery process
Corrections
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 movements
To Cash in hand
None
Receipt of Cheques from
clients
To Cheques in hand
None
Giro Bank a/c movements
To Joint stock bank a/cs
Need to contra off the 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
Loss on sale of foreign coin
To Loss account
None — interfaced as a business loss to ESFS
Sale of counterfeit/ mutilated
notes
To summary movement and ADS client
debtor a/cs
None - Clearing of debtor is to Cheques to
EDS.
Cash centre losses/gains
To Loss account
None ~ interfaced as a business loss to ESFS
Girobank Deposits
To Girobank client_creditor a/c
Compare to Estimates paid to Girobank
Girobank Deposit shortages
not settled
To Girobank Client debtor a/c
None all control on ADS
Girobank Deposit surpluses
no settled
To Girobank client creditor a/c
None all control on ADS
Unidentified pouches To Unidentified pouch a/c None all control on ADS
Foreign Exchange on Hand I To Foreign Exchange in hand by None
by currency currency
Foreign exchange To Foreign Exchange revaluations None
tevaluations
Foreign exchange Wholesale
To Foreign Exchange Purchase/sale
Match to settlement to First Rate
© Post Office™ 2003
Version 0.4
Page 49/124
Conceptual Design
COMMERCIAL IN CONFIDENCE
POL00038885
POL00038885
Project: Automated Ledgers
Doc Ref: POL/IMPACT/DES/***
Cash Centre Transaction
cel
POL FS Accounting all by cash
ntre
Subsequent Action on POL FS.
femittances in & out col
ntrol
Sundry costs & revenue Appropriate sundry revenue and cost None
incurred by branch accounts
Individual Transactions for:
Cash Centre Transaction POL FS Accounting Subsequent Action on POL FS
Remittances in and out of Cash
to Branches
To Cash in Transit
Match to data from Horizon
Remittances in Discrepancies
To Agent account
Send to Horizon as Transaction Correction
Coin Club & Customer bulk To BoE Incoming CHAPS clearing Match to transactions on BoE Statement
cash sale
Coin Club & Customer bulk To BoE outgoing Chaps clearing Match to transactions on BoE Statement
cash purchase
Cash In and out of Bond
To Cash in Bond clearing
Match to BoE Bank Statement
Bank Machine ATM cassette To Bank Machine “debtor’ a/c Bank Machine ATM Process (TBD)
remit out
Bank Machine ATM cassette To Bank Machine “debtor” a/c Bank Machine ATM Process (TBD)
remit in
Repatriation of Scottish Notes
To BoE Incoming CHAPS/BACS
clearing
Match to transactions on BoE Statement
Remittances in and out of
Foreign Currency — by
individual currency — volume
and value
To Stock accounts (if balance
sheet stock)
@ To MM Stock by product
Match to value from Horizon.
@ 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.
Summary Movements in:
NSSC Transaction
POL FS Accounting all by NSCC
Subsequent Action on POL FS.
Receipts of Balance Sheet Stock To Stock Account None
from suppliers To MM Stock by product
Returns of Balance Sheet Stock to I To Stock Account None
suppliers To MM Stock by product
Despatch of Balance Sheet Stock
to Branches
Move from Stock to Stock in Transit
alc
Remove from MM Stock by product
Match to Receipt of stock by branch
Return of Balance Sheet Stock by
branches
Move from Stock in transit to Stock
To MM stock by product
Match to despatch of stock by branch
Write off /adjustments/destruction I To Write/off adjustments accounts None
to balance sheet stock
Receipt of other trading stock from I To MM Stock by product None
suppliers
Return of other trading stock to To MM Stock by product none
suppliers
Despatch of other trading to
Branches
Remove from MM stock by product
Match to Receipt of stock by branch
Return of other trading stock by
branches
To MM Stock by product
Match to despatch of stock by branch
© Post Office™ 2003
Version 0.4
Page 50/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
NSSC Transaction POL FS Accounting all by NSCC Subsequent Action on POL FS
Write off /adjustments/destruction Remove/add to MM stock by product I None
to other trading sheet stock
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 I 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 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 From the data received from the client, summarised information is generated and loaded onto
POLIFS. Settlement team does not require detail information for settlement to clients
442021 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.
442030 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.
Version 0.4 Page 51/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Activity Description
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/veekly basis to clients
444120 Client is sent electronic summary information based daily transaction summaries. (Currently
sent weekly)
444110 On receipt of the paper work and the electronic information, the client carries out their own
444130 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 settlement)
444150 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
© Post Office™ 2003
Version 0.4 Page 52/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
Activity Description
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
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-in 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
Version 0.4 Page 53/124
© Post Office™ 2003,
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
POL00038885
POL00038885
Activity
Description
445010
445020
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) —
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.
445050
Acheck 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)
Version 0.4 Page 54/124
© Post Office™ 2003
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
POL00038885
POL00038885
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.
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
Bra
inches 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)
Version 0.4 Page 55/124
© Post Office™ 2003
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
POL00038885
POL00038885
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.
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
Version 0.4 Page 56/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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 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)
Version 0.4 Page 57/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
Activity Description
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:
e Client name
© Client Product
© Client Bank Details
« 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)
e 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)
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 Amounts due to be paid are discussed between the Team Leader and Manager where necessary
446070 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:
« 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
Itis 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 0.4 Page 58/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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 payment
453070
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 0.4 Page 59/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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 either the client or
466002 the customer.
466003 Evidence is submitted by the client or the customer — for the customer, this may be, for
example, a till receipt or a utility bill stamped and initialled by the branch
466004
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:
e 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 0.4 Page 60/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
Activity Description
470050 Acknowledging the statement of debt, a series of dialogues takes place between the
Postmaster /Nominee and the Debt Recovery Team to determine how the debt is going to
470060 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 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. This
is via a telephone call to Debt Recovery who take the details and process the payment via
470160
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
470180 this should be set to 2 weeks — i.e. 10 working days). Debt Recovery contact the
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 0.4 Page 61/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
Activity Description
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 Ledger_I Release 1
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.
Itis therefore recommended that no reconciliation is attempted between the Horizon and POL FS versions of the Liability
Statement.
8.8 A489 General Ledger Processing
© Post Office™ 2003
Step Who When
1. Clear all GL accounts set up as open item managed Automatic Daily
Job
2. Exception reporting for open items Automatic Daily
Version 0.4 Page 62/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
Job
3.__ Investigate open items POL Daily
4. Inform branches/cash centre/EDS/Streamline of exceptions where I POL Daily
necessary so they can make adjustments
5. Journal any central adjustments into POL Ledger as required. This I POL Daily
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 the following Management Information:
Client Related:
e Value of indebtedness to clients both individually and in total
Value of client indebtedness to POL both individually and in total
Age of indebtedness both individually and in total
Payment History
Overall difference between settlements on client or estimated data and actual value of transactions recorded in
Branches
e NAO requirements
Agent Related:
e Value of agent indebtedness to POL both individually and in total
e — Age of indebtedness both individually and in total
Outstanding Transaction Corrections by Agent and in total
e Value and age of “suspense” items by agent (or branch) and in total
Branch Related:
e Full Balance Sheet by branch
e Full Balance Sheet by branches in RLM / Retail Area Heads hierarchy
e Value of items expensed or written off by branch
e Value of P&L Revenue transacted by branch
Cash Centre Related:
e Full Balance Sheet by Cash Centre
e Full Balance Sheet for all Cash Centres, reconcilable to SAP ADS
e Value of items expensed or written off by Cash Centre
e Value of P&L Revenue transacted by Cash Centre
Post Office Network:
e Full Balance Sheet
¢ Full P&L based on items recorded in Branch/Cash centres
Version 0.4 Page 63/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
e Exception reporting of unmatched items - e.g. remittances, cheques, payments to and from POL bank accounts.
etc.
e DTI Securitisation Report (defined in Release 1)
Stock Reporting
e Volumes for non balance sheet stock
¢ Volume and value for balance sheet stocks
e — Sales versus Holdings branch/hierarchy/business for various time periods
Stock holdings by client, by product and denomination
Foreign Exchange Reporting
e Foreign exchange quantities by branch with sterling equivalent
e — Sales versus Holdings by branch/hierarchy/business for various time periods
Version 0.4 Page 64/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
8.9.2 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.
Client Reporting (Contractual Agreements)
Ref Requirements Description Business Category Report! Proposed
Area Functionality Application
Area
MI100 I Information required by Audit for issued error I Data Client Report POL FS
details, errors BTA and errors not Network I Exceptions
Reinvention offices
MI101 I Information to Multiples Partners regarding I Data Client Report POLFS
outstanding, issued and BTA errors. Exceptions
MI 104 I Ability to produce data files or reports for clients I Data Client Report TMS/POL
as defined within contractual agreements. For I Preparation/ FS
example volume and value of transactions, I Data
customer details if applicable, product I Exception
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.
Version 0.4 Page 65/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Management Reporting
Ref Requirements Description Business Category Report/ Proposed
Area Functionality I Application
Area
MI114 I Volume and value of outstanding I Data Management I Report POL FS
exceptions by branch, by age, by value I Exceptions
MI115 I Volume and value of issued errors by I Data Management I Report POL FS
product or branch Exceptions
MI117 I Number and value of maintained errors I Data Management I Report POL FS
and write offs by product Exceptions
MI 118 I Ability to pull off statistics regarding team I Data Management Report POL FS
performance (exceptions —_created, I Exceptions/
exceptions issued, exceptions cleared, I Debt
exceptions outstanding etc). Ability to I Recovery
Temove from one teams statistics and
add to another team as the exception
passes through the process.
MI122 I Debtor days by client and product and I Debt Management Report POL FS
trend analysis monitoring Recovery
MI123 I Creditor days by organisation and I Debt Management I Report POL FS
product and trend analysis monitoring Recovery
MI124 I Errors produced for creditors and I Debt Management I Report POL FS
debtors - issued or resolved, number I Recovery
and value, by client and product.
MI125 I Progress of exception _ handling I Debt Management Report POL FS
measured against target (failures to I Recovery
issue or clear in x number of days)
MI 126 I Aged debt profile by number and value Debt Management Report POL FS
Recovery
MI127 I Debt as a _ percentage of I Debt Management I Report POL FS
sales/transactions by product Recovery
MI128 I Monitoring of percentage of debt I Debt Management I Report POL FS
recovered and outstanding Recovery
MI129 I Bad debt provision monitoring Debt Management I Report POL FS
Recovery
Version 0.4 Page 66/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
Operational Reporting (What we need to do our day jobs)
Ref Requirements Description Business Category Report! Proposed
Area Functionality I Application Area
MI130 I Ability to pull off ad hoc reports selecting I All Operational I Functionality I Data
required data fields from available list and Warehouse
defining format as required, POL FS
MI131 I Ability to run batch reports to defined I All Operational I Functionality I Data
timescales and formats as required. Warehouse
POL FS
MI 132 I Volume and value of transactions and sup doc I Data Operational I Report Data
information to be reported in a variety of ways I Exceptions Warehouse
(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).
MI133 I All created exceptions to be reported by I Data Operational I Report Data
transaction, by product, by branch. All I Exceptions Warehouse
outstanding exceptions to be reported by
transaction, by product, by branch.
MI 134 I Details of cleared exceptions to be archived but I Data Operational I Report POL FS/
still accessible to provide a rolling 12 month I Exceptions Data
view. Warehouse
MI 136 I Ability to flag branches on exception reports I Data Operational I Functionality I POL FS
that require priority attention or specific action I Exceptions
(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.
MI139 I Ability to report Debt Recovery Case I Debt Operational I Report POL FS
Management By branch, by branch type, by I Recovery
Agent name, by product (by client), by age of
debt.
MI140 I Report on high value debt (e.g. all outstanding I Debt Operational I Report POL FS
debt which exceeds a defined limit, by branch) I Recovery
MI 141 I Report on Debt Recovery repeat offenders I Debt Operational I Report POL FS
(problem offices) Recovery
MI 142 I Value of debt or credit by number, by branch, I Debt Operational I Report POL FS
by branch type (to meet current organisational I Recovery
structure), by product, by method of payment,
by age of debt
MI143 I Former Subpostmasters accounts held I Debt Operational I Functionality I POL FS
including Branch, Agent name, Age of debt, I Recovery
Dispute details, Losses (write off). Ability to
search on a particular field (je. Agent name)
Version 0.4 Page 67/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
Ref Requirements Description Business Category Report! Proposed
Area Functionality I Application Area
and be able to track status, audit log entries
MI 144 I Ability to identify specific types of debt e.g. I Debt Operational I Report POL FS
Invoices debt - Licence fee, ISIS, Shortages, I Recovery
by agent, by branch, by age of debt
MI 145 I Disputed debt by branch, by client (e.g. Giro) Debt Operational I Report POL FS
Recovery
MI 146 I Non-recoverable debt - e.g. as a result of fraud I Debt Operational I Report POL FS
or client negotiations, details to be held until I Recovery
written off. By network (national total of all
branches), by branch, by product, by client
MI 147 I Data archiving ability Support System Functionality I POL FS
Data
Warehouse
MI 148 I Ability to access archived data easily and run I Support System Functionality I POL FS
reports by transaction, by branch, by product, Data
by client as required Warehouse
MI 151 I Ability to schedule regular report production. I Support System Functionality I POL FS
Ability to monitor production of scheduled Data
reports. Warehouse
MI 152 I Report showing transaction, supporting I Data Operational I Functionality I TMS/POL FS
document or client level adjustments. By I Exceptions & Report
branch, by product, by value, by number. To
include date of adjustment, user details and
reason code for adjustment.
Cash Management Requirements
Ref Requirements Description Business Category Report! Proposed
Area Functionality I Application
Area
MI 153 I Ability to undertake trend analysis in order I Cash Operational Functionality I POLFS
to aid forecasting of the future value of I Management & Report
transactions (e.g. DNS, Girobank, DVLA)
MI 154 I Ability to undertake trend analysis in order I Cash Operational Functionality I POLFS
to aid prediction of client for ESFS Management & Report
MI155 I Ability to identify and report the current I Cash Operational Functionality I POLFS
outstanding balance within each ledger. Management & Report
MI157 I Ability to identify and report stock I Cash Operational Report POL FS
holdings by client, by product, by I Management
denomination (e.g. Vodaphone
phonecards, £5, £10 etc.)
MI159 I Ability to produce reports to aid I Cash Operational Functionality I POLFS
Version 0.4 Page 68/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Ref Requirements Description Business Category Report! Proposed
Area Functionality I Application
Area
reconciliation of ledgers and substantiate I Management & Report
ledger balances
MI 161 I Ability to provide verification of accounts - I Cash Operational Functionality I POL FS
Emst & Young Audit requirement Management
MI 164 I Ability to identify cash and stock holdings I Cash Operational Functionality’ I POLFS
by product, by branch Management Report
MI165 I Ability to produce statement of accounts I Cash Operational Functionality) I POLFS
for each client including brought forward I Management Report
figures, sales, settlements made and a
closing balance.
MI 167 I Ability to identify cash remittance in transit I Cash Operational Functionality I POLFS
values by product. Management & Report
MI168 I Summary report of data posted to ledgers I Cash Operational Report POL FS
and interfaced to ESFS by value of I Management
debits/credits against each ledger code.
MI171_ I Daily, National summary of transactions, I Cash Operational Report! POLFS
by client, by product, by method of I Management Functionality
payment. Split by deposits and
withdrawals (rather than net position).
MI172 I Updated transaction data received from I Cash Operational Functionality I POLFS &
Non polled offices to have indicator flag I Management & Report Data
applied. Warehouse
Version 0.4 Page 69/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
8.9.3 Data Warehouse reporting
8.9.3.1 Requirements from the Programme CD
No. Revised Description
MI 1002 Ability to identify top sellers, worst sellers write-off, wastage for particular products by
time and organisation.
Mi 1004 Provision of information regarding office opening hours, closures and relocations to
various internal parties and clients, replacing report ‘TP 129”
MI 1005a Ability to track KPls for the Cash Accounting and Cash Management teams, by
individual against
¢ 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
« 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.
MI 1005b Ability to track KPIs for the Cash Accounting and Cash Management teams, by team
against
e team target and
group target.
Broken down by
e — exception type.
« By product,
¢ Resolution reason
In addition it must be possible to determine the
e Error clearance rate (per team per week)
e Average time spent at each stage of the process by product by the team.
The targets must be parameter driven and it must be possible to group products
together and report as above against targets.
MI 1005¢ Ability to track KPls for the Cash Accounting and Cash Management teams, by group
against 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 group per week)
e Average time spent at each stage of the process by product by the group.
Version 0.4 Page 70/124
© Post Office™ 2003
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
POL00038885
POL00038885
The targets must be parameter driven and it must be possible to group products
together and report as above against targets.
MI 1006 Ability to produce value and volume of exceptions (transaction corrections) for historic
feporting and trend analysis.
e By transaction type
e — By product,
e — By organisational unit,
e By exception status (e.g. created, cleared, outstanding),
© Period
Against total
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 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 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:
e A44 Client Settlement to Client
¢ A465 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 $70 reporting requirements
No.
Original Description
MI 1101
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
© Post Office™ 2003
Version 0.4 Page 71/124
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
POL00038885
POL00038885
MI 1102
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
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
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 0.4 Page 72/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
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 0.4 Page 73/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
8.10 New Reference Data System
The NRDS has jurisdiction over the following systems:
Horizon; POL FS; SAP HR.
Itis not in the scope of the NRDS to control reference data on SAP ADS, YANTRA, 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 0.4 Page 74/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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) Alogical 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
Product
POL FS
Article
Z Dummy
Quantity (0)
“Articl
Mode’
: &
Ss POL FS
Account (0)
HORIZON
Mode
[Settlement Type (0)
[+-———Ledger Indicator (0)
[-———Summarisation
L_ Transaction Reference (0)
‘Movement Type (0)
Map of Data Entities in Logical Data Map to POL Data Model
I 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
© Post Office™ 2003
Version 0.4 Page 75/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
§ 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
= — REMin 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 POLFS
POL Data Model All logical data items above equate to either:
Ledger Posting: For all value transactions
Inventory Item: For all stock transactions
Version 0.4 Page 76/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
9.2 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 AIS I It is unclear if information relating client related transactions will be recorded
such that TMS can pass this data to Ml. 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 POLFS
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.
Version 0.4 Page 77/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POU/IMPACT/DES/**
9.3 Financial Results to ESFS
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 POLFS
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
AIS Issued
Source POLFS
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
© Post Office™ 2003
Version 0.4 Page 78/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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.
AIS Issued - one for each logical data item
Source NRDS
Destination POLFS
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.
Als Issued
Source POLFS
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
© Post Office™ 2003
Version 0.4 Page 79/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
9.7 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.
AIS Unknown
Source NRDS
Destination Horizon
POL Data Model See 8.10.2
9.8 NSSC Stock movements from YANTRA
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 retums of stocks to/from branches
«Write off/adjustments of stock in NSSC
Special requirements
The link between the Yantra 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 Ais 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.
AIS Issued
Source YANTRA
Destination POLFS
POL Data Model Logical data items will all be Inventory Item Movements
© Post Office™ 2003
Version 0.4 Page 80/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
9.9 Summary Transaction Information to Girobank
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 POLFS
Destination Girobank systems
POL Data Model Ledger postings
9.10 Summary Transaction Information to NS&l
Attribute Description
Description The file will contain the summary of transaction information relating to NS&I
Logical data items = Summarised transactions quantities and values by branch, day and product as
fequired.
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&I to establish requirements.
Als Outstanding
Source POLFS
Destination NS&l systems
POL Data Model Ledger postings
Version 0.4 Page 81/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
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 = 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.14 Statements to Agents
AIS not being produced — not an electronic data flow
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 0.4 Page 82/124
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL00038885
POL00038885
Automated Ledgers
POLIMPACTIDES/*"*
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
= __ Payment references and values
Special requirements
None at this time
Time constraint None
Type of Object Electronic file
Als Outstanding
Source POLFS
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
* __Intemal 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.
Als Outstanding
Source ESFS
Destination NRDS
POL Data Model Cost Centres & Internal order - Represent Organisation Units - in particular
Branches
© Post Office™ 2003
Version 0.4
Page 83/124
Conceptual Design
COMMERCIAL IN CONFIDENCE
Project:
Doc Ref:
POL00038885
POL00038885
Automated Ledgers
POLIMPACTIDES/*"*
10 Non-Functional Requirements
10.1 Volumetrics
10.1.1 Peak Day figures
Horizon 17500-18000 3,600,000
SAP ADS 20 72,000
YANTRA 1600 40
Bank Statements 600 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
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.
Documents ILines Line Items Retention IComments
per doc period
months
ICCA Cost Centre Accounting 10,000) 15 450,000] 43INeeds to be held for 4
ye
PCA Profit Centre Accounting 10,000,000) 10 100,000,000} 3]Needs to be held for 1
ye
Fi (fb01) _IFinance Documents 8,320,000} 139} _1,156,480,000) 13
MM (mb01)IMaterial Movements 7,346,000 137] _1,006,402,000) 3
ISD (va01) [Sales invoices 5,320,000) 160 851,200,000} 4873 MONTHS 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:
The audit requirements from a technical perspective are:
the raw (unprocessed) data and be kept for 18 months.
stored within the SAP system
then stored in line with current Horizon practices
© Post Office™ 2003
Version 0.
4
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.
to keep a copy of all bulk data files exchanged between the POL FS domain and other domains. The data should be
audit records of user activity within the SAP application should be created by standard SAP functions and then
audit records of support activity on the POL FS host platforms should be created by standard Horizon functions and
Page 84/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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
e 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
e Support for the Service should be available during the hours of service measurement i.e. 07:30-19:30 Mon-Fri
(excl. Bank Holidays)
tis 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 clientInetwork 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
! The service boundary will be defined during contractual discussions
Version 0.4 Page 85/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
Itis 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:
e 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
e — Allother data to be loaded into POL FS to be made available by 03:00
° New reference data to POL FS
¢ — Stock movements from YANTRA to POL FS
Itis 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
The BACS interface will be scheduled to run during the on-line day.
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.
Version 0.4 Page 86/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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
y See service levels for the Host Service under section 10.3
10.3.3 Prism Alliance
I Same as current LFS service levels
10.4 Problem 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
10.4.3 Backup & Recovery
All business data must be backed up daily. Backups should be kept for 4 days before being overwritten.
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:
e the number of supported users
e end-user response times
e the time by which data loads have to be complete
Presentation Service
Version 0.4 Page 87/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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
e 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
e Consolidation of related processes, to minimise movements of data, reduce audit
and reconciliation points
e Adoption of commodity platform products to minimise hardware and associated
support costs and to maximise availability of skilled resources
e Usage of packages, where business requirements can be mapped onto generic
product capabilities
e — Clear separations of functional boundaries to retain flexibility in the future
Version 0.4 Page 88/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
11.1 End-to-End Architecture Diagram (Example shown below)
Fujitsu Domain
Counter : RMG Domain
Physical View
- PRISM
Horizon Data Centre i Domain
Huthwaite
lanagement Information
Stock
Warehouse
‘Transaction
Management
(ine Adjustment
Notification)
Version 0.4 Page 89/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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:
« 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
e 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
e 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.
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.
Version 0.4 Page 90/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
Bespoke processes such as the jobs that process the files fed from Horizon should be monitored.
Itis 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
« — successful loading of the inbound interface files
e — successful production and delivery of the outbound interface files
Version 0.4 Page 91/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
11.3 Integration & Interface
Horizon to POL/FS interfaces
SAPIADS to POLIFS interface
POLIFS 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
YANTRA 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.4 Other 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
e 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
e 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 Northem Data
Centre
? By SAP client domain this means the end user components of the SAP solution that are managed by Prism.
Version 0.4 Page 92/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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 POLIFS Interface
AIS for SAP ADS to POLIFS 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 Yantra 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.
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
Version 0.4 Page 93/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
13.2.6
13.3
13.3.4
13.3.2
13.3.3
13.3.4
13.3.5
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.
Fujitsu Services
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.
End to End Integration, Testing and Acceptance
Post office will determine how this task is carried out.
See Section 17
Managed Service
Fujitsu Services shall provide service support for hosting the POL FS application.
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.
Internal Processes & Procedures
Fujitsu Services shall update where necessary, any internal processes & procedures, in order to support the
Horizon elements of the project.
14 Planning
14.1
14.2
© Post
Timescales
Refer to Release 3 and S80 project plans
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 0.4 Page 94/124
Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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
co Review suppliers internal test results / progress reports
o Review suppliers internal testing fault logs for impact
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: -
o Supplier document reviews
o Review of supplier test plans / scripts for completeness
o Witness specific key tests during a supplier testing cycle
o Review supplier test results
Version 0.4 Page 95/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
o Review supplier test fault logs for impact
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
co 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
oo0°0
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)
o 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.
16.1.8 Counter & Interface Testing
e — 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.
Version 0.4 Page 96/124
© Post Office™ 2003,
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
POL00038885
POL00038885
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.
FS solution is implemented.
Version 0.4
© Post Office™ 2003
Page 97/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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 0.4 Page 98/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
18 Appendix A- Requirements Catalogue
Details of the acceptance method can be found in section 16.
Program Req I Req ID Supplier X Ref to Description
ee
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
I _to Royal Mail Group using simplified business processes and reduced duplication and requirement for reconciliation
FIH-002 FIH 002 Prism 44 I . Introduction of a Client Ledger, Agent Ledger, Stock Ledger to enable standard procedures for Debt Recovery and
i I monitoring. To enable the capture, validation, verification and correction of client transaction data.
FIH-003 FIH 003 Prism 44 Produce POL Ledgers to report P&L and BS for POL in so far as the transactions are handled within the POL
“TASS 00
___environment with a stream of data from branches and cash centres .
I The Cash and Bank account values, from ledger implemented i in $60, will not be overwritten with CLASS v lues at
V ASS 002
_ASS 003
Matching o of client summary data to POL FS data will be done on a risk based approach.
I Reporting of transaction data to clients will not take place on PO! is information will either
L _ directly (e.g. AP/Banking), or is available from MI.
ASS 005 Prism 42 Depending upon where it resides at the time of S80 implementation, Foreign Exchange movements to/from cash
I centres will be received by POL FS either by an automated feed from SAP ADS or by the manual input of output
1m STAMPS.
‘fed to clients
“ASS 006 Prism 4.2. Inorder that some of the exi isting c controls can be removed there is a ‘plan of migration ‘of some - products/services to.
_ Automated Payments process. This piece of work is with Sales and Marketing. If this is not completed then there
I are some controls, which currently exist in the legacy systems that are not being designed with in POL FS. These
_ controls will be replicated in another system, to be defined.
ASS 007 Prism 42 I It is assumed that an electronic feed of stock movements to/from the branch network will be provided by the
. L i __YANTRA System that should have replaced the STAMPS System before S80 implementation.
ASS 008 _ Prism 42 i Reporting of data to clients from POL FS will be at the maximum level of Branch, Trading Day & Product.
__POFS 001 Prism 43 POL FS will be the auditable financial ledgers for Post Office Ltd Network.
_ POFS 002 44 I It shall be possible to audit movements within POL FS by branch back to Horizon
POFS 003 “P : 7 440 Tits shall be possible to reconcile movements within POL FS by cash centrebacktoSAPADS
POFS 004 44 I Technical requirement: to keep a copy of all bulk data files exchanged between Horizon domain and Prism domain.
_ Fujitsu The data should be the raw (unprocessed) data.
Version 0.4 Page 99/124
© Post Office™ 2003
POL00038885
Program Req
D -
Req ID
~ POFS 005
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
‘Supplier =X Ref to ] Description
a NS OO
Prism 44 I Technical requirement: audit records of user activity within the SAP application should be created by standard SAP
POFS 006
Prism/ 44
Fujitsu
echnical 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
TEC - 001 TEC 001 . “The applications should be data driven
TEC - 002 TEC 002 45.2 The applications should be modular were ever possible thereby allowing components, such as the presentation
“TEC-003 TEC 003
TEC -004 I TEC 004 related =
TEC - 005 TEC 005 45,2 _ Adoption of commodity platform products to minimise hardware and associated support costs and to maximise
La en on ane co 2vailability of skilled resources sn
TI TEC 006 Prism _Usage ges, where business pped onto generic product capabilities
TEC - 023 TEC 023 Prism _ Integration with SAP ADS
TEC -025 TEC 025 Prism 45 I Integration with ES-FS
TEC -025a § TEC 025a Prism 45 / Integration with Horizon
i _ Fujitsu I i
L TEC-026 Prism 45 __ Integration with NRDS
TEC 027 __Integration with Yantra
ACM 001
_ACM-001
~CSH-001
“CSH-002
CSH 001
CSH 002
© Post Office™ 2003
/ Prism 5.4
‘Prism 6.3
I Interface with Girobank
_Interface with DNS
Integration with BACS
il Any individual component of the programme must conform to the POL Strategic Data Model
“To implement a client ledger that accurately identifies PO Ltd’s liability to and from clients and enables accurate,
To receive a daily interface of summarised transaction data, from Horizon, by client or product.
I
Version 0.4
Page 100/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID I Supplier =X Ref to I Description
ID L _ThisCD
CSH-003 CSH 003 Prism 6.3 To refer to information about transactions from clients in order to resolve any disputed items and determine true
I liability. Summary available from POL/FS detail from Data Warehouse
“CSH-004 CSH 004" Prism “63 i To receive a daily interface of summarised transaction data, from SAP/ADS, by client or product.
CSH 005 Prism 63 I To calculate, pay / receive and account for Client settlements based on the contractual data stream, being any
_ combination of:
/ Horizon
I « SAP ADS (eg Corporate deposits)
¢ Client data (eg Camelot)
I e Other existing contractual stream (e.g. BBC non bar coded licences)
e Stock adjustments from NSSC.
63 _ __To pay / receive settlements based on estimates and / or including standing deposits :
CSH006
ee GSH OOF $3. ttlement facility to be available by 7:30 am in support of client settlement terms
CS 001 Cs 001 6.3 A daily view of summarised balance (value and volume) by client, by product, by branch or cash centre, and by
I day.
“C8002 Cs 002 Prism 6.3 I Ability to split client balances, when a client has several products or contracts with different terms of payment, in
i Z order to map into different sub accounts in the ledger _
CS 003 CS 003 I The ability for each trading day to have a unique document entry
CS 004 CS 004 Prism 763 I The ability for non-polled offices transaction data, once received, to be:
e Accounted for in the current accounting period based on posting date
I Recorded against the appropriate trading dates
I Settled to clients based on trading date
CS 005 CS 005 Prism 6.3 he ability for differentiation between trading date and posting date.
CS 006 I CS 006 Prism 63 “The ability to receive client summary reports, by volume and value, for Automated Payment clients. These will not
i _ be held in POL FS.
CS 007 CS 007 Prism 6.3 _ Amechanism to be able to trace disputed totals back to transaction level, on MIS, in order to resolve and correct
_ information at the appropriate p
Version 0.4 Page 101/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
Program Req ReqID I Supplier =X Ref to I Description
ID i _ This CD L
cs 009 Prism 6.3 Ability to compare the values of settlement made based on client against actual data from Horizon for the equivalent
I period. POL FS will enable comparison at a daily branch and product level for all such clients. There will be the
L i _ability to perform detailed transaction comparison but this will not be on POL FS. I
Cs 010 Prism 6.3 I The ability to provide a generic solution for the main proportion of clients and only build exception processes when
L L I __Necessary
cs 011 Prism 6.3 _. To be able to settle (pay and receive) by contractually required methods of payment:
« =BACS
© CHAPS
e «Swift
e Cheque
i Direct Debit (payment receipt only)
cs 012 Prism 6.3 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.
“C8014 Prism 6.3
Ll _ Warehouse reporting.
cs 015 Prism 6.3 I The ability to adjust settlement and account for discrepancies identified from:
I ¢ — Client invoices or data mismatches with Horizon transactions
e Transaction Corrections (covering customer, supplier and branch queries)
e Banks (unpaid cheques & Data Reconciliation Service adjustments)
e Estimating differences
C8017 / Prism 763 Settlement process, to include adequate control procedures, and to pay amounts due in accordance with client's -
I Individual settlement terms.
CS 018 Prism 6.3 i 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 I To implement a debtor's ledger (accounts receivable), which accurately identifies amounts owed to PO Ltd liabi y
I from agents, former sub postmasters, customers and clients in relation to transaction balances. If client balances are
I on an accounts payable ledger then to be able to identify and manage debit items within the overall creditor.
Version 0.4 Page 102/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
Program Req ReqID I Supplier =X Ref to I Description
ID i _ThisCD
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
I e.g. cash receipts by debtor from the POL ledger entries.
“DRH- 003 DRH 003°” “Prism 764 i To be able to record debt recovery plan decisions, and action taken so as to manage debt recovery and document I
I stages of escalation taken.
DRH- 004 VDRH 004° Prism P64 ‘To be able to refer to information about transactions both in MIS and directly entered trading transactions with
I 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 “To be able to generate identified transaction errors, to be fed back electronically to Horizon, if, as a result of
ee ee ee ee investigation, debts need to be transferred and corrected within a branch liability statement.
DRH- 006 DRH 006 Prism 64 I To be able to view debtor credit history in order to assess credit worthiness.
DRH - 007 DRH 007 Prism 64 I To be able to assign appropriate credit terms to different debt items e.g. 30 days for counter transaction errors, 45
__days for
ins to SPMs
DRH-008 ~~ DRH 008 Prism To be able to assign different agents/branches to a central “head office” payment point in the instance of multiples
I who require a central authorisation for settlement to POL.
— DROO1 Prism _ daily view of outstanding debtor balances (or suspense items) and the history of management for live items
DR 002 DR 002 _ Ability to age debt (or suspense items) so as to manage over due items.
_ at the appropriate point to amend ledgers, and reporting or management information.
_ information will come from NRDS.
Version 0.4 Page 103/124
© Post Office™ 2003
Conceptual Design
POL00038885
POL00038885
Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/"*
Program Req ReqID
ID
“DR-005
DR 005
Description
UA flag needs to be set when a branch (or in the case of multiples the total of branches) has a debt of more than
~DROO6
“DRO?
DRO08
‘DROO9
~CHH-002
DR 006
“DR 007
DR 008
DR 009
“DR O10
DRO11
CHH 002
© Post Office™ 2003
Supplier X Ref to.
i _ This CD
Prism 64
Prism 64
(Prism 6.4
Prism 64
“Prism 64
geet eo
Prism 6.4
Prism 6.5
I To be able to produce debt recovery reporting such as —
I 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)
I Debt Recovery repeat offenders (problem offices)
I Value of debt or credit by number, by branch, by branch type (to meet current organisational structure), by product,
I 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)
I Non-recoverable debt - e.g. as a result of fraud or client negotiations, details to be held until written off. By network
I (national total of all branches), by branch, by product, by client
i Ability to search on a particular field (i.e. Agent name) and be able to track status, audit log entries
Version 0.4
i Ability to record ‘Agent's debt from:
_ Ability to produce invoices for transaction corrections to be sent to central “head office” for 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
I requirements. Measurement against agreed timescales.
¢ Actioned Transaction Corrections — automated from Horizon interface
_Other debts as identified - manually entered
_ Ability to record reductions in debt on agent's account based on:
e Payment by Credit Card
*__Deductions from payroll
I IADS 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)
SAP/ADS to make available, by cash centre, to the POL Financial System the detailed cash pouch data, for
I remittances into the cash centre, for entry into the cash ledger to enable Cash In Transit matching within the ledgers
(Release 1)
wake available, h centre,
transactions, (value and volume), by client for entry into the client ledger
Page 104/124
Conceptual Design
POL00038885
POL00038885
Project: Automated Ledgers
~SRH-001 “SRH 001
© Post Office™ 2003
Prism
66
Version 0.4
I To provide end to end vis
_ National Secure Stock Centre) until sale, loss or return.
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
Program Req ReqID Supplier © X Ref to I Description
ID i _ThisCD
CHH-004 CHH 004 Prism 6.5 SAPIADS to undertake the summarisation of required data, to an agreed level, prior to entry into the cash and client
CHH-005 CHH 005 Prism 6.5 I The interface will provide all transactions which affect cash and near cash values of the cash centre. For exampk
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
I Cheques on hand
CHH-006 CHH 006 Prism 6.5 "ihe interface will provide a snapshot of all transactions at approx midnight and must be available within the POL FS
es ee ns ef _-by.07:30 the following day. nnn nnn
CHO001 CH 001 Prism 6.5 I 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
I populate the interface.
I The trading statement will encompass a snapshot of cash and stock and also any current discrepancies or suspense
I items. It will also enable the cash centre to view what business has been transacted over the last period. The cash
I centre manager will be required to “sign off’ the trading statement as a true and accurate position at specified points
in time.
I It is possible that the SAP/ADS system can produce the level of information required which would satisfy both
I control issues and security and audit requirements.
I The Trading Statement is being developed independently of POL FS by CL&S.
ity of the stock movements from point of entry (whether direct to branch or via the
Page 105/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
Program Req ReqID I Supplier =X Ref to I Description
ID i _ThiscD
SRH-002 SRH 002 Prism 6.6 POL FS MM module to accept a daily interface of stock sales in order to maintain accurate link between stock
I movements and stock sales.
“SRH-003 SRH 003 Prism 766 I POL FS MM module to accept a daily interface of stock adjustments at the branches, from stock declaration
Ll I i __process hence identifying stock discrepancies.
SRH-004 SRH 004 Prism 6.6 I To provide an interface of stock at National Secure Stock Centre, identifying stock discrepancies, for despatch to
I I __POL FS MM module.
SRH-005 SRH 005 Prism 6.6 To provide auditable balances of stock throughout the network for probity and audit purposes
“sR oot SR00i I Prism 66S The Horizon system to make available to the POL FS MM module details of identified stock discrepancies by
I volume, and value, (where relevant).
“R002 'SR002 Prism 6600 ~The Horizon system to make available to the POL FS MM module the daily movements of stock into and out of
“SR 004 SR004 Prism
“SR 008 *SR005 Prism
SR 006 SR006 Prism
SR 007 SR 007 Prism
“SR 008 “Not included
I in $80 CD
© Post Office™ 2003
_ MM module the daily sales of stock.
766 I 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.
6.6 The National Secure Stock Centre to make available to the POL FS MM module the daily movements of stock into
I and out of the central stock unit by volume, and value, (where relevant). These must include both intemal and
_ external movements.
6.6 I The POL FS MM module to hold information by stock type in order to inform POL FS of all balance sheet impacts.
6.6 i POL FS MM module to hold value of all stock, which has a balance sheet impact, by stock item.
To identify instances of obsolete stock which should have been returned to National Secure Stock Centre
Version 0.4 Page 106/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
Program Req ReqID I Supplier =X Ref to I Description
ID L _ThiscD
BDC 001 Prism 67 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.
The daily movement in foreign currency held will be received as part of the daily interface from Horizon. _
BDC 002 Prism 6.7 “Stock quantities (e.g. $300) of Travellers cheques, by currency and branch to be held within POL FS in MM module
I (not valued)
BOC 003 Prism 67 ’ Margins and Commissions on transactions (Sell and Buy) are to be posted to an appropriate settlement account for
the Bureau Joint Venture.
_ current build for Horizon triggers_~ revaluation from the running of the trial balance.
BDC 005 Prism 6.7 Currency transfers between the Cash Centre Network and the Client are to be included within the POL FS Balance
I I Sheet, with postings to a Client Settlement Account where appropriate.
BDC 006 Prism 6r / ‘Management information in support of individual inventory management capability will be available within POL FS
I (e.g. stock : sales ratios by Branch; stock holdings by branch or branch hierarchy)
BDC 007 / Prism "er T POL FS reporting capability to be accessible within the Cash Centre Network.
“BDC 008 Prism 6.7 "Stock adjustments to be recorded separately in POL FS.
‘NRDS001 Prism s68 _ NRDS to provide reference data shared by multiple systems to POL FS
NRDS 002 Prism 6.8
il a 68 ; RDS to accept reference data mastered i in POL FS ‘that i is ‘required for interface data mapping _
NRDS 003 Prism 6.8
CNRDS to provide a ‘data mapping faci ity to enable interfaces between. significant systems to be controlled ‘using I
_teference data rather than hard coding
NRDS 004 Prism 68 _NRDS interface to Horizon to be enhanced with various data objects including interface data mapping logic.
I ly y , by : yy day.
cs001 L
FI-002 Covered by = Prism 6.3 _ Ability to split values, when a client has several products with different terms of payment, in order to map into
cso02 _ different accounts in the ledger.
Version 0.4 Page 107/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/"*
Program Req ReqID
ID
“F003 Covered
by
Prism
_This CD _
63
I Supplier =X Ref to I Description
I The ability for each trading day tohavea unique line.
“Fi-004 Covered by = Prism 6.3 he ability for non-polled offices transaction data to be summarised into the relevant trading day when next polled.
Cs004 l
Fl-005 Covered by Prism 63 i The ability for differentiation between trading date and posting date.
Cs005 {
FI-007 I Covered by Prism 6.3 I To be able to determine the amount due to a client using payment terms agreed with client
~FL-008 64 I
“FL-009 Covered by I Prism 763 I To enable payments tofrom clients with functionality for matching and closing paid items to leave open items for
cs19
__Management of debtors/creditors .
© be able to produce correspondence to chase ou
statements, reminder letters
FLOt1 Covered by = Prism 64 I To process agent debt items
I DROO1 I I i
FI-012 Covered by = Prism 64 _ Allow matching to enable management of open items
DROO4 I
“FLOI3-- “Covered “by Prism 6.4 “Tobe able to produce correspondence to chase outstanding items e.g. statements, reminderletters
DROS Ll
FI-014 Covered by = Prism 64 I To provide information of aged balances
DRO15 l
“FOI FL015 6.2 i To produce a set of auditable accounts within the framework of I of Accounts speci
FI-016 FL016- Prism 6.2 _To enable matching of suspense items for debt recovery purposes and error handling -
ELOIT FLOI? Prism $2. -und0.enable the reporting of stock values in the relevant balance sheet accounts (this will cover the Stock Ledger)
_FL018 F1018 _ Prism 6.2 __To consolidate information from SAP ADS financials to report the POL accounts
_FI019 _F1019 Prism 6.2 ‘© account for business transactions which will populate the trading ledger
tt ( Br
F021 _ Prism 64 lonitoring of system rejections to ensure that data is resent and processed or accepted successfully
FI 022 Prism 6.1 I System Management controls e.g. access levels, user ID's, passwords etc.
i
Version 0.4 Page 108/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID I Supplier =X Ref to I Description
JID L _ This CD L
FI 023 Prism 6.1 Ability to monitor interfaces received and processed or rejected, and extracts produced including reconciliation of file
I interfaces across systems (i.e. data received by POL FS from TMS also received by Data Warehouse). Where
L i __fejections occur, error messages should be produced, indicating reason, to aid investigation.
MI 100 Prism 8.9.2 I Information required by Audit for issued error details, errors BTA and errors not Network Reinvention offices
M401 ’ Prism 7692 information to Multiples Partners regarding outstanding, issued and BTA errors.
value of transactions, customer details if applicable, product breakdown by volume and value, details of adjustments
I 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
I tate, DVLA, Department of Health, Inland Revenue.
/olume and value of outstanding exceptions by branch, by age, byvalue
. .
MI 115 Prism 8.9.2 I Volume and value of issued errors by product or branch
I exceptions outstanding etc). Ability to remove from one teams statistics and add to another team as the exception
passes through the process.
I
MI 122 ' Prism 8.9.2 I Debtor days by client and product and trend analysis monitoring
MI 125 Prism 8.9.2 i Progress of exception handling measured against target (failures to issue or clear in x number of days)
PMri26 Prism 8.9.2 I Aged debt profile by number and value
MI 127 Prism 8.9.2 I Debt as a percentage of sales/transactions by product
I
Version 0.4 Page 109/124
© Post Office™ 2003
" Ability to produce data files or reports for clients as defined within contractual agreements. For example volume and
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID I Supplier =X Ref to I Description
i) L _ThisCD
MI 128 Prism 8.9.2 Monitoring of percentage of debt recovered and outstanding
MI 129 Prism 8.9.2 I Bad debt provision monitoring
MI 130 Prism 8.9.2 i Ability to pull off ad hoc reports selecting required data fields from available list and defining format as required.
Teports to defined timescales and formats as requ
lity to
I
~""Velume and vaiue of transactions and sup doo information to be reported in a Variely of ways (e.g. by transaction, by
I 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 433 Prism °8.9.2 Al created exceptions to be reported by transaction, by product, by branch. All outstanding exceptions to be
I feported by transaction, by product, by branch.
MI 134 Prism 8.9.2 ‘Details of cleared exceptions to be archived but still accessible to provide a rolling 12 month view.
MI 136 7 Prism “892 I 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
I 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
I client), by age of debt.
MI 140 Prism 8.9.2 i Report on high value debt (e.g. all outstanding debt which exceeds a defined limit, by branch)
MI 142 Prism 8.9.2 i 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 I Former Subpostmasters accounts held including Branch, Agent name, Age of debt, Dispute details, Losses (write
I off). Ability to search on a particular field (i.e. Agent name) and be able to track status, audit log entries
I
Version 0.4 Page 110/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACT/DES/"*
Program Req ReqID I Supplier =X Ref to I Description
i) L _ThisCD i
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
I age of debt
Mi 145 ‘Prism 8.9.2 Disputed debt by branch, by client (e.g. Giro)
M446 ’ Prism 7692 I 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 151 Prism 8.9.2 _ Ability to schedule regular report production. Ability to monitor production of scheduled reports.
TMi 152 Prism 8.9.2 I 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 8.9.2 lity to undertake tr 1d analysis in order ‘prediction of client for ESFS
Mi 155, “Prism” 8.9.2 "Abiity io identify and report the current ouistanding balance within each ledger,
i
MI 157 Prism 78927 t Ability to identify and report stock holdings by client, by product, by denomination (e.g. Vodaphone phonecards, £5,
I £10 etc.)
. MI 159 i Prism. 7 iG 9.2 bility to produce reports to aid reconciliation of ledgers and substantiate ledger balances _ .
MI 161 Prism 789.2 Ability to provide verification of accounts - Erst & Young Audit requirement
- MI 164 I Prism 8.9.2 — I “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
I anda closing balance.
I
Version 0.4 Page 111/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDES/"*
Program Req ReqID
D
MI 167
MI 1002
Mi 1004
I Supplier =X Ref to I Description
Prism
_This CD
8.9.2
I Ability to identify cash remittance in transit values by product.
_ Summary report of data posted to ledgers and interfaced to ESFS by value of debits/credits against each ledger
I code.
I 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.
Provision of information regarding office opening hours, closures and relocations to various internal parties and
I clients, replacing report ‘TP 129”
MI 1005a
© Post Office™ 2003
{
_ Ability to track KPIs for the Cash Accounting and Cash Management teams, by individual against
¢ _ individual target,
team target and
e group target.
_ Broken down by
e Exception type.
e By product,
e Resolution reason
_ In addition it must be possible to determine the
e 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
I against targets.
Version 0.4 Page 112/124
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID Supplier © X Ref to I Description
i) i _ThiscD
MI 1005b Prism 8.9.3 Ability to track KPls for the Cash Accounting and Cash Management teams, by team against
e team target and
e group target.
I Broken down by
e — exception type.
e By product,
I ¢ Resolution reason
In addition it must be possible to determine the
e Error clearance rate (per team per week)
e Average time spent at each stage of the process by product by the team.
I The targets must be parameter driven and it must be possible to group products together and report as above
against targets,
I
Mi1005c¢ Prism °89.3 _ Ability to track KPIs for the Cash Accounting and Cash Management teams, by group against group target.
I 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 group per week)
Average time spent at each stage of the process by product by the group.
I The targets must be parameter driven and it must be possible to group products together and report as above
I against targets.
Version 0.4 Page 113/124
© Post Office™ 2003
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID I Supplier =X Ref to I Description
i) L _ThiscD
MI 1006 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,
e By organisational unit,
e By exception status (e.g. created, cleared, outstanding),
I «Period
I Against total
“M1010 Prism 89.3 Ability to identify and report on multiple transactions (e.g. multiple AP transactions carried out against the same
MI 1016 I Prism 89.3 T Ability to carry out Rota Checking. The rota checks must be data driven and the outlets selected will vary over time.
I This is in support of Rota Checking Process.
MI 1017 ' Prism 7893 ] Ability to carry out Range Checking of aggregate total. This is in support of the Range Checking process.
_ of the following processes:
e A44 Client Settlement to Client
I ¢ — A45 Client Settlement from Client
I It must be possible to load client transaction level data for investigation and compare to the POL transaction data
I stream for that client.
Mi 1101 bility to work out a notional cost for recorded errors for each branch by applying ABC (Activity Based Costing). To
I support product P & L analysis
—" PMrtio2 “Prism “8.9.3 I Daily reporting by value, volume and margin (all products) as provided by ABC, giving Product Profit & Loss. To
I support branch P & L analysis
Mi 1103 Prism 8.9.3 ; I Data feed required to produce the Recall report, This is based on an existing AS.
Version 0.4 Page 114/124
© Post Office™ 2003
I customer teference). Based on an OPTIP report that provides information of this nature (1958 - Multiple
Transactions Report).
Conceptual Design
POL00038885
POL00038885
Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID Supplier © X Ref to I Description
ID i _ This CD
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 I Data feed required to existing Horizon MIS
“Mi 1106 Prism 893 i Data feed required to support Risk Model
“/MI1107-~~ Prism" 8.9.3 Ability to monitor and take action on the completion of Branch Trading Statements
PMit108- Prism 8.93
I 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
I 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.
I There is a further requirement to enquire on existence and data contained within these events, to allow further
I investigation of Branch Trading Statement production activity.
Ability to monitor and take action on amounts made good and/or amounts removed with associated values
I There is a requirement to produce summary reports based on the existence and data contained within the following
I 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.
I 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
Version 0.4
© Post Office™ 2003
_ Ability to monitor the usage of Cash Variance reports
I There is a requirement to produce summary reports based on the existence and data contained within the following
I 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.
I 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.
Page 115/124
Conceptual Design
Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POL/IMPACTIDESI**
Program Req ReqID Supplier © X Ref to I Description
i) i i _ThiscD
MI 1110 Prism 8.9.3 Ability to monitor and take action the number of outstanding Transaction Corrections at a branch
© Post Office™ 2003
I 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
I system. The report will summarise and highlight, transaction corrections by branch, by age outstanding and by
I 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 0.4
Page 116/124
POL00038885
POL00038885
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
19 Appendix B - Impact Stakeholder Forum Design Principles
Principles/ Working Assumptions for discrepancies
e 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
e 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
e The correction should be automatic or with minimal intervention (this needs to be confirmed with FUS and may
not be possible)
«Transaction corrections which are not undertaken within stipulated timescales will create an exception report
from POLIFS in order to aid any further investigation
e 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
«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
«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.
e 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.
e The differing scenarios for transaction corrections e.g. multiples, directly managed will be managed by
reference data.
e 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
e Horizon will record volumes/ quantities only for all transactions, except on sale, or loss, transactions when it will
additionally record value.
Version 0.4 Page 117/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
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
e Vendor accounts should be set up using standard SAP functionality
e For clients paid on estimates the principle of a “holding” account will apply
e For client paid on their data, currently matched via OpTip, will only be matched if deemed high risk eg Lottery.
Low tisk 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
e — Verification will take place at the branch and within MI not within POL/FS
Version 0.4 Page 118/124
© Post Office™ 2003
Conceptual Design Project:
COMMERCIAL IN CONFIDENCE Doc Ref:
POL00038885
POL00038885
Automated Ledgers
POLIMPACTIDES/*"*
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 4
+ By end of day cheques sent to EDS for Processing
* Cheques “Remmed-out” of Branch
+ Nightly interface summarises data and sends to POL FS.
Version 0.4
© Post Office™ 2003
Page 119/124
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
+ — Effective Accounting on POL FS - MVL sale
+ CrDVLA 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 ale Value by branch and day
+ Dr Cheques in Clearing GL alc Daily value
* Clear Cheques to EDS GL a/c 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
20.4 Transaction Corrections
* Replaces the Error Notice
* Electronic Message to Horizon
Version 0.4 Page 120/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
20.4.2
“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.
+ DrAgent £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
+ CrCashin Hand £1000
Reverse Transaction Correction because actioned
+ Dr Transaction Correction a/c £1000
+ CrAgent £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 a/c
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
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
Version 0.4 Page 121/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POLIMPACTIDES/™*
* 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 alc
+ Dr Branch Rem Out £1000
* CrEDS Processed £1100
+ Dr Branch TC £100
20.4.3 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
+ DrAgent £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
+ DrCashin Hand £100
* Reverse Transaction Correction debtor on Agent
+ Dr Transaction Correction a/c £100
+ CrAgent £100 Agent no longer owes PO
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.
+ DrAgent £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 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
Version 0.4 Page 122/124
© Post Office™ 2003
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
* — Correct original error
+ Dr Gas Client £270 corrects future settlement
+ CrCash in Hand £270
+ Reverse Transaction Correction debtor on Agent
+ Dr Transaction Correction alc £270
+ CrAgent £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
* — 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/c by 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 Yantra.
+ — 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
Version 0.4 Page 123/124
© Post Office™ 2003,
POL00038885
POL00038885
Conceptual Design Project: Automated Ledgers
COMMERCIAL IN CONFIDENCE Doc Ref: POV/IMPACT/DES!**
+ — 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
e 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
e Branch accepts Pouch and scans in. (No Auto Rem)
e Branch enters quantity and value of product received in pouch
e 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
20.9Sale 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
= Marginonsale £20.16
« — Joe Public pays £645.16 recorded as increase in Cash in hand
= Effective Accounting on POL FS - sale of phone card
= 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
© Stock document reduces stock of $ in Branch
o Stock document identifies movement as sales and creates a finance document
= Debit Cost of Sales; $ £625
= Credit Stock GL a/c $625
Version 0.4 Page 124/124
© Post Office™ 2003,