Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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: Approved
Originator & Department: Gareth I Jenkins (Tel RASD
Contributors:
Approval Authorities
Name I Position I Signature I Date
Tony Drahota Manager RASD
Fujitsu Services Post Office
Account
© 2004 Fujitsu Services Post Office Account Page 1 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Chapter 0 -
Document Control
0.1 DOCUMENT HISTORY
Version Date Reason for Issue Associated CP/
f PinICL Nos.
0.4 16/03/2004 I First Draft issued for comment. None
0.2 08/04/2004 I Second Draft issued for comment. [None
0.3 29/04/2004 I Third Draft issued for comment. I_None
1.0 30/04/2004 I Baselined version None
14 16/09/2004 I Changes to include feedback from HLDs and CRs GP Gash-Dee}
CP 3787;
CP 3797;
CP 3823
GP-3843
2.0 20/12/2004 I Changes to include review comments and CRs CP 3843
CP 3842
cP 3844
CP 3888
0.2 Review DETAILS
Review Comments b)
Review Comments to:
Originator
Mandatory Review Authority
Name
RASD
Phil Boardman (*)
Development Design
Pete Jobson (*)
Phil Hemingway (*)
Martin Nixon (*)
Rex Dixon
Duncan MacDonald
‘Sudhanshu Agrawal
Peter Ashdown (*)
ITU
Janusz Holender
Customer Services
Reg Barton
Post Office Ltd
Karen Hillsden
Optional Review/Issued for Information
RASD
Allan Hodgkinson
Tony Drahota
Development
Bob Gurney
Nial Finnegan
Clive Williams
James Stinchcombe
Glenn Stephens
Dave Johns
Kevin Watson
Alan D'Alvarez
Roy Birkinshaw
Chris Baile
Trevor Leahy
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 2 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Roger Barnes
Roger Donato (*)
Tom Northcott
Walter Wright
Mark Scardifield
Simon Fawkes
Mark Ascott
Andy Scott
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
jon
[AUDIT] CR/FSP/006 Audit Trail Functional POA
Specification
[CDBT] EA/CDE/002 1.0 Branch Trading Reporting, Post
Management and Control and Office Ltd
Transaction Management 1 POA
Conceptual Design
[CDBTCR1] Changes to [CDBT] POA
[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
(eT) CT207¢ Commercial Terms for Impact I POA
Release 3 - Solution Build &
Test and Implementation
Stages (Branch Trading
Horizon Enhancements)
[CTRBAL] EA/HLD/005 Impact Release 3 - Counter POA
Design for Balancing, Rollover
and Stock Processing
[CTRDEC] EA/HLD/006 Impact Release 3 - Counter POA
Design for Declaration,
Correction and Revaluation
[CTSAIS] EAVIFS/005 1.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]} EAVIFS/011 Impact Release 3 - Report POA
Production User Interface
1 This isn't a stand-alone document but is Attachment I to [CT].
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 3 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
[DRSHLD] NB/HLD/026 DRS Host Application and POA
Workstation High Level Design
Delta for IMPACT Release 3
[DRSREP] CS/SPE/011 Network Banking End To End POA
Reconciliation Reporting
[DWhHLD) DW/DES/088 Data Warehouse Outbound POA
Data File Delivery HLD
[E2EBRS] BD/BRD/017 041 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
[HRSAPAIS]2 1.5 HR SAP 4.6B Interface Prism
Documentations
[HRSAPAIS1] I EA/HR/001 1.0 Horizon To SAP Human Prism
EAVIFS/015 Resources System - Pivot
Interface Specification
[LFSHLD] LFS/DES/003_I 4.0 LFS Host HLD POA
[MENU] SD/SPE/016 34.0 Horizon OPS Menu Hierarchy POA
[MIGOVW] EA/HLD/008 Impact Release 3 - Migration I POA
High Level Design
[MIGSTGY) SU/STR/OO7 07 IMPACT Programme S80 Post
Migration Strategy Office Ltd
[MISAIS] EA/IFS/006 4.4 Horizon to POL MIS AIS POA
[POLFSAIS] EA/IFS/003 POL FS AIS Prism
[POLFSMAP] POL/E2E/ 1.0 Mapping of Horizon products to I Post
DES/011 POL FS chart of accounts Office Ltd
EA/CDE/001 codes
[POLTIS] TIF S/008 Horizon to Post Office POA
Technical Interface
Specification
[RDMCHLD} RD/DES/056 Reference Data End to End POA
High Level Design for S80
(Impact, Track & Trace, +1
Sales)
[RDMIG] RD/DES/059 S80 Impact — Reference Data POA
Requirements to support
Functional Changes and to
control Migration
[RDMOD] RD/DES/057 RDMC / RDDS High Level POA
Design for S80 Impact
[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 Application Interface Post
BF/IFS/010 Specification Reference Data to I Office Ltd
Pathway
[RDTPSAIS] RD/IFS/018 RDMC to TPS Application Data I POA
Interface
[RECON] BP/SPE/034 Reconciliation definition POA
[RIPCNT] TD/SPE/010 Riposte 6 Message Server POA
Configuration for Counters
[RIPCS] TD/SPE/009 Riposte 6 Message Server POA
Configuration for
Correspondence Servers
2 We do not formally have a copy of this document. The relevant information is now all in [HRSAPAISI], however I've
retained this reference for completeness.
3 This defines the current interface from CBDB 10 HR SAP.
4 NBthis 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.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 4 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
[RIPDC] TD/SPE/O11 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
[SAPDP] EA/DPRIOO5 Impact R3 SAP Hosting Design I POA
Proposal
[SLA] SPR/MT/007 1.0 Service Level Targets for Post
CS/SLA/002 Horizon Services Office Ltd
[TCAIS] EA/IFS/002 1.6 POL Finance Systems to TMS / I Prism
Horizon Transactional
Corrections Interface
Specification
[TIPAIS] TINFS/O01 70 Pathway to TIP Application Post
Interface Specification Office Ltd
[TPSAGTHLD] I EA/HLD/010 TPS Agent HLD POA
[TPSDWHAIS] I DW/IFS/021 TPS Application Interface POA
Specification
[TPSMAP] AD/DES/047 Agent to TPS Mapping Table _I POA
[TPSPOLFS] EA/HLD/007 TPS POL FS Summarisation POA
HLD
[TPSOTHER] EA/HLD/009 TPS HR SAP Summarisation & I POA
Transaction Corrections HLD
[VOLS] PA/PER/033 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
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)
C112 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
© 2004 Fujitsu Services Post Office Account Page 5 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
cP Change Proposal (A formal mechanism within Fujitsu Services Post Office Account
for controlling changes)
CR Change Request (A formal mechanism within Post Office Ltd for controlling
changes and requesting changes to be made by Fujitsu Services)
CT Commercial Terms.
cTsS Client Transmission Summaries
CTT 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 to 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
HLD High Level Design
HR SAP The SAP System used by Royal mail Group's Human Resources fo pay
sub-postmasters
TU 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
NBSC Network Business Support Centre (?) This is the Help desk operated by Post Office
Ltd to support branch staff with business problems.
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
POL MIS. Post Office Ltd Management Information System
This is a Post Office Ltd system used to provide management information to Post
Office Ltd staff. This is sometimes referred to as the POL Data Warehouse and
should not be confused by the Post Office Account Data Warehouse which is used
for measuring service delivery and is internal to Horizon.
RDDS Reference Data Distribution Service
RDMC 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
SAP ADS SAP Advanced Distribution System
SLA Service Level Agreement
SLT Service Level Target
SU Stock Unit
Tc Transaction Correction
© 2004 Fujitsu Services Post Office Account Page 6 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
TIP Transactional Information Processing
Ts. Technical Interface Specification
TMS Transaction Management System
TPS Transaction Processing System
UIDP. User Interface Design Proposal
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 A term 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 A report providing a summary of what has happened within a Branch
Statement 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 returned. 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 behalf 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 A manual 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 fora Branch
Financial Institution ‘An independent organisation providing Financial services (usually
Banking or Debit Card)
Harvester A software Agent that transfers data from Riposte to a Host System
© 2004 Fujitsu Services Post Office Account Page 7 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Horizon That part of Post Office Ltd’s System developed and operated by Fujitsu
Services
Host Accomponent 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 middleware
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 A means of accounting within a Branch
Streamline Accompany 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 overall 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
© 2004 Fujitsu Services Post Office Account Page 8 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Trading Day The accounting day within a Branch. Itis 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.
Transaction This represents an EPOSSTransaction 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 2.0
Changes from version 1.1 are marked in red (like this) with significant deletions in red-
strikeout-(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:
= Incorporation of CPs 3842, 3843, 3844 & 3888
0.5.2 Changes in Version 1.1
This-is- called 4-1 , L Lh L sil beth
This supersedes various informal issues 1.1a through to 1.1b
Changes from version 1.0 to version 1.1a are marked in red (like this) with significant
deletions in red-strikeout-(ike-this). Changes from Version 1.la 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:
© 2004 Fujitsu Services Post Office Account Page 9 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= The breakdown of work between the various HLDs has now been included in
section 1.5
= 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).
0.5.3 Changes in Version 1.0
Changes from version 0.3b to 1.0 are marked in green (like this).
0.5.4 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-(likethis). 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:
= 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.5 Changes in Version 0.2
This supersedes various informal issues 0.2a through to 0.2d.
© 2004 Fujitsu Services Post Office Account Page 10 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Changes from version 0.1 to version 0.2a are marked in red (like this) with significant
deletions in red -strikeout-(like-this). 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.6 Changes in Version 0.1
This is called 0-4, , i sivenlationLh -se-will-be-O-
This supersedes various informal issues 0.1a through to 0.1c.
None. This is the first version.
0.6 CHANGES EXPECTED
0.6.1 Outstanding Design Issues
A number of areas of in the document require clarification. These are marked in
YeiHOW or BEBBH highlight in this working draft (as indicated):
= Yellow highlight indicates further investigation required within Fujitsu Services or
significant bits of text to be produced
= Green Highlight indicates a clarification of requirements is needed from Post Office
Limited.
Wherever possible a working assumption is recorded.
There are also a number of minor comments that require resolving that are made in a
distinctive style like this.
I’ve split such outstanding issues into three lists:
= Issues to be resolved by Post Office Ltd
am _ 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.
Section Issue Action On Date
None
Table 1 — Outstanding Issues on Post Office Ltd
Section Issue Action On Date
None
© 2004 Fujitsu Services Post Office Account Page 11 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
Table 2 —- Outstanding Issues on Fujitsu Services POA
The following table is here to provide an audit of issues resolved since version 1.0 and the
various intermediate versions of this DP. It will be removed at the next issue.
Section _ Issue Et ase Action : On __I Date
1.5.3 Define where “Protection against I Covered in [CTRDEC] af Closed
Data Loss” is to be covered in
HLD.
1.5.3 Define where “Reversal Control” I Email sent to Martin / Phil I Gld+PJ Closed
is to be covered in UIDP / HLD.
Also MiMAN
1.5.3 Define where “Protection against I Email sent to KW GH KW Closed
lost data at system start” and Done
“Change APS to use EPOSS
Core” is to be covered in HLDs.
1.6.1.1 What do we do about Training Decide and then raise a DR-+MK Closed
Mode? CR
I recommend killing it. Included in
PSO_CR00280
7611 ‘What do we do about Training I Depends on response GH Closed
Mode? from POL,
I recommend killing it. Killed!
2.3 Add section on Reconciliation Done Gi Closed
2.3.1 How do TCs work with Stock / Clarify requirement and KH+GR Closed
NAD / Mode SO. perhaps update AIS
2.5.1.1.1 Can we extend from 42 days? Trying to sort out a GI BR Closed
commercial offer for POL.
Can't be done
2.5.1.1.1 Sort this out with Karen Morley Email sent to Kevin Gd Closed
4 Watson re this
Doc provided by Roger
Goldring
2.5.1.1.2. Need to include migration No longer relevant Gt Closed
4 implications
2.6.1.1.2. Needs tidying Done Gid Closed
4
2.5.1.1.2. How do we capture Euro Stamp I Ensure that this is KA Closed
4 change? managed through OBC
Assumed done.
2.5.1.1.2 Confirm that none of these Assumed OK. KHARG Closed
4 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
2.5.1.1.2 What do we do with Postal CR Needed? KH Closed
4 Orders and their fees? CR 265 raised — under
discussion
Assumed to be withdrawn
2.5.1.1.3 Needs tidying. Done Git Closed
2.5.1.1.4 Emergency Suspense Are there any new Pe Closed
requirements coming out
of this?
CR Needed? No
All OBC
25.1.1.5 I Need to ensure picked up by Email sent to Kevin GH Closed
APS Watson re this
Assumed OK
2.5.1.4.7 What are UI implications? Await HLD info GW Closed
Dev
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 12 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
2.5.1.2.1 Confirm that it is OK to always If this is not the case, KHIBG Closed
follow the Cash Declaration then raise a CR
detailed dialogues OK
2.5.1.2.1. I Which way do the signs go? GH Closed
2
2.5.1.3.7. I How do we handle zeros? Now resolved GH Closed
1 Dev
2.5.1.3.8 What are the rules for deciding Clarified Dev Closed
what can be reprinted?
2.5.1.3.8 Stock Unit Balance Reports: Can reprint last TP KH Closed
Rollover and all BP
rollovers in the current
and previous TP
2.5.1.3.8 Counters Revenue Schedule No KH Closed
2.5.13.9 Report: _Is this still needed
2.5.1.3.11 I Need to complete this section Waiting for CR from POL I Gli Closed
Done
2.5.1.4.1. I Future of Parcel Traffic CR needed? KH Closed
1 No. This is to stay
2.5.1.4.1 Confirm that the described OK BS Closed
2 mechanism is OK
2.5.1.4.2 I Is Non-accounting Data check Yes KH Closed
still needed?
2.5.1.4.2 How do we remember the Leave to HLD Dey Closed
Suspense summary?
2.5.1.4.2 What if a SU rolls early?. How Leave to HLD fase Closed.
do we reprint BTS then?
2.5.1.5.3 Align with HLD Done GIdMN Closed
2.5.1.5.5 Move to 2.3 Done Ghd Closed
2.5.1.6.3 Are Roles configurable MN to update HLD MN Closed
2.5.1.7.1 Implications for isolated nodes? I Use EPOSS Watchdog, GH Closed
but need to link to other
docs
Covered in [CTRDEC]
25.17.14 Are the signs correct? Yes Gls Closed
2.5.1.7.2 Need HLD to be updated. Done Bay Closed
2.5.1.8 How do we handle CAP / TP Now in section 2.6.3.2.6 GHHRH Closed.
decision for MiMAN
2.5.1.8 Are the simple MiMAN changes Confirmed KH Closed
described adequate?
2.5.2.1 Is there an impact on RDT? No DMeD. Closed
2.5.2.4 Product Ids for new Events [RDMIG] will cover this Andy. Closed
Corbett
2.5.2.7 AIS Changes needed to handle Included in NS Closed
negative numbers PSO_CR00272
2.5.2.10 Confirm no problem with Included in KHENS. Closed
negative input PSO_CR00275
2.5.2.10 Clarify Signage Rules and Included in NS Closed
negative values in headers PSO_CR00275
2.5.2.12 Need to extend AIS to allow us Draft AIS changes GIERA Closed
to reject records that fail Ref These are currently in
Data validation. [TPSOTHER]
Done
2.5.2.12 Include CR 264 Done Gib Closed
2.5.2.14 Are there migration implications I No Ghd Closed
of this?
2.5.2.14 How to we interface to FRTS? Assumed OK GALRG Closed
2.6.1.6 Remove? Done Gis Closed
2.6.2 Complete details of FTMS Done Gl Closed
changes
2.6.3 Son of MiIMAN Added Ghd Closed
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 13 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.6.3.1.2 ls a POL FS Pilot required and if I CR 3870 has been raised I KH+RG Closed
so what is the scope and to address this
purpose? Out of Scope
2.6.3.1.3 I How do we suppress alerts on I There aren't any specified I GIS +RA Closed
missing TC files?
Do we actually raise them?
2.6.3.2.1 I Do some of these Suspense Included in KH Closed
9.3 account changes need to move PSO_CRO0268
to a later point?
2.6.3.2.5 How do we handle multiple Take the earliest CAP. GHLMN Closed
conflicting soft launches?
3.44 This detail needs to move to Done GHIMNE [Closed
[CTRBAL] PH
Table 3 —-Resolved Issues
0.7 CONTENTS
0.7.1 Table of Contents
CHAPTER 0 - DOCUMENT CONTROL...
0.1 DocuMENT HISTORY.
0.2 REVIEW DETAILS.
0.3 ASSOCIATED DOCUMENTS.
04 ABBREVIATIONS & DEFINITIONS.....
0.4.1 Abbreviations...
0.4.2. Definitions....
0.5 CHANGES IN THIS VERSION.
0.5.1 Changes in Version 2.0.
Changes in Version 1.1.
Changes in Version 1.0.
0.5.4 Changes in Version 0.3.0.0
0.5.5
Changes in Version 0.
0.5.6 Changes in Version 0.1.
0.6 CHANGES EXPEC
ED.
0.6.1 Outstanding Design Iss...
0.7 CONTENTS...
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 14 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
0.7.1 Table of Contents.
0.7.2 Table of Figures
0.7.3 Table of Tables...
CHAPTER 1 - INTRODUCTION..
Ll PRIVACY AND CONFIDENTIALITY ....00os0snssnnsnnnnnnnnnnunnninnnnnnmnnnnnnnnnnnn 21
1.1.1 Accuracy
11.2 Copyright...
1.2 SCOPE OF THE DOCUMENT 21
1.2.1 Scope...
1.2.2. Timescales and Phasing...
1.2.3 Potential for Change.
1.2.4 Requirements Out of Scope.
13 REQUIREMENTS OVERVIEW. 22
14 DocuMENT SUMMARY. 23
LS OTHER AFFECTED DOCUMENTS. ..csessonsennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnes 24
1.5.1 Counter High Level Design.eocssssssssssssssssssssssssssssssseessssssusssssssssssssussssiunsnnnseseesee 25
1.5.2. User Interface Design Proposals..... 25
1.5.3 Counter Index Check......
1.5.4 TPS Host High Level Design.....
1.5.5 Host Index Check.
1.6 DEPENDENCIES ON Post OFFICE LTD. 29
1.6.1 Exceptions.
1.6.1.1 Training...
CHAPTER 2 - SOLUTION OUTLINE DESIGN.
2.1 GENERAL, 31
2.2 OVERVIEW OF IMPACT RELEASE 3 COMPONENTS. sessed L
2.2.1 Breakdown of Horizon Systems.
2.2.2 Breakdown of Branch Systems.
2.2.3 Breakdown Of TMS.cocccccserssescerecseeieenseneereenes 35
© 2004 Fujitsu Services Post Office Account Page 15 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.2.4 Breakdown of Transaction Storage... .. 36
2.3 Mayor New END TO END CONCEPTS, 37
2.3.1 Transaction Corrections. 38
39
2.3.2 Reconciliation.
24 UNCHANGED PROCESSES..... 40
2.5 CHANGED COMPONENTS. 40
2.5.1 I Counter Components. 40
Branch Transactions. 40
Changes to Cash / Stock declarations and handling of variances. 49
Reporting...
Balancing and Rollover.
EOD. =
Logon Checks...
Process Transaction Correctior
MiMAN.
Removal of Tr
aining Mode...
2.5.2 Host Components...
2.5.2.1 RDMC....
2.5.2.2 LFS...
2.5.2.3 Process SAP ADS Transaction:
2.5.2.4 TPS Harvesting.
2.5.2.5
2.5.2.6
2.5.2.7 Generate MIS Info.
2.5.2.8 Transaction Summarisation.
2.5.2.9 Accept CAPO Data.
2.5.2.10 Generate HR SAP Info,
2.5.2.11 Generate POL FS Info.
2 Transaction Correction
2.5.2.13 POA Data Warehouse.
2.5.2.14 TPS Host.....
2.6 MIGRATION CONSIDERATIONS, 90
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.7 Upgrade of Counter processes to operate Branch Trading Statement........01. 93
2.6.2 Mapping of Changes to Migration Points. 94
© 2004 Fujitsu Services Post Office Account Page 16 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.6.3 Specific Migration Developments. 96
2.6.3.1 Data Centre Change:
2.6.3.2. Counter Change:
CHAPTER 3 - DATA MODE 102
3.1 GENERAL, 102
3.2 EXTERNAL INTERFACES. 103
B21 Reference Datd..s.cceccseseeriecsesvesverveeseeseessesieneessssesesseesseseesneaeensensesaessesneesseaneeseens 103
3.2.2 Transaction Corrections.
3.2.3 SAP ADS Transactions and SUMMATICS.......+..0 esses ieee eo sees teen tees teeneeetesseesseses 103
3.2.4 Ledger Entry Information. .. 103
3.2.5 TMS Info from Clients...
3.2.6 Remuneration Information.........
3.2.7 Management Info... 104
3.2.8 CTS Files... 105
3.3 INTERNAL INTERFACES. 105
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. 106
344 Stock-Lnit Summary for Branch Trading Report. 106
3.5 REFERENCE DATA CHANGES. 106
CHAPTER 4 - ENVIRONMENTAL CONSTRAINTS.
4.1 GENERAL, 109
42 TECHNICAL INTERFACE FROM SAP ADS...
43 TECHNICAL INTERFACE FROM NRDS..
44 TECHNICAL INTERFACES TO AND FROM POL FS..
4.5 TECHNICAL INTERFACE FROM EDS 110
4.6 TECHNICAL INTERFACE TO HR SAP...
47 TECHNICAL INTERFACE TO MIS...
© 2004 Fujitsu Services Post Office Account Page 17 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
48 TECHNICAL INTERFACE TO CTS..
CHAPTER 5 - NON-FUNCTIONAL REQUIREMENTS...
5.1 GENERAL. sossccsnsinnninennnininininnnniennansneniniie esntttnnnnnsnnninsennense cone 13,
5.2 AVAILABILITY. 113
1 Resilience.
5.3 USABILITY, 113
54 ‘VOLUMETRICS. 113
5.5 SERVICE LEVEL OBJECTIVES. 113
5.5.1 SLA Changes.
5.5.1.1 LFS..
5.5.1.2. TMS - POL-F!
5.5.1.3 Transaction Correction......
5.5.1.4 TMS — MIS (SAP ADS data).
5.5.1.5 TMS - MIS (Horizon data).
3 6 TMS ~-HR SAP.
5.5.1.7 TMS (CTS file).
5.5.1.8 TMS (FRTS file).
5.5.2 SLAs to be removed.
5.5.3. Unchanged SLAs
5.5.4 Migration Implications
CHAPTER 6 - TESTING AND ACCEPTANCE...
6.1 GENERAL. sosscnnnnstninnneninininninnnnnnnnennesnnaiee snnnnitninnnnennnntannnnnennsnsee cow L 18
6.2 PRODUCT TESTING. 118
6.2.1 Test Stages...
6.2.2. Test Environments
6.3 ASPECTS TO BE TESTED ...cscsssseiisnnsnssnn sissnnnnnnnnenensnennneinnensnnnnnnsnnnanes LED
6.3.1 Business functionality.
6.3.2 Performance.
6.3.3 Volume.
6.3.4 Integrity.
6.3.5 Resilience.
© 2004 Fujitsu Services Post Office Account Page 18 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
63.6 Recoverability (including backup and recovery, including disaster recovery
6.3.7 Networking
6.3.8 Security.
63.9 Supportability........
6.3.10 Manageability (system management).
6.3.11 Migratio
6.4 ACCEPTANCE. 120
6.4.1 Live Pilot..
6.4.2 Capacity Modelling...
CHAPTER 7 - MAPPING OF PROCESSES TO COMPONENTS...
7A GENERAL, 122
7.2 MAIN BUSINESS PROCESSES. 122
CHAPTER 8 - COMPLIANCE MATRICEG.....
8.1 GENERAL. onsecnnintcninnnisrnnnnnesnninnenennn sonnneteannnneennnnnennnnaen 124
8.2 COMPLIANCE MATRIX. sestntnnnnnennennnnnnsee . essen z crsenennenes L26
8.3 ADDITIONAL REQUIREMENT. 132
84 OTHER ASSUMPTIONS. 137
8.5 CHANGE REQUESTS. 141
CHAPTER 9 - RETAINED INFORMATIO!
91 GENERAL. orcsnnnisnniinnnnnninininnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnenmnnnnnennnnne LAB
9.2 NON-VALUE STOCK ANALYSIS. 143
9.2.1 Travel Schemes and Local Authority Vouchers.
9.2.2 MVL Disks...
9.2.3 Other Tokens...
9.2.4 NRA Rods.
9.2.5 N. Lott. Chqs.
9.3 CURRENT SUSPENSE PRODUCTS. 145
© 2004 Fujitsu Services Post Office Account Page 19 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 Storag
Figure 6 — Migration Timeline.....
Figure 7 — Ref Data Model for Articles.
0.7.3 Table of Tables
Table 1 — Outstanding Issues on Post Office Ltd...
Table 2 ~ Outstanding Issues on Fujitsu Services POA.
Table 3 —Resolved Issues...
Table 4 — Out of Scope Processe:
Table 5 — Document Structure...
Table 6 — Contents of [CTRBAL
Table 7 — Contents of [CTRDEC]
Table 8 — Contents of [DIAGREP]
Table 9 — Contents of [DIAGDEC
Table 10 — Contents of [DIAGBAL].
Table 11 — Counter Index Check...
Table 12 — Contents of [TPSPOLFS].
Table 13 — Contents of [TPSOTHER
Table 14 — Host Index Check.
Table 15 — External Interfaces...
Table 16 — Unchanged Processe: cesses
Table 17 — Riposte Configuration Changes.
Table 18 — Expiry Value Analysis.
Table 19 — Current Settlement Product:
Table 20 — Method of Payment Products.
Table 21 — Stock Products currently adjusted by Value.
Table 22 — Reports affected by Stock Changes...
Table 23 — Reports that can be reprinted.
Table 24 — Reports to be removed.
Table 25 — Current Weekly Report:
Table 26 — Additional EPOSS Events to be harvested.
Table 27 — POL FS File Delivery Information...
Table 28 — POL FS File Acknowledgement Information.
Table 29 — CTS File Receipt Information...
Table 30 — FRTS File Receipt Information.
Table 31 — HR SAP File Delivery Information
Table 32 — Transaction Correction Metrics.
Table 33 — Migration of Functions.
Table 34 — Migration of SLAs...
Table 35 — Mapping of Business Processes to DP Sections. .. 123
© 2004 Fujitsu Services Post Office Account Page 20 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Table 36 — Acceptance Mechanisms..
Table 37 — Compliance Matrix......
Table 38 — Additional Requirements Compliance Matrix.
Table 39 — Assumption
Table 40 — Sofi Change Request:
Table 41 — Hard Change Requests for S80...
Table 42 — Hard Change Requests for $90..
Table 43 — Categories of Non-Value Stock.
Table 44 — Current Suspense Products...
© 2004 Fujitsu Services Post Office Account Page 21 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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.
= 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.
© 2004 Fujitsu Services Post Office Account Page 22 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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 4:
Business Process Comment
Perform Transaction Checks — Periodic _I This will be handled by the Post Office MIS system
Summarise Cash Centre Transactions _I This will be handled by SAP ADS as at present
Table 4 — 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]
© 2004 Fujitsu Services Post Office Account Page 23 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
A number of further requirements were identified following the baselining of [CDBT],
which have been included in [CT] as Attachment 1.
A number of further Change Requests have been 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:
= Verification
= Other Data Capture
= 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:
Chapter Title Comment R
Chapter 2 - This is the bulk of the document
Solution Outline Design and describes all the new and
changed functions that are required
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 —_I requirements including any Service
Level targets
Chapter 6 = This describes requirements on
Testing and Acceptance Testing
© 2004 Fujitsu Services Post Office Account Page 24 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Chapter 7 - This provides a mapping from the
Mapping of Processes to Business functions described in
Components [CDBT] to the functional changes
described in Chapter 2
Chapter 8 - This is an appendix that formally
Compliance Matrices describes the compliance to the
requirements specified in [CDBT]
and subsequent Change Requests.
Table 5 — 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:
m= [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
= [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 [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:
= [REPREC] to define the new receipt layouts
= [VOLS] to include information on the volumes associated with the new data flows
© 2004 Fujitsu Services Post Office Account Page 25 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= [MENU] to update the Menu hierarchy
= [DRSREP] to remove the NB103 report
= [TIPAIS] can be withdrawn
= [AUDIT] will need updating to reflect changes to Auditing
= [RECON] will need updating to reflect reconciliation changes
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.
DP Section I Section Heading Description
2.5.1.1 Branch Transactions
25.1.3.2 Office Snapshot Report
2.5.1.3.3 Suspense Account Report
2.5.1.3.7 Other reports affected by changes.
to Stock Processing
25.1.3.8 Reprints of Reports
2.5.1.3.10 _I Weekly Reports
2.5.1.4 Balancing & Rollover
2.6.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 I Softlaunch menu changes to
CBDB suspense/housekeeping
2.6.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
2.6.3.2.4 Support of nRDS supported Assumed that there is no change in this
Settlement Products area
2.6.3.2.5 Support for Quiescent Rollover
3.4.1 Stock Unit Summary for Branch
Trading Report
Table 6 — Contents of [CTRBAL]
DP Section I Section Heading Description
2.5.1.2 Changes to Cash / Stock
declarations and handling of
variances
251.34 Remuneration Reporting
2.5.1.3.4 Counter Weekly Redeemed
Savings Stamps Report
2.5.1.3.5 APS Transactions Report
2.5.1.3.9 Reports to be removed
2.5.1.5 EOD
2.5.1.6 Logon Checks
2.5.1.7 Process Transaction Corrections
Section Variance Persistent Objects
removed
Table 7 — Contents of [CTRDEC]
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 26 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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].
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.
DP Section Heading CD Process Comment
Section
2.5.1.3.1 I Weekly Reports Produce Periodic Changes to the production of the office
0 Summaries summary reports (with cut-offs). New
reports, removed reports and changes to
report selection criteria
2.5.1.3.1_ I Remuneration Produce Sales New functionality around the entry and
Reporting Report to Assist validation of reporting criteria
Remuneration
Check
2.5.1.3.5 I APS Transactions Produce Other Changes to report layouts as a result of
Report Horizon Reports changes to the management of Stock and
2.5.1.3.7 I Other reports changes associated with the menu
affected by changes hierarchy in regard to additional and
to Stock Processing removed reports.
2.5.1.3.9 I Reports proposed
to be removed
2.5.1.3.2. I Office Snapshot Review Stock Held I Changes incurred to the Office Snapshot
Report Across Branch Report
25.1.38 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.1.3.6. I Event Log
Table 8 — Contents of [DIAGREP]
DP Section Heading CD Process Comment
Section
2.5.1.6.3 I Outstanding Receive Automated I Changes to the Logon process related to
Transaction Message the presence of outstanding Transaction
Corrections Corrections.
2.5.1.7 Process Transaction I Handle Transaction I Selection and processing of Transaction
Correction Corrections Corrections, including the reporting of
them.
2.5.1.2.1 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
2.5.1.2.2 Reporting of Cash Create Variance Menu, Dialogue and Report format for the
Variances
Report ... Compare
Generated with
Actual Cash Held
Across Branch
Cash Variance Report.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 27 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.1.2.3 Processing of Cash I Make Good, Hold Menu items and dialogues associated
Variances or Declare Any with the recognition and resolution of
Cash Variance and I Cash Variances.
Make Good or
Declare any
Outstanding
Losses
2.5.1.1.2. I Stock Revaluation Stock Revaluation Messages for user when revaluations are
3 approaching
2.5.1.1.2. I Stock Remittance / Rem In/Out Stock Changes to Stock Remittances and
1 Transfer Transfers resulting from Stock by
Volume.
2.5.1.2.4 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.
2.5.1.6.1 ONCH run for
“yesterday”
Table 9 — Contents of [DIAGDEC]
DP Section Heading _I CD Process Comment
Section She
2.5.1.4.1 Changes to Rollover I Produce Trial Dialogue for order and content of
processing Balance and warnings around new roll-over
Produce Final constraints. This will include all changes
Balance associated with both Individual and
Shared Stock Unit period rollovers as well
as changes to the Office Rollover
process.
2.5.1.4.2 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 Protection against
4 lost data at system
start
2.5.1.6.2 Stock Unit in correct
Trading Period
2.5.1.1.4 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 10 — 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
UI and HLD documents. The following table summarises this mapping and identifies
any sections which are not actually covered.
Section Heading UL HLD
2.5.1.1 Branch Transactions [CTRBAL]
2.5.1.1.1 Extending Transaction Retention
2.5.1.1.1.1 I Riposte Configuration Parameters
2.5.1.1.1.2 I Changes to the Expiry of Riposte messages
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 28 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
2.5.1.1.1.3 I Analysis of “unnecessary messages” and their removal
2.5.1.1.1.4 I Protection against lost data at system start
2.5.1.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. Stock Revaluation [DIAGDEC] I [CTRDEC]
2.5.1.1.2. Exceptional Products [CTRBAL]
2.544 Merging of Value and Non-Value Stock [CTRBAL]
2544 Changes to Suspense Products [DIAGBAL]
2.5.1.1 Change APS to use EPOSS Core
2.5.1.1 Settlement Transactions
2.5.1.1 Reversal Control [CTRDEC]
2.5.1.2 Changes to Cash / Stock declarations and handling of [CTRDEC]
variances
2.5.1.2.1 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
2.5.1.2.3 _I Processing of Cash Variances [DIAGDEC]
2.5.1.2.4 Stock Declarations and Variances [DIAGDEC]
2.5.1.2.5 Non-Value Stock Declarations
25.1.3 Reporting
2.5.1.3.1 Remuneration Reporting [DIAGREP] I [CTRDEC]
2.5.1.3.2 I Office Snapshot Report [DIAGREP]_I [CTRBAL]
2.5.1.3.3 Suspense Account Report [DIAGREP] I [CTRBAL]
2.5.1.3.4 I Counter Weekly Redeemed Savings Stamps Report [DIAGREP] I [¢TRDECT
NB
[CTRBAL]
says-itis-
Borer
this.
However it
doesn't
nae
anything-
yet!
2.5.1.3.5 I APS Transactions Report [DIAGREP] I [CTRDEC]
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.1.3.7.3 I Other Reports
2.5.1.3.8 _I Reprints of Reports [DIAGREP] I [CTRBAL]
2.5.1.3.9 I Reports proposed to be removed [DIAGREP] I [CTRDEC}
NB
[CTRBAL]
ra
covering.
this.
2.5.1.3.10 I Weekly Reports [DIAGREP] I [CTRBAL]
2.5.1.3.11_I Inclusion of Week Numbers in Reports
2.5.1.4 Balancing and Rollover [CTRBAL]
2.5.1.41 I 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.1.4.2 I Branch Trading Reports [DIAGBAL]
2.5.1.4.3 Remove Extended CAPs [DIAGBAL]
25.144 Selecting the next Trading Period
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 29 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
25.1.5 EOD [CTRDEC]
2.5.1.5.1 Removal of LFS Weekly Stock Reporting functions
2.5.1.5.2 I POL FS Summarisation at counter
2.5.1.5.3 I Maintenance of Office Variances Persistent Object
2.5.1.5.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 __I Protection against lost data
2.5.1.6 Logon Checks [CTRDEC]
2.5.1.6.1 ONCH run for “yesterday” [DIAGDEC]
2.5.1.6.2 I Stock Unit in correct Trading Period [DIAGBAL]
2.5.1.6.3 Outstanding Transaction Corrections [DIAGDEC])
2.5.1.6.4 I Protection against Data Loss [DIAGBAL] I 22
25.4.7 Process Transaction Correction [DIAGDEC] I [CTRDEC]
2.5.1.7.1 Actual Processing of the Transaction Corrections
2.5.1.7.2 _I Selecting Transaction Corrections
2.5.1.7.3 Reporting on Transaction Corrections
25.18 MiMAN NIA [CTRBAL]
25.1.9 Removal of Training Mode
Table 11 — Counter Index Check
1.5.4 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
which HLD.
DP Section I Section Heading Description
2.5.2.8.1 Initial Summarisation of Product and
Mode
2.5.2.8.2 Summarisation for POL FS
2.5.2.11 Generate POL FS Info
Table 12 — Contents of [TPSPOLFS]
DP Section I Section Heading Description
2.5.2.7 Generate MIS Info
2.5.2.8.3 Summarisation for HR SAP.
2.5.2.10 Generate HR SAP Info
2.5.2.12 Transaction Correction
2.5.2.14 TPS Host
Table 13 - Contents of [TPSOTHER]
1.5.5 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.
Section Heading HLD
2.5.2.1 RDMC [RDMCHLD]
2.5.2.2 LFS [LFSHLD]
2.5.2.4 TPS Harvesting [TPSAGTHLD]
2.5.2.5 DRS Host [ORSHLD)
2.5.2.6 APS Host N/AS
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 30 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
25.2.7 Generate MIS Info [TPSOTHER]
2.5.2.8.1 Initial Summarisation of Product and Mode [TPSPOLFS]
2.5.2.8.2 I Summarisation for POL FS. [TPSPOLFS]
2.5.2.8.3 _ I Summarisation for HR SAP [TPSOTHER]
2.5.2.10 Generate HR SAP Info [TPSOTHER]
2.5.2.11 I Generate POL FS Info [TPSPOLFS]
2.5.2.12 Transaction Correction [TPSOTHER]
2.5.2.13 I POA Data Warehouse [DWhHLD)]
2.5.2.14 I TPS Host [TPSOTHER]
3.5 Reference Data Changes [RDMCHLD]
Table 14 — Host Index Check
1.6 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)
o [HRSAPAIS] (Interface to HR SAP)
ao [HRSAPAIS]] (Interface to HR SAP)
a [MISAIS] (Interface to Post Office Ltd MIS System)
o [POLFSAIS] (Interface to POL FS)
co [RDSAIS] (Interface from nRDS)
a [TCAIS] (Interface from POL FS for Transaction Corrections)
a [POLTIS] (Technical Interface to Post Office Ltd)
1.6.1 Exceptions
The following requirements have been excluded from this DP:
= 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.
5 There are no APS host changes required.
© 2004 Fujitsu Services Post Office Account Page 31 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= The requirements for handling SAP ADS Transactions through TMS [BT 108] and
for supporting a feed from CAPO to be included in the feed to HR SAP [BT111]
have been excluded.
This reflects what has been agreed in [CT].
1.1.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.
In particular the current Training Mode functionality will be removed [PSO_CR00280
CP 3842]. See also sections 2.5.1.9 and 3.5.
© 2004 Fujitsu Services Post Office Account Page 32 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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.
rien I_Reterence Data R2
systems R2
__
tient Access R POLESRE
Bank Starnents R2
rmmncaen I 8 I
systems 2
3
i I Z I ctsries
4
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.
© 2004 Fujitsu Services Post Office Account Page 33 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
The interfaces (which are summarised in Table 15 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
Interface Name From To Ref I AIS Tis Comment
Reference Data POL Horizon I 3.2.1 I [RDSAIS] [POLTIS]
Client Access. Out of Scope
Bank Statements Out of Scope
Transaction Corrections I POL FS I Horizon I 3.2.2 I [TCAIS] NIA TIS is Internal
to Fujitsu
SAP ADS Transactions Out of Scope
and Summaries
Ledger Entry Horizon I POLFS I 3.2.4 I [POLFSAIS] N/A TIS is Internal
Information to Fujitsu
Remuneration Horizon I POL 3.2.6 I [HRSAPAIS1 I [POLTIS]
Information
Management Info Horizon_I POL 3.2.7_I [MISAIS] [POLTIS]
CTS File Horizon I POL 3.2.8 I [CTSAIS] [POLTIS]
Table 15 - 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:
a Terminals for user access to POL FS (and other systems)
a SAP ADS
o MIS
a Reference Data System
= 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.
= 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.
© 2004 Fujitsu Services Post Office Account Page 34 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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.
[ROWCRE
_eerence Data 2 Reterence Data R2
_
aoe [TusR2
I Ledger Entry Information R2_
I
systems R2 [ 7 [.___ctsFies
w23 ‘Transaction Corrections Aza
Figure 2 — Horizon Systems
The components are:
= RDMC
This is the existing Horizon RDMC.
Changes are described in section 2.5.2.1
= Branch Systems
These are the existing Horizon Counters. This is expanded further in section 2.2.2.
= Transaction Management
This is the new Horizon Data Centre functionality. This is expanded further in
section 2.2.3.
2.2.2 Breakdown of Branch Systems
Figure 3 provides a breakdown of the Branch Systems and the interfaces between the
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 35 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
components.
Reference Data R2
Transactions R2 ‘Transactions R2
]
I
I
I
I
Cash and [Reborn
Sock
Ld
‘Transactions R2
Declaration
Hi
R37
I
I
I
I
I
I
I
aa I
!
Process
“Transaction Conections Transaction
eters ig) Corecton
cash Deciaration
Togon Ghee
4
wea6
Figure 3 —- Branch Systems
The components are:
= Branch Transactions
This is the normal handling of 7ransactions 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.
© 2004 Fujitsu Services Post Office Account Page 36 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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
Storage Ro. I Ledger Entry Information R2
Management Info R2
Remuneration Information
Transactions R2 CTS Files
3
A24.3
Transaction Corrections Transaction Transaction Corrections
Correction
I fp
2
A2.4.2
Figure 4- TMS
The components are:
= 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.
© 2004 Fujitsu Services Post Office Account Page 37 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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 7ransaction 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.
PASS APS PS Glen
—< AP Transactions He AAP Transactions
= RE >I id
12 Transactions
7
crs Fies Fhace
Sie
Transactions R2 I vein! Transactions
™I Y
Dy] Temporary
‘Transaction Sofe
I o8C8 Transactions
y
P2435
(08CS Transactions
P2437
Transactions -Gererate¥$ Management info R2. [ POUWAS}
142 Transactions + > ine 3
DWP P2434 0R3 P24314
ee
‘summaries
BY Summary Sid aE
‘cenerte HR oF
Remuneration Summangs SAP! Remuneration infomat
> >
Pe4a6 POLFSR
‘Generate POL Leager Entry Infomation fi
Summaries FS into ier Ey Sf
>
Figure 5 — Transaction Storage
The components are:
= 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.
© 2004 Fujitsu Services Post Office Account Page 38 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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).
No changes are required. deseribed (However see also 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.
= 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.
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.
© 2004 Fujitsu Services Post Office Account Page 39 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.3 MaJor 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.
Two such concepts have been identified
= Transaction Corrections
= Reconciliation
These are discussed in the following sub-sections.
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.
The main purpose of this functionality is to enable financial corrections to be made to
the branch position. However it is also possible to adjust stock levels and correct
potential errors in the recording of non-accounting data. Both of these are done by
using the “Stock Write On / Off? Mode. In this Mode a Volume is specified rather
than a Value for the correction. It is not possible to amend both Volume and Value in
a single Transaction Correction.
In summary the process works as follows:
= 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 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.)
= 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
© 2004 Fujitsu Services Post Office Account Page 40 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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)
= 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.
= 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.3.2 Reconciliation
In general, reconciliation is unchanged, however there are currently some places where
there is reconciliation against the Cash Account and in general these reconciliation
checks are to be removed rather than being changed to reconcile against anything else.
The following summarises the reconciliation changes:
= APS Reconciliation
This is totally unchanged. Currently there are three aspects to this:
co Reconciliation of AP Transactions at the counter against those harvested to the
APS Host
o Reconciliation of AP Transactions sent to clients against those available in TPS
co Reconciliation of the AP Transactions sent to clients against the Client
Summaries
= DRS Reconciliation
This is unchanged to a large extent. The only change is that the reconciliation of
DRS transactions against the Cash Account information that has been sent to Post
© 2004 Fujitsu Services Post Office Account Page 41 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Office Ltd (covered by the NB103 report) is removed at the time that the OPTIP
interface is removed. This is discussed further in section 2.5.2.5
= EPOSS Reconciliation with TPS.
Currently there are 3 aspects to this:
o Reconciliation of the total value and volume of transactions that take place at
the counter against those passed to OPTIP.
o Reconciliation of the daily transactions at the counter against the cash account
as checked at the counter.
o Reconciliation of the daily transactions in the Host against the cash account.
The first check will remain (though it will be reconciled against the transactions
being passed to POL MIS rather than to OPTIP since POL MIS is in effect
replacing OPTIP). The other two checks will be removed since the cash account
will no longer be available. The changes are discussed further in sections 2.5.1.5.5
and 2.5.2.14.
It should be noted, that strictly the reconciliation should be changed to reconcile
against the POL FS feed rather than the POL MIS feed, however such a change
would introduce a number of complications:
co The detailed transactions passed to POL FS and POL MIS are not quite the
same, and so there would be migration issues in co-ordinating the changes to
the counter calculation of the reconciliation totals to align with the POL FS
data rather than the POL MIS data
a The transactions passed to POL FS are already checked as having a net value
of zero, which should be sufficient to identify any missing transactions.
Therefore it is proposed that no change is made and that we continue to reconcile
the counter transactions against the POL MIS feed. This approach has been
discussed with the Horizon operational support staff and they support this.
2.4 UNCHANGED PROCESSES
A number of the Business Processes described in [CDBT] require no functional
change. These are listed in Table 16:
_Business Process _ ESA i . I Comment
Perform Range Checks -Transaction ... Validate Data
Captured
Automated Reconciliation
Produce Daily Summaries
Verify Summaries
Despatch Redeemed Dockets
Input Non Accounting Data
Input Bulk Data
Input Additional Client Data
Investigate Balance Discrepancies
Roll Over Inactive Stock Units
© 2004 Fujitsu Services Post Office Account Page 42 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Table 16 — Unchanged Processes
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, BT050]
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
= 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
© 2004 Fujitsu Services Post Office Account Page 43 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.1.1.1.1 Riposte Configuration Parameters
The Riposte configuration is documented in three separate documents:
= Counters [RIPCNT]
= 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
branch by Day J. Feedback suggests that this is probably too risky so
MinMessageExpiry will remain at 34 days.
Riposte is currently configured as follows:
Platform Config Param Current Value _I New Value
Correspondence Server & Clients_I MinMessageExpiry 10 10
Counter MinMessageExpiry 34 346
Correspondence Server & Clients _I MaxMessageExpiry 37 50
Counter MaxMessageExpiry 37 50
Correspondence Server & Clients I DefaultMessageExpiry I 36 43
Counter DefaultMessageExpiry I 36 43
Table 17 — 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.
2.5.1.1.1.2_ 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].
2.5.1.1.1.3 Analysis of “unnecessary messages” and their removal
A quick analysis of a live counter shows the following Expiry Values
Expiry Value I Number Message Types Comment
of :
Message
s
34 5831 Persistent Objects Could well have lower values which are
[R14], [Recov] overridden by MinMessageExpiry
35, 18950 EPOSS Transactions etc Must be explicitly set.
36 8716 LPOs Probably defaulted
EOD Reconciliation
LFS
Total 33497
6 leit is unchanged
© 2004 Fujitsu Services Post Office Account Page 44 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Table 18 - Expiry Value Analysis
Two separate exercises have been carried out:
= Set the Riposte Configuration values as specified in Table 17 and run a counter
with a complete mixture of transactions and look to see what the Expiry values
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:
o LPOs
a Some LFS Messages (ie those containing <WAIndex:>)
o Print messages
co EOD Reconciliation messages (though many of these are likely to be removed)
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
identified in section 2.5.1.1.1.2.
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
© 2004 Fujitsu Services Post Office Account Page 45 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
vulnerable and so the Riposte Configuration parameter DisableArchiving must be set
to 1 (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] In particular, if this
is a new counter (ie a box swap) then DisableArchiving will be set to I as part of the
cold build.
Although 1 day is possibly a bit aggressive, with only 7 days between a “normal” 5 week
Trading Period and losing data, I 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
= 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.
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.
© 2004 Fujitsu Services Post Office Account Page 46 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 Volume Stock Transactions (beth-steck-and—nen-steck} may need to
include these Tertiary Mappings where they exist in addition to the current Primary /
Secondary Mappings, if dependant-zpon the Mode of the Transaction incurs a value
movement (ie SaleValue is not zero).
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. 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 “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. NB there is a
suggestion that Euro stamps are to be withdrawn which would also solve this problem
This should be a simple Reference Data change.
Table 21 (in section 2.5.1.2.4) identifies other products that are likely to present a
similar problem. All these products should continue to be managed by Value and so
have their mapping set appropriately and appear in reports as at present.
It is assumed that all of these exception products are removed.
However our current design will handle such products sensibly (other than not revaluing them).
© 2004 Fujitsu Services Post Office Account Page 47 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.1.1.3 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,
There are a number of requirements in terms of how Stock is to be handled in future.
BT055]
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. Now approved for S90.
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 report
is not actually used by SAP ADS, there is no need to wait until the interface is
removed before starting to remove non-value stock from the system.
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.
= 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 or-raise-suitable-CRs.
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:
The concept of “emergency suspense” is an operational workaround for when one or more
branches has incorrect Reference Data. In such cases, the process that they are asked to follow
© 2004 Fujitsu Services Post Office Account Page 48 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
by the NBSC is to record the transaction against a suspense account (eg Cash Surpluses C) and
when the Reference Data is corrected to reverse the transaction and record the correct
transaction.
There are two aspects of this:
+ If the “emergency suspense” products are still required, then we need to keep the buttons for them (or
introduce new ones)
+ If they are to continue to be “Suspense” products, does that mean we have to leave full access to the
Housekeeping Menu?
[Any changes here will be done using the OCP process
= 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 categories. 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.
These names are likely to change, however the concept will not. It is anticipated that such
changes will be handled as a result of normal OBC change.
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). [BT 102]
= 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. [BT 103]
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.
© 2004 Fujitsu Services Post Office Account Page 49 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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:
Product Numbers I Category Comment
10639 & 10990 Revaluations These appear to be historic and can no longer be
transacted.
11212 & 11213 Revaluations Currently used for revaluations.
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
Table 19 — 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 that we take the second approach. In particular, transactions
involving such products must not be sent to MIS and so the product Reference Data
© 2004 Fujitsu Services Post Office Account Page 50 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
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.
There are no User Interface implications with such a check, since there are already
checks in place as to which Transactions can be reversed and the same mechanism will
be used to inform the user that such transactions cannot be reversed.
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.
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 and replaced by a Daily Cash
Declaration. [BT 104]
© 2004 Fujitsu Services Post Office Account Page 51 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 particular, what this means is:
= Shared Stock Unit
When a declaration is requested:
co The user is presented with a list of the latest declaration for all Declaration Ids
that currently exist. They also have the option of "New Declaration" (and this
will be the only option if there are no existing declarations)
co The previous declaration is presented for updating (for a New Declaration this
will have zero for everything)
o When they complete the declaration it will be stored so as to over-write the
previous declaration for that Declaration Id. If they had selected "New
Declaration" they will be invited to enter the Declaration Id and will be warned
if this will result in over-writing an existing declaration with that Declaration Id
At desktop start-up, any zero value Declaration Ids which have a current value of
zero and “Make Good” amount of zero will be removed such that they are no
longer available. This is the only way to remove a declaration Id from the list
presented (ie Declare it with a zero value and wait until the next day).
= Unshared Stock Unit
When a declaration is requested:
co The previous declaration is presented for updating.
co When they complete the declaration it will be stored so as to over-write the
previous declaration (if any)
This has a number of implications:
= Normally for a Daily Cash Declarations, the user will have to update the previous
’’s declaration. This will mean having to clear out yesterday's figure before
in today's figures. For a Shared Stock Unit this can be avoided by always
choosing "New Declaration" and selecting the Declaration Id after the Declaration
and saying "OK" when asked if the old one is to be over-written. There is no
similar avoidance for Unshared Stock Units
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.
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.
© 2004 Fujitsu Services Post Office Account Page 52 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 I 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
system derived figure and again any differences will be recorded (as a variance) as part
of the appropriate event. [BT105]
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 Persistent Objects for each Declaration Id that has
been used within the current Stock Unit
Note that the current selection of Declarations restricts the choice to those Declarations made
since the last BP rollover. It is proposed that no such restriction is made here or elsewhere
where Declarations are selected for display.
2) For each Declaration Id being displayed need to include the following:
¢ Declaration Id
e User
¢ Date and Time of Declaration
© Node
3) 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)
4) If the user selects Continue, the current stock unit derived position is
calculated and compared with the sum of the declarations selected.
5) 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
6) 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.
© 2004 Fujitsu Services Post Office Account Page 53 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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
m 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
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)
= Shared Stock Unit Variance Check Complete with Discrepancy (Event Id 64)
© 2004 Fujitsu Services Post Office Account Page 54 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
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 variable Parameter
<P4>>-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:
= 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 belogically-deletedwt y
imilar-way-to-that ly-d vith-the- ONCH—#w—SS-
rather-th e-the Persistent Objects when-th th
eontent-should ben da : tt
Persistent-Object—Th H-aveid for.
Deleted Persistent Object +i}
tHeast Jes-after-+t Loft 4
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-t rrent ONCH Persist
t_ef-<arr—torwarddeelarati ' it 4h ay}
P Jd
single Persistent Object:
The manipulation and content of the Variance Persistent Objects is defined in
{DIAGDEC}{CTRDEC].
2.5.1.2.2 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 what when-theast-declarations have been made was-dene-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
© 2004 Fujitsu Services Post Office Account Page 55 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
3) 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.
4) 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].
The report is defined as providing data up to and including “yesterday”. Since much of
the report is prepared as part of the EOD process, then should the EOD process not
run for some reason (eg one of the counters is broken), then data for those days which
have not run the EOD process will be missing.
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. In the case of deleted
Stock Units, this may not change until the next week, however the value in such
Stock Units must be zero (it is not possible to delete a Stock Unit that has any
value in it or has carried out any Transactions in the current accounting period)
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.5.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)
© 2004 Fujitsu Services Post Office Account Page 56 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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.
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
These buttons will be available for any clerk to record the “making good” 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.
Note that if there is no current Cash Declaration for the Stock Unit (ie no Cash
Declaration has been made since the Stock Unit was last balanced or created), then the
Make Good or Remove Excess Cash processing will be rejected (see [DIAGDEC]).
Two separate events will be defined:
= Make good a loss (Event Id 59)
= 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]
© 2004 Fujitsu Services Post Office Account Page 57 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
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. 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 declaration2. This declaration may be an
update to any previous declaration made since the Stock Unit was last rolled over
(see section 2.5.1.2.1). 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:
© 2004 Fujitsu Services Post Office Account Page 58 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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.
= 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.
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 20 shows those items on the current Stock Adjustments menu that represent
“Methods of Payment” rather than actual stock products:
Product Number I Product Name Comment
2 Cheque
2642 Citibank Money Order
4 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
take place.
5 Unpaid Cheque
231 Encashed OB Cheq to CRU
278 POL Cheque
Table 20 — Method of Payment Products
These products should continue to be adjusted by value by the Stock Adjustments
function.
Table 21 shows those items on the current Stock Adjustments menu that are adjusted
by Value rather than by Volume:
Product Number I Product Name_ : Comment
15 Philatelic Items Other
17 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 21 — Stock Products currently adjusted by Value
These products should continue to be handled by value in all cases.
© 2004 Fujitsu Services Post Office Account Page 59 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
However POL are looking at removing these products and replacing them with alternative
products that can be handled by Volume. Any such changes are considered to be “Business as
Usual” and not specifically 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) [BT106]
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
= Suspense Account Report
= Counter Weekly Redeemed Savings Stamps Report
m_ APS Transactions Report
= Variance Reporting (see section 2.5.1.2.2)
= Stock Unit Balance Reports (see section 2.5.1.4.1)
= 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
= 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.
© 2004 Fujitsu Services Post Office Account Page 60 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Currently all reports have references to CAP within their headers. Changes will be
required to change this to a Trading Period identifier.
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. It should be noted that this will only
provide a guide, since it will not take into account issues such as the fact that lottery
transactions are paid for early and that the report doesn’t necessarily include non-
accounting data for which the Postmaster is remunerated. 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.
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 [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.
© 2004 Fujitsu Services Post Office Account Page 61 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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]
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.
© 2004 Fujitsu Services Post Office Account Page 62 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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]
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. Hopefully it is just bad
examples in [REPREC]. However there are some products listed in Table 21 (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:
Report Report Name Change defined
Classification
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
© 2004 Fujitsu Services Post Office Account Page 63 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Office Weekly Transfer Reconciliation See section 2.5.1.3.7.2
Office Weekly Unreconciled Transfers I 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
[ Return Advice Note See section 2.5.1.3.7.1
Table 22 — Reports affected by Stock Changes
2.5.1.3.7.1_ I Remittance and Transfer Reports
The general rule regarding Remittance and Transfer reports is that reports that indicate
specific transactions should show volumes and suppress values (for volume stock).
Reports that summarise remittances / transfers should suppress volumes and
summarise values (usually to zero for volume stock remittances / transfers). The
exception to this is the Office Weekly Remittances In / Out reports which summarise
by product rather than by remittance and so, on these, volume products should be
summarised by volume, and value products by value.
Th Fe cmt +5-sh hd rf }: d—h tock tt; it: t
P yout Bea; “any St
zero-value—thus-resulting-in-th Jue-colunan- Hy-being-2 i I
+h} +h +} I: +h tual 2
g 5 5 P
}j ieut: zah i} troters +} rath
partieutai hu tpu p
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 the Stock Unit Balance
report (see section 2.5.1.4.1.3).
It will contain two main sections:
o Value Stock and MOP
o Volume Stock
corresponding to the sections in the Stock Unit Balance report.
© 2004 Fujitsu Services Post Office Account Page 64 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
The Value column should be removed in the Volume Stock section and no Total is
required in that section.
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.
Report Name Comment
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 23 - Reports that can be reprinted
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”.
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.
= Frack-andFrace Manifest-Reprint
The current functionality is purely to reprint the last report produced. so no change
is required.
= 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
© 2004 Fujitsu Services Post Office Account Page 65 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 and they will be
printed in the new format.
= Stock Unit Balance: Reprint
= 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
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.
However it will also be possible to reprint all Balance Period reports for the
current and previous Trading Period.
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]
Report Name Comment
Counter Weekly DVLA V10
Counter Weekly DVLA V11
Office Weekly Counters Revenue Schedule And the ability to reprint it
Declaration and Confirmation — Non-Value [BT063)
Stock
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 24 — Reports to be removed
© 2004 Fujitsu Services Post Office Account Page 66 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 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
m 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.
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 25 lists all the current weekly report and highlights those that need to be
considered further.
Report Name i Comment Action Required
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 I 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 cut 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
© 2004 Fujitsu Services Post Office Account Page 67 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 2.5.1.3.8
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
Office Weekly Suspense Account No cut off None
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 25 — 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
anew 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.
© 2004 Fujitsu Services Post Office Account Page 68 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.1.3.11 Inclusion of Week Numbers in Reports
This change was introduced by PSO_CR00271 in CP 3888.
For a number of reports (listed below) Post Office Ltd require that in place of Cash
Account Week number a Client Accounting Week Number is printed.
The Client Accounting Week Number is to correspond to the period between midnight
on Wednesdays and is to be numbered from 01, starting at the beginning of the Post
Office Ltd accounting calendar (as identified in Type A Reference Data) each year.
Reports on which the Client Accounting Week is required:
G9901MA Daily Record of Deposits
G9902MA Daily Record of Withdrawals
P5589 Inland Revenue Tax Credits (and reprint option)
Counter Weekly Inland Revenue Tax Credits
P2311MA P&A Summary (and reprint option)
P2311MA (B) Batch Control Voucher
Counter Weekly Green/Violet Giros.
Counter Weekly P&A
Office Weekly P&A
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
a Selecting the next Trading Period
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
= Producing the Trial Balance / Final Balance report
© 2004 Fujitsu Services Post Office Account Page 69 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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_ I Checking that a Stock Unit is balanced
Some additional checks are required at this point:
= On the Final Stock Unit to be rolled over within the Branch
a 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):
= 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 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 the Local
Suspense account has been 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
It 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
negative 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).
© 2004 Fujitsu Services Post Office Account Page 70 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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
Mappings. These Tertiary Mappings will be in addition to the existing mappings
included on the Transactions.
Ifa 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 further lines will be required for Local Suspense Transfers.
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
© 2004 Fujitsu Services Post Office Account Page 71 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
I 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.
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 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
o 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.
a Cash and near cash (eg cheques and ForEx)
a 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.
Fhis-data-will-be-heldin-a Persistent Object-as-deseribed-in-section 3.44.
© 2004 Fujitsu Services Post Office Account Page 72 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.1.4.2 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]
Tt 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) The normal “Produce Report” screen is displayed
2) The Report tablet will include “Trading Period” and the current week
3) 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]
4) The report can then be built up as follows:
I The following is a high level outline. The detailed report is defined in [DIAGBAL]
a) Standard Heading
b) 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 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.
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-41)
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.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.4.4 Selecting the next Trading Period
When a Branch is rolling forward into the next Trading Period, it is necessary to
decide what the following period will be.
The current mechanism is fairly simple (ignoring extended CAPs which are no longer
supported at S80), namely that it will add 1 to the current “next CAP” number and if
© 2004 Fujitsu Services Post Office Account Page 73 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
the resulting CAP number exists in Reference Data, then it will set that as the new
“next CAP”. If that CAP number doesn’t exist, then it is assumed to be the end of the
year and so the Reference Data for CAP I of the next year is checked and if that exists
then “next CAP” will be set to this. Should this not exist either, then the rollover will
be prevented and an error displayed to the user.
With Trading Periods, the same approach will be followed. However given the
increased likelihood of running out of Trading Periods before the end of the year the
algorithm for setting “next TP” will be as follows:
= Add 1 to current “Next TP”
= Ifthe resulting TP number exists in the Reference Data calendar, all is well so exit
= Ifthe resulting TP number doesn’t exist in the Reference Data calendar, check for
TP 1 of “next year”. If that is found in the Reference Data calendar, use it
= If“next year” doesn’t exist yet, use the resulting TP (ie “next TP”+1). Note that in
this case the TP will not exist in the calendar so the normal prompts to the user
warning them that the TP is incorrect and on subsequent logons that the TP
doesn’t match the calendar will be output. However this is seen to be a better
option than forcing the branch to stay in the current TP until the end of the year.
[PSO_CR00278 3842]
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
= 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 Thursday
and Friday mornings and again on Friday evening, should be removed from the
Counter Applications Schedule since they are no longer required. [BT058]
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.
© 2004 Fujitsu Services Post Office Account Page 74 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.1.5.2 POL FS Summarisation at counter
This functionality was introduced as part of Impact Release I 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 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.
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
Variance Persistent Object.
It will also handle the bringing forward of data from previous days’ Variance Persistent
Objects in the case where no cash declaration is done (either where it is “forgotten” or
the Drawer / Stock Unit is unused for a day).
Then ti that-needs-te-+ bled. +h yt thieh-i+-+ Heulated-is:
= Suspense
a LoealSuspense
= Adjustments
Fk caleulated—by—seanninge—all_events—fi yesterday’s EOD—Marker—and
accumulating the net value ‘of -all-Cash- Made-Good-and-Excess-Cash Removed
events (Ids 89 & 58).
a Tr tion-Corrections Processed
This} leulated—b: + Fy i rar leti rar let
ry all -F i p' plete S-
tsi terday’s EOD Mark
a Transaction Corrections Outstanding
Fhis-is-caleulated-using +h ametogie-as-defined ti
= Stock Units notlogged-on-Today
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]
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.
It is proposed that this is achieved by providing a new function that merely calculates
the Daily Transaction Totals.
© 2004 Fujitsu Services Post Office Account Page 75 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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]
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.
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. [BT0S1]
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
Th 1 in the followi n.
© 2004 Fujitsu Services Post Office Account Page 76 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 to make a declaration at that time. [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 Trading
Period Calendars. [BT044] See also section 3.5.
2.5.1.6.3 Outstanding Transaction Corrections
This supports the Business Process Receive Automated Message.
In order to inform the Postmaster that a Transaction Correction has arrived in the
branch for processing, an 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 Process
Transaction Correction function immediately, provided that this is not an isolated
node. 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 is similar to that done at End of Day described in
section 2.5.1.5.6.
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 s
and so no counter functionality was required. Any counter work is therefore in addition to the
March 2003 costings.
© 2004 Fujitsu Services Post Office Account Page 77 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 Sccurity 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 Housekeeping
menu.
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.
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 which 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.
EPOSS Watchdog needs to ensure that Transaction Corrections are prevented on
isolated nodes. This is a Reference Data Change.
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] defines how the Transaction Correction is to be held as Attribute
Grammar.
© 2004 Fujitsu Services Post Office Account Page 78 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 UIDP 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+meanFCCRM?)
a Then, Cheque can be used instead.
[And so could Debit Card when CP 3785 is implemented. I
= 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.
= 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.
To protect against the product having a fixed price, thus resulting in a Value being
generated, the SW Mode will be defined as using a zero price for Stock by Volume
products.
Note that this will not solve the problem for a Stock by Value product. Should this
occur, then the Instruction Product will be used to settle any Value included on the
stack.
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 additienal-data-
client reference 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.
© 2004 Fujitsu Services Post Office Account Page 79 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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”.
2.5.1.7.2 Selecting Transaction Corrections
[CTRDEC] describes how a Transaction Correction is stored within the messagestore.
Transaction Corrections can be easily identified by having a <WAIndex.LFSFlag:TC>
attribute and <Data.Ref:> and <Data.Iter:> 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.
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.
© 2004 Fujitsu Services Post Office Account Page 80 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 [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.
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. This is discussed
further in section 2.6.3.2.6.
2.5.1.9 Removal of Training Mode
Training Mode is currently invoked through a button on the main menu.
This button is set up as part of the <Collection:DesktopApps><ObjectName:Training>
Type D Reference Data.
Training Mode will be disabled by removing this via a Reference Data change just
before Point 20. No attempt will be made to tidy up any Training Mode code or
remove any other Training Mode support.
This is in response to removed PSO_CR00280 (CP 3842).
2.5.2 Host Components
2.5.2.1 RDMC
© 2004 Fujitsu Services Post Office Account Page 81 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.2.2
2.5.2.3
2.5.2.4
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.
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.
Process SAP ADS Transactions
The requirement for this has been removed and so the rest of this section has been deleted.
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.
The following additional events are required: [BT1 10]
ID Product I Ti 2 Comment
55 2222 Trading Statement Created
56 2222 Trading Statement Period rolled
57 I 2222 Trading Statement Period Roll
_I___ I Abandoned __ a
58__I 2229 Excess Cash Removed Parameter required indicating amount
59 2222 Cash Shortage Made Good Parameter required indicating amount
60 2222 Cash Variance Report Previewed
61 2222 Cash Variance Report Printed
62 I 2222 Outstanding Transaction Correction Parameter required indicating number
Reminder Displayed of Transaction Corrections Outstanding
Table 26 — Additional EPOSS Events to be harvested
© 2004 Fujitsu Services Post Office Account Page 82 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 [{MISAJS} [RDMIG] 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,
Pouchld, Ref and AddRef into which these are harvested.
= 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 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. 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-NULL 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.
= 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
EPOSSCAP Office 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 R -e-the NB103 drilldewn-functionality-on-the DRS _Werkstati
= Ina number of the NB102 reports the CAP column will be blank.
© 2004 Fujitsu Services Post Office Account Page 83 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
This is achieved without changing the DRS code since no attempt is made to copy
data for NULL cash accounts.
Other than that the reconciliation process remains unchanged. [BT059]
It is expected that all these changes can be achieved through standing data and
Maestro changes and no code changes are actually required. See [DRSHLD] for
details. [DRSREP] describes the changes to the DRS Reports.
2.5.2.6 APS Host
No changes are needed here.
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.
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.
© 2004 Fujitsu Services Post Office Account Page 84 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
2.5.2.8.1 Initial Summarisation of Product and Mode
All Transactions are summarised by Product / Mode combinations such that for cach
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
© 2004 Fujitsu Services Post Office Account Page 85 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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.
2.5.2.8.3
2) If the Article Mode is described as being “non-summarised”, then the
underlying transactions need to be preserved without being summarised.
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:
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
Summarisation for HR SAP
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.
A separate set-ef 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
© 2004 Fujitsu Services Post Office Account Page 86 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
numbers of branches not required are fairly low - it is the Directly Managed Branches
of which there are about 600).
Since [HRSAPAIS1] requires the data passed across to be predominantly positive (ie
for both in-pay and out-pay transactions to be passed as positive counts, and only
having negative amounts where any reversals / corrections exceed the number of actual
transactions). In order to achieve this the accounting sense of the product needs to be
ascertained from the product Reference Data and those transactions identified as out-
pay transactions need to have their signs reversed as part of the summarisation
process. [PSO_CR00275 3843]
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 and HR SAP Groups
(specifically Lottery transactions for franchised offices), 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.
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. 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. [BT 112]
This supports part of the Business Processes Deliver Data to External Systems.
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 in a 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
© 2004 Fujitsu Services Post Office Account Page 87 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.2.11
2.5.2.12
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 which will generate any file currently due,
however-a-parameter-will be-required-indieating (whether to-prod he-files for
the “multiples” or for the bulk of the branches). 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. All data should be sent even if a branch has been closed.
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.
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—caleulati fh iber—of
+r; sacti is—ale dy—being ad ff + 1, ot MIS—a: dther is dt
ealeulate-this—Any differences (eg due to exceptions) can be ignored.
Transaction Correction
This functionality will be done within the TPS Host system.
© 2004 Fujitsu Services Post Office Account Page 88 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
This component takes the file produced each night by POL FS of Transaction
Corrections and passes them on to the specified Branch. [BT113] The file is described
in section 3.2.2
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. Failures in the File
Header or Trailer will result in the entire file being rejected.
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. This is covered in PSO_CRO00264 (CP 3844)
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)
m_ FRTS File Delivery (Outbound)
= HR SAP File Delivery (Outbound)
= 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:
© 2004 Fujitsu Services Post Office Account Page 89 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Field Name Value Description
File Id Name of the file
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 The FAD Code of the sub-file
Table 27 — 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, when TPS copies the file to POL FS, an acknowledgement record must be
generated by-FPS that confirms the date/time that each sub-file was delivered to POL
FS. This record must be in the following format:
Field Name_I Value Description
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 The FAD Code of the sub-file
Table 28 — POL FS File Acknowledgement 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.
2.5.2.13.2 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.
2.5.2.13.3 CTS File Delivery
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 I Value Description
File Id Name of the file
Source TPS The source of the SLA
Dest cTsS 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
© 2004 Fujitsu Services Post Office Account Page 90 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 29 — 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.
2.5.2.13.4 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 _I Value : : Description
File Id Name of the file
Source TPS The source of the SLA
Dest FRTS The destination (ie: FRTS)
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 — 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 Warchouse will need to be updated to accept NULL FAD Codes.
2.5.2.13.5 HR SAP File Delivery
It is assumed that
= 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 cach 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
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 successfull delivery,
© 2004 Fujitsu Services Post Office Account Page 91 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.5.2.13.6
2.5.2.13.7
TPS will send the following information to the MIS system in the existing MIS SLA
delivery file:
Field Name Value Description
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
delivery date (where ‘n’ is defined by
a TPS System parameter — currently
expected to be 3)
D_Date The delivery date/time of successful
delivery of the HR SAP File
Records The number of originating This will always be ‘1’ since we are
transaction records measuring the file rather than the contents
FAD_Code The FAD Code of the sub-file NULL. FAD Code is not relevant
Table 31 — 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.
SAPADS to MIS File Delivery
The requirement for this has been removed and so the rest of this section has been deleted.
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:
Item Description
Metric This defines the type of data being loaded (le: Transaction Corrections). The value
for this will be ‘TO01"
Receipt Date I This is the date/time that the data was made available to TPS.
Table 32 — Transaction Correction Metrics
© 2004 Fujitsu Services Post Office Account Page 92 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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)
m= The new events being harvested by the TPS Harvester (see Table 26 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.
= In order to support the new Transaction Modes introduced by Transaction
Correction processing the check constraint "Transaction_Mode_Id in (1, 2, 3, 4, 5,
7, 8,9, 10, 11, 12, 13, 14,15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28)"
will change to include new modes (29,30,31,32,33,34) to the list.
This change will affect all transaction tables and take place at Migration Point 10.
= In order to simplify TPS Host processing the following check constraints will be
added (at Migration Point 10):
o "TRADING_DATE" is not null
This change will affect all Transaction and Event tables.
= 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 40 in the
migration process (see also section 2.6):
o “BALANCE PERIOD" is not null
a balance_period >= 0
a "CASH_ACCOUNT_PERIOD" is not null
a cash_account_period >= 0
This change will affect all Transaction tables.
SSC see the above constraints as the primary candidates for causing harvester exceptions
They also see missing Start Date for causing a small number of harvester exceptions in the
past. But this check constraint must be kept as the Agents usually derive the missing value of
Start Dates
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
© 2004 Fujitsu Services Post Office Account Page 93 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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
= 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
a The checks on the Branch Reconciliation Totals generated at EOD should
continue
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.
= Changes are required on the current interface of Bureau transactions to FRTS,
since the control file includes summaries based on CAP.
The working assumption is that we should summarise by Margin Product and
Transaction Mode Code (ie ignore 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.
2.6 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 full migration design has been agreed.
There are a number of assumption in this section which are recorded in section 8.4
2.6.1 Migration Overview
Figure 1 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.
© 2004 Fujitsu Services Post Office Account Page 94 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Point 10 Point 20 Point 25 Point 30 Point 40 Point 50
We rom CBDB/OPTip From
Switch fo new I I
yours OPTip fed off I
Phase A I I Phase C
“~
San Tie
in ALL frances
POL FS
capa
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-Count feware- Upsrade (Point 45)
= Upgrade of Counter processes to operate Branch Trading Statement (Point 50)
([BT114]
These are described in more detail below.
2.6.1.1 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, 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.
It 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.
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
Page 95 of 146
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 R1 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.
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.
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
© 2004 Fujitsu Services Post Office Account Page 96 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.6.1.5
2.6.1.7
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
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.
In addition there are various other changes to the Horizon Host systems to complete
the migration process at this point.
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
Should tt ter_rollout_be—delayed ber—of-el: r ired—to—tt
This-is-not-as-good-as-what-is_proposed-below-with-aRollover- Triggered Soft- Launch and tit
partiewlar-may-introduce-problems-for-a-Branch-that-doesn-t-complete-its-rollover-until-the]
“AP-on-We . sine vould. b i POL-KS!
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”.
© 2004 Fujitsu Services Post Office Account Page 97 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.6.2 Mapping of Changes to Migration Points
Table 33 shows at which migration point each aspect of the functional changes
described in section 2.5 will change. The points are described in section 2.6.1 above.
Section Functional Change Mig Comment
Point
2.5.1.1.1 Extending Transaction 10/
Retention 20
2.5.1.1.2 Stock to be handled by Volume I 50
rather than by Value
2.5.1.1.3 Merging of Value and Non- N/A See section 2.6.3.2.3
Value Stock
2.5.1.1.4 Changes to Suspense Products I 30- Also Error Notices and Vouchers are to be
aad disabled at this point
50 There are also some new Housekeeping
functions to be introduced at the same time.
H Local introduced
until Roint 50.
2.5.1.1.5 Change APS to use EPOSS 20
Core
2.5.1.1.6 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.5.1.4.7 Reversal Control 20
2.5.1.2.1 Changes to Cash Declarations _I 20
2.5.1.2.2 _I Reporting of Cash Variances _I 20
2.5.1.2.3 Processing of Cash Variances I 20
2.5.1.2.4 Stock Declarations and 50
Variances
2.5.1.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 Office Snapshot Report 50
2.5.1.3.3 I Suspense Account Report 20
2.5.1.3.4 Counter Weekly Redeemed 50
Savings Stamps Report
2.5.1.3.5 APS Transactions Report 20
2.5.1.3.6 Event Log 20 Though some new events will not be
generated until point 50
2.5.1.3.7 Other reports affected by 50
changes to Stock Processing
2.5.1.3.8 I Reprints of Reports 50
2.5.1.3.9 Reports proposed to be 50 Some may go at 20
removed
2.5.1.3.10_I Weekly Reports 50 May be able to do it at 20
2.5.1.3.11 I Inclusion of Week Numbers in 30
Reports
2.5.1.4.1 Changes to Rollover 50
processing
2.5.1.4.2 I Branch Trading Reports 50
2.5.1.4.3 Remove Extended CAPs 20
2.5.1.5.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.
2.5.1.5.2 POL FS Summarisation at N/A No Change required
Counter
2.5.1.5.3 Maintenance of Office 20
Variances Persistent Object
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 98 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
25154 I LFS EOD functionality changes I N/A I No Change required
to handle changes in Cash
Declarations
2.5.1.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.1.6.2 Logon Checks: Stock Unit in 50
correct Trading Period
2.5.1.6.3 Logon Checks: Outstanding 50
Transaction Corrections
2.5.16.4 Protection against Data Loss 20
2.5.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
2.5.1.7.3 Reporting on Transaction 50 Can't introduce this before Transaction
Corrections Corrections are supported.
2.5.1.8 MIMAN 20
2.5.1.9 Removal of Training Mode 10 - This is a ref data change and so needs to
20 happen at a fixed time. It should be OK to
do this at any time between 10 and 20 and
must be done before the counter is upgraded
to S80.
2.5.2.1 RDMC 10
2.5.2.2 LFS 10 Now that the change is being managed by
the LFS Harvester, this can be done at Point
10
2.5.2.4 TPS Harvesting 10
2.5.2.5 DRS Host 40 + to-the-DR; kstati M7 i
to-be-delayed-
tion is-that th bed th
Sametime
2.5.2.6 APS Host N/A No changes
2.5.2.7 Generate MIS Info 40
2.5.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.
2.5.2.10 Generate HR SAP Info 25
2.5.2.11 Generate POL FS Info 25
2.5.2.12 Transaction Correction 25
2.5.2.13 POA Data Warehouse 10
2.5.2.14 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.
Chapter 4 I FTMS 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 33 - Migration of Functions
© 2004 Fujitsu Services Post Office Account
Page 99 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 33, 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
a Switch of TMS feed of Transactions from OPTIP to MIS
o Generate HR SAP Info
= Counter Changes
o Process the final cash account for CBDB
ca Upgrade of Counter processes to operate Branch Trading Statement
co Merging of Non-Value and Value Stock
a Support of nRDS supported Settlement Products
a Support for Quiescent Rollover
co MiMAN change
o Reprinting Reports
These are described further below
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 process. However some processes will be
designed such that they will test a 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.
CP 3870 has been raised to capture the costs for achieving a Cut-over Rehearsal. The
proposed approach is as follows:
© 2004 Fujitsu Services Post Office Account Page 100 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
m The Live Maestro schedule is changed to take an export of key TPS Host tables
each night from Point 10 to Point 40.
= On 4 consecutive nights these exports are take from the TPS Host and copied to
exchangeable media
a The media is transported to FELO1
a The data is loaded onto the V&I Test TPS Host (one day at a time)
= The POL FS interface files are produced and written to exchangeable media
a The media is transported to Wigan
u The Data is loaded onto a test instance of POL FS
No formal request has been received from Post Office Ltd for such a Rehersal, so it is
outside the scope of this version of the DP.
Should-such-a-pilet-b: jred—then-it-will need-t t foll
Pi t 5 P*
The—-fé h noth 2—sysill be
a During the Pilot the existing S60-dataflowtoPOL FS will continue-as-normal
a I additi th tritial arisati pr d—_POL—F: arisati
pr 5 +d ibed-i ti 252 a 2-52-82} il-be-activatedt ther
iththe-POL-FS. +: tit F di ibed+ is 2 3. Hh
tht p tion-2.6.3.4-3-40-provide-the-
psuedo-S60-and-Opening Figures-flows-to POL-FS-
e- ACStFO-SE} edu e- i ensure-that the Live POE FS, feed is processed i ‘Sta cd
Point 30-CAP’
= Oth tasks that a £¢ ? 3 +P, +25 iy +: +}
a O +} jet lete—th rsistent-dat: tedin-POL-F: +of-
Ls ‘P 7 PF oS PS
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:
= Transaction Correction Processing is activated
However it is unlikely that any Transaction Correction files will be received until
some time later. day dlerting produced as #-restlt-of Tradsnetion Correction Files
d-at-thi
PP’
© 2004 Fujitsu Services Post Office Account Page 101 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.6.3.1.4
= The interface to POL FS is switched from the Impact Release 1 interface to the
Release 3 interface.
= 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.
= 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 concerned 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.
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
© 2004 Fujitsu Services Post Office Account Page 102 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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
Stock Unit or Branch rolling over into a specified CAP number defined in the Soft
Launch Reference Data.
This CAP will be flagged as requiring a Rollover Triggered Soft Launch (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:
a The report changes to include a week number (see section ) will take effect at this
point. [PSO_CR00271 3888]
a The Permissions should be changed on the Housekeeping menu to restrict access
Si hisis-a-elobal Ref Data hange-andit dt rf ph +-+to-dh +his-at
fixed-ti rE th. tate—T} for dat 4b a if: +: }
haw dt. 0—but-prier-t imt30—NB-it-st Idn2t tH +4} re +41}
-but-p Pp =
p, be ‘i b b :
i
hat-only-Me b
lystmed OK,
@ The existing Error Notice. Cash Shortage / Surplus and Vouchers buttons should
b ‘d- from the Housekeeping Menus since these functions at longer-to-
be-used.
Note-th +s—held. A. +s—that d-atthi int
te-that-any Pp ts-that-a: a point
i. Susp HF +t} rar ti +ntred: d-at-PointS0.
and POL-FS-generate-an-appropriate-Transaction-Correction-to-elear-the Susp!
item:
the H. keeping Menu etion-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:
= Each Stock Unit will rollover into a new “CAP” following the pre-S80 processes.
© 2004 Fujitsu Services Post Office Account Page 103 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
This CAP will be flagged as requiring a Rollover Triggered Soft Launch (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 33 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.
Mew FypeA Refer data. + bI that-th ting—Fype-C
Di iL: +i fF d- ts that-th
ata g-a-part a t 1¥e-that
A Refer Dat it jate-suffi d_net-clash-and. }
7 ‘PPFOP: -
t d-date-the-old-Refe data-and-start-date-tk reference-Dat
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. In
particular this change can take place while the counter is still at S75 (and in fact the
migration is simplest if this is the case).
© 2004 Fujitsu Services Post Office Account Page 104 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2.1.1.1.5 Support for Rollover Triggered Soft Launch
A new technique is introduced, that of a Rollover Triggered Soft 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.
= 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].
Note that if there are multiple Soft Launch products for Point 50, only the earliest
CAP will be used and the others will be ignored.
2.1.1.1.6 MiMAN change
Although the changed way of operating MiMAN will take effect from Point 20, there
is one significant impact on Migration. MiMAN will need to decide whether the
branch is to initially operate in Cash Account or Branch Trading Mode when it first
initialises the branch.
The way in which this is done is as follows
= Check to see if there is a cash account calendar present in Reference Data. If there
isn’t then we must be in a later year and so should operate in Branch Trading
Mode
a Check to see if there is an active Point 50 Soft Launch product for this branch. If
not we should operate in Cash Account Mode
= If there is check the CAP associated with that Soft Launch product and decide if
the dates for that CAP in the CAP calendar are before or after “today”. If the CAP
is in the future, then we should operate in Cash Account Mode, otherwise we
should operate in Branch Trading Mode.
2.1.1.1.7 Reprinting Reports
Report reprinting is fully covered by section 2.5
© 2004 Fujitsu Services Post Office Account Page 105 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Chapter 3 -
Data Model
3.1 GENERAL
Figure I 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
a Reference Data (section 3.2.1)
a Client Access (out of scope)
co Bank Statements (out of scope)
a Transaction Corrections (section 3.2.2)
a 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)
ca Management Info (section 3.2.7)
a 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)
a RDMC to TMS: Reference Data (interface unchanged — see section 3.5 for
details of content changes)
a Branch to TMS: Transactions (section 3.3.1)
co TMSto Branch: Transaction Corrections (section 3.3.2)
a Within Branch: Transactions (section 3.3.3)
= Data Stores
5 Variance Persistent Objects-(secti
© 2004 Fujitsu Services Post Office Account Page 106 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
o Stock Unit Summary for Branch Trading Report (section 3.4.1)
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].
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.
3.2.6 Remuneration Information
This is the interface to HR SAP and is formally defined in [HRSAPAIS1] which is
based on [HRSAPAIS].
At the time this DP was originally produced, [HRSAPAIS1] 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:
= That data will be provided one or two months in arrears as specified in the
summarisation Reference Data.
© 2004 Fujitsu Services Post Office Account Page 107 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= Two separate interfaces will be used:
a An initial 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.
= It is 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.
= 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.
= 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 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.
3.2.7 Management Info
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 [MISAIS].
The following summarises the main changes from [TIPAIS] to [MISAIS]:
= Changes due to removal of the Cash Account
The CAP and BP fields will be removed retained rth te i-be-null
the-branch-has 4 from Cash Account to-Trading Period (peint-50-in th
= 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 B5 and Bo 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.
© 2004 Fujitsu Services Post Office Account Page 108 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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 26.
= Rules for Signs
All Transactions are now to be passed to POL MIS with the signs used on the
Horizon Counter rather than as predominantly positive (which is how it is specified
in [TIPAIS]). [PSO_CR00272 3843]
= Record Identifiers changes
Record Identifiers have been changed to reflect the Additional Transactional
Information provided. [PSO_CR00272 3843]
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.
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.
© 2004 Fujitsu Services Post Office Account Page 109 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
3.4 DATA STORES
This is fully described in the various High Level Design documents.
Fell. rf Steck Unit Rellever- + - Obj} J: Jy Fit
Suman Intonation fon she. Balance Ropon to naopece the Branch Trading
Statement. This will be held in--a~ Persistent Object in a Collection called
“su. ” with an ObjectN LEGO? Caneh SS-is the Stock Unit N .
a Cash
a Other MOP
o OtherStamps
so ForEx
4 1B LE butt bhy-th be-obi b
LE } h ious Trading Period R
a Receipts-value-Total (excluding the following 6-items)
2 Remittance dr {Cash} Potal
o Remittance In-(Other-Stamps)-Fotal
es RemittanceIn(ForEx)-Total
o Fransferstntrom-otherSUs
a Fransfers-InfromLocal Suspen
a Pay ts-valuePotalexeludine the foll 6-itenas)
= Remititiess GattCastiy-boral
o Remittance Out (Other Stamps) Total
ao Fransfers-Out-to-Suspense
5 Fransfers-Outto-otherSUs
a Transaction Correcti Accepted
Lh he Belanee-Rep spart-of
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”
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
Page 110 of 146
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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.
= Include “Settlement Products” as part of normal Type A Ref Data.
= Inclusion of optional “loss price” on Product Reference Data for stock products.
= 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.
= Various Calendars
o Branch Trading Periods and allocation of branches to their calendar
co HR SAP Periods
ca 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.
= The Training Mode button will need to be removed from the Desktop
[PSO_CR00280 3842]
© 2004 Fujitsu Services Post Office Account Page 111 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
HORIZON POL FS
Product > article
C Dummy
Quantity (0)
“Article POL FS.
Mode” [2° I account (0)
[Settlement Type (0)
[Ledger Indicator (O)
HORIZON [——Summarisation
Mode
L_ Transaction Reference (O)
‘Movement Type (0)
Figure 7 — Ref Data Model for Articles
© 2004 Fujitsu Services Post Office Account Page 112 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Chapter 4 -
° °
Environmental Constraints
41 GENERAL
The Impact Programme is primarily concerned with application changes and there are
no significant Infrastructure changes other than in terms of new / changed technical
interfaces to other systems. This chapter is concerned with describing these Technical
(as opposed to Application) Interface changes.
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 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 deleted without
being marked as such.
4.3 TECHNICAL INTERFACE FROM NRDS
The existing technical interface will remain unchanged.
© 2004 Fujitsu Services Post Office Account Page 113 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
4.4 TECHNICAL INTERFACES TO AND FROM POL FS
The technical interface that was introduced as part of Impact Release I 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).
= These files need to be audited on despatch and receipt
This interface is no a fully two way interface in that it also needs to support the flow of
Transaction Corrections from POL FS to Horizon. The receipt of Transaction
Correction files needs to be monitored as follows:
= At least one file should be received every night Monday through to Saturday.
= More than one file may be received on any day and also a file may be received on a
Sunday night
= Should a file not be received when expected, then an alert needs to be raised so
that this can be investigated on the morning of the next working day. This alert
will be raised using the mechanism introduced for monitoring POL FS Error Files
at S60 in CP 3775. (Ie a message is written to the local application log which is
picked up by Systems Management and an Event is presented to SMC to process
according to KELs. A KEL would be provided to ensure that such an event
resulted in a call being raised on SSC to process on the next working day.)
[PSO_CR00276 3843]
4.5 TECHNICAL INTERFACE FROM EDS
POL have dropped the requirement for this, so remainder of section has been deleted without
being marked as such.
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”
a At the middle of the month to cover the bulk of the branches
© 2004 Fujitsu Services Post Office Account Page 114 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 before the required delivery date. 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.
= See section 5.5 for SLA requirements.
= These files need to be audited on despatch
4.7 TECHNICAL INTERFACE TO MIS
This is a new interface, however it is effectively the equivalent of the current OPTIP
Interface as defined in [POLTIS].
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:
= 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)
= 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:
a__ Approx Daily File Size: Assumed to be the same as for [TIPAIS].
© 2004 Fujitsu Services Post Office Account Page 115 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= Proposed Operational Schedule
This will continue to be passed across as soon as it is available (usually before
midnight).
= There are no SLAs associated with this interface
= These files need to be audited on despatch
© 2004 Fujitsu Services Post Office Account Page 116 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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.
5.5 SERVICE LEVEL OBJECTIVES
There are a number of aspects to SLAs:
= New/ Changed SLAs
© 2004 Fujitsu Services Post Office Account Page 117 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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:
= LFS — remains unchanged
= TMS - POL-FS — to be consistent with that being developed for S60
= 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 [CDBTCR1] 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.
In addition we will monitor the delivery of files to FRTS for completeness.
5.5.1.1 LFS
Stated Requirement: remains unchanged.
Proposal: 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 requirement is for Horizon to deliver the files to
POL FS by 03:00. Post Office Ltd has indicated that this should be taken as the SLA.
Proposal: The Service Level Target to be:
a 96% of Transactions to be delivered to POL FS by 03:00 on Day B
a 97% of Transactions to be delivered to POL FS by 03:00 on Day C
a 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
© 2004 Fujitsu Services Post Office Account Page 118 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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)
5.5.1.3 Transaction Correction
Stated Requirement: to be like Planned Orders — 95% by 08.00 and 100% by 24.00 —
both Day A.
This SLT appears to have been based on the previous version of the Horizon
agreement whereas, the current SLT for Planned Orders reads:
Provided data delivered by 06:00 from SAP ADS:
a 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.
The requirement as stated is self-contradictory.
Proposal: 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.
5.5.1.4 TMS — MIS (SAP ADS data)
POL have dropped the requirement for this, so remainder of section has been deleted without
being marked as such.
5.5.1.5 TMS — MIS (Horizon data)
Stated Requirement: by 03.00.
Proposal: 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
a 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.
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.
© 2004 Fujitsu Services Post Office Account Page 119 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Proposal: 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.
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: The overnight CTS file should be loaded onto the Horizon-Post
Office gateway by 07:307.
Proposal: 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:
= LFS Weekly Stock on Hand feed is being removed
= OPTIP Feed is removed
= Network Banking Report NB 103
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)
7 This requirement was not stated in [CDBT], but introduced as part of agreeing [CT]
© 2004 Fujitsu Services Post Office Account Page 120 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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 timetable:
Interface Point I Comment :
TMS - POL-FS 40 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 40 Date to be agreed
NB Counter won't process them until Point 50.
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 10 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 34 — 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.
© 2004 Fujitsu Services Post Office Account Page 121 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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
= Product Introduction Test (PIT)
= Direct Interface Test (DIT) tests new or amended interfaces to internal or external
systems
In particular a number of DIT tests are required:
I’ve excluded any SAP Hosting interfaces
a Interface from NRDS to Horizon (Reference Data)
a Interface from TMS to POL FS (Summarised Transactions)
a Interface from POL FS to TMS (Transaction Corrections)
a Interface from TMS to MIS (Horizon Transactions)
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
= Release Test (RT)
This also includes Migration Testing
© 2004 Fujitsu Services Post Office Account Page 122 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
= 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 I week CAP to a monthly Trading period and the corresponding increase in
message store sizes on the time for report production
= 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.
© 2004 Fujitsu Services Post Office Account Page 123 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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.
© 2004 Fujitsu Services Post Office Account Page 124 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/1 1/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
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 ensuring that all
these acceptance criteria are met other than in those cases where there are agreed
exceptions.
6.1.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.1.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.
© 2004 Fujitsu Services Post Office Account Page 125 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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
Process Name SA Ref DP UL HLD I Comment
: Section
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 - A4.1.1.2 24 N/A N/A No changes required
Transaction ... Validate Data
Captured
Automated Reconciliation A4.1.1.3 2.4 N/A N/A No changes required
Produce Reports and
Information
Produce Daily Summaries A41.2.1 2.4 N/A N/A No changes required
Produce Periodic Summaries I A4.1.2.2 2.5.1.3.10 I [DIAGR
EP]
Produce Sales Report to A41.2.3 2.5.1.3.1 [DIAGR
Assist Remuneration Check EP]
Verify Summaries A4.1.2.4 24 N/A N/A No changes required
Despatch Redeemed A41.2.5 24 N/A N/A No changes required
Dockets
Produce Other Horizon A4.1.2.6 2.5.1.3.7 [DIAGR
Reports EP]
Other Data Capture
Input Non Accounting Data__I A4.1.3.1__I 24 NIA N/A __I No changes required
Input Bulk Data A4.1.3.2 2.4 N/A N/A No changes required
Input Additional Client Data A4.1.3.3 24 N/A N/A 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 A4.1.6.1 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
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 126 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Make Good, Hold or Declare I A4.1.6.3 2.5.1.2.3 [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.1.7.1.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
AL]
Investigate Balance A4.1.7.3 24 N/A N/A No changes required
Discrepancies
Make Good or Declare any A4.1.7.4 2.5.1.1.4 [DIAGD.
Outstanding Losses EC]
Produce Final Balance A4.1.7.5 2.5.1.4.1 [DIAGB
Au
Produce and Confirm A41.7.6 2.5.1.4.2 [DIAGB
Trading Statement AL]
Roll Over Inactive Stock A41.7.7 24 N/A N/A No changes required
Units
Stock Revaluation A41.7.8 2.5.1.1.2.3 I [DIAGD
EC]
Summarise Transaction
Data
Scan Transaction for Day A4.3.1 2.5.2.4 N/A
Accumulate Transactions for I A4.3.2 2.5.2.8 NIA
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 2.5.2.3 NIA
Systems 25.2.6
2.5.2.7
2.5.2.10
2.5.2.11
Table 35 — Mapping of Business Processes to DP Sections
© 2004 Fujitsu Services Post Office Account Page 127 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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 36 contains the key.
Id
Description
Meaning
DR
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
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
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
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
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
Statement of fact
Where the solution to a Requirement is self-evident and does
not lend itself to formal proving.
Statement of obligation
Relates to requirements that represent either:
© Anexisting 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)
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 128 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Table 36 — Acceptance Mechanisms
© 2004 Fujitsu Services Post Office Account Page 129 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
8.2 COMPLIANCE MATRIX
Req ID I Description FS K Ref Rec I Comment —
4 ‘ , : Comp I I Rule : )
BTO01 Production of a balance report for a stock unit must be Yes 2.5.1.3 FST
possible to be produced within 5 times the current production
time for a stock unit with a busy transaction profile, long
trading statement period
BT002 Functionality not specifically identified to be changed within Yes 6.3.1 FST
this document must not be affected to degrade the existing
service provided by the Horizon system.
BT003 Migration to POL-FS must occur at the end of a financial Yes 2.6.1.4 SOF
period
BTOO07 The content and format of trial and final balance reports will Yes 2.5.1.4.1 FST
be altered as defined in [REPREC]s
BT008 A new trading statement report will be produced, the content Yes 2.5.1.4.2 FST
and format of which will be as defined in [REPREC]9.
BTOO9 A new variances report will be produced, the content and Yes 2.6.1.2.2 FST
format of which will be as defined in [REPREC]/0.
BTO16 Functionality to allow entry of date range on the of Sales Yes 2.5.1.3.1 FST
Report to be produced will be implemented within Horizon,
the system will verify that a valid date range has been
entered, If invalid it will allow re-entry, if valid it will produce
the existing sales report but with data covering the specified
data range.
BT024 A user with the appropriate role will be informed, at log on, Yes 2.5.1.6.3 FST I This has been rewritten as [BT024a]
that there are outstanding Transaction Corrections awaiting
processing, whenever there are any
8 — Wording changed as a result of Rep_Clar
9 Wording changed as a result of Rep_Clar
10 Wording changed as a result of Rep_Clar
© 2004 Fujitsu Services Post Office Account Page 130 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version
Date:
EA/DPR/004
2.0
20/12/2004
FUJ00090393
FUJ00090393
BT025
There will be a button for Transaction Correction
Management within the menu hierarchy which is only
accessible by users with the appropriate role. This will
provide the user with a list of the unprocessed Transaction
Corrections, displayed in date/time order. Having selected the
Transaction Correction to process, the system will display
text making clear what will happen when they select any of
the options presented, the user need not process the
transaction correction at this point//
For each Transaction Correction the user will have up to three
options — Each option, when selected, will perform an
identified set of transactions, defined within the Transaction
Correction. (this may include an option to Do Nothing
(requesting further investigation).
Yes
2.5.1.7
FST
BT026
At the end of performing a cash declaration, in a shared stock
unit, the system will enter, if the user chooses to, the cash
discrepancies function to support the identification of any
variance.
2.5.1.2.1
FST
BT028
Reminders for ONCH function to be performed at log on if not
performed previous day will be removed and, instead, the
system will remind users to perform cash declaration function
if it has not been performed on the previous day; there will be
no option to cancel without declaring/2.
Yes
2.5.1.6
FST
BT029
When the cash declaration has been made the figures for
denominational split will be passed to SAP-ADS as if an
ONCH declaration had been performed.
Yes
2.5.1.5.4
FST
BT032
A new function for recording a “make good” action will be
made available this will allow the user to enter the amount
made good. It will record the amount made good, making a
new declaration for cash by altering the previous declaration
by the amount made good. Amounts made good will be
reported on variance reports, balance reports and trading
statements
Yes
2.5.1.2.3
2.5.1.2.2
2.5.1.4.1
2.5.1.4.2
FST
BT036
Adjustments in stock (whether identified via adjustments or
stock declarations) should be adjusted at the adjustment.
price whenever defined in reference data.
Yes
2.5.1.2.4
FST
11 Wording changed as a result of Rep_Clar
12. Wording changed as a result of Cash Dect
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 131 of
146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
FUJ00090393
FUJ00090393
BT037 The Office Snapshot report will be redefined without stock Yes 2.5.1.3.2 FST
values as defined in [REPREC]/3.
BT038 Anew check is to be introduced after producing the Trial Yes 2.5.1.4.1 FST
Balance (ie when the “rollover” button is pressed prior to
producing the Final Balance). This check will act as follows:
1. Ifit isn’t the last Stock Unit to rollover, the clerk will
be advised that the Discrepancy is to be posted to a
“local adjustments” account. They have the option
of 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
Unit can be rolled over.
Local Adjustment will behave in a similar way to existing
Suspense Account items, namely the values will not be
associated with any Stock Unit, but is considered as part of
the overall Branch balance.
13 Wording changed as a result of Rep_Clar
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 132 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version
Date:
EA/DPR/004
2.0
20/12/2004
FUJ00090393
FUJ00090393
BT039
There is an existing report that shows the state of all
suspense accounts and all Transactions associated with the
suspense accounts during the Trading Period, indicating
which Stock Unit carried out the Transaction. It is proposed
that Local Adjustment transactions are included in this report
as with any other Suspense transactions
Yes
2.5.1.3.3 FST
BT040
Horizon should be changed such that only Supervisors and
Managers (etc) will be allowed to carry out Suspense
Transactions. The only exception to this will be the automatic
posting of Discrepancies to Local Adjustment.
Yes
2.5.1.1.4 FST
This has been rewritten as [BT040a]
BT041
The user will select the appropriate function which will display
the Trial Trading Statement (as per outlined report) and this
may be printed. When the user is content to confirm the
position he will be presented with a textual message which
describes the liability and responsibility which the postmaster
is accepting. If the postmaster accepts this the system will
record this action, print the Final Trading Statement and
commit an event which identifies that the agent has produced
the Trading Statement and accepted liability for the trading
position
2.5.1.4.2 FST
BT043
The confirmation event will be made available to the data
warehouse (POL MIS) to enable monitoring of who has and
who hasn't done a trading statement. The “confirmation
transaction” will not contain the constituent parts that make
up the trading position.
Yes
2.5.1.4.2 FST
2.5.2.7
BT044
A facility for different branches to operate on a different (four
weekly) branch trading calendar, will be implemented, which
branch is operating to which calendar is to be defined by
reference data.
2.5.1.6.2 FST
BT045
The current functionality for extending accounting periods
should be removed. The Horizon system should continue to
remind users to roll-over the accounting period if they logon
to a SU in the wrong Trading Period according to the
calendar.
Yes
2.5.1.4.3 FST
BT046
Revaluation functionality to be redefined such that the user is
reminded, for a series of days, at logon of an upcoming
revaluation (defined by Reference Data). The reminder will
suggest that the branch manager checks stock and makes
any adjustments prior to the price change
2.5.1.1.2 FST
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 133 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
BT049 The data retention period will be increased such that all Yes 2.5.1.1.1 FST
trading data is available within the Branch for a minimum of
42 days. _ jo ee ee I
BTOSO The data retention period will be increased such that all Yes 2.5.1.1.1 FST
trading data is available at the data centre for a minimum of
42 days. _
BTOS6 All stock items will be monitored throughout the Horizon Yes 2.5.1.1.2 DR
system by volume and not by value. FST
BTOS8 The existing Weekly Stock Holding feed to SAP-ADS will be Yes 2.5.1.5.1 POT
removed 2.5.2.2
BTO59 I There is a requirement to continue ensuring reconciliation Partly I 1.6.1 DR I Note that the changes in Section 21, Appendix C, of
between data flows which remain within the Fujitsu domain 2.5.1.5 [CDBT] are out of scope.
and ensuring that control totals are applied to any external 2.5.1.5.5
interface to allow detection of file corruption. All these 2.5.2.5
reconciliations should take advantage of the simplified 2.5.26
process described in Section 21, Appendix C, of [CDBT] 2.5.2.14
FUJ00090393
FUJ00090393
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 134 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
EA/DPR/004
Version 2.0
Date:
20/12/2004
FUJ00090393
FUJ00090393
BTO60
It is required that only reports that have previously been
printed can be reprinted; and that the reprint reports are
identified by date and time previously printed. The following
particular requirements are identified for report re-prints:
« 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 Period N+1 to Period N+2
* There is no need to reprint the Office Weekly
Counters Revenue Schedule, since the original
report has been removed
* For the following reports:
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 required
¢ The Track and Trace Manifest, currently allows
reprint of 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.
BT062
Yes
2.5.1.3.8 FST
This has been rewritten as [BTO60a]
Yes
25.2.5 I DR
BT063
The consolidated stock unit non-value stock report is no
longer required and can be removed. The check to ensure
that the consolidated stock unit non-value stock report is
produced as part of end of period processing will also be
removed
Yes
2.5.1.3.9 DR
2.5.1.4.2 FST
BTO65
A new Transaction Corrections report will be produced, the
content and format of which will be as defined in
[REPREC]I4.
Yes
2.5.1.7.3 FST
14 Wording changed as a result of Rep_Clar
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 135 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Table 37 — Compliance Matrix
8.3 ADDITIONAL REQUIREMENT
FUJ00090393
FUJ00090393
A number of further requirements have been documented following the baselining of [CDBT]. These have been agreed with POL and are
recorded here.
Req!ID Description FS X Ref — Acc I Comment
Comp Rule I
BTOO6 This requirement has now been removed
BT024a I A user with the appropriate role will be informed, at log on, Yes 2.5.1.6.3 FST I Last sentence added.
that there are outstanding Transaction Corrections awaiting
processing, whenever there are any. The dialogue informing
the user of this will include a button allowing access to the
“Process Transaction Correction” function.
BTO30 This requirement has now been removed.
BT040a_I Horizon should be changed such that only those Roles that Yes 2.5.1.1.4 FST I Roles clarified
can do an Office Balance (ie Manager, Supervisor, Migrate,
Auditor and Auditor - Emergency Manager) will be allowed to
carry out Suspense Transactions. The only exception to this
will be the automatic posting of Discrepancies to Local
Adjustment.
BT051 I Process for recovery situations when the Branch is nearing, I Yes 25.1.56 I DR I There is now a requirement on Fujitsu to support this
or has exceeded, 42 days since it produced the last Branch Post Office Ltd requirement
Trading Statement will be defined. However there is no requirement on Fujitsu to make
any specific changes.
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 136 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version
Date:
EA/DPR/004
2.0
20/12/2004
FUJ00090393
FUJ00090393
BTOS5
There is a requirement to control all items of stock. This will
be achieved through reference data by defining as controlled
products those products which are currently non-value
products
POL will review all non-value items and identify requirements
for redefining them as controlled stock items.
A document 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 they will be controlled accurately by this
redefinition and that for any products which cannot be
controlled in this way, requirements for bringing them under
control will be identified, documented and managed through
the change request mechanism.
Existing processes for transferring, testing and implementing
new reference data to the Horizon counter will be used to
make any identified changes. Existing Change Request
processes will be applied to new requirements identified
Yes
2.5.1.1.3
2.6.3.2.3
DR
There is now a requirement on Fujitsu to support this
Post Office Ltd requirement.
However there is no requirement on Fujitsu to make
any specific changes.
BTOS7
The following reports are no longer required and will be
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 cash Declaration report that we
need to retain)
* Office Weekly Cash Flow(this is replaced by the
Variance report)
* Cash Account Trial
¢ Cash Account Final
2.5.1.3.9
FST
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 137 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
BT060a I It is required that only reports that have previously been Yes 25.1.2.2. I FST
printed can be reprinted; and that the reprint reports are 4
identified by date and time previously printed. The following 2.5.1.3.8
particular requirements are identified for report re-prints:
"For Stock Unit Balance Reports and Branch Trading
Statements, the requirement is to be able reprint the last
report of each type generated.
™ There is no need to reprint the Office Weekly Counters
Revenue Schedule, since the original report has been
removed
"For the Cash Variance report the date range for which
the report is to be produced will be defined as part of the
reprint request mechanism. The report will be produced
from data stored during the requested period.
= For the following reports:
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
required.
=" The Track and Trace Manifest, currently allows reprint of
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.
= No other reports require reprints.
BT102 Horizon will be changed such that the menu hierarchy reflects I Yes 2.5.1.1.4 FST
changes made in the suspense products and allows users to
access the new products. _
BT103 I The buttons that allow Error Notices to be cleared and Yes 2.5.1.1.4 FST
Vouchers to be processed will be removed, since in the future
this will be achieved using Transaction Corrections
BT104 I The current ONCH button will access the common declare Yes 2.1 FST
cash functionality
© 2004 Fujitsu Services Post Office Account Page 138 of 146
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version
Date:
EA/DPR/004
2.0
20/12/2004
FUJ00090393
FUJ00090393
BT105
There will be a new Check for Variances function in the menu
hierarchy for shared stock units which will provide the current
functionality to sum up part cash declarations (only), using
the current algorithms for summing cash declarations in
shared stock units, and calculate any variance from the stock
unit derived cash position.
Yes
2.5.1.2.1
1
FST
BT106
The buttons for making declarations and confirmation of non-
value stock items will be removed from the menu hierarchy.
Yes
2.5.1.2.5
FST
BT107
A new Counter Weekly Redeemed Savings Stamps
mandatory report is required with similar content to the Office
Weekly Redeemed Savings Stamps Summary
Yes
2.5.1.3.4
FST
Reports defined in [CDBTCR1]
BT108
A daily feed of transaction details and summaries will be
accepted from SAP-ADS for passing to POL-FS and the MIS
No
2.5.2.3
FST
POT
Considered top be out of scope.
BT110
Horizon will store data for the following events and forward
the data to the POL Data Warehouse system;
"Trading Statement Created
"Trading Statement Period rolled
"Trading Statement Period Roll Abandoned
™ Excess Cash Removed
™ Cash Shortage Made Good
™ Cash Variance Report Previewed
"Cash Variance Report Printed
= Outstanding Transaction Correction Reminder Displayed
Yes
2.5.2.4
FST
BT111
A file of CAPO data from EDS will be received, the data will
be loaded into TMS such that the information can be merged
in with the data being sent to HR SAP each month.
2.5.2.9
FST
POT
Considered top be out of scope
BT112
Transaction Data must be summarised and generated into
files of information to provide base data for the payroll
calculations within HR SAP. This will follow the existing rules
currently used by CBDB.
Yes
2.5.2.10
FST
POT
BT113
The nightly file of transaction corrections will be loaded and
distributed to the appropriate branch systems for local
handling.
Yes
2.5.2.12
FST
BI114
Migration at S80 will be complex and will require the full end
to end participation in determining the exact detail. Each
migration step must be specified in detail to ensure integrity
of data and processes throughout the migration period.
2.6.1
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.
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 139 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
BT115 In circumstances where the Branch Trading Statement is not I Yes 2.5.1.1.1 FST
produced within the data retention period, the Horizon system 4
should attempt to retain the data for the entire period, subject 2.5.1.5.6
to hardware limitations and constraints.
BT116 The production of the reports below needs to change such Yes 2.5.1.3.10 I FST
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. An implicit cut-off
will occur 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 P&A P2311MA
« Office Weekly Pensions and Allowances
.
Table 38 — Additional Requirements Compliance Matrix
© 2004 Fujitsu Services Post Office Account Page 140 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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:
_DP X Ref I Assumption __I Comment
2.5.1.1.6 NRDS to provide Settlement Products and Now included in [RDSAIS]
35 Primary and Tertiary Mappings to Horizon
Lo via Type A interface
2.5.1.2.2 Variance Report only produces data up to It is understood that there may also be a
and including “yesterday” requirement to include some of today’s
data. However the detailed
requirements have not yet been
confirmed so this will be processed as a
CR once agreed
Post Office Ltd have decided not to
change this.
2.5.1.4.1 Stock Remittances / Transfers will be
3 excluded from the SU Balance report since
they are zero value.
2.5.1.4.2 I We assume all the Branch Trading report is I Confirmed in the detailed report
printed in single normal font. specification defined in [DIAGBAL]
2.5.1.7.1 I Note that there are potential requirements I There may be a future CR to bring such
to handle adjustments to both value and adjustments back into scope.
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 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
2.5.2.3 Requirement to process SAP ADS. Confirmed.
2.5.2.13.6 I Transactions is out of scope
3.2.34.2
8.3:
BT108
2.5.2.8.2 In situations where Horizon detects an error I There is an increased likelihood of this
in a POL FS subfile, the sub-file will not be 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 to MIS.
2.5.2.9 Requirement to process CAPO Confirmed
3.2545 Transactions is out of scope
8.3:
BT111
2.6 The following assumptions are made about
migration
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 141 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
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 cases, any
attempt to logon or attach to a
stock unit in the new CAP will
result in all buttons being inhibited
other than those that will support
CAP Rollover; Attachment to a
new SU; and Logout.
Detailed design now shows that this is
not desirable or necessary
The proposal now is that the menu
structure presented to users reflects the
current state of the Stock Unit and
Office in terms of whether they are
operating in CAP or TP mode
¢ — 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.
This is the current baseline. However
POL are 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.
It is understood that a CR will be raised
if a Pilot is to be operated, at which time
operating, infrastructure and test rig
costs will be assessed, i.e. costs for
Pilot operation are not covered by this
CT.
© 2004 Fujitsu Services Post Office Account
Page 142 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref: EA/DPR/004
Version 2.0
Date: 20/12/2004
* The flow to POL FS will conform to
the S60 AIS until we first pass
through the S80 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
$80 interface (but include a
Balancing account)
The details have now been changed
such that Point 25 has been introduced
for the change from the S60 AIS to the
$80 AIS. Also detailed data delivery
has been changed as a result of
CP 3823
«There may be circumstances
under which S80 Transactions
from Horizon get passed to POL
FS prior to the Opening Balances.
[POLFSAIS] now reflects this.
¢ — ForEx will continue to be handled
as a single account within POL FS
It is understood that a CR is likely to be
raised to change this.
PSO_CR00220v2 has formally
documents this change.
« 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
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.
This Point is now formally referred to as
Point 40.
« 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.
It is understood that POL procedures
will attempt to mitigate this risk.
Detailed design work will also attempt to
reduce the probability of this happening
The design now ensures that this will not
happen.
«There is no requirement to look at
old NB103's after CBDB switch off
3.2.6
The following assumptions are made about
the interface to HR SAP:
Once the AIS has been baselined, the
impact on the solution design will be
assessed and any changes in the
assumed requirement will be addressed
by CR.
All these assumptions have now been
confirmed in [HRSAPAIS1].
«That data will be provided one or
two months in arrears as specified
in the summarisation Reference
Data
© 2004 Fujitsu Services Post Office Account
Page 143 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
* Two separate interfaces will be
used:
o Aninitial feed for “multiples” (about
250 branches)
oA 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.
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.
¢ — Itis 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.
It is 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 or two months in
arrears.
¢ The Reference Data available at
the Data 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 summarisation
(eg following non-polling)
« — It is 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.
© 2004 Fujitsu Services Post Office Account
File: pteb4.doc
COMMERCIAL IN CONFIDENCE
Page 144 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090393
FUJ00090393
Ref.: EA/DPR/004
Version 2.0
Date: 20/12/2004
The following assumptions are made about
the interface to MIS:
Once the AIS has been baselined, the
impact on the solution design will be
assessed and any changes in the
assumed requirement will be addressed
by CR
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 50 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 BS and B6 of
[MISAIS] define the additional data
required.
Ithas been agreed that the
Quantity field can be extended to
accommodate Bureau Quantities
than having to hold it as an
some additional events that are to
be passed through to MIS. This is
also defined in Table 26.
44
It is assumed that all the interfaces are
either to POL FS (hosted by Fujitsu) or toa
single Gateway system in Huthwaite and so
covered by a single TIS ([POLTIS])
Will be removed as a duplicate
Will be removed as a duplicate
Requirement BT0859 is only partially
covered. In particular the reference to
Appendix C of [CDBT] (which is out of
scope) is excluded.
All the changed requirements identified in
this section are assumed to be applied to
[CDBT] and are consequently considered to
be part of the requirement.
8.3:
BT108
The Transaction Interface from SAPADS to
support the MIS data is out of scope
8.3:
BT111
8.5
The data flow from EDS for CAPO
Enlivenments is out of scope
Table 39 —- Assumptions
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
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 145 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Such changes will not result in a CP being raised.
= 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:
CR Number cP Title Comment
PSO_CR00210 I 3797 ‘Change to process for creating and content of Included with
NRDS to Fujitsu interface file PSO_CR00223v
2
PSO_CR00211 I Cash I Cash Declarations Now mandatory.
ect See
N/A section 2.5.1.6.1
PSO_CR00220 I 3823 Change to level of foreign currency detail from Included with
v2 Horizon to POL FS PSO_CR00241
PSO_CR00225 I Rep-C! I Changes as a result of User Interface Definition I Changes to
ar Work Requirements
NIA wording reflected
in Section 8.2
Table 40 — Soft Change Requests
CR Number cP Title Comment
PSO_CR00215 I 3787 ‘Suspense Report — ability to split cash in ‘Approved
pouches detail report from main suspense report I See
section 2.5.1.3.3
PSO_CRO0218_I 3823 Changes to Error rejection rules on POL FS AIS Approved
PSO_CRO00223 I 3797 Simplify the interface between NRDS and Approved
v2 Horizon (AIS version 6.4)
PSO_CRO0241 I 3823 ‘Changes to Branch Ledger AIS for migration and I Approved
cutover
PSO_CRO0263 I 3843 ‘Change format of Article field from Number (10) I No change
to Char(10) in all cases. required to this
doc
PSO_CR00264 I 3844 Change to the POL FS to Horizon TC Functional I No change
Specification and AIS required to this
doc
PSO_CRO0268 I 3842 Migration of suspense and error notices at S80 See section
and replacement of vouchers 2.6.2
PSO_CR00271 I 3888 Use week number instead of cash account week I See section
on Giro forms 2.5.1.3.11
PSO_CR00272 I 3843 ‘Changes to the Interface from Horizon to POL See
MIS; section 3.2.7
PSO_CR00275 I 3843 Amount/Volume Signs on the Horizon to HRSAP_ I See section
Interface 2.5.2.8.3
PSO_CR00276 I 3843 Error Processing on the Transaction Corrections I See section 4.4
Interface
PSO_CR00277 I 3843 Introduce a new value for Quantity in the No change
POL_FS_ARTICLE table required to this
doc
PSO_CROO278 I 3842 Trading periods — increase possible number See section
2.5.1.44
PSO_CR00280 I 3842 Remove Training Mode See section
2.5.1.9
PSO_CR00287 I 3844 Site Id for Branches No change
© 2004 Fujitsu Services Post Office Account Page 146 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
Tequired to this
doc
PSO_CR00289 I 3844 Change the name, format and relevant values for I No change
the field Dummy in POL FS Article entity in the required to this
RDS to Horizon interface. doc
Table 41 —- Hard Change Requests for S80
CR Number CP I Title Comment
PSO_CR00213 I 378 I Introduction of debit card option for settlement I Approved
5 _ I of Transaction Correction debt or discrepancies I Subsequently
arising from Branch Trading rollover withdrawn
PSO_CR00214 I 378 I Ni Cheques - the requirement to move the rem I Approved/s
6 out function from the stock pick list and place, Subsequently
as a separate icon, on the remittance menu. withdrawn
PSO_CR00227 I 378 I Formal Impact assessment of Smartpost Study CP Rejected
2 captured data being sent to S80 POL FS, May require changes to
POLMIS and SAP HR MIS Interface when the
E2E design is agreed
PSO_CR00243 I 381 I Change of non-value stock to controlled stock I Approved
3__I (MVL and NRA)
PSO_CR00288 I tbs I Inclusion of PO savings stamps in weekly Need a CP, but out of
redeemed savings stamps report and facility
for cut off.
scope of this DP
Table 42 — Hard Change Requests for S90
13 POL would like this brought forward to $80 if possible.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 147 of 146
Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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
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.
Prod Group Id I Group Name Numbe I Comments
é r
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 43 - Categories of Non-Value Stock
[Ms tem has 4702 Pre Pack Currency instead of N Lott Chgs.
Table 43 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.
© 2004 Fujitsu Services Post Office Account Page 148 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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.
© 2004 Fujitsu Services Post Office Account Page 149 of 146
COMMERCIAL IN CONFIDENCE
File: pteb4.doc Printed on 22/11/2002 2:20:00 by S
FUJ00090393
FUJ00090393
Fujitsu IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Services
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/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 44 shows the products currently transacted as part of the Housekeeping menu:
Product Number _I Product Name Comment
111 NS & I E/N dep To-be-withd: handled-by TCs in fut
GRexpected-to-change-this-
173 NS & I E/N wdrwi To-be- withdrawn {handied-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 To Remain unchanged
2657 Migrate-UP-Out To Remain unchanged.
2654 Migrate-UR-In To Remain unchanged.
2656 Migrate-UP-In To Remain unchanged
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 150 of 146
Printed on 22/11/2002 2:20:00 by S
Fujitsu
Services
FUJ00090393
FUJ00090393
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version 2.0
COMMERCIAL IN CONFIDENCE Date: 20/12/2004
2600 Bur/rob loss u/p To Remain unchanged.
2601 Rdm Rob loss To Remain unchanged.
247 Loan to PO To Remain unchanged.
248 LoantoPOwdrn To Remain unchanged.
2164 Rem Surplus To Remain unchanged
2165 Rdm rem shrige To Remain unchanged.
2167 Rem shortage To Remain unchanged.
2168 Rdm rem surplus To Remain unchanged.
2177 FinalA/c 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 reduced to
zero.
2529 Rdm voucher This one should be withdrawn. However it needs
to remain until Suspense account reduced to
zero.
2849 POL chg to up To Remain unchanged.
2848 POL chq up out To Remain unchanged
Table 44 — 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.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pteb4.doc
Page 151 of 146
Printed on 22/11/2002 2:20:00 by S