Fujitsu Services
POL00038916
POL00038916
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Document Title:
Document Type:
Release
Abstract:
IMPACT Release 3 Design Proposal
Design Proposal
S80
This document is the Design Proposal for the Horizon aspects of
Release Three of IMPACT (was known as End-to-End Re-
architecting Release 2).
Document Status: Draft
Originator & Department: Gareth I Jenkins (Tel: I j - RASD
Contributors:
Approval Authorities
Tony Drahota
Manager RASD.
Fujitsu Services Post Office
Account
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1.
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services
IMPACT Release 3 Design Proposal Ref.:
COMMERCIAL IN CONFIDENCE Date:
Version:
POL00038916
POL00038916
EA/DPR/004
4.4
16/09/2004
Chapter 0 -
Document Control
0.1
0.2
DOCUMENT HISTORY
irst Draft issued for comment.
None
I 08/04/2004
I 29/04/2004
I 30/04/2004
16/09/2004
Second Draft issued for comment.
Third Draft issued for comment.
Baselined version
Changes to include feedback from HLDs and CRs
None
None
None
CP Cash_Decl
CP Rep_Clar
CP 3787;
CP 3797;
cP
POL_FS_AIS
CP 3813
REVIEW DETAILS
Review Comments by:
Review Comments to:
1 30/09/2004
Originator
“Phil Bo
RASD
Development Design
__Pete Jobson (*)
Phil Hemingway (*)
Martin Nixon
I Rex Dixon
Duncan MacDonald
Sudhanshu Agrawal
Peter Ashdown
ITU Janusz Holender
Customer Services Reg Barton
Post Office Ltd
RASD
Karen Hillsden
Dave-Rarnell
Optional Review/Issued for Information
“Allan Hodgkinson
Tony Drahota
Bob Gurney
Nial Finnegan
Development
Clive Williams
_Teny-Hayward
James Stinchcombe
Gienn Stephens
Dave Johns
Kevin Watson
I Alan D’Alvarez
Roy Birkinshaw
eryHeats
Chris Bailey
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Printed on 22/11/2002 2:20:00 by Gld
Page 2:
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
I Trevor Leahy
Roger Donato (*)
I Walter Wright
Mark Scardifield
Roger Barnes
_Simon Fawkes
Mark Ascott
“Andy Scott
I Miriam Bell
Karen Morley
Colin Mills
ITU Peter J Robinson
Neil Gormley
Eric Jennings (*)
Programmes Bill Reynolds
Customer Services "Mik Peach
Post Office Ltd Torstein Godeseth
(*) = Reviewers that returned comments
0.3 ASSOCIATED DOCUMENTS
Reference Doc Vers I Date Title Source
clon
{[CDBT} EA/CDE/002 ‘I 1.0 Branch Trading Reporting, Post
Management and Control and Office Ltd
Transaction Management /POA
Conceptual Design
[CDBTCR1] Changes to (CDBT]! POA
[CDIAGT ROA
RS
[CDPOLFS] BD/CDE/008 05 PO Ltd Financial Systems Post
Release 3 Conceptual Design Office Ltd
/ Prism
[CDPROG] AccCM-PCD 3.2 Accounting & Cash Post
CR/CDE/006 Management Programme- Office Ltd
Release 1 - Conceptual Design
(en C2076 Commercial Terms for impact I POA
Release 3 - Solution Build &
Test and Implementation
Stages (Branch Trading Horizon
Enhancements)
{CTRBAL] EA/HLD/O0S: impact Release 3 - Counter POA
Design for Balancing, Rollover
and Stock Processing
{CTRDEC] EA/HLD/006 impact Release 3 - Counter POA
Design for Deciaration,
Correction and Revaluation
(GFRHLOT impact R3 Counter HLO POA
[CTSAIS] EA/IFS/005 4.0 Horizon to POL Client POA
Transmission Summaries AIS
[DIAGBAL] EA/IFS/013 impact Release 3 - Balancing POA
and Trading Statement
Production User Interface
{DIAGDEC] EA/IFS/012 impact Release 3 - Declaration, I POA
Correction and Revaluation
User Interface
{DIAGREP] EA/IFS/011 impact Release 3 - Report POA
Production User interface
1 This isn't a stand-alone document but is Attachment £ to [CT].
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 3:
File: EADPROO4.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Reference I Doc Vers I Date Tie ‘Source
-ion
{[DRSHLD] NB/HLD/026 DRS Host Hi-D-Application and I POA
Workstation High Level Design
Delta for IMPACT Release 3
{ORSREP] CS/SPE/O14 Network Banking End To End POA
Reconciliation Reporting
[DWhHLD] DW/DES/088 Data Warehouse Outbound POA
Data File Delivery HLD
[E2EBRS] BD/BRD/O17 0.4 21/02/03 I Business Requirements - End Post
to End Re-Architecting Post Office Ltd
Office Product, Branch, Client,
Cash and Stock Processes &
Systems Feasibility Study
{EDSAIS} EAMFS/004 O-4 22/03/04 I CARO.—-Horizon-Accounts POA
Activated AIS
[HRSAPAIS]!” 1.5 HR SAP 4.68 Interface Prism
Documentation?
[HRSAPAIS1] I EA/HR/001 4.0 44/04/04. I Horizon To SAP Human. Prism
EAVIFS/015 Resources System - Pivot
Interface Specification
FHRSAPRAIS2} I EAVHR/GO4! 0.04 I 44/04/04 I Hi Fe eT my
Resources System—Pivet2
Interface Specification
{LFSHLD] LFS/DES/003_I 4.0 LFS Host HLD POA
{MENU} SD/SPE/016 32.0 Horizon OPS Menu Hierarchy POA
34.0
[MENUSUP} SD/ISPE/022 222: Horizon-OPS-Menu-Hierarchy: ROA
4 Changes Supplement—issue
222
[MiGow] EA/ALDI008 impact Release 3 - Migration POA
High Level Design
[MIGSTGY] SU/STR/007 07 IMPACT Programme S80 Post
Migration Strategy Office Ltd
[MISAIS] EA/IFS/006 1.0 Horizon to POL Data POA
Warehouse AIS
[POLFSAIS] EA/IFS/003 0.5 POL FS AIS Prism.
[POLFSMAP] I POL/E2E/ 1.0 Mapping of Horizon products to_I Post
DES/014 POL FS chart of accounts Office Ltd
EA/CDE/001 codes
{POLTIS] TVIFS/008 Horizon to Post Office Technical I POA
Interface Specification
[RDMCHLD] RD/DES/056 Reference Data End to End POA
High Level Design for S80
(impact, Track & Trace, +1
Sales)
[RDMOD] ROIDES/057 RDMC / RDDS High Level POA
Design for S80 Impact
Reference Data Model for S80
title may change)
[RDRV] RDP/TEC/951 I 2.34 I 12/01/04 I Reference Data Rules and Post
RD/CSD/002 Values Office Ltd
[RDSAIS]} RDP/AIS/014 64 05/07/02 I Application Interface Post
BF/IFS/010 Specification Reference Data to I Office Ltd
Pathway
2 We do not forme copy of this document. The relevant wformation is now all in [HRSAPAISL}, however I've
retained this reference for completeness
3 This defines the current interface from CBDB to HR SAP.
4 NB this is the current imerface. We have not received a version for the S80 changes yet. It is assumed to be a later version
of the same document
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 4.
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Reference Doc Vers I Date Title Source
-ion
[RDTPSAIS] RDIIFS/018 RDMC to TPS Application Data I POA
interface
[RIPCNT] TD/SPE/O10 Riposte 6 Message Server POA
Configuration for Counters
[RIPCS] TD/SPE/009 Riposte 6 Message Server POA
Configuration for
Correspondence Servers
[RIPDC] TD/SPE/011 Riposte 6 Message Server POA
Configuration for Riposte
“Clients”
[REPREC] SD/DES/005 Horizon OPS Reports & POA
Receipts.
{S15] Schedule 15 of the Contract - Post
Service Levels and Remedies Office Ltd
[SAPADSAIS] I PSOANDIE2E! I 49° SAP. ADS to POLFS: Prise
SGLIGIE
BP/DES/030 Specification
[SAPDP] EA/DPR/005 DP-for impact R3 SAP Hosting I POA
Design Proposal
[Sli SPRIMT/O07 I 1.0 Service Level Targets for Post
CS/SLA/002 Horizon Services Office Ltd
[TCAIS] EA/IFS/002 16 23/03/04 I POL Finance Systems to TMS / I Prism
Horizon Transactional
Corrections Interface
Specification
[TIPAIS] TWIFS/001 7.0 Pathway to TIP Application Post
Interface Specification Office Ltd
[TPSAGTHLD] I EA/HLD/O10 TPS Agent HLD POA
[TPSDWHAIS}] I OW/AFS/021 TPS Application Interface POA
Specification
[TPSMAP] AD/DES/047 ‘Agent to TPS Mapping Table POA
[TPSPOLFS] EA/HLD/007 impact Release 3-TPS-Delta POA
High-Level-_Desiga
TPS POL FS Summarisation
HLD
[TPSOTHER} EA/HLD/009 TPS HR SAP Summarisation & I POA
Transaction Corrections HLD
VOLS] PA/PERIO33_I 2.0 Horizon Capacity Management I POA
and Business Volumes
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 ABBREVIATIONS & DEFINITIONS
0.4.1 Abbreviations
Abbreviation I Definition
‘Acks ‘Acknowledgments
ADC Advanced Distribution Centre: Used as an abbreviation on the Horizon desktop for
Remittances to and from SAP ADS
Ais Application Interface Specification
APS Automated Payments Service. The subsystem that handles the acceptance of
automated payments on behalf of Post Office clients and passes details of those
payments directly to the clients.
ARL Additional Remedy Level
NB-Version-1.0-is-the-S60-interface-We-have-not-received-a-version for the S80-changes-yet—It-is-assumed-to-be-a-later
version-of-the-samerdocument
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5.
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Abbreviation
BIT Business Integration Test
BLOB Binary Large OBject (a mechanism used by both Riposte and Oracle to hold an
arbitrary piece of binary within the normal “database” structures)
Cii2 The version of the Banking or Debit Card confirmation message picked up by the
TPS harvester for summarisation to POL FS made available to the DRS system for
Reconciliation
c12 The version of the Banking or Debit Card confirmation message harvested in real-
time to the DRS system for Reconciliation.
CAP. Cash Account Period
CAPO Card Account for Post Office. The special Bank Account provided by Post Office for
Benefit Payments.
CAS Counter Application Scheduler
CBDB Counters Business DataBase. Post Office Limited’s current Accounting Systems
ccd. Contract Controlled Document
cD Conceptual Design
cP Change Proposal (A formal mechanism within Fujitsu Services Post Office Account
for controlling changes)
cR Change Request (A formal mechanism within Post Office Lid for controlling changes
and requesting changes to be made by Fujitsu Services)
cT Commercial Terms
cTS Client Transmission Summaries
CIT Counter Transaction Timings
DIT Direct Interface Test
DP Design Proposal
DRS Data Reconciliation Service. A system used to reconcile the on-line transactions
between the Financial Institutions and Horizon
OWh Data Warehouse
E2E End fo End testing where testing is carried out by POL of the full business processes
EDS The company which Post Office Ltd’s cheque processing is outsourced to
EOD End of Day
FAD. Financial Accounts Division (FAD Code)
FRTS First Rate Transaction Services (the Joint venture between Post Office Ltd and the
Bank of Ireland that handles Post Office’s Bureau de Change products)
FTMS File Transfer Management Service
HL High Level Design
HR SAP The SAP System used by Royal mail Group’s Human Resources to pay
sub-postmasters
ITU Integration and Testing Unit (within Fujitsu Services Post Office Account)
LOT Liquidated Damage Threshold
LFS Logistics Feeder Service
LPO Local Persistent Object
Mi Management Information
MIS Management Information System.
NB103 A Report produced from the DRS reconciling Banking and Debit Card Trasnactions
against the Cash Account Period they were carried out in.
NBE Network Banking Engine
NRDS New Reference Data System (a replacement from RDS)
OBCS Order Book Control Service
OLA Operational Level Agreement
‘ONCH Overnight Cash Holding
OPTIP. Operational TIP.
PIT Product introduction Test
PO Ltd Post Office Ltd
POA Post Office Account
POL Post Office Ltd
POL FS Post Office Ltd’s Financial System
RDDS Reference Data Distribution Service
ROMC Reference Data Management Centre
RDS. Reference Data System
Rem Remitance
RMG Royal Mail Group
S80 System Release 80. A Horizon Release.
SAP. An industry standard accounting system
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6:
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Abbreviation I Definition
SAP ADS SAP Advanced Distribution System
SLA Service Level Agreement
SLT Service Level Target
SU Stock Unit
Tce Transaction Correction
TIP Transactional Information Processing
TIS Technical Interface Specification
TS Transaction Management System
TPS Transaction Processing System
0.4.2 Definitions
The following terms, when capitalised as here, have specific meanings as indicated.
Term Definition
Account An account within POL FS into which Transactions or Summaries are
posted.
The mapping of Horizon Products and the modes in which they are
transacted onto POL FS accounts will be defined in Reference Data.
Agent A component of the Horizon architecture which links Host Systems to
Riposte
Note that it is used in other documents to refer to a person working in a
Branch, however in this document it is purely used to refer to the Horizon
System component
AP Clients. Post Office Ltd’s Clients for the Automated Payment Service
Article Aterm used in SAP to represent a Product
Article Mode ‘A concept in the mapping of products and Modes to Articles
Balancing The process by which a clerk ensures that all the cash and stock for
which they are responsible is correct.
Branch The term used for any Post Office wither operated directly by POL or on
their behalf by a sub-postmaster. In the past the term Outlet was used
(but I hope I’ve avoided it in this document!)
Branch Manager The person responsible for the operation of a Post Office Branch
Branch Trading Statement I A report providing a summary of what has happened within a Branch
during a Trading Period
Card Account The special Bank Account provided by Post Office for Benefit Payments.
‘Cash Account The mechanism by which a Postmaster currently reports their liability to
POL
Cash Centre ‘A place where cash is prepared to delivery for Branches (and non-POL
destinations) and to which cash is retumed. Their cash is managed
through SAP ADS.
Clerk A person working in a Branch who uses Horizon
Counter The terminal used by a clerk when interacting with Horizon. Note that
there are also "back office” counters in some larger branches which are
purely for administrative functions.
Data Centre The Central Systems run by Fujitsu Services in their Data Centres of
Bootle and Wigan.
Data Warehouse ‘A System used to hold data for long term analysis
Desktop The software that provides the interface to Horizon for a Clerk
E-Pay ‘A company which acts as an agent for Electronic Top ups on behaif of all
the mobile phone operators.
End of Day End of Day is defined as taking place 30 mins after the scheduled closing
time (in Reference Data) for a Branch or 19:00 whichever is earlier.
Horizon has a mechanism whereby background processes can be
triggered to operate in the Branch at the End of Day time, for example to
trigger the harvesting of that day's transactions.
Error Notice Amanual mechanism by which the Central Post Office Ltd accounting
functions can request corrections are made to branch accounts following
various errors. This is to be replaced by Transaction Corrections.
FAD Code Unique identifier for a Branch
Financial Institution ‘An independent organisation providing Financial services (usually
Banking or Debit Card)
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 7:
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Term Definition
Harvester A software Agent that transfers data from Riposte to a Host System
Horizon That part of Post Office Ltd’s System developed and operated by Fujitsu
Services
Host ‘A component of the Horizon architecture that supports databases and
database processing
Huthwaite The location of Post Office Ltd’s Data Centre
impact The programme within Post Office Ltd which is making change to Improve
the accounting processes.
Loader A software Agent that transfers data from a Host System to Riposte
Logon The mechanism by with a user connects to the counter and identifies
themselves.
Maestro The Job Scheduling software used within Horizon
Mails The SmartPost application used to aid clerks in calculating the postage
required for any item and printing labels for affixing to the items
Messagestore The storage mechanism used by Riposte
Mode Identifies the business functions under which a counter transaction is
being carried out.
‘Outlet No longer used. This term has now been replaced by Branch.
Persistent Object A technique used within Riposte for holding data indefinitely rather than
transiently
Postmaster The person responsible for a Branch. (Used interchangeably with Branch
Manager.)
Prism The organisation who supply and operate Post Office Ltd’s back-end
systems
Prism Alliance The organisation that is responsible for the development, operation and
support of Royal Mail Group's central systems including those of Post
Office Ltd.
Product ‘Something that is transacted at a counter. Products may be Stock
products or Service products.
Quantum ‘A Smart Card used to top up Gas meters.
Reference Data A mechanism by which parameter values are held outside code in such a
way that they can be easily updated through defined processes
Remittance The receipt or despatch of some item of Stock in a Branch
Replenishment Delivery An electronic flow indicating the amount of cash to be delivered to a
Branch
Riposte A product from Escher Group Ltd that provides a messaging middieware
for communication between Branches and the Horizon Data Centre
Rollover The means by which a Stock Unit moves from one Trading (or Balance)
Period to another
Settlement Product ‘A Product whose prime purpose is to enable EPOSS to balance a
customer session. Its use is primarily in those Modes where there is no
clear settlement, such as Transfers and remittances.
Soft Launch A mechanism that allows functionality to be activated independently of
Software installation at Branches
Stock Unit Ameans of accounting within a Branch
Streamline ‘A company which acts as a Merchant Acquirer processing Debit card
Transactions on behalf of other Financial Institutions.
Sub-File That part of a file of data that holds the data associated with a single
Branch’s trading on a single Trading Date
Summarisation This is the process of taking the information from a set of transactions and
producing a summary total of the overalll net effect of such transactions.
For Release 1, this summarisation will be simply to add up the Sale Value
of all relevant Transactions with due regard to the arithmetic sign.
Supervisor ‘A role within a Branch with special privileges
‘Suspense Account ‘A means by which cash discrepancies can be accounted for with a branch
outside of any Stock Unit.
Tertiary Mapping ‘A new form of mapping used for Stock products to enable them to appear
correctly on the various counter reports.
Tivoli The Systems Management Software used within Horizon,
Trading Day The accounting day within a Branch. It is defined to end 30 minutes after
the scheduled Branch closing time or 19:00 whichever is earlier.
Any transactions that take place after the end of the Trading Day are
considered to be part of the following Trading Day.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 8.
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Term Definition
Transaction This represents an EPOSS Transaction written to the Riposte message
store.
The sum of the sale values of all Transactions within a Customer Session
will always be zero thus enabling normal double entry book-keeping to be
carried out.
Transaction Correction An automated mechanism by which the Central Post Office Ltd
accounting functions can request corrections are made to branch
accounts following various errors. This replaces Error Notices.
Watercard A Smart Card used to top up Water meters.
0.5 CHANGES IN THIS VERSION
0.5.1 Changes in Version 1.1
Dhisnis-called-bole-to-cll oie i Lestee-will-bebele
This supersedes various informal issues 1.4a through to 1.16.
Changes from version 1.0 to version 1.1a are marked in red (like this) with significant
deletions in red-strikeout-(like-this}. Changes from Version 1.1a are in violet (like
this). Changes from Version 1.1b are in brown (like this).
Note that in some places where a section has had major changes I’ve not preserved
the original text to make the new description more readable. Such sections are clearly
marked.
I have attempted to maintain the sub-section numbers within sections 2.5, Chapter 3
and Chapter 4 to aid traceability from other documents. This may result in some
sections being empty. New sub-sections are added at the end of their parent section to
aid this even if this is not necessarily the most logical place. Note that section 2.6 has
been restructured and in particular the subsections of 2.6.3 have all changed. Note
that Figure numbers and Table numbers may well have changed.
Changes are primarily:
= The breakdown of work between the various HLDs has now been included in
section 1.5
m= The excluded interfaces (SAP ADS Transaction Data and CAPO remuneration
data) have been removed from the DP to avoid confusion as to their status
® Migration Terminology has been aligned with that defined in [MIGSTGY].
= Alignment with the lower level documents, ie User Interface Design Proposals,
HLDs and AISs, which are now available. In some cases this has resulted in text
being removed from the DP to avoid duplication.
= Section on LFS Harvester included since it has now been decided to cut-off the
Weekly Stock data in the LFS Harvester to simplify migration
= Details of Post Office Ltd Change Requests and Fujitsu Change Proposals
included as section 8.5
= Some of the more detailed discussion sections have either been removed (if the
subject is now covered in a lower level document) or moved to an appendix within
Chapter 9 (if the discussion may be relevant for future CRs).
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9:
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
0.5.2 Changes in Version 1.0
Changes from version 0.3b to 1.0 are marked in green (like this).
0.5.3 Changes in Version 0.3
This is called 0.3c to allow for informal circulation. The formal issue will be 0.3
This supersedes various informal issues 0.3a through to 0.3b.
Version 0.3b has been put into PVCS as version 0.3 without further change.
Changes from version 0.2 to version 0.3a are marked in red (like this) with significant
deletions in red-strikeout-(like-this). Changes from 0.3a to 0.3b are in violet (like
this).
Note that in some places where a section has had major changes I’ve not preserved
the original text to make the new description more readable. Such sections are clearly
marked.
Changes are primarily:
a The expansion of sections which were previously TBS
= Resolution of issues highlighted in version 0.2
= Alignment with the design that was costed for the CT.
Version 0.3 is being sent on a limited circulation and it is expected that it will be
updated to version 1.0 for baselining shortly.
0.5.4 Changes in Version 0.2
[ this supersedes various informal issues 0.2a through to 0.2d.
Changes from version 0.1 to version 0.2a are marked in red (like this) with significant
deletions in red-strikeout-ikethis). Changes from 0.2a to 0.2b are in violet (like
this). Changes from version 0.2b to 0.2c are marked in green (like this). Changes
from version 0.2c to 0.2d are marked in brown (like this). Changes from version 0.2d
are marked in dark teal (like this).
Note that in some places where a section has had major changes I’ve not preserved
the original text to make the new description more readable. Such sections are clearly
marked.
Since most of the document has changed significantly, no attempt has been made to
summarise the areas of change here.
0.5.5 Changes in Version 0.1
This-is called-0-1d-to-allow forinformale The formalissue-will-beQ4
This supersedes various informal issues 0.1a through to 0. 1c.
None. This is the first version.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: _ 16/09/2004
0.6 CHANGES EXPECTED
0.6.1 Outstanding Design Issues
A number of areas of in the document require clarification. These are marked in
yellow;
highlight in this working draft (as indicated):
= Yellow highlight indicates further investigation required within Fujitsu Services
or significant bits of text to be produced
x ise-hichlioht-indicates-that- {CDBE ds-te-t Jated-to-reflect-what-
2 5 s t T P i
&
¢
stated
= Green Highlight indicates a clarification of requirements is needed from Post
Office Limited.
Wherever possible a working assumption is recorded.
r
There are also a number of minor comments that require resolving that are made in a distinctive
style like this.
ve split such outstanding issues into three lists:
a Issues to be resolved by Post Office Ltd
o Kems-that-require-clarification
8
Jremas-where-the-CD. 4s-updatine-to-reflect-asreed.
Sup
a Issues to be resolved within Fujitsu Services
= Issues in previous versions of this DP which are now resolved (noting their
resolution). Such issues will be removed in the next issue of this DP.
What do we do about Training Decide and then raise a
Mode?
{recommend killing it.
234 How do TCs work with Stock / Clarify requirement and KH7CR
NAD / Mode SO perhaps update AIS
2.5.1.1.2.4 I How do we capture Euro Stamp I Ensure that this is KH
change? managed through OBC.
2.5.1.1.2.4 I Confirm that none of these KH/PG
exceptional products need to be
re-valued.
Related to this, I suspect that
POL FS can't handle any such
products so do we need to
prohibit them
25.1.1.2.4 I What do we do with Postal CR Needed? KH
Orders and their fees?
25.14.14 I Emergency Suspense Are there any new KH
requirements coming out
of this?
CR Needed?
25.1.2.1 I Confirmthatitis OKto always I If this is not the case, then I KH/BG
follow the Cash Declaration raise a CR
detailed dialogues
25.14.14 I Future of Parcel Traffic CR needed? KH
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.4.1.2 I Confirm that the described BG
mechanism is OK
25.1.8 Are the simple MiMAN changes KH
described adequate?
25.24 Product ids for new Events Andy
Corbett
25.2.7 AIS Changes needed to handle NS
negative numbers
25.2.10 I Confirmno problem with KH NS
negative input
2.5.2.44 How to we interface to FRTS? CA/PG
263.12 I Isa POL FS Pilot required and if KH7PG
so what is the scope and
purpose?
26.3.2.1 I Do some of these Suspense KH
9.3 account changes need to move
toa later point?
Table 1 — Outstanding Issues on Post Office Ltd
Table.2Issues-requiring-updates to {CDBT]
15.3 Define where “Reversal Control” GI / PJ
is to be covered in UIDP / HLD.
15.3 Define where “Protection against GH/PJ
Data Loss” is to be covered in
HUD.
1.6.1.4 What do we do about Training Gi
Made?
L recommend killing it
2.3 Add section on Reconciliation Gis
2.5.4.1.1.4 I Sort this out with Karen Morley Gis
2.5.1.1.2.4 I Need to include migration Gis
implications
25.145 _I Needs tidying Gu
25.1.1.5 I Need to ensure picked up by Gi
APS
25.44.27 What are UI implications? Gil
2.5.1.2.1.2 I Which way do the signs go? Gu
2.5.1.3.7.1_I How do we handle zeros? Gis
2.5.1.3.8 What are the rules for deciding Dev
what can be reprinted?
2.5.4.4.2 How do we remember the Dev
Suspense summary?
2.5.1.4.2 What if a SU rolls early?. How Dev
do we reprint BTS then?
25.4.5.3 Align with HUD GiJ / MN
25.155 Move to 2.3 Gis
2.5.4.6.3 Are Roles configurable Gis
2.5.4.7.4 Implications for isolated nodes? Gid
25.4.7.4 Are the signs correct? Gis
2.5.4.7.2 Need HLD to be updated. MN
25.1.8 How do we handle CAP / TP GiJ/ PH
decision for MIMAN
2.5.2.1 Is there an impact on RDT? DMcD
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.2.12 I Need to extend AIS to allow us to I Draft AIS changes G7 PA
reject records that fail Ref Data__I These are currently in
validation [TPSOTHER]
26.1.6 Remove? Gi
26.2 Complete deiails of FTMS GN
changes
26.3 Son of MIMAN Gis
2.6.3.1.3 I How do we suppress alerts on Gi
missing TC files?
Do we actually raise them?
26.3.2.5 How do we handle multiple GiJd / MN
conflicting soft launches?
3.4.3 This detail needs to move to GiJd / MN
{[CTRBAL]
Table 3 — Outstanding Issues on Fujitsu Services POA
The following table is here to provide an a
various intermediate versions of this DP. It will be removed at the next issue.
dit of issues resolved since version 1.0 and the
[Section I tssue Action Date”
0.4 Complete list of CPs and CRs Bis Closed
0.3 Ref and title needed for various Need feedback from Dev Dev Closed
docs Unlikely to be available for
a while.
1.5.3 ls 2°¢ half of table needed? No Gi Closed
2.5.1.3.1 Pete has a simpler solution Need to discuss this with Gis Closed
POL to see if acceptable
Need to add SAPADS to MIS Ignore for now since out of I TH N/A
Interface into [MISAIS] scope Closed
25.2.8.2 How does this work for a New No. KH Closed
Branch?
2.5.2.14 Change to remove mini-cash Gis Closed
account reconciliation at Point
40.
26.3.1.2 Add Requirement Ref There isn’t one. Gib Closed
26.3.2 What is “son of MiMAN"? KH Closed
2.6.3.2.5 How do we handle “multiple First one. Ke Closed
triggers"?
325 AIS needed (EDS) Fujitsu is authoring this. TH NA
Ignore for now since out of Closed
scope.
42 Need to confirm approach Clarification from Dev GH NA
(Mark Ascott) Closed
This may go away!
Assume that it will.
5.5.1.3 Should this be OLA rather than BR Closed
SLA?
5.5.1.5 Should this be OLA rather than BR Closed
SLA?
85 Complete Gis Closed
Table 4 —-Resolved Issues
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Printed on 22/11/2002 2:20:00 by Gld
Page 12
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
0.7 CONTENTS
0.7.1 Table of Contents
CHAPTER 0 - DOCUMENT CONTROL...
01 DOCUMENT HIStory ....
0.2 REVIEW DETAILS .....s.seseee
0.3 ASSOCIATED DOCUMENTS ...
04 ABBREVIATIONS & DEFINITIONS.
0.4.1 Abbreviations
0.4.2. Definitions...
0.5 CHANGES IN THIS VERSION .....ccssssssesesssseeeees
0.5.2. Changes in Version 1.0.....
0.5.3 Changes in Version 0.3.....
0.5.4 Changes in Version 0.2 ......04.
0.5.5 Changes in Version 0.1.....
0.6 CHANGES EXPECTED.
0.6.1 Outstanding Design Issues...
0.7 CONTENTS
0.7.2. Table of Figures...
0.7.3 Table of Tables...
CHAPTER 1 - INTRODUCTION...
11 PRIVACY AND CONFIDENTIALITY .......ccscscssesssssssssssseesecescossesssnesseesecsonsssssnammaseessesssesssnes2 I
LILI Accuracy
11.2 Copyright osssseuseesnnansenese
12 SCOPE OF THE DOCUMENT ........0000
1.2.2. Timescales and Phasing...
1.2.3 Potential for Change.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
1.2.4 Requirements Out of Scope.
13 REQUIREMENTS OVERVIEW .......
14 DOCUMENT SUMMARY...
1S OTHER AFFECTED DOCUMENTS...
15.1 Counter High Level Design ..
1.5.2. User Interface Design Proposals
1.5.3 Counter Index Chec
1.5.4 TPS Host High Level Design .
1.5.5 Host Index Check.
1.6 DEPENDENCIES ON Post OFFICE LTD .
1.6.1 Exceptions...
1.6.1.1 Training
CHAPTER 2 - SOLUTION OUTLINE DESIGN...
2.1 GENERAL ...
OVERVIEW OF IMPACT RELEASE 3 COMPONENTS.
2.2.1 Breakdown of Horizon Systems..
2.2.2 Breakdown of Branch Systems...
2.2.3. Breakdown of TMS.
2.2.4 Breakdown of Transaction Storage...
23 MAJOR NEW END TO END CONCEPTS
2.3.1 Transaction Corrections...
24 UNCHANGED PROCESSES
2.5 CHANGED COMPONENTS ..
2.5.1 Counter Components
2.5.1.1 Branch Transactions ...
Changes to Cash / Stock declarations and handling of variances.
Reporting..........
Balancing and Rollover.........
EOD...
Logon Checks
Process Transaction Correction........
MiMAN..
75
2.5.2 Host Components...
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1£
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
RDMC..
LFS..
Process SAP ADS Transactions.
TPS Harvesting
DRS Host
APS Host.
Generate MIS Info.
Transaction Summari
Accept CAPO Data ..
2.5.2.10 Generate HR SAP Info
1 Generate POL FS Info
2 Transaction Correction
5.2.13 POA Data Warehouse .
.14 TPS Host
2.6 MIGRATION CONSIDERATIONS ...
vn
2.6.1 Migration Overview.
2.6.1.1 Data Centre Migration...
2.6.1.2 Counter Software Upgrade
2.6.1.3 Switch to new POL FS Interface...
2.6.1.4 Running the Final Counter Cash Account for CBDB...
2.6.1.5 Switch of TMS feed of Transactions from OPTIP to MIS
2.6.1.6 Delayed Counter Software Upgrade...
2.6.1.7 Upgrade of Counter processes to operate Branch Trading Statement ...
94
2.6.2 Mapping of Changes to Migration Points...
2.6.3 Specific Migration Developments
2.6.3.1 Data Centre Changes......
2.6.3.2 Counter Changes ..
CHAPTER 3 - DATA MODEL ..
3.1 GENERAL ..
3.2 EXTERNAL INTERFACES
105
3.2.1 Reference Data......
3.2.2 Transaction Corrections...
3.2.3. SAP ADS Transactions and Summaries
3.2.4 Ledger Entry Information ....
3.2.5 TMS Info from Clients...
3.2.6 Remuneration Information...
3.2.7 Management Info...
3.2.8 CTS Files
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
3.3 INTERNAL INTERFACES ....
3.3.1 Branch to TMS: Transactions.
3.3.2. TMS to Branch: Transaction Corrections......
3.3.3. Within Branch: Transactions...
3.4 DATA STORES...
3.4.3 Stock Unit Summary for Branch Trading Report.
108
3.5 REFERENCE DATA CHANGES......
CHAPTER 4 - ENVIRONMENTAL CONSTRAINTS...
41 GENERAL ....
4.2 TECHNICAL INTERFACE FROM SAP ADS oe :
43 TECHNICAL INTERFACE FROM NRDS.....
44 TECHNICAL INTERFACES TO AND FROM POL FS......
45 TECHNICAL INTERFACE FROM EDS.
4.6 TECHNICAL INTERFACE TO HR SAP ...
47 TECHNICAL INTERFACE TO MIS......
48 TECHNICAL INTERFACE TO CTS.....
CHAPTER 5 - NON-FUNCTIONAL REQUIREMENTS ..
5.1 GENERAL ....
5.2 AVAILABILITY...
5.21 Resilience......
5.3 USABILITY
54 VOLUMETRICS.......
5.5 SERVICE LEVEL OBJECTIVES.
S51 SLA Chan ges.essescescree
LFS..
TMS - POL-F:
Transaction Correction ,
TMS ~ MIS (SAP ADS data)
TMS — MIS (Horizon data)..
TMS — HR SAP.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 17
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
5.5.1.7 TMS (CTS file)
5.5.1.8 TMS (RTS file’
5.5.2 SLAs to be removed...
5.5.3 Unchanged SL:
5.5.4 Migration Implications .....
5.6 SECURITY.
CHAPTER 6 - TESTING AND ACCEPTANCE...
61 GENERAL ..
6.2 PRODUCT
STING
6.2.1 Test Stages
6.2.2 Test Environments...
63 ASPECTS TO BE TESTED...
6.3.1 Business functionality
6.3.2 Performance....
6.3.3 Volume......
6.3.4 Integrity...
6.3.5 Resilience...
6.3.6 Recoverability (including backup and recovery, including disaster recovery)
6.3.7 Networking...
6.3.8 Security
6.3.9 Supportability.
6.3.10 Manageability (system management).
6.3.11 Migration...
64 ACCEPTANCE ......
6.4.1 Live Pilot...
6.4.2 Capacity Modelling...
CHAPTER 7 - MAPPING OF PROCESSES TO COMPO
7A GENERAL ....
72 MAIN BUSINESS PROCESSES.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
CHAPTER 8 - COMPLIANCE MATRICEG......
8.1 GENERAL...
8.2 COMPLIANCE MATRIX...
8.3 ADDITIONAL REQUIREMENT ...
84 OTHER ASSUMPTIONS .......
8.5 CHANGE REQUESTS.
CHAPTER 9 - RETAINED INFORMATION
1 GENERAL wesc
9.2 NON-VALUE STOCK ANALYSIS...
9.2.1 Travel Schemes and Local Authority VouchePs ........00+0000000
9.2.2 MVL Disks ...
9.2.3 Other Tokens.
9.2.4 NRA Rods.....
9.2.5 N. Lott. Chqs....
93 CURRENT SUSPENSE PRODUCTS.
0.7.2 Table of Figures
Figure I — IMPACT Release 3 Components
Figure 2 — Horizon Systems
Figure 3 — Branch Systems......
Figure 4— TMS .
Figure 5 — Transaction Storage
Figure 6 — Migration Timeline.
Figure 7 — Ref Data Model for Articles
0.7.3 Table of Tables
Table I — Outstanding Issues on Post Office Ltd.
Fable 2—Issue: dates-te 1} CDBE
Suwlys quiring updates te {CI
Table 3 — Outstanding Issues on Fujitsu Services POA.
Table 4 Resolved Issues.
Table 5 ~ Out of Scope Processes.
Table 6 — Document Structure ....
Table 7 — Contents of [CTRBAL] ..
Table 8 — Contents of [ICTRDEC
Table 9 - Contents of [DIAGREP]
Table 10 - Contents of [DIAGDEC]} .
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Table 11 — Contents of [DIAGBAL}....
Table 12 ~ Counter Index Check...
Table 13 ~ Contents of [TPSPOLFS]
Table 14 ~ Contents of ITPSOTHER I ..
Table 15 — Host Index Check .....
Table 16 — External Interfaces...
Table 17 — Unchanged Processes.
Table 18 — Riposte Configuration Changes ..
Table 19 — Expiry Value Analysis...
Table 20 — Current Settlement Products
Table 21 ~ Method of Payment Products...
Table 22 — Stock Products currently adjusted by Value...
Table 23 — Reports affected by Stock Changes.
Table 24 — Reports that can be reprinted ......
Table 25 — Reports to be removed ..
Table 26 — Current Weekly Reports
Table 27 — Additional EPOSS Events to be harvested...
Table 28 — POL FS File Delivery Information
Table 29 — POL FS File Receipt Information
Table 30 ~ CTS File Receipt Information.
Table 31 — FRTS File Receipt Information
Table 32 — HR SAP File Delivery Information
Table 33 — Transaction Correction Metric
Table 34 — Migration of Functions ...........
Table 35 — Migration of SLAs...
Table 36 — Mapping of Business Processes to DP Section
Table 37 — Acceptance Mechanisms.
Table 38 — Compliance Matrix ..
Table 39 — Additional Requirements Compliance Matrix .
Table 40 — Assumptions... sees
Table 41 ~ Soft Change Requests...
Table 42 — Hard Change Requests for $80
Table 43 — Hard Change Requests for $90
Table 44 — Categories of Non-Value Stock
Table 45 — Current Suspense Products .....
62
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 2C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 1 -
Introduction
1.1 PRIVACY AND CONFIDENTIALITY
1.1.1 Accuracy
Fujitsu Services endeavours to ensure that the information contained in this document
is correct but, whilst every effort is made to ensure the accuracy of such information,
it accepts no liability for any loss (however caused) sustained as a result of any error
or omission in the same.
1.1.2 Copyright
© 2004 Fujitsu Services. All rights reserved. No part of this document may be
reproduced, stored or transmitted in any form without the prior written permission of
Fujitsu Services.
1.2 SCOPE OF THE DOCUMENT
1.2.1 Scope
[CDPROG] identified a number of areas for the business proposition of the Impact
programme of which only some will be achieved by the completion of this project.
The business proposition section of [CDPROG] is copied below.
a Interface of data to RMG financial systems (including for data passed to HR SAP)
= Management of PO Ltd Bank Accounts (though this is not a “front end” issue and
so is not covered here)
= Capture, Validation, Verification and Correction of client transaction data from
any channel where applicable
= Provision of validated client transaction data to internal and external recipients
(though some of this is done via POL FS and MI)
= Responding to client/branch enquiries concerning transaction data (Enquiries to
allow response)
= Accounting at branches
= Branch control
= Recovering debt from branches, clients etc (inc non-transaction) debt
This Design Proposal documents the solution design for the Fujitsu Services
components of Impact Release 3
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 21
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
The Design Proposal has been produced in parallel with the Conceptual Design. The
Conceptual Design (ie requirements) for the overall Impact Programme is defined in
[CDPROG]. The detailed requirements for the projects that make up Release 3 are
described in two separate Conceptual Design documents [CDBT] covering the Branch
perspective and [CDPOLFS] covering the Central perspective.
This Design Proposal is only addressing those requirements defined in [CDBT]. Any
requirements on Fujitsu associated with the Hosting of POL FS (covered in
[CDPOLFS)]) will be covered in a separate Design Proposal [SAPDP].
Any requirements on Fujitsu Services that are not fully met by this Design Proposal
are listed in section 1.6.1.
If the Fujitsu Services Commercial Terms for the Solution Build and Test and
Implementation Phases is accepted by Post Office Ltd then the solution delivered by
Fujitsu Services will be based on the outline design defined in this Design Proposal.
1.2.2 Timescales and Phasing
The design contained in this Design Proposal does not link Impact Release 3 to a
particular Horizon release. The release will be determined by the Joint Demand
Planning Forum.
However the expectation is that it will be included in S80.
1.2.3 Potential for Change
There are no specific requirements to allow for future change, however the use of
Reference Data where possible provides a good basis for minimising the
developments required in future to accommodate changes.
It is understood that the data feed to HR SAP (see section 3.2.6) is likely to be
simplified in the future and although that change is out of scope, the design should
take this into account.
1.2.4 Requirements Out of Scope
A number of the Business Processes described in [CDBT] are outside the scope of this
DP. These are listed in Table 5:
Perform Transaction Checks ~ Periodic__I This will be handled by the Post Office MIS system
Summarise Cash Centre Transactions This will be handled by SAP ADS as at present
Table 5 — Out of Scope Processes
In addition Section 21 (Appendix C) of [CDBT] identifies a number of changes based
on Schedule 12 savings. These are considered to be outside the scope of this DP.
1.3 REQUIREMENTS OVERVIEW
The detailed requirements for Release 3 are described in [CDBT].
A number of further requirements were identified following the baselining of
[CDBT], which have been included in [CT] as Attachment 1.
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 22
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
A number of further Change Requests have bene raised by Post Office Ltd and these
are listed in section 8.5.
Some requirements are also defined in [CDPROG], however since these are not
currently aligned with those in [CDBT], they have been ignored in this Design
Proposal.
Chapter 8 provides a formal compliance statement against each requirement in
[CDBT] (section 8.2) and Attachment I of [CT] (section 8.3) with references to where
the way in which the requirement is to be met is described in this document.
A number of assumptions were made at the time [CT] was approved and these are
formally described in Attachments 2 and 3 of [CT]. Section 8.4 is equivalent to
Attachment 2 of [CT] and Section 5.5 reflects the proposal made in Attachment 3 of
[CT].
1.4 DOCUMENT SUMMARY
{CDBT] split the changes required by Impact Release 3 as far as Horizon is concerned
into a number of areas:
This dee
deseribes:
= Verification
+-deseribes_th sed-_desien for “+ Release 3]; rtiewlarit
‘PROP P aa Pi
a Other Data Capture
a Produce Reports
= Daily Trading
= Produce Branch Accounts
= Stock Control
= Discrepancy Management
= Transaction Management
This document describes the changes that are required to Horizon to meet these
requirements. It is split into a number of chapters:
s is the bulk of the document an
describes all the new and changed
functions that are required
Solution Outline Design
Chapter 3 = This describes new and changed
Data Model interfaces and major data changes
Chapter 4 - This describes the technical aspects
Environmental Constraints of the various interfaces
Chapter 5 - This describes all the non-functional
Non-Functional Requirements requirements including any Service
Level targets
Chapter 6 = This describes requirements on
Testing and Acceptance Testing
Chapter 7 = This provides a mapping from the
Mapping of Processes to
Components
Business functions described in
[CDBT] to the functional changes
described in Chapter 2
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPROO4.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by Gld
Page 2¢
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Title Comment
- This is an appendix that formally
Compliance Matrices describes the compliance to the
requirements specified in [CDBT]
and subsequent Change Requests.
Table 6 — Document Structure
1.5 OTHER AFFECTED DOCUMENTS
A number of High Level Design and interface documents are being produced and
some existing documents are being updated from this Design Proposal:
s_{CTRHLD] -which-covers-all-aspects-of the-counter-changes-and- ral-overview
= [CTRBAL] and [CTRDEC] which covers the counter changes. The split between
these documents is described in section 1.5.1.
= [TPSPOLFS] and [TPSOTHER] which cover those aspects to be included in the
TPS Host. The split between these documents is described in section 1.5.4.
= [TPSDWHAIS] which covers the changes to the interface between the TPS Host
and the POA Data Warehouse
= [RDMCHLD] which covers those aspects to be included in the Reference Data
Management Host
= [RDMOD] which defines the changes to the Reference Data Model for S80
a [RDTPSAIS] which defines the interface between RDMC / RDDS and the TPS
Host
= [LFSHLD] which covers those aspects to be included in the LFS Host (minor
changes only)
= [DRSHLD] which covers those aspects to be included in the DRS Host
= [DWhHLD] which covers those aspects to be included in the POA Data
Warehouse
a [TPSAGTHLD] which covers those aspects to be included in the TPS Agent
= [TPSMAP] which covers the mappings between the TPS Harvester and TPS Host
interface tables.
= =[MIGOVW] which provides an overview of all the migration aspects
In addition, the detailed interaction between the clerk and the system will be described
in [€DIAG}-[DIAGBAL], [DIAGDEC] and [DIAGREP]. The split between these
documents is described in section 1.5.2.
The following CCDs will need to be updated as a result of the changes described in
this Design Proposal:
mu [REPREC] to define the new receipt layouts
= [VOLS] to include information on the volumes associated with the new data flows
= [MENU] to update the Menu hierarchy. Fhe-che s-to-thi described +:
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 24
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
Fujitsu Services
POL00038916
POL00038916
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
m [DRSREP] to remove the NB103 report
a [TIPAIS] can be withdrawn
1.5.1 Counter High Level Design
The High Level Design for the counter has been split between two High Level Design
Documents the following tables define which parts of this DP are covered by which
HLD.
25.4.1 Branch Transactions
25.132 Office Snapshot Report
2.5.1.3.3 Suspense Account Report
25.137 Other reports affected by changes
to Stock Processing
2513.8 Reprints of Reports
2513.10 I Weekly Reports
25.4.4 Balancing & Rollover
26.1.4 Running the Final Counter Cash Softlaunch menu changes to
Account for CBDB- suspense/housekeeping
2617 Upgrade of Counter processes to_I As part of the final Cash Account rollover
operate Branch Trading Statement_I process
2.6.3.2.1 Process the final cash account for Softlaunch menu changes to
CBDB (Branch suspense/housekeeping
26.3.2.2 Upgrade of Counter processes to
operate Branch Trading Statement
2.6.3.2.3 Merging of Non-Value and Value Assumed that there is no change in this
Stock area
26.324 Support of ARDS supported ‘Assumed that there is no change in this
Settlement Products area
2.6.3.2.5 Support for Quiescent Rollover
3.4.3 Stock Unit Summary for Branch
Trading Report
Table 7 — Conten
ts of [CTRBAL]
Section’
Deseription
Changes to Cash / Stock
declarations and handling of
variances
2.5.1.3.4 Remuneration Reporting
25.1.3.4 Counter Weekly Redeemed
Savings Stamps Report
2.5.4.3.5 APS Transactions Report
2513.9 Reports to be removed
25.4.5 £00
25.16 Logon Checks
25.17 Process Transaction Corrections
3.4.2 Variance Persistent Objects
Table 8 — Contents of [CTRDEC]
1.5.2 User Interface Design Proposals
The detailed interaction between the clerk and the system will be described in three
separate documents: [DIAGBAL], [DIAGDEC] and [DIAGREP].
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 2£
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Each of the three documents covers a distinct set of requirements that are documented
in the high-level process models within [CDBT]. These high-level process models
listed in full in section 7.2. The scope of each document is described in the following
tables.
ection
2.5.1.3.10 I Weekly Reports Produce Periodic I Changes to the production of the office
Summaries summary reports (with cut-offs). New
reports, removed reports and changes to
report selection criteria.
2.5.4.3.1 I Remuneration Produce Sales New functionality around the entry and
Reporting Report to Assist validation of reporting criteria
Remuneration
Check
25135 I APS Transactions I Produce Other Changes to report layouts as a result of
Report Horizon Reports changes to the management of Stock and
25.41.3.7 I Other reports changes associated with the menu
affected by changes hierarchy in regard to additional and
to Stock Processing removed reports.
2513.9 I Reports proposed to
be removed
2.5.1.3.2. I Office Snapshot Review Stock Heid I Changes incurred to the Office Snapshot
Report Across Branch Report
2.5.1.3.8 I Reprints of Reports
2.5.1.3.3 I Suspense Account
Report
2.5.1.3.4 I Counter Weekly
Redeemed Savings
Stamps Report
2.5.4.3.6. I Event Log
Tabie 9 — Contents of [DIAGREP]
nt
25.163 I Outstanding Receive Automated I Changes to the Logon process related to
Transaction Message the presence of outstanding Transaction
Corrections Corrections.
25.4.7 Process Transaction I Handle Transaction I Selection and processing of Transaction
Correction Corrections Corrections, including the reporting of
them.
2.5.4.24 Changes to Cash Compare Cash Declarations and Cash Variance
Declarations Generated with identification for both individual and
Actual Cash Held Shared Stock Units.
for Stock Unit
25.122 I Reporting ofCash I Create Variance I Menu, Dialogue and Report format for the
Variances Report ... Compare I Cash Variance Report.
Generated with
Actual Cash Held
Across Branch
25.1.2.3 Processing of Cash I Make Good, Hold Menu items and dialogues associated with
Variances or Declare Any the recognition and resolution of Cash
Cash Variance and I Variances.
Make Good or
Declare any
Outstanding
Losses
2.5.1.1.2.3 I Stock Revaluation Stock Revaluation Messages for user when revaluations are
approaching.
2.5.1.1.2.1 I Stock Remittance / Rem In/Out Stock Changes to Stock Remittances and
‘Transfer Transfers resulting from Stock by Volume.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 2€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Secti ding CD Proce:
251.24 Stock Declarations Local Stock Check I Changes to Stock Declaration and
and Variances Stock Held for Adjustments resulting from Stock by
Stock Unit Volume and the use of the Loss Price.
25.16.14 I ONCH run for
“yesterday”
Table 10 ~ Contents of [DIAGDEC]
25.144 I Changes to Rollover I Produce Trial Dialogue for order and content of
processing Balance and warnings around new roll-over constraints.
Produce Final This will include all changes associated
Balance with both individual and Shared Stock Unit
period rollovers as well as changes to the
Office Rollover process.
2544.2 I Branch Trading Produce and The report layout of the of the new
Reports Confirm Trading I Trading Statement and dialogues
Statement associated to the rollover confirmation
2.5.1.1.1.4 I Protection against
lost data at system
start
25.1.6.2 Stock Unit in correct
Trading Period
251.14 I Changes to
Suspense Products
2.6.3.2.1 Process the final
cash account for
CBDB
2.6.3.2.2 Upgrade of Counter
processes to
‘operate Branch
Trading Statement
Table 11 — Contents of [DIAGBAL]
1.5.3 Counter index Check
Sections 1.5.1 and 1.5.2 relate the sections of this DP associated with the counter to
ULand HLD documents. The following table summarises this mapping and identifies
any sections which are not actually covered.
ectiol leading LI
25.1.1 Branch Transactions [CTRBAL]
254.1.4 Extending Transaction Retention
25.1.1.1.1 I Riposte Configuration Parameters
2.5.1.1.1.2_I Changes to the Expiry of Riposte messages
2.5.1.1.1.3 I Analysis of ‘unnecessary messages’ and their removal
25.1.1.14 I Protection against lost data at system start PIAGBAL]
25.4.1.2 Stock to be handled by Volume rather than by Value
2.5.1.1.2.1_I Stock Remittance / Transfer [DIAGDEC]
2.5.1.1.2.2 I Stock Sales
2.5.1.1.2.3 I Stock Revaluation [DIAGDEC] I [CTRDEC]
25.1.1.24 I Exceptional Products [CTRBAL}
2.5.1.1.3 _I Merging of Value and Non-Value Stock [CTRBAL]
25414 Changes to Suspense Products [DIAGBAL]
2.5.1.1.5 Change APS to use EPOSS Core
25.4.1.6 Settlement Transactions
25.1.1.7 Reversal Control 22 22
© [DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 27
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
leading E
25.4.2 Changes to Cash / Stock declarations and handling of [CTRDEC]
variances
2.5.1.2.4 Changes to Cash Declarations [DIAGDEC]
2.5.1.2.1.1_I Check for Variances Function
2.5.1.2.1.2 I Declaration Events
2.5.1.2.1.3 I Variance Persistent Objects
2.5.1.2.2 _I Reporting of Cash Variances [DIAGDEC]
2.5.1.2.2.1_I Reprints of the Cash Variance Report
25.1.2.3 I Processing of Cash Variances {DIAGDEC]
2.5.4.2.4 Stock Declarations and Variances [DIAGDEC]
2.5.4.2.5 Non-Value Stock Declarations
25.13 Reporting
2.5.1.3.1 I Remuneration Reporting (DIAGREP] I [CTRDEC]
2.5.1.3.2 I Office Snapshot Report {DIAGREP]_I [CTRBAL]
2.5.1.3.3 I Suspense Account Report {DIAGREP]_I [CTRBAL]
251.34 Counter Weekly Redeemed Savings Stamps Report [DIAGREP] I [CTRDEC]
NB
[CTRBAL]
says it is
covering
this.
However it
doesn’t
say
anything
ret!
25.135 I APS Transactions Report (DIAGREP]_ I [CTROEC]
2.5.1.3.6 I Event Log (DIAGREP]_I [CTRBAL]
2.5.1.3.7 I Other reports affected by changes to Stock Processing {DIAGREP]_I [CTRBAL]
2.5.1.3.7.1_I Remittance and Transfer Reports
2.5.1.3.7.2_I Remittance and Transfer Summaries
2.5.4.3.7.3_I Other Reports
25.1.3.8 I Reprints of Reports (DIAGREP]_I [CTRBAL]
25.13.9 I Reports proposed to be removed [DIAGREP] I [CTRDEC]
NB
[CTRBAL]
says it is
covering
this.
25.13.10 _I Weekly Reports {DIAGREP]_I [CTRBAL]
2544 Balancing and Rollover [CTRBAL]}
25.4.4.4 Changes to Rollover processing [DIAGBAL]
2.5.1.4.1.1_I Checking that a Stock Unit is balanced
2.5.1.4.1.2_I Handling Discrepancies prior to Rolling over
2.5.1.4.1.3 I Producing the Trial Balance / Final Balance report [DIAGREP]
2.5.1.4.1.4 I Rolling over the data into the next Trading Period
2.5.4.4.2 I Branch Trading Reports [DIAGBAL]
254143 Remove Extended CAPs [DIAGBAL]
2.5.45 EOD [CTROEC]
25.15.14 Removal of LFS Weekly Stock Reporting functions
2.5.4.5.2 POL FS Summarisation at counter
2545.3 Maintenance of Office Variances Persistent Object
25.15.4 LFS EOD functionality changes to handle changes in Cash
Declarations
2.5.1.5.5 Simplification of EPOSS Reconciliation
2.5.1.5.6 Protection against lost data
25.16 Logon Checks [CTRDEC]
25.16.14 ONCH run for “yesterday” [DIAGDEC}
2.5.1.6.2 Stock Unit in correct Trading Period {DIAGBAL]
2546.3 Outstanding Transaction Corrections [DIAGDEC}
2.5.1.6.4 __I Protection against Data Loss (DIAGBAL]_I 7?
25.4.7 Process Transaction Correction [DIAGDEC] I [CTRDEC]
25.4.7.4 Actual Processing of the Transaction Corrections:
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 2€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
1.5.4
lectin:
Reporting on Transaction Corrections
Bi
s-the final cash tforCBDB
{CFRBAL}
Rew
covered.
[MIGOWW
2632-2
Upgrade of Gounterp {o-operate Branch trad
Statement
1
[CFRBAL
Row
coveredin
Mico.
DIAGBAG
Merging-of N rT a Value Sk
26.324
Support.of HRDS supported Settlement Products
wt for-Q t Roll
PP
{[CTRBAL]
new
soveredin
[MIGOVW
1
{EFRDEC]
{CFRBAL
Table 12 ~ Counter Index Check
TPS Host High Level Design
The High Level Design for the TPS Host has been split between two High Level
Design Documents the following tables define which parts of this DP are covered by
Heading Description
Generate MiS Info
2.5.2.8.4 Initial Summarisation of Product and Mode
2.5.2.8.2 Summarisation for POL FS
2.5.2.11 Generate POL FS Info
2.5.2.14 TPS Host
Table 13 - Contents of [TPSPOLFS]
2.5.2.8.3 Summarisation for HR SAP
2.5.2.10 Generate HR SAP Info
2.5.2.12 Transaction Correction
Table 14 — Contents of [TPSOTHER]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Print
Page 2¢
ted on 22/11/2002 2:20:00 by Gld
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
1.5.5
1.6
Host Index Check
Section 1.5.4 relates the sections of this DP associated with the TPS Host to the HLD
documents. The following table summarises this mapping and identifies any sections
which are not actually covered.
ading
ROMC [ROMCHLD}
LFS {LFSHLD]
Process-SAP-ADS-Transactions
TPS Harvesting [TPSAGTHLD]
DRS Host [DRSHLD]
APS Host NIA
Generate MIS Info {TPSPOLFS]
initial Summarisation of Product and Mode [TPSPOLFS]
Summarisation for POL FS [TPSPOLFS]
Summartisation for HR SAP [TPSOTHER]
‘Accept CARO Data
Generate HR SAP info. (TPSOTHER]
Generate POL FS Info [TPSPOLFS]
Transaction Correction (TPSOTHER]
POA Data Warehouse [DWhHLD]
TPS Host {TPSPOLFS]
Reference Data Changes [ROMCHLO}
Table 15 — Host Index Check
DEPENDENCIES ON POST OFFICE LTD
The following are dependencies on Post Office Ltd:
m= That a CR is raised on [CDBT] to make the clarifications identified in
[CDBTCR1].
= That the following AISs and TISs are finalised and agreed according to the
development timetable assumed by the Commercial Terms and that any changes
to the interface requirements contained in the baselined AISs/TISs will be
introduced under Change Control:
a [CTSAIS] (Interface to Post Office Ltd of Client Transmission Summaries)
of EDSAIS:
co [HRSAPAIS] (Interface to HR SAP)
co [HRSAPAIS]] (Interface to HR SAP)
FHRSAPAIS2} daterface to HR SAP.
(interface-from-
co [MISAIS] (Interface to Post Office Ltd MIS System)
co [POLFSAIS] (Interface to POL FS)
a [RDSAIS] (Interface from nRDS)
Sof Card-Account-Activations}”
a {SAPADSAIS} Gnterface-f SAP-ADS-&
is Ht
8 There are no APS host cha quired.
Currently assumed out of scope.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Page 3C
Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
oc [TCAIS] (Interface from POL FS for Transaction Corrections)
a [POLTIS] (Technical Interface to Post Office Ltd)
» _ Confirmation-that-d is-not-a-requi +-to-support-thefoll AIS5-—HE-th
decisi 4s—that t—forth AISs—is—1 ied—th th Ke rt " dibs
i SEPP ° ia T it
handiednder- Change Control
co. fEDSAIS}Interface-from-EDS-of Card-Account-Activations}
ou {SAPADSAIS1 aterace from SAP ADS for Transaeti LS 3
t + }
1.6.1 Exceptions
The following requirements have been excluded from this DP:
a The requirements outlined in Section 21, Appendix C, of [CDBT] have been
excluded from this Design Proposal. In particular this means that requirement
[BT059] is not fully met.
= Some aspects of controlling non-value stock are excluded since the detailed
requirements are not clear. This is discussed further in section 2.5.1.1.3.
« The requirements for handling SAP ADS Transactions through TMS [BT108] and
for supporting a feed from CAPO to be included in the feed to HR SAP [BTI 11]
have been excluded.
1.6.1.1 Training
It is assumed that training will be provided by Post Office Ltd.
No specific training facilities are to be provided by Fujitsu Services.
Need to understand what impact this will have on Training Mode in general.
8 Currently assumed out of scope.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/
Page 31
11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 2 -
Solution Outline Design
2.1 GENERAL
This chapter provides a definition of the solution being proposed. This is done in the
following ways:
= An overview of the full Impact Release 3 solution is presented including a
breakdown of the components for which Fujitsu Services are responsible
= Changes to the components for which Fujitsu Services are responsible are then
described in more detail, enabling the High Level Designs for these components
to be produced
= Issues to do with Migration and initial start up are covered separately
Interfaces between components (both Internal to Fujitsu Services and External to or
from other service providers) are described in Chapter 3.
2.2 OVERVIEW OF IMPACT RELEASE 3 COMPONENTS
Figure I shows the overall scope of Release 3 of Impact and the components and
interfaces involved.
Pian _Reternce Osta Re
I systems Ra
I
I fend hecmen 2 POLFSRE
I Bank Stents R2
i
I >
I 3
I Transaction Comectons Ga
I
I
I Hessen
I Se systems 2
I Cn, .
I SAPADS Transaeers and Summaries Lees Ent eration 2
I Remuneration ifematon
I
I
I _—___
*I
CTS Fies
Management info R2
Figure 1 — IMPACT Release 3 Components
For simplicity I’ve left out the interfaces which are unaffected by Impact. In particular the
interfaces to and from AP Clients and the on-line and reconciliation interfaces with 3" parties
such as the NBE and Streamline.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 32
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
The interfaces (which are deseribed summarised in Table 16 below and described in
Chapter 3) are colour coded to highlight changes:
= Black lines represent existing interfaces that are unchanged
= Blue lines represent existing interfaces that are modified
= Red lines represent new interfaces
face Ts”
Reference Data POL Horizon _I 3.2.1_I [RDSAIS] [POLTIS]
Client Access Out of Scope
Bank Statements Out of Scope
Transaction Corrections I POLFS I Horizon I 3.2.2 I [TCAIS] N/A TIS is Intemal
to Fujitsu
‘SAP ADS Transactions I POL Horizon [32.3 I FSAPADSAIS] I [POLTIS] I Out of Scope
and Summaries & POL
FS
Ledger Entry Information I Horizon I POLFS I 3.2.4 I [POLFSAIS] N/A TIS is Intemal
to Fujitsu
TMS.-tnfoe-from-Glients: POL. Horizon I 3.2-5 I [EDSAIS} fPOLTS]
Remuneration Horizon I POL 3.2.6 I IHRSAPAIS] I [POLTIS]
Information [HRSAPAIS1]
Management Info Horizon I POL 3.2.7 _I [MISAIS] [POLTIS]
CTS File Horizon _I POL 3.2.8 I [CTSAIS] [POLTIS]
Table 16 — External Interfaces
It should be noted that some of the components are external to the overall system.
These are shown as green boxes in the diagram.
Some of the components / data flows have a suffix of “R2”. This has been done
purely to avoid duplicating objects names within Systems Architect. These suffixes
should be ignored and have not been included in the text in this document.
The components are:
= Prism Systems
This represents the systems provided and operated by the Prism Alliance. The
main components relevant to Fujitsu are:
Terminals for user access to POL FS (and other systems)
SAP ADS
MIS
Reference Data System
oooo0
= Horizon Systems
This represents the systems developed and operated by the Fujitsu Services. This
is expanded further in section 2.2.1.
= POLFS
This represents the new Financial System which will replace CBDB. It is being
developed by Prism, but will be operated by Fujitsu Services.
Its design is outside the scope of this document.
dey dd. tood—th: hess intedts ith. £4 Lelents fy 4,
astenas-that-will-need-te-t stod-by EMS
¥ PP yo MS:
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 3¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
The I: that—- nlp } feed—of—data—f EDS.
a a SeOpe-ts = S
= HRSAP
This is a system run by RMG to pay Postmasters. It is fed by summaries of value
and volume of a subset of transactions, which are the basis of the Postmaster’s
pay.
= POL Client Settlement
This represents that part of the Post Office’s central systems which receives the
CTS file each day.
= Financial Institutions
This represents the various external Financial Institutions which will need to
provide input to POL FS. These are outside the scope of this document.
2.2.1 Breakdown of Horizon Systems
Figure 2 provides a breakdown of the Horizon Systems and the interfaces between
them. For simplicity the agents have been omitted from the diagram. Changes to
agents will be covered as part of the description of the corresponding Host Systems.
Reference Data R2 Reference Data R2
— Re
Ree THSRE
Management info R2
‘Transaction Corectons A ae
rats ee Remuneration Infomation
I yen 82 -———————— TS Files .
fal 4
i rx] Teansacton Corrections Ra
Figure 2 — Horizon Systems
The components are:
= RDMC
This is the existing Horizon RDMC.
Changes are described in section 2.5.2.1.
a Branch Systems
These are the existing Horizon Counters. This is expanded further in
section 2.2.2.
a Transaction Management
This is the new Horizon Data Centre functionality. This is expanded further in
section 2.2.3.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 34
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
2.2.2 Breakdown of Branch Systems
Figure 3 provides a breakdown of the Branch Systems and the interfaces between the
components.
32
Fetrence Osta R2
Branch Transactions R2 BOOK Transactions R2
Transactions . —o
ci
4 q
#231
Caan and Peat
Stock »
Dectsration
7 q Transactions R2
37 7235
¥
Baisnes ad
Rotor R2
Transaction
Transacten Conections
Comecten 234
3
F233 I cash Dedtaration
Jiao Geeks]
a
I
R36
Figure 3 —- Branch Systems
The components are:
= Branch Transactions
This is the normal handling of Transactions within the Branch (ie the main
counter functionality).
Changes are described in section 2.5.1.1.
= Cash and Stock Declaration
There are requirements to change the declaration processes.
Changes are described in section 2.5.1.2.
= Reporting
Changes are required to the various daily and weekly reports being produced to
support the new branch processes.
Changes are described in section 2.5.1.3.
= Balancing and Rollover
These processes require changes to move from a Cash Account process to
producing a Branch Trading Statement.
Changes are described in section 2.5.1.4.
= EOD
This is the existing system initiated End of Day process which takes place in the
background.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Page 3€
Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Changes are described in section 2.5.1.5.
= Logon Checks
Some changes are required to some of the existing checks and new checks are
being introduced.
Changes are described in section 2.5.1.6.
= Process Transaction Correction
This is new functionality and is described in section 2.5.1.7.
2.2.3 Breakdown of TMS
Figure 4 provides a breakdown of TMS components and the interfaces between them.
Reference Data R2
Transaction
Ledger Entry Information R2
Storage R2 9 Y
Management Info R2
Remuneration Information
Transactions R2 CTS Files
A co
3]
A2.4.3
Transaction Corrections Transaction Transaction Corrections
Correction
a a
2
A2.4.2
Figure 4-— TMS
The components are:
a LFS
Since the changes to LFS are the removal of functionality rather than the
introduction of new functions, then it is omitted from the diagram
Changes are described in section 2.5.2.2.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 3€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= Transaction Storage
This is basically the functionality carried out by the current Host Systems (TPS,
DRS, APS, OBCS and the Data Warehouse) as modified to meet the Impact
requirements. This is expanded further in section 2.2.4.
= Transaction Correction
This is a new function to pass through Transaction Corrections from POL FS to
the Branches.
It is described in section 2.5.2.12.
2.2.4 Breakdown of Transaction Storage
Figure 5 provides a breakdown of Transaction Storage components and the interfaces
between them.
CEAITIPY FS Clare
aaa 0 Transactions sp tanactore
stone
Cia Tanetons
8S Transactions oan _
Transactions na. (PERSE >I Frorce
wan3e restore 2 (ecemsI _Tansactens
ones hos i I v
I oy Yessy
I ranean ——
7 Transactions Management no 2 [ POC WS]
12 ansacios >I ne
(88 Tranacons Transactions
x Yi —
PATARR ao
a (Ree
onsets [ OSS] eunmataaich
La
summaries
Sy iy ——s
ewe onic —
[ remureratn Sunmatds °° I Remuneration oma
L }
(ase) POUFSR:
[Generate POL Ledger Entry information
‘summaries FS info di
Th. fi ? th. the-H. Deata-< 42. } $
entre H-S- pur SUPP)
the-processi £-the-SAR-4ADS-Enets ' LS) sies-information-f I
the-dat +9-the-MIS-s:
pass . ys
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 37
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Ch rs des ibed-+ seeti 2.5.2.3.
a TPS Harvesting
This will become the prime mechanism for extracting Transactions from Branches
into the central data stores for passing onto the other Systems.
Changes are described in section 2.5.2.4.
= OBCS Host
This system will be unchanged. It is expected to die as Order Books are phased
out, however this may not be until after S80.
No changes are required for Impact R3.
= DRS Host
All existing interfaces to Reconciliation Clients (eg NBE, Streamline and E-Pay)
will continue to be supported (but have been excluded for simplicity).
The main change is to support the removal of the CAP on the C112 records and
the removal of the NB103 reports.
Changes are described in section 2.5.2.5.
= APS Host
All existing interfaces from AP Clients (eg Quantum and Watercard) will continue
to be supported (but have been excluded for simplicity).
Changes are described in section 2.5.2.6.
= Generate MIS Info
This will take the detailed Transactions from Branches and pass them across to the
MIS System.
Changes are described in section 2.5.2.7.
= Transaction Summarisation
This is a new component which is responsible for summarising transactions on a
daily basis so that the appropriate summaries can be made available to other
systems.
This is described in section 2.5.2.8.
=
tavhich-pr fil ived th-from-EDS
d-is-used-to-feed-HR-SAP-with-details-of new-CARO-accounts-acth 4.
This-is-deseribed-in-section-2-5.2.9-
= Generate HR SAP Info
This will take the Transaction Summaries and pass them over to HR SAP.
Changes are described in section 2.5.2.10.
= Generate POL FS Info
This will take the Transaction Summaries and pass them over to POL FS.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 3€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Changes are described in section 2.5.2.11.
In addition,
« There will need to be some changes to the Post Office Account Data Warehouse
to support Service Level monitoring.
These changes are described in section 2.5.2.13.
= There will need to be some interim changes to the current TPS Host processing
during the migration phases before we get to the full target functionality.
These changes are described in section 2.5.2.14.
2.3 Magsor NEw END To END CONCEPTS
The purpose of this section is to provide an end-to-end description of new
components that have an effect on multiple components of the proposed solution.
Do I need to add in a subsection here on Reconciliation?
Also need to consider the removal of min-cash account reconciliation.
2.3.1 Transaction Corrections
This is a new set of business processes to enable corrections to be made to the Branch
accounts as a result of various central investigations. The purpose of this new process
is to replace the existing Error Notice functionality.
In summary the process works as follows:
a The central accounting function decides that it is necessary to make some
adjustment to the Branch accounts
= A Transaction Correction is defined which will carry out the necessary changes (ie
the central user will define an amount to be transacted for a given Product in a
given Branch and a corresponding Settlement Product which will normally be
Cash or a defined Suspense Product).
The Transaction Correction will also define a list of possible actions that the
Branch Manager can take and also text to be presented to the Branch Manager
informing him / her of the affect of carrying out any of these actions.
a A daily file of such Transaction Corrections is generated from POL FS and passed
to Horizon overnight
= Horizon host systems need to receive this file and send messages using Riposte to
the specified Branches with details of the Transaction Correction. This will use
normal Bulk Loader technology including the use of Acks from the Branch to
acknowledge successful receipt of the Transaction Correction which can be
reported on as with any other in-bound file delivery. (See section 2.5.2.12 for
more details.)
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 3¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= In order to alert Branch Management of the receipt of Transaction Corrections a
new check is included at Logon for roles MANAGER and SUPERVISOR as to
whether there are any Outstanding Transaction Corrections and if so the user is
informed of the number currently outstanding and given the option of processing
them. (See section 2.5.1.6 for more details.)
= A new Transaction Correction Button is provided to enable the Branch Manager /
Supervisor to view and process Outstanding Transaction Corrections. (See
section 2.5.1.7 for more details)
a The result of processing a Transaction Correction will normally be the creation of
the specified Transactions, which will be returned to POL FS as part of the normal
flow of Summarised Transaction data at the end of the Trading Day on which the
Transaction Correction was processed at the Branch.
a An additional check is made as part of the Branch Balancing Process to ensure
that there are no Outstanding Transaction Corrections. This ensures that
Transaction Corrections cannot be ignored indefinitely. (See section 2.5.1.4.1 for
more details.)
As far as the processing of Transaction Corrections is concerned, the Host
functionality is very similar to that for Replenishment Deliveries (introduced at
Impact Release 1), in that a single message is written to Riposte for the appropriate
Branch for each Transaction Correction.
When a Transaction Correction is processed, a message is written at the Branch, thus
enabling a Branch to scan all Transaction Corrections and any Transaction Correction
Processed messages, and thus easily identify any that are Outstanding. This is the
same as the logic currently used to handle LFS messages.
In order to keep things simple at the Branch, it is proposed that Transaction
Corrections include the <WAIndex.LFSFlag:> attribute with new values for
Transaction Corrections and Processed Transaction Corrections. (See [CTRDEC].)
2.4 UNCHANGED PROCESSES
A number of the Business Processes described in [CDBT] require no functional
change. These are listed in Table 17:
Perform Range Checks -Transaction ... Validate Data Captured
Automated Reconciliation
Produce Daily Summaries
Produce Perodic Summares:
Verify Summaries
Despatch Redeemed Dockets
Produce Other Horizon Reports
Input Non Accounting Data
input Bulk Data
Input Additional Client Data
Investigate Balance Discrepancies
Roll Over Inactive Stock Units
Table 17 —- Unchanged Processes
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 4C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5 CHANGED COMPONENTS
2.5.1 Counter Components
2.5.1.1 Branch Transactions
There are a number of aspects to this:
= Extending Transaction Retention
= Stock to be handled by Volume rather than by Value
= Merging of Value and Non-Value Stock
= Changes to Suspense Products
= Change APS to use EPOSS Core
= Settlement Transactions
= Reversal Control
These are discussed further below.
2.5.1.1.1 Extending Transaction Retention
This is a new requirement and wasn't included in the March 2003 costings.
It doesn't directly support a Business function, but more the non-functional requirements and the
move to a monthly reporting period.
The move from a one week Cash Account period to a monthly Trading Period means
that transactional data will need to be retained in the branch for a minimum of 42 days
rather than the current 35 days. [BT049, BT0SO]
POL would prefer longer, but 42 days is thought to be the best we can offer without upgrading
the Correspondence Server Disk storage. Disk storage at the counter is considered not to be an
issue.
There are a number of aspects to this:
= Changes to Riposte configuration parameters and the migration implications
= Changes to applications in the way that they specify the Expiry of Riposte
messages
a Analysis of “unnecessary messages” and their removal
= Protection against lost data at system start
= Protection against lost data at EOD (see section 2.5.1.5.6)
= Protection against lost data at Logon (see section 2.5.1.6.4)
Some of these topics are covered elsewhere in the DP (as indicated), the remaining
ones are covered in the following subsections.
2.5.1.1.1.1 Riposte Configuration Parameters
The Riposte configuration is documented in three separate documents:
= Counters [RIPCNT]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 41
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
POL00038916
POL00038916
EA/DPR/004
4.4
16/09/2004
Correspondence Servers [RIPCS]
Other platforms [RIPDC]
These documents will be updated to reflect the detailed configuration changes
following detailed design. The main change is to MaxMessageExpiry to allow
messages to be retained for longer, however there are some messages whose retention
could be reduced in the branch given that we are committed to recover any non-polled
b
ranch by Day J.
MinMessageExpiry will remain at 34 days.
Riposte is currently configured as follow:
Feedback suggests that this is probably too risky so
Correspondence Server & Clients _I MinMessageExpiry 10
Counter MinMessageExpiry 34 349
Correspondence Server & Clients_I MaxMessageExpiry 37 50
Counter MaxMessageExpiry 37 50
Correspondence Server & Clients I DefaultMessageExpiry I 36 43
Counter DefaultMessageExpiry I 36 43
2.5.1.1.1.2
2.5.1.1.1.3
Table 18 — Riposte Configuration Changes
Making these changes will require some other Riposte Configuration parameters to be
changed in line, however the details will be covered in the Riposte Configuration
documents [RIPCNT], [RIPCS] and [RIPDC] rather than here.
Changes to the Expiry of Riposte messages
The main EPOSS messages are explicitly written with an Expiry value of 35 days.
These need to be changed to 42 days. This value should be defined in a Type C
Reference Data Object, thus allowing the exact value to be easily tuned in future.
In some cases we may decide to just change the Expiry to the default value.
This is defined in [CTRBAL]}.
Analysis of “unnecessary messages” and their removal
A quick analysis of a live counter shows the following Expiry Values
E
Persistent Objects Could well have lower values which are
[R11], [Recov] overridden by MinMessageExpiry
35 18950 EPOSS Transactions etc __I Must be explicitly set.
36 8716 LPOs Probably defaulted
EOD Reconciliation
LFS
Total 33497
Table 19 — Expiry Value Analysis
Fewould be-usefulte-carsout Two separate exercises have been carried out:
= Set the Riposte Configuration values as specified in Table 18 and run a counter
with a complete mixture of transactions and look to see what the Expiry values
9 Jeitis unchanged
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPROO4.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by Gld
Page 42
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
become for various types of message. Need to consider any that do not have a
value of 34, 35 or 43, since that would mean that these are being explicitly set to
that value. No such messages have been identified.
= Analysis of those messages with a current Expiry value of 35 or 36 to see if it can
be sensibly changed. Specific types of message that could be considered for
reducing the Expiry value are:
LPOs
Some LFS Messages (ie those containing <WAIndex:>)
Print messages
EOD Reconciliation messages (though many of these are likely to be
removed)
oooo
The output of this analysis will be a series of proposals for further changes to the
Expiry Values of specific messages which should then be included with those changes
This is covered in [CTRBAL].
2.5.1.1.1.4_ Protection against lost data at system start
One of the major risks associated with increasing the Trading Period to 4 or 5 weeks
is that there is a significantly reduced margin for error should a branch not change its
Trading Period at the correct time. Currently there is a one week Cash Account
Period (which exceptionally can be extended to 3 weeks) and data is retained for 35
days, thus having a minimum safety factor of 2 weeks and a normal safety factor of 4
weeks before data relevant to the current trading period is lost. With the revised 4 / 5
week Trading Period and 42 days Transaction Retention, the safety factor has been
reduced to 2 weeks normally and only one week if there is a 5 week Trading Period.
Given the way in which the counter is currently engineered means that all local
reporting will fail and the ability to carry forward data into a new period will fail if
the data recorded at the start of a period is no longer available. Therefore, it is
essential that measures are introduced to ensure that the chances of losing data
associated with the current Trading Period are minimised. It is expected that there
may still be some obscure circumstances under which the data is lost, and the only
option in such cases will be to Temporarily Close the branch and reopen it as a “new
branch” as is currently done for long term temporary closures. Such a closure must be
for a minimum of 15 days currently and no work is being done to reduce that as part
of Impact R3.
The main measure to be undertaken to protect against data loss is a set of checks at
End Of Day. These are described in section 2.5.1.5.6. However these checks do not
protect against the case where all the counters in a Branch are switched off for a
period, thus preventing the EOD checks from being carried out. A simple mechanism
to handle this scenario is to carry out a check as part of the initial counter load
sequence, namely how long has the counter been switched off. If this is more than a
day (24 hours), then the assumption should be that the data on the counter may be
vulnerable and so the Riposte Configuration parameter DisableArchiving must be set
to I (through the registry) before starting the Riposte Service. The EOD checks will
ensure that this is reset back to 0 once it is safe to do so. [BT115]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 4¢
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Consideration is required as to whether there is a problem with implementing such a check on a
spare. For this check to be of use it must take place before Riposte is first loaded. It may be
sufficient that the code that carries out such a check is defined as an “immediate” fix.
This can be addressed in the HLDs.
PH: Have opened up conversation with Karen to attend to this - the following is her first quick
look at the problem “The starting of the Riposte service afier a reboot is instigated from a batch
file (services.bat) run under the control of PostPolo.exe (which is launched by Polo when PMMC
login is completed). This batch file is one of a number in the Cadmincfg\Postpoto directory
which are run in sequence by PostPolo. It looks as though we may need to insert another batch
file to be run before services.bat which changes the Riposte configuration if it thinks it is
necessary. I'm not sure at the moment how we work out how long the Counter has been switched
off, particularly in the case of a box-swap. Gareth seems to be implying that it is simple, so
hopefially it will be!”
GIJ: My statement was based on a conversation with Simon Fawlkes,
This bit of code is owned by Karen Morley’s team in ITU.
I need to ensure that this is being picked up properly.
Although I day is possibly a bit aggressive, with only 7 days between a “normal” 5 week
Trading Period and losing data, 1 believe that this is necessary. However the time should be
configurable (via the registry) to allow subsequent tuning.
2.5.1.1.2 Stock to be handled by Volume rather than by Value
This is a new requirement and wasn’t included in the March 2003 costings.
It doesn’t directly support a Business process.
This has a number of implications: [BT056]
= Stock Remittance / Transfer
= Stock Declaration / Adjustment (see section 2.5.1.2.4)
= Stock Sales
a Stock Unit Balancing (see section 2.5.1.4.1)
= Stock Reporting (see section 2.5.1.3.7)
= Stock Revaluation
= Exceptional Products
Some of these topics are covered elsewhere in the DP (as indicated), the remaining
ones are covered in the following subsections.
2.5.1.1.2.1 Stock Remittance / Transfer
This supports part of the Business Process Rem In/Out Stock.
In general, Stock Remittances and Transfers are carried out by volume. There are
some exceptions to this and these are discussed in section 2.5.1.1.2.4. However when
the remittances / transfer transactions are recorded, then the stock values are recorded.
This should be changed such that a value of zero is recorded.
This may require changes to the Transaction validation function for Fixed priced
products.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 44
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
A new flag will be required in product Reference Data to identify a stock Product as
being handled by Volume rather than by Value and this should be used for controlling
this change. (See also section 3.5.)
This in turn means that when the Remittance / Transfer session completes, there will
be a net value of zero on the stack, and so strictly there would be no need for a
settlement transaction. However, a zero-value settlement transaction will be recorded
since some reporting is against the Settlement Product.
A consequence of this is that there will be no value for the overall Remittance /
Transfer session and so this will mean that the Remittance / Transfer reports will
change. This is covered further in section 2.5.1.3.7.
2.5.1.1.2.2 Stock Sales
A concept of Tertiary Mappings is introduced for stock products (see
section 2.5.1.4.1.3) in order to support the production of the Stock Unit Balance
Report. All Transactions (both stock and non-stock) may need to include these
Tertiary Mappings where they exist in addition to the current Primary / Secondary
Mappings, dependant upon the Mode of the Trasnaction.
This is a change to EPOSSCore and so is not specific to stock.
2.5.1.1.2.3 Stock Revaluation
This supports part of the Business Process Stock Revaluation.
A consequence of holding stock by volume rather than by value (and the business
reason for doing it) is that revaluation is no longer required as a branch accounting
function. I However the current mechanism of reporting imminent product
revaluations is still required to ensure that stock levels are adjusted correctly prior to
the revaluation and that staff are fully aware of the new prices. [BT046] However the
functionality to support revaluation of Stock Levels will no longer be required and so
can be removed. (ie the button will become invisible at the appropriate point in
migration)
2.5.1.1.2.4 Exceptional Products
“Other Stamps” have a special problem since they can’t easily be managed by
Volume. Therefore they will continue to be managed by Value and so still appear as
part of the Stock Unit Balance (together with Cash, Cheques and Foreign Currency)
In particular any Non Value Indicator stamps (in particular the 38p Europe stamp)
should be removed from the list of “ether-stamps” on the Declare Stamps and Postage
Stamps Remittance menus and no longer be transacted as Postage Stamps (F3 on the
main Serve Customer menu) and appear as a separate menu item. This will enable
them to be held by volume and thus avoid any future revaluation. Note that there is a
requirement on Post Office Ltd ([BT047]) to make this change.
This can be handled via normal OBC and should take place prior to S80.
This should be a simple Fype- Reference Data change.
I It probably required both Type A and Type C Reference Data changes.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 4£
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.1.3
Table 22 (in section 2.5.1.2.4) identifies other products that are likely to present
g
Need to cover this in {MIGOVW],
imilar problem. All these products should continue to be managed by Value and si
have their mapping set appropriately and appear in reports as at present.
It is assumed (though perhaps not explicitly stated), that none of the exceptional products will
require to be re-valued,
Phil B is working with POL on a detained analysis to try and remove all such exceptions.
I'm also concerned that any such exceptional products will give POL FS a problem.
However our current design will handle such products sensibly (other than revaluing them). The
issue is what impact it has on POL FS.
2
0
Baseline position is that we do nothing and that they are both handled as Volume Stock.
Merging of Value and Non-Value Stock
This is a new requirement and wasn't included in the March 2003 costings.
It doesn't directly support a Business function.
(BT0S5]
There are a number of requirements in terms of how Stock is to be handled in future.
No changes are currently proposed in this area other than removing the non-value stock
functions.
The following discussion is included for information and we anticipate receiving a CR from POL
to request further work in this area.
The CR is 3813.
I need to update this section.
They can best be summarised as removing the distinction between Value and Non-
Value stock.
Currently, the only purpose of Horizon taking note of non-value stock is for the
weekly stock report to SAP ADS. This will be removed (see section 2.5.1.5).
Having done that, any current non-value stock products can be “retired” in the normal
way and removed from the system. Since it is understood that the weekly stock repo
is not actually used by SAP ADS, there is no need to wait until the interface
removed before starting to remove non-value stock from the system.
rt
is
Further analysis is required by Post Office Ltd as to what should happen to these non-
value stock products. The following are the options:
= Do Nothing
= Change the transactions that are currently undertaken which use the non-value
stock to become Value Stock transactions.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPROO4.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Page 4€
Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= Re-engineer the transactions to better exploit Horizon functionality
Since there are no specific requirements on this in [CDBT], our current costings
assume that Post Office Ltd will choose “do nothing” in all cases.
Further analysis has been carried out and this is included in section 9.2.
2.5.1.1.4 Changes to Suspense Products
This is a new requirement and wasn’t included in the March 2003 costings.
This supports part of the Business Process Make Good or Declare any Outstanding
Losses.
There are currently a number of Products and Buttons that relate to the Suspense
account. For each line on the suspense account there are 2 associated products:
= One to post the item to the Suspense Account
= One to clear the item from the Suspense Account
Most of these are invoked by Buttons or picklists on or below the Housekeeping
menu. The following changes are required:
There are two aspects of this.
* ifthe “emergency suspense” products are still required, then we need to keep the buttons for
them (or introduce new ones)
+ If they are to continue io be “Suspense
products, does that mean we have to leave full
access to the Housekeeping Menu?
tny changes here would require a CR/CP.
= All of the Suspense Account Products are to be restricted to those Roles who can
do an Office Balance (ie Manager, Supervisor, Migrate, Auditor and Auditor -
Emergency Manager). [BT040a]
This will be controlled using normal Menu Security functionality on the
Housekeeping menu.
= The list of Suspense Account products needs to be rationalised. Some additional
products are required and some existing products may no longer be required. In
particular some of the products may become non-core. [BT 102]
Branch Consumables and Corporate Customers have been introduced as new
Housekeeping categori It is assumed that normal Pick List mechanism can be
used to define the exact products to be included in these categories and that the
introduction of such products will be handled using the OBC process.
Note that Products cannot be removed if there is still a balance associated with
them. This means that in practice it is unlikely that any Suspense products will
actually be removed, however the buttons that enable the Suspense products to be
used will be removed. Business processes will then ensure that Transaction
Corrections are used to clear out the balance from these Suspense products.
= Need to introduce a new “Local Suspense Account”. This is also linked to the
Stock Unit Balancing Process (see section 2.5.1.4.1). [BT102]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Page 47
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= The buttons that allow Error Notices to be cleared and Vouchers to be processed
need to be removed, since in the future this will be achieved using Transaction
Corrections. [BT103]
This can all be implemented via Reference Data Changes.
The detailed changes are specified in [DIAGBAL].
Section 9.3 contains details of the current suspense products.
2.5.1.1.5 Change APS to use EPOSS Core
The APS application needs to be changed to call EPOSS Core thus enabling it to pick
up other changes associated with Stock Products and Tertiary mappings.
Tneed to ensure that this is being picked up properly.
2.5.1.1.6 Settlement Transactions
Currently, we have a number of “special products” with Product Ids in the range
10,000 to 13,000 which are managed by Fujitsu and do not come from POL as
Type A Reference Data.
Historically these products are of no interest to POL and in particular are not passed
to OPTIP. In general this is achieved by suppressing such products in either the TPS
Harvester or in the TPS Host (or in many cases both!).
However with the introduction of Impact, some of these products are relevant to POL
FS, namely the Remittance Settlement Products for Cash and ForEx. At Impact R1
these are picked up at the branch as part of the EOD Summarisation process and
harvested as part of the POL FS feed into the TPS Host. However at Impact R3, since
summarisation of transactions for POL FS is done in TPS, all such transactions will
need to be harvested otherwise the data passed to POL FS may not balance and data
will be lost.
The following table shows the types of products affected with approximate numbers:
10639 & 10990 Revaluations These appear to be historic and can no longer be
transacted.
11212 & 11213 Revaluations Currently used for revaluations. Since revaluations-areto
b dit d-that-th th tRroduct
ti-revaluati longer required.
Will still be required to support ForEx revaluations
11101 Adjustment This relates to staff discounts and has never been turned-
on in live. Since the system has moved-on since
implementation, then I would suggest that it would be risky
to turn this functionality on without rechecking the code (le:
would require a CP).
Therefore suggest this product is removed.
11200 & 11201 Transfers Settlement Products for Transfers between Stock Units
11202 — 11211; Rems Settlement Products for various modes of Remittance
11215 & 11216 NB some are no longer used (Modes now redundant)
plus others at S60
11214 Parcel Traffic Settlement Product for Parcel Traffic sessions
11217 - 11299 Rems New Settlement Products introduced at S60 or later
11300 - 11401 Scales No longer used
11999 - 12002 BES No longer used
© [DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 4€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Table 20 — Current Settlement Products
There are two approaches to this that could be considered:
= That we continue using the existing Settlement Products, but ensure that they are
harvested to TPS so that they can be used for Transaction Summarisation, but are
suppressed in the feed to OPTIP. We would need to consider separately whether
or not they should be passed to POL MIS.
= That we pass control of these products back to nRDS since they need to be aware
of those used for summarisation to POL FS. This will probably result in them
having new Product Ids (presumably in the 5000 or 6000 range), which in turn
will require changes to some of the Type C Ref Data to use the new products.
It has been agreed withir-Fujitsu that we take the second approach;-hewever-this-has
still-to-be-discussed-with-the-POL-Refe Data-t . In particular, transactions
involving such products must not be sent to MIS and so the product Reference Data
needs to identify such products to enable them to be easily suppressed by the TPS
Host system.
The proposed approach is to request that nRDS delivers replacements for the
Settlement Products that we expect to be used and we then withdraw all the 1xxxx
equivalent products following migration. There are migration issues and these are
discussed in section 2.6.3.2.4.
Fer-tt ini duets-it-is-safest-teteave-th 4 d-conti
SP 8 s > PP’
th Harvesting.—Fhi s-that-if-th: -er-transacted,-th ill Hei
Ahich-will-easily-be detected in-the POL-FS-S risation-funeti
2.5.1.1.7 Reversal Control
This section has been added as a result of a question from ITU concerning the ability to Reverse
Transaction Corrections.
An additional check is required in the handling of Existing Reversals, based on the
Mode of the original transaction. In order to support this check a new flag is required
in the ModeParameters to indicate if Existing Reversals are supported for
Transactions originally carried out in a given Mode
It should be noted that there are already a number of specific checks done for an
existing reversal, some of which are already based on the mode of the original
transaction. Consideration should be given to removing such checks to utilise the
generic mechanism.
Note that this will have UT implications which have missed the current UIDP.
I need to consider the implications of this.
2.5.1.2 Changes to Cash / Stock declarations and handling of variances
This is a new requirement and wasn’t included in the March 2003 costings.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 4¢
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Again, there are a number of aspects to this:
= Changes to Cash Declarations
= Reporting of Cash Variances
= Processing of Cash Variances
= Stock Declarations and Variances
= Non-Value Stock Declarations
These are discussed further below.
2.5.1.2.1 Changes to Cash Declarations
This supports the Business Process Compare Generated with Actual Cash Held for
Stock Unit.
Currently there are separate functions for a Cash Declaration (on the Stock Balancing
menu) and ONCH Declaration (on the reporting menu). Both have similar dialogues
with the branch office staff and record similar information within the message store.
It is required that the ONCH declaration be removed. [BT 104]
For ease of transition, the Cash Declaration Button will also be placed on the
Reporting menu.
The dialogue of the Cash Declaration function will be basically unchanged.
The detailed dialogues for the current Cash Declarations and ONCH Declarations
have subtle differences. In all cases the Cash Declaration dialogue will be followed
rather than that for ONCH Declaration dialogue.
In order to support subsequent reporting, details of cash declarations made need to be
held in a set of Persistent Objects similar to those currently used to hold details of
ONCH Declarations. These are described in section 2.5.1.2.1.3. The denominational
level information will continue to be maintained in Declaration messages. The
Variance Py S45) +. Ob}. t. iid: ify—th Jatest-Deeclarati. +h hi 5 4:
made:
For an Unshared Stock Unit, any difference between the declared figure and the
systems generated figure will be presented to the user and will be recorded (as a
discrepancy — but now to be called a variance) as part of the Declaration event.
For a Shared Stock Unit, a new function, Check for Variances, is required to check for
Cash Variances across all declarations within the stock unit. This is described in
section 2.5.1.2.1.1.
In addition, an extra button is added into the “Produce Report” screen at the end of a
Cash Declaration in a Shared Stock Unit, giving the user the option of going straight
into this new “Check for Variances” function. [BT026]
2.5.1.2.1.1 Check for Variances Function
The Check for Variances function will present a list of declarations for that stock unit
with different Declaration Ids and then compare the total declared position against the
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
system derived figure and again any differences will be recorded (as a variance) as
part of the appropriate event. [BT 105]
The rules for picking those Declarations Ids to be presented as part of the Check
Variances function are the same as those currently used by the Stock Unit Balance
Process. The processing required is:
1) Find the latest Declaration Variance Persistent Objects for each Declaration Id
that has been used within the current Stock Unit
3) For each Declaration Id being displayed need to include the following:
© Declaration Id
e User
e Date and Time of Declaration
© Node
4) The user has the option of abandoning the function if they are not happy with
the list presented. This can be achieved by use of the Prev or Home buttons.
There is no need to explicitly request confirmation. The list will be displayed
as a picklist (as for the current list displayed as part of SU Balancing)
5) If the user selects Continue, the current stock unit derived position is
calculated and compared with the sum of the declarations selected.
6) If they match, then a Shared Stock Unit Variance Check Complete event is
written; the Stock Unit Variance Persistent Object is updated; and the function
exits having confirmed to the user that there is no variance
7) If they do not match, then a Shared Stock Unit Variance Check Complete with
Discrepancy event is written; the Stock Unit Variance Persistent Object is
updated; and the function exits having informed the user that there is a
variance and what it is
Note that there is no requirement to produce a report at this stage. All the relevant
information can be found on the Variance Report.
It should be noted, that no attempt will be made to check or to take into account any
transactions that may have taken place between the times the various declarations
were made and the time that the Variance is calculated.
This is no different from the current “Discrepancies” function.
Two new events are required for this:
a Shared Stock Unit Variance Check Complete
= Shared Stock Unit Variance Check Complete with Discrepancy
Note that if other users attached to the Stock Unit have continued trading since they
made their Declarations, then the Variance that is calculated is likely to be incorrect.
No attempt should be made to compensate for this. It is the responsibility of the
Branch staff to ensure that no such trading takes place. This is why a list of when the
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 51
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
last Cash Declarations were made for each declaration Id is required to assist in
monitoring this.
This function can optionally be selected at the end of the Cash Declaration process, so
that the branch office staff can move into it directly if they know that all Cash
Declarations have already been made for that Stock Unit.
2.5.1.2.1.2 Declaration Events
In order to simplify subsequent processing of Variances, then it is necessary to change
the way in which the Declaration event is recorded.
There are 3 events currently associated with Declaration:
= Declaration Complete (Event Id 21)
This is used when a declaration has completed with no discrepancy or where it is
not possible to check if there is a discrepancy (eg in a Shared SU)
In this case the event message includes information about the value that was
declared
= Declaration Abandoned (Event Id 22)
I've tried to generate this event and have failed. I suspect it can’t happen.
It is now confirmed that although the code supports the generation of this event, it is not possible
to get to this bit of code. It can be ignored as far as this DP is concerned.
= Declaration Complete with Discrepancy (Event Id 23)
This is used when a declaration has completed and it has been detected that there
is a discrepancy from the systems derived figure.
In this case the event message includes information about the value that was
declared and the amount of the discrepancy
In addition two new events have been identified above:
= Shared Stock Unit Variance Check Complete (Event Id 63)
a Shared Stock Unit Variance Check Complete with Discrepancy (Event Id 64)
These new events will need to be defined in Type C Reference Data. Also a new
mechanism will need to be introduced to indicate that the shared stock unit
declarations have been completed.
Haye I got the signs the right way around? It isn’t clear in [CTRDEC] either.
These events will be classified as Balancing Events and SU Balancing Events and
those indicating a discrepancy (ie Event Ids 23 and 64) will contain a Parameter
<P1:> containing the amount of the Discrepancy. This amount will be held as a
signed amount — positive indicating a gain and negative a loss.
2.5.1.2.1.3. Variance Persistent Objects
In order to support the production of the Variance report (defined in section 2.5.1.2.2)
the following Persistent Objects are required:
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 52
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.2.2
= One for each week for each Stock Unit (shared or unshared)
= One for each week for each Declaration Id in each Shared Stock Unit
= One for each week for the Office
Old Persistent Objects should be logically deleted when they are no longer of use in a
similar way to that currently done with the ONCH_ww_SS' Persistent Objects,
however rather than removing the Persistent Objects, when they are no longer
required, their content should be removed and a “logically deleted” flag should be
included in the Persistent Object. This will avoid any problem with the Riposte
mechanisms for removing Deleted Persistent Objects. This logical deletion should
not take place until at least 5 weeks after the end of the week for which the Persistent
Object was created.
Each Persistent Object should contain a composite attribute for each day of the week
starting with Thursday, with the attribute name being the weekday name. Any
declaration made the following day as part of the logon check will be held under
yesterday’s composite attribute. Unlike the current ONCH Persistent Objects there is
no concept of carry forward declarations, so it will only be necessary to update a
single Persistent Object.
The manipulation and content of the Variance Persistent Objects is defined in
section-3.4.2 [DIAGDEC].
Reporting of Cash Variances
This supports the Business Process Create Variance Report ... Compare Generated
with Actual Cash Held Across Branch.
A report is required to show the variances for all Stock Units in the branch and also
indicate when the last declaration was done for each Stock Unit.
This is a new Office Daily Report which is generally available.
It is assumed that a new button is added into the Reports Menu at some appropriate
place (probably as an Office Daily Report)
The processing when the button is touched is as follows: [BT009]
1) The normal “Produce Report” screen is displayed
2) The Report tablet will include “Trading Period” and the current week
3} A-list-of Stock-Lnits-is-obtained
Presumably-by-enumerating-the Stocktmis-collection:
L pax Default Stock om ck Units m d.
4) All the Stock Unit Variance Persistent Objects for this week are found (of all
types)
NB if it is a Thursday, then the report is done on last weeks data and last
week’s Variance Persistent Objects are used instead.
If-this—isn2t-the—fiest-week—ef-a—Tradin Peried—then—Adl the Stock Unit
Nariance—P, iso—fe 4+, late th
riod fais
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
6) The report is then produced.
Details of the report layout are in [DIAGDEC] and the way in which it is
produced is defined in [CTRDEC].
ean-then-be-built-up-as-follows:
I've deleted the detail that was previously held in the DP at this point, since it is now in
[DIAGDEC} or [CTRDEC]
I've not marked it as a deletion.
It should be noted, that immediately after migrating to the Impact R3 functionality,
there will be a very limited history of Variance Persistent Objects. Any data that is
required by the report, which is not available in the Variance Persistent Objects,
should be treated as if no declarations were made on that day and “x”s output.
Special handling is required for Stock Units that have been Created or Deleted during
the time covered by the report. The rules are as follows:
= Reporting for these Stock Units should be as above for the periods when the Stock
Units were in existence
= For those periods when the Stock Units were not in existence, then the various
columns should have a value of “n/a” rather than “x”, and the Stock Units should
be ignored in terms of deciding if totals should be included.
2.5.1.2.2.1 Reprints of the Cash Variance Report
This report is produced from the raw data in a similar manner to the production of the
Cash Variance report as described above. The difference is that the date range for
which the report is to be produced is defined as part of the reprint mechanism and the
Variance Persistent Objects for that period are used rather than those for the current
week. [BT060a]
2.1.2.3 Processing of Cash Variances
This supports the Business Process Make Good, Hold or Declare Any Cash Variance.
The Cash Declaration process may result in Variances being identified between the
Declared Cash values and the System Generated values. Such variances can either be:
= Held (ie ignored for now in the expectation that they will resolve themselves)
m Made Good (ie the physical cash will be adjusted to match the System Generated
figure)
= Recording the variance as a Discrepancy (ie the System Generated figure will be
adjusted to match the physical cash by creating a transaction which is balanced
against the Discrepancy product)
This is current functionality and will continue to be invoked only as part of the
Stock Unit balancing process. This is covered further in section 2.5.1.4.1.
Making good a loss (or removing excess cash), has no actual affect on the system
generated figures since what is being done is adjusting the actual cash holding to
reflect what the system thinks it to be. This can be thought of as making an update to
the last Cash Declaration recorded in the system.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 54
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
There is also a requirement to make any such event explicitly visible, so that if an
issue subsequently comes to light there is some evidence that there had been a
variance within the system. [BT032]
Therefore two new “buttons” are introduced in the Stock Balancing Menu:
= Make good a loss
= Remove excess cash
The-c Dial s-will decide-wh. hese-buttens—-will-be-added-to-th
These buttons will I be available for any clerk to record the “making wood” events.
Such “make good” events will be recorded in the audit trail and can be viewed using
the normal event reporting mechanisms and will also be passed through to MIS. They
are also shown on the Stock Unit Balance Report (section 2.5.1.4.1), the Variance
Report (section 2.5. 1.2.2) and the Branch Trading Report (section 2.5.1.4.2).
Invoking either button will result in a screen being presented to the user inviting them
to enter the amount to be made good (or removed). No attempt is made to calculate or
verify this amount is to be made, since it is assumed that trading has taken place since
the last Declaration.
The Variance report may help the User in working out how much (s)he needs to Make Good.
Two separate events will be defined:
= Make good a loss (Event Id 59)
m Remove excess cash (Event Id 58)
These events will be classified as Balancing Events and SU Balancing Events and will
contain a Parameter <P1:> containing the amount of cash Made Good / Removed.
This amount will always be held as a positive amount — the different events will allow
the effect to be deduced when reporting on the amounts.
The relevant event is written to record the fact that the Stock Unit’s cash position has
been corrected.
In addition, the last cash declaration for the Stock Unit will be updated (for an
unshared Stock Unit the user will be asked to chose which Declaration Id should be
updated). [BT032]
Need to handle the case where no declaration has yet been made. However this is unlikely to
happen in practice since:
¢ adeclaration should be made each day
* adeclaration would probably have been made to enable a variance to be identified and thus
for the clerk to decide that there is something to make good
Any subsequent attempt to update the declaration will make it clear that there is an
amount “made good” (or removed) from the Declaration. However if a subsequent
Declaration is made, it is assumed that the cash declared at that time is correct and the
record of the amount made good (or removed) will not be carried forward in the
Declaration.
Foals -of-all-amounts-made-good-or- removed: within-the-current-Balance-Period-will
tad onthe Balance Reperi(s LAt
F is LS ~
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.2.4 Stock Declarations and Variances
This supports the Business Process Local Stock Check Stock Held for Stock Unit.
There are currently two mechanisms supported for managing Stock levels and
adjusting them:
= Stock Adjustments
This mechanism presents the clerk with a list of all Stock items (apart from cash
and “other stamps”), together with the system derived stock levels.
The user can then page through the list of products and amend the volume of any
products to match those actually held. When the Finish button is pressed a “Stock
Adjustment” transaction is created for each stock item whose level has been
changed based on the Sale Price and a balancing transaction of cash in each case.
= Stock Declarations
This mechanism is only available in a Shared Stock Unit. The clerk is presented
with a list of all previous Stock Declarations made, together with their Declaration
Ids and timestamps in this current Balance Period ter-CAP2}. They can then
select one of these declarations to update or alternatively decide to make a new
declaration from scratch.
They are then presented with a list of all Stock items (apart from cash and “other
stamps”) and are invited to make a “blind declaration”. If it is a new declaration,
then they are required to enter a Declaration Id.
Subsequent use of the Discrepancies function or running a Trial Balance will then
compare the total Declarations for the Stock Unit with the System Derived figures
and highlight any discrepancies that are identified. If this check is done as part of
the Trial Balance process, then the discrepancies must be accepted, which will
result in a Discrepancy transaction being created for each stock item whose level
is identified as being in error based on the Sale Price and a balancing transaction
of the Discrepancy product in each case.
Both of these mechanisms need to be retained, however rather than using the Sale
Price when recording the Adjustment or Discrepancy transaction, a separate “loss
price” should be used. This “loss price” will optionally be supplied as part of the
Product Reference Data. Should no “loss price” be defined in Reference Data, then
the Sale Price should be used. [BT036]
This has a number of implications:
= Changes are required to Product Reference data to include an optional “loss price”
for those products where it is different from the sale price. This is discussed
further in section 3.5.
a The Pick lists displayed by the Stock Adjustment and Stock Declaration functions,
include the Sale Price in brackets after the Product Name. This should be
replaced by the “loss price” (if specified).
= When the Adjustment or Discrepancy is recorded as a Transaction, then the price
used should be the “loss price”.
Note that any validation associated with Fixed Price products needs to take into
account that the loss price may well differ from the Sale Price.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Currently Methods of Payments such as Cheques and Vouchers are also presented in
these lists.
In fact my system has 15 additional items in the Adjust Stock menu compared with the Declare
Stock menu (344 and 359 respectively, so it’s a bit hard to compare them easily!).
Table 21 shows those items on the current Stock Adjustments menu that represent
“Methods of Payment” rather than actual stock products:
2 Cheque
2642 Citibank Money Order
Voucher to CRU Presumably we're getting rid of this
Assumed to be at Point 30 in migration so this will
no longer be valid when the changes to Stock
4 take place.
5 Unpaid Cheque
231 Encashed OB Cheq to CRU
278 POL Cheque
Table 21 — Method of Payment Products
These products should continue to be adjusted by value by the Stock Adjustments
function.
Table 22 shows those items on the current Stock Adjustments menu that are adjusted
by Value rather than by Volume:
15 Philatelic Items Other
47 Presentation Pack
5456 Prestige Stamp Books
5457 Mini Sheets
21 Other Stamps Ordinary we were already aware of this one
28 Other Postage Stationery
27 Other Stamp Special
43 Stamp Book Other
45 Disct Whsle Stamp Books
2649 Migration Only Item-HCS
Table 22 — Stock Products currently adjusted by Value
These products should continue to be handled by value in all cases.
However POL are looking at removing these products and replacing them with alternative
products that cau be handied by Volune. Any such changes are considered to be “Business as
Usuat” and not specificatly part of Impact R3.
2.5.1.2.5 Non-Value Stock Declarations
This is a new requirement and wasn’t included in the March 2003 costings.
It doesn’t directly support a Business function.
Since the intention is to remove non-value stock as a concept any processing of non-
value stock will need to be removed. (See also section 2.5.1.1.3) [BT 106]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 57
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.3 Reporting
These are new requirements and weren't included in the March 2003 costings.
There are a number of aspects to this:
= Remuneration Reporting
= Office Snapshot Report
a Suspense Account Report
= Counter Weekly Redeemed Savings Stamps Report
ma APS Transactions Report
m Variance Reporting (see section 2.5.1.2.2)
= Stock Unit Balance Reports (see section 2.5.1.4.1)
a Branch Trading Reports (see section 2.5.1.4.2)
= Reporting on Transaction Corrections (see section 2.5.1.7.3)
= Event Log
= Other reports affected by changes to Stock Processing
= Reprints of Reports
a Reports to be removed
= Weekly Reports
Some of these are discussed elsewhere in this DP (as referenced); the remainder are
discussed further below.
The move from a weekly Cash Account to a monthly Branch Trading cycle means
that there will up to be 5 times as much data to scan when preparing a report, and
some reports will be much bigger. However there are no requirements to improve the
reporting mechanisms, and so increased report production times are acceptable.
(BT001]
Dev have some ideas in terms of “caching” Data Server data to improve the performance, but I
want to avoid this if at all possible so as to keep things simple.
Currently all reports have references to CAP within their headers. Changes will be
required to change this to either a Trading Period identifier ora—+radi mh E
Range.
2.5.1.3.1 Remuneration Reporting
This supports the Business Process Produce Sales Report to Assist Remuneration
Check. The business requirement is that a postmaster can look at the data that will be
used by HR SAP to calculate his remuneration. However it is up to the Postmaster to
select the appropriate dates that align with those used for delineating “pay months”.
Another aspect of this alignment is that the dates specified need to align to EOD
markers rather than to calendar dates so that again the data aligns with that which is
passed to HR SAP.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
The requirements are to be met by making a change to the way in which the current
Sales Report is produced.
Currently, the Sales Report reports on all relevant transactions since the start of the
current Cash Account period.
The requirement is to include an additional dialogue at the start of the process asking
the clerk to input a Start Date and an End Date.
The dialogue will be formally defined in {¢D1AG}[DIAGREP], however it will have
the following characteristics: [BT016]
1) A new button is added to the “Produce Report” screen called “Define Date
range”
2) The Report tablet will include “Trading Period” rather than “Office CAP”
3) If no Date range is selected then the current behaviour will continue (ie from
the start of the current Trading Period up until the present time)
4) If “Define Date range” is selected, then the clerk is invited to select firstly a
Start Date and then an End Date. These are both to be specified as normal
calendar dates (dd/mm/yy). The following validation is required:
a) End Date is no later than “yesterday” and EOD has been run for that
day.
b) Start Date is less than or equal to End Date
c) Start Date is not less than xx days before “today”
Where xx is defined in Reference Data and defines the Transaction
Retention time.
5) The scan for the Transactions to build the report should be modified so that if
a Date Range is specified, then the start point for the transactions is defined as
the EOD marker for the Trading day before Start Date, and the end point for
the transactions is defined as the EOD marker for the Trading day of End
Date. These EOD markers can be found by following the chain of EOD
Markers from the Current EOD Object.
2.5.1.3.2 Office Snapshot Report
This supports the Business Process Review Stock Held Across Branch.
This report is similar in layout to the Stock Unit Balance report, however covers all
transactions for all Stock Units, rather than being restricted to a single Stock Unit.
It is proposed that its scope is unchanged, however the actual report layout will be
changed in line with the changes being made to the Stock Unit Balance report as
defined in section 2.5.1.4.1.3. [BT037]
2.5.1.3.3 Suspense Account Report
This report needs to take into account the changes to the Suspense Products
(described in section 2.5.1.1.4) and also the introduction of the “Local Suspense
Account”. [BT039]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 5¢
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
It has been agreed that this report will continue to be available to all users (ie no
additional security needs to be added).
However to avoid the report growing too much and to enable old Suspense Products
to be “retired”, some additional flexibility is required in the way the report is
produced. Currently all possible Suspense Products are reported on in the Suspense
Account Report. In future only those Suspense Products which have either a Balance
or a movement during the Trading Period should be included. All Suspense Products
with zero balance and no movements in the period should be suppresses when the
report is printed.
There is an added complexity. With the introduction of Cash in Pouches at S60, there
will be a potentially large number of Cash in Pouches transactions, particularly in
large branches (maybe hundreds in a 5 week period). Therefore CP3787 has been
raised to address this issue. The solution has two aspects:
= The “Cash in Pouches” section of the Suspense Report will be handled differently
from all other Suspense product, in that only the summary line will be included.
This summary line will just give the total Volume and Value of Cash in Pouches
Transactions together with the B/Fwd and C/Fwd figures. The detailed
transactions will be suppressed.
= A new report will be introduced which will provide the details of all the Cash in
Pouches Transactions. This report will be optional.
2.5.1.3.4 Counter Weekly Redeemed Savings Stamps Report
This is a new report. [BT107]
It should become a mandatory report with a cut-off and must be produced if any
savings stamps have been redeemed. It should include a total of all transactions
which involve redeemed trading stamps since the last cut-off. These can be identified
by having a Level 2 accounting node of 535.
2.5.1.3.5 APS Transactions Report
This report is currently produced based on all Transactions that are found under the
APS Node in the accounting hierarchy. Given the need to introduce Stock Products
for AP Transactions, then the report should be changed to report on all Transactions
which have been written with <Application: APS>.
2.5.1.3.6 Event Log
No changes are required to the reports as such, however there will be additional
events introduced which will need to be categorised appropriately to appear on the
various subsets of events.
This should be purely a Reference Data change to the Events Collection.
2.5.1.3.7 Other reports affected by changes to Stock Processing
The changes to Stock Processing, particularly those requiring stock to be held by
Volume rather than by Value (see section 2.5.1.1.2) require a number of reports to be
changed so that stock values are no longer reported. [BT056]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.3.7.1
I’ve also seen some example reports where a stock item only has a value and no volume — clearly
we will need to ensure that this doesn't cause any problems. Hopefitlly it is just bad examples in
[REPREC]. However there are some products listed in Table 22 (section 2.5.1.2.4) which need
special consideration.
This is expected to be primarily a change to the report definitions in GlobalObjects.dat rather
than actual code changes.
The following table lists the reports that are affected and where the required changes
are specified:
‘Name ¢
EPOSS Balancing Reports
Declaration: Stock on Hand See section 2.5.1.3.7.3
Stock Unit Balance: Snapshot See section 2.5.1.4.1.3
Stock Unit Balance: Report See section 2.5.1.4.1.3
Stock Unit Balance: Reprint See section 2.5.1.4.1.3
Office Balance Snapshot See section 2.5.1.4.1.3
EPOSS Counter Weekly Reports
Counter Weekly Remittances In See section 2.5.1.3.7.1
Counter Weekly Remittances Out See section 2.5.1.3.7.1
Counter Weekly Remittances Summary I See section 2.5.1.3.7.2
Counter Weekly Stock on Hand See section 2.5.1.3.7.3
Counter Weekly Transfer Summary See section 2.5.1.3.7.2
Counter Weekly Transfers In See section 2.5.1.3.7.1
Counter Weekly Transfers Out See section 2.5.1.3.7.1
Counter Weekly Travel Schemes. No change required.
EPOSS Office Daily Reports
Office Daily Remittances In See section 2.5.1.3.7.2
Office Daily Remittances Out See section 2.5.1.3.7.2
Office Daily Revalued Product List No change required.
EPOSS Office Weekly Reports
Office Weekly Remittances In (P) See section 2.5.1.3.7.1
Office Weekly Remittances Out (P) See section 2.5.1.3.7.1
Office Weekly Suspense Account See section 2.5.1.3.3
Office Weekly Transfer Reconciliation See section 2.5.1.3.7.2
Office Weekly Unreconciled Transfers See section 2.5.1.3.7.2
EPOSS Receipts and Slips
Remittance In Slip See section 2.5.1.3.7.1
Remittance Out Slip See section 2.5.1.3.7.1
Transfer In Slip See section 2.5.1.3.7.1
Transfer Out Slip See section 2.5.1.3.7.1
LFS Reports and Receipts
[Retum Advice Note See section 2.5.1.3.7.1
Table 23 — Reports affected by Stock Changes
Remittance and Transfer Reports
The report layouts should remain unchanged, however any stock remittances will be
at zero value, thus resulting in the value column usually being zero in such cases.
Since there will be some cases (eg cash), where the value is non-zero, the actual
report layout will not change. In particular zero values will still be output in the
report rather than being suppressed.
Tneed to check this. I think we may have since decided to stippress zero values.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Page 61
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.3.7.2 Remittance and Transfer Summaries
The report layouts should remain unchanged, however any stock remittances will be
at zero value, thus resulting in the value column usually being zero in such cases.
2.5.1.3.7.3. Other Reports
These need to be considered individually:
= Declaration: Stock on Hand
The value column should be remain in the report layout to support stock that is
still handled by Value, however the value should be suppressed for those products
handled by Volume (rather than included as zero). The total at the bottom should
be removed.
= Counter Weekly Stock on Hand
This report needs to be restructured in a similar way to te-previde-a-tist-of-all-steck
items-as-held-in-the-stock-on-tand seed £ the Stock Unit Balance report (see
section 2.5.1.4.1.3).
It will contain two main sections:
o Value Stock and MOP
co Volume Stock
corresponding to the sections in the Stock Unit Balance report.
The Value column should be removed in the Volume Stock section and no Total is
required in that section.
A. rf +h. ak 4} sheuld—b. in-n—th ja ++: PF rt—steck
that-is-still-handled-by-Value-and-MOP-products ! lue-should—b
5 4 -for-th roducts-handled-by-Kol a luded-as
SUPPEESS sep y s 7
The-total-at-the-bottom-should-t >ved.
This restructuring can be achieved by using the Tertiary mappings described in
section 2.5.1.4.1.3.
2.5.1.3.8 Reprints of Reports
Currently a number of reports are defined as being capable of being reprinted.
Stock Unit Balance: Reprint
Cash Account: Reprint Requirement carried forward to
Branch Trading report
Office Weekly Counters Revenue Schedule: Reprint This report is no longer required so
the reprint can also be removed.
Office Weekly Inland Revenue Tax Credits P5589: Reprint
Office Weekly P&A P2311MA: Reprint
Office Weekly Redeemed Savings Stamps Summary:
Reprint
Track and Trace Manifest: Reprint
Table 24 — Reports that can be reprinted
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 62
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
It is also required that the new Variances report will need to be reprinted. Since the
requirements for this are somewhat different to other reports this is considered as part
of the Variance report in section 2.5.1.2.2. [BT060a]
The current mechanism for this is that each time one of these re-printable reports is
produced, then the start and end markers used for producing the report are stored and
the reprint is achieved by rescanning the transactions using those markers. This
means that reprints can be done for those CAPs that are still “in scope”.
I believe that “in scope” means the last 3 CAPs, however I'm not sure what happens with multi-
week CAPs. I suspect it is the last 3 CAP numbers which means that the Transactions must be
there even with a multi-week CAP.
Can this be confirmed please?
The move to 4/5 week Trading Periods makes the Reprint function more complex.
Different reports are affected in different ways:
= Office Weekly Counters Revenue Schedule: Reprint
Since the original report is to be removed, then there is no need for a reprint.
a Track and Trace Manifest: Reprint
The current functionality is purely to reprint the last report produced, so no change
is required.
T now understand that this report has not yet been introduced. It isn't yet clear if it will be
introduced in S80, however I think it is OK to ignore it in this context since it is not aligned to
CAPs,
Office Weekly Inland Revenue Tax Credits P5589: Reprint
Office Weekly P&A P2311MA: Reprint
Office Weekly Redeemed Savings Stamps Summary: Reprint
Variance Report Reprint (new)
All of these will continue to be weekly reports, however they will be identified by
the Date Range for which they were produced rather than by the CAP of the week
for which they apply.
The requirement is to be able to reprint all those reports for which the data is still
available, ie the last 5 reports. Therefore, no changes are required to the way in
which the reprints are produced other than by identifying past reports by a date
range rather than a CAP.
Note that when the branch has just migrated from CAP operation into Branch
Trading operation, it should still be possible to Reprint the reports from the “CAP
period”, however such reports will be identified to the user by the dates when they
were produced rather than by the CAP they were produced for.
= Stock Unit Balance: Reprint
a Branch Trading Report: Reprint
Here, the requirement is to be able to reprint the last report that has been produced
for each Stock Unit /Office (excluding any interim Stock Unit Balance Period
reports). This will be achieved by ensuring that all data required to reprint the
report is stored as a BLOB within the messagestore at the time that the report is
originally run. New reprint functionality is then required to take the data from this
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6¢
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
BLOB and regenerate the report based on that data. Since only the last report
requires to be reprinted, it is sufficient to maintain the last report data as a
Persistent Object which is overwritten each time a new report is produced.
Note that during the first Branch Trading Period it should still be possible to
reprint the last CAP based Stock Unit Balance Report or Cash Account Report,
provided that all the data for such a report is still available in the message store (ie
by invoking the old code to regenerate the report from the raw data). Once a
Stock Unit or Branch has rolled over into the second Branch Trading Period, then
there is no need to be able to reprint CAP based data
2.5.1.3.9 Reports proposed to be removed
The following reports are considered no longer necessary as a result of the changes
introduced by Impact (or other changes) and so will to be removed. [BT057]
Counter Weekly DVLA V11
Office Weekly Counters Revenue Schedule And the ability to reprint it
Declaration and Confirmation — Non-Value Stock I [BT063]
Counter Daily Cash on Hand ‘There is a separate report for Cash Declaration
which is nearly identical
It is just the Cash Declaration report that we need
to retain
Office Weekly Cash Flow This is replaced by the Variance report
Counter Daily Revaluation Session Slip
Table 25 — Reports to be removed
2.5.1.3.10 Weekly Reports
There are currently a number of Weekly Reports within Horizon. The move to a
monthly Trading Period means that all these reports need to be reviewed as to what
affect this might have on them. The underlying principle is that current weekly
reports will remain weekly and will be driven by a normal calendar (typically start of
business on Thursday to close of business the following Wednesday). Reports will
either be mandatory or non-mandatory in terms of business processes. Mandatory
reports will be produced weekly by reference to the calendar by the Branch staff.
Non-mandatory reports will be produced by the same means but if not printed will
accumulate data during the trading period until they are printed. Some reports are
defined as Mandatory within Horizon and what this means is that Horizon will ensure
that they are printed at before allowing the Stock Unit to rollover at trading period
end.
No support is required from Horizon to manage conformance to any of the above
other than the following:
= Existing mechanisms for forcing reports to be produced prior to Stock Unit /
Office rollover will be maintained
= Any necessary changes to ensure that reports can be cut-off other than at period
end (for example on a weekly basis where required) such that subsequent weekly
reports only report from the last cut-off rather than for the full Trading Period to
date are needed.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 64
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Many reports have the concept of a cut-off. What this means is that once a report has
been successfully produced, the clerk can request a cut-off; such that any subsequent
attempts to produce this report will only look at Transactions that have taken place
since the cut-off was invoked.
Table 26 lists all the current weekly report and highlights those that need to be
considered further.
EPOSS Counter Weekly Reports
‘Counter Weekly DVLA V10 Report to be removed
Counter Weekly DVLA V11 Report to be removed
Counter Weekly Green/Violet Giros Cut off None
Counter Weekly Inland Revenue Tax Credits Cut off None
Counter Weekly Miscellaneous Transactions Cut off None
Counter Weekly P&A Cut off None
Counter Weekly Pos Paid Cut off None
Counter Weekly Remittances In No cut off None
Should be Period based
Counter Weekly Remittances Out No cut off None
Should be Period based
Counter Weekly Remittances Summary No out off None
Should be Period based
Counter Weekly Stock on Hand No cut off None
This is a snapshot, so cut
off is irrelevant
Counter Weekly Transfer Summary No cut off None
Should be Period based
Counter Weekly Transfers In No cut off None
Should be Period based
Counter Weekly Transfers Out No cut off None
Should be Period based
Counter Weekly Travel Schemes Cut off None
EPOSS Office Weekly Reports
Office Weekly Cash Flow Report to be removed
Office Weekly Counters Revenue Schedule Report to be removed
Office Weekly Counters Revenue Schedule: Report to be removed
Reprint.
Office Weekly Green/Violet Giros Cut off None
Office Weekly Inland Revenue Tax Credits No cut off See Below
Office Weekly Inland Revenue Tax Credits No cut off See Below
P5589
Office Weekly Inland Revenue Tax Credits See section 2.5.1.3.8
P5589: Reprint
Office Weekly P&A P2311MA No cut off See Below
Office Weekly P&A P2311MA: Reprint See section 2.5.1.3.8
Office Weekly P2311MA (B) No cut off None
This has no data!
Office Weekly Pensions and Allowances No cut off See Below
Office Weekly POs Encashed Cut off None
Office Weekly Postage Labels No cut off None
Should be Period based
Office Weekly Redeemed Savings Stamps No cut off See Below
Summary Needs to be redesigned
Office Weekly Redeemed Savings Stamps See section 25.1.38
Summary: Reprint
Office Weekly Remittances In (P) No cut off None
Should be Period based
Office Weekly Remittances Out (P) No cut off None
Should be Period based
Office Weekly Sales Report No cut off None
In future will be Date based
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6£
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Office Weekly Suspense Account No cut off
Should be Period based
Office Weekly Transfer Reconciliation No cut off None
Should be Period based
Office Weekly Unreconciled Transfers No cut off None
Should be Period based
Other Weekly Reports
Foreign Currency Holdings Snapshot at any time None
Table 26 — Current Weekly Reports
The following changes are required:
= Office Weekly Inland Revenue Tax Credits
Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA
Office Weekly Pensions and Allowances
Office Weekly Redeemed Savings Stamps Summary
All of these reports need to change such that a cut-off is taken and the next report
will only look at the Stock Unit reports (ie Counter Weekly) produced since the
last time the summary report was cut-off. This is a new type of cut-off
functionality. Note that an implicit cut-off will occur when the branch is moved
to a new Trading Period. [BT116]
Note that there is currently no Counter Weekly Redeemed Savings Stamps report, however one is
being introduced for S80. See section 2.5.1.3.4.
2.5.1.4 Balancing and Rollover
There are a number of aspects to this:
= Changes to Rollover processing
= Branch Trading Reports
= Remove Extended CAPs
These are discussed further below.
2.5.1.4.1 Changes to Rollover processing
The March 2003 costings assumed no change to this process and so no costs were defined in this
area.
This supports the Business Processes Produce Trial Balance and Produce Final
Balance.
In general, the Stock Unit Balancing process will be very similar to that which is
currently in place. The following highlights the changes: [BT038]
The following are the main areas for change:
= Checking that a Stock Unit is balanced before allowing a Trial Balance to be
produced.
= Handling Discrepancies prior to Rolling over
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= Producing the Trial Balance / Final Balance report
= Rolling over the data into the next Trading Period
The migration implications are covered separately in section 2.6.3.2.2.
These are discussed below.
2.5.1.4.1.1 Checking that a Stock Unit is balanced
Some additional checks are required at this point:
Baseline position is that it stays as specified, however a CR / CP may be raised in this area
#. borall Steck-Lnits-tincluding-thedast)
o _I£-this-is—a-_rell. Tradine—Periedlas dt Balane
S As PP
). Di oj Hb 4-to-the-Local- Sus; count
P ry i E
+ ¥ tion-te-bi the-bal £-the-Diserepane
d-creat tching-tra tion-a +t-the-Local-S: 5
s Ss SESE
A Mod HL troduced~for-Such—Eranse H-take~plac
H. Mode-and-th pending-Local-Susp: e +-Product
be-identified-as-the-balancing-products for-the-Dise ey-product
Heusel hode—d. 4 hether—it Pp. Jewati
P S °
Diserey t-is-being- transacted —Two-Local Suspense-Ae +-Produe!
and for. tive-tra! " pa puired-si th
Pes (- s e
need-to-be-reported-on-in- different parts-of the accounting hierarchy:
= On the Final Stock Unit to be rolled over within the Branch
co Check that there are no Outstanding Transaction Corrections within the
Branch
This check is similar to the one carried out at logon (see section 2.5.1.6).
2.5.1.4.1.2 Handling Discrepancies prior to Rolling over
At the point where the user decides whether the rollover is to a new Trading Period or
to a new Balance Period within the current Trading Period, additional checks are
required.
If the rollover is to a new Trading Period (as opposed to a Balance period):
= then any Nett Discrepancy needs to be transferred from the Stock Unit to the
Branch’s Local Suspense Account. This is done by generating a pair of
transactions such that the first transaction causes the cumulative value of the
Discrepancy products for that SU becomes zero and the other transaction is
generated to balance this transaction is-balanced-by-a-transaction against the Local
Suspense Account product. These transactions should be carried out in Mode
Housekeeping (HK).
= If this is the last Stock Unit to rollover, also need to ensure that there-are-no
Diserepancies-within-the Steck -Unit-and-that the Local Suspense account has been
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 67
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
cleared. If it has not yet been cleared a dialogue is introduced to allow it to be
cleared at the time.
There is a requirement (that emerged in the UI workshops) that different
“products” are available for settlement depending upon the type of branch. The
rules for which products should be available are as follows:
a If Local Suspense has an overall gain (ie cash needs to be removed from the
till to balance it), then one list of products needs to be presented
a If Local Suspense has an overall loss (ie cash needs to be put in the till to
balance it), then a separate list of products needs to be presented
dt is proposed that each of these lists is presented as a Product Group which
identifies the relevant products. Some products may be non-core and they should
only be included in the pick list if they are available to be transacted in the branch
(as is the normal case for pick lists). Similarly some products may have minimum
or maximum values defined for them (in the normal way) and again they should
only be included in the list if the amount required to clear local suspense (ie the
ive of the amount in local suspense) is valid.
Should the selected product fail to be transacted then a suitable message should be
displayed to the user and they then have the opportunity to select a different
product or to abandon the rollover (using the Prev or Home buttons as normal).
A consequence of this is that the Final Balance Report may differ from the Trial
Balance report.
2.5.1.4.1.3 Producing the Trial Balance / Final Balance report
The actual Stock Unit Balance report that is produced (both for Trial and Final
Balances) will be amended as follows: [BT007]
The following are the areas in which changes are required:
= Header
Standard report header changes to remove CAP from the Header are required
here.
= Discrepancies Section
After the existing Discrepancy details, there is a need to add in the new lines for
the “Cash Made Good” and “Excess Cash removed” events. This information
should be obtained from the events recorded at the time (see section 2.5.1.2.3). A
total is also required. [BT032]
Note that on a Final Balance following a Trading Period Rollover, the Nett
discrepancy line will be zero.
= Balance Section
Since Stock is to be held by volume rather than value, then Volume Stock
holdings should be removed from this section.
This is to be achieved by including a new set of mappings on all stock product
Reference Data and included in all Stock Transactions known as Tertiary
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Mappings. These Tertiary Mappings will be in addition to the existing mappings
included on the Transactions.
If a Transaction has a Tertiary Mapping, then it is ignored when constructing this
section of the table. This will result in only those Inventory products with no
Tertiary Mappings (eg cash, cheques, other stamps or Foreign Exchange) being
included in this section of the Balance Report.
= Receipts Section
All Volume stock movements will need to be included in the receipts section.
If an Item has a Tertiary mapping then this should be used instead of its Primary
mapping when building up this part of the report.
In addition a further lines will be required for Local Suspense Transfers. Fhis-can
be-achieved-by-defini iate-Primary Mappines forthi duct
ry SP appHAgss P °
PPpropH
Revaluation Up transactions will no longer occur, so the “Reval Up” line should
be suppressed if it is zero.
It should be noted that since Volume Stock Remittances will have zero value, then
their value will be excluded from the Remittance part of this section. The same
also applies to Volume Stock Transfers.
= Payments Section
If an Item has a Tertiary mapping then this should be used instead of its Primary
mapping when building up this part of the report.
1 wouldn't expect any Stock Products to be mapped to the Payments section, however the
implementation should allow for it rather than exclude it.
« New lines will be required for Local Suspense Transfers. Fhis-can-be-achieved
by defini jate Pri Mannings for-this product
a 'S-approps PY EPPHAESS Pi -
Revaluation Down transactions will no longer occur, so the “Reval Down” line
should be suppressed if it is zero.
It should be noted that since Volume Stock Remittances will have zero value, then
their value will be excluded from the Remittance part of this section. The same
also applies to Volume Stock Transfers.
= Stock Section
This is a new section. Its purpose is to provide the current balance (by volume) of
all stock items that are held by volume. This can be done by selecting all stock
items (including the opening balance for the period) that have tertiary mappings,
but building the report based on the primary mappings. Such a figure will take
into account all Remittances and Transfers.
In order to support the revised reprinting functionality, the data used to build up the
report needs to be stored as a BLOB so that the report can be re-printed without the
original transactions being present.
2.5.1.4.1.4 Rolling over the data into the next Trading Period
The current rollover process generates a large amount of data from the Stock Unit
Balance report for use as an opening position for the new trading period. In the
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 6¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services
POL00038916
POL00038916
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.4.2
future, less data needs to be generated. The following defines what data needs to be
generated following the Stock Unit Rollover:
Opening Balances of all Inventory Products. This includes
eo Stock (this should just be a volume with a zero value other than those
exceptional products covered in section 2.5.1.1.2.4)
Any such item that has a Tertiary mapping should include a “dummy” Tertiary
mapping to ensure that it is handled correctly on the Balance Reports.
o Cash and near cash (eg cheques and ForEx)
c Suspense products
This data is currently written to the messagestore as part of the SU Rollover
process and, other than holding the carried forward stock with zero value (if there
are Tertiary Mappings present), no further changes are required.
Summary Information from the Balance Report to support the Branch Trading
Statement.
This data will be held in a Persistent Object as described in section 3.4.3.
Branch Trading Reports
This is the replacement for the Cash Account report.
This supports the Business Process Produce and Confirm Trading Statement.
[BT008, BT032, BT041, BT043]
It is assumed that the existing Office Rollover button will trigger this report instead of
the current Cash Account Report.
The processing when the button is touched is as follows:
1)
2)
3)
4)
The normal “Produce Report” screen is displayed
The Report tablet will include “Trading Period” and the current week
All the current checks made prior to allowing a Trial Cash Account to be
produced are made except that the check for non-value stock can be removed.
[BT063]
The report can then be built up as follows:
Perhaps this is too detailed for a DP, however I've included it since it is my way of clarifying my
understanding of the requirement.
Details defined in the UIDP.
a) Standard Heading
b) The-data-in-each-column-is-based-on-the The first column provides an
Office Total and is obtained by summing the values in the row. The
second column provides details of what is currently held in the
Suspense Account. The remaining columns provide details recorded
when each Stock Unit rolled over into the next trading period. If there
are too many Stock Units to fit on a single page, then additional pages
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPROO4.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by Gld
Page 7C
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
are required. Each page will repeat the Row headings, however there
is no need for subtotals to be carried forward from one page to the next
thetast-col £+thetast-pa il -contain the Office totals,
c) The data in each row can be obtained from the data stored as part of
each Stock Unit’s rollover process (see section 3.4.3)
Need to define how we obtain the Suspense summary. Perhaps this can be generated as part of
printing the Suspense report?
T need to sort this out.
@). The-Trading Positi d-Bal. Carried Ei d-lines-should-b:
jeulated by rf +the—l: i i: det int tf, a had
yo that-the-Balance—C; 4ed—F “d—fi. st-be—z
(oth ricea has. Gi a}.
In order to support the revised reprinting functionality, the data used to build up the
report needs to be stored as a BLOB so that the report can be re-printed without the
original transactions being present.
It may be sufficient to rely on the underlying Stock Unit rollovers maintaining this info.
Need to allow for an early rollover of one of the SUs.
2.5.1.4.3 Remove Extended CAPs
The Office Balancing Menu currently has a button to allow Cash Accounts to be
extended to 2 or 3 weeks.
This button should be removed, thus removing this functionality since it no longer
makes sense with Branch Trading Statements. [BT045]
2.5.1.5 EOD
There are a number of aspects to this:
= Removal of LFS Weekly Stock Reporting functions
= POL FS Summarisation at counter
= Maintenance of Office Variances Persistent Object
a LFS EOD functionality changes to handle changes in Cash Declarations
= Simplification of EPOSS Reconciliation
= Protection against lost data
The current APS EOD Reconciliation function will remain unchanged. [BT059]
These are discussed in the following sub-sections.
2.5.1.5.1 Removal of LFS Weekly Stock Reporting functions
The current LFS Weekly Stock Reporting functions which are run early on
Wednesday; Thursday and Friday mornings and again on Friday evening, should be
removed from the Counter Applications Schedule since they are no longer required.
[BT0S8]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 71
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
It is proposed that the code is left in the counter rather than actually being removed.
Strictly not part of EOD, but that’s as good a place to mention it as any other.
In theory it could be done tomorrow, but we need to understand what constraints there might be
from testing as to when it is removed. The actual removal is a change to the Reference Data that
controls the CAS.
2.5.1.5.2 POL FS Summarisation at counter
This functionality was introduced as part of Impact Release 1 at S60. With the move
to Transaction Summarisation at the Data Centre (see section 2.5.2.8), this
functionality will no longer be required other than perhaps to calculate the Carried
Forward cash position for the SAP ADS ONCH data flow. Because of this
dependency, it is simplest to leave the functionality unchanged.
jt—is d—that—th. 34 lified--EOQD. 7 Ss. sribed.
e a. is
seeti 5}-tak he-maint iE sh-p
thus this-function-to-be. Lone, s-complet
th atthis# nod ! 4 igrat 1
f oF
Th fe ch: s—will—b de—h: d-the-Ref ce-D: that sk th:
furnet ib. dat tha o tad jorati, -f. sect
PPEVP aS . ~
2.5.1.5.3 Maintenance of Office Variances Persistent Object
In order to support the Variance Report (described in section 2.5.1.2.2) a new function
is required as part of EOD processing to calculate information for the report.
This function will assemble the data needed for that day’s portion of the Office
Persistent Object.
It will also handle the bringing forward of data from previous days in the case where
no cash declaration is done (either where it is “forgotten” or the Drawer / Stock Unit
is unused for a day).
This has changed. Need to align with HLD,
I'm not 100% sure that the HLD is right yet so T'll leave this for now.
The information that needs to be assembled and the way in which it is calculated is:
= Suspense
Is there an appropriate accounting node (or pair of nodes) that will enable data Server to
calculate this easily?
WW: I don’t think there is. The suspense nodes are spread throughout the accounting hierarchy,
not conveniently under a single node or even a node pair. There is a collection, SuspenseGroups
which defines what goes onto the Suspense Account report in terms of EPOSSProduct pairs. This
may be sufficient for our purposes. If not, it might be possible to extend this collection to include
the appropriate EPOSSNodes as well.
This level of detail can be sorted out in the HLD.
Local Suspense
This can presumably be done in a similar way to Suspense. It is probably OK to treat Local
Suspense in the same way as Suspense for most purposes.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 72
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
This level of detail can be sorted out in the HLD.
a Adjustments
This is calculated by scanning all events from yesterday’s EOD Marker and
accumulating the net value of all Cash Made Good and Excess Cash Removed
events (Ids 59 & 58).
= Transaction Corrections Processed
This is calculated by scanning all Transaction Completion Complete messages
events from yesterday’s EOD Marker.
= Transaction Corrections Outstanding
This is calculated using the same logic as defined in Section 2.5.1.7.2.
a Stock Units not logged on Today
How is this done? Presumably can be done by checking all the SU Objects and building up an
appropriate list.
Or perhaps not transacted.
This level of detail can be sorted out in the HLD.
2.5.1.5.4 LFS EOD functionality changes to handle changes in Cash Declarations
It has now been decided that it is simplest to leave this functionality unchanged.
[BT029]
Sinee—sisnifieant—ch: s. required—to—this—cede—and thee +—code—has
intenance-problems(dueto-bei itten-in-C_rather_than-VB-ike the rest-of th
? v: it sed-that thi £, ienality-is. fate? in—-VB-all. or the
= ~ PROP" ~ ‘J ©
old-code-to-be-retired:
Thefuncth alt tig eq a + the fol,
s... Examine-the-various-Variance-Persistent-Objects-(deseribed-in-section-3.4.2)-and
thei: seciated—L 1. ay to~build the-Declared. h-Resiti fox
that-dass
b l HL
ti fi 4s
a... Write-the-data-_in-the- ONCH. age-as-at-present—It-should+ ted-that-th
if: fd, at fash. that+this-dat iL-abve fit-iat 4,
R. 4 a the—1 +} ist: ie-to-~handle—th st, £
Pe i) i) c
data BLOB +. db
¢
2.5.1.5.5 Simplification of EPOSS Reconciliation
The current EPOSS Reconciliation function runs each day as part of the EOD set of
tasks. At present this is a fairly complex set of tasks, however once the cash account
has been removed, then it should be possible to simplify it significantly to a simple
check that all Transactions have been successfully harvested.
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 72
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
It is proposed that this is achieved by providing a new function that merely calculates
the Daily Transaction Totals. +4 ge-for-this-can—be-extracted-lremthe-eurrent
funetion-into-a-new-function—Whistit ing-through-the transactions-to-de-this
also-maintain-the-Daily-CashM that-is required-by-the LES BOD
Therefore no changes will be made to the current function and the Reference Data that
invokes this function will be removed and replaced by Reference Data to invoke the
new function at the appropriate migration stage (see section 2.6.2). [BT059]
k rd +: +. cat £ thy id-EODB-A ti. 5-te-th: EOD-A. r
‘PP ere ~ a
th £% i 1-te-be-i pi ted-in-suck that—it-adilar fier-tk ed
344th is. Pp scibilien: that th, beth + da + d-that hh, "
s-that-it-cheeks-to-see-if the old. s_have-dene-the-work-already-and-if-so-to-d
‘nothite:
There is an issue with the reconciliation as proposed. What it does is allow reconciliation of
those Transactions that are being passed to OPTIP, not those transactions that are being passed
to POLE
We have considered making changes to the Reconciliation process to enable us to reconcile the
POL FS subset of transactions rather than the POL MIS subset, however making such a change
would require a CP io be raised, and this is tikely to be rejected on the grounds that there is no
chance of getting it included in 880 timescales.
Given the various checks that are in place, it seems safe to leave things as they are, Dis
with CS support this approach.
Should this move to section 2.3?
2.5.1.5.6 Protection against lost data
This is a new EOD Check that is required to protect against the potential loss of data
as discussed earlier in section 2.5.1.1.1.4. [BT115]
This check needs to be run on all counters every night as part of the EOD process.
However it is not important when in the EOD sequence it is actually run.
A check is required on the following:
= How many days ago was the Branch rolled over into the current Trading Period?
= For each stock Unit in the Branch that is still current (ie not Deleted), how many
days ago was it last rolled over into a new Trading Period?
In order to support this, the StockUnit Persistent Object and the EPOSSOffice CAP
Persistent Object will both need to include a new field “Date of last Trading Period
Rollover”, so that this check can easily be made without trawling through the
messagestore.
The Largest number of days detected from these checks needs to be calculated and
this number needs to be compared against a configurable parameter (configurable via
Type C Reference data to allow tuning — the proposed value is 38 days).
If the number of days exceeds the threshold, then the Riposte configuration parameter
DisableArchiving needs to be checked and if it is currently set to 0 it should be set to
1. Regardless of whether the parameter is changed an Error Event should be raised to
alert SMC.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 74
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
If the number of days does not exceed the threshold, then the Riposte configuration
parameter DisableArchiving needs to be checked and if it is currently set to 1 it
should be reset to 0. There is no need to record an error event in this case.
Simon has suggested that we may need to do some work to produce a report on these events to
pass to POL. This is excluded from the current costs. [BTO51]
NB: Any such reporting would be a Data Centre function and have no impact on the counter.
2.5.1.6 Logon Checks
This is a new requirement and wasn’t included in the March 2003 costings.
There are a number of aspects to this:
= ONCH run for “yesterday”
= Stock Unit in correct Trading Period
= Outstanding Transaction Corrections
® Protection against Data Loss
These are discussed in the following sub-sections.
2.5.1.6.1 ONCH run for “yesterday”
The checks currently carried out as part of the logon process that an ONCH
declaration was made the previous day, should be amended to check that a Cash
Declaration was made the previous day. If no cash declaration was made the previous
day, the user will be forced invited to make a declaration at that time; but siay-desiine
do-se-(this-is-different-fi the-e +-ONCH-check-at-lo
there ino option to decline) [BT028]
2.5.1.6.2 Stock Unit in correct Trading Period
The existing check that a Stock Unit is running in the correct Cash Account Period
(based on the Cash Account Weeks Reference Data), needs to be modified such that
the check is based on the Trading Period (based on the Trading Period Calendar).
In order to spread the workload at the centre, different branches will be configured (in
the Branch’s “Outlet Reference Data”) with an “Offset” (in days) from the eperate-to
different Trading Period Calendars aad-each—villindicatesvhat-Calendarit-should
eperate-to. [BT044] See also section 3.5.
2.5.1.6.3 Outstanding Transaction Corrections
This supports the Business Process Receive Automated Message.
Is the list of Roles configurable by Type C Ref data? DP says yes, HLD doesn’t mention it,
In order to inform the Postmaster that a Transaction Correction has arrived in the
branch for processing, and additional check is required on logon for any user with a
Role of Manager or Supervisor (actual list of Roles to be defined in Reference Data
see section 3.5), to see if there are any unprocessed Transaction Corrections.
[BT024a] How this is done is described in Section 2.5.1.7.2. If there are any, the
user should be prompted about their existence and given the option to invoke the
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 7£
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Process Transaction Correction function immediately. Such a check should take
place after all other existing checks.
An event needs to be recorded when a user is prompted. Section 20.15 of [CDBT]
defines how the event should be categorised. This is a new event with Identifier 62
and needs to include a parameter indicating the number of Outstanding Transaction
Corrections.
2.5.1.6.4 Protection against Data Loss
This is a new logon check. The logic
in section
s similar to that done at End of Day described
A check is required on the following:
= How many days ago was the Branch rolled over into the current Trading Period?
= How many days ago was the current Stock Unit rolled over into the current
Trading Period?
If either of these periods is greater than a configurable parameter (configurable via
Type C Reference data to allow tuning ~ the proposed value is 38 days), then a
warning is displayed to the user indicating this fact.
2.5.1.7 Process Transaction Correction
The March 2003 costings for this assumed that a centrally generated memo view was sufficient
and so no counter functionality was required. Any counter work is therefore in addition to the
March 2003 costings.
This supports the Business Process Handle Transaction Corrections.
There are a number of aspects to this:
= Actual Processing of the Transaction Corrections
= Selecting Transaction Corrections
= Reporting on Transaction Corrections
These are discussed in the following sub-sections.
2.5.1.7.1 Actual Processing of the Transaction Corrections
This is new functionality to automate the processing of Transaction Corrections (a
replacement for Error Notices). It is only available to those Roles who can do an
Office Balance (ie Manager, Supervisor, Migrate, Auditor and Auditor - Emergency
Manager). This will be controlled using normal Menu Security functionality.
This function will be activated by a new button on Horizon or as part of the logon
process (see section 2.5.1.6). [BT025]
Given the security requirements, it is simplest to add the button to the Housekeepng
menu,
The-CounterDieloaues-wwill decide awhere-the-butt il -be-added-to-the-syst
When the function is invoked, the user will be presented with a list of outstanding
Transaction Corrections. Section 2.5.1.7.2 describes how Outstanding Transaction
corrections are found.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 7€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
The list should be a picklist with the Transaction Corrections ordered based on Date
and Time generated. If multiple Transaction Corrections have the same Date and
Time generated, then they are further ordered based on the TC Reference field.
TC Reference is a concatenation of Iteration flag and Reference Id.
The user can then select a Transaction Correction from the list and process it.
Once a Transaction Correction has been selected for processing the system needs to
ensure that no other user is able to select that Transaction Correction for processing.
NB if it is simpler to lock out users from all TC processing rather than just locking out an
individual TC, then this is acceptable.
Also need to consider inhibiting this on an isolated Node.
The user will be shown what effect the Transaction Correction will have on their
branch position by displaying the Text field associated with the Transaction
Correction and will be invited to select one of up to 3 options associated with the
Transaction Correction (as specified in the Allowed Modes field).
[TCAIS] defines the interface in detail and in particular defines the 6 options that can
be presented to the user (though for any one Transaction Correction a maximum of 3
are available). Each of these Options is required to correspond to a new Settlement
Mode to simplify the passing of the data back to POL FS through the normal
Summarisation interface.
(CTRDEC] Seetion-3
Attribute Grammar.
defines how the Transaction Correction is to be held as
Depending on the mode selected the Transaction Correction will be processed as
follows:
= Mode MG (Make Good)
The Transaction Correction will define the Product to be transacted
(<Data.Article:>) and the accounting sense (<Data.AccountingSense:>), and also
the Product against which the Transaction Correction should be settled
(<Data.Instruction:>).
Following the UNDP discussions, it has now been agreed that in the following
circumstances the “Instruction” product may be substituted. These circumstances
are:
a If “Instruction” is “cash” (ie Product 1) and the accounting sense is such that
cash must be put in the till (ie TCINV — or do I mean TCCRM?)
a Then, Cheque can be used instead.
And so could Debit Card when CP 3785 is implemented.
= Modes HD (Plead Hardship), WO (Wrote Off) or AN (Assign to Nominee)
The Transaction Correction will define the Product to be transacted
(<Data.Article:>) and the accounting sense (<Data.AccountingSense:>).
Settlement will be against a fixed Settlement Product for the selected mode.
This fixed product would be defined in the normal ModeParameters Type C
Reference Data.
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 77
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= Mode EV (Request Evidence)
In the case of Mode EV two transactions are written against the article Product,
one positive and one negative, thus having a null effect on the Branch accounts.
However both transactions will be passed to POL FS so that they can tell that this
has happened.
= Mode SW (Stock Write On / Off)
In this case there will just be a single transaction (with Quantity and no value)
against the Article product (<Data.Article:>). Since it has no value, then there is
nothing to settle.
In all cases the transactions that are generated by this process (including any
settlement transactions) need to include the TC Reference (<Data.Ref:>) and the
additional data field (<Data:AddRef:>) so that it can be passed to POL FS.
These should be put into two new attributes under
<EPOSSTransaction.BlackBoxData:> called Ref and AddRef.
Note that there are potential requirements to handle adjustments to both value and volume, In
this case we will need to use the loss price if available for the products.
Assumed out of scope.
Assumption recorded in section 8.4
When the Transaction Correction is processed a Transaction Correction Processed
message should be written as part of the same Riposte Transaction, thus enabling
reports to understand the outcome of the Transaction Correction and to ensure that it
is not reprocessed.
It will also be possible to abandon the Transaction Correction. Should the
Transaction Correction be abandoned, then there will be no impact on the system and
the Transaction Correction will still appear in the list of outstanding Transaction
Corrections and may be processed by a suitably empowered user at a later time.
However any locks applied to prevent other users processing the Transaction
Correction will need to be removed.
Should the user select one of the options associated with the Transaction Correction,
then the underlying Transactions defined in the Transaction Correction will be applied
in the Stock Unit in which the user is currently assigned.
Should any of the associated Transactions fail validation for whatever reason, a
suitable message will be displayed to the user providing them with information to
raise a Help Desk call. The Transaction Correction will then be marked as having
been processed, though no underlying transactions will actually be performed.
A consequence of this is that a new method needs to be made available by EPOSS
Core, such that it is possible to pass it a Transaction and to decide whether or not it is
valid. If it is decided it is valid, then any subsequent request to write that Transaction
would always succeed.
This is necessary since at present any problems with the parameters would result in
prompts to the user about “miss-typed transactions”.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 7€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.1.7.2 Selecting Transaction Corrections
[CTRDEC] Seetien-3-3.2-describes how a Transaction Correction is stored within the
messagestore. Transaction Corrections can be easily identified by having a
<WAIndex.LFSFlag:TC> attribute and a <Data.Refi> and <Datatter:> TEId:=
attributes containing the unique Transaction Correction Reference defined by POL
FS.
A simple scan of the messagestore looking for all such messages will identify all
Transaction Corrections that have been received in the branch.
T suggest that the whole store is searched. It would help if the query is as refined as possible to
search on <WAlndex.LFSFlag:TC><Application:TC>, and only for the Correspondence server
Nodes.
This can be defined in the HLD. But it isn’t yer!
Once a Transaction Correction has been processed (as described in section 2.5.1.7.1),
then a Transaction Correction Processed message is written containing the
<WAIndex.LFSFlag:TP> attribute.
This mechanism then enables all Outstanding Transaction Corrections to be easily
identified as being those with a <WAIndex.LFSFlag:TC> message and no
corresponding <WAIndex.LFSFlag:TP> message for any given Transaction
Correction Reference.
Similarly all those Transaction Correction References with both a
<WAIndex.LFSFlag:TC> message and a corresponding <WAIndex.LFSFlag:TP>
message identify those Transaction Corrections that have been processed.
2.5.1.7.3 Reporting on Transaction Corrections
Two new reports are required to provide information about Transaction Corrections.
These are: [BT065]
= Outstanding Transaction Corrections Report
= Processed Transaction Corrections Report
Section 20.3 in Appendix B of [CDBT] defines the structure of these reports which
are both similar. Detailed definition of the report layouts will be defined as part of the
High Level Design phase in fCDIAG}[DIAGDEC].
The principle difference between the two reports is in selecting which Transaction
Corrections are to be reported on. This is described in section 2.5.1.7.2.
2.5.1.8 MiMAN
This is an aspect that was forgotten in the original design.
MiMAN is a desktop component that handles the initial startup of a new Branch in
Horizon.
It was designed to support the initial rollout of Horizon and enables opening values to
be input to Horizon to represent the state of each Stock Unit at the time that the Stock
Unit switches from manual processing to Horizon.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 7¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
It is now primarily used when a new Branch opens or reopens after a long term
temporary closure.
MiMAN is driven by the Cash Account Reference Data and provides a fast
mechanism for taking on the opening position.
It is proposed that MiMAN is replaced by a simple function that identifies whether or
not the Branch should be opening in CAP of TP mode and sets up an initial opening
balance of zero and initialises the current CAP / TP as appropriate.
Uf anything other than this is required, then a CR/ CP will be required.
I need to define how we can control the initial decision benveen CAP / TP using the Soft Launch
mechanism.
2.5.2 Host Components
2.5.2.1 RDMC
Is there an impact on RDT?
The main changes here are to support the new Reference Data that will be received
from POL as Type A Reference Data. This will be defined in [RDSAIS].
In addition there will be a Check function provided which will ensure the integrity of
the summarisation Reference Data. In particular it will need to ensure that all Product
/ Mode combinations have a defined mapping onto an Article. If this isn’t the case,
then there is a risk that when the transactions from a branch are summarised that they
will not balance to zero.
2.5.2.2 LFS
Nothing was included in the March 2003 costings in this area.
The weekly Stock Reporting functionality can be removed. This affects both the LFS
Agent and the LFS Host. Since the information is currently unused, it might as well
be removed as soon as LFS is upgraded at the Data Centre. [BT058]
It has now been decided that the simplest way to do this is to change the LFS
Harvester such that it no longer attempts to Harvest the Stock Statements. At the
simplest level this is purely a case of removing the filter from the LFS Harvester, but
the opportunity should also be taken to remove the associated code modules that
process the Stock statements and in particular the modules that access the Stock tables
in the LFS Host
The LFS Host (and Maestro schedules) can then be enhanced to remove these tables
and the associated modules that process Stock Statements.
Phisawill-be-a-ch: +0-the-_LES Hest only—The LES He terwill-beleft-alone-th
itayilleernt: +9-4 oa »Stock 4: ddate thetic tad bu thee 7
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 8C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.2.3 Process SAP ADS Transactions
The requirement for this has been removed and so the rest of this section has been deleted.
2.5.2.4 TPS Harvesting
This supports the Business Processes Scan Transaction for Day.
A few changes have been identified as being required here:
= Additional event information is required for MIS. Therefore the details of which
events are to be harvested and how they are to be transformed needs to be refined.
BT110]
The following additional events are required:
Trading Statement Created
56 ‘Trading Statement Period rolled
O77 Trading Statement Period Roll Abandoned
58 ‘Excess Cash Removed Parameter required indicating amount
59 ‘Cash Shortage Made Good Parameter required indicating amount
60 ‘Cash Variance Report Previewed
61 ‘Cash Variance Report Printed ° :
62 ‘(Outstanding Transaction Correction Parameter required indicating number of
__Reminder Displayed Transaction Corrections Outstanding
Table 27 — Additional EPOSS Events to be harvested
Note that additional Product Ids will need to be provided by Post Office Ltd onto
which these Event Ids should be mapped by the agent. These Product Ids will be
formally defined in [MISAIS] once they have been allocated by the Post Office
Reference Data team.
= In order to support the generation of individual Transactions for POL FS, it is
necessary to pick up the various Reference attributes if they are present.
Reference attributes will be present on Remittance Balancing transactions (in
Attribute <EPOSSTransaction.BlackBoxData.PouchId:>) and also for Transaction
Corrections (in Attributes <EPOSSTransaction.BlackBoxData.Ref:> and
<EPOSSTransaction.BlackBoxData.AddRef:>).
Three new columns will be required in the EPOSSTransaction interface tables,
Pouchid, Ref and AddRef into which these are harvested. H-it~is—present;
<EPOSS Transaction-BlackBoxData-Pouchld=>--will-be—harvested--into~-the-Ref
a 4 d hich-a—-T " 6 d-out d-by-th:
PP 'y
+ calue-t £ to-the ORTID-intert:
d-that-for-the POL-ES -interf: “ill thi I:
4h d-to-add 1 inte-all-the-rel. +-EPS-Jnterface-tables-t
jude +t deal
aa js fue-is-stilt ired-by-the OR TIP inter d-willals
= The TPS Harvester currently has a fairly complex mechanism by which it
calculates the CAP and BP of a Transaction based on the rollover markers that
delineate when the CAP and BP change for any Stock Unit. This mechanism will
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 81
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
need to be retained while data is still being passed to OPTIP, however once the
branches are no longer operating on CAPs, it will no longer be sensible to report
on this.
Therefore, it is proposed that an additional check is included in the TPS Harvester.
When the Stock Unit Persistent Object is retrieved in order to calculate the CAP
and BP a check is made as to whether that Stock Unit is currently operating in
Cash Account or a Branch Trading Period mode ee-section 2-63-22). If the
Stock Unit is operating in a Branch Trading Period mode, the Stock Unit
Persistent Object will contain an attribute <Data.TP:> with a non-null value. In
this case no further attempt should be made to calculate CAP or BP and values of
zero should be input into the TPS Interface tables. Note that if no Stock Unit
Persistent Object is found (for example because it has been deleted since the
transaction took place), then again values of zero should be returned. If TPS is in
the early stages of migration, then this will result in the Transaction being handled
as an Exception, but that is no different to what happens at present.
ws Currently the CAPTrailer message is picked up in order to harvest Cash Account
related data. If the branch is operating in Branch Trading Period mode,
{identified by the presence of an attribute <Data.TP:> with a non-null value in the
EPOSSOffice CAP Persistent Object) then no further processing is required
2.5.2.5 DRS Host
The following changes are needed here:
= Remove reporting based on CAP (eg NB103) [BT062]
Dev are concerned that POL haven't thought through the full implications on this on the Pol
Reconciliation processes.
a Remove the NB103 drilldown functionality on the DRS Workstation
Potentially this should be done some time later since this is used to look at historic reports.
See also section 2.6.2
= Inanumber of the NB102 reports the CAP column will be blank.
The specific sections are 2, 3, 4,5, 8,9, 10 & 11.
No change will be made to these reports for Impact R3.
We should look at removing this column in a future release, but leave it there for Impact R3.
= The DRS function that copies in data from TPS Host about Cash Account
Delivery to POL needs to stop doing that. Note that the function cannot be
removed altogether since it also copies in data on non-polled offices and it is
assumed that this is still required.
Other than that the reconciliation process remains unchanged. [BT059]
2.5.2.6 APS Host
Em-not-aware-of any No changes are needed here new.
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 82
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
This supports part of the Business Processes Deliver Data to External Systems.
In particular the reconciliation process remains unchanged. [BT059]
2.5.2.7 Generate MIS Info
This functionality will be done within the TPS Host system.
This supports part of the Business Processes Deliver Data to External Systems.
Problems have been identified in the current AIS / implementation (which is based on the OPTIP
feed):
+ Currenily all transactions other than Cash and Bureau are sent at their absolute values
+ There are no AIS Rules for Cash signage for Transaction Correction Modes
The introduction of Transaction Correctiosn implies that we will need to support signs on any TC
transactions and we ened io understand what impact this has on all signs.
One possibility is to send all transactions as signed. mple for TPS, but will probably
require s change in POL MIS. Another is to take account of the “Accounting Sense”
Ref Data when mapping signs and this will probably result in current mappings for most current
products. Then just need to consider the impact on TC product
This process takes the transactions and events from the Temporary Transaction Store
and passes them to POL MIS in a file as described in section 3.2.7. [BT043]
This process will be similar to the current process that produces the Transaction Files
for OPTIP, however the file format has changed as described in section 3.2.7. One
further change is that Settlement Transactions are not to be passed through to MIS.
Settlement Transactions are identified by having an Attribute Transfer_Txn_To_MIS
set in the Product Reference Data for the Product
2.5.2.8 Transaction Summarisation
This functionality will be done within the TPS Host system.
This supports the Business Processes Accumulate Transactions for Summarisation.
Currently this is being done at the Branch and the summaries are harvested into TPS
for passing onto POL FS.
There is no specific requirement on Fujitsu to make the changes in this area. This is because we
have chosen to do this as it makes the overall system simpler.
However what is now proposed is a new Summarisation function at the Data Centre
that will run as part of the normal overnight processing after the day’s data has been
harvested.
Summarisation is a three-stage process:
= Initial Summarisation of Product and Mode
= Summarisation for POL FS
= Summarisation for HR SAP
These are discussed further below.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 8¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.2.8.1 Initial Summarisation of Product and Mode
All Transactions are summarised by Product / Mode combinations such that for each
Branch and Trading Day there is a single Summary Record for each combination of
Product / Mode that has taken place during the Trading Day. So as to support
Migration (see section 2.6.3.1.3), separate summaries are produced for each CAP,
thus enabling those transactions produced prior to Migration Point 30 to be separated
from those that take place after this point.
Note that those Product / Mode combinations that are defined in the POL FS
Summarisation Reference Data as needing to be passed through to POL FS at a
transaction level are not summarised, but passed through as individual transactions
into the intermediate summarisation tables.
2.5.2.8.2 Summarisation for POL FS
A further set of summarisation, based on Reference Data, then maps the Product /
Mode summaries for each Branch / Trading Day onto the data to be passed to the
relevant POL FS Accounts (based on Articles).
Only Initial Summaries for a CAP greater than the CAP that triggers Point 30 are
considered. All other initial summaries are ignored by this process.
The rules for Summarisation are as follows:
1) For each set of Transactions that have been summarised by Horizon Product
and Mode they can be further summarised as follows:
a) Reference Data will define the Article associated with the given
Horizon Product.
b) This Article will have associated one or mode Article Modes
corresponding to the Horizon Mode under which the Product was
transacted.
c) If there is a single Article Mode for all Modes, then that Article Mode
is used to accumulate the details for all the transactions for that
Horizon Product
d) If there are a number of different Article Modes for different Modes,
then the appropriate one is used to accumulate the details for all the
transactions for that Horizon Product carried out in the appropriate
Mode
2) If the Article Mode is described as being “non-summarised”, then the
underlying transactions need to be preserved without being summarised.
ae ted—touerh ith th. guired—-Rek d—held—+: d—oef—th.
—- Such ra? hould—be-held-—in-thi 3 4 if-th
Beetle
3) A number of attributes are associated with the Article Mode and these will
need to be passed to POL FS with the associated Records.
A potential problem is that some transactions will have failed Harvesting and will
subsequently be passed through when they are repaired.
Recent analysis shows a number of causes:
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 84
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
¢ — Post Office doesn’t roll over for several weeks and so TPS Harvester generates a zero CAP /
BP
¢ Delete Stock Unit results in a zero CAP / BP
+ BdC problem where Reference Data allows a currency to be transacted, but First Rate
doesn’t provide a spot rate for that currency.
In all these cases the transactions would be OK as far as Summarisation is concerned. It is
proposed that these constraints are removed (see section 2.5.2.14). However Summarisation will
need to allow for potential errors.
The current frequency of such problems is about once per week so they can be handled manually
by the SSC.
In order to handle the case where Transactions are known to be missing (ie they have
failed harvesting), then there is no point in attempting to produce a sub-file for
passing to POL FS since it will be incomplete. Such cases can be detected by
examining the TPS Harvester Exceptions tables. Should any Transactions be in these
tables, the summaries should be held back for processing on a subsequent day when
the exceptions have been processed. A mechanism is required to take the corrected
exceptions and add them into the appropriate summaries.
A check is also required that all the data in a sub-file has a net value of zero. Should
this not be the case, then an exception needs to be raised and the summaries held back
until a correcting transaction is generated to enable the sub-file to balance correctly.
In theory this can’t happen, however in practice there could be bugs in the system or perhaps
even Reference Data errors that will cause this to occur. Therefore we need to allow for it.
We don’t want to repeat the mistakes we made with the original TPS processing where we
assumed that such errors couldn't happen!
James has confirmed that this holding back of sub-files is unlikely to give us SLA problems.
Assumption recorded in section 8.4
2.5.2.8.3 Summarisation for HR SAP
Only Initial Summaries for a CAP greater than the CAP that triggers Point 30 are
considered. Afl other initial summaries are ignored by this process.
A separate set of summarisation, again based on Reference Data, maps the Product /
Mode summaries for each Branch / Trading Day onto the data required for HR SAP
based on CTT Numbers. Note that not all Branches are required for HR SAP
summarisation (though it may be simpler to summarise for all branches and discard
those not required when the interface is built for HR SAP each month, since the
numbers of branches not required are fairly low - it is the Directly Managed Branches
of which there are about 600).
It is proposed that sets of summarisations are held for each branch for each target Pay
Period (as defined in Reference Data). Each day, the intermediate summaries
(described in section 2.5.2.8.1) are added into the set of summaries for the appropriate
Pay Period based on the Trading Date for which the transactions making up the
summaries took place. Note that for some CTT numbers (specifically Lottery
transactions), the summaries will need to be added into an earlier Pay Period than
others. This will be defined as part of the mapping Reference Data.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 8&
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Any corrected Transactions (following Harvesting exceptions) also need to be added
into the appropriate set of summaries based on their Trading Date.
Note that once a set of summaries has been sent to HR SAP, they will be marked as
such and any attempt to add further data into those summaries should result in the
data being included in the next period. ption—be tod fi 4
investigation: This should only happen if a branch has been non-polled for a
significant period and so should be very rare.
2.5.2.9 Accept CAPO Data
The requirement for this has been removed and so the rest of this section has been deleted.
2.5.2.10 Generate HR SAP Info
This functionality will be done within the TPS Host system. [BT112]
This supports part of the Business Processes Deliver Data to External Systems.
PO:
Currently, Postmasters pay is calculated based on the work that they did 2 months ago
other than for Lottery Transactions, where it is based on the work done in the previous
month. In order to support this, data about transactions undertaken during a pay
period are passed to HR SAP each month to support a run of the payroll system. An
added complication is that for those branches where the contract is with a separate
organisation (such as Tescos) rather than an individual, the data has to be made
available to HR SAP ina separate file for a separate payroll run.
POL are planning to simplify this such that all Postmasters / multiples will be paid
based on the previous months trading data. However it is not yet agreed when this
might happen, so we have designed the summarisation and file generation
mechanisms to support the current interface.
The summarisation process (including any complexities associated with accounting
for Lottery transactions “early”) is described in section 2.5.2.8.3. This process is
purely concerned with the ability to generate the two separate files each month to
contain the data for the relevant branches.
A single file generation process is required, however a parameter will be required
indicating whether it is to produce the files for the “multiples” (as—defined—in
fARSAPAISH) or the-file for the bulk of the branches (as-definedin fHRSAPAIS2P.
The format of both files is defined in [HRSAPAIS1].
This parameter will also control which branches should be included in the selection of
summarisation data. The identification of Branches into these two categories (or as
not required for HR SAP) will be done through Reference Data.
There is no requirement to consider the case of a branch changing its categorisation
during a month. In order to detect the situation where data comes from branches after
the data has been sent to HR SAP, the process should mark all summaries that have
been sent to HR SAP thus enabling the summarisation process to include them in the
next period’s summaries. raise-an-exception-in-this-ease: All data should be sent even
if a branch has been closed.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 8€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
It is assumed that this doesn't give us a problem in terms of Reference Data having removed a
closed branch. In particular the branch would be marked as ‘Closed’ rather than being
physically removed.
2.5.2.11 Generate POL FS Info
There is no specific requirement on Fujitsu to make the changes in this area. This is because we
have chosen to do this as it makes the overall system simpler.
This functionality will be done within the TPS Host system.
This supports part of the Business Processes Deliver Data to External Systems.
A set of files is required to be generated each night for passing to POL FS. The
structure of the file is basically the same as for S60, however the detailed record
formats have changed. Instead of building up the summaries at the counter and
passing them straight through to the file generation function, the summarisation will
now take place at the Data Centre. Some transactions (as defined in Ref Data) will
still need to be passed through “un-summarised”. All records for a single Branch /
Trading Day should have a net value of zero. This needs to be checked as part of the
file generation process and exceptions should be raised if that isn’t the case.
In order to support SLA Monitoring, information needs to be passed to the POA Data
Warehouse defining which Subfiles have been delivered to POL FS and the number
of Transactions associated with these sub-files. The calculation of the number of
transactions is already being made for the flow to MIS, and there is no need to re-
calculate this. Any differences (eg due to exceptions) can be ignored.
2.5.2.12 Transaction Correction
This functionality will be done within the TPS Host system.
This component takes the file produced each night by POL FS of Transaction
Corrections and passes them on to the specified Branch. [BT113]
This is a standard File Load and Distribute process very similar to that used for LFS
Planned Orders and Replenishment Deliveries.
In addition to loading the data some mapping is required based on Reference Data
(see section 3.5).
This mapping will be used to convert the Article and Instruction fields of the
Transaction Correction into the corresponding Horizon Products. Checks are also
done that the resulting Horizon Products can be transacted for the amounts specified
in any of the Modes that are defined as part of the Transaction Correction.
In addition the Allowed Modes field needs to be mapped through to the list of actual
modes that are allowed to simplify the branch processing.
Any failures from the above checks will result in the failing Transaction Correction
being rejected, but the remaining ones being processed as normal.
Note that some of these checks are not currently defined in [TCAIS], therefore a CR
will need to be raised to update the AIS once the detailed design for this function has
been done.
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 87
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
CR to be drafted.
2.5.2.13 POA Data Warehouse
There is no specific requirement on Fujitsu to make the changes in this area. However there are
requirements for us to measure and monitor various SLA and this work is in support of this.
The POA Data Warehouse will need to be aware of all file deliveries that we need to
monitor. Each interface needs to be considered separately in the following
subsections:
= POLFS File Delivery (Outbound)
a MIS File Delivery (Outbound)
= CTS File Delivery (Outbound)
= FRTS File Delivery (Outbound)
= HR SAP File Delivery (Outbound)
I 4 : :
a Transaction Corrections File Delivery (Inbound)
2.5.2.13.1 POL FS File Delivery
What is needed here is to report on how many transactions that were harvested into
TPS and aggregated to create the individual sub-files that have been successfully
passed to POL FS each day in time for loading.
In order to measure the delivery, TPS must provide the Data Warehouse with a file of
records in the following format
Value
Name of the file
Deseripti
Source TPS The source of the SLA
Dest PFS The destination (ie: POL FS)
C_Date The Creation date (EOD Date) of the sub-file
D_Date The delivery date/time of successful delivery of the
sub-file
Records The number of originating transaction records that
were aggregated to generate the sub-file
FAD_Code I The FAD Code of the sub-file
Table 28 — POL FS File Delivery Information
In order that this information can be compiled, TPS must record the number of
individual transaction records that have been aggregated to create each sub-file. In
addition, an acknowledgement file must be generated by TPS that confirms the
date/time that each sub-file was delivered to POL FS. This file must be in the
following format:
C_Date The Creation date (EOD Date) of the sub-file
D_Date The delivery date/time of successful delivery of the sub-file
FAD_Code I The FAD Code of the sub-file
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 8€
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.5.2.13.2
2.5.2.13.3
2.5.2.13.4
Table 29 - POL FS File Receipt Information
The Acknowledgement file will be loaded into TPS and joined with the data that has
recorded the number of originating transactions in each sub-file and the resultant data
will be written to the existing (TIP) MIS SLA file that is presented to the Data
Warehouse.
The only changes to the Data Warehouse should be the addition of Meta Data that
defines the new SOURCE and DEST along with the target SLA times to be measured
for Days A through J.
MIS File Delivery
The MIS file delivery measurement will act in exactly the same manner as the
existing TIP File delivery measurement. No changes to the mechanism are expected.
CTS File Delivery
dei d-that-th il-by S t-of the-delins £CTS- Fil
It is assumed that the measurement of the delivery of CTS Files will record the
delivery of the file rather than the delivery of the records within the file.
In order to measure the delivery, TPS must provide the Data Warehouse with a file of
records in the following format:
Field Name” Description
File Id Name of the file
Source TPS The source of the SLA
Dest cis The destination (ie: CTS)
C_Date The Creation date (EOD Date) of the file
D_Date The delivery date/time of successful
delivery of the file
Records 1 We are measuring the delivery of the file
and therefore we can assume that it
contained 1 record that was either
successfully delivered today (100%) or not
(0%)
FAD_Code NULL
Table 30 — CTS File Receipt information
The only changes to the Data Warehouse should be the addition of Meta Data that
defines the new METRIC and RECEIPT_DATE cut-off time along with the target
SLA times to be measured for Days A through J.
The Data Warehouse will need to be updated to accept NULL FAD Codes.
FRTS File Delivery
It is assumed that the measurement of the delivery of FRTS Files will record the
delivery of the file rather than the delivery of the records within the file.
In order to measure the delivery, TPS must provide the Data Warehouse with a file of
records in the following format:
Field Name “T Value Descriptio’
File Id Name of the file
Source TPS The source of the SLA
Dest. FRITS The destination (ie: FRTS)
C_Date The Creation date (EOD Date) of the file
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Page 8¢
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Valu
The delivery date/time of successful
delivery of the file
Records 1 We are measuring the delivery of the file
and therefore we can assume that it
contained 1 record that was either
successfully delivered today (100%) or not
(0%)
Description
FAD_Code NULL
Table 31 — FRTS File Receipt Information
The only changes to the Data Warehouse should be the addition of Meta Data that
defines the new METRIC and RECEIPT DATE cut-off time along with the target
SLA times to be measured for Days A through J.
The Data Warehouse will need to be updated to accept NULL FAD Codes.
2.5.2.13.5 HR SAP File Delivery
It is assumed that
a The data must be made available to HR SAP on a specific date/time of the month
= That there are 2 completely separate measures for each of the two files that must
be delivered.
= That timely delivery of a file to HR SAP is sufficient to meet the SLA 100% even
if the file does not contain content for all branches
a... That-the-CAPO-data for-each-tile-delivery have-b seived-at-least-24
bh, et the-dealinx £ ines ized-bu-}R-SAD
Pi as “i J
if the-CARO-interface-is-withdrawn-then-this-dependeney-cati-b ‘vhs
The TPS System will send each of the files to the HR SAP system and the successful
receipt of an acknowledgement from the remote FTMS Gateway will indicate the
measure of successful delivery.
TPS will send the following information to the MIS system in the existing MIS SLA
delivery file
File Id The name of the file sent
Source TPS The source of the SLA
Dest HRS1 or HRS2 The destination (ie: HR SAP)
HRS‘ is the file delivered to support Braches
held under a separate contract (eg: Tescos)
HRS2 is the file delivered to support normal
Braches
C_Date (00:00 ‘n’ days before the target Hi ifthe receipt of information fi
delivery date (where ‘n’ is defined by GAP is later-than-this-time, then this. date
a TPS System parameter — currently i_ be the date/time of receipt of file fi
expected to be 3)weekend.ofthe-pay I capo +#
FUR
D_Date The delivery date/time of successful
delivery of the HR SAP File
Records The number of originating transaction I This will always be ‘1’ since we are
records measuring the file rather than the contents
FAD_Code The FAD Code of the sub-file NULL. FAD Code is not relevant
+8 __ Will be removed ifne-CAPO flow
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Table 32 — HR SAP File Delivery Information
New meta data will be required in the Data Warehouse that measures successful
delivery as being within 72:00 hours + 21:30 hours of the C_date.
Note that should the TPS System Parameter controlling how early the file generation
process is to be run be changed, then the Data Warehouse measure will need to be
changed in line with it.
The Data Warehouse will need to be updated to accept NULL FAD Codes.
2.5.2.13.6 SAPADS to MIS File Delivery
The requirement for this has been removed and so the rest of this section has been deleted.
2.5.2.13.7 Transaction Corrections File Delivery
The existing mechanism for writing acknowledgement requests to the counter
following the delivery of inbound data will be used to measure the delivery of
Transaction Corrections. The acknowledgement agent will then harvest confirmation
of receipt of the data into OMDB and this information will be transferred to the Data
Warehouse where the performance will be reported. No changes are required to this
existing mechanism.
The TPS system will present the following metrics to the Agent Loader process in
order to facilitate the measurement
Metric This defines the type of data being loaded (le: Transaction Corrections). The value
for this will be ‘T001’
Receipt_Date I This is the date/time that the data was made available to TPS.
Table 33 — Transaction Correction Metrics
The only changes to the Data Warehouse should be the addition of Meta Data that
defines the new METRIC and RECEIPT_DATE cut-off time along with the target
SLA times to be measured for Days A through J.
2.5.2.14 TPS Host
A number of changes are required here:
m Since the Transactions for dummy Settlement Products will now be harvested in
order to support the POL FS Information flow, then it will be necessary to
explicitly suppress this data on the flow to OpTIP. This is done in the same way
as on the POL MIS flow (see section 2.5.2.7)
a The new events being harvested by the TPS Harvester (see Table 27 in
section 2.5.2.4) must not be passed through to OPTIP. Therefore the process that
generates the file for OPTIP needs to suppress those events should they be
harvested.
a The Seeth +Fransactions_that - being -harvested-inte EP: 4d to-b
S) ae the. +9-OPRTIP—Thisis-alse-a ; it +he-MIS-feed-and
PPI ¥ ‘¢ rf
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 91
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= In order to reduce the number of TPS Harvester Exceptions, which will result in
failures to deliver data to POL FS, a review is required of the constraints on the
TPS Harvester Interface tables, thus allowing some Transactions that are currently
handled as exceptions through to the main TPS system for processing.
It is proposed that the following constraints are removed at point D in the
migration process (see also section 2.6):
o That CAP and BP are greater than zero
Further constraints that can be relaxed may be identified as more detailed design progresses.
These will be captured in the HLD.
It will not be possible to relax all constraints on the TPS Harvester interface
tables, so this means that the Transaction Summarisation Function will need to be
able to handle such cases (see also section 2.5.2.8). Since the current failure rate
is very low (about I per week), it is proposed that this change to the constraints is
done as part of the switching of the interface from OPTIP to POL MIS thus
avoiding the need to filter out such transactions from the flow to OPTIP.
This has the effect of potentially increasing the number of failures in transaction summarisation
during the period when data is being sent to POL FS and to OPTIP, however given the expected
frequency at which such problem occur, this should be OK operationally,
See also section 2.6.3.1.1
a TPS is involved in a number of reconciliation processes. In general, these should
continue as they are [BT059]. Specifically:
a The APS Transactions should be generated as at present for passing to the
APS reconciliation system
co The checks on the Branch Reconciliation Totals generated at EOD should
continue
May need to make some changes here so as to support end to end reconciliation from the counter
to the POL FS feed.
However the calculation of the “mini cash account” to reconcile against the
Branch’s Cash Account summaries can be removed from the code. There is no
longer a requirement to support this functionality during the early stages of Impact
R3 id-be-stopped-once the feed to-OPTIPG d.—In-particularthe-data
& he-branch-will-ne-t be-available-atthis-peint-lers £
Si +P
a Changes are required on the current interface of Bureau transactions to FRTS,
since the control file includes summaries based on CAP.
Note that the transactional data flow to the POA Data Warehouse remains unchanged.
Similarly, the CTS file will continue to be delivered unchanged, though it will no
longer be co-ordinated with the other OPTIP files.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 92
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.6
2.6.1
2.6.1.1
MIGRATION CONSIDERATIONS
The requirements for migration require further work. This section has made a number of
assumptions as to how it will work. Should these assumptions be incorrect, then CRs will be
raised when a fill migration design has been agreed.
There are a number of assumption in this section which are recorded in section 8.4
Migration Overview
Figure I is adapted from [CDBT] and shows a timeline for the different aspects of
migration. This diagram has been expanded in [MIGSTGY] to include POL FS
activities as well, however the simpler diagram is sufficient for this DP.
Point 10 Point 20 Point 25 Point 30 Point 40 Point 45 Point 50
SAPHR
From CBDR OPFip
2 EBDB
Time
In ALL feanches
aware Migration
POLES
cBDB
Figure 6 — Migration Timeline
Migration will occur over a period of time. The key migration points are:
= Data Centre Migration (Point 10)
= Counter Software Upgrade (Point 20)
= Switch to new POL FS Interface (Point 25)
= Running the Final Counter Cash Account for CBDB (Point 30)
= Switch of TMS feed of Transactions from OPTIP to MIS (Point 40)
= Delayed Counter Software Upgrade (Point 45)
= Upgrade of Counter processes to operate Branch Trading Statement (Point 50)
[BT114]
These are described in more detail below.
Data Centre Migration
This will be the normal upgrade process that takes place over a single weekend. It
will ensure that all the Data Centre Systems are able to support the new functionality,
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
while also retaining support for the existing functionality, prior to it being switched
off.
Once this migration has taken place, it will be possible to receive the additional
Reference Data required to support the new functionality from NRDS and to
distribute it as required.
Tt is expected that NRDS will have been upgraded prior to this point so that the new
Reference Data can be prepared, thus enabling the new Reference Data to be
distributed as soon as the Horizon Data Centre is migrated. However until this point
the pre-S80 interface will be supported by NRDS in delivering Reference Data to
Horizon.
2.6.1.2 Counter Software Upgrade
This will follow the normal pattern for a Software rollout and include some initial trial
Branches to ensure that the process runs smoothly, prior to rolling the software out to
the full estate. Some of the new functionality will become active as soon as the
Branch is upgraded, while other functions will be controlled by a Soft Launch
mechanism and so be activated at a later time.
2.6.1.3 Switch to new POL FS Interface
In order to support a possible pilot of POL FS for full Impact R3 functionality, then it
is necessary to continue supporting the Impact RI interface to POL FS until the pilot
is complete. This allows TPS to support both flows in parallel. This delay in
switching the interface also allows time for the new Summarisation Reference Data to
be distributed from NRDS to Horizon.
Once the pilot is complete it is then necessary to switch to using the Impact R3
interface prior to the new data being generated.
This point is chosen so as to ensure that it occurs before any Branches are trading in
the CAP following the CAP that triggers Point 30. It is Post Office Ltd’s
responsibility to ensure that no Branch is running too many CAPs ahead of where it
should be. It is expected that setting this point 2 weeks before the scheduled Point 30
is sufficient to achieve this.
Should any Branch have rolled over into the CAP following Point 30 prior to this
point, then the Opening Figures and initial transactions for that Branch are likely to be
incorrect and will have to be manually corrected. It is Post Office Ltd’s responsibility
to make any such corrections in POL FS.
2.6.1.4 Running the Final Counter Cash Account for CBDB
It is a requirement of the POL FS designers that the switch over of the accounts from
CBDB to POL FS occurs at a single point in time, which coincides with a POL Month
End. [BT003] A specific Cash Account Week will be identified such that once that
Cash Account has been produced, all subsequent transactions will be summarised and
passed to POL FS. In addition a special migration flow of data will be required to
pass the Closing Figures from that Cash Account through to POL FS as Opening
Figures for the corresponding accounts.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 94
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
POL will be required to ensure that all Branches generate this Cash Account on time.
This will ensure that we have a clean cutover.
There will also be some minor changes to the menu structures, particularly under the
Housekeeping menu at this point. Other than that, this should be invisible to Branch
staff.
As far as the Data Centre is concerned, this is the point at which the new Impact
Release 3 data is first sent to POL FS. #-i pected-that-the-intert: ibs
switched-ft the-1. t-Reb 4 -fe t-to-th } t-Rel. for t-a-few
Ps P 2
a of +e-thi th. +h. at i:
yep i ?
There may need to be an earlier pilot of a small number of branch’s data to a test POL FS.
Should such a pilot be supported, then there will need to be a period of a few days between
ending the pilot and switching to the new interface to POL FS, The design will only support such
a pilot while we are passing Live Data to the Live POL FS using the Impact R1 interface.
We have only provided for supporting the pilot in our development costs. No operational or test
support has been included since the migration strategy is not clear.
Assumption recorded in section 8.4
2.6.1.5 Switch of TMS feed of Transactions from OPTIP to MIS
Once all Cash Account data from the final cash account has been successfully passed
to OPTIP, the Transactional flow to OPTIP can be discontinued and replaced by the
new flow to MIS.
This should be invisible to Branch staff.
This point also indicates that migration to POL FS is complete, so process used during
the migration can be stopped at this point. From this point onwards, the Data Centre
is operating the complete Impact R3 functionality.
Delayed Counter Software Upgrade
This point is included as a potential contingency for fallback should there be problems in keeping
to the development schedule.
It is not considered further in this document.
Should such a contingency be invoked, then a “sanity check” exercise is required to ensure that
no inconsistencies occur.
Should the counter rollout be delayed, a number of changes are required to the
migration strategy. The main one being that all functionality identified below as
being activated at Point 20 will, in fact be activated at Point 45 instead. It also means
that there will be no S80 functionality at the branch to support Point 30, and so this
will need to be achieved as a Reference Data change on a given effective date (ie just
after midnight on the day after Point 30).
This is not as good as what is proposed below with a “Rollover Triggered Soft Launch”, and in
particular may introduce problems for a Branch that doesn’t complete its rollover witil the
Thursday morning since Error Notices and Suspense items will not be available. There may also
be problems for any branches that rollover early and then use the Error Notice facilities in the
new CAP on Wednesday evening, since these would need to be passed to POL FS!
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
The acceptability of this approach will need to be agreed with POL.
2.6.1.7 Upgrade of Counter processes to operate Branch Trading Statement
At some later time the branches need to switch to using the new processes. This can
be done by different branches at different times, thus allowing a pilot to be supported.
However the changes in process at any branch need to occur immediately after rolling
over into a new Cash Account Period.
This will be achieved by introducing a new type of “Soft Launch” which will be
triggered as part of the rollover process to a specified Cash Account Period. This is
known as a “Rollover Triggered Soft Launch”.
2.6.2 Mapping of Changes to Migration Points
Table 34 shows at which phase-of migration point each aspect of the functional
changes described in section2.5 will change. The points are described in
section 2.6.1 above.
25.1.1.4 Extending Transaction 10/
Retention 20
25.1.1.2 Stock to be handled by Volume I 50
rather than by Value
25.1.1.3 Merging of Value and Non- Post See section 2.6.3.2.3
Value Stock 50
2541.44 Changes to Suspense Products I 30 Also Error Notices and Vouchers are to be
and — I disabled at this point
50 There are also some new Housekeeping
functions to be introduced at the same time.
However, Local Suspense is not introduced
until Point 50.
25.1.1.5 Change APS to use EPOSS 20
Core
25.1.16 Settlement Transactions 10- This is a ref data change and so needs to
25 happen at a fixed time. It should be OK to do
this at any time between 10 and 25 and
shouldn't require the counter to be at S80.
2.8.1.2.1 Changes to Cash Declarations 20
2.5.1.2.2 I Reporting of Cash Variances _I 20
2.5.1.23 I Processing of Cash Variances __I 50
25.1.24 Stock Declarations and 50
Variances
25.4.2.5 Non-Value Stock Declarations 50 This is removing functionality
2.5.1.3.1__I Remuneration Reporting 20
2.5.1.3.2 _I Office Snapshot Report 50
2.5.1.3.3 I Suspense Account Report 20
25.41.34 Counter Weekly Redeemed 50
Savings Stamps Report
2.5.4.3.5 APS Transactions Report 20
25.1.3.6 Event Log 20 Though some new events will not be
generated until point 50
25.41.37 Other reports affected by 50
changes to Stock Processing
25.138 I Reprints of Reports 50
25.1.3.9 Reports proposed to be 50 Some may go at 20
removed
25.13.10 I Weekly Reports 50 May be able to do tat 20
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
Functional
2.5.1.4.1__ I Changes to Rollover processing I 50
2.5.14.2 _I Branch Trading Reports 50
25.1.4.3 Remove Extended CAPs 20
2.5.1.6.1 Removal of LFS Weekly Stock 10- This is a ref data change and so needs to
Reporting functions 30 happen at a fixed time. It should be OK to do
this at any time between 10 and 30 and
shouldn't require the counter to be at S80.
Pet agesting doing this inthe LF:
Harvester.atPomt40.
26.1.5.2 I POLFS Summarisation at NA I This functionality-can-b aby End
Counter Dating the Ret data that invokes-this
function-through t-any-time-betv
points 40-and-50
Note that this is dependent on“Simplficat
$EROSS-R iliation’-tak
¥.the.functionality,-oth it-could-b
removed.at Pomt-25.
No Change required
25.1.5.3 Maintenance of Office 20
Variances Persistent Object.
25.154 I LFS EOD functionality changes IN/A I No Change required
to handle changes in Cash
Declarations
25.4.5.5 Simplification of EPOSS Post This functionality can be removed by End-
Reconciliation 40 Dating the Reference Data that invokes this
function through CAS and introducing the
Reference Data to invoke the replacement
function at the same time at any time
between points 40 and 50
2.5.1.5.6 Protection against lost data 20
2.5.1.6.1 Logon Checks: ONCH run for 20
“yesterday”
2.5.4.6.2 Logon Checks: Stock Unit in 50
correct Trading Period
5.4.6.3 Logon Checks: Outstanding 20
Transaction Corrections 50
25.1.7 Process Transaction Correction I 50 This has to occur at point 50 otherwise it will
be expensive to make the changes to support
TCs on a CAP report
Assume this is OK
25.1.7.3 Reporting on Transaction 20 Can't introduce this before Transaction
Corrections 50 Corrections are supported.
2.5.2.4 RDMC 10
2.5.2.2 LFS 490 eecs te be.doneiaiariaensure inate data
10 i a
in-particular-it must be after “R. Lot:
Stock R f "
Now that the change is being managed by
the LFS Harvester, this can be done at Point
10.
523 B PADS TE i WA
25.24 TPS Harvesting 40
25.2.5 DRS Host 40 Changes to the DRS workstation may need to
be delayed.
PGL-to-consider-this-
Assumption is that this can be done at the
same time.
2.5.26 APS Host vA No changes
25.2.7 Generate MIS Info 40
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Printed on 22/11/2002 2:20:00 by Gld
Page 97
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Functional
25.2.8 Transaction Summarisation 25 This needs to be delayed until point 25, to
allow time for the Reference data to be
distributed from NRDS.
Note that if a pilot is to be supported, then
this will need to be started earlier.
‘Accept CARO Data NA
Generate HR SAP Info 25
Generate POL FS Info 25
and
30
2.5.2.12 Transaction Correction 25
2.5.2.43 POA Data Warehouse 16
25.214 I TPS Host 10 The main changes take place at point 10,
and however some of the changes to the
40 constraints on the Harvester Interface tables
should be left until point 40.
22 FIMS Services 10 All of these should be configured at Point 10.
The move to them should be soft via changes
to TPS environment variables.
Table 34 — Migration of Functions
2.6.3 Specific Migration Developments
This section has been restructured and so no attempt has been made to explicitly mark deletions.
New text is marked where possible.
As can be seen from Table 34, a number of migration activities need to take place
other than as part of the normal Software introduction changes.
These are:
= Data Centre Changes
o Switch on Transaction Correction Feed
a Switch the POL FS Feed from Impact Release 1 to Impact Release 3 interface
and generate Opening Balances where required
o Switch of TMS feed of Transactions from OPTIP to MIS
o Generate HR SAP Info
= Counter Changes
co Process the final cash account for CBDB
co Upgrade of Counter processes to operate Branch Trading Statement
co Merging of Non-Value and Value Stock
a Support of nRDS supported Settlement Products
co Support for Quiescent Rollover
Need to consider the impact on MiMAN.
These are described further below.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9€
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
2.6.3.1 Data Centre Changes
The simplest way to describe the specific migration considerations is to go through
the Migration Points in turn
2.6.3.1.1 Point 10
At this point all new Data Centre processes are delivered and a Maestro scheduled is
produced that will run all the relevant proce: However some processes will be
designed such that they will test TPS System Variables to decide at which point in the
migration process the system is and where appropriate exit without doing any further
processing. This approach avoids the need to provide and test a number of different
Maestro schedules during the migration period.
2.6.3.1.2 Support of a POL FS Pilot
We are required to support a pilot of the migration to POL FS.
However there is no explicit numbered require this
Should such a pilot be required, then it will need to operate as follows:
= During the Pilot the existing S60 data flow to POL FS will continue as normal
ws In addition, the Initial Summarisation process and POL FS Summarisation
processes (described in sections 2.5.2.8.1 and 2.5.2.8.2) will be activated, together
with the POL FS migration processes described in section 2.6.3.1.3 to provide the
psuedo-S60 and Opening Figures flows to POL FS.
The TPS System Parameter that defines the Point 30 CAP will be set to the “Pilot
Point 30 CAP”
= Other tasks that are due for activation at Point 25 will not be run, thus ensuring
that there is no data being produced for HR SAP
= Once the pilot is complete, then any persistent data generated in POL FS as part of
the pilot needs to be cleared out and the various TPS System Parameters reset to
the correct values.
2.6.3.1.3 Point 25
This is the point where a lot of the new functionality starts to become active.
Specifically:
s Transaction Correction Processing is activated
However it is unlikely that any Transaction Correction files will be received until
some time later. Any alerting produced as a result of Transaction Correction Files
not being received need to be suppressed / ignored at this point.
How is this to be achieved?
Do we raise such alerts?
a The interface to POL FS is switched from the Impact Release 1 interface to the
Release 3 interface.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 9¢
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= Transaction Summarisation within TPS starts at this point. However in order to
support the migration requirements, the Initial Summarisation (described in
section 2.5.2.8.1) will produce separate summaries for each CAP within a Branch
and Trading Date.
a The normal Summarisation processes for POL FS and HR SAP (described in
sections 2.5.2.8.2 and 2.5.2.8.3 will restrict themselves to those initial summaries
where the CAP is greater than that defined as triggering Point 30, or as being
NULL (indicating that the branch has passed Point 50)
Due to still having the full TPS Harvester constraints until migration point 40, there will be an
increased likelihood of Summarisation failures during this early period.
Assumed to be acceptable.
« From this point onwards, HR SAP summarisation and File generation can operate
in “final form”.
= A separate POL FS Summarisation Process is provided that will summarise all
Cash and near-cash data from the Initial Summaries which have a CAP of less
than or equal to the CAP that triggers Point 30 and generate an appropriate
balancing transaction, thus ensuring that the Impact Release one subset of data
continues to be passed to POL FS at this time. In order to support this a special
set of “S60 mappings” will be defined as standing data within POL FS. This
mapping will be based on [POLFSMAP].
= In order to provide Opening Figures for POL FS, a further process is provided that
will take details from the Cash Account produced at the end of the CAP that
triggers Point 30 and generate the Opening Figures for all Stock, Suspense and
Discrepancy products other than those such as Cash and Cheques which are
already known to POL FS from Impact Release 1.
= Since CBDB is not concemed with any Cash Accounts beyond Point 30, the TPS
function that passes Cash Accounts through to OPTIP will suppress any Cash
Accounts for a CAP greater than Point 30. This is necessary since Point 40 is
likely to be over a week after Point 30.
2.6.3.1.4 Point 40
This is the point where a migration from CBDB to POL FS can be considered to be
complete from a Horizon Perspective.
Specifically:
= The migration process for POL FS (described above) can be withdrawn
« Switch of TMS feed of Transactions from OPTIP to MIS
2.6.3.2 Counter Changes
2.6.3.2.1 Process the final cash account for CBDB
In general this phase should have minimal impact on the branch processes. However
there are some changes required to the menu structures at this point. These changes
will be triggered by a new type of Soft Launch which is invoked as a result of the
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Stock Unit or Branch rolling over into a specified CAP number defined in the Soft
Launch Reference Data. H-is-expectedthatthe+ toa Pod ager tise
This CAP will be flagged as requiring a Rollover Triggered Soft Launch quiescent
voHever (see section 2.6.3.2.5). This will ensure that the soft launch functionality is
triggered correctly.
It is expected that the same CAP will trigger this change across the full estate.
The changes that need to happen at this point are:
= The Permissions should be changed on the Housekeeping menu to restrict access
to Managers / Supervisors etc.
Since this is a global Reference Data change and it would be simplest to do this at
a fixed time across the estate. Therefore, a date will be chosen when most
branches have moved to S80, but prior to point 30. NB it shouldn’t matter if there
are still some branches on $75.
Provided branch staff are expecting this then there should be no problem, since it is anticipated
that only Managers / Supervisors should be attempting to use this functionality anyway.
Assumed OK.
a The existing Error Notice, Cash Shortage / Surplus and Vouchers buttons should
be removed from the Housekeeping Menus since these functions are no longer to
be used.
Note that any amounts held in Suspense Accounts that are removed at this point
will remain in Suspense until Transaction Corrections are introduced at Point 50,
and POL FS generate an appropriate Transaction Correction to clear the Suspense
item.
= Buttons to support the new “local write off’ products should become available on
the Housekeeping Menu (see section 9.3)
2.6.3.2.2 Upgrade of Counter processes to operate Branch Trading Statement
This is where the main changes occur at the Branch. Again it is triggered by a Soft
launch product linked to a given CAP. It is expected that in this case, different
branches will migrate at different CAPs.
The process is expected to operate as follows:
a Each Stock Unit will rollover into a new “CAP” following the pre-S80 processes.
As part of this rollover a new flag needs to be included in the Stock Unit
Persistent Object to indicate that this Stock Unit is now operating in Branch
Trading Period mode rather than Cash Account mode. This flag is needed so that
other processes such as the TPS Harvester can tell in which mode this Stock unit
is operating.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
This CAP will be flagged as requiring a Rollover Triggered Soft Launch quiescent
rollover (see section 2.6.3.2.5). This will ensure that the soft launch functionality
is triggered correctly.
= When all Stock Units have rolled over in this way (including inactive Stock
Units), the Office can then be rolled over into the new CAP and produce the final
Cash Account Report.
= From this point onwards, all reports will be in their new format and any
functionality identified as “Point 50” in Table 34 will be made available. In
particular the buttons used to invoke the non-value stock functions will be
removed.
2.6.3.2.3 Merging of Non-Value and Value Stock
This can be seen as a product introduction / change process. It is not expected that
any changes in functionality are required, however there will be changes to Reference
Data. Further analysis may be required on a product by product basis to sort out the
exact consequences.
This should be handled as an OBC change once all branches are operating on the new
processes. Any changes other than those handled through the normal OBC process
are currently out of scope. [BT055]
This is discussed in section 2.5.1.1.3 and there are some outstanding issues to be resolved before
I can consider this further.
Assumed out of scope.
2.6.3.2.4 Support of nRDS supported Settlement Products
There is probably no migration development required here as such, however there is a
need to identify exactly how this migration is to take place.
The current state is that we have Type C Reference Data that defines the current
Settlement Products with appropriate Product Mappings. We also have Product Mode
Reference Data that identifies the Settlement Products.
Moving to Type A Reference data may give us problems in that the existing Type C
Reference Data will be using a particular suffix, and we need to ensure that the new
Type A Reference Data will use an appropriate suffix and not clash and we have a
mechanism to end date the old Reference data and start-date the new reference Data
smoothly. There should be no need to co-ordinate this in terms of CAPs since both
products should have identical mapping s and so will be treated identically.
2.6.3.2.5 Support for Rollover Triggered Soft Launch
A new technique is introduced, that of a Rollover Triggered Sofi Launch. What this
means is that once a Stock Unit has rolled over into a specified CAP, the soft launch
mechanism is invoked so as to update the Horizon Menus to reflect the changes that
are required at that point.
It is proposed that this will operate as follows:
= The CAP for which this rollover is to apply is defined in Reference Data using the
standard Soft Launch control mechanisms.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
m Whenever a Stock Unit completes a CAP rollover or a user logs in or is attached
to a different Stock Unit, the Soft Launch mechanism is invoked to ensure that the
correct Horizon Menus are displayed according to whether the Stock Unit is
operating before or after the “target CAP”.
Full details how this is achieved are described in [MIGOVW].
Need to define how we are to handle the case where multiple Soft Launch products are made
available with different target CAPs in the same Branch.
POL have indicated that we should take the earliest one.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 3 -
Data Model
3.1 GENERAL
Figure 1 shows the interfaces between Horizon and other components involved in
Impact Release 3 and the breakdowns in Figure 2 to Figure 5 show the interfaces
between the components of Horizon. Figure 5 also shows some data stores. These
Interfaces and Data stores represent the Data Model. They can be divided into
External interfaces, Internal interfaces and Data Stores:
= External Interfaces
These are described in section 3.2
co Reference Data (section 3.2.1)
a Client Access (out of scope)
co Bank Statements (out of scope)
co Transaction Corrections (section 3.2.2)
co SAP ADS Transactions and Summaries (out of scope)
o Ledger Entry Information (section 3.2.4)
a TMS Info from Clients (out of scope)
co Remuneration Information (section 3.2.6)
co Management Info (section 3.2.7)
co CTS File (section 3.2.8)
= Internal Interfaces
These are described in section 3.3
co RDMC to Branch: Reference Data (interface unchanged — see section 3.5 for
details of content changes)
co RDMC to TMS: Reference Data (interface unchanged — see section 3.5 for
details of content changes)
co Branchto TMS: Transactions (section 3.3.1)
co TMS to Branch: Transaction Corrections (section 3.3.2)
co Within Branch: Transactions (section 3.3.3)
= Data Stores
co Summary Store (section 3.4.1)
o Variance Persistent Objects (section 3.4.2)
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
o Stock Unit Summary for Branch Trading Report (section 3.4.3)
Finally section 3.5 describes the dependencies on Reference Data.
3.2 EXTERNAL INTERFACES
3.2.1 Reference Data
Changes will be required to [RDSAIS] to include the changes to Reference Data
described in section 3.5.
3.2.2 Transaction Corrections
This is a new data flow from POL FS to Horizon giving details of Error Notices that
are to be distributed to the branches to be actioned.
The interface will be an overnight file from POL FS containing all the Error Notices
to be distributed for that day. Feedback will be provided to POL FS via transactions
in the normal Ledger Entry Information flow (see section 3.2.4).
The interface is formally defined in [TCAIS].
fuinal-draf-avadable.
yh is_probah ne <0 worker
3.2.3 SAP ADS Transactions and Summaries
POL have dropped the requirement for this, so remainder of section has been deleted without
being marked as such.
3.2.4 Ledger Entry Information
This is primarily an expansion of the summarised financial information being passed
to POL FS at RI to cover all Horizon products rather than just cash and near cash
products. However the details format of the data has changed.
The interface is formally defined in the AIS [POLFSAIS].
3.2.5 TMS Info from Clients
POL have dropped the requirement for this, so remainder of section has been deleted without
being marked as such.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
3.2.6 Remuneration Information
This is the interface to HR SAP and is formally defined in [HRSAPAIS1] and
fARSAPAIS2} which is based on [HRSAPAIS].
At the time this DP was originally produced, [HRSAPAIS 1] was not available and so
a number of assumptions were made about the interface (documented below). Now
that [HRSAPAIS1] has been produced, they have all been confirmed as correct:
In-the-ab: £-an-AIS—the follow: ti de:
s 5 S F °
= That data will be provided one or two months in arrears as specified in the
summarisation Reference Data.
= Two separate interfaces will be used:
o Aninitial feed for “multiples” (about 250 branches)
a A full feed for other sub-post offices (about 16,000 branches)
Reference Data will be used to identify in which feed the data for a branch is to be
included. Note that some branches (Directly Managed Branches) are not included
in either feed.
= There is no requirement to migrate a branch from one feed to the other.
= That any migration to the target situation of data being passed across as a single
feed, 1 month in arrears is out of scope of Impact S80 and will be handled by a
separate CR, though the design should take into account the fact that this is likely
to be required in future.
= Itis assumed that a Calendar will be provided via Reference Data defining the cut-
off dates for summarisation and also the dates at which files will be sent to HR
SAP.
a It is assumed that the mapping of products to CTTs will be provided by Reference
Data. This mapping will also indicate whether the summary is to be passed to HR
SAP one or two months in arrears.
u It is assumed that it is acceptable to use the Reference Data currently available at
the Data Centre at the time the Transaction is harvested available—for
summarisation is—to—be—used for the Summarisation and that there is no
requirement to maintain historical mapping data associated with the time that the
transaction was actually carried out should that be differed (eg following non-
polling)
= It is assumed that not all transactions will be mapped to a CTT, and so no
checking is required regarding transactions that are not mapped to any CTT
number as part of the summarisation process.
Adthough-there-are-twe-separate-AdSs-{fHRSAPAISH and HRSAPAIS2})-the-file
f is-id L-in—both --The-differene rely--in-ter f-the-fil
1 the identifieation-fields-in-the-file-head
Th head ‘daxhich- v1 treltetals—te -heek Hh. +3 ft
Pi ¥
file.
Th: felt jt: @ f¥detail dg—Fhi d. tai} de a +h
duct-seld—by-—in-a—b: h-in—a—s' ci fied tf Eoereach- sord—thi is—eiths
lis J Pe Z
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Vek 44. +he-tetal bereft 44. £5 det). Val 4. +} tetal
ree S s P I the
zal fthe-+ ti. fe roduct}. ; eG; eth
The—fi 4 Kreis S, pitts d—Variable-CS\ is b—field. a
ted-b: d-each-field-is-of-variabletenath
P y sth:
3.2.7 Management Info
The starting point for this is the current OPTIP AIS and is formally defined in
[TIPAIS]. A new AIS wilt-be has been produced defining this interface [MISAIS].
The following summarises the main changes from [TIPAIS] to [MISAIS]:
Ther beret. 2 he-ch or de
Pp ‘t >
= Changes due to removal of the Cash Account
The CAP and BP fields will be retained, however the values will be null once the
branch has moved from Cash Account to Trading Period (point 50 in the
migration — see section 2.6).
= Additional Transactional Information
There are a number of the more recent “specialised” transactions where all that is
passed to OPTIP is the basic EPOSS Transactional Data. Sections BS and B6 of
[MISAIS] define the additional data required.
It has also been agreed that the Quantity field can be extended to accommodate
Bureau Quantities rather than having to hold it as an additional field.
= Additional Event Information
Section B7.2 of [MISAIS] identifies some additional events that are to be passed
through to MIS. This is also defined in Table 27.
3.2.8 CTS Files
The starting point for this is the current OPTIP AIS and is formally defined in
[TIPAIS]. A new AIS has been produced defining this interface [CTSAIS].
The CTS file is currently delivered as part of the current OPTIP set of files as a
separate file. The file itself will remain unchanged.
3.3 INTERNAL INTERFACES
3.3.1 Branch to TMS: Transactions
This is the current flow of data to the TPS Harvester.
It may need some minor changes.
3.3.2 TMS to Branch: Transaction Corrections
This is a new data flow.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
There are two aspects to this:
= The Oracle table structure used in TPS to make the Transaction Corrections
available to the Agent
This is documented in [TPSOTHER]
= The Attribute Grammar format used to hold the Transaction Correction in Riposte
This is documented in [CTRDEC]
Low level detail removed without marking.
3.3.3 Within Branch: Transactions
This is the current recording of EPOSS Transactions.
3.4 DATA STORES
3.4.1-___Summary-Store
This-wilt-be-defined-in-the HED.
I Low level detail removed without marking.
3.4.3 Stock Unit Summary for Branch Trading Report
Move to [CTRBAL].
However it isn’t there
Following a Stock Unit Rollover, a Persistent Object needs to be written containing
Summary Information from the Balance Report to support the Branch Trading
Statement. This will be held in a Persistent Object in a Collection called
“SUSummary” with an ObjectName of “SS” (where SS is the Stock Unit Name).
The Data to be included is:
= Carried Forward Figures for:
o Cash
co Other MOP
o Other Stamps
co ForEx
Also need Brought Forward Figures, but presumably they can be obtained by picking the Carried
Forward figures up from the previous Trading Period Rollover.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services
POL00038916
POL00038916
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Total for Trading Period of:
Receipts value Total (excluding the following 6 items)
Remittance In (Cash) Total
Remittance In (Other Stamps) Total
Remittance In (ForEx) Total
Transfers In from Suspense
Transfers In from other SUs
Transfers In from Local Suspense
Payments value Total (excluding the following 6 items)
Remittances Out (Cash) Total
Remittance Out (Other Stamps) Total
Remittance Out (ForEx) Total
Transfers Out to Suspense
Transfers Out to other SUs
Transfers Out to Local Suspense
Transaction Corrections Accepted
oo00000000500000
This isn’t currently part of the Balance Report, but is part of the BTS.
o Nett Cash Adjustment
3.5 REFERENCE DATA CHANGES
The following identifies the areas in which Reference Data will need to change. The
details will be covered in [RDMCHLD].
Support of “Stock by Value”
o Tertiary Mappings
Note that the opportunity has been taken to allow Tertiary Mappings and also
Primary Mappings to be provided from NRDS through the Type A Reference data
interface.
‘sumption recorded in section 8.4
= Include “Settlement Products” as part of normal Type A Ref Data.
= Inclusion of optional “loss price” on Product Reference Data for stock products.
2 Reles-to-be-p pted-att da +h reutst: dite Ee
= Ref Data to support Summarisation for POL FS and also mapping Articles to
Products for TCs
= Ref Data to support Summarisation for HR SAP including list of relevant
branches and identification of CTT number to be used for CAPO data.
Reference Data will define the mappings from Horizon Products to CTT numbers
and also whether Value or Volume (either sum of Quantity or Number of
Transactions) or both are required.
a—Ref-Data-to-support-Identificati £ Transaction Data fromthe SAP-_ADS feed
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 1C
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= Various Calendars
a Branch Trading Periods and allocation of branches to their calendar
co HR SAP Periods
co HR SAP Delivery dates
= Introduce Local Suspense Account Product
= Introduce a number of new Modes
= RDS to provide mapping info as Type A Ref Data
= Soft Launch Reference Data, and in particular the ability to link a soft launch to a
given CAP.
HORIZON POL FS
Product >>} article
C Dummy
Quantity (O)
“Article POL FS.
Mode” [2% ¥ I account (0)
[Settlement Type (O)
[+1 edger Indicator (O)
HORIZON [-——Summarisation
Mode
‘Transaction Reference (O)
Movement Type (0)
Figure 7 — Ref Data Model for Articles
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 4 -
Environmental Constraints
4.1 GENERAL
This chapter is concerned with the Technical (as opposed to Application) Interfaces.
Information is also included about the operational schedule, SLAs and Volumes
associated with the interfaces, which although included in the AISs is more relevant to
this part of the document.
There are a number of aspects to this:
__Technical-Interface-fi SAR-ADS
= Technical Interface from NRDS
= Technical Interfaces to and from POL FS
= Technical Interface to HR SAP
= Technical Interface to MIS
= Technical Interface to CTS
These are described further in the following subsections.
Since all of these interfaces are bulk file transmissions and most are from the Horizon
Data Centre to Huthwaite, then they will be formally defined in an update to
[POLTIS].
Assume this is the only TIS needed.
Assumption recorded in section 8.4
4.2 TECHNICAL INTERFACE FROM SAP ADS
POL have dropped the requirement for this, so remainder of section has been de d without
being marked as such.
4.3 TECHNICAL INTERFACE FROM NRDS
The existing technical interface will remain unchanged.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
4.4 TECHNICAL INTERFACES TO AND FROM POL FS
The technical interface that was introduced as part of Impact Release 1 will remain
unchanged.
However the volume of data will be increased significantly (since now all transactions
are summarised rather than just cash and near-cash movements) and there is a need to
measure delivery times to support SLA measurement (see section 5.5).
a These files need to be audited on despatch and receipt
4.5 TECHNICAL INTERFACE FROM EDS
4.6 TECHNICAL INTERFACE TO HR SAP
This is a new interface.
It is assumed that we will send this file to the remote FTMS Server at Huthwaite.
The following assumptions are made:
= Approx Monthly File Size
0.9mb for the first interface (company franchises) and 30mb for the main interface
= Proposed Operational Schedule
Each month there will be two separate “pay runs”:
o At the beginning of the month to cover the “multiples”
o At the middle of the month to cover the bulk of the branches
Each “pay run” will take place over a weekend. The exact dates for these pay
runs and the range of Trading Days to be included in each pay run will be defined
in a Reference Data Calendar (see section 3.5). Data delivery should be by 21.30
on the Friday preceding the pay run. Data must not be delivered more than a
week before hand. Therefore, to provide operational flexibility and opportunity to
sort out any unexpected problems it is proposed that the file is generated and sent
a configurable number of days en-the-day before the required delivery date-iethe
Fhursday). This will initially be set to 3 days beforehand (ie Tuesday).
For simplicity, this task will be scheduled to be invoked each day, and the first
check that is made is whether there is anything to be run. If not it will exit with a
response indicating that there was no work to do, thus allowing Maestro to by-
pass the remaining work associated with delivering the file.
a See section 5.5 for SLA requirements.
= These files need to be audited on despatch
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
4.7 TECHNICAL INTERFACE TO MIS
Th tw ts-to-this-interfé
SP
= Delivery of Horizon +i MIS
a — Deli ! £-Cash-Centre-Er: tis te-MIS
Beth i. I. +h deli £31, s—h H hy ib. abl +—-di ff¢ +
ti ¢ te-deliveries will be required-each night
a P t =
This is a new interface, however it is effectively the equivalent of the current OPTIP
Interface as defined in [POLTIS]
it-is-assumed-thatve-will-send These files will be sent to the remote FTMS Server at
Huthwaite.
At the time this DP was originally produced, [MISAIS] was not available and so a
number of assumptions were made about the interface (documented below). Now that
[MISAIS] has been produced, they have all been confirmed as correct:
In-the-abs fanAIS_the follows s ptions-ar de:
= Approx Daily File Size is assumed to be the same as for [TIPAIS].
= Proposed Operational Schedule
These will be passed as soon as they are available and should be with MIS at a
similar time to them being passed to OPTIP now (normally before midnight)
o... SAP-ADS-Fransactions
Th. iL. S d. sth. 4 jlable—h. } thes 4 t
d-until-04-00-this-will-b h-later-than-the Herizon-Transacti
= See section 5.5 for SLA requirements
= These files need to be audited on despatch
4.8 TECHNICAL INTERFACE TO CTS
This is a new interface, however it is effectively the equivalent of the current OPTIP
Interface as defined in [POLTIS].
It is assumed that we will send this file to the remote FTMS Server at Huthwaite.
At the time this DP was originally produced, [CTSAIS] was not available and so a
number of assumptions were made about the interface (documented below). Now that
[CTSAIS] has been produced, they have all been confirmed as correct:
dath bs if AIS—the-foll 43 ti de:
o P :
= Approx Daily File Size: Assumed to be the same as for [TIPAIS].
= Proposed Operational Schedule
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
This will continue to be passed across as soon as it is available (usually before
midnight).
= There are no SLAs associated with this interface
a These files need to be audited on despatch
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 5 -
Non-Functional Requirements
5.1 GENERAL
These can be broken down into a number of areas:
Availability
Usability
Volumetrics
Service Level Objectives
Security
These are discussed in the following sections.
5.2 AVAILABILITY
None of the changes proposed will impact on the current systems availability and any
changes should be made in line with current practice, thus ensuring that systems
availability is not impacted.
5.2.1 Resilience
No special considerations are required for Resilience. Existing mechanisms within
the Host systems and agents will provide the necessary Resilience.
5.3 USABILITY
The changed counter processes will conform to the existing systems and any text
displayed to the clerk must be agreed with Post Office Ltd.
5.4 VOLUMETRICS
Volumetrics will be described in the relevant AISs. [VOLS] will be updated to
include the volumes associated with the new interfaces.
A key change here is the increased data retention period at the counter and the
Correspondence Server and-also-the-implicati £-handling-Stock-sales—as-tw
linked-4 +i ther-th: {see-section-2-S-+12).
5.5 SERVICE LEVEL OBJECTIVES
There are a number of aspects to SLAs:
= New/ Changed SLAs
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= SLAs being removed
= Unchanged SLAs
= Migration Implications
These are discussed in the following sections.
5.5.1 SLA Changes
I This section has now been updated to match Attachment 3 to [CT].
Section 11.3 of [CDBT] says the following about Service levels:
a LFS — remains unchanged
a TMS - POL-FS ~ to be consistent with that being developed for S60
a Transaction Correction — to be like Planned Orders — 95% by 08.00 and 100% by
24.00 — both Day A
= TMS ~MIS (SAP ADS data) — by 05.00
Note that this data flow has been withdrawn as a result of {CDBTCRI] and so no SLT is
required.
= TMS - MIS (Horizon data) — by 03.00
= TMS-—HRSAP 100% by 21.30 on Friday preceding weekend of pay run
= TMS (CTS file) —no SLA
Each of these statements is discussed separately in the following subsections.
NB-there-is-ne-Si-F-on-th ipt-of-the-file-from-EDS-
In addition we will monitor the delivery of files to FRTS for completeness.
5.5.1.1 LFS
Stated Requirement: remains unchanged.
Proposal: We-acceptthis: There are no changes to the LFS interfaces (other than the
removal of the weekly Stock on hand files — see section 5.5.2), so no changes are
needed here.
5.5.1.2 TMS - POL-FS
Stated Requirement: to be consistent with that being developed for S60.
For S60 there is no SLA on this interface and no measures are in place.
[CDPOLFS], however, says that the ‘Tequirement is for Horizon to deliver the files to
POL FS by 03:00. We ved-suid fem Post Office Ltd has indicated
that we-should-take this should be taken as $ being the SLA.
Proposal: Fhat cept SLT-similar-to—thatfor-the-c: +-OPTIP- deliver
namely The Service Level Target to be:
co 96% of Transactions to be delivered to POL FS by 03:00 on Day B
o 97% of Transactions to be delivered to POL FS by 03:00 on Day C
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
5.5.1.3
5.5.1.4
5.5.1.5
co 98% of Transactions to be delivered to POL FS by 03:00 on Day D
a 100% of Transactions to be delivered to POL FS by 03:00 on Day J
LDT is the same as SLT and ARL is 98% of Transactions to be delivered to POL
FS by 03:00 on Day D.
Remedies to be consistent with Data File delivery to TIP (as set out in Schedule
15, Annex 2, Paragraph 2.2.4)
Transaction Correction
Stated Requirement: to be like Planned Orders — 95% by 08.00 and 100% by 24.00
~ both Day A.
this-as-below:
This SLT appears to have been based on the previous version of the Horizon
agreement whereas However, the current SLT for Planned Orders reads:
Provided data delivered by 06:00 from SAP ADS:
co 90% by 08:00 on Day A
a 96% by 12:00 (noon) on Day A
There is no LDT and ARL is 95% by 12:00 (noon) on Day A.
¥Fherefore The requirement as stated is self-contradictory.
Proposal: Fhatwe-accept-asimilar Fujitsu will support a contractual SLT similar to
that for Planned Orders and Remedies to be consistent with LFS Remedies (as set out
in Schedule 15, Annex 2, Paragraph 2.4.5.3), rather than that stated in the CD.
TMS — MiS (SAP ADS data)
POL have dropped the requirement for this, so remainder of section has been deleted without
being marked as such.
TMS — MIS (Horizon data)
Stated Requirement: by 03.00.
Proposal: Fhat-we-aceept Fujitsu to support an SLT similar to that for the current
OPTIP delivery namely:
co 96% of Transactions to be delivered to MIS by 03:00 on Day B
a 97% of Transactions to be delivered to MIS by 03:00 on Day C
a 98% of Transactions to be delivered to MIS by 03:00 on Day D
c 100% of Transactions to be delivered to MIS by 03:00 on Day J
However in this case there is no LDT and no ARL, and no Remedies apply. Fhe
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Page 11
Fujitsu Services
POL00038916
POL00038916
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
5.5.1.6 TMS — HR SAP
Stated Requirement: 100% by 21.30 on Friday preceding weekend of pay run.
Given that the Friday that we need to load this data is beyond Day J for any of the relevant data,
then I don’t see any problem with this.
Proposal: Fhat-we-accept Fujitsu will support an SLT as follows:
That the file containing data for HR SAP is delivered to the Huthwaite remote
gateway by 21:30 on Friday preceding weekend of pay run, provided that the date
has been notified at least 2 weeks in advance.
CAPO data will not be included in this file as the interface with CAPO is
currently out of scope.
CAPO -data-will-only-be-inchided-in-this-file-previded-it-has-bi received-by-th
There should be no LDT but the ARL should be the same as the SLT.
Remedies: in the event of failure to achieve the ARL then Post Office shall be
entitled to recover Post Office Additional Costs from Fujitsu Services.
5.5.1.7 TMS (CTS file)
Stated Requirement: ne-SLA The overnight CTS file should be loaded onto the
Horizon-Post Office gateway by 07:30/!.
Proposal: We-accept-+this This is an acceptable operational measure, subject to the
following qualification:
The measurement will be treated as design target with Fujitsu Services taking
responsibility for tuning the infrastructure to meet the design targets and
discussing any changes in infrastructure through the Capacity Management
Service.
5.5.1.8 TMS (FRTS file)
In this case there is no formal requirement, however for completeness it is proposed
that we measure delivery of the overnight FRTS files against a target delivery time to
the Horizon-Post Office gateway of 07:30 on Day B.
5.5.2 SLAs to be removed
The following interfaces are removed as part of the introduction of Impact R3 and so
the associated SLAs need to be removed:
u
LFS Weekly Stock on Hand feed is being removed
OPTIP Feed is removed
Network Banking Report NB 103
This requirement was not stated in [CDBT}, but wntroduced as part of agreeing {CT]
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Page 11
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
5.5.3 Unchanged SLAs
The following interfaces are unaffected by the introduction of Impact R3 and so the
associated SLAs are unchanged:
= Reference Data Delivery
= Delivery of Data to AP Clients
= Delivery of Network Banking Reports (other than NB103 which is being
removed)
= Delivery of Data to FRTS
5.5.4 Migration Implications
The SLA changes will take places at different times during the migration.
Section 2.6.1 defines the various migration stages.
The following table shows how the SLA changes fit in with this migration timetabl
TMS - POL-FS 40 Since-first-day-willinclide-a-special-migrat r
notwantte-have-an-SLT-onit-
iso-may-notwant-an SLT-on both this-and-OpTiP.
sould-postpone.untiD
This SLT should commence after branch opening
positions are established on POL FS. The introduction
of this SLT should align with the ceasing of the OpTIP
SLT, i.e. there will only be one SLT or the other SLT in
operation at any one time.
Transaction Correction 30 Date to be agreed
NB Counter won't process them until Point 50.
FMS — MS SAP ADS dat 3S
TMS — MIS (Horizon data) 40 Date to be agreed
TMS — HR SAP Post 50 I Date to be agreed
May not start for a month or two.
LFS Weekly Stock on Hand 70 This interface is not currently used and so the SLT
should stop asap
OPTIP Feed 40 Date to be agreed
Network Banking Report NB 103 I 40 Date to be agreed
Table 35 — Migration of SLAs
5.6 SECURITY
None of the changes proposed will impact on the current systems security and any
changes should be made in line with current practice, thus ensuring that systems
security is not impacted.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 11
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 6 -
Testing and Acceptance
6.1 GENERAL
Each element of the new solution will be tested independently based on their interface
specifications. Testing up to the service boundary between Fujitsu Services and Post
Office domain is assumed on the basis of DIT testing at the boundary.
[CDBT] specifies that an End to End test will also be required.
A Test Strategy will be produced defining in detail the testing that will be carried out
at the various stages. The results of tests will be made available to Post Office Ltd as
described in that Test Strategy.
6.2 PRODUCT TESTING
6.2.1 Test Stages
The following test stages will be applied to each component:
= Unit Testing - module testing
= Link test — testing the interaction between modules
a Product Introduction Test (PIT)
a Direct Interface Test (DIT) tests new or amended interfaces to internal or external
systems
In particular a number of DIT tests are required:
Pve excluded any SAP Hosting interfaces
c Interface from NRDS to Horizon (Reference Data)
o_ Interface from TMS to POL FS (Summarised Transactions)
co Interface from POL FS to TMS (Transaction Corrections)
o..Interface-fromSAP-ADS.to-TMS (Cash Centre Transactions)
co Interface from TMS to MIS (Horizon aad-Cash-Centre Transactions)
co daterface-trom-EDS-to-FMS-(Cash-Account- Enlivenments)
a Interface from TMS to HR SAP (Postmaster Remuneration Data)
a Interface from TMS to POL (DRS Reports and CTS Reports)
= Business Integration Test (BIT) to prove the business integration of the various
components of the system on a live-like infrastructure
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
m Release Test (RT)
This also includes Migration Testing
a Live Support Test (LST)
Note that LST does not include a POL FS system and so will not test any
interfaces to POL FS.
In addition there will be support for the Post Office End-to-End Testing. This will
include the use of a POL FS system and so can be used for any required testing of the
interface to POL FS.
6.2.2 Test Environments
No specific test environments or test harnesses are required. Since the new external
interfaces are Bulk File interfaces all that is required is the generation of these files
and the checking of the revised files that are transmitted.
6.3 ASPECTS TO BE TESTED
The following sub-sections are provided as input to the Test Strategy and are aligned
with the requirements of the Test Strategy.
Note that there will be a number of non-functional tests being carried out for the
Hosting of POL FS, however those are all outside the scope of this DP.
6.3.1 Business functionality
The Business Functionality is described in Chapter 2. All new Business Functionality
as described there will need to be explicitly tested.
Existing functionality needs to be regression tested to show that it hasn’t been
changed and that the service provided has not been degraded. [BT002]
6.3.2 Performance
The following needs to be considered for Performance Testing:
= Impact on overall Counter Performance, in particular the effect of the increase
from a 1 week CAP to a monthly Trading period and the corresponding increase
in message store sizes on the time for report production
a The time taken to summarise the transactions with the TPS Host prior to delivery
to POL FS
= The time taken to produce the monthly files for HR SAP
= Ability to deliver the various data flows within their targets
Note that it should be assumed that all counters will have been upgraded to 256Mb of
memory prior to the rollout of S80.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
6.3.3 Volume
The main effect of Volumes is on the ability to summarise the Transactions prior to
delivery to POL FS. In addition need to consider the implications of the longer Data
Retention period on the counter and Correspondence Server.
The volume of data to be passed to MIS will be similar to that currently passed to
OPTIP.
6.3.4 Integrity
This cover auditing of the interfaces that are subject to DIT.
6.3.5 Resilience
There is no specific resilience testing required.
6.3.6 Recoverability (including backup and recovery, including disaster
recovery)
There is no specific recoverability testing required.
6.3.7 Networking
There is no specific network testing required.
6.3.8 Security
There is no specific security testing required.
6.3.9 Supportability
There is no specific supportability testing required.
6.3.10 Manageability (system management)
There is no specific manageability testing required.
6.3.11 Migration
Migration is described in section 2.6. The migration requirements are fairly complex
and particular attention needs paying to testing the various migration scenarios, and in
particular the ability to migrate from the final cash account to the first Branch Trading
period while still providing valid data. The soft launch of the various features will be
tested as part of this test phase.
6.4 ACCEPTANCE
[CDBT] specifies some acceptance criteria and the way in which they will be
accepted against each requirement. The focus of acceptance testing will be on
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
ensuring that all these acceptance criteria are met other than in those cases where
there are agreed exceptions.
6.4.1 Live Pilot
There are no explicit requirements for a Live Pilot, however there are requirements to
support Soft Launch for some aspects of the functionality (see section 2.6), which will
enable a Live Pilot to be supported.
It should be assumed that a Live Pilot will be required in line with best practice on
other releases.
6.4.2 Capacity Modelling
The changes introduced here will have an impact on the overall system capacity.
Testing will demonstrate that the changes can accommodated within the current
headroom in the system.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 7 -
Mapping of Processes to Components
7.1 GENERAL
[CDBT] describes the requirement in terms of a number of processes. This DP
describes systems components that are intended to support those processes. The
following table shows the relationships between the Processes and Systems
components.
7.2 MaIN BUSINESS PROCESSES
Local Verification
Perform Transaction Checks I A4.1.1.1 1.2.4 N/A N/A Process out of scope
= Periodic
Perform Range Checks - A41.1.2 24 N/A N/A No changes required
Transaction ... Validate Data
Captured
Automated Reconciliation A4.1.1.3 24 N/A N/A No changes required
Produce Reports and
Information
Produce Daily Summaries Ati21 [24 WA NZA__I No changes required
Produce Periodic Summaries I A4.1.2.2 24 [DIAGR
2.5.1.3.10_ I EP]
Produce Sales Report to A4.1.2.3 2.5.1.3.1 [DIAGR
Assist Remuneration Check EP]
Verify Summaries A41.2.4 24 N/A N/A No changes required
Despatch Redeemed A41.2.5 24 NiA NIA No changes required
Dockets
Produce Other Horizon x 24 [DIAGR No.changes required
Reports 25.1.3.7 I EP}
‘Other Data Capture
Input Non Accounting Data__I A4.4.3.1__I 24 NA N/A_I No changes required
Input Bulk Data A4.1.3.2 24 N/A N/A No changes required
Input Additional Client Data A4.1.3.3 24 NiA NIA No changes required
Discrepancy Management
Receive Automated Message I A4.1.5.1 2.5.1.6.3 [DIAGD
EC]
Handle Transaction A4.1.5.2 2.5.1.7 [DIAGD
Corrections EC]
Compare Generated with
Actual Cash Position
Compare Generated with A416. 2.5.1.2.1 [DIAGD
Actual Cash Held for Stock Ec}
Unit
Create Variance Report A4.1.6.2 2.5.1.2.2 [DIAGD
Compare Generated with EC]
Actual Cash Held Across
Branch
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Make Good, Hold or Declare . [DIAGD
Any Cash Variance Ec]
Stock Checking and
Declaring
Rem In/Out Stock A4.1.7.1.1 I 2.5.1.1.2.1 I [DIAGD
EC]
Local Stock Check Stock A41.7.1.2 I 2.5.1.2.4 [DIAGD
Held for Stock Unit EC]
Review Stock Held Across A4.4.7.4.3 I 2.5.1.3.2 [DIAGR
Branch EP}
Produce Branch Accounts
Produce Trial Balance A4.1.7.2 2.5.1.4.1 [DIAGB
A]
investigate Balance A4i73 [24 NA N/A I No changes required
Discrepancies
Make Good or Declare any A4ATA 25.1.14 [DIAGD
Outstanding Losses Ec]
Produce Final Balance A4175 2.5.1.4.1 [DIAGB
AL]
Produce and Confirm Trading 2.5.1.4.2 [DIAGB
Statement A
Roll Over Inactive Stock Units 24 NA N/A No changes required
Stock Revaluation 2.5.1.1.2.3 I [DIAGD
EC]
Summarise Transaction
Data
Scan Transaction for Day A431 25.2.4 N/A
Accumulate Transactions for I A4.3.2 2.5.2.8 NA
Summarisation
Summarise Cash Centre A4.3.3 1.2.4 NIA N/A Assume that this is
Transactions done by SAP ADS
Deliver Data to External none 25.2.3 N/A
‘Systems 25.26
25.2.7
2.5.2.10
2.5.2.11
Table 36 — Mapping of Business Processes to DP Sections
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 8 -
Compliance Matrices
8.1 GENERAL
The purpose of this chapter is to list all the formal Requirements identified in [CDBT]
and [CDPROG] that are identified as being on Fujitsu Services together with
compliance statements and references to where in this document the meeting of the
requirement is described. Details of acceptance criteria are also included.
I've ignored [CDPROG] since it isn’t yet aligned with [CDBT].
NB it does have some high level requirements which may need to be added in here.
POL have categorised the various requirements with acceptance mechanisms. I’ve
included the mechanism to be used in the following section. Table 37 contains the
key.
Document review Requirements that cannot be objectively verified by a test of
the Work Package solution may be satisfied by PO undertaking
a Document Review. The outcome of any such review will be
documented by PO in the Document Review report.
DW I Design Walkthrough Requirements may be satisfied by PO evidencing a Design
Walkthrough of the Fujitsu Services Design as specified in the
Design Proposal. The outcome of any such design
walkthrough will be documented by PO in the Design
Walkthrough report.
FST I Fujitsu Services Test Tests that are run and managed by Fujitsu Services for the
purpose of verifying that a Fujitsu Services Work Package
satisfies the Work Package Acceptance Criteria. Fujitsu
Services shall produce a test report presenting the results of
the tests. The assessment of the results of these tests will be
by inspection carried out by Fujitsu Services or jointly with PO,
in conjunction with the Acceptance Criteria.
POT I Post Office E2E Test Tests that are run and managed by PO (which in terms of the
scope of this document), are for the purpose of verifying in
terms of the E2E solution, Acceptance Criteria have been met.
PO shall provide appropriate evidence to FS, if any non-
compliances are identified.
M Monitoring PO shall specify any requirement beyond the level of support
that Fujitsu Services are required to provide under normal
operational practice (such as a report etc). Typically the
duration of this requirement may be of the order of one month
and no greater than 3 months, but in any event to be agreed in
advance between PO and FS.
SOF I Statement of fact Where the solution to a Requirement is self-evident and does
not lend itself to formal proving,
SOO I Statement of obligation Relates to requirements that represent either:
* An existing Fujitsu Services obligation or
* Agreed additional Fujitsu Services obligation (to be
recorded subsequently as an amendment to the contract
clauses, schedules, or contract controlled documents)
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Table 37 — Acceptance Mechanisms
©[ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 12
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
8.2
COMPLIANCE MATRIX
POL00038916
POL00038916
BTOO1 Production of a balance report for a stock unit must be
I possible to be produced within 5 times the current production
I time for a stock unit with a busy transaction profile, long
_trading statement period
Functionality not specifically identified to be changed within
I this document must not be affected to degrade the existing
_setvice provided by the Horizon system.
BTO02
BT003 Migration to POL-FS must occur at the end of a financial
_ period
: The content and format of trial and final balance reports will be
I altered as defined in [REPREC]’”. specified-in-Appendix-B-of
BTOO7
SOF
FST
BT008
/ Anew trading statement report will be produced, the content
I and format of which will be as defined in [REPREC]!?.
ces repo Pl ;
I format of which will be as defined in [REPREC}’’. specified.in
BT016
‘unctionality to allow entry of date range on the of Sales
I Report to be produced will be implemented within Horizon, the
I system will verify that a valid date range has been entered, If
I invalid it will allow re-entry, if valid it will produce the existing
I_Sales report but with data covering the specified data range.
I FST
Yes
~BT024 ~~ “Auser with the appropriate role will be informed, at log on, that
I there are outstanding Transaction Corrections awaiting
I processing, whenever there are any.
a result of Rep_Clar
ding che
Wording changed as a result of Rep_Clar
Wording changed as a result of Rep_Clar
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Printed on 22/11/2002 2:20:00 by GlJ
Page 128 of 148,
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
44
16/09/2004
I There will be a button for Transaction Correction Management
POL00038916
POL00038916
BT026
BT028
BT029
“BTO32
is
16
Wording chang
I within the menu hierarchy which is only accessible by users
I with the appropriate role. This will provide the user with a list of
I the unprocessed Transaction Corrections, displayed in
I date/time order. Having selected the Transaction Correction to
I process, the system will display text making clear what will
I happen when they select any of the options presented, the
user need not process should-be-able-to-print-the-details-of-the
I transaction correction at this point in-order-te-consider-its,
fore-invokingit 5
I For each Transaction Correction the user will have up to three
+ options — Each option, when selected, will perform an
I identified set of transactions, defined within the Transaction
I Correction. (this may include an option to Do Nothing
_(fequesting further investigation).
“At the end of performing a cash declaration, in a shared stock
I unit, the system will enter, if the user chooses to, the cash
I discrepancies function to support the identification of any
_ variance.
I Reminders for ONCH function to be performed at log on if not
I performed previous day will be removed and, instead, the
I system will remind users to perform cash declaration function
I if it has not been performed on the previous day: there will be
I no option to cancel without declaring’*. but-this may-be
_ declined.
Yes
Yes
26124
_ FST
2.5.1.6
‘When the cash declaration has been made the figures for
I denominational split will be passed to SAP-ADS as if an
_.ONCH declaration had been performed.
‘A new function for recording a “make good’ action will be
I made available this will allow the user to enter the amount
I made good. It will record the amount made good, making a
I new declaration for cash by altering the previous declaration
I by the amount made good. Amounts made good will be
I reported on variance reports, balance reports and trading
I Statements.
das a result of Rep_Clar
Wording changed as a result of Cash Decl
Yes
Yes
‘De isa
7251.23
2.5.1.2.2
© 2.5.1.41
1 25.1.4.2
FST
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPR004.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Page 129 of 148,
Printed on 22/11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
L
I BTO36
‘Adjustments in stock (whether identified via adjustments or
I stock declarations) should be adjusted at the adjustment price
L I Whenever defined in reference data.
BT037 The Office Snapshot report will be redefined without stock
I values as defined in [REPREC]!”. section 20.7. in Appendix-8
_oHCDBT}
17 Wording changed as a result of Rep_Clar
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 130 of 148,
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
BT038 I Anew check is to be introduced after producing the Trial
I Balance (ie when the “rollover” button is pressed prior to
I producing the Final Balance). This check will act as follows:
I 1. If itisn’t the last Stock Unit to rollover, the clerk will be
advised that the Discrepancy is to be posted to a I
“local adjustments” account. They have the option of I
accepting or rejecting this action.
a. Should they accept it, then a pair of
transactions will be generated resulting in
the Discrepancy being reduced to zero and
a corresponding amount being put into a
“local adjustments product”.
b. Should they reject it, then the rollover is
aborted and the clerk is free to do whatever
they wish to balance the Stock Unit and will
then need to balance the Stock Unit again at
a later time.
c. The “local adjustment” is not associated with
any Stock Unit (as with a Suspense
account). Items can be added to it by any
clerk, but only as part of the Balancing
Process. Managers / Supervisors will be
able to move items from it into cash in their
SU to be Made Good.
2. If this is the last Stock Unit to Rollover an additional
check will be performed to ensure that the net total of
transactions, within the Trading Period, in the “local
adjustment” account has a net value of zero.
3. If this is the last Stock Unit to Rollover, then the user
will be informed if the Stock Unit has a Discrepancy
and that this must be resolved before the last Stock
i Unit can be rolled over.
I Local Adjustment will behave in a similar way to existing
I Suspense Account items, namely the values will not be
I associated with any Stock Unit, but is considered as part of the
_ overall Branch balance
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 131 of 148
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
' There is an existing report that shows the state of all suspense
I accounts and all Transactions associated with the suspense
I accounts during the Trading Period, indicating which Stock
I Unit carried out the Transaction. It is proposed that Local
I Adjustment transactions are included in this report as with any I
_ other Suspense transactions i I i .
8T040°™” “Horizon should be changed such that only Supervisors and Yes ‘25714 FST This has been rewritten as [BT040a]
Managers (etc) will be allowed to carry out Suspense I
I Transactions. The only exception to this will be the automatic
A posting of Discrepancies to Local Adjustment. .
BT041 The user will select the appropriate function which will display I Yes 2.5.14.2
I the Trial Trading Statement (as per outlined report) and this I
I may be printed. When the user is content to confirm the
I position he will be presented with a textual message which
I describes the liability and responsibility which the postmaster
I is accepting. If the postmaster accepts this the system will
I record this action, print the Final Trading Statement and
I commit an event which identifies that the agent has produced
I the Trading Statement and accepted liability for the trading
FST
L _ position. i L
BT043 The confirmation event will be made available to the data Yes 25.1.4.2 I FST
I warehouse to enable monitoring of who has and who hasn't i
I done a trading statement. The “confirmation transaction” will 25.2.7
I not contain the constituent parts that make up the trading
ition.
facility for different branches to operate on a diffe! (four Yes
I weekly) branch trading calendar, will be implemented, which
I branch is operating to which calendar is to be defined by
Feference data. ef
I The current functionality for extending accounting periods Yes
I should be removed. The Horizon system should continue to
I remind users to roll-over the accounting period if they logon to
L __a SU in the wrong Trading Period according to the calendar.
BT046 = Revaluation functionality to be redefined such that the user is Yes
I reminded, for a series of days, at logon of an upcoming
I revaluation (defined by Reference Data). The reminder will
I suggest that the branch manager checks stock and makes any
adjustments prior to the price change
I The data retention period will be increased such that all trading I Yes
I data is available within the Branch for a minimum of 42 days. I
FST
-BT044
/ BT049
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 132 of 148,
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GlJ
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
44
16/09/2004
POL00038916
POL00038916
I The data retention period will be increased such that all trading
I data is available at the data centre for a minimum of 42 days.
Yes
FST
BTO56
BT058
BTO59
/ BTO6O
_BT062
_ All stock items will be monitored throughout the Horizon
__system by volume and not by value.
I The existing Weekly Stock Holding feed to SAP-ADS will be
I removed
/ There is a requirement to continue ensuring reconciliation
I between data flows which remain within the Fujitsu domain
I and ensuring that control totals are applied to any external
I interface to allow detection of file corruption. All these
I reconciliations should take advantage of the simplified process
_ described in Section 21, Appendix C, of [CDBT]
I It is required that only reports that have previously been
I printed can be reprinted; and that the reprint reports are
I identified by date and time previously printed. The following
I particular requirements are identified for report re-prints:
I For Stock Unit Balance Reports and Branch Trading
{ Statements, the requirement is to be able to produce
reprints for all reports for Period N up until the rollover from
i Period N+1 to Period N+2
I © There is no need to reprint the Office Weekly Counters
Revenue Schedule, since the original report has been
I removed
I For the following reports:
i Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA
Office Weekly Redeemed Savings Stamps
I Variance Report (new)
I The requirement is that each of these is a weekly report
and it is sufficient to be able to reprint any of these for
which the data is still available (ie the last 5 reports). In
particular, this will ensure that all such reports for the
I current Branch Trading Period can be reprinted if required.
I The Track and Trace Manifest, currently allows reprint of
I the last report produced. My understanding is that such a
report is normally produced daily, so no special
consideration is required in terms of long term storage of
the data for this report.
__ The NB103 DRS reconciliation reports will be eliminated.
Yes
"Yes
Partly
Yes
rYes
2.5.1.1.2
726.151
(25.2.2
21.6.1
25.1.5
(25.155
2.5.25
25.26
(25.2.14
(25.138
25.2.5
“DR
DR
FST =
POT
“DR” "Note that the changes in Section 27, Appendix C, of
[CDBT] are out of scope.
I FST ‘This has been rewritten as [BT060a]
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPR004.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Page 133 of 148,
Printed on 22/11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
BT063 The consolidated stock unit non-value stock report is no longer I Yes I 25.1.3.9 DR
i I required and can be removed. The check to ensure that the 225.142 I FST
_ consolidated stock unit non-value stock report is produced as I i
I part of end of period processing will also be removed. I
BTO65 _ Anew Transaction Corrections report will be produced, the I Yes 2.5.1.7.3
I
I
L
FST
© content and format of which will be as defined in [REPREC]’*
I Specified in-Section-20.3 in Appendix B-of {CDBT]
Table 38 - Compliance Matrix
8.3 ADDITIONAL REQUIREMENT
A number of further requirements have been documented following the baselining of [CDBT]. These have been agreed with POL and
are recorded here.
This requirement has now been removed
“FST
there are outstanding Transaction Corrections awaiting
processing, whenever there are any. The dialogue informing
I the user of this will include a button allowing access to the
I_ “Process Transaction Correction” function.
__This requirement has now been removed.
FST I Roles clarified
BT040a” Horizon should be changed such that only those Roles that Yes ‘otia
I can do an Office Balance (ie Manager, Supervisor, Migrate, i
I Auditor and Auditor - Emergency Manager) will be allowed to
I carry out Suspense Transactions. The only exception to this
I will be the automatic posting of Discrepancies to Local
Adjustment.
“BT051 rocess for recovery when the Branch is nearing, or Yes "There is now a requirement on Fujitsu to support this
I has exceeded, 42 days since it produced the last Branch i I Post Office Ltd requirement.
I Trading Statement will be defined I However there is no requirement on Fujitsu to make
I any specific changes.
18 Wording changed as a result of Rep_Clar
© [ DATE \@ “yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 134 of 148
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
' There is a requirement to control alll items of stock. This will be There is now a requirement on Fujitsu to support this
I achieved through reference data by defining as controlled 263.23 — Post Office Ltd requirement.
I products those products which are currently non-value i However there is no requirement on Fujitsu to make
I products
I POL will review all non-value items and identify requirements _
I for redefining them as controlled stock items. t
I Adocument of the findings of the review of non-value stock
items will be produced and reviewed to ensure that it identifies
_ those which are to be reclassified as controlled items and that
I they will be controlled accurately by this redefinition and that
I for any products which cannot be controlled in this way,
I requirements for bringing them under control will be identified,
I documented and managed through the change request
I mechanism.
I Existing processes for transferring, testing and implementing
I new reference data to the Horizon counter will be used to
I make any identified changes. Existing Change Request
processes will be applied to new requirements identified.
any specific changes.
g rep 1g
I removed from the Horizon system:
_¢ Counter Weekly DVLA V10
Counter Weekly DVLA V11
Office Weekly Counters Revenue Schedule
Declaration and Confirmation — Non-Value Stock
Counter Daily Cash on Hand (there is a separate report for
Cash Declaration which is nearly identical, and it is just the
I cash Declaration report that we need to retain)
I Office Weekly Cash Flow(this is replaced by the Variance
i report)
I) Cash Account Trial
..Cash Account Final i
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 135 of 148
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GlJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
BT060a It is required that only reports that have previously been
I printed can be reprinted; and that the reprint reports are 25.138
I identified by date and time previously printed. The following
I particular requirements are identified for report re-prints:
I= For Stock Unit Balance Reports and Branch Trading I
I Statements, the requirement is to be able reprint the last
I report of each type generated
I = There is no need to reprint the Office Weekly Counters
] Revenue Schedule, since the original report has been
I removed
I ™ For the Cash Variance report the date range for which the
L report is to be produced will be defined as part of the
reprint request mechanism. The report will be produced
I from data stored during the requested period.
I= For the following reports:
i Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA
Office Weekly Redeemed Savings Stamps
Variance Report (new)
The requirement is that each of these is a weekly report
and it is sufficient to be able to reprint any of these for
which the data is still available (ie the last 5 reports). In
particular, this will ensure that all such reports for the
current Branch Trading Period can be reprinted if
I required
I ™ The Track and Trace Manifest, currently allows reprint of
I the last report produced. Since this report is normally
produced daily, no special consideration is required in
terms of long term storage of the data for this report.
I ™ _No other reports require reprints. i
BT102 Horizon will be changed such that the menu hierarchy reflects I Yes 25.114
/ changes made in the suspense products and allows users to
Le ___ access the new products. . ni wd i
BT103"” ‘The buttons that allow Error Notices to be cleared and Yes £2.5.1.14 FST
I Vouchers to be processed will be removed, since in the future i
/ FST
L _ this will be achieved using Transaction Corrections. i L i
BT104 ~The current ONCH button will access the common declare Yes 2.5.1.2.1 I FST
I cash functionality i
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 136 of 148,
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GlJ
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
POL00038916
POL00038916
I There will be a new Check for Variances function in the menu
I hierarchy for shared stock units which will provide the current
I functionality to sum up part cash declarations (only), using the
I current algorithms for summing cash declarations in shared
I Stock units, and calculate any variance from the stock unit
__derived cash position.
I
BT106™” “The buttons for making declarations and confirmation ofnon- I Yes. =< 2.5.4.25 FST
value stock items will be removed from the menu hierarchy. Le
BT107 I Anew Counter Weekly Redeemed Savings Stamps Yes I 2.5.1.34 FST I Reports defined in [CDBTCR1]
I mandatory report is required with similar content to the Office I
I Weekly Redeemed Savings Stamps Summary. L
BT108 = A daily feed of transaction details and summaries will be No 125.23 FST = Considered top be out of scope.
I accepted from SAP-ADS for passing to POL-FS and the MIS. Le POT
BT110 __ Horizon will store data for the following events and forward the I Yes 25.2.4
I data to the POL Data Warehouse system;
I Trading Statement Created
I = Trading Statement Period rolled
_™ Trading Statement Period Roll Abandoned
_™ Excess Cash Removed
I ™ Cash Shortage Made Good
= Cash Variance Report Previewed
Cash Variance Report Printed
lay
FST
“BT111— Afile of CAPO data from EDS will be received, the data will be I No 2.5.29 FST Considered top be out of scope.
I loaded into TMS such that the information can be merged in I POT
_ with the data being sent to HR SAP each month. i i
BT112 Transaction Data must be summarised and generated into Yes 25.210 FST
I files of information to provide base data for the payroll I POT
I calculations within HR SAP. This will follow the existing rules I
_ currently used by CBDB. . . —
BT113 = The nightly file of transaction corrections will be loaded and Yes
“BTIN4
I distributed to the appropriate branch systems for local
handlin
I Migration at S80 will be complex and will require the full end to
I end participation in determining the exact detail. Each
I migration step must be specified in detail to ensure integrity of
_data and processes throughout the migration period
25.212 I FST
Yes 264 DR
There is a requirement on Fujitsu to support this Post
Office Ltd requirement.
However there is no requirement on Fujitsu to make
any specific changes
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPR004.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by GlJ
Page 137 of 148
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
44
16/09/2004
POL00038916
POL00038916
I In circumstances where the Branch Trading Statement is not
I produced within the data retention period, the Horizon system
I should attempt to retain the data for the entire period, subject
I to hardware limitations and constraints.
BTI16
The production of the reports below needs to change such that
I a cut-off is taken and the next report will only look at the Stock
I Unit reports (ie Counter Weekly) produced since the last time
the summary report was cut-off. An implicit cut-off will occur
I when the branch is moved to a new Trading Period.
Office Weekly Inland Revenue Tax Credits
Office Weekly Inland Revenue Tax Credits P5589
Office Weekly Pensions and Allowances
Office Weekly Redeemed Savings Stamps Summary
.
ce
Ie Office Weekly P&A P2311MA.
fe
.
Yes
2.5.1.3.10
FST
Table 39 — Additional Requirements Compliance Matrix
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
File: EADPR004.Impact_Release3_DP.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by GlJ
Page 138 of 148,
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
8.4
OTHER ASSUMPTIONS
During the development of the DP and the costing exercise a number of cases have
been identified where [CDBT] was not clear and so assumptions have been made to
enable as design to be produced. These are:
gS
2.5.1.1.6
3.5
“25.1.2.2
“281443
926474
NRDS to provide Settlement Products and
Primary and Tertiary Mappings to Horizon
fia Type A interf
Variance Report only produces daia up to
and including “yesterday”
Stock Remittances / Transfers will be
excluded from the SU Balance report since
they are zero value.
Wea
Note that there are potential requirements to
handle adjustments to both value and
volume using Transaction Corrections (eg
correcting an Orange ‘phone card
transaction to an O2 ‘phone card
transaction. In this case we will need to use I
the loss price if available for the products.
The requirement to handle both value and
volume adjustments using Transaction
Corrections is not addressed by the
__proposed Fujitsu solution.
jomment
I Now included in [RDSAIS}
itis understood that there may aiso be a
I requirement to include some of today’s
I data. However the detailed requirements
I have not yet been confirmed so this will
I be processed as a CR once agreed.
I Post Office Ltd have decided not to
There may be a future CR to bring such
_ adjustments back into scope.
25.23 Requirement to process SAP ADS © Confined.
2.5.2.13.6 I Transactions is out of scope i
3.2.34.2
8.3:
BT108 i
2.5.2.8.2 In situations where Horizon detects an error I There is an increased likelihood of this
ina POL FS subfile, the sub-file will notbe during the period between migration
forwarded to POL FS until the error has : points C and D.
been investigated and corrected within
Horizon. NB In such cases, the underlying
transactions may already have been
_ forwarded 10. MIS. mmm
2.5.2.9 Requirement to process CAPO Transactions I Confirmed.
3.2.54.5 is out of scope i
migration:
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
Page 12
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
.
.
...Adttachment to a new SU;
It is acceptable to prohibit further
processing in a Stock Unit that has rolled
into a new CAP until the Branch is rolled
over into the new CAP for the two special
rollovers, ie the final CAP to CBDB and
the final CAP prior to switching to Branch
Trading Processes (points 30 and 50 in
the migration process). In both these
buttons being inhibited other than those
that will support CAP Rollover;
id Logout.
Following the final CAP rollover for
CBDB, changes will be made to the
housekeeping menu to support changed
Suspense accounts; prevention of Error
Notice and Voucher processing; and
introduction of new Housekeeping
functions to replace vouchers.
Detailed design now shows that this is
_ not desirable or necessary
I The proposal now is that the menu
I structure presented to users reflects the
current state of the Stock Unit and Office
in terms of whether they are operating in
I CAP or TP mode
cases, any attempt to logon or attach toa»
stock unit in the new CAP will result in all:
‘This is the current baseline. However
I POL ate still considering raising a CR to
_ change this
Restricting the Housekeeping menus as
specified in requirement [BT040a] will
happen at a specified date prior to the
final CAP for CBDB being rolled over at
all branches (ie it will not be co-ordinated _
to a CAP rollover). In particular this
change will take place at the same time
in all branches and will not be available
for piloting.
Transactions Corrections will not be able
to be processed until the branch is
operating in Branch Trading Mode (ie
point 50 in the migration process)
Transactions Corrections received earlier _
than point 50 will be retained and can be
processed after point 50 until 42 days
after they were delivered by POL FS.
it must be possible to support a pilot
“POL FS" for selected branches in
parallel with normal “S60” operation of
the live POL FS. Such a pilot can then
be stopped and a “proper” migration
supported. The term pilot is taken to
mean the provision of data from selected
branches to a test instance of POL FS.
whilst continuing to provide an
operational feed to CBDB. On
completion of the pilot, it is assumed that
the data in the POL FS test instance will
be discarded.
The flow to POL FS will conform to the
$60 AIS until we first pass through the
$80 Data (i.e. Point 30 in the migration
process). Therefore late data from
branches that are still operating at S60
will then pass the data through the S80
interface (but include a Balancing
account)
There may be circumstances under
which S80 Transactions from Horizon get _
passed to POL FS prior to the Opening
Balances.
' Itis understood that a CR will be raised if
I a Pilot is to be operated, at which time
+ operating, infrastructure and test rig
I costs will be assessed, i.e. costs for Pilot
I operation are not covered by this CT.
The details have now been changed
_ such that Point 25 has been introduced
i for the change from the S60 AIS to the
I S80 AIS. Also detailed data delivery has
I been changed as a result of
_ CP POL_FS_AIS
[POLFSAIS] now reflects this.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Page 14
Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
‘ForEx will continue to be handled as a
single account within POL FS.
.
« The CD has not identified the
requirement for any special reports that
need to be created to support branch
migration. In particular, the opening
Balance from the first “new” Stock Unit
Balance will not match the Closing
Balance of the last “old” balance (though
business processes can be defined to
allow the two to be manually reconciled)
Pending completion of POL requirement
analysis to define specific requirements,
it has not been possible to address any
changes that may be necessary to
handle migration non-value stock
__Products to value stock products.
It is understood that a CR is likely to be
I Taised to change this.
I PSO_CRO0220v2 has
I documents this change.
formally
Vitis understood that a CR is likely to be
I raised to change this.
.
The feed to OPTIP will be switched to
MIS at a given point after POL FS is
operational (expected to be
approximately 10 days following point 30
in the migration process). It is
understood that there is no requirement
for no parallel running.
* Branch transactions conducted following
completion of the final CAP and the
commencement of the next trading day
(i.e. at the switch from CBDB to POL FS
may be excluded / double counted in the
summaries prepared for HR
.
There is no requirement to look at old
“zeNB109's after CBDB switch off
The following assumptions are made about
the interface to HR SAP:
I This Point is now formally referred to as
I Point 40.
itis understood that POL procedures will
attempt to mitigate this risk. Detailed
I design work will also attempt to reduce
: the probability of this happening.
I The design now ensures that this will not
happen.
nce the AiS has been baselined, the
_ impact on the solution design will be
I assessed and any changes in the
I assumed requirement will be addressed
I by CR.
I All these assumptions have now been
That data will be provided ‘one or two
months in arrears as specified in the
summarisation Reference Data.
i confirmed in [HRSAPAIS1
]
Two separate interfaces will be used:
An initial feed for “multiples” (about
250 branches) :
A full feed for other sub-post offices ©
(about 16,000 branches) I
Reference Data will be used to identify
in which feed the data for a branch is to
be included. Note that some branches.
(Directly Managed Branches) are not
included in either feed.
There is no requirement to migrate a
branch from one feed to the other.
°
.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Page 14
Printed on 22/11/2002 2:20:00 by Gld
Fujitsu Services IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
POL00038916
POL00038916
Ref.: EA/DPR/004
Version: 1.1
Date: 16/09/2004
There is not a requirement to provide
support for migration to a target position
where data is passed across as a single
feed, 1 month in arrears. Any such
requirement and will be handled by a
separate CR, though the design should,
where practical, take into account the fact _
that this is likely to be required in future.
is assumed that a Calendar will be
provided via Reference Data defining the
cut-off dates for summarisation and also
the dates by which files will be sent to HR :
_SAP.
“itis assumed that the mapping of
products / modes to CTTs will be
provided by Reference Data. This
mapping will also indicate whether the >
summary is to be passed to HR SAP one I
or two months in arreal
The Reference Data available at the Data i
Centre at the time of the Summarisation
Process will be used for Branch
Transaction summarisation. It is
assumed that there is no requirement to
maintain historical mapping data
associating reference data that was.
current at the time that the transaction
was actually carried out should that be
different from that at the point of
.
.
“itis assumed that not all transactions will
be mapped to a CTT, and so no checking
/ reporting is required to detect
transactions that are not mapped to any
CTT number as part of the
summarisation process.
I The following assumptions are made about
the interface to MIS:
3.2.7
"Once the AIS has been baselined, the
I impact on the solution design will be
I assessed and any changes in the
_ assumed requirement will be addressed
I byCR.
I All these assumptions have now been
_confirmed in [MISAIS}.
* The CAP and BP fields will be retained,
however the values will be null once the
branch has moved from Cash Account to =
Trading Period (point 59 in the {
migration).
There are a number of the more recent
“specialised” transactions where all that
is passed to OPTIP is the basic EPOSS
Transactional Data. Sections 85 and 86
of [MISAIS] define the additional data
required
ithas been agreed that the Quantity field
can be extended to accommodate
Bureau Quantities rather than having to
__.hold it as an additic
* Section 87.2 of [MISAIS] identifies some
additional events that are to be passed
through to MIS. This is also defined in
Table 27.
.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc
Page 14
Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
either to POL FS (hosted by Fujitsu) or to a
single Gateway system in Huthwaite and so
I_covered by a single TIS ([POLTIS])
Will be removed as a duplicate
8.2: Will be removed as a duplicate
__BT030 i . . .
8.2: Requirement BT059 is only partially
BTOS9 I covered. In particular the reference to
Appendix C of [CDBT] (which is out of
I SCOPE) is excluded. .
83 V All the changed requirements identified in
I this section are assumed to be applied to
[CDBT] and are consequently considered to =
be part of the requirement.
“83 / The Transaction Interface from SAPADS to
_BT108 __Support the MIS data is out of scope
8.3: I The data flow from EDS for CAPO
_BT111 I_Enlivenments is out of scope
Table 40 —- Assumptions
8.5 CHANGE REQUESTS
Post Office Ltd have raised a number of Change Requests on Fujitsu for Impact
Release 3. There are 2 types of Change Request:
= Soft Changes
Where the change is considered to be a clarification and has no material impact on
the overall costs of Impact Release 3
Such changes will not result in a CP being raised.
a Hard Changes
Where there is a real change involved.
Such changes will result in a CP being raised. In some cases the CP may not be
scheduled until a later Release than the rest of Impact Release 3, in which case the
CP will not be included in this document.
The following tables list all the CRs that have been raised on Impact Release 3 split
into Soft and Hard Changes:
PSO_CRO0210 3797 IChange to process for creating and content of included with
INRDS to Fujitsu interface file. PSO_CRO00223v2
IPSO_CRO0211 ICash_DecICash Declarations Now mandatory.
f See
section 2.5.1.6.1
IPSO_CR00220v2 POL_FS_. [Change to level of foreign currency detail from included with
AIS, Horizon to POL FS IPSO_CRO0241
IPSO_CRO0225 [Rep_Clar IChanges as a result of User Interface Definition [Changes to
fork Requirements
wording reflected in
Section 8.2
Table 41 — Soft Change Requests
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
JER fitle. Gor
PSO_CR00215 8787 Suspense Report ~ ability to split cash in pouches Approved
detail report from main suspense report See
section 2.5.1.3.3
PSO_CR00218 POL_FS_ [Changes to Error rejection rules on POLFS AIS [For impact
is
PSO_CR00223v2 8797 \Simplify the interface between NRDS and Horizon [Approved
(AIS version 6.4)
PSO_CR00241 POL_FS_ Changes to Branch Ledger AIS for migration and _ IFor impact
Ais icutover
PSO_CRO0243 3813 Change of non-value stock to controlled stock (MVL [Awaiting approval
land NRA )
Table 42 —- Hard Change Requests for S80
IPSO_CRO00213 8785 Iintroduction of debit card option for settlement of
[Transaction Correction debt or discrepancies
larising from Branch Trading rollover
PSO_CR00214 8786 INi Cheques ~ the requirement to move the rem IApproved!9
lout function from the stock pick list and place, as a
\separate icon, on the remittance menu
PSO_CR00227 8782 IFormal impact assessment of Smartpost captured [Study CP Rejected.
ldata being sent to S80 POLFS,POLMIS and _IMay require changes to
SAP HR MIS Interface when the
E2E design is agreed
‘Approved
Table 43 — Hard Change Requests for S90
19 POL would like this brought forward to S80 if possible.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Chapter 9 -
Retained Information
9.1 GENERAL
This chapter has been added to hold text that has been removed from the DP, but is
perhaps relevant to future changes or Lower Level design documentation.
9.2 NON-VALUE STOCK ANALYSIS
I This text was previously part of section 2.5.1.1.3.
The remainder of this section is an analysis of the sort of things that could be done,
however at present it is assumed that none of this will be done for Impact R3.
up
3297 MVL Discs 34 Need special consideration
3298 Milk Tokens 1 Will become uncontrolled
3299 Travel Schemes 379 Ref Data Change
3300 Local Authority Vehr_I 20 Ref Data Change
3301 Other Tokens 16 Need special consideration
3302 NRA Rods 6 Need special consideration
3304 N. Lott. Chqs 1 Need special consideration
NB we were looking at re-engineering this
product
Table 44 — Categories of Non-Value Stock
My system has 4702 Pre Pack Currency instead of N Lott Chqs.
Table 44 identifies the various types of non-value stock in the current system. The
following subsections consider each one in turn.
9.2.1 Travel Schemes and Local Authority Vouchers
These can be converted into controlled stock fairly simply. They are currently
defined as a single product which is used both for the non-value stock declaration and
for the transaction of the item within the Serve Customer menu. The following is
required for these products.
Note that these changes should not be done on Live until after the cash account has
been removed (ie after point E in the migration strategy). This will mean that there is
no need to worry about the impact on cash account mappings.
= New buttons are added to the Rem In / Out from ADC and Transfer Out menus to
support Remitting these products in / out and transferring them between Stock
Units. These buttons should use the same pick lists as are currently used on the
Serve Customer menus for these products.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
= RDS generates a new version of the Reference Data such that the product is
defined as a Stock Item with any necessary changes to the product mappings so
that it is reported correctly.
Since changing mappings on an existing product is likely to cause unpredictable
effects, it will be necessary to introduce new, equivalent products with the new
mappings and withdraw the old ones. Since these products appear on picklists,
then this should not cause any problems other than to any PLU lists.
The product will also need to be included in the Stock Adjustment and Stock
Declarations lists.
= Following the change of Reference Data, the next time the Stock Unit is balanced,
then the user will find that the system generated Stock Position will not match
reality. This should be rectified by making a Stock Adjustment (or in a shared
Stock unit it could be done by making a Stock Declaration on each drawer and
accepting any discrepancy that results). This will result in the systems generated
position being brought in line with the amount present.
Note that to avoid this resulting in a corresponding cash discrepancy it will be
necessary to ensure that all such products have a zero “loss price” (at least until
this adjustment has been carried out).
Need to check if these adjustments will cause any problems for POL FS. I would assume that
they won't since there will have been no “opening figures” for these products.
= Ifrequired it should then be OK to change the “loss price” to a non-zero value.
9.2.2 MVL Disks
MVL Disks are currently sold by the AP application and detailed investigations are
required to decide what can be done.
Here there are currently different stock products for each expiry date. Changing the
DVLA application to take this into account is considered to be outside the scope of
Impact, so it is assumed that it is sufficient to mange the stock of MVLs at the generic
level. Currently there is no link between DVLA Transactions and an explicit month’s
tax disk.
Te it is sufficient to know that a branch has 70 tax discs and not know that there are 10 for each
month from September 2004 to March 2005.
9.2.3 Other Tokens
It isn’t currently clear what these products are used for. They seem to be all
Electricity tokens of some sort, but it isn’t clear how they are used. They are assumed
to be related to AP Transactions. Detailed investigations are required to decide what
can be done.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
9.2.4 NRA Rods
Looking at these products there appear to be separate service products for a single
stock product (eg a Salmon licence can be sold as a number of different products
depending who it is sold to and for what period of time). There is little that can be
done here without Product re-engineering.
9.2.5 N. Lott. Chqs
This has been discussed as a potential product for re-engineering and it is proposed
that it is left uncontrolled until such re-engineering takes place.
9.3 CURRENT SUSPENSE PRODUCTS
This text was previously part of section 2.5.1.1.4.
Table 45 shows the products currently transacted as part of the Housekeeping menu
Nur
NS & I E/N dep To be withdrawn (handled by TCs in future)
cR ge
173 NS & 1 E/N warwi To be withdrawn (handled by TCs in future)
221 Loss A reedemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2858 Loss B redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2859 Loss C redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2860 Loss D redeemed To be withdrawn, however it needs to remain until
‘Suspense account reduced to zero.
829 Gain A redeemed To be withdrawn, however it needs to remain until
‘Suspense account reduced to zero.
2864 Gain B redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2541 Giro EN rept To be withdrawn (handled by TCs in future)
2542 Giro EN pay To be withdrawn (handled by TCs in future)
106 POL E/N Rec To be withdrawn (handled by TCs in future)
162 POL E/N Pay To be withdrawn (handled by TCs in future)
144 Prepurchase To Remain unchanged.
211 PrepurchseRdm To Remain unchanged
146 Gain Ato UR To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2862 Gain B to UR To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
223 Loss A to Table 2a To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2855 Loss B to Table 2a To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2856 Loss C to Table 2a To be withdrawn, however it needs to remain until
‘Suspense account reduced to zero.
2857 Loss D to Table 2a To be withdrawn, however it needs to remain until
‘Suspense account reduced to zero.
2655 Migrate-UR-Out a
To Remain unchanged
2657 Migrate-UP-Out To-be-withdrawn?.-Prebably-not.
To Remain unchanged
2654 Migrate-UR-In 2
To Remain unchanged
© [ DATE \@ "yyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPRO04.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by Gld
POL00038916
POL00038916
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.1
COMMERCIAL IN CONFIDENCE Date: 16/09/2004
Migrate-UP-In y
To Remain unchanged.
2600 Bur/rob loss u/p To Remain unchanged.
2601 Rdm Rob loss To Remain unchanged.
247 Loan to PO To Remain unchanged.
248 LoantoPOwdm To Remain unchanged
2164 Rem Surplus To Remain unchanged.
2465 Rdm rem shrige To Remain unchanged
2167 Rem shortage To Remain unchanged
21468 Rdm rem surplus To Remain unchanged
2177 FinalA/e surplus To Remain unchanged.
2178 Final acc def To Remain unchanged.
2530 Unpaid Cheque A to UP To Remain unchanged
2846 Unpaid Cheque B to UP This one should be withdrawn. However it needs
to remain until Suspense account reduced to zero.
2847 Unpaid Cheque C to UP This one should be withdrawn. However it needs.
to remain until Suspense account reduced to zero.
2531 Unpaid Chq A Redeemed To Remain unchanged
2851 Unpaid Chq B Redeemed This one should be withdrawn. However it needs.
to remain until Suspense account reduced to zero.
2852 Unpaid Chq C Redeemed This one should be withdrawn. However it needs
to remain until Suspense account reduced to zero.
2528 Voucher to U/P This one should be withdrawn. However it needs
to remain until Suspense account reduiced to zero.
2529 Rdm voucher This one should be withdrawn. However it needs
to remain until Suspense account reduced to zero.
2849 POL chq to up To Remain unchanged.
2848 POL chq up out To Remain unchanged
Table 45 — Current Suspense Products
Also need to define additional Housekeeping Transactions required. Specifically need
transactions to handle write-offs for things like local postage.
These will be agreed as part of the User Interface discussions.
© [ DATE \@ "yyyy" \* MERGEFORMAT ] Fujitsu Services Post Office Account Page 14
COMMERCIAL IN CONFIDENCE
File: EADPROO4.Impact_Release3_DP.doc Printed on 22/11/2002 2:20:00 by GiJ