Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Document Title:
Document Type:
Release
Abstract:
Document Status:
Originator & Department:
Contributors:
Approval Authorities
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).
Approved
Gareth I Jenkins (Tel
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 145
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
Chapter 0 -
Document Control
0.1 DOCUMENT HISTORY
Version Date Reason for Issue Associated CP/
PinICL Nos.
0.1 16/03/2004 _ 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. None
1.0 30/04/2004 I Baselined version None
0.2 Review DETAILS
Review Comments by: Se Ld
Review Comments to: Originator
Mandatory Review Authority Name
RASD Tony Drahota
Bob Gurney
Phil Boardman
Development Pete Jobson
Chris Bailey
Phil Hemingway
Rex Dixon __
Duncan MacDonald
Sudhanshu Agrawal
ITU Janusz Holender
Customer Services Reg Barton
Post Office Ltd Torstein Godeseth
Dave Parnell
Optional Review/Issued for Information
RASD Allan Hodgkinson
Nial Finnegan
Tony Hayward
James Stinchcome
Development Dave Johns
Alan D'Alvarez
Roy Birkinshaw
Tony Heath
Trevor Leahy
Roger Donato
Walter Wright
Mark Scardifield
Peter Ashdown
Roger Barnes
Simon Fawkes
Mark Ascott
Andy Scott
ITU Peter J Robinson
Programmes Bill Reynolds
Customer Services Mik Peach
(*) = Reviewers that returned comments
© 2004 Fujitsu Services Post Office Account Page 2 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
0.3 ASSOCIATED DOCUMENTS
Reference Doc Vers-I Date Title Source
ion
[CDBT] EAICDE/002 I 1.0 Branch Trading Reporting, Post Office
Management and Control and Ltd / POA
Transaction Management
Conceptual Design
[CDBTCR1] ‘Changes to [CDBT] POA
[CDIAG] Ss Counter Err for ES R3 I POA
[CDPOLFS] BD/CDE/008 0.3 PO Ltd Financial Systems Post Office
Release 3 Conceptual Design Ltd / Prism
[CDPROG] AccCM-PCD 3.2 Accounting & Cash Post Office
CRICDE/006 Management Programme- Ltd
Release 1 - Conceptual Design
[CTRHLD] tbs impact R3 Counter HLD POA
[CTSAIS] EA/IFS/005 0.1 Horizon to POL Client POA
Transmission Summaries AlS
[DRSHLD] NB/HLD/003 DRS Host HLD POA
(OWhHLD] Data Warehouse HLD POA
[E2EBRS] BD/BRD/017 0.1 21/02/03 I Business Requirements - End to I Post Office
End Re-Architecting Post Office I Ltd
Product, Branch, Client, Cash
and Stock Processes & Systems
Feasibility Study
[EDSAIS] EA/IFS/004 0.1 22/03/04 I CAPO — Horizon Accounts POA
Activated AIS
[HRSAPAIS] tbs 1.5 HR SAP 4.6B Interface Prism
Documentation?
[HRSAPAIS1] EA/HR/001 0.01 I 14/04/04 I Horizon To SAP Human Prism
Resources System - Pivot
Interface Specification
[HRSAPAIS2] EA/HR/001! 0.01 I 14/04/04 I Horizon To SAP Human Prism
Resources System - Pivot 2
Interface Specification
[LFSHLD] LFS/DES/003 LFS Host HLD POA
[MENU] SD/SPE/016 32.0 Horizon OPS Menu Hierarchy POA
[MIGOVW] Impact R3 Migration Overview POA
[MISAIS] EA/IFS/006 0.1 Horizon to POL Data POA
Warehouse AIS
[POLFSAIS] EA/IFS/003 0.23 POL FS AIS Prism.
[POLTIS] TWIFS/008 Horizon to Post Office Technical I POA
Interface Specification
{RDDSHLD} RDBDS-HLD POA
[RDMCHLD] RD/DES/056 Reference Data End to End POA
High Level Design for S80
(Impact, Track & Trace, +1
Sales)
([RDMOD) tbs Reference Data Model for S80 POA
Aw N
This isn’t a stand-alone document but is an Annexe to the CT associated that is being produced based on this DP
This defines the current interface from CBDB to HR SAP.
NB we are aware of changes that are required from this baselined document. These are clearly indicated where relevant.
NB this is the current interface, 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: ptSe02.doc
Page 3 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
[RDRV] RDP/TEC/951 I 2.34 I 12/01/04 I Reference Data Rules and Post Office
RD/CSD/002 Values Ltd
[RDSAIS] RDP/AIS/014 5.2a I 05/07/02 I Application Interface Post Office
BFIIFS/O10 5 Specification Reference Datato I Ltd
Pathway
[RDTPSAIS] tbs Reference Data to TPS AIS POA
[RIPCNT] TD/SPE/O10 Riposte 6 Message Server POA
Configuration for Counters
[RIPCS] TD/SPE/009 Riposte 6 Message Server POA
Configuration for
Correspondence Servers.
[RIPDC] TDISPEIO11 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 Office
Service Levels and Remedies Ltd
[SAPADSAIS] PSO/IND/E2E/ I 1.06 SAP ADS to POL FS Application I Prism
SOL/016 Interface Specification
BP/DES/030
[SAPDP] tbs DP for Impact R3 SAP Hostin, POA
[SLA] SPR/MT/007 1.0 Service Level Targets for Post Office
CS/SLA/002 Horizon Services Ltd
fSFYLE} SDASTD/004 49.0 Horizon Office Platform-Sermice- I ROA
Style Guide
[TCAIS] EA/IFS/002 1.37. I 23/03/04 I POL Finance Systems to TMS/ I Prism
Horizon Transactional
Corrections Interface
Specification
[TIPAIS] TVIFS/001 7.0 Pathway to TIP Application Post Office
Interface Specification Ltd
[TPSAGTHLD] I tbs TPS Agent HLD POA
[TPSMAP] AD/DES/047 Agent to TPS Mapping Table POA
[TPSHLD] TPS Host HLD POA
[VOLS] PAIPERIO33__I 2.0 Horizon Capacity Management I POA
and Business Volumes
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 ABBREVIATIONS & DEFINITIONS
0.4.1 Abbreviations
Abbreviation I Definition
‘Acks Acknowledgments
4 NBthis is the current interface. We have not received a version for the S80 changes yet. It is assumed to be a later version
of the same document.
5 NB this is the current imerface. We have not received a version for the S80 changes yet. It is assumed to be a later version
of the same document.
6 NB Version 1.0 is the S60 interface. We have not received a version for the S80 changes yet. It is assumed to be a later
version of the same document.
7 NB we are aware of changes that are required from this baselined document. These are clearly indicated where relevant.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 4 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
payments directly to the clients.
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
ARL. Additional Remedy Level
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.
CBDB Counters Business DataBase. Post Office Limited’s current Accounting Systems
CCD Contract Controlled Document
cD Conceptual Design
CT Commercial Terms
CTS 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)
FTMS File Transfer Management Service
HLD High Level Design
HR SAP The SAP System used by Royal mail Group’s Human Resources to pay
‘sub-postmasters
ITU Integration and Testing Unit (within Fujitsu Services Post Office Account)
LOT Liquidated Damage Threshold
LFS Logistics Feeder Service
LPO Local Persistent Object
MI Management Information
MIS Management Information System
NB103 ‘A Report produced from the DRS reconciling Banking and Debit Card Trasnactions
against the Cash Account Period they were carried out in.
NBE Network Banking Engine
NRDS New Reference Data System (a replacement from RDS)
OBCS Order Book Control Service
OLA Operational Level Agreement
OMDB i
ONCH Overnight Cash Holding
OPS Office Platform Service
OPTIP Operational TIP
PO Ltd Post Office Ltd
POA Post Office Account
POL Post Office Ltd
POL FS Post Office Ltd’s Financial System
RDDS Reference Data Distribution Service
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
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 5 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
SU Stock Unit
TC Transaction Correction
TIP. Transactional Information Processing
TIs Technical Interface Specification
TMS Transaction Management System
TPS Transaction Processing System
0.4.2 Definitions
The following terms, when capitalised as here, have specific meanings as indicated.
Term Definition
Account An account within POL FS into which Transactions or Summaries are
posted.
The mapping of Horizon Products and the modes in which they are
transacted onto POL FS accounts will be defined in Reference Data.
Agent A component of the Horizon architecture which links Host Systems to
Riposte.
Note that it is used in other documents to refer to a person working in a
Branch, however in this document it is purely used to refer to the Horizon
‘System component
AP Clients Post Office Ltd’s Clients for the Automated Payment Service
Article A term used in SAP to represent a Product
Article Mode Aconcept 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
hope I've avoided it in this document!)
Branch Manager
The person responsible for the operation of a Post Office Branch
Branch Trading Statement I A report providing a summary of what has happened within a Branch during
a Trading Period
Card Account
The special Bank Account provided by Post Office for Benefit Payments.
Cash Account
The mechanism by which a Postmaster currently reports their liability to
POL
Cash Centre
A place where cash is prepared to delivery for Branches (and non-POL
destinations) and to which cash is 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 Accompany 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 Amanual mechanism by which the Central Post Office Ltd accounting
functions can request corrections are made to branch accounts following
various errors. This is to be replaced by Transaction Corrections.
FAD Code Unique identifier for a Branch
Financial Institution An independent organisation providing Financial services (usually Banking
or Debit Card)
Harvester A software Agent that transfers data from Riposte to a Host System
Horizon That part of Post Office Ltd's System developed and operated by Fujitsu
Services
© 2004 Fujitsu Services Post Office Account Page 6 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Host A component of the Horizon architecture that supports databases and
database processing
Huthwaite The location of Post Office Ltd's Data Centre
Impact The programme within Post Office Ltd which is making change to Improve
the accounting processes.
Loader A software Agent that transfers data from a Host System to Riposte
Logon The mechanism by with a user connects to the counter and identifies
themselves.
Maestro. The Job Scheduling software used within Horizon
Mails The SmartPost application used to aid clerks in calculating the postage
Tequired 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
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
Trading Day The accounting day within a Branch. It is defined to end 30 minutes after
the scheduled Branch closing time or 19:00 whichever is earlier.
Any transactions that take place after the end of the Trading Day are
considered to be part of the following Trading Day.
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.
© 2004 Fujitsu Services Post Office Account Page 7 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
[Watercard [A Smart Card used to top up Water meters. ]
0.5 CHANGES IN THIS VERSION
0.5.1 Changes in Version 1.0
Changes from version 0.3b to 1.0 are marked in green (like this).
0.5.2 Changes in Version 0.3
This is called 0.3c to allow for informal circulation. The formal issue will be 0.3
This supersedes various informal issues 0.3a through to 0.3b.
Version 0.3b has been put into PVCS as version 0.3 without further change.
Changes from version 0.2 to version 0.3a are marked in red (like this) with significant
deletions in red-strikeout-(like-this). Changes from 0.3a to 0.3b are in violet (like this).
Note that in some places where a section has had major changes I’ve not preserved the
original text to make the new description more readable. Such sections are clearly
marked.
Changes are primarily:
= 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.3 Changes in Version 0.2
[ This supersedes various informal issues 0.2a through to 0.2d. I
Changes from version 0.1 to version 0.2a are marked in red (like this) with significant
deletions in red-strikeout-ikethis}. Changes from 0.2a to 0.2b are in violet (like this).
Changes from version 0.2b to 0.2c are marked in green (like this). Changes from
version 0.2c to 0.2d are marked in brown (like this). Changes from version 0.2d are
marked in dark teal (like this).
Note that in some places where a section has had major changes I’ve not preserved the
original text to make the new description more readable. Such sections are clearly
marked.
Since most of the document has changed significantly, no attempt has been made to
summarise the areas of change here.
0.5.4 Changes in Version 0.1
Th Hed--td-to-allowfé 1 A The-f Pe I be-O-1
This supersedes various informal issues 0.la through to 0.1c.
© 2004 Fujitsu Services Post Office Account Page Sort45
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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
, HGUGISE or BABEH highlight in this working draft (as indicated):
= Yellow highlight indicates further investigation required within Fujitsu Services or
significant bits of text to be produced
= Turquoise highlight indicates that [CDBT] needs to be updated to reflect what is
stated
= 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
This has been further split into:
a Items that require clarification
These issues are now all closed.
a Items where the CD needs updating to reflect agreed clarifications
These are now formally defined in [CDBTCR1] and a compliance matrix has
been included in section 8.3.
= 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
Table 1 — Outstanding Issues on Post Office Ltd
Section __I Issue Action On Date
Table 2 Issues requiring updates to [CDBT]
Section Issue Action On Date
0.3 Ref and title needed for various Need feedback from Dev Dev
docs Unlikely to be available for
a while.
2521 Is there an impact on RDT? DMcD
© 2004 Fujitsu Services Post Office Account Page 9 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
232 Need to extend AIS to allow us to I Draft AIS changes Gi
reject records that fail Ref Data
validation.
3.2.3.2 Need to add SAPADS to MIS. Ignore for now since out of I TH
Interface into [MISAIS] scope
3.25 AIS needed (EDS) Fujitsu is authoring this. TH
Ignore for now since out of
scope.
42 Need to confirm approach Clarification from Dev GW
(Mark Ascott)
This may go away!
Assume that it will
5.5.1.3 Should this be OLA rather than BR
SLA?
5.5.1.5 Should this be OLA rather than BR
SLA?
Table 3 — Outstanding Issues on Fujitsu Services POA
The following table is here to provide an audit of issues resolved since version 0.2 and the
various intermediate versions of this DP. It will be removed at the next issue.
Section Issue Action On Date
0.3 Are all these docs needed? Some now removed. Gib
04 Needs updating and bringing in Done Ge
line
14 Needs updating and bringing in Left as is bond
line
1.6 Anything else to add? Need feedback from Bob BG
Done
22 Update diagram to change HR Diagram was correct Cle
SAP to SAP HR
25.1.1.1 Risk of lost data through mis- GlJ to produce proposal as I BR
operation to what we could do and
send to POL
Doc produced and sent to
POL 20/4.
Doc updated to cover this
scenario
2.5.1.1.1 Risk of lost data through mis- GIJ to produce proposal as I Gld
operation to what we could do and
send to POL
Doc produced and
circulated within Fujitsu
Proposal now included.
2.5.1.1.1.2 I ls DefaultMessageExpiry 42 or Done bees
432
2.5.1.1.1.3 I Need feedback from proposed HLD Www
experiments.
2.5.1.1.1.4 I No specific Requirement to BT115 PB
Protect against lost data at system
start in [CDBT]
2.5.1.1.1.4 I Is there a problem for the spare? _I HLD Dev KM
2.5.1.1.2.1 I Are there any implications on Will be taken into account I Walter
validation of fixed price products? Wright
© 2004 Fujitsu Services Post Office Account Page 10 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.1.1.2.1 I Can we move mappings to Assume we can do this BR
NRDS? unless we hear by
Thursday.
Flag to indicate Stock
items.
I've sent Daniel an email
on this. I will assume that
this can be handled as part
of the ongoing Ref Data
AIS discussions.
2.5.1.1.2.1 I What will happen to Rem We will still write them, but I Walter
Settlement Transactions? with zero value Wright
2.5.1.1.3 I No specific Requirement to Merge I BT055 DR
2.6.3.3 Value and Non-Value Stock in
[CDBT]
25.1.1.3 How do we take on previous non- I DP says adjustments BR
value stock as Value stock? Now have follow ups.
Doc produced on this and
sent to POL 20/4.
Assumed out of scope.
25.1.1.3 I Im preparing a separate note on I Doc produced and Gu
non-value stock for discussion circulated within Fujitsu
with POL and inclusion here later._ I Done
2.5.1.1.3 I need feedback on this from Dev_I Removed Ww
25115 I need to tidy this up Removed io
2.5.1.1.3.1 I Dev to confirm by HLD elites =
experimentation.
2.5.1.1.3.1 I Are there migration issues? HLD Dee
25.1.1.4 No specific Requirement to BT102 PB
rationalise suspense accounts in
[CDBT]
251.14 No specific Requirement to BT102 PB
introduce local suspense
accounts in [CDBT]
2.5.1.1.4 No specific Requirement to BT103 PB
remove error notices in [CDBT]
2.5.1.1.4.1 I A number of detailed clarifications I DP-—Ben—could-wealse- I DR
required aeep a counle of spares BG
Gld:-What does this-
Frean?
Need some specific
clarifications. Main issue
now is Migration accounts.
Also need to consider the
new Housekeeping
Products (though perhaps
as part of Counter
Dialogues).
Dave to Check with Ann
Clerk
Assume still needed
H/K Txns for Counter
dialogues
Closed
2.5.1.1.6 Migration issues Section 2.6.3.7 added Dev
25.1.1.6 Proposal is that Settlement POL to confirm that this is I DP
Products are provided bynRDS I OK
Assume “yes”
Now in 8.4
25.1.2.1 No specific Requirement to BT104 Pa
change cash declarations in
[CDBT]
2.5.1.2.1.1 I Needs updating following Done Ge
changed requirement
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 11 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.1.2.1.1 I Confirm no report required as part I Dave to confirm BR
of this. Confirmed.
2.5.1.2.1.1 I No specific Requirement to BT105 PB
introduce Check for Variances
Function in [CDBT]
2.5.1.2.1.2 I Is “Declaration Abandoned” ever I Clarification from Dev Walter
generated (and if so why)? Trivial question hepa
Clarified.
2.5.1.2.1.2 I Sort out impact of Events Clarification from Dev Pd
changes. Simple question
Clarified
2.5.1.2.1.3 I When should these be logically Clarification from Dev oes
deleted? Simple question
Clarified
25122 Should report include “today”? For now assume not, but
there may be a CR for this
in the future.
Now in 8.4
25.1.22 I Is variance report Manager ‘Assume it is generally DR
Supervisor only? available
POL to confirm.
Agreed.
25.1.2.2 Confirm assumptions about Dave to consider BR
handling deleted / created stock Assumptions not
Units in historical variance reports. I acceptable. Proposal re-
worked.
2.5.1.2.2 Needs updating to handle Deleted I Done Ghd
and New Stock Units.
2.5.1.2.2.1 I No specific Requirement reprint Change to BTO60 PB
Cash Variance Report in [CDBT]
2.5.1.2.3 Need to clarify exact requirements I Ben to feedback BG
of the variance report. Phil is discussing this with I RB
Dave / Ben (CD
inconsistent)
(email from Phil to Dave
19/4)
Further feedback from Ben
needed
Not an issue if Variance
Report is only up to
“yesterday” as stated in
[cDBT].
Closed
2.5.1.2.4 When do we get rid of vouchers?_I Assume at point C Ghd
2.5.1.2.4 I Are there any implications on No Walter
validation of fixed price products? eet
25.1.2.5 No specific Requirement to BT106 PB
remove Non-Value Stock
Declarations in [CDBT]
2.5.1.3 I need to tidy this up Done Gls
2.5.1.3.4 No specific Requirement to add BT107 PB
Counter Weekly Redeemed Report Defns added to CD
Savings Stamps Report in
[CDBT]
25.1.3.5 _I I need to provide something here._I Done GW
2.5.1.3.7.2 I How useful are Remittance / Ben Dave to consider BR
Transfer summaries with Stock by I Initial feedback received, BS
Volume changes? but needs further
consideration
Reports should remain “as
is”
2.5.1.3.7.2 I If these are still required and we Now have settlement PJ
are basing it in settlement products, however need
products what do we do? guidance from POL.
© 2004 Fujitsu Services Post Office Account Page 12 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.1.3.7.3 I Confirm that this can be done as_ I Confirmed. Ps
proposed
25.1.3.8 Dev to confirm correctness of Confirmed. Aw
proposal
2.5.1.39 I No specific Requirement to Covered by BTO57 PB
remove these reports in [CDBT] _ I This isn’t a Fujitsu
Requirement!
Requirement changed to
include Fujitsu
2.5.1.3.10 I No specific Requirement to BT116 a
change these weekly reports in
[CDBT]
2.5.1.4.1 Need to consider migration Done in 2.6.3.2. Gis
aspects somewhere.
2.5.1.4.1.1 I Tidy this up Done Gi
2.5.1.4.1.3 I Stock Remittances / Transfers will I Ben to consider BP
be excluded from the SU Balance I Initial feedback received, BG
report since they are zero value. _I but needs further
Is that what you want? consideration
Assumed OK.
Now in 8.4
2.5.1.4.1.3 I Dev to confirm this is correct Confirmed WwW
2.5.1.4.1.4 I Dev to confirm this is correct Confirmed WwW
2.5.1.4.2 Is there a need for an “Interim” No
Branch Trading Report?
25.1.4.2 We assume all the Branch POL to confirm DP.
Trading report is printed in OK
standard fonts and nothing fancy. I Now in 8.4
2.5.1.5.2 Need to complete this. Done Gls
2.5.1.5.3 Dev to provide feedback Clarified WwW
25.154 Need to confirm assumption that HLD can cover this. ee
BLOBs are no longer required
2.5.1.5.5 Need to complete this. Done Gl
2.5.1.5.5 Guidance on how we continue to I Leave Type C Ref Dataas I Rd
maintain “Derived Cash” is.
2.5.1.5.5 I need to sort out a few issues To be covered in 2.5.1.1.6 I Gt
here.
25.156 What process do we have for POL to consider BR
reporting to POL branches that No costs for this have
are “falling off the cliff’? been included.
BTO051
25.163 I Should the Logon Prompt go Yes PB
directly to the “Process CD to be clarified. Added
Transaction Correction” function? I to BT024
CD has no explicit requirement for
this.
2.5.1.7.1 Do these Options clash with No Ps
existing Modes? Dev to confirm
2.81.7.1 Some modes may need special HLD detail Pd
configuring
2.5.1.7.1 Need to understand settlement Clarification from Dev Po
implications on non-value TCs Simple Questions
Closed
25.1.7.1 I Confcall on Tuesday implies Updated AlS version 1.4 I DR
change to AIS and hence due
requirement. How is this to be Now received.
handled? However it doesn’t cover
the scenario of swapping
2 for Vodaphone phone
cards.
Now in 8.4
2.5.1.7.2 Do these Values clash with No Ps
existing Values? Dev to confirm
© 2004 Fujitsu Services Post Office Account Page 13 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
25172 Is there a sensible “start marker” Start of Message Store Ps
to use for this? Perhaps it is best
to go to start of Message store?
25.2.1 TBS Depends on completing DMeD
Ref Data Analysis and
production of an AIS.
Done
25.22 Conf call on Tuesday implies may I Itis assumed that Karen DR
still need Stock info to SAP ADS _I has miss-understood what
(though I suspect Karen mis- this flow is and so we
understood what it does) should assume no change
here (ie the weekly stock
info goes)
Dave to confirm with Karen
that this is OK.
Assume OK.
Karen has confirmed this.
2523 Requirements unclear (need AIS) I We should do no more TG
2.5.2.13.5 I (SAP ADS Transactions) work in this area on the
3.2.34.2 I Suggestion it may be dropped? _I basis that this will probably
be dropped.
Now in 8.4
25.2.3 No specific Requirement to BT108 PB
support SAP ADS Transactions in I Now in 8.4
[CDBT]
25.2.4 No specific Requirement to add BT110 PB
events in [CDBT]
25.24 How do we handle settlement ‘Separate note produced DP
transactions? on this and circulated 20/4
This will involve NRDS and MIS Closed
as well as Horizon
25.2.4 Can OPTIP handle the new Assume that we suppress I DP
events, or do we need to filter them
them until OPTIP feed is turned
off?
2.5.2.4 Does MIS need “Number of Yes
Outstanding TCs as part of the
event?
25.2.4 Need to update following new Done Gi
version of [TCAIS]
25.2.4 A number of detailed questions Done Gh
regarding what exactly we can
pass to MIS and OpTIP.
25.2.5 We're concerned that implications I POL to confirm OK DP.
of removing NB103 not fully Assumption is that it is OK.
thought through. Closed.
2.5.2.5 Need to complete this. Completed Sud
Input needed from Dev
25.2.7 How do we recognise Settlement I Leave to HLD Sue
Transactions?
25.2.8 How do we handle Transactions I Clarification from Dev Sud
that fail to be Harvested to TPS? Clarified
2.5.2.8 Need to complete this. Clarification from Dev Gl
Detailed input needed
Completed
25.2.8.2 Need to complete this. iid
25.2.8.2 Is it acceptable to hold back POL I POL to confirm
FS subfiles in error cases? NB Now in 8.4
they may have gone to MIS.
25.2.8.2 Is it acceptable to hold back POL I OK — check with Philip. GW
FS subfiles in error cases? NB Checked OK
they may have gone to MIS.
25.2.8.2 Is there a problem with take on of I HLD bedi dee
opening figures from MiMAN?
2.5.2.8.3 Need to complete this. Completed Gi Rd
© 2004 Fujitsu Services Post Office Account Page 14 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
25.2.9 Is this still in scope? (CAPO data We should do no more FS
3.2545 feed from EDS) work in this area on the
basis that this will probably
be dropped.
Now in 8.4
25.2.9 No specific Requirement to BT111 PB
support CAPO data feed from Now in 8.4
EDS in [CDBT]
2.5.2.10 Assuming we go for the “complex I Cost with caveats He NS
approach” need guidance as to _I (Separate email sent to
the need to move to the simple Nigel Stone on these
approach later. Should that be issues)
included in the costs? Closed
2.5.2.10 Assuming we go for the “complex I Cost with caveats Bes
approach” What about branches I Closed
that change from feed 1 to feed 2
during a month?
2.5.2.10 Is there an issue with Ref Data for I No DMcD
closed branches being removed?
2.5.2.10 No specific Requirement to BT112 PB
support HR SAP in [CDBT] Assumed 2 months in
arrears and 2 files
Have not done 2 costings
2.5.2.11 Need to complete this. Done Ghd
2.5.2.12 I No specific Requirement to BT113 PB
support Transaction Corrections
in [CDBT]
2.5.2.12 Need to consider Validation Clarification from Dev Gh
process Detailed input needed
Done in Host
2.5.2.13 What do we do with this? Clarification from Dev Pe
Detailed input needed
Provided
2.5.2.13 How do we find out when POL N/A NE
FS has loaded the data?
2.5.2.14 Need to update 2.6 to align with Done tad
this.
26.1 No specific Requirement to BI114 PB
support Migration in [CDBT]
26.2 Need to complete this. Done Gl
26.2 Is there a migration problem with Now sorted. Pd
timing of LFS Stock feed?
Can TCs be delayed until Branch I POL to consider DBP
switches to Branch Trading? Now in 8.4
Is there a requirement to look at POL to consider DP
old NB103's after CBDB switch Now in 8.4
off?
2.6.3.1.1 I Timing of permissions change on I Glu to provide a migration
Housekeeping menu. Simplest is I proposal to include this
to do this at a single time across (still outstanding)
the estate independently of the GlJ to document as
other changes. Is that OK? working assumptions
Suggest a fixed date is
chosen
Now in 8.4
26.3.1.1 Input for CAP controlled Soft Complete / ref to HLD ed
launch
2.6.3.1.2 Do we need to support a pilot for I Will come out of Migration I PB
POL FS take on? review (see BT114)
2.6.3.1.2 Need to complete this. Done Std
25444 I Need to explore migration ‘GI to provide a migration
Peete requirements for adjusting B fwd / I proposal to include this
2.6.3.2 C fwd positions on SU Balance Assume nothing special
reports (and Branch Trading?) done here.
Now in 8.4
© 2004 Fujitsu Services Post Office Account Page 15 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.6.3.2 Process to lock counter to Done Gl
prevent further activity needs
defining.
2.6.3.2 Do we need “double roll”? No. Gl
263.3 ‘Assumption is that moving non- _I Migrate in Post E. Gi
value stock to value stock willbe I Cost is part of Impact.
outside scope of Impact since no I Out of scope
specific requirements. Probably
handled as OBC.
26.3.6 Transactions between last CAP Can we do better? Gh
roll over and end of Trading day I Nowin 8.4
will be excluded / double counted
3.21 Need to complete this. Depends on completing DMcD.
Ref Data Analysis and
production of an AIS.
Closed
a2 AIS to be formalised (TCs) In particular we are
expecting some further
changes from the
baselined version 1.3
Version 1.4 now received,
but 1.3 is still the baseline
for the CT
3.24 AIS to be formalised (POL FS) In particular we are
expecting some further
changes from the
baselined version 0.2
0.3 now received, but 0.2
is still the baseline for the
CT
3.2.6 AIS needed (HR SAP) Received 19/4
Closed
3.2.6 How much in arrears is this Assume 2 months
interface? (HR SAP) Closed
3.2.6 Need to formalise the Now in 8.4 Gl
assumptions made
3.27 Need to formalise the Now in 8.4 Gi
assumptions made
327.1 Need to complete this. Done Ge
3.2.7.2 Can we extend Quantity feed to Raise at MIS Interface BR
support ForEx correctly? workshop on 22/4
Agreed
3.2.7.3 Need to complete this. Done Py
3.3.2 Detailed info needed Completed Rs
3.4.1 Need to complete (Summary HLD GARE
Store). das
3.4.2 Object Naming HLD? Www
Completed
3.4.2 Detailed sizing of Persistent HLD ey
Object needed
3.5 Need to complete this. Clarification from Dev DMcD-TBS
Need AIS
Done
3.5 Extend NRDS to provide Primary I Now in 8.4
and Tertiary mappings.
42 Need NF Regs (SAP ADS We should do no more +S
Transactions) work in this area on the
basis that this will probably
be dropped
Assume out of scope.
44 Need SLA Info (POL FS) Done
44 How do we detect Data loaded We need to raise a CR to Gls
successfully in POL FS the AIS
No longer required.
© 2004 Fujitsu Services Post Office Account Page 16 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
45 Need NF Regs (EDS) Done
45 Confirm date of delivery Done
46 Need to define where the file is to I FTMS Remote Gateway at I BR
be delivered Huthwaite
46 How early can file be delivered? Email sent to Nigel 15/4/04 I NS.
Closed
46 How do we handle missing data? I Email sent to Nigel 15/4/04 I NS
Closed
46 How do we run this once per Maestro calls it every day PaaS
month
47 SLA situation to be resolved. Covered elsewhere.
65 Need SLA Info POL to agree with Fujitsu FS
proposal (note sent 20/4)
Now included
5.3 Is [STYLE] still relevant? No. GlJ/ AH
55 Need SLA Info ‘Separate proposal Gi
circulated. To be included
when agreed.
Done
6.21 Is this complete? ITU to provide WY
Yes
6.2.2 Need to update this Done Gis
6.3.4 What is needed here? ITU to provide AU
Done
72 Need to complete this. Done baal
8.2: Should be removed since itis the I Agreed PB
BTOO6 same as BTOO7
8.2: Should be removed since itis the I Agreed PB
BT030 same as BTOO9
8.2 Need to find this in doc Done Ghd
BTO59
Table 4 —-Resolved Issues
0.7 CONTENTS
0.7.1 Table of Contents
CHAPTER 0 - DOCUMENT CONTROL. 2
0.1 DocuMENT HIsToryY.....
0.2 Review DETAILS...
0.3 ASSOCIATED DOCUMENTS...
0.4 ABBREVIATIONS & DEFINITIONS...
0.4.1 Abbreviations...
0.4.2. Definitions,
0.5 CHANGES IN THIS VERSION.
0.5.1 I Changes in Version 1.0......
0.5.2 Changes in Version 0.3......
© 2004 Fujitsu Services Post Office Account Page 17 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
0.5.3 Changes in Version 0.2...... 8
0.5.4 Changes in Version 0.1.
0.6 CHANGES EXPECTED.
0.6.1 Outstanding Design Issues...
0.7 CONTENTS...
0.7.1 Table of Contents.
0.7.2. Table of Figures.
0.7.3 Table of Tables.
CHAPTER 1 - INTRODUCTION..
1 PRIVACY AND CONFIDENTIALITY.
LILI Accuracy...
1.1.2 Copyright..
12 SCOPE OF THE DOCUMENT...
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...
14 DocuMENT SUMMARY...
15) OTHER AFFECTED DOCUMENTS
1.6 DEPENDENCIES ON Post OFFICE L1D....
1.6.1 Exceptions.
1.6.1.1 Training.
CHAPTER 2 - SOLUTION OUTLINE DESIGN..
21 GENERAL.
22 OVERVIEW OF IMPACT RELEASE 3 COMPONENTS....
2.2.1 Breakdown of Horizon Systems...
2.2.2 Breakdown of Branch Systems.
2.2.3 Breakdown of TMS.
2.2.4 Breakdown of Transaction Storage...
© 2004 Fujitsu Services Post Office Account Page 18 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
23 Mayor New END TO END CONCEPTS...
2.3.1 Transaction Corrections
2.4 UNCHANGED PROCESSES..
25) CHANGED COMPONENTS...
2.5.1 Counter Components.
2.5.1.1 Branch Transactions...
2.5.1.2 Changes to Cash / Stock declarations and handling of variances
2.5.1.3 Reporting...
2.5.1.4 Balancing and Rollover.
2.5.1.5 EOD.....
2.5.1.6 Logon Checks.
2.5.1.7 Process Transaction Correction:
Q 2 00 0 © % O oo
2.5.2 Host Components..
2.5.2.1 RDMC.....
2,522, LES...
2.5.2.3 Process SAP ADS Transactions.
2.5.2.4 TPS Harvesting.
2.5.2.5 DRS Host.....
2.5.2.6 APS Host...
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 Infe
2.5.2.12 Transaction Correction.
2.5.2.13 POA Data Warehous'
2.5.2.14 TPS Host.
bo 20 90 a0 BB D0 a0 oo wo me me oo OD
2.6 MIGRATION CONSIDERATIONS.
2.6.1 Migration Overview...
@
2.6.1.1 Data Centre Migration.
2.6.1.2 Counter Software Upgrade.
2.6.1.3. Running the Final Counter Cash Account for CBDB
2.6.1.4 Switch of TMS feed of Transactions from OPTIP to MIS...
2.6.1.5 Upgrade of Counter processes to operate Branch Trading Statement
Go 00 00 © Oo OD
2.6.2 Mapping of Changes to Migration Phases,
2.6.3 Specific Migration Developments...
Cy
Process the final cash account for CBDB....
Upgrade of Counter processes to operate Branch Trading Statement.
Merging of Non-Value and Value Stoc!
Switch of TMS feed of Transactions from OPTIP to MIS.
Accept CAPO Data...
Generate HR SAP Info..
Support of nRDS supported Settlement Products...
© 2004 Fujitsu Services Post Office Account Page 19 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
0 00 00 G0 00 OO
Joo
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.6.3.8 Support for Quiescent Rollover... oil
CHAPTER 3 - DATA MODEL.......
3.1 GENERAL..
3.2 EXTERNAL INTERFACES.....
3.2.1 Reference Data...
3.2.2. Transaction Corrections...
3.2.3. SAP ADS Transactions and Summaries.
3.2.3.1 The interface from SAP ADS to TM:
3.2.3.2 The interface from TMS to MIS.....
3.2.4. Ledger Entry Information........
3.2.5 TMS Info from Clients...
3.2.6 Remuneration Information...
3.2.7 Management Info... ee
3.2.7.1 Changes due to removal of the Cash Account.....
3.2.7.2 Additional Transactional Information.
3.2.7.3 Additional Event Information...
3.2.8 CTS Files...
85: INTERNAL INTERFACES...
3.3.1 Branch to TMS: Transactions...........
3.3.2. TMS to Branch: Transaction Corrections.
3.3.3 Within Branch: Transactions...
3.4 DATA STORES.
3.4.1 Summary Store....
3.4.2. Variance Persistent Objects.
3.4.2.1 Stock Unit Variance Persistent Objects
3.4.2.2 Declaration Variance Persistent Object:
3.4.2.3. Office Variance Persistent Objects.....
3.4.3 Stock Unit Summary for Branch Trading Report...
BS) REFERENCE DATA CHANGES...
CHAPTER 4 - ENVIRONMENTAL CONSTRAINTS...
4.1 GENERAL,
42 TECHNICAL INTERFACE FROM SAP ADS...
43 TECHNICAL INTERFACE FROM NRDS....
© 2004 Fujitsu Services Post Office Account Page 20 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
44 TECHNICAL INTERFACES TO AND FROM POL FS.
45 TECHNICAL INTERFACE FROM EDS.
4.6 TECHNICAL INTERFACE TO HR SAP.
47 TECHNICAL INTERFACE TO MIS.
48 TECHNICAL INTERFACE TO CTS.
CHAPTER 5 - NON-FUNCTIONAL REQUIREMENTS...
5.1 GENERAL.
52 AVAILABILITY...
5.2.1 Resilience.
55: USABILITY,
5.4 VOLUMETRICS..
5.5 SERVICE LEVEL OBJECTIVES...
5.5.1 SLA Changes...
5.00 GES.
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).
5.5.1.6 TMS — HR SAP...
5.5.1.7 TMS (CTS file).
5.5.2 SLAs to be removed...
deb 90 2 9 oD oD oD
5.5.3 Unchanged SLAs.
5.5.4 Migration Implications...
5.6 SECURITY...
CHAPTER 6 - TESTING AND ACCEPTANCE .,...ssessssssseeesees
6.1 GENERAL.
6.2 PRODUCT TESTING.
6.2.1 Test Stages...
6.2.2. Test Environments...
63 ASPECTS TO BE TESTED...
6.3.1 Business functionality.
6.3.2 Performance...
© 2004 Fujitsu Services Post Office Account Page 21 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
6.3.3 Volume...
6.3.4 Integrit
6.3.5 Resilience.
6.3.6 Recoverability (including backup and recovery, including disaster recovery).
6.3.7 Networking...
6.3.8 Security.
6.3.9 Supportability...
6.3.10 Manageability (system management)...
6.3.11 Migration.
64 ACCEPTANCI
6.4.1 Live Pilot..
6.4.2 Capacity Modelling...
CHAPTER 7 - MAPPING OF PROCESSES TO COMPONENTS...
ral GENERAL,
72 MAIN BUSINESS PROCESSES.....
CHAPTER 8 - COMPLIANCE MATRICES...
8.1 GENERAL,
8.2 COMPLIANCE MATRIX...
8.3 ADDITIONAL REQUIREMENT....
84 OTHER ASSUMPTIONS...
0.7.2 Table of Figures
Figure 1 - IMPACT Release 3 Components.
Figure 2 — Horizon Systems........
Figure 3 — Branch Systems..
Figure 4 - TMS.
Figure 5 — Transaction Storag:
Figure 6 — Ref Data Model for Articles...
20 00 © 00 o o0
0.7.3 Table of Tables
Table 1 — Outstanding Issues on Post Office Ltd...
Table 2 —Issues requiring updates to [CDBT].....
© 2004 Fujitsu Services Post Office Account Page 22 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Table 3 — Outstanding Issues on Fujitsu Services POA.....
Table 4 —Resolved Issues.....
Table 5 — Out of Scope Processes
Table 6 — External Interfaces.
Table 7 — Unchanged Processes.
Table 8 — Riposte Configuration Changes...
Table 9 — Expiry Value Analysis...
Table 10 — Categories of Non-Value Stock.
Table 11 — Current Suspense Products.....
Table 12 — Current Settlement Products.
Table 13 — Method of Payment Products.
Table 14 — Stock Products currently adjusted by Value.
Table 15 — Reports affected by Stock Changes.
Table 16 — Reports that can be reprinted.
Table 17 — Reports to be removed.
Table 18 — Current Weekly Reports...
Table 19 — Additional EPOSS Events to be harveste
Table 20 — POL FS File Delivery Information.
Table 21 — POL FS File Receipt Informatio
Table 22 — HR SAP File Delivery Information...
Table 23 - SAP ADS MIS File Delivery Information
Table 24 — Transaction Correction Metrics.....
Table 25 — Migration of Functions.
Table 26 — Migration of SLAs...
Table 27 — Mapping of Business Processes to DP Sections.
Table 28 — Acceptance Mechanism...
Table 29 — Compliance Matrix..
Table 30 — Additional Requirements Compliance Matrix.
Table 31 — Assumptions.
0 20 G0 G0 00 © G0 O 0 G0 © Oo OD Ow OO OD GO OO G B OO OH OH OO O_O HO
© 2004 Fujitsu Services Post Office Account Page 23 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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.
112 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:24 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 ete (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 24 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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.
12:2 Timescales and Phasing
The design contained in this Design Proposal does not link IMPACT Release 3 to a
particular Horizon release. The release will be determined by the Joint Demand
Planning Forum.
However the expectation is that it will be included in S80.
1.2.3 Potential for Change
There are no specific requirements to allow for future change, however the use of
Reference Data where possible provides a good basis for minimising the developments
required in future to accommodate changes.
It is understood that the data feed to HR SAP (see section 3.2.6) is likely to be
simplified in the future and although that change is out of scope, the design should take
this into account.
1.2.4 Requirements Out of Scope
A number of the Business Processes described in [CDBT] are outside the scope of this
DP. These are listed in Table 5:
Business Process Comment
Perform Transaction Checks — Periodic This will be handled by the Post Office MIS system
Summarise Cash Centre Transactions This will be handled by SAP ADS as at present
Table 5 - Out of Scope Processes
In addition Section 21 (Appendix C) of [CDBT] identifies a number of changes based
on Schedule 12 savings. These are considered to be outside the scope of this DP.
1.3 REQUIREMENTS OVERVIEW
The detailed requirements for Release 3 are described in [CDBT].
© 2004 Fujitsu Services Post Office Account Page 25 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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] with references to where in this document the way in which the requirement is
to be met is described.
1.4 DOocuUMENT SUMMARY
This document describes the proposed design for Impact Release 3. In particular it
describes:
= Verification
= Other Data Capture
= Produce Reports
= Daily Trading
= Produce Branch Accounts
= Stock Control
= Discrepancy Management
= Transaction Management
1.5 OTHER AFFECTED DOCUMENTS
A number of High Level Design and interface documents are being produced from this
Design Proposal:
m= = [CTRHLD] which covers all aspects of the counter changes and general overview
= [TPSHLD] which covers those aspects to be included in the TPS Host
= [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
= [TPSAGTHLD] which covers those aspects to be included in the TPS Agent
© 2004 Fujitsu Services Post Office Account Page 26 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= [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 [CDIAG]
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
= [MENU] to update the Menu hierarchy
1.6 DEPENDENCIES ON PosT OFFICE LTD
The following are dependencies on Post Office Ltd:
= 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 witheutintroducing further changes.—These- AlSs-and FiSs-
are:
a [CTSAIS] (Interface to Post Office Ltd of Client Transmission Summaries)
a [EDSAIS] (Interface from EDS of Card Account Activations)s
a [HRSAPAIS] (Interface to HR SAP)
a [HRSAPAIS]] (Interface to HR SAP)
a [HRSAPAIS2] (Interface to HR SAP)
a [MISAIS] (Interface to Post Office Ltd MIS System)
a [POLFSAIS] (Interface to POL FS)
a [RDSAIS] (Interface from nRDS)
a [SAPADSAIS] (Interface from SAP ADS for Transactions and Summaries)9
a [TCAIS] (Interface from POL FS for Transaction Corrections)
a [POLTIS] (Technical Interface to Post Office Ltd)
= Confirmation that there is not a requirement to support the following AISs. If the
decision is that support for these AISs is required then the requirement will be
handled under Change Control
ao [EDSAIS] (Interface from EDS of Card Account Activations)
8 Currently assumed out of scope.
9 Currently assumed out of scope.
© 2004 Fujitsu Services Post Office Account Page 27 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
1.1.1.4
a [SAPADSAIS] (Interface from SAP ADS for Transactions and Summaries)
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.
Training
It is assumed that training will be provided by Post Office Ltd.
No specific training facilities are to be provided by Fujitsu Services.
© 2004 Fujitsu Services Post Office Account Page 28 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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.
Prism —I_ Reference Data R2
Systems R2
Cent Access R2 Ee
ae ‘Bank Statments R2
*8 : 3
Transaction Comections Lc
Horizon
systems R2
Ledger Entry information R2
Remuneration hvomation ; I
AS
SSAPADS Transactions and Summaries
eS TMS info trom Clients
m
CTS Files
id
Management Info R2
‘AT
Figure 1 —- IMPACT Release 3 Components
For simplicity I've lefi 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.
The interfaces (which are described summarised in Table 6 below and described in
Chapter 3) are colour coded to highlight changes:
© 2004 Fujitsu Services Post Office Account Page 29 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= 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 Ts Comment
Reference Data POL Horizon I 3.2.1_I [RDSAIS] [POLTIS]
Client Access Out of Scope
Bank Statements Out of Scope.
Transaction Corrections POLFS I Horizon I 3.2.2 I [TCAIS] Internal to
Fujitsu
SAP ADS Transactions POL Horizon I 3.2.3 I [SAPADSAIS] I [POLTIS]
and Summaries & POL
FS
Ledger Entry Information I Horizon I POLFS I 3.2.4 I [POLFSAIS] Internal to
Fujitsu
TMS Info from Clients POL Horizon I 3.2.5 _I [EDSAIS] [POLTIS]
Remuneration Horizon I POL 3.2.6 I [HRSAPAIS] [POLTIS]
Information [HRSAPAIS1]
[HRSAPAIS2]
Management Info Horizon_I POL 3.2.7_I [MISAIS] {POLTIS]
CTS File Horizon_[ POL 3.2.8 I [CTSAIS] [POLTIS]
Table 6 — External Interfaces
It should be noted that some of the components are external to the overall system.
These are shown as green boxes in the diagram.
Some of the components / data flows have a suffix of “R2”. This has been done purely
to avoid duplicating objects names within Systems Architect. These suffixes should be
ignored and have not been included in the text in this document.
The components are:
= Prism Systems
This represents the systems provided and operated by the Prism Alliance. The
main components relevant to Fujitsu are:
Terminals for user access to POL FS (and other systems)
SAP ADS
MIS
Reference Data System
oooa
= 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.
= External Clients
It is understood that there are some interfaces with external clients from legacy
systems that will need to be supported by TMS.
The only one that is now in scope is a feed of data from EDS concerning enlivened
Card Accounts.
© 2004 Fujitsu Services Post Office Account Page 30 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
= HRSAP
This is a system run by RMG to pay Postmasters. It is fed by summaries of value
and volume of a subset of transactions, which are the basis of the Postmaster’s pay.
= POL Client Settlement
This represents that part of the Post Office’s central systems which receives the
CTS file each day.
= Financial Institutions
This represents the various external Financial Institutions which will need to
provide input to POL FS. These are outside the scope of this document.
2.2.1 Breakdown of Horizon Systems
Figure 2 provides a breakdown of the Horizon Systems and the interfaces between
them. For simplicity the agents have been omitted from the diagram. Changes to
agents will be covered as part of the description of the corresponding Host Systems.
RONG RE
Reference Data R2 Reference Data R2
rd ‘SAPADS Transactions and
TMS Info rom Clients
‘Transaction ConectionsI
Branch Transactions R2
Systems R2
E
73 ‘Transaction Corrections
THERE
Ledger Entry Information R2
Management Info R2
I__—_—_Menaosrt 2g,
Remuneration Information
(CTS Files
2)
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: ptSe02.doc
Page 31 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
components.
Reference Data R2
Branch Transactions R2 SOBRE Transactions R
Transactions
7a maa
Cash and Reporing
Stock
bmi ‘Transactions R2
737 738
Taine and
RotoverR2
Process 4
Transaction Coretons aes maa
E}
R233 I Cash Decaration
Topon Cheeks}
736
Figure 3 —- Branch Systems
The components are:
= Branch Transactions
This is the normal handling of Zransactions 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.
Changes are described in section 2.5.1.5.
© 2004 Fujitsu Services Post Office Account Page 32 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= 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
SAPADS Transactions and Summaries Transaction
>) Storage R2 Ledger Entry Information R2
Management Info R2
TMS Info from Clients
=I Remuneration Information
ed!
Transactions R2 CTS Files
>I
3]
A2.4.3
Transaction
Transaction Corrections Transaction Corrections
Correction
> >
2
A242
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.
= Transaction Storage
This is basically the functionality carried out by the current Host Systems (TPS,
DRS, APS, OBCS and the Data Warchouse) as modified to meet the Impact
requirements. This is expanded further in section 2.2.4.
© 2004 Fujitsu Services Post Office Account Page 33 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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.
Breakdown of Transaction Storage
Figure 5 provides a breakdown of Transaction Storage components and the interfaces
between them.
Bach
toms
12 Transactions
(P2a330rs) a
AP Transactions : ver AP Transactions
crs ries aon
(0B Transactone
Paas2 TPS
sale rvesing
ees tom
Transaction Sore
Peas?
Transactions Management no R2
POLS
>
SSAPADS Traneactons
112 Tanesctons .
(08S Tranasctone
a Yole ae
Summaries
Pasa)
__
x ‘Summary Ste
“Accupt CAPO)
Dee
“caret
Remuneration Summaries
(_Paaaie)
SPAS
(waLFs)
cara Account Enivenment no
kK
cara cout Enver no
[Ror]
Remuneration Infomation
THES
[PorFsRa,
Ledger Entry Ifomaton R2
>
Figure 5 — Transaction Storage
The components are:
Process SAP ADS Transactions
This is a new function within the Horizon Data Centre. It’s purpose is to support
the processing of the SAP ADS Transactions and Summaries information flow and
pass the data onto the MIS system.
Changes are described in section 2.5.2.3.
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
File: ptSe02.doc
Page 34 of 145
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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.
= DRS Host
All existing interfaces to Reconciliation Clients (eg NBE, Streamline and E-Pay)
will continue to be supported (but have been excluded for simplicity).
The main change is to support the removal of the CAP on the C112 records and
the removal of the NB103 reports.
Changes are described in section 2.5.2.5.
= APS Host
All existing interfaces from AP Clients (eg Quantum and Watercard) will continue
to be supported (but have been excluded for simplicity).
Changes are described in section 2.5.2.6.
= Generate MIS Info
This will take the detailed Transactions from Branches and pass them across to the
MIS System.
Changes are described in section 2.5.2.7.
= Transaction Summarisation
This is a new component which is responsible for summarising transactions on a
daily basis so that the appropriate summaries can be made available to other
systems.
This is described in section 2.5.2.8.
= Accept CAPO Data
This is a new component which processes a file received once a month from EDS
and is used to feed HR SAP with details of new CAPO accounts activated.
This is described in section 2.5.2.9.
= Generate HR SAP Info
This will take the Transaction Summaries and pass them over to HR SAP.
Changes are described in section 2.5.2.10.
= Generate POL FS Info
This will take the Transaction Summaries and pass them over to POL FS.
Changes are described in section 2.5.2.11.
In addition, 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 35 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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.
2.3.1 Transaction Corrections
This is a new set of business processes to enable corrections to be made to the Branch
accounts as a result of various central investigations. The purpose of this new process
is to replace the existing Error Notice functionality.
In summary the process works as follows:
= 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 Transition Corrections a
new check is included at Logon for roles MANAGER and SUPERVISOR as to
whether there are any Outstanding Transaction Corrections and if so the user is
informed of the number currently outstanding and given the option of processing
them. (See section 2.5.1.6 for more details.)
= A new Transaction Correction Button is provided to enable the Branch Manager /
Supervisor to view and process Outstanding Transaction Corrections. (See
section 2.5.1.7 for more details)
= 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.)
© 2004 Fujitsu Services Post Office Account Page 36 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 section 3.3.2.)
2.4 UNCHANGED PROCESSES
A number of the Business Processes described in [CDBT] require no functional
change. These are listed in Table 7:
Business Process Comment
Perform Range Checks -Transaction ... Validate Data Captured
Automated Reconciliation
Produce Daily Summaries
Produce Periodic Summaries
Verify Summaries
REM-outand Despatch Redeemed Dockets/\Vouchers
Produce Other Horizon Reports
Input Non Accounting Data
Input Bulk Data
Input Additional Client Data
Remtn/Out Stock
tock Revaluation (Stamps)
=
Investigate Balance Discrepancies
Roll Over Inactive Stock Units
Table 7 —- 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
© 2004 Fujitsu Services Post Office Account Page 37 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
These are discussed further below.
25e11 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)
Some of these topics are covered elsewhere in the DP (as indicated), the remaining
ones are covered in the following subsections.
2.5.1.1.1.1 Riposte Configuration Parameters
The Riposte configuration is documented in three separate documents:
= Counters [RIPCNT]
= 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 3410
Correspondence Server & Clients MaxMessageExpiry 37 50
Counter MaxMessageExpiry 37, 50
Correspondence Server & Clients DefaultMessageExpiry 36. 43
Counter DefaultMessageExpiry I 36 43
10 Ieitis unchanged
© 2004 Fujitsu Services Post Office Account Page 38 of 145,
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Table 8 — 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 will be defined in the counter HLD.
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
Messages
34 5831 Persistent Objects Could well have lower values which are
[R11], [Recov] overridden by MinMessageExpiry
35, 18950 EPOSS Transactions etc Must be explicitly set.
36 8716 LPOs Probably defaulted
EOD Reconciliation
LFS
Total 33497
Table 9 - Expiry Value Analysis
It would be useful to carry out two separate exercises:
These need to be scheduled during April.
Email sent to Mark Scardifield to get this resourced.
Feedback from this will be handled though the HLD.
Set the Riposte Configuration values as specified in Table 8 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
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:
a LPOs
a Some LFS Messages (ie those containing <WAIndex:>)
o Print messages
a 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.
© 2004 Fujitsu Services Post Office Account Page 39 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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, then 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 to be 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 counter my be 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]
Consideration is required as to whether there is a problem with implementing such a check on
a spare. For this check to be of use it must take place before Riposte is first loaded. It may be
sufficient that the code that carries out such a check is defined as an “immediate” fix.
This can be addressed in the HLDs.
This bit of code is owned by Karen Morley’s team in ITU.
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)
© 2004 Fujitsu Services Post Office Account Page 40 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= 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.
A consequence of this is that there will be no value for the overall Remittance /
Transfer session and so this will mean that the Remittance / Transfer reports will
change. This is covered further in section 2.5.1.3.7.
2.5.1.1.2.2 Stock Sales
A concept of Tertiary Mappings is introduced for stock products (see
section 2.5.1.4.1.3) in order to support the production of the Stock Unit Balance
Report. All Transactions (both stock and non-stock) will need to include these
Tertiary Mappings where they exist in addition to the current Primary / Secondary
Mappings.
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 (Stamps).
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)
© 2004 Fujitsu Services Post Office Account Page 41 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 “other stamps” 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 should be a simple Type A Reference Data change.
Table 14 (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.
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.
[BT0S5]
No changes are currently proposed in this area other than removing the non-value stock
functions.
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 is being 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.
Previous text in this section has been removed without marking it as such.
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.
= Reengineer 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.
Prod Group Id_I Group Name Number I Comments.
3297 MVL Discs 34 Need special consideration
3298 Milk Tokens 4 Will become uncontrolled
3299 Travel Schemes 379 Ref Data Change
3300 Local Authority Vchr_I 20 Ref Data Change
3301 Other Tokens 16 Need special consideration
© 2004 Fujitsu Services Post Office Account Page 42 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 10 — Categories of Non-Value Stock
My system has 4702 Pre Pack Currency instead of N Lott Chgs.
Table 10 identifies the various types of non-value stock in the current system. The
following subsections consider each one in turn.
2.5.1.1.3.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.
Dev to confirm the following please — preferably by carrying out a controlled experiment.
Results will be fed back to POL and may result in further CRs.
= 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.
= 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.
The product will also need to be included in the Stock Adjustment and Stock
Declarations lists.
I believe that these are based on the Primary mappings so this may well require the Primary
mappings for the product to change. Since these will become Stock Products, then they will
also require Tertiary mappings.
Will that cause any migration issues?
Results will be fed back to POL and may result in further CRs.
= 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).
© 2004 Fujitsu Services Post Office Account Page 43 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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.
= If required it should then be OK to change the “loss price” to a non-zero value if
required.
2.5.1.1.3.2 I 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.
2.5.1.1.3.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.
2.5.1.1.3.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.
2.5.1.1.3.5 — N. Lott. Chas
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.
251.14 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:
© 2004 Fujitsu Services Post Office Account Page 44 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.1.1.4.1
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). [B¥040; 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]
The detailed requirements are to be addressed as part of Counter Dialogues.
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]
‘My-expeetation-is-that This can all be implemented via Reference Data Changes.
Current Suspense Products
Table 11 shows the products currently transacted as part of the Housekeeping menu:
Product Number _I Product Name Comment
111 NS &1 E/N dep To be withdrawn (handled by TCs in future)
173 NS & 1 E/N wdrwl To be withdrawn (handled by TCs in future)
221 Loss A reedemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2858 Loss B redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2859 Loss C redeemed To be withdrawn, however it needs to remain until
‘Suspense account reduced to zero.
2860 Loss D redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
829 Gain A redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2864 Gain B redeemed To be withdrawn, however it needs to remain until
Suspense account reduced to zero.
2541 Giro EN rept To be withdrawn (handled by TCs in future)
2542 Giro EN pa 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
211 PrepurchseRdm
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.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 45 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 be withdrawn? Probably not.
Assume these are still needed.
2657 Migrate-UP-Out To be withdrawn? Probably not.
Assume these are still needed.
2654 Migrate-UR-In To be withdrawn? Probably not.
Assume these are still needed.
2656 Migrate-UP-In To be withdrawn? Probably not.
Assume these are still needed.
2600 Bur/rob loss u/p
2601 Rdm Rob loss
247 Loan to PO
248 LoantoPOwdrn
2164 Rem Surplus
2165 Rdm rem shrige
2167 Rem shortage
2168 Rdm rem surplus
2477 FinalA/c surplus
2178 Final acc def
2530 Unpaid Cheque A to UP
2846 Unpaid Cheque B to UP Do-we need 3 of these? Suggest that This one
should be withdrawn. However it needs to remain
until Suspense account reduced to zero.
2847 Unpaid Cheque C to UP Do-we-need-3 of these? Suggest that This one
should be withdrawn. However it needs to remain
until Suspense account reduced to zero.
2531 Unpaid Chg A Redeemed
2851 Unpaid Chq B Redeemed Fivwe seecd tat ihess sisest tha: This one,
should be withdrawn. However it needs to remain
until Suspense account reduced to zero.
2852 Unpaid Chq C Redeemed ‘Do-we-need 3 of these?_Suggest that This one
should be withdrawn. However it needs to remain
until Suspense account reduced to zero.
2528 Voucher to U/P
2529 Rdm voucher
2849 POL chg to up
2848 POL chq up out
Table 11 — 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 Counter Dialogues discussions,
2.5:1.15 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.
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.
© 2004 Fujitsu Services Post Office Account Page 46 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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.
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 Harvester. However at Impact R3,
since summarisation of transactions for POL FS is done in TPS, all such transactions
will need to be harvested otherwise the data passed to POL FS may not balance and
data will be lost.
The following table shows the types of products affected with approximate numbers:
10639 & 10990 Revaluations These appear to be historic and can no longer be
transacted.
11212 & 11213 Revaluations Currently used for revaluations. Since revaluations are to be
removed, it is proposed that these settlement products
remain until revaluations are no longer required.
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 12 — Current Settlement Products
There are two approaches to this:
= 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 within Fujitsu that we take the second approach, however this has
still to be discussed with the POL Reference Data team. In particular, transactions
involving such products must not be sent to MIS and so the product Reference Data
needs to identify such products to enable them to be easily suppressed by the TPS Host
system.
Assumption recorded in section 8.4
The proposed approach is to request that nRDS delivers replacements for the
Settlement Products that we expect to be used and we then withdraw the 1xxxx
© 2004 Fujitsu Services Post Office Account Page 47 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
equivalent products following migration. There are migration issues and these are
discussed in section 2.6.3.7.
For the remaining products it is safest to leave them alone, and continue to suppress
them on Harvesting. This means that if they are ever transacted, they will result in an
error which will easily be detected in the POL FS Summarisation function.
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. [BT 104]
For ease of transition, the Cash Declaration Button will also be placed on the
Reporting menu.
The dialogue of the Cash Declaration function will be basically unchanged.
In order to support subsequent reporting, details of cash declarations made need to be
held in a set of Persistent Objects similar to those currently used to hold details of
ONCH Declarations. These are described in section 2.5.1.2.1.3. The denominational
level information will continue to be maintained in Declaration messages. The current
Variance Persistent Object will identify the latest Declaration that has been made.
For an Unshared Stock Unit, any difference between the declared figure and the
systems generated figure will be presented to the user and will be recorded (as a
discrepancy — but now to be called a variance) as part of the Declaration event.
For a Shared Stock Unit, a new function, Check for Variances, is required to check for
Cash Variances across all declarations within the stock unit. This is described in
section 2.5.1.2.1.1.
In addition, an extra button is added into the “Produce Report” screen at the end of a
Cash Declaration in a Shared Stock Unit, giving the user the option of going straight
into this new “Check for Variances” function. [BT026]
© 2004 Fujitsu Services Post Office Account Page 48 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.1.2.1.1_ Check for Variances Function
The Check for Variances function will present a list of declarations for that stock unit
at 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 different-frem those currently used by the Stock
Unit Balance Process. The processing required is:
ray $e tie Cheek ton ee a ee ee tof thet
Fi P gi
Sie, Sere Se Sa
P then Bis yes y>0t ey
4) Find the latest Variance Persistent Objects for each Declaration Id that has
been used within the current Stock Unit
5) Find the last 1fthere-is-a Declared Value fertodey-in the Persistent Object, and
include it in the list to be displayed.
6) For each Declaration Id being displayed need to include the following:
e User
¢ Time of Declaration
7) 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)
8) If the user selects Continue, the current stock unit derived position is
calculated and compared with the sum of the declarations selected.
9) 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
10) — If they do not match, then a Shared Stock Unit Variance Check Complete with
Discrepancy event is written; the Stock Unit Variance Persistent Object is
updated; and the function exits having informed the user that there is a variance
and what it is
Note that there is no requirement to produce a report at this stage. All the relevant
information can be found on the Variance Report.
It should be noted, that no attempt will be made to check or to take into account any
transactions that may have taken place between the times the various declarations were
made and the time that the Variance is calculated.
This is no different from the current “Discrepancies” function.
© 2004 Fujitsu Services Post Office Account Page 49 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Two new events are required for this:
= Shared Stock Unit Variance Check Complete
= Shared Stock Unit Variance Check Complete with Discrepancy
Note that if other users attached to the Stock Unit have continued trading since they
made their Declarations, then the Variance that is calculated is likely to be incorrect.
No attempt should be made to compensate for this. It is the responsibility of the
Branch staff to ensure that no such trading takes place. This is why a list of when the
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)
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.
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:
© 2004 Fujitsu Services Post Office Account Page 50 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= One for each week for each Stock Unit (shared or unshared)
= One for each week for each Declaration Id in each Shared Stock Unit
= One for each week for the Office
Old Persistent Objects should be logically deleted when they are no longer of use in a
similar way to that currently done with the ONCH_ww_SS Persistent Objects, however
rather than removing the Persistent Objects, when they are no longer required, their
content should be removed and a “logically deleted” flag should be included in the
Persistent Object. This will avoid any problem with the Riposte mechanisms for
removing Deleted Persistent Objects. This logical deletion should not take place until
at least 5 weeks after the end of the week for which the Persistent Object was created.
Each Persistent Object should contain a composite attribute for each day of the week
starting with Thursday, with the attribute name being the weekday name. Any
declaration made the following day as part of the logon check will be held under
yesterday's composite attribute. Unlike the current ONCH Persistent Objects there is
no concept of carry forward declarations, so it will only be necessary to update a
single Persistent Object.
The content of the Variance Persistent Objects is defined in section 3.4.2
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 when the last declaration was done for each Stock Unit.
This is a new Office Daily Report which is generally available.
It is assumed that a new button is added into the Reports Menu at some appropriate
place (probably as an Office Daily Report)
The processing when the button is touched is as follows: [BT009]
1) The normal “Produce Report” screen is displayed
2) The Report tablet will include “Trading Period” and the current week
3) A list of Stock Units is obtained
Presumably by enumerating the StockUnits collection.
However the Default Stock Unit should be omitted from the Stock Units being reported on.
4) All the Stock Unit Variance Persistent Objects for this week are found (of all
types)
5) If this isn’t the first week of a Trading Period, then all the Stock Unit Variance
Persistent Objects for last week are also found to populate the Carried
Forward column of the report
6) The report can then be built up as follows:
Perhaps this is too detailed for a DP, however I’ve included it since it is my way of clarifying
my understanding of the requirement.
a) Standard Heading
© 2004 Fujitsu Services Post Office Account Page 51 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Details to be defined as part of Counter Dialogues discussion.
b) Days in Trading Period line: use the Reference Data Trading Period
calendar to identify the day numbers within the current trading period.
If this isn’t the first week of the trading period, then need to include the
last day of the previous week in the first column. If it is the first week
of the trading period, then need the first column should be included.
But left blank with no heading.
c) Dates line: the calendar dates for these days need to be included here.
d) For each column, the data used to populate it is found from the
appropriate Stock Unit Variances Persistent Object. Data is included in
all columns within the period of the report up to and including
yesterday. The remaining columns should be left blank. The day for
which data is to be included in a column is selected as follows:
POL may want this to include “today”, but that will be handled by a CR.
Assume only up to yesterday for now.
Assumption recorded in section 8.4
i) If there is an entry in the Stock Unit Variances Persistent Object
for the given day, then use the data from that entry
ii) If there is no entry for the day, check the Office Variances
Persistent Object for the given day and see if this Stock Unit is
included in the list of Stock Units not logged on today.
iii) If the stock Unit was not logged on, go back through previous
days in the Office Variances Persistent Object until the last day
that the Stock Unit was logged on and pick up the values from
that days’ information in the Stock Unit Variances Persistent
Object
iv) Otherwise put an “x” in the relevant data fields
e) Cash Variances section: For each Stock Unit create a separate line
with the value of the Variance for the given day (or “x” if no data for
the given day).
f) Cash Variances total: If any of the values for the stock units for that
day are “x”, then the total should be “x”, otherwise it should be the sum
of the Variances for all stock units.
g) Derived Figures section: For each Stock Unit create a separate line
with the value of the Derived Figure obtained by adding the Variance to
the Declared Figure for the given day (or “x” if no data for the given
day).
h) Derived Figures total: If any of the values for the stock units for that
day are “x”, then the total should be “x”, otherwise it should be the sum
of the Derived Figures for all stock units.
i) Declared Figures section: For each Stock Unit create a separate line
with the value of the Declared Cash for the given day (or “x” if no data
for the given day).
© 2004 Fujitsu Services Post Office Account Page 52 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
aD) Declared Figures total: If any of the values for the stock units for that
day are “x”, then the total should be “x”, otherwise it should be the sum
of the Declared Figures for all stock units.
k) Stock Unit Breakdowns section: For each Shared Stock Unit create a
separate line for each separate Declaration Id with the value of the
Declared Cash for the given day (or “x” if no data for the given day).
In this case the data will be taken from the Declaration Id Variances
Persistent Object for the appropriate Stock Unit
1) The remaining rows in the report are obtained from the corresponding
attributes of the Office Variances Persistent Object for the given day.
It should be noted, that immediately after migrating to the Impact R3 functionality,
there will be a very limited history of Variance Persistent Objects. Any data that is
required by the report, which is not available in the Variance Persistent Objects, should
be treated as if no declarations were made on that day and “x”s output.
Special handling is required for Stock Units that have been Created or Deleted during
the time covered by the report. The rules are as follows:
= Reporting for these Stock Units should be as above for the periods when the Stock
Units were in existence
= For those periods when the Stock Units were not in existence, then the various
columns should have a value of “n/a” rather than “x”, and the Stock Units should
be ignored in terms of deciding if totals should be included.
2.5.1.2.2.1. Reprints of the Cash Variance Report
This report is produced from the raw data in a similar manner to the production of the
Cash Variance report as described above. The difference is that the date range for
which the report is to be produced is defined as part of the reprint mechanism and the
Variance Persistent Objects for that period are used rather than those for the current
week. [BT060a]
2501,.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)
= Made Good (ie the physical cash will be adjusted to match the System Generated
figure)
= Recording the variance as a Discrepancy (ie the System Generated figure will be
adjusted to match the physical cash by creating a transaction which is balanced
against the Discrepancy product)
This is current functionality and will continue to be invoked only as part of the
Stock Unit balancing process. This is covered further in section 2.5.1.4.1.
Making good a loss (or removing excess cash), has no actual affect on the system
generated figures since what is being done is adjusting the actual cash holding to
© 2004 Fujitsu Services Post Office Account Page 53 of 145,
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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:
= Make good a loss
= Remove excess cash
The Counter Dialogues will decide where these buttons will be added to the system.
These buttons will be available for any clerk to record the “making good” event. Such
“make good” events will be recorded in the audit trail and will also be passed through
to MIS.
Invoking either button will result in a screen being presented to the user inviting them
to enter the amount to be made good (or removed). No attempt is made to calculate
or verify this amount is to be made, since it is assumed that trading has taken place
since the last Declaration.
[ the Variance report may help the User in working out how much (s)he needs to Make Good.
Two separate events will be defined:
= Make good a loss (Event Id 59)
= 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 would be updated (for an
unshared Stock Unit the user will be asked to chose which Declaration should be
updated). [BT032]
An implication of this is that if a cash shortage is made good at end of day after the Cash
Declaration has been done for that day, then a Variance Report for that day will show the
variance, but the report for the following day should not show a variance (unless further errors
are introduced). I believe that that is what is required.
Note that this scenario is not possible since Variance reports cannot be produced for “today”.
Need to handle the case where no declaration has yet been made. However this is unlikely to
happen in practice since:
¢ —adeclaration should be made each day
¢ a declaration would probably have been made to enable a variance to be identified and thus for the clerk to
decide that there is something to make good
Any subsequent attempt to update the declaration will make it clear that there is an
amount “made good” (or removed) from the Declaration. However if a subsequent
Declaration is made, it is assumed that the cash declared at that time is correct and the
© 2004 Fujitsu Services Post Office Account Page 54 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
record of the amount made good (or removed) will not be carried forward in the
Declaration.
Totals of all amounts made good or removed within the current Balance Period will be
reported on the Balance Report (see section 2.5.1.4.1).
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 Finnish 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 (or CAP?). They can then select
one of these declarations to update or alternatively decide to make a new
declaration from scratch.
They are then presented with a list of all Stock items (apart from cash and “other
stamps”) and are invited to make a “blind declaration”. If it is a new declaration,
then they are required to enter a Declaration Id.
Subsequent use of the Discrepancies function or running a Trial Balance will then
compare the total Declarations for the Stock Unit with the System Derived figures
and highlight any discrepancies that are identified. If this check is done as part of
the Trial Balance process, then the discrepancies must be accepted, which will
result in a Discrepancy transaction being created for each stock item whose level is
identified as being in error based on the Sale Price and a balancing transaction of
the Discrepancy product in each case.
Both of these mechanisms need to be retained, however rather than using the Sale
Price when recording the Adjustment or Discrepancy transaction, a separate “loss
price” should be used. This “loss price” will optionally be supplied as part of the
Product Reference Data. Should no “loss price” be defined in Reference Data, then
the Sale Price should be used. [BT036]
This has a number of implications:
= Changes are required to Product Reference data to include an optional “loss price”
for those products where it is different from the sale price. This is discussed
further in section 3.5.
© 2004 Fujitsu Services Post Office Account Page 55 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= 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 need 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 13 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
Voucher to CRU Presumably we're getting rid of this
Assumed to be at stage C in migration so this will
no longer be valid when the changes to Stock take
4 place.
5 Unpaid Cheque
231 Encashed OB Cheg to CRU
278 POL Cheque
Table 13 — Method of Payment Products
These products should continue to be adjusted by value by the Stock Adjustments
function.
Table 14 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
‘7 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 14 — Stock Products currently adjusted by Value
These products should continue to be handled by value in all cases.
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.
© 2004 Fujitsu Services Post Office Account Page 56 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Since the intention is to remove non-value stock as a concept any processing of non-
value stock will need to be removed. (See also section 2.5.1.1.3) [BT 106]
2.5.1.3 Reporting
These are new requirements and weren’t included in the March 2003 costings. I
There are a number of aspects to this:
Remuneration Reporting
Office Snapshot Report
Suspense Account Report
Counter Weekly Redeemed Savings Stamps Report
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]
Currently all reports have references to CAP within their headers. Changes will be
required to change this to either a Trading Period identifier or a Trading Period date
Range.
Detail to be agreed as part of Counter Dialogues discussions.
2.5:1.3-41 Remuneration Reporting
This supports the Business Process Produce Sales Report to Assist Remuneration
Check.
The requirements are to be met by making a change to the way in which the current
Sales Report is produced.
© 2004 Fujitsu Services Post Office Account Page 57 of 145,
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 [CDIAG], 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 Psd days before “today”
I need to define xx, but it will probably be 42 days. This value needs to be defined as a
parameter in POA Reference Data so that we can adjust it simply if required.
Alternatively can do this validation by walking the chain of EOD Markers and ensuring that
the EOD Marker for the day before Start Date is found. However a fixed limit is probably an
easier check.
5) The scan for the Transactions to build the report should be modified so that if a
Date Range is specified, then the start point for the transactions is defined as
the EOD marker for the Trading day before Start Date, and the end point for
the transactions is defined as the EOD marker for the Trading day of End Date.
These EOD markers can be found by following the chain of EOD Markers
from the Current EOD Object.
2:5:1.3:2 Office Snapshot Report
This supports the Business Process Review Stock Held Across Branch.
This report is similar in layout to the Stock Unit Balance report, however covers all
transactions for all Stock Units, rather than being restricted to a single Stock Unit.
It is proposed that its scope is unchanged, however the actual report layout will be
changed in line with the changes being made to the Stock Unit Balance report as
defined in section 2.5.1.4.1.3. [BT037]
© 2004 Fujitsu Services Post Office Account Page 58 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 Accounts
to be “retired”, some additional flexibility is required in the way the report is produced.
Currently all possible Suspense Accounts are reported on in the Suspense Account
Report. In future only those Suspense accounts 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.
2.5.1.3.4 Counter Weekly Redeemed Savings Stamps Report
This is a new report. [BT107]
It should become a mandatory report with a cut-off and must be produced if any
savings stamps have been redeemed. It should include a total of all transactions which
involve redeemed trading stamps since the last cut-off. These can be identified by
having a Level 2 accounting node of 535.
2.5.1.3.5 APS Transactions Report
This report is currently produced based on all Transactions that are found under the
APS Node in the accounting hierarchy. Given the need to introduce Stock Products
for AP Transactions, then the report should be changed to report on all Transactions
which have been written with <Application:APS>.
2.5.1.3.6 Event Log
No changes are required to the reports as such, however there will be additional events
introduced which will need to be categorised appropriately to appear on the various
subsets of events.
This should be purely a Reference Data change to the Events Collection.
2.5.1.3.7 Other reports affected by changes to Stock Processing
The changes to Stock Processing, particularly those requiring stock to be held by
Volume rather than by Value (see section 2.5.1.1.2) require a number of reports to be
changed so that stock values are no longer reported. [BT056]
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 14 (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:
© 2004 Fujitsu Services Post Office Account Page 59 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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
Office Weekly Transfer Reconciliation See section 2.5.1.3.7.2
Office Weekly Unreconciled Transfers See section 2.5.1.3.7.2
EPOSS Receipts and Slips
Remittance In Slip See section 2.5.1.3.7.1
Remittance Out Slip See section 2.5.1.3.7.1
Transfer In Slip See section 2.5.1.3.7.1
Transfer Out Slip See section 2.5.1.3.7.1
LFS Reports and Receipts
[Return Advice Note See section 2.5.1.3.7.1
Table 15 — Reports affected by Stock Changes
2.5.1.3.7.1_ I Remittance and Transfer Reports
The report layouts should remain unchanged, however any stock remittances will be at
zero value, thus resulting in the value column usually being zero in such cases.
Since there will be some cases (eg cash), where the value is non-zero, the actual report
layout will not change. In particular zero values will still be output in the report rather
than being suppressed.
2.6.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.
© 2004 Fujitsu Services Post Office Account Page 60 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= Counter Weekly Stock on Hand
This report needs to be restructured to provide a list of all stock items as held in
the stock on hand section of the Stock Unit Balance report (see
section 2.5.1.4.1.3).
Again, the value column should be remain in the report layout to support stock that
is still handled by Value and MOP products, 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.
This restructuring can probably 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 16 — 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. [BF060; BT060a]
The current mechanism for this is that each time one of these re-printable reports is
produced, then the start and end markers used for producing the report are stored and
the reprint is achieved by rescanning the transactions using those markers. This means
that reprints can be done for those CAPs that are still “in scope”.
I believe that “in scope” means the last 3 CAPs, however I’m not sure what happens with multi-
week CAPs. I suspect it is the last 3 CAP numbers which means that the Transactions must be
there even with a multi-week CAP.
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.
= Track and Trace Manifest: Reprint
The current functionality is purely to reprint the last report produced, so no change
is required.
© 2004 Fujitsu Services Post Office Account Page 61 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Office Weekly Inland Revenue Tax Credits P5589: Reprint
Office Weekly P&A P2311MA: Reprint
Office Weekly Redeemed Savings Stamps Summary: Reprint
Variance Report Reprint (new)
All of these will continue to be weekly reports, however they will be identified by
the Date Range for which they were produced rather than by the CAP of the week
for which they apply.
The requirement is to be able to reprint all those reports for which the data is still
available, ie the last 5 reports. Therefore, no changes are required to the way in
which the reprints are produced other than by identifying past reports by a date
range rather than a CAP.
= 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.
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 Stock _I [BT063]
Counter Daily Cash on Hand There is a separate report for Cash Declaration
which is nearly identical
It is just the Cash Declaration report that we
need to retain
Office Weekly Cash Flow This is replaced by the Variance report
Counter Daily Revaluation Session Slip
Table 17 — Reports to be removed
2.5.1.3.10 Weekly Reports
There are 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. Mandatory reports will be produced weekly by
reference to the calendar. Non-mandatory reports will be produced by the same means
© 2004 Fujitsu Services Post Office Account Page 62 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
COMMERCIAL IN CONFIDENCE
but if not printed will accumulate data during the trading period until they are printed
and will be forced to be printed at trading period end.
No support is required from Horizon to manage conformance to any of the above
other than the following:
= Existing mechanisms for forcing reports to be produced prior to Stock Unit /
Office rollover will be maintained
= Any necessary changes to ensure that reports can be cut-off 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.
Table 18 lists all the current weekly report and highlights those that need to be
considered further.
Report Name 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 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
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:
Reprint
Report to be removed
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.
© 2004 Fujitsu Services Post Office Account Page 63 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Office Weekly Redeemed Savings Stamps See section 2.5.1.38
Summary: Reprint
Office Weekly Remittances In (P) No cut off None
Should be Period based
Office Weekly Remittances Out (P) No cut off None
Should be Period based
Office Weekly Sales Report No cut off None
In future will be Date based
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 18 — Current Weekly Reports
The following changes are required:
= Office Weekly Inland Revenue Tax Credits
Office Weekly Inland Revenue Tax Credits P5589
Office Weekly P&A P2311MA
Office Weekly Pensions and Allowances
Office Weekly Redeemed Savings Stamps Summary
All of these reports need to change such that a cut-off is taken and the next report
will only look at the Stock Unit reports (ie Counter Weekly) produced since the
last time the summary report was cut-off. This is a new type of cut-off
functionality. Note that an implicit cut-off will occur when the branch is moved to
a new Trading Period. [BT116]
Note that there is currently no Counter Weekly Redeemed Savings Stamps report, however one
is being introduced for S80. See section 2.5.1.3.4.
2.5.1.4 Balancing and Rollover
There are a number of aspects to this:
= Changes to Rollover processing
= Branch Trading Reports
= Remove Extended CAPs
These are discussed further below.
2.5.1.4.1 Changes to Rollover processing
The March 2003 costings assumed no change to this process and so no costs were defined in
this area.
This supports the Business Processes Produce Trial Balance and Produce Final
Balance.
In general, the Stock Unit Balancing process will be very similar to that which is
currently in place. The following highlights the changes: [BT038]
© 2004 Fujitsu Services Post Office Account Page 64 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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
= Rolling over the data into the next Trading Period
The migration implications are covered separately in section 2.6.3.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:
= For all Stock Units (including the last)
8
a If this is a rollover into a new Trading Period (as opposed to a Balance period),
any Discrepancies will be moved to the Local Suspense account
This involves creating a Transaction to bring the balance of the Discrepancies
products to zero and create a matching transaction against the Local Suspense
Account product.
A new Mode will be introduced for such Transactions and the corresponding
Local Suspense Account Products can be identified as the balancing products
for this Mode, depending on whether it is a Positive or Negative Discrepancy
that is being transacted. Two Local Suspense Account Products (one for
positive and one for negative transactions) are required since they need to be
reported on in different parts of the accounting hierarchy. Only-a-single-Leeal-
a positive or negative value:
A single mode is sufficient if we use the S60 feature of having separate balancing products for
a given transacted product since we already have separate products for Positive and Negative
Discrepancies.
I'll leave the detail to the HLD.
We should not require a new mode. The discrepancies are held as Discrepancy Up and down
products. S60 code can transact these products in housekeeping mode and settle to either of I
the new Suspense products.
= 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).
© 2004 Fujitsu Services Post Office Account Page 65 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
a If this is a rollover into a new Trading Period (as opposed to a Balance period),
need to ensure that there are no Discrepancies within the Stock Unit and that
Local Suspense account has been cleared.
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, and additional check is
required.
If the rollover is to a new Trading Period, then any Nett Discrepancy needs to be
transferred from the Stock Unit to the Branch’s Local Suspense Account. This is done
by generating a pair of transactions such that the cumulative value of the Discrepancy
products for that SU becomes zero and this transaction is balanced by a transaction
against the Local Suspense Account product.
A consequence of this is that the Final Balance Report will 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]
= Balance Section
Since Stock is to be held by volume rather than value, then 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.
If a Transaction has a Tertiary Mapping, then it is ignored when constructing this
section of the table. This will result in only those Inventory products with no
Tertiary Mappings (eg cash, cheques, other stamps or Foreign Exchange) being
included in this section of the Balance Report.
= Receipts Section
All stock movements will need to be included in the receipts section.
Tf an Item has a Tertiary mapping then this should be used instead of its Primary
mapping when building up this part of the report.
© 2004 Fujitsu Services Post Office Account Page 66 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
In addition a further line will be required for Local Suspense Transfers. This can
be achieved by defining appropriate Primary Mappings for this product.
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 stock Remittances will have zero value, then they will
be excluded from the Remittance part of this section. The same also applies to
Stock Transfers.
Is this OK? Do they need including elsewhere?
Assumed OK.
Assumption recorded in section 8.4
= Payments Section
If an Item has a Tertiary mapping then this should be used instead of its Primary
mapping when building up this part of the report.
A new line will be required for Local Suspense Transfers. This can be achieved by
defining appropriate Primary Mappings for this product.
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 stock Remittances will have zero value, then they will
be excluded from the Remittance part of this section. The same also applies to
Stock Transfers.
Is this OK? Do they need including elsewhere?
Assumed OK.
Assumption recorded in section 8.4
= 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
© 2004 Fujitsu Services Post Office Account Page 67 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
a 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.
This data will be held in a Persistent Object as described in section 3.4.3.
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]
It is assumed that the existing Office Rollover button will trigger this report instead of
the current Cash Account Report.
[ this can be confirmed as part of the Counter Dialogues discussions.
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]
[Are there any other checks that need to change?
4) The report can then be built up as follows:
Perhaps this is too detailed for a DP, however I've included it since it is my way of clarifving
my understanding of the requirement.
Assume all lines printed in standard font and nothing clever.
Assumption recorded in section 8.4
a) Standard Heading
[Details to be defined as part of Counter Dialogues discussion
b) The data in each column is based on the details recorded when each
Stock Unit rolled over into the next trading period. The last column
provides an Office Total and is obtained by summing the values in the
© 2004 Fujitsu Services Post Office Account Page 68 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.1.4.3
2.5.1.5
2.5.1.5.1
row. 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 — the last column of the last page will contain the
Office totals.
c) The data in each row can be obtained from the data stored as part of
each Stock Unit’s rollover process (see section 3.4.3)
d) The Trading Position and Balance Carried Forward lines should be
calculated by summing the lines above (taking into account “logical”
signs). Note that the Balance Carried Forward figure must be zero
(otherwise an error has occurred).
Do I need to be more specific about the calculation?
What should happen if the Balance Carried Forward is non-zero? I suggest we do what is
currently done with an unbalanced Cash Account Report.
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.
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]
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.
Removal of LFS Weekly Stock Reporting functions
The current LFS Weekly Stock Reporting functions which are run on Wednesday,
Thursday and Friday, 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.
© 2004 Fujitsu Services Post Office Account Page 69 of 145
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
In theory it could be done tomorrow, but we need to understand what constraints there might be
from testing as to when it is removed. The actual removal is a change to the Reference Data
that controls the CAS.
2.5.1.5.2 POL FS Summarisation at counter
This functionality was introduced as part of Impact Release 1 at S60. With the move
to Transaction Summarisation at the Data Centre (see section 2.5.2.8), this
functionality will no longer be required other than perhaps to calculate the Carried
Forward cash position for the SAP ADS ONCH data flow. It is proposed that the
simplified EOD reconciliation process (described in section 2.5.1.5.5) takes over the
maintenance of this Carried Forward cash position, thus allowing this function to be
removed once migration is complete.
This means that this function will no longer be required once migration is complete.
Therefore no changes will be made here and the Reference Data that invokes this
function will be removed at the appropriate migration stage (see section 2.6.2).
2.5.1.5.3 Maintenance of Office Variances Persistent Object
In order to support the Variance Report (described in section 2.5.1.2.2) a new function
is required as part of EOD processing to calculate information for the report.
This function will assemble the data needed for that day’s portion of the Office
Persistent Object.
The information that needs to be assembled and the way in which it is calculated is:
= Suspense
Is there an appropriate accounting node (or pair of nodes) that will enable data Server to
calculate this easily?
WW: I don't think there is. The suspense nodes are spread throughout the accounting
hierarchy, not conveniently under a single node or even a node pair. There is a collection,
SuspenseGroups which defines what goes onto the Suspense Account report in terms ofI
EPOSSProduct pairs. This may be sufficient for our purposes. If not, it might be possible to
extend this collection to include the appropriate EPOSSNodes as well.
This level of detail can be sorted out in the HLD.
Local Suspense
can presumably be done in a similar way to Suspense. It is probably OK to treat Local
spense in the same way as Suspense for most purposes.
This level of detail can be sorted out in the HLD.
= Adjustments
This is calculated by scanning all events from yesterday’s EOD Marker and
accumulating the net value of all Cash Made Good and Excess Cash Removed
events (Ids 59 & 58).
= Transaction Corrections Processed
This is calculated by scanning all Transaction Completion Complete messages
events from yesterday’s EOD Marker.
= Transaction Corrections Outstanding
© 2004 Fujitsu Services Post Office Account Page 70 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
This is calculated using the same logic as defined in Section 2.5.1.7.2.
= Stock Units not logged on Today
How is this done? Presumably can be done by checking all the SU Objects and building up an
appropriate list.
Or perhaps not transacted.
This level of detail can be sorted out in the HLD.
2.5.1.5.4 LFS EOD functionality changes to handle changes in Cash Declarations
Since significant changes are required to this code and the current code has
maintenance problems (due to being written in C rather than VB like the rest of the
counter code), it is proposed that this functionality is re-written in VB allowing the old
code to be retired.
The function will need to carry out the following:
= Examine the various Variance Persistent Objects (described in section 3.4.2) and
their associated Declaration messages to build up the Declared cash Position for
that day.
I won't attempt to specify this logic but will leave it to the HLD. I
= Write the data in the ONCH message as at present. It should be noted that the
number of denominations of cash means that this data will always fit into a single
Riposte message so the logic in the existing code to handle the storage of excessive
data in a BLOB is not required
Need to check that I’ve got my sums right in this.
This can be resolved in HLD work
[BT029]
2.5.1.5.5 Simplification of EPOSS Reconcili
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.
ion
It is proposed that this is achieved by providing a new function that merely calculates
the Daily Transaction Totals. The code for this can be extracted from the current
function into a new function. Whilst it is scanning through the transactions to do this it
can also maintain the Daily Cash Movement figure that is required by the LFS EOD
functionality.
We may need to make some changes to the way in which the Daily Transaction Totals is
calculated to address the issue of “Settlement Transactions”.
However assuming we take the approach of changing to use normal Product Ids for Settlement
Transactions as discussed in section 2.5.1.1.6, no changes should be needed here (other than
perhaps removing any special code that excludes them at present).
© 2004 Fujitsu Services Post Office Account Page 71 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
NB the current POL FS Summarisation functionality relies on the summarisation mappings in
the Cash transactions to operate correctly. Need to consider how we do this in future. It is
proposed that we leave the Type C Ref data that does this in place.
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]
In order to support migration from the old EOD functions to the new EOD function,
the new function need to be implemented in such a way that it will run after the old
ones (if there is a possibility that they are both run on a given day) and that when it
runs that it checks to see if the old ones have done the work already and if so to do
nothing.
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?
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. [BTOS1]
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
© 2004 Fujitsu Services Post Office Account Page 72 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
These are discussed in the following sub-sections.
2.5.1.6.1 ONCH run for “yesterday”
The checks currently carried out as part of the logon process that an ONCH
declaration was made the previous day, should be amended to check that a Cash
Declaration was made the previous day. If no cash declaration was made the previous
day, the user will be invited to make a declaration at that time, but may decline to do
so (this is different from the current ONCH check at log on since at present there is no
option to decline). [BT028]
2.5.1.6.2 Stock Unit in correct Trading Period
The existing check that a Stock Unit is running in the correct Cash Account Period
(based on the Cash Account Weeks Reference Data), needs to be modified such that
the check is based on the Trading Period (based on the Trading Period Calendar).
In order to spread the workload at the centre, different branches will operate to
different Trading Period Calendars and each Branch’s “Outlet Reference Data” will
indicate what Calendar it should operate to. [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, and additional check is required on logon for any user with a
Role of Manager or Supervisor (actual list of Roles to be defined in Reference Data
see section 3.5), to see if there are any unprocessed Transaction Corrections. [B¥924-
BT024a] How this is done is described in Section 2.5.1.7.2. If there are the user
should be prompted about their existence and given the option to invoke the Process
Transaction Correction function immediately. Such a check should take place after all
other existing checks.
An event needs to be recorded when a user is prompted. Section 20.15 of [CDBT]
defines how the event should be categorised. This is a new event with Identifier 62
and needs to include a parameter indicating the number of Outstanding Transaction
Corrections.
a Process Transaction Correction
The March 2003 costings for this assumed that a centrally generated memo view was sufficient
and so no counter functionality was required. Any counter work is therefore in addition to the
March 2003 costings.
This supports the Business Process Handle Transaction Corrections.
There are a number of aspects to this:
= Actual Processing of the Transaction Corrections
= Selecting Transaction Corrections
= Reporting on Transaction Corrections
These are discussed in the following sub-sections.
© 2004 Fujitsu Services Post Office Account Page 73 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
DSM A Actual Processing of the Transaction Corrections
This is new functionality to automate the processing of Transaction Corrections (a
replacement for Error Notices). It is only available to those Roles who can do an
Office Balance (ie Manager, Supervisor, Migrate, Auditor and Auditor - Emergency
Manager). This will be controlled using normal Menu Security functionality.
This function will be activated by a new button on Horizon or as part of the logon
process (see section 2.5.1.6). [BT025]
The Counter Dialogues will decide where the button will be added to the system.
I suggest it is somewhere under the Housekeeping menu, thus ensuring it has the correct access
permissions.
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.
TC Reference is a concatenation of Iteration flag and Reference Id.
The user can then select a Transaction Correction from the list and process it.
Once a Transaction Correction has been selected for processing the system needs to
ensure that no other user is able to select that Transaction Correction for processing.
Not sure how to do this, but it is no different from preventing multiple users from producing a
Cash Account at the same time.
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.
This detail can be sorted out in the HLD.
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.
None of these options clash with existing Modes. However, some of these new modes will need
to be configured to act such that a Settlement product is not required when transacting (eg
when transacting MG).
Section 3.3.2 defines how the Transaction Correction is to be held as Attribute
Grammar.
Depending on the mode selected the Transaction Correction will be processed as
follows:
m__Mode MG (Make Good)
© 2004 Fujitsu Services Post Office Account Page 74 of 145,
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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:>).
= 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.
In all cases the transactions that are generated by this process (including any settlement
transactions) need to include the TC Reference (<Data.Ref:>) and the additional data
field (<Data:AddRef:>) so that it can be passed to POL FS.
These should be put into two new attributes under
<EPOSSTransaction.BlackBoxData:> called Ref and AddRef.
I mplif—_H. : 5 5
Note that there are potential requirements to handle adjustments to both value and volume. In
this case we will need to use the loss price if available for the products.
Need further guidance on the precise requirements here.
Assumed out of scope.
Assumption recorded in section 8.4
When the Transaction Correction is processed a Transaction Correction Processed
message should be written as part of the same Riposte Transaction, thus enabling
reports to understand the outcome of the Transaction Correction and to ensure that it
is not reprocessed.
It will also be possible to abandon the Transaction Correction by-use-of the Prey-or-
Home-button. 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.
© 2004 Fujitsu Services Post Office Account Page 75 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 EPROSS
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”.
25 AT 2 Selecting Transaction Corrections
Section 3.3.2. describes how a Transaction Correction is stored within the
messagestore. Transaction Corrections can be easily identified by having a
<WAIndex.LFSFlag:TC> attribute and a <Data.TCId:> attribute 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 aise ae that have been received in the branch. beep jaids Decne
Period Mark d-teimit thi -F:
I suggest that the whole store is searched. It would help if the query is as refined as possible to
search on <WAlndex.LFSFlag:TC><Application:TC>, and only for the Correspondence server
Nodes.
This can be defined in the HLD.
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
<WA\Index.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
<WA\Index.LFSFlag:TC> message and a corresponding <WAIndex.LFSFlag:TP>
message identify those Transaction Corrections that have been processed.
25108 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
© 2004 Fujitsu Services Post Office Account Page 76 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 [CDIAG].
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.2 Host Components
2.5.2.1 RDMC
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.
This may be a bit too simplistic. I'll leave it to the HLD to be more precise.
For example, I would expect any Transfers to be excluded and so the Transfer In / Out modes
may need to be explicitly excluded from the checks.
2.5.2.2 LFS
Nothing was included in the March 2003 costings in this area.
The weekly Stock Reporting functionality can be removed. This affects both the LFS
Agent and the LFS Host. Since the information is currently unused, it might as well be
removed as soon as LFS is upgraded at the Data Centre. [BT058]
This will be a change to the LFS Host only. The LFS Harvester will be left alone thus
it will continue to harvest any Stock-on-hand data that is generated by the counter.
2.5.2.3 Process SAP ADS Transactions
This is a new requirement and wasn’t included in the March 2003 costings.
POL are now considering dropping this requirement.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Assumption recorded in section 8.4
[BT108]
This functionality will be done within the TPS Host system.
This supports part of the Business Processes Deliver Data to External Systems.
© 2004 Fujitsu Services Post Office Account Page 77 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
At Impact R1, SAP ADS sends summaries of its Transactions directly to POL FS,
however for R3, there is a requirement for SAP ADS Transactions to be included in
the POL Data Warehouse, and so such Transactions will need to pass through TMS.
At this stage it isn't very clear as to exactly what is required.
The current assumption is that SAP ADS will provide a single file each night,
containing a mixture of Summarised and Transactional Data which is passed to both
POL FS and TMS. POL FS will load the data in a similar way to that in which it
processes the file at Impact Release 1.
TMS will have a new function which will process the file and extract any Transactional
Data and load it into a file for passing to MIS. The format of the file is described in
section 3.2.3.2.
2.5.2.4 TPS Harvesting
This supports the Business Processes Scan Transaction for Day.
A few changes have been identified as being required here:
= Additional event information is required for MIS. Therefore the details of which
events are to be harvested and how they are to be transformed needs to be refined.
The following additional events are required [BT 110]:
D Ti (Comment
55 _ [Trading Statement Created
56 _Trading Statement Period rolled
‘57 _ITrading Statement Period Roll
\Abandoned
58 Excess Cash Removed Parameter required indicating amount
59 (Cash Shortage Made Good Parameter required indicating amount _I
60 (Cash Variance Report Previewed
61 (Cash Variance Report Printed
62 Outstanding Transaction Correction Parameter required indicating number of
Reminder Displayed Transaction Corrections Outstanding
Ie this required?
Table 19 — Additional EPOSS Events to be harvested
Note that additional Product Ids will need to be provided by Post Office Ltd onto
which these Event Ids should be mapped by the agent. These Product Ids will be
formally defined in [MISAIS] once they have been allocated by the Post Office
Reference Data team.
= In order to support the generation of individual Transactions for POL FS, it is
necessary to pick up the various Reference attributes if they are present.
Reference attributes will be present on Remittance Balancing transactions (in
Attribute <EPOSSTransaction.BlackBoxData.Pouchld:>) and also for Transaction
Corrections (in Attributes <EPOSSTransaction.BlackBoxData.Ref:> and
<EPOSSTransaction.BlackBoxData.AddRef:>).
Two new columns will be required in the EPOSSTransaction interface tables, Ref
and AddRef into which these are harvested. If it is present,
<EPOSSTransaction.BlackBoxData.PouchId:> will be harvested into the Ref
column.
© 2004 Fujitsu Services Post Office Account Page 78 of 145,
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Note that both attributes should never be present and it is acceptable to use the existing
harvester technique of mapping both attributes to the same variable on this basis.
db the TRS
y
= Currently, the mode under which a Transaction is carried out is mapped by the
Harvester from a mnemonic to a numeric value to conform to the OPTIP interface.
It has been agreed that for the POL FS interface we will use the mnemonic values,
so we will need to add a new column into all the relevant TPS Interface tables to
include the mnemonic mode value.
The numeric value is still required by the OPTIP interface and will also continue to
be used by MIS.
= 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 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 (see section 2.6.3.2). If the Stock Unit is
operating in a Branch Trading Period mode no further attempt should be made to
calculate CAP or BP and values of zero should be input into the TPS Interface
tables. Note that if no Stock Unit Persistent Object is found (for example because
it has been deleted since the transaction took place), then again values of zero
should be returned. If TPS is in the early stages of migration, then this will result
in the Transaction being handled as an Exception, but that is no different to what
happens at present.
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.
Remove the NB103 drilldown functionality on the DRS Workstation
Potentially this should be done some time later since this is used to look at historic reports.
See also section 2.6.2
In a number of the NB102 reports the CAP column will be blank.
The specific sections are 2, 3, 4, 5, 8,9, 10 & 11.
No change will be made to these reports for Impact R3.
We should look at removing this column in a future release, but leave it there for Impact R3.
© 2004 Fujitsu Services Post Office Account Page 79 0f145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= The DRS function that copies in data from TPS Host about Cash Account Delivery
to POL needs to stop doing that. Note that the function cannot be removed
altogether since it also copies in data on non-polled offices and it is assumed that
this is still required.
Other than that the reconciliation process remains unchanged. [BT059]
2.5.2.6 APS Host
I’m not aware of any changes needed here now.
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 ina 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.
Need to decide exactly how settlement transactions are to be identified. My working
assumption is that this can be done based on Ref Data available to TPS Host. However if there
is a need to include a new flag from the counter, then there will be knock-on effects on the TPS
Harvester and EPOSS Core.
This detail can be sorted out in the HLD.
PJ: Does this include Cash, Cheques etc? or just Automatically settled products (112??
Range). If this is to include just the auto-settle products then these have an <ASP:> attribute
that could be harvested.
2.5.2.8 Transaction Summarisation
This functionality will be done within the TPS Host system.
This supports the Business Processes Accumulate Transactions for Summarisation.
Currently this is being done at the Branch and the summaries are harvested into TPS
for passing onto POL FS.
There is no specific requirement on Fujitsu to make the changes in this area. This is because
we have chosen to do this as it makes the overall system simpler.
However what is now proposed is a new Summarisation function at the Data Centre
that will run as part of the normal overnight processing after the day’s data has been
harvested.
Summarisation is a three-stage process:
= Initial Summarisation of Product and Mode
© 2004 Fujitsu Services Post Office Account Page 80 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.2.8.1
2.5.2.8.2
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
Summarisation for POL FS
Summarisation for HR SAP
These are discussed further below.
Initial Summarisation of Product and Mode
All Transactions are summarised by Product / Mode combinations such that for each
Branch and Trading Day there is a single Summary Record for each combination of
Product / Mode that has taken place during the Trading Day.
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).
The rules for Summarisation are as follows:
1)
2)
3)
For each set of Transactions that have been summarised by Horizon Product
and Mode they can be further summarised as follows:
a)
b)
c)
d)
Reference Data will define the Article associated with the given
Horizon Product.
This Article will have associated one or mode Article Modes
corresponding to the Horizon Mode under which the Product was
transacted.
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
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
If the Article Mode is described as being “non-summarised”, then the
underlying transactions need to be extracted together with the required
References and held instead of the summary. Such transactions should be held
in the summary store as if they are summaries.
A number of attributes are associated with the Article Mode and these will
need to be passed to POL FGS with the associated Summary.
A potential problem is that some transactions will have failed Harvesting and will
subsequently be passed through when they are ‘Tepaired. Sie sne et hee
d-the-S
40-do-with-th yi
PB
balance”.
ory i Hh d-the-original isation-to“net
act ginal a
Recent analysis shows a number of causes:
rate for that currency.
© 2004 Fujitsu Services Post Office Account Page 81 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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.
Also need POL to consider if this is acceptable. They also need to be aware that in such cases
the majority of the transactions from those branches will have been passed to MIS and so MIS
will not be exactly in step with POL FS.
Assumed OK.
Assumption recorded in section 8.4
Are there any special considerations when opening a new branch in terms of the opening
figures?
This will need to be addresses as part of HLD work.
2.5.2.8.3 Summarisation for HR SAP
A separate set of summarisation, again based on Reference Data, maps the Product /
Mode summaries for each Branch / Trading Day onto the data required for HR SAP
based on CTT Numbers. Note that not all Branches are required for HR SAP
summarisation (though it may be simpler to summarise for all branches and discard
those not required when the interface is built for HR SAP each month, since the
numbers of branches not required are fairly low - it is the Directly Managed Branches
of which there are about 600).
It is proposed that sets of summarisations are held for each branch for each target Pay
Period (as defined in Reference Data). Each day, the intermediate summaries
(described in section 2.5.2.8.1) are added into the set of summaries for the appropriate
Pay Period based on the Trading Date for which the transactions making up the
summaries took place. Note that for some CTT numbers (specifically Lottery
© 2004 Fujitsu Services Post Office Account Page 82 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
transactions), the summaries will need to be added into an earlier Pay Period than
others. This will be defined as part of the mapping Reference Data.
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 an
exception being generated for manual investigation. This should only happen if a
branch has been non-polled for a significant period and so should be very rare.
PJ: I was assuming that any late polled txns (after the summaries have been sent) are
summarised into the next period.
2.5.2.9 Accept CAPO Data
POL are now considering dropping this requirement.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL
Assumption recorded in section 8.4
This functionality will be done within the TPS Host system.
This is a new process that takes the file from EDS and loads the data into the
Summarisation store such that the information can be merged in with the data being
sent to HR SAP each month. [BT111]
The file is received once a month and there is about 2 weeks before the data is required
for the HR SAP file generation process.
It is assumed that Reference Data will provide a mapping from an entry in the file to a
single “CTT number” (see section 3.5).
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 ina separate file for a separate payroll run.
POL are planning to simplify this such that all Postmasters / multiples will be paid
based on the previous months trading data. However it is not yet agreed when this
might happen, so we have designed the summarisation and file generation mechanisms
to support the current interface. need-te-provide-twe-alternate-designsforthesetwe-
sSeenartos-
© 2004 Fujitsu Services Post Office Account Page 83 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
The summarisation process (including any complexities associated with accounting for
Lottery transactions “early”) is described in section 2.5.2.8.3. This process is purely
concerned with the ability to generate the two separate files each month to contain the
data for the relevant branches.
A single file generation process is required, however a parameter will be required
indicating whether it is to produce the files for the “multiples” (as defined in
[HRSAPAIS1]) or the file for the bulk of the branches (as defined in [HRSAPAIS2]).
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 raise an exception in
this case. 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,
he Ref Data-for-S hthe-branch lude-and-alse_the-AIS
defining-the-File format-th He painhs !
It iI} F f ‘bset-of T 7? th.
-
2.5.2.11 Generate POL FS Info
There is no specific requirement on Fujitsu to make the changes in this area. This is because we
have chosen to do this as it makes the overall system simpler.
This functionality will be done within the TPS Host system.
© 2004 Fujitsu Services Post Office Account Page 84 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
This supports part of the Business Processes Deliver Data to External Systems.
A set of files is required to be generated each night for passing to POL FS. The
structure of the file is basically the same as for S60, however the detailed record
formats have changed. Instead of building up the summaries at the counter and
passing them straight through to the file generation function, the summarisation will
now take place at the Data Centre. Some transactions (as defined in Ref Data) will
still need to be passed through “un-summarised”. All records for a single Branch /
Trading Day should have a net value of zero. This needs to be checked as part of the
file generation process and exceptions should be raised if that isn’t the case.
In order to support SLA Monitoring, information needs to be passed to the POA Data
Warehouse defining which Subfiles have been delivered to POL FS and the number of
Transactions associated with these sub-files. The calculation of the number of
transactions is already being made for the flow to MIS, and there is no need to re-
calculate this. Any differences (eg due to exceptions) can be ignored.
2.5.2.12 Transaction Correction
This functionality will be done within the TPS Host system.
This component takes the file produced each night by POL FS of Transaction
Corrections and passes them on to the specified Branch. [BT 113]
This is a standard File Load and Distribute process very similar to that used for
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.
Do-We need to reject records where we fail to do this mapping.2. Currently the AIS has no
validation rules on these fields (since I originally planned to do this mapping at the counter).
Need to define detailed mappings from File to Interface tables to Attribute Grammar sometime
/somewhere. However I see this as part of the HLD rather than the DP.
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.
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
= MIS File Delivery
= CTS File Delivery
© 2004 Fujitsu Services Post Office Account Page 85 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= HR SAP File Delivery
= SAPADS to MIS File Delivery
= Transaction Corrections File Delivery
252 13.0 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:
Source TPS The source of the SLA
Dest PES 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 20 - POL FS File Delivery Information
In order that this information can be compiled, TPS must record the number of
individual transaction records that have been aggregated to create each sub-file. In
addition, an acknowledgement file must be generated by TPS that confirms the
date/time that each sub-file was delivered to POL FS. This file must be in the
following format:
C_Date The Creation date (EOD Date) of the sub-file
D_Date The delivery date/time of successful delivery of the sub-file
FAD_Code The FAD Code of the sub-file
Table 21 — POL FS File Receipt Information
The Acknowledgement file will be loaded into TPS and joined with the data that has
recorded the number of originating transactions in each sub-file and the resultant data
will be written to the existing (TIP) MIS SLA file that is presented to the Data
Warehouse.
The only changes to the Data Warehouse should be the addition of Meta Data that
defines the new SOURCE and DEST along with the target SLA times to be measured
for Days A through J.
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.6.2.13.3 CTS File Delivery
It is assumed that there will be no measurement of the delivery of CTS Files
© 2004 Fujitsu Services Post Office Account Page 86 of 145,
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.5.2.13.4 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 each of the two files that must
be delivered.
= That timely delivery of a file to HR SAP is sufficient to meet the SLA 100% even if
the file does not contain content for all branches
= That the CAPO data for each file delivery must have been received at least 24
hours before the delivery of any file required by HR SAP
If the CAPO interface is withdrawn then this dependency can be withdrawn.
The TPS System will send each of the files to the HR SAP system and the successful
receipt of an acknowledgement from the remote FTMS Gateway will indicate the
measure of successful delivery.
TPS will send the following information to the MIS system in the existing MIS SLA
delivery file:
FieldName __I Value Description
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 (ie: Tescos)
HRS2 is the file delivered to support normal
Braches
C_Date 00:00 on the Thursday before the However, if the receipt of information from
weekend of the pay run CAPO is later than this time, then this date will
be the date/time of receipt of file from
CAPO.11
D_Date The delivery date/time of successful
delivery of the HR SAP File
Records The number of originating transaction I This will always be ‘1’ since we are measuring
records the file rather than the contents
FAD_Code The FAD Code of the sub-file NULL. FAD Code is not relevant
Table 22 — HR SAP File Delivery Information
New meta data will be required in the Data Warehouse that measures successful
delivery as being within 24:00 hours + 21:30 hours of the C_date.
The Data Warehouse will need to be updated to accept NULL FAD Codes.
2.5.2.13.5 SAPADS to MIS File Delivery
POL are now considering dropping this requirement. If so this section will be deleted.
POL to confirm.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Assumption recorded in section 8.4
It is assumed that the measure will be on successful delivery of the entire SAPADS File
to MIS
11 Will be removed ifno CAPO flow
© 2004 Fujitsu Services Post Office Account Page 87 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
In order to measure the delivery, TPS must provide the Data Warehouse with a file of
records in the following format:
FieldName I Value Description
Source TPS The source of the SLA
Dest MIS The destination (ie: MIS)
C_Date The receipt date/time of the SAPADS I Date/Time it arrived on the local FTMS.
File Gateway
D_Date The delivery date/time of successful Date/Time of the acknowledgement received
delivery of SAPADS File back from the remote MIS FTMS Gateway
Records The number of originating transaction I This will always be ‘1’ since we are measuring
records the file rather than the contents
FAD_Code The FAD Code of the sub-file NULL. FAD Code is not relevant
Table 23 — SAP ADS MIS File Delivery Information
The MIS SAPADS SLA Acknowledgement file will be loaded into TPS and joined
with the data that recorded the file receipt from SAP ADS and a resultant record 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 and the cut-off time for File Receipt from SAP ADS.
2.5.2.13.6 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 24 — Transaction Correction Metrics
The only changes to the Data Warehouse should be the addition of Meta Data that
defines the new METRIC and RECEIPT_DATE cut-off time along with the target
SLA times to be measured for Days A through J.
2.5.2.14 TPS Host
A number of changes are required here:
= 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.
= The new events being harvested by the TPS Harvester (see Table 19 in
section 2.5.2.4) must not be passed through to OPTIP. Therefore the process that
© 2004 Fujitsu Services Post Office Account Page 88 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
generates the file for OPTIP needs to suppress those events should they be
harvested.
= The Settlement Transactions that are now being harvested into TPS need to be
suppressed on the flow to OPTIP. This is also a requirement on the MIS feed and
is discussed in section 2.5.2.7.
= In order to reduce the number of TPS Harvester Exceptions, which will result in
failures to deliver data to POL FS, a review is required of the constraints on the
TPS Harvester Interface tables, thus allowing some Transactions that are currently
handled as exceptions through to the main TPS system for processing.
It is proposed that the following constraints are removed at point D in the
migration process (see also section 2.6):
a That CAP and BP are greater than zero
Further constraints that can be relaxed may be identified as more detailed design progresses.
These will be captured in the HLD.
It will not be possible to relax all constraints on the TPS Harvester interface tables,
so this means that the Transaction Summarisation Function will need to be able to
handle such cases (see also section 2.5.2.8). Since the current failure rate is very
low (about 1 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.2
= 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 should be stopped once the feed to OPTIP is
removed. In particular the data from the branch will no longer to be available at
this point (or soon afterwards).
Note that the current interface of Bureau transactions to FRTS remains unchanged.
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
© 2004 Fujitsu Services Post Office Account Page 89 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
2.6.1 Migration Overview
Migration will occur over a period of time. The key phases are:
= Data Centre Migration (Phase A)
= Counter Software Upgrade (Phase B)
= Running the Final Counter Cash Account for CBDB (Phase C)
= Switch of TMS feed of Transactions from OPTIP to MIS (Phase D)
= Upgrade of Counter processes to operate Branch Trading Statement (Phase E)
[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.
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 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
fie-need-to-prevent2/ 3-week-CashAccounts-atthattime). This will ensure that we
have a clean cutover.
Other than that, this should be invisible to Branch staff.
Not completely true since some of the changes associated with Suspense and Housekeeping also
occur at this point.
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. It is expected that the interface will be switched
© 2004 Fujitsu Services Post Office Account Page 90 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
from the Impact Release 1 format to the new Impact Release 3 format a few days prior
to this rather than at point A.
There may need to be an earlier pilot of a small number of branch’s data to a test POL FS.
Should such a pilot be supported, then there will need to be a period of a few days between
ending the pilot and switching to the new interface to POL FS. The design will only support
such a pilot while we are passing Live Data to the Live POL FS using the Impact R1 interface.
We have only provided for supporting the pilot in our development costs. No operational or
test support has been included since the migration strategy is not clear.
Assumption recorded in section 8.4
2.6.1.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.
2.6.1.5 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.
2.6.2 Mapping of Changes to Migration Phases
Table 25 shows at which phase of migration each aspect of the functional changes
described in section 2.5 will change. The phases are described in section 2.6.1 above.
Functional Change Migration I Comment
Phase
Extending Transaction Retention A/B
Stock to be handled by Volume rather than I E
by Value
Merging of Value and Non-Value Stock Post E See section 2.6.3.3
Changes to Suspense Products c Also Error Notices and Vouchers are to be
disabled at this point
There are also some new Housekeeping
functions to be introduced at the same time.
‘Change APS to use EPOSS Core B
Settlement Transactions A-C This is a ref data change and so needs to
happen at a fixed time. It should be OK to
do this at any time between A and C and
shouldn't require the counter to be at S80.
Changes to Cash Declarations B
Reporting of Cash Variances B
Processing of Cash Variances E
‘Stock Declarations and Variances E
Non-Value Stock Declarations E This is removing functionality
Remuneration Reporting B
Office Snapshot Report E
© 2004 Fujitsu Services Post Office Account Page 91 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
Suspense Account Report B
Counter Weekly Redeemed Savings E
Stamps Report
APS Transactions Report B
Event Log B Though some new events will not be
generated until point E
Other reports affected by changes to Stock I E
Processing
Reprints of Reports E
Reports proposed to be removed E Some may go atB
Weekly Reports E May be able to do it at B
Changes to Rollover processing E
Branch Trading Reports [4
Remove Extended CAPs B
Removal of LFS Weekly Stock Reporting A-C This is a ref data change and so needs to
functions happen at a fixed time. It should be OK to
do this at any time between A and C and
shouldn't require the counter to be at S80.
POL FS Summarisation at Counter Post D This functionality can be removed by End-
Dating the Reference data that invokes this
function through CAS at any time between
points D and E
Maintenance of Office Variances Persistent I B
Object
LFS EOD functionality changes to handle B
changes in Cash Declarations
Simplification of EPOSS Reconciliation Post D This functionality can be removed by End-
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 D and E
Protection against lost data B
Logon Checks: ONCH run for “yesterday” B
Logon Checks: Stock Unit in correct E
Trading Period
Logon Checks: Outstanding Transaction B
Corrections
Process Transaction Correction GE Ormaybe-B since this-willbe-harmiessif
there-aren'tany
This has to occur at point E otherwise it will
be expensive to make the changes to
support TCs on a CAP report
Assume this is OK
Reporting on Transaction Corrections B
RDMC A
LFS D Needs to be done later to ensure that no
data is still coming through from the
Branches.
In particular it must be after “Removal of
LFS Weekly Stock Reporting functions”
Process SAP ADS Transactions D
TPS Harvesting A
DRS Host AD honda changes i N61 may Baye io
take-placeater
Changes to the DRS workstation may need
to be delayed.
POL to consider this.
Assumption is that this can be done at the
same time.
APS Host N/A
Generate MIS Info P)
Transaction Summarisation Cc
Accept CAPO Data Post D
Generate HR SAP Info Post D
© 2004 Fujitsu Services Post Office Account
Page 92 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Generate POL FS Info c
Transaction Correction Cc
POA Data Warehouse A
TPS Host N/A A and I The main changes take place at point A,
D however some of the changes to the
constraints on the Harvester Interface tables
should be left until point D.
Table 25 — Migration of Functions
2.6.3 Specific Migration Developments
As can be seen from Table 25, a number of migration activities need to take place
other than as part of the normal Software introduction changes.
These are:
= Process the final cash account for CBDB
= Upgrade of Counter processes to operate Branch Trading Statement
= Merging of Non-Value and Value Stock
= Switch of TMS feed of Transactions from OPTIP to MIS
= Accept CAPO Data
= Generate HR SAP Info
= Support of nRDS supported Settlement Products
= Support for Quiescent Rollover
These are described further below.
2.6.3.1 Process the final cash account for CBDB
There are two aspects to this:
= Branch
= Horizon Data Centre
These are discussed in the following subsections.
2.6.3.1.1 Branch
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
Branch rolling over into a specified CAP number defined in the Soft Launch Reference
Data. It is expected that the same CAP will trigger this change across the full estate.
This CAP will be flagged as requiring a quiescent rollover (see section 2.6.3.8). This
will ensure that the soft launch functionality is triggered correctly.
Further details will be in the HLD.
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:
© 2004 Fujitsu Services Post Office Account Page 93 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= The Permissions should be changed on the Housekeeping menu to restrict access
to Managers / Supervisors etc.
This is a global Reference Data change and it would be simplest to do this at a fixed time
across the estate.
I need to check with POL to see if there is a point at which we can do this independently of the
rest of the migration activities. Provided branch staff are expecting this then there should be
no problem, since it is anticipated that only Managers / Supervisors should be attempting to
use this functionality anyway.
I suggest we pick a date when most branches have moved to S80, but prior to point C. NB it
shouldn't matter if there are still some branches on S75.
POL to confirm.
Assumed OK.
= The existing Error Notice, Cash Shortage / Surplus and Vouchers buttons should
be removed from the Housekeeping Menus since these functions are no longer to
be used.
= Th ee +t} Fa! +4 fi ti hould—beer ilabh thi
= Buttons to support the new “local write off’ products should become available on
the Housekeeping Menu (see section 2.5.1.1.4.1)
2.6.3.1.2 Horizon Data Centre
The Transaction Summarisation function needs to be activated at this point and in
particular it needs to generate “opening balances” for the various new POL FS
accounts.
Need to consider the changes required to support moving of ForEx to individual currencies.
May have cases where txns go to POL FS prior to the opening balances. Philip Godden has
confirmed that this is OK.
Due to still having the full TPS Harvester constraints until migration point D, there will be an
increased likelihood of Summarisation failures during this early period.
Assumed to be acceptable.
2.6.3.2 Upgrade of Counter processes to operate Branch Trading Statement
This is the 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.
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.
© 2004 Fujitsu Services Post Office Account Page 94 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
This CAP will be flagged as requiring a quiescent rollover (see section 2.6.3.8).
This will ensure that the soft launch functionality is triggered correctly.
[ Assume nothing special is done here. I
= 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 “Phase E” in Table 25 will be made available. In
particular the buttons used to invoke the non-value stock functions will be
removed.
2.6.3.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.4 Switch of TMS feed of Transactions from OPTIP to MIS
This should be a simple change to the Maestro schedule to stop generating the TIP
stream and to start generating the MIS and CTS data feed.
The process to take the SAP ADS Transaction file and process it for passing to MIS
should be turned on at the same time.
2.6.3.5 Accept CAPO Data
This should be a simple change to the Maestro schedule to start searching for this file.
2.6.3.6 Generate HR SAP Info
This should be a simple change to the Maestro schedule to start producing this file.
© 2004 Fujitsu Services Post Office Account Page 95 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
There will potentially be a gap between the last Cash Account roll over and the first Trading
Period.
POL would like us to do something better.
However that is currently considered to be out of scope.
2.6.3.7 Support of nRDS supported Settlement Products
There is probably no migration development required here as such, however there is a
need to identify exactly how this migration is to take place.
The current state is that we have Type C Reference Data that defines the current
Settlement Products with appropriate Product Mappings. We also have Product Mode
Reference Data that identifies the Settlement Products.
Moving to Type A Reference data may give us problems in that the existing Type C
Reference Data will be using a particular suffix, and we need to ensure that the new
Type A Reference Data will use an appropriate suffix and not clash and we have a
mechanism to end date the old Reference data and start-date the new reference Data
smoothly. There should be no need to co-ordinate this in terms of CAPs since both
products should have identical mapping s and so will be treated identically.
Details to be defined in HLD.
2.6.3.8 Support for Quiescent Rollover
A new technique is introduced, that of a “quiescent rollover”. What this means is that
once a Stock Unit has rolled over into a specified CAP, no further work can be carried
out in that Stock Unit until the entire Branch has rolled into the new CAP (or Trading
Period).
It is proposed that this will operate as follows:
= The CAP for which this rollover is to apply is defined in Reference Data.
[Details to be defined in HLD.
= Once a Stock Unit rolls over into the target CAP the user is taken to a new screen
that will provide a limited number of functions (NB the functions will only be
included if the user’s role has permission to use it normally):
a Rollover to anew CAP
a Switch to another Stock Unit
ao Logout
a Check to see if the Rollover to the new CAP is complete.
The latter is a new function, and if it is selected and it is found that the rollover is
not complete, then it informs the user and returns to the screen defined above.
If it is found that the rollover is complete, then it invokes the Soft Launch function
which will update all the menus to the new target mechanisms (as is normally done
© 2004 Fujitsu Services Post Office Account Page 96 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
at Desktop start) and then display the top level menu and allow the user to
continue working as normal.
= Similar checks are required at Logon and Stock Unit Attach, namely is the Stock
Unit to which the user will Attach / Logon in a different CAP from the System and
if so is it the “critical CAP”. If so the user will be taken to the menu defined
above.
There may be a hole to be plugged when Counter 1 has rolled the branch and then a user logs
on counter 2. How do we ensure that the menus are updated unless we check for Soft Launch
on all logons?
I'll leave that for the HLD to sort out.
© 2004 Fujitsu Services Post Office Account Page 97 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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)
a Bank Statements (out of scope)
a Transaction Corrections (section 3.2.2)
a SAP ADS Transactions and Summaries (section 3.2.3)
a Ledger Entry Information (section 3.2.4)
a TMS Info from Clients (section 3.2.5)
a TMS Infoto-Cli
ao Remuneration Information (section 3.2.6)
a Management Info (section 3.2.7)
a CTS File (section 3.2.8)
= Internal Interfaces
These are described in section 3.3
a 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)
a TMSto Branch: Transaction Corrections (section 3.3.2)
o Within Branch: Transactions (section 3.3.3)
= Data Stores
ao Summary Store (section 3.4.1)
a Variance Persistent Objects (section 3.4.2)
© 2004 Fujitsu Services Post Office Account Page 98 of 145,
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
a Stock Unit Summary for Branch Trading Report (section 3.4.3)
Finally section 3.5 describes the dependencies on Reference Data.
3.2 EXTERNAL INTERFACES
3.2.1 Reference Data
Changes will be required to [RDSAIS] to include the changes to Reference Data
described in section 3.5.
3.2.2 Transaction Corrections
This is a new data flow from POL FS to Horizon giving details of Error Notices that
are to be distributed to the branches to be actioned.
The interface will be an overnight file from POL FS containing all the Error Notices to
be distributed for that day. Feedback will be provided to POL FS via transactions in
the normal Ledger Entry Information R2 flow (see section 3.2.4).
The interface is formally defined in [TCAIS].
Initial draft available.
The information is probably sufficient to cost the work required to support it.
3.2.3 SAP ADS Transactions and Summaries
POL are now considering dropping these interfaces.
POL to confirm.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Assumption recorded in section 8.4
The prime purpose of this flow is for SAP ADS to report Ledger Entry Information to
POL FS, however it also contain details of SAP ADS transactions which need to be
included in the flow to MIS.
Figure 5 has shown this as two separate interfaces:
= The interface from SAP ADS to TMS
= The interface from TMS to MIS
These are discussed separately below.
3.2.3.1 The interface from SAP ADS to TMS
The interface is formally defined in [SAPADSAIS].
But not yet!
© 2004 Fujitsu Services Post Office Account Page 99 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
For RI this flow was direct from SAP ADS to POL FS and only contained the
summarised data.
It has now been agreed that any summaries for which MIS requires detailed
transactional level data will be broken down and the file will contain all the detailed
transactions rather than the summaries. The additional volume of data to be loaded
into POL FS will be negligible compared with the data generated by the branches each
day.
In the absence of an AIS, the following assumptions are made:
= It is assumed that there is a simple mechanism to separate out the Transactional
data to be passed to MIS from the non-transactional data that TMS can ignore. It
is assumed that this differentiation is determined by Record Types in the file with
Record Type filtering criteria defined by Reference Data.
The S80 SAP ADS — POLFS interface will be based on the S60 interface. Client
transactions (e.g. giro change) need to be captured at the individual level. The
detail records will have a Client Id and probably Transaction Time added, but will
otherwise be the same as the S60 AIS.
The SAP ADS data is likely to be very simple — an initial view is:
Transaction Date
Transaction Time?
Cash Centre (FAD)
Client
Product/Service
Amount
Quantity
oooooaoods
3.2.3.2 The interface from TMS to MIS
This is based on the interface to MIS for Horizon Transactions defined in [MISAIS]
and will also be documented in [MISAIS].
Until we see [SAPADSAIS] I don’t think it is sensible to try and progress this.
The following is probably sufficient for costing purposes but not for taking the design any
further.
In the absence of an AIS, the following assumptions are made:
= It is assumed that the mapping of records from the form received to the form being
passed to MIS is trivial.
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.
© 2004 Fujitsu Services Post Office Account Page 100 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
The interface is formally defined in the AIS [POLFSAIS].
Initial draft available.
The information is probably sufficient to cost the work required to support it.
3.2.5 TMS Info from Clients
POL are now considering dropping this interface.
POL to confirm.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Assumption recorded in section 8.4
Currently a single flow of data from EDS concerning CAPO accounts activated in
order to feed Postmaster Remuneration.
The interface is formally defined in the AIS [EDSAIS].
The information is probably sufficient to cost the work required to support it.
In the absence of an AIS, the following assumptions are made:
= It is assumed that validation will be restricted to file format and that the FAD is
known to Horizon.
The AIS doesn’t actually say this. It should!
3.2.6 Remuneration Information
This is the interface to HR SAP and is formally defined in [HRSAPAIS1] and
[HRSAPAIS2] which are based on [HRSAPAIS].
Although these AISs are now available, they do not form part of the contractual baseline.
These Assumptions need to be included in the CT.
Assumption recorded in section 8.4
In the absence of an AIS, the following assumptions are made:
= tis-assumed That data will be provided one or two months in arrears as specified
in the summarisation Reference Data and—that-this—is—th fi henthi
= 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.
© 2004 Fujitsu Services Post Office Account Page 101 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
3.2.7
= 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 available for summarisation is to be
used for 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.
Although there are two separate AISs ((HRSAPAIS1] and [HRSAPAIS2)]), the file
format is identical in both cases. The differences are purely in terms of the file naming
and the identification fields in the file headers records.
There is a header record which provides control totals for checking the integrity of the
file.
This is followed by a series of detail records. There is one detail record for each
product sold by in a branch in a specified month. For each record there is either a
Volume (i.e. the total number of transactions for a product), a Value (i.e. the total
value of the transactions for a product), or in some cases both.
The file structure is Comma Separated Variable (CSV), ie each field value is separated
by a comma and each field is of variable length.
I’ve removed the remainder of this section which is now included in ([HRSAPAIS1] and
[HRSAPAIS2]. For clarity I've removed it altogether rather than marking it in strikeout.
Payroll period should come from the Reference Data Calendar (see section 3.5). The rest
should be straightforward.
Management Info
The starting point for this is the current OPTIP AIS and is formally defined in
[TIPAIS]. A new AIS will be produced defining this interface [MISAIS].
Need to spell out the changes.
Assumption recorded in section 8.4
The information is probably sufficient to cost the work required to support it.
© 2004 Fujitsu Services Post Office Account Page 102 of 145
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Fujitsu have now been asked to produce this. For now I’ve included proposed changes to the
current interface it below. One we have a draft AIS, it can be removed from here.
There are a number of aspects to the changes required:
= Changes due to removal of the Cash Account
= Additional Transactional Information
= Additional Event Information
These are discussed further below.
327A Changes due to removal of the Cash Account
The CAP and BP fields will be retained, however the values will be null once the
branch has moved from Cash Account to Trading Period (point E in the migration —
see section 2.6).
3.2.7.2 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 D6, D7 and D8 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.
3.2.7.3 Additional Event Information
Section D10.2 of [MISAIS] identifies some additional events that are to be passed
through to MIS. This is also defined in Table 19.
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.
The following is a suggested form for the Transaction Correction in Attribute
Grammar:
© 2004 Fujitsu Services Post Office Account Page 103 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
<Application:TC>
<WAIndex:
<LFSFlag:TC>
>
<Data:
>
<TranType:TransactionCorrection>
<Ref:> // Reference ID in [TCAIS]
<Iter:> // Iteration Flag in [TCAIS]
<Article:> / Article in [TCAIS] (but converted to a Horizon
Product)
<Instruction:> // Instruction in [TCAIS] (but converted to a Horizon
Product)
<AccountingSense:>
<Value:>
<Qty:>
<Modes:
cheb
<2:>
<g>
>
<Text:>
// Mapped from Label Identifier in [TCAIS]
// Error Value in [TCAIS]
// Error Quantity in [TCAIS]
// Derived from Allowed Modes in [TCAIS]
// The actual Modes (of which there can be up to 3)
// Message in [TCAIS]
The Transaction Correction can be uniquely identified by concatenating <Data.Iter:>
and <Data.Ref:>.
The following defines a completed Transaction Correction:
<Application:TC>
<WAIndex:
<LFSFlag:TP>
<TranType:CompletedTc>
>
<Data:
<Ref:>
<Iter:>
<Action:>
>
// Reference ID in [TCAIS]
// \teration Flag in [TCAIS]
// The Mode selected
May also need a pointer to the actual Transaction.
Detailed design of the reporting aspects should be able to decide if this is needed.
3.3.3 Within Branch: Transactions
This is the current recording of EPOSS Transactions.
3.4 DATA STORES
3.4.1 Summary Store
[ This will be defined in the HLD.
© 2004 Fujitsu Services Post Office Account Page 104 of 145
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
3.4.2 Variance Persistent Objects
As described in section 2.5.1.2.1.3 a set of Variance Persistent Objects are introduced.
Three types of Variance Persistent Objects are required:
= Stock Unit Variance Persistent Objects
= Declaration Variance Persistent Objects (for each Declaration Id in each Shared
Stock Unit)
= Office Variance Persistent Objects
Their structure is described in the following sections.
The Persistent Objects should be held in a Collection called ‘Variance_ww’ where ww
represents the week for which the Data is being held.
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.
I’ve not done any sizing to check to see if all this data can be held in a single Persistent Object
within the 2K Riposte limit. If it doesn’t fit we need to consider how to address that issue.
This can be resolved as part of HLD work.
Any declaration made the following day as part of the logon check will be held under
yesterday's composite attribute. Unlike the current ONCH Persistent Objects there is
no concept of carry forward declarations, so it will only be necessary to update a
single Persistent Object.
3.4.2.1 Stock Unit Variance Persistent Objects
The ObjectName of this Persistent Object will be “SS” (where SS is the Stock Unit
Name).
The following information needs to be held:
= Date / Time Declaration was made
= User making declaration
For a Shared Stock Unit, the two attributes above represent the User carrying out the “check
I for variances” function.
= Declaration Id
For an Unshared Stock Unit the Declaration Id that will enable the messages that
provide the latest Declaration to be identified.
Omitted for a Shared Stock Unit
= Declared Value
For a shared stock unit, this is the sum of all the individual Declared Values from
the individual Declaration Id Persistent Objects
For an unshared stock unit it is the actual declared value
= Variance
Te the difference between the Declared Value and the Derived value.
© 2004 Fujitsu Services Post Office Account Page 105 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
There is no need to hold the Derived value explicitly since this can be calculated from the
Declared Value and the Variance.
3.4.2.2 Declaration Variance Persistent Objects
The ObjectName of this Persistent Object will be “SS dd” (where SS is the Stock Unit
Name and dd is the Declaration Id).
The following information needs to be held:
= Date / Time Declaration was made
= User making declaration
= Declaration Id
The Declaration Id that will enable the messages that provide the latest Declaration
to be identified.
= Declared Value
3.4.2.3 Office Variance Persistent Objects
The ObjectName of this Persistent Object will be “Office”.
The following information needs to be held:
These all need to be calculated at EOD. See section 2.5.1.5
= Suspense
This is the nett movement into and out of the Suspense accounts (excluding Local
Suspense) during the day.
= Local Suspense
This is the nett movement into and out of the Local Suspense account during the
day.
= Adjustments
This is the nett amount Made Good (or excess cash removed) during the day.
= Transaction Corrections Processed
The number (not value) of Transaction Corrections processed during the day.
= Transaction Corrections Outstanding
The number (not value) of Transaction Corrections outstanding at the end of the
day.
= Stock Units not logged on Today
This is a list of all current SUs that have not been logged on today. This enables
information from previous days to be carried forward in the Variance reports.
© 2004 Fujitsu Services Post Office Account Page 106 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
3.4.3 Stock Unit Summary for Branch Trading Report
Following a Stock Unit Rollover, a Persistent Object needs
to be written containing
Summary Information from the Balance Report to support the Branch Trading
Statement. This will be held in a Persistent Object
in a Collection called
“SUSummary” with an ObjectName of “SS” (where SS is the Stock Unit Name).
The Data to be included is:
= Carried Forward Figures for:
Cash
Other MOP
Other Stamps
ForEx
oooad
Also need Brought Forward Figures, but presumably they can be obtained by picking the
Carried Forward figures up from the previous Trading Period Rollover.
= Total for Trading Period of:
Receipts value Total (excluding the following 6 items)
Remittance In (Cash) Total
Remittance In (Other Stamps) Total
Remittance In (ForEx) Total
Transfers In from Suspense
Transfers In from other SUs
Transfers In from Local Suspense
Payments value Total (excluding the following 6 items.
Remittances Out (Cash) Total
Remittance Out (Other Stamps) Total
Remittance Out (ForEx) Total
Transfers Out to Suspense
Transfers Out to other SUs
Transfers Out to Local Suspense
Transaction Corrections Accepted
oo00000000 00000
)
This isn’t currently part of the Balance Report, but is part of the BTS.
a 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] or RBBSHED}.
= Support of “Stock by Value”
o Tertiary Mappings
Can extend this further to get NRDS to provide the Primary and Terti
Assumption recorded in section 8.4
jary mappings.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc
Page 107 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= Include “Settlement Products” as part of normal Type A Ref Data.
Assumption recorded in section 8.4
Need to consider what knock on effects there are on their use with Product Modes etc.
= Inclusion of optional “loss price” on Product Reference Data for stock products.
= Roles to be prompted at logon when there are Outstanding TCs
= 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.
= Ref Data to support Identification of Transaction Data from the SAP ADS feed
= Various Calendars
a Branch Trading Periods and allocation of branches to their calendar
a HR SAP Periods
ao HR SAP Delivery dates
= Introduce Local Suspense Account Product
= = Introduce a number of new Modes
= RDS to provide mapping info as Type A Ref Data
= Soft Launch Reference Data, and in particular the ability to link a soft launch to a
given CAP.
HORIZON POL FS
Product >I article
[ Dummy
Quantity (0)
“Article POL FS
Mode” [2 I account (0)
[Settlement Type (0)
4 edger Indicator (O)
HORIZON -——Summarisation
Mode
Transaction Reference (O)
‘Movement Type (0)
Figure 6 — Ref Data Model for Articles
© 2004 Fujitsu Services Post Office Account Page 108 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
© 2004 Fujitsu Services Post Office Account Page 109 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Chapter 4 -
Environmental Constraints
4.1 GENERAL
This chapter is concerned with the Technical (as opposed to Application) Interfaces.
Information is also included about the operational schedule, SLAs and Volumes
associated with the interfaces, which although included in the AISs is more relevant to
this part of the document.
There are a number of aspects to this:
= Technical Interface from SAP ADS
= Technical Interface from NRDS
= Technical Interfaces to and from POL FS
= Technical Interface from EDS
= 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 are now considering dropping the requirement for TMS to process this.
POL to confirm.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Assumption recorded in section 8.4
There is one interface affected:
= SAP ADS Transactions and Summaries
This is a new file that will be transmitted from SAP ADS for processing by both POL
FS and by TMS, together with appropriate error files being returned if necessary.
© 2004 Fujitsu Services Post Office Account Page 110 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
This will use the existing technical interface defined in [POLTIS], which is based on
the use of FTMS for transmitting files to and from Huthwaite.
One issue with this interface is that the file is required by two separate systems within
the Fujitsu Data Centre:
= TMS
= POLFS
There are two approaches that can be taken:
= SAP ADS treats this as two completely separate interfaces and so provides two
copies of the file in the appropriate Transmission directories on the Remote FTMS
Server
m= SAP ADS places a single file on the Remote FTMS server, and we manage the
delivery of the file to both destinations
In either case, both systems will be validating the file independently, and so there will
potentially be two separate flows of error files being returned to SAP ADS.
My preferred approach is to have a single file delivered by SAP ADS which is then
delivered (via FTMS) to TMS. The file is then copied onto an appropriate share on
the POL FS Host. Error files are returned using FTMS to two separate directories on
the remote FTMS service (depending on whether they were originated from TMS or
from POL FS).
This issue is irrelevant if we don’t have to support this flow
In the absence of an AIS, the following assumptions are made:
Approx Daily File Size: Assumed to be small.
To be determined 19/3 (Nigel Stone/Philip Godden).
NS: Philip is working with the SAP ADS team to get the volumes of these client transactions (it
is likely to be small compared with rems — I will chase again on Monday).
= Proposed Operational Schedule
Currently the file is delivered overnight from SAP ADS to POL FS and is made
available by 04:00.
Delivery is 7 days per week 365 days per year.
= It is assumed that this is a point-to-point interface between SAP ADS and TMS
with no dependence on POL FS verification of content.
= It is assumed that there are no SLAs associated with this interface
= These files need to be audited on receipt
4.3 TECHNICAL INTERFACE FROM NRDS
The existing technical interface will remain unchanged.
© 2004 Fujitsu Services Post Office Account Page 111 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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
4.5 TECHNICAL INTERFACE FROM EDS
POL are now considering dropping this interface.
POL to confirm.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Assumption recorded in section 8.4
This is a new interface.
It is understood that an amount of manual processing is currently done within
Huthwaite to transfer this file to the appropriate place.
It is assumed that this file will be delivered to a new directory on the Remote FTMS
server at Huthwaite and will be picked up when required by the host system.
Since this file is due on the 3" day of each calendar month, then a Maestro schedule
will pick this file up on the 4" of each month and process it.
There is no rush to process it or sort out any errors since the data is not used until afier the
i.
In the absence of an AIS, the following assumptions are made:
= It is assumed that a single file will be received on the 3“ of each calendar month
and that this file will be made available on the FTMS Gateway at Huthwaite so that
Horizon can pick it up and process it.
= It is assumed that any error handling on the file will be manual (ie any failure in
processing the file will require human intervention and the process for loading the
“fixed” file can be repeated on another day).
= Approx Monthly File Size: Current spec states 3mb, but likely to be significantly
less
© 2004 Fujitsu Services Post Office Account Page 112 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= Proposed Operational Schedule
Not likely to be significant since if file arrives on 3" and details needed about 20"
we have plenty of time to process it.
If the file is not received, need an alert operations staff that the file has not been
delivered to invoke process to “get” file — assume this gives sufficient leeway in
processing
= There are no SLAs associated with this interface
= These files need to be audited on receipt
4.6 TECHNICAL INTERFACE TO HR SAP
This is a new interface.
It is assumed that we will can-either-send this file to the remote FTMS Server at
Huthwaite or-pass-itte-EDG.
In-the-absence-of an-AS, The following assumptions are made:
= Approx Monthly File Size
0.9mb for the first interface (company franchises) and 40mb 30mb for the main
interface
= Proposed Operational Schedule
Each month there will be two separate “pay runs”:
a At the beginning of the month to cover the “multiples”
a At the middle of the month to cover the bulk of the branches
Each “pay run” will take place over a weekend. The exact dates for these pay runs
and the range of Trading Days to be included in each pay run will be defined in a
Reference Data Calendar (see section 3.5). Data delivery should be by 21.30 on
the Friday preceding the pay run. Data must not be delivered more than a week
before hand. Therefore, to provide operational flexibility and opportunity to sort
out any unexpected problems it is proposed that the file is generated and sent on
the day before the required delivery date (ie the Thursday).
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. Fh ib SEA ful-deli
£1002 Lf jlable-dat: being deli d-b: 24:30. th } +-Erid:
= These files need to be audited on despatch
© 2004 Fujitsu Services Post Office Account Page 113 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
4.7 TECHNICAL INTERFACE TO MIS
There are two aspects to this interface:
= Delivery of Horizon Transactions to MIS
= Delivery of Cash Centre Transactions to MIS.
Working assumption is that we should do no further work on this interface until advised
otherwise by POL.
Both will involve the delivery of files, however they will be available at different times,
so two separate deliveries will be required each night.
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 these files to the remote FTMS Server at Huthwaite.
In the absence of an AIS, the following assumptions are made:
= Approx Daily File Size is assumed to be the same as for the current AIS.
= Proposed Operational Schedule
a Horizon Transactions
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)
ao SAP ADS Transactions
These will be passed as soon as they are available, however since these are not
received until 04:00, this will be much later than the Horizon Transactions.
= See section 5.5 for SLA requirements
= These files need to be audited on despatch
48 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.
© 2004 Fujitsu Services Post Office Account Page 114 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
In the absence of an AIS, the following assumptions are made:
= Approx Daily File Size: Assumed to be the same as for the current AIS.
= 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 115 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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 guide {SFYLE}
and any text displayed to the clerk must be agreed with Post Office Ltd.
5.4 VOLUMETRICS
Volumetrics will be described in the relevant AISs. [VOLS] will be updated to include
the volumes associated with the new interfaces.
A key change here is the increased data retention period at the counter and the
Correspondence Server and also the implications of handling Stock sales as two linked
transactions rather than one (see section 2.5.1.1.2)
5.5 SERVICE LEVEL OBJECTIVES
There are a number of aspects to SLAs:
m= New/ Changed SLAs
= SLAs being removed
© 2004 Fujitsu Services Post Office Account Page 116 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
= Unchanged SLAs
= Migration Implications
These are discussed in the following sections.
5.5.1 SLA Changes
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
= TMS -MIS (Horizon data) — by 03.00
= TMS ~—HRSAP 100% by 21.30 on Friday preceding weekend of pay run
= TMS (CTS file) —no SLA
Each of these statements is discussed separately in the following subsections.
NB there is no SLT on the receipt of the file from EDS.
5.5.1.1 LFS
Stated Requirement: remains unchanged.
Proposal: We accept this.
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. We’ve now received guidance from Post Office Ltd that we should
take this as being the SLA.
Proposal: That we accept an SLT similar to that for the current OPTIP delivery
namely:
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
LDT is the same as SLT and ARL is 98% of Transactions to be delivered to POL
FS by 03:00 on Day D.
© 2004 Fujitsu Services Post Office Account Page 117 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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 was based on the old contract. The new contract (December 2002) has changed
this as below.
However, 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.
Therefore the requirement as stated is self-contradictory.
Proposal: That we accept a similar contractual SLT to that for Planned Orders rather
than that quoted in the CD.
5.5.1.4 TMS — MIS (SAP ADS data)
[Note that the requirement for this interface may be dropped. I
Stated Requirement: by 05.00.
Proposal: That we accept an SLT as follows:
That the file containing Transactional Data for MIS is delivered to the Huthwaite
remote gateway by 07:00 each day, provided that the corresponding data has been
received from SAP ADS by 04:00 that day.
The SLT is achieved provided that we fail to meet this delivery no more than 4
times within a year. NB failures to meet this target on a Sunday or Bank Holiday
will not count towards this.
There should be no LDT or ARL.
[Alternatively we could support an OLA of 05:00 with no SLT or penalties.
5.5.1.5 TMS — MIS (Horizon data)
Stated Requirement: by 03.00.
Proposal: That we accept an SLT similar to that for the current OPTIP delivery
namely:
a 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
© 2004 Fujitsu Services Post Office Account Page 118 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
However in this case there is no LDT. The ARL is 98% of Transactions to be
delivered to MIS by 03:00 on Day D.
5.5.1.6 TMS — HR SAP
Stated Requirement: 100% by 21.30 on Friday preceding weekend of pay run.
Given that the Friday that we need to load this data is beyond Day J for any of the
relevant data, then I don’t see any problem with this.
Proposal: That we accept 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 only be included in this file provided it has been received by the
Monday prior to the Friday on which the data is to be delivered.
There should be no LDT but the ARL should be the same as the SLT.
5.5.1.7 TMS (CTS file)
Stated Requirement: no SLA.
Proposal: We accept this.
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)
= 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:
© 2004 Fujitsu Services Post Office Account Page 119 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Phase I Comment
c Since first day will include a special migration run may
not want to have an SLT on it.
Also may not want an SLT on both this and OpTIP so
could postpone until D
NB Counter won't process them until Point E.
Interface
TMS - POL-FS
Transaction Correction
TMS — MIS (SAP ADS data)
TMS — MIS (Horizon data)
TMS — HR SAP
LFS Weekly Stock on Hand
May not start for a month or two.
This interface is not currently used and so the SLT
should stop asap
OPTIP Feed
Network Banking Report NB 103
alo} >Iax]ojujo
%
m
Table 26 — 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 120 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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 SAP ADS to TMS (Cash Centre Transactions)
a Interface from TMS to MIS (Horizon and Cash Centre Transactions)
a Interface from EDS to TMS (Cash Account Enlivenments)
a Interface from TMS to HR SAP (Postmaster Remuneration Data)
a Interface from TMS to POL (DRS Reports and CTS Reports)
= Business Integration Test (BIT) to prove the business integration of the various
components of the system on a live-like infrastructure
= Release Test (RT)
© 2004 Fujitsu Services Post Office Account Page 121 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
This also includes Migration Testing
= 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
See os the checking of the revised ONCH files that are
transmitted and: Eni oH files.
6.3 ASPECTS TO BE TESTED
The following sub-sections are provided as input to the Test Strategy and are aligned
with the requirements of the Test Strategy.
Note that there will be a number of non-functional tests being carried out for the
Hosting of POL FS, however those are all outside the scope of this DP.
6.3.1 Business functionality
The Business Functionality is described in Chapter 2. All new Business Functionality
as described there will need to be explicitly tested.
Existing functionality needs to be regression tested to show that it hasn’t been changed
and that the service provided has not been degraded. [BT002]
6.3.2 Performance
The following needs to be considered for Performance Testing:
= Impact on overall Counter Performance, in particular the effect of the increase
from a 1 week CAP to a monthly Trading period and the corresponding increase in
message store sizes on the time for report production
= 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 122 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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 and-alse-the-implications-
The volume of data to be passed to MIS will be similar to that currently passed to
OPTIP.
6.3.4 Integrity
This cover auditing of the interfaces that are subject to DIT.
6.3.5 Resilience
There is no specific resilience testing required.
6.3.6 Recoverability (including backup and recovery, including disaster
recovery)
There is no specific recoverability testing required.
6.3.7 Networking
There is no specific network testing required.
6.3.8 Security
There is no specific security testing required.
6.3.9 Supportability
There is no specific supportability testing required.
6.3.10 Manageability (system management)
There is no specific manageability testing required.
6.3.11 Migration
Migration is described in section 2.6. The migration requirements are fairly complex
and particular attention needs paying to testing the various migration scenarios, and in
particular the ability to migrate from the final cash account to the first Branch Trading
period while still providing valid data. The soft launch of the various features will be
tested as part of this test phase.
6.4 ACCEPTANCE
[CDBT] specifies some acceptance criteria and the way in which they will be accepted
against each requirement. The focus of acceptance testing will be on ensuring that all
© 2004 Fujitsu Services Post Office Account Page 123 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
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.
However—they—are—expeeted_te—be Testing will demonstrate that the changes can
accommodated within the current headroom in the system.
© 2004 Fujitsu Services Post Office Account Page 124 of 145
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
Chapter 7 -
Mapping of Processes to Components
7.1
7.2
GENERAL
[CDBT] describes the requirement in terms of a number of processes.
describes systems components that are intended to support those processes.
This DP
The
following table shows the relationships between the Processes and Systems
components.
MAIN BUSINESS PROCESSES
Process Name SA Ref DP Section I Comment
Local Verification
Perform Transaction Checks — Periodic A4.1.4.1 1.2.4 Process out of scope
Perform Range Checks -Transaction A4112. I 24 No changes required
Validate Data Captured
Automated Reconciliation A4.1.1.3 24 No changes required
Produce Reports and Information
Produce Daily Summaries A4.1.2.1 24 No changes required
Produce Periodic Summaries A41.2.2 24 No changes required
Produce Sales Report to Assist A4.1.2.3 2.5.1.3.1
Remuneration Check
Verify Summaries A4424 [24 No changes required
REM-outand Despatch Redeemed A4125 I 24 No changes required
DocketsVouchers.
Produce Other Horizon Reports A4126 [24 No changes required
Other Data Capture
Input Non Accounting Data A4134 24 No changes required
Input Bulk Data A4.1.3.2 24 No changes required
Input Additional Client Data A4.1.3.3 24 No changes required
Discrepancy Management
Receive Automated Message A4.1.5.1 25.1.6.3
Handle Transaction Corrections A41.5.2 2.5.1.7
are Generated with Actual Cash
n
Compare Generated with Actual Cash A41.6.1 2.5.1.2.1
Held for Stock Unit
Create Variance Report ... Compare A4.1.6.2 2.5.1.2.2
Generated with Actual Cash Held Across
Branch
Make Good, Hold or Declare Any Cash A4.1.6.3 2.5.1.2.3
Variance
Stock Checking and Declaring
Rem In/Out Stock A4.1.7.1.1 I 2.5.1.1.2.1 No-Ghange?
Local Stock Check Stock Held for Stock I A4.1.7.1.2 I 2.5.1.2.4
Unit
Review Stock Held Across Branch A41.7.1.3 I 2.5.1.3.2
Produce Branch Accounts
Produce Trial Balance A41.7.2 2.5.1.4.1
Investigate Balance Discrepancies A4.1.7.3 24 No changes required
Make Good or Declare any Outstanding I A4.1.7.4 2.5.1.1.4
Losses
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 125 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
Produce Final Balance A41.7.5 2.5.1.4.1
Produce and Confirm Trading Statement_I A4.1.7.6 25.1.4.2
Roll Over Inactive Stock Units A41.7.7 24 No changes required
‘Stock Revaluation Stamps) A478 I 24
2.5.1.1.2.3
Summarise Transaction Data
Scan Transaction for Day A4.3.1 2.5.2.4
Accumulate Transactions for A4.3.2 25.2.8
Summarisation
Summarise Cash Centre Transactions A4.3.3 1.24 Assume that this is done by
SAP ADS
Deliver Data to External Systems none 25.2.3
25.2.6
2.5.2.7
2.5.2.10
2.5.2.11
Table 27 — Mapping of Business Processes to DP Sections
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 126 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
FUJ00090060
FUJ00090060
IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/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 28 contains the key.
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.
soo
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)
Table 28 —- Acceptance Mechanisms
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 127 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
8.2 COMPLIANCE MATRIX
BT001 Production of a balance report for a stock unit must be possible I Yes 25415 FST
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 this I Yes 6.3.1 FST
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 period. I Yes 26.1.3 SOF
BT006 I A-new-trial bal: rLwill-be produced the-contentand. FST I Tobe ved. since th ed by BTOO7
BT007 The content and format of trial and final balance reports will be Yes 25.141 FST
altered as specified in Appendix B of [CDBT]
BTO08 I Anew trading statement report will be produced, the content Yes 25.1.4.2 FST
and format of which will be as specified in Appendix B of [CDBT]
BT009 I Anew variances report will be produced, the content and format I Yes 2.5.1.2.2 FST I Also see BT030 which is basically the same
of which will be as specified in Section 20.2 in Appendix B of
[CDBT]
BT016 Functionality to allow entry of date range on the of Sales Report I Yes 2.5.1.3.1 FST
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 Auser with the appropriate role will be informed, at log on, that Yes 2516.3 FST I This has been rewritten as [BT024a]
there are outstanding Transaction Corrections awaiting
processing, whenever there are any.
© 2004 Fujitsu Services Post Office Account Page 128 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
1.0
30/04/2004
FUJ00090060
FUJ00090060
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 should be
able to print the details of the transaction correction at this point
in order to consider its implications before invoking it.
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
25.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.
Yes
251.21
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, but this may be
declined.
Yes
25.16
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
BT030
A new function will be made available to provide the variance
Same-as-BT009
BT032
Anew 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
25.1.2.3
25.1.2.2
25.1.4.1
25.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
251.24
FST
BT037
Report will be redefined without stock values as defined in
section 20.7 in Appendix B of [CDBT]
Yes
25.1.3.2
FST
© 2004 Fujitsu Services Post Office Account
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Page 129 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
1.0
30/04/2004
FUJ00090060
FUJ00090060
BT038
Anew check is to be introduced after producing the Trial
Balance (ie when the “rollover” button is pressed prior to
producing the Final Balance). This check will act as follows:
1. Ifitisn’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.
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 thisis 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.
Yes
25141
FST
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
251.333
FST
© 2004 Fujitsu Services Post Office Account
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Page 130 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
1.0
30/04/2004
FUJ00090060
FUJ00090060
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
251.14
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.
Yes
25.1.4.2
FST
BT043
The confirmation event will be made available to the data
warehouse 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
25142
2527
FST
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.
Yes
25.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
25.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
Yes
25.1.1.2
FST
BT049
The data retention period will be increased such that all trading
data is available within the Branch for a minimum of 42 days.
Yes
25.1.1.1
FST
BTO050
The data retention period will be increased such that all trading
data is available at the data centre for a minimum of 42 days.
Yes
25444
FST
BTO56
All stock items will be monitored throughout the Horizon system
by volume and not by value.
Yes
251.12
DR
FST.
BT058
The existing Weekly Stock Holding feed to SAP-ADS will be
removed
Yes
25.1.5.1
2522
POT
© 2004 Fujitsu Services Post Office Account
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Page 131 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
BT059 I There is a requirement to continue ensuring reconciliation Partly 16.1 DR I tneed-to-add-this-onein
between data flows which remain within the Fujitsu domain and 25.15 Note that the changes in Section 21, Appendix C, of
ensuring that control totals are applied to any extemal interface 25.155 [CDBT] are out of scope.
to allow detection of file corruption. All these reconciliations 25.25
should take advantage of the simplified process described in 25.26
Section 21, Appendix C, of [CDBT] 252.14
BTO60 I It is required that only reports that have previously been printed I Yes 25.1.3.8 FST I This has been rewritten as [BT060a]
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:
e 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
e 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)
e 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.
e _Noother reports require reprints.
BT062 The NB103 DRS reconciliation reports will be eliminated. Yes 2.5.2.5 DR
BT063 I The consolidated stock unit non-value stock report is no longer I Yes 25.1.3.9 DR
required and can be removed. The check to ensure that the 2514.2 FST
consolidated stock unit non-value stock report is produced as
part of end of period processing will also be removed.
BT065 Anew Transaction Corrections report will be produced, the Yes 251723 FST
content and format of which will be as specified in Section 20.3
in Appendix B of [CDBT]
© 2004 Fujitsu Services Post Office Account Page 132 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
Table 29 — Compliance Matrix
8.3 ADDITIONAL REQUIREMENT
A number of further requirements have been documented following the baselining of [CDBT]. These have been agreed with POL and are
recorded here.
BTO06 This requirement has now been removed.
BT024a I Auser with the appropriate role will be informed, at log on, that I Yes 25.16.3 FST I Last sentence added.
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.
BT030 This requirement has now been removed.
BT040a I Horizon should be changed such that only those Roles that can I Yes 251.14 FST I Roles clarified
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.
BTO51 Process for recovery situations when the Branch is nearing, or Yes 25.156 DR There is now a requirement on Fujitsu to support this
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 Page 133 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/004
1.0
30/04/2004
FUJ00090060
FUJ00090060
BT055
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
NN
@ or
is
oe
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.
BT057
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)
e Office Weekly Cash Flow(this is replaced by the
Variance report)
Cash Account Trial
« Cash Account Final
Yes
25.1.3.9 I FST
© 2004 Fujitsu Services Post Office Account
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Page 134 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/O04
1.0
30/04/2004
FUJ00090060
FUJ00090060
BT060a
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 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.
Yes
FST
Tes
BT102
Horizon will be changed such that the menu hierarchy reflects
changes made in the suspense products and allows users to
access the new products.
Yes
25.114
FST
BT103
The buttons that allow Error Notices to be cleared and
Vouchers to be processed will be removed, since in the future
this will be achieved using Transaction Corrections.
Yes
25.1.1.4
FST
BT104
The current ONCH button will access the common declare cash
functionality
Yes
251.241
FST
© 2004 Fujitsu Services Post Office Account
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Page 135 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
Ref.:
Version:
Date:
EA/DPR/O04
1.0
30/04/2004
FUJ00090060
FUJ00090060
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
25A2AA
FST
BT106
The buttons for making declarations and confirmation of non-
value stock items will be removed from the menu hierarchy.
Yes
25:1.215'
FST
BT107
Anew Counter Weekly Redeemed Savings Stamps mandatory
report is required with similar content to the Office Weekly
Redeemed Savings Stamps Summary.
Yes
25.1.3.4
FST
Reports defined in [CDBTCR1]
BT108
A daily feed of transaction details and summaries will be
No
25.23
FST
POT
Considered top be out of scope.
accepted from SAP-ADS for passing to POL-FS and the MIS
No AP Harvester is no longer being removed Need I
te-come-backto-this one.
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
25.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.
No
25.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
25.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
25.212
FST
© 2004 Fujitsu Services Post Office Account
File: pt5e02.doc
COMMERCIAL IN CONFIDENCE
Page 136 of 145
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
BT114 Migration at S80 will be complex and will require the full end to Yes 26.1 DR There is a requirement on Fujitsu to support this Post
end participation in determining the exact detail. Each migration Office Ltd requirement.
‘step must be specified in detail to ensure integrity of data and However there is no requirement on Fujitsu to make
processes throughout the migration period. any specific changes.
BT115 In circumstances where the Branch Trading Statement is not Yes 2.5.1.1.1.4 I FST
produced within the data retention period, the Horizon system 25.156
should attempt to retain the data for the entire period, subject to
hardware limitations and constraints.
BT116 The production of the reports below needs to change such that I Yes 2.5.1.3.10 I FST
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
Office Weekly Redeemed Savings Stamps Summary
Table 30 — Additional Requirements Compliance Matrix
© 2004 Fujitsu Services Post Office Account Page 137 of 145
COMMERCIAL IN CONFIDENCE
File: pt5e02.doc Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/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:
NRDS to provide Settlement Products and
Primary and Tertiary Mappings to Horizon via
Type A interface
Variance Report only produces data up to
and including “yesterday”
It is understood that there may also be a
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.
migration:
* Itis 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 C and E
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.
2.5.1.4.1.3 I Stock Remittances / Transfers will be
excluded from the SU Balance report since
they are zero value.
25.142 I We assume all the Branch Trading report is
printed in single normal font.
25.1.7.1 Note that there are potential requirements to There may be a future CR to bring such
handle adjustments to both value and volume I adjustments back into scope.
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.
25.2.3 Requirement to process SAP ADS
2.5.2.13.5 I Transactions is out of scope
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 been I points C and D.
investigated and corrected within Horizon.
NB In such cases, the underlying transactions
may already have been forwarded to MIS.
25.29 Requirement to process CAPO Transactions
3.2545 is out of scope
8.3:
BT111
26 The following assumptions are made about
© 2004 Fujitsu Services Post Office Account
Page 138 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Printed on 04/5/2004 3:30:00 by AC
FUJ00090060
FUJ00090060
Fujitsu Services IMPACT Release 3 Design Proposal Ref.: EA/DPR/004
Version: 1.0
COMMERCIAL IN CONFIDENCE Date: 30/04/2004
* — 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.
«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 E in the
migration process). Transactions
Corrections received earlier than Itis understood that a CR will be raised if
point E will stil be retained and can I @ Pilots to be operated, at which time
be processed after point E until 42 operating, infrastructure and test rig costs
days after they were delivered by will be assessed, i.e. costs for Pilot
POL FS. operation are not covered by this CT.
« It must be possible to support a pilot
“POL FS" for selected branches in
parallel with normal “S60” operation
of the live POL FS. Such a pilot can
then be stopped and a “proper”
migration supported. The term pilot
is taken to mean the provision of
data from selected branches to a
test instance of POL FS whilst
continuing to provide an operational
feed to CBDB. On completion of
the pilot, it is assumed that the data
in the POL FS test instance will be
discarded.
* The flow to POL FS will conform to
the S60 AIS until we first pass
through the S80 Data (i.e. Point C in
the migration process). Therefore
late data from branches that are still
er Hoare Mette fu It is understood that a CR is likely to be
include a Balancing account) raised to change this.
« There may be circumstances under
which S80 Transactions from
Horizon get passed to POL FS prior
to the Opening Balances.
« — ForEx will continue to be handled as
a single account within POL FS
* The CD has not identified the
requirement for any special reports
that need to be created to support
branch migration. In particular, the
opening Balance from the first “new”
Stock Unit Balance will not match
the Closing Balance of the last “old”
balance (though business
processes can be defined to allow
the two to be manually reconciled)
© 2004 Fujitsu Services Post Office Account Page 139 of 145
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc Printed on 04/5/2004 3:30:00 by AC
It is understood that a CR is likely to be
raised to change this.
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
* 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.
* 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 A in the migration process). It
is understood that there is no
requirement for no parallel running.
* Branch transactions conducted
following completion of the final
CAP and the commencement of the
next trading day (ie. at the switch
from CBDB to POL FS may be
excluded / double counted in the
summaries prepared for HR SAP is-
concerned.
There is no requirement to look at
old NB103's after CBDB switch off
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.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 140 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
The following assumptions are made about
the interface to HR SAP:
* — That data will be provided one or
two months in arrears as specified in
the summarisation Reference Data.
«Two separate interfaces will be
used:
© 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
ssummarisation and also the dates
by which files will be sent to HR
SAP.
* [tis 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.
suis assimed thal tis arcentabe t6 I
use The Reference Data currently
available at the Data Centre at the
time of the Summarisation Process
will be used for Branch Transaction
is-available-for summarisation. It is
assumed te-be-used for
summarisation-and 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)
« — Itis assumed that not all
transactions will be mapped to a
CTT, and so no checking / reporting
is required to detect transactions
that are not mapped to any CTT
number as part of the
summarisation process.
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.
© 2004 Fujitsu Services Post Office Account
COMMERCIAL IN CONFIDENCE
File: ptSe02.doc
Page 141 of 145
Printed on 04/5/2004 3:30:00 by AC
Fujitsu Services
IMPACT Release 3 Design Proposal
COMMERCIAL IN CONFIDENCE
FUJ00090060
FUJ00090060
Ref.: EA/DPR/004
Version: 1.0
Date: 30/04/2004
3.2.7 The following assumptions are made about Once the AIS has been baselined, the
the interface to MIS: impact on the solution design will be
* The CAP and BP fields will be assessed and any changes in the
retained, however the values willbe I assumed requirement will be addressed
null once the branch has moved by CR
from Cash Account to Trading
Period (point E 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 D6, D7 and D8 of
[MISAIS] define the additional data
required.
« — Ithas been agreed that the Quantity
field can be extended to
accommodate Bureau Quantities
rather than having to hold it as an
additional field.
* — Section D10.2 of [MISAIS] identifies
some additional events that are to
be passed through to MIS. This is
also defined in Table 19.
44 Itis assumed that all the interfaces are either
to POL FS (hosted by Fujitsu) or to a single
Gateway system in Huthwaite and so covered
by a single TIS ([POLTIS])
8.2: Will be removed as a duplicate
BTO06
8.2: Will be removed as a duplicate
BT030
82: Requirement BT059 is only partially covered
BT059 In particular the reference to Appendix C of
[CDBT] (which is out of scope) is excluded.
8.3 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: The Transaction Interface from SAPADS to
BT108 support the MIS data is out of scope
8.3: The data flow from EDS for CAPO
BT111 Enlivenments is out of scope
Table 31 — Assumpt
tions
© 2004 Fujitsu Services Post Office Account
File: ptSe02.doc
COMMERCIAL IN CONFIDENCE
Page 142 of 145
Printed on 04/5/2004 3:30:00 by AC