POL00038909
POL00038909
IMPACT Programme
S80 Migration Strategy
© Post Office™ 2004
IMPACT Programme
POL00038909
POL00038909
Dave Parnell
Gareth Jenkins
Philip Godden
Paul Butler
Ben Gildersleve
Ann Clarke
Mark Kirton
Karen Hillsden
Chris Allen
Phil Boardman
Sue Milne
Graham Shaw
‘Sue Harding
Torstein Godeseth
oe
Graeme Seedall
DRN; Desktop/RNMS
Version 0.7
Page 2 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
Table of Contents
CHAPTER 0 DOCUMENT CONTROL...
0.1 DOCUMENT INFORMATION.
0.2 DOCUMENT HISTORY,
0.3 CHANGE PROC!
Es
is
as
IS
ES
CHAPTER 1 - INTRODUCTION,
Ll SCOPE
SCOPE OF THE DOCUMENT ..
CHAPTER 2 - IMPACT R3 MIGRATIO:
2.1 INTRODUCTION ..
21.1 Key Principles...
MIGRATION COMPONEN
nm
io
2.2.1 Migration Timeline .
2.2.2 Reference Dat
2.2.3 Implement S80 on Horizon...
Preparation to Implement POL_F
POL-FS Implementation...
Handling Hangouts from POL-F'S Implementation...
Su
Switch on Brat
hes to Branch Trading .
Switch Remuneration Feed into HRSAP
Decommissioning Legacy System:
bo
a
MIGRATION ASSUMPTIONS - HORIZON
MIGRATION ASSUMPTIONS — BACK END ......
MIGRATION REQUIREMENTS FROM BRANCH TRADING CD .....
rm I
2.5.1 Mapping of Changes to Migration Phases.
CHAPTER 3 ~ DETAILED WORK ACTIVITIES.
3.1 GENERAL.
R
3.3 DETAILED ACTIVITIES...
CHAPTER 4 - APPENDI
INTRO!
4.2 MIGRATION OVERVIEW ...
4.3 FUJITSU PROPOSAL...
DRN; Desktop/RNMS Version 0.7 Page 3 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
DRN; Desktop/RNMS Version 0.7 Page 4 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
DRN; Desktop/RNMS Version 0.7 Page 5 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
Chapter 0 Document Control
0.1 DOCUMENT INFORMATION
Horizon Release No: $80
Document Title: ‘$80 Migration Strategy
Document Type: Migration Strategy
“Abstract: This document details the end fo end approach for functional and systems migration at S80. On
agreement the document will be passed to Business Change for implementation
Document Status: Draft
Originator & Department: David Pamell — Business Solutions
Contributors: POL, Fujitsu Services, PRISM Alliance
Post Office Distribution: Contributors
Supplier Distribution: Contributors
Table 1: Document Information
0.2 DOCUMENT HISTORY
04 31/5/04 I_Draft for discussion
02 2116104 Updated draft for discussion in Design Authority
Table 2: Document History
DRN; Desktop/RNMS Version 0.7 Page « of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
0.3 CHANGE PROCESS
Any changes to this issued version of this document will be made, controlled
and distributed by: -
Business Solutions
Post Office Ltd
80 Old Street
London
0.4 CHANGES IN THIS VERSION
04 None, First draft template
0.2 «Updated draft following group feedback
03 «Updated following DA teleconference
04 «Following comments from Graeme Seedall
05 ¢___ Following comments from Torstein Godeseth and Gareth Jenkins
06 ¢ __ Final version for internal review
O7 + Version submitted for formal review
Table 3: Changes in this Version
0.5 Key CONTACTS
Davie Business
Gareth Jenkins Fujitsu Applications TDA
Philip Godden PRISM Design
Table 4: Key Contacts
DRN; Desktop/RNMS Version 0.7 Page 7 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
0.6 Review DETAILS
Post Office Ltd:
Design Authority
Programme Manager
Technical Design Authority
Business Design Authority
Product Deployment
Business Change
Release Manager
Torstein Godeseth
Sue Harding
David Parnell, Chris Allen, Karen Hillsden_
Steve Grayston, Ben Gildersleve, Ann Clarke, Mark Kirton
Graeme Seedall
Fujitsu RASD Gareth Jenkins
Fujitsu Project Manager Bill Reynolds
PRISM - Philip Godden, Sue Milne - -
Optional Review/lssued for Information
POL
Table 5: Review Details
0.7 ASSOCIATED DOCUMENTS
Reference Versio! Date.
BTRMC&TM- 1.0 29/3/04 Branch Trading Reporting, Management and Control and
001 I Transaction Management Conceptual Design -
POL/IMPACTID 1.0 116/04 I POLtd Financial Systems Release 3 Conceptual Design
ES/R3029
EA/DPR/O04 4.0 I 30/4/04 IMPACT Release 3 Design Proposal
Table 6: Associated Documents
Unless a specific version is referred to above, reference should be made to the current approved
versions of the documents.
DRN; Desktop/RNMS
Version 0.7 Page 8 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
0.7.1 ABBREVIATIONS
Abbreviation I Definition
ADC Advanced Distribution Centre: Used as an abbreviation on the Horizon desktop for
Remittances to and from SAP ADS.
AIS ‘Application Interface Specification
APS Automated Payments Service. The subsystem that handles the acceptance of
automated payments on behalf of Post Office clients and passes details of those
payments directly to the clients.
ARL Additional Remedy Level
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
DWh 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
itv 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 Transactions
against the Cash Account Period they were carried out in
NBE Network Banking Engine
NRDS. New Reference Data System (a replacement from RDS)
OBCS Order Book Control Service
OLA Operational Level Agreement
ONCH ‘Overnight Cash Holding
OPTIP Operational TIP
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 Remittance
RMG Royal Mail Group
$80 System Release 80. A Horizon Release.
DRN; Desktop/RNMS Version 0.7 Page 9 of 37
© Post Office™ 2004
IMPACT Programme
POL00038909
POL00038909
Abbreviation
Definition
SAP
An industry standard accounting system
SAP ADS
SAP Advanced Distribution System
SLA
Service Level Agreement
SLT
Service Level Target
SU
Stock Unit
TC
Transaction Correction
TIP
Transactional Information Processing
Ts
Technical Interface Specification
TMS
Transaction Management System
TPS
Transaction Processing System
Other generic IT terms can be looked up at: http://www.whatis.com/
Table 7: Abbreviations/Definitions
DRN; Desktop/RNMS
Version 0.7
© Post Office™ 2004
Page 10 of 37
POL00038909
POL00038909
IMPACT Programme
DRN; Desktop/RNMS Version 0.7 Page 11 of 37
© Post Office™ 2004
IMPACT Programme
Chapter 1 -
Introduction
1.1
1.2
SCOPE
SCOPE OF THE DOCUMENT
The Conceptual Designs for Branch Trading and POL-FS at S80 and
the Fujitsu Design Proposal describe the functional components
required for the end to end solution. All three documents contain
some elements of migration thinking and assumptions
An initial workshop has been held with business and supplier
representatives to co-ordinate these activities and create a logical start
point for migration
The purpose of this document is to build on that workshop and develop
a migration strategy, the purpose of which is as follows:
e Agree the scope of migration
e Agree an approach and timeline for overall migration
which will act as a baseline against which to assess future
change
e Develop overall work activities which need to be done to
take the Migration Strategy to the next level of detail
e Agree ownership and roles in conducting the next level of
detail
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 12 of 37
IMPACT Programme
Chapter 2 -
Impact R3 Migration
POL00038909
POL00038909
2.1
2.2
INTRODUCTION
The migration approach is shown as a timeline that covers activities
around the end to end aspects of Impact at S80 with specific reference
to Horizon, POL-FS, nRDS and MI It focuses on process and
functional change and introduction with consequential systems
impacts. It does not show implementation activities such as when we
should be communicating with sub-postmasters — but could be adapted
for that purpose.
Section 2.2 depicts the major components of the timeline and their key
activities.
Key Principles
e Itis a key element of the strategy that the main phases shown under
“Migration Components’ below should be run with as little
parallelism as practical. Each phase contains sufficient complexity
to demand the full focus of Programme Management attention
whilst it is in progress.
e There will be no attempt to parallel run the new systems with the
current systems as this will be too labour intensive given that there
are fundamental differences in data entities
e All reference data will be set up in advance of implementing any
other component of S80
e Decommissioning of any legacy systems will happen at the end of
migration
MIGRATION COMPONENTS
Reference Data Set up
Data cleansing in advance - removing duplicates etc
Implement nRDS system into production
All reference data for POLFS
All clients, agents and other customers set up in reference data
All client products items set up
Chart of Accounts loaded
All reference data for Horizon
Mapping of products to POLFS codes
Mapping of CTTs for SAPHR.
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 13 of 37
POL00038909
POL00038909
IMPACT Programme
Adding in Type C data
Sales Prompts reference data
Track&Trace reference data
All reference data for MIS
Implement S80 on Horizon
Data Centre upgrade
Counter Software implementation - all aspects of S80 inc Prompts/T&T
Core functionality changes eg.Transaction retention, APS, - need business
check
Begin processing cash variances and new suspense methods
Preparation to implement POLFS
Load opening balances for start of year 04/05 from CBDB
Load period movements into POL-FS from CBDB
Run final cash account for branch - need to ensure compliance
Rationalise suspense values and outstanding errors centrally and by branch
POLFS implementation
Pass branch opening balances generated from Horizon
Open items from CBDB and other sources (legacy systems) loaded to
POL-FS
Move from errors to Transaction Corrections (TCs)
Stack up TCs or invoke interim manual process or
alternative method of de-risking the error situation
Receive interfaces from SAPADS, Hemel and loading of small systems data
and deliver
new interfaces out of POL-FS
Handling hangouts from POLFS implementation
Extract late movements that have come into CBDB - for loading to POL-FS —
up to cut off date
Confirming balances correctly set up
Switch on Enhanced MIS
Provide MI requirements from enhanced Data Warehouse - need to prove
live reports
Switch off OPTIP feed
Switch Outlets to Branch Trading
Prepare branches for proving their opening balances for passing to POL-FS
Four weeks with 4,000 branches per week - key element to be decided
Begin producing Branch Trading and other new reports and removing cash
account functions
Begin processing Transaction Corrections at branch
Merge value and non-value stock and handle stock by volume
Switch Remuneration feed into HRSAP
Begin summarising transactions from Horizon for HRSAP
Lottery data first
Decommission Legacy systems
Run legacy systems until access and archiving needs are met
DRN; Desktop/RNMS Version 0.7 Page 14 of 37
© Post Office™ 2004
IMPACT Programme
Switch off
2.2.1 Migration Timeline
The timeline is shown at Figure 1
It shows different aspects of migration and describes 3 migration
phases.
Phase A: This is the time from when all preparatory activities are
undertaken (including the setting up of Reference Data) and the
branch migrates to include support for the functionality described
in the Branch Trading CD until the final Cash Account that is to be
processed by CBDB. It is required to be a Wednesday (since Cash
Accounts change on a Wednesday) and it should also be the
Wednesday immediately prior to a Post Office Ltd Month End.
This phase is also used to load initial data into POL-FS including
opening CBDB balances for the financial year.
The assumption is that the updated nRDS system must also have
been made ready one month in advance of Horizon Data Centre
migration and be delivering interfaces to all recipient systems. As
nRDS must support systems through the migration it is required to
deliver pre-migration (i.e. S70) and post-migration (i.e. S80)
interfaces for those systems which change at this release.
Phase B: This is the period when POL FS will be providing the
central support for the Financial systems, however the branches
will still be operating most of the current processes
This phase will also be used to receive interfaces from SAPADS
and Hemel (STAMPS migrating to Yantra) into POL-FS and
continue loading other data into POL-FS eg. small systems data
and start sending new outbound interfaces
The new MIS feed from Horizon will be switched on and any MI
requirements dependent upon this can begin to be generated during
this phase.
Phase C: This is when the branches switch to using Branch Trading
statements rather than the current Cash Accounts.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 15 of 37
IMPACT Programme
For POL-FS this will be when the first interfaces to ES-FS are run
and CBDB error notices cease going into POL-FS
This phase will also include the switch to Horizon feeding SAPHR
for remuneration purposes and the decommissioning of legacy
systems
Other points from Figure I are:
= During Phase B, the first time that the Summarisation process
operates to pass data to POL FS, it is necessary to ensure that the
Opening Position is correctly passed across to POL FS. This
Opening Position should be based on the closing levels reported in
the Final Cash Account sent to CBDB. All transactions from the
point at which the Final cash account was taken must be identified
and their effect passed to POL FS even if they took place in earlier
Trading Days so that there are no Transactions not accounted for in
either CBDB or POL FS. The Opening Figures will be passed to
POL FS in a separate sub-file from normal Transactions with an
appropriate balancing figure.
This issue has a certain amount of complexity which is further
described in the paper attached at Appendix A — POL-FS
Migration.
During Phase B there will still be cash account information coming
from some branches (following non-polling) that will need to be
sent to CBDB. In order to support this, the existing interface to
OPTIP will need to be maintained during this period. Once all
Final Cash Accounts have been sent through, it is then possible to
switch off the feed to OPTIP and to replace it with an enhanced
data feed to MIS. The completion of final cash accounts will be
monitored from OpTIP data. This point is identified as Point 40.
The switch from phase B to phase C (ie Point 50) will not take
place at the same time in all branches. This will allow the new
branch processes to be piloted. A “soft launch” mechanism is
required to enable the rolling over of a Cash Account to result in
the migration of Stock Units and the branch into the new way of
working (i.e. moving from phase B to phase C).
CBDB will pass data to HR SAP covering the period up until the
final Cash Account (i.e. Point 30). This means that the first run of
data from TMS to HR SAP will probably be nearly 2 months after
the move from Point 30. An added complication is that Lottery data
is passed only one month in arrears. See section 2.2.9 for further
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 16 of 37
IMPACT Programme
POL00038909
POL00038909
Data for
Hoxizon
input
Hofizon Data
Cobre
Mibration
Extract Opening
(CBDB balances
as at 01/04/05
Data Cleansing ~ Errors on CBDB & fther Legacy system data
Extract Period 1
CBDB movement
into POL
Load c808
YIE & Period
movements
Point OS Point 10 Point 20 Point 25 Point 30 Point 40 Point 50 Point 60 Point 70
Load
adcttional
data into
NROS for SAP
POL-FS and I Firsf/Face From SAP it
@ mis NRGS to Switelito new CBDB From THS
s Pout OPTip asta
3
2 interfide We
% Load Gof
B Accounts
B Ino POL FS
3 kintertace
ToNRDS tego) systems
Phase A Phase B Phase sey ee
¢ i >
Final PROB
Pt30 +1 Day
pening
balances from
Horizon
First transaction
fle trom Horizor
First $80 ADS
transaction Ufa
FS
NSSC Opening
stock balances
Extract CBDB “open
items” for clients &
agents etc
Load into POL FS
‘Small systems
‘opening
balances into
POLFS:
(Fossacs)
Piao 2 Wee
Extract tinal
CBDB period
movement
Load into POL,
FS
(C808 Issued
Errors Mface to
POLFS.
First
Pol
Hong
irc Wace
FSto
ptso+1
Month
First POL FS
toESFS
Face
Pea0+8
Months
Stop CBOB
EINorices to
POL FS
Figure 1 — Migration Timeline
Migration will occur over a period of time. The key points are:
Reference Data Set Up ( by Point 05)
Implement $80 on Horizon
© Horizon Data Centre Migration (Point 10)
o Counter Software Upgrade (Point 20)
Switch Horizon and POL FS to use the Release 3 interface (Point
25)
Preparation to Implement POL-FS
DRN; Desktop/RNMS
Version 0.7
Page 17 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
o Running the Final Counter Cash Account for CBDB
(Point 30)
= POL-FS Implementation
o Horizon opening balances in POL-FS (Point 30 + 1 day)
would be the ideal theoretical position. In practice these
will trickle through at any time between point 25 and
Point 40 depending on when a branch rolls its cash
account and non-polling issues.
= Handling Hangouts from POL-FS Implementation
o Final CBDB movement period (Point 30 + 2 weeks)
= Switch on Enhanced MIS (Point 40)
= Switch Branches to Branch Trading (Point 50). This will be spread
out over a significant period.
= Switch Remuneration Feed into HRSAP (Point 60). In practice this
will occur before all branches have been switched to Branch
Trading (point 50)
= Decommissioning Legacy Systems (Point 70)
These are described in more detail in Section 2.2.2
The following gives some indication of the actual durations of the
various activities.
Point 05 will be circa 1/4/05 as Point 10 is currently planned for the
weekend of 29/4/05
Then expect to allow about two weeks for Ref Data distribution
followed by the first trial counter — model office - (Calthorpe) at Point
20 (16/5/05) followed by a software pilot of Counters for two weeks
(to complete 3/6/05) followed by the full rollout of Counter software
which normally takes about 4 to 6 weeks. (potentially 15/7/05)
Evaluation can take place throughout the trial/pilot and beyond but by
3/6 the business should be sufficiently informed to know whether to
authorise software rollout to commence on 6/6
Point 25 must be after all counter have migrated (ie achieved Point 20)
and it must also be before any branch has rolled the "Point 30 Cash
Account". And should have a safety net of two weeks (15/7/05)
Since Point 30 must be a POL month end June is too early and so end
July (27/7/05) is perhaps more likely and certainly lower risk.
Point 40 will be about 10 days later (6/8/05) , thus allowing the first
Branch Trading Pilot branches to achieve Point 50 two weeks after
Point 30 (10/8/05) .
It is proposed that for the Pilot that the pilot branches will be the first
part of the initial implementation group (Group A) and they will
perform their last cash account in week 1 (Point 30 + 1 week) followed
DRN; Desktop/RNMS Version 0.7 Page 18 of 37
© Post Office™ 2004
IMPACT Programme
by their first Branch Trading Statement the following week, (Point 30
+ 2 weeks) They will then not perform another Branch Trading
Statement until the next period end (4 weeks later — Point 30 + 6
weeks) along with the rest of Group A. who start with a short 1 week
trading period followed by a 4/5 week period. Assuming the business
can support 4 tranches of approximately 4000 branches, then by Point
30 + 10 weeks all branches will have rolled over their first Trading
Period (19/10/05). It will clearly take longer if we cannot support
4000 branches moving each week.
Note: POL month end = Wednesday
POL00038909
POL00038909
2.2.2 Reference Data Set Up
The first activity is to undertake data cleansing in advance of inputting
new items of data. This means ensuring that duplicate items are
removed and standard naming conventions are applied so that the same
instance of an entity is not described in more than one way.
The second activity to undertake is to make sure all the necessary items
of reference data have been set up in nRDS and that the relevant data
has been interfaced to its receiving systems notably POL-FS, Horizon
and MIS.
This activity should not be underestimated as there are new and
complex data items and relationships which need to be in full working
order before any of the other components can take place and it is
assumed that full testing, including Live Reference Data Proving, will
have taken place as part of the testing approach. Specific, but not
exhaustive, relationships are:
e Setting up all clients, agents and other customers
e Setting up all new stock items
«© Mapping products to POL-FS codes
¢ Setting up the hierarchy for Transaction Corrections
© Mapping of CTTs for summarising the data for SAPHR
¢ Setting up the necessary relationships for Type C reference data
which is going to be part of nRDS
2.2.3 Implement S80 on Horizon
There are two major activities here.
Firstly, Data Centre Migration 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.
DRN; Desktop/RNMS Version 0.7 Page 19 of 37
© Post Office™ 2004
2.2.4
IMPACT Programme
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.
Secondly, Counter Software Upgrade will follow the normal pattern
for a Software rollout and include some initial trial Branches to ensure
that the upgrade 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 will be activated at a
later time.
Preparation to Implement POL_FS
The following activities are required from a hardware and software
implementation perspective:
Hardware:
¢ Complete build of infrastructure for the SAP R3 application in
addition to the S60 production system.
« Complete build of the infrastructure for the Middleware
application.
e Ensure that both production systems have full connectivity
from Fujitsu domain to the Horizon domain. This includes
connection to the user presentation layer, print servers, and all
interface connections as necessary.
Software:
e Transport all tested configuration and development objects
from the Development system to the Production system.
e Migrate the Middleware development from the development or
test middleware system to the production system
In POL-FS activities must be undertaken to load the start of the
financial year opening balances from CBDB into POL-FS. This is in
addition to any identified previous year closing balances and
movements that need to be put into POL-FS to create the correct
starting position.
There is also an activity to address the position of the suspense
accounts both centrally and locally particularly as the current
“unknown items” option will no longer be available to the branch. An
exercise to cleanse suspense accounts in advance of implementing
POL-FS is envisaged.
It is a requirement of POL FS 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. 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
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 20 of 37
2.2.5
IMPACT Programme
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.
Branches need to generate this Cash Account on the selected
Wednesday. This will ensure that we have a clean cutover. Processes
must be put in place to ensure compliance and the receipt of cash
accounts will be monitored through OpTIP. It is almost certain,
however, that there will be a small number of branches which cannot
conform to this through no fault of their own. A process for dealing
with these exceptions needs to be prepared.
[DN from GJ: As far as Horizon is concerned we will manage that cut-
over whenever the Cash Account is rolled over and it need not be on
that Wednesday. We need to define an earliest and latest time for this
so as to ensure that we don’t miss the data.]
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 from the Impact Release 1 format to the
new Impact Release 3 format a few days prior to this rather than at
point 10.
This is now referred Point 25. This needs to be defined in relation to
Point 30, such that any branches that rollover the Point 30 cash account
prior to Point 25 will not migrate correctly. It is probable that a week
is sufficient, but it depends how well the branches are controlled in
terms of conformance to correct CAP weeks.
POL-FS Implementation
A process will be defined to ensure the accuracy of Horizon opening
balances. This process will operate at the branches and will utilise
outputs/reports from pre-S80 Horizon so that an accurate position can
be reached. These balances will then be passed separately to POL-FS
for population of the ledgers.
It should be recognised that the opening figures for all stock items
(other than those included in S60) are being taken from the Cash
Account in addition to the opening figures from the Suspense and
Discrepancy tables in the Cash Account produced at Point 30
The error process from CBDB will be ceased and the new Transaction
Correction process will commence. However, given that this activity
is prior to branches switching to Branch Trading then there is an
interim period to be addressed. This will either mean a) stacking up
the Transaction Corrections for dealing with later b) invoking some
form of manual intervention or c) invoking an alternative process
which de-risks the strategy Note that there is no way to support this in
the branch. Business requirements for this need to be addressed as
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 21 of 37
2.2.6
2.2.7
2.2.8
IMPACT Programme
this may result in a Change request for the storage of Transaction
Correction data centrally beyond the currently proposed 42 day limit
and an Error Migration Approach needs to be defined.
Open items from a number of sources will need to be loaded into POL-
FS (either by a data load routine or by keying directly). In either
instance there needs to be a reconciliation exercise to ensure integrity
of the data.
Interfaces from SAPADS, Yantra and other legacy systems (eg.
FOSACS) will also need to be generated. These will be a mixture of
start up figures and ongoing interfaces with regular transaction data.
Handling Hangouts from POL-FS Implementation
This activity will extract any late movements that have come into
CBDB, for a variety of reasons, so that they may be loaded into POL-
FS. This could be as a result of late activity in branches or via client
management. There will be a final cut off point for this activity.
Switch on Enhanced 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.
The upgraded MIS system at $80 will contain updated data feeds from
Horizon in addition to new data feeds from a number of other sources.
All of these data feeds will be available at this point and all MIS
requirements from the data warehouse can be met at this point. It may
be possible to meet some MIS requirements earlier than this point
dependent upon the nature of the data feeds. Analysis will determine
what is possible.
Switch on Branches to Branch Trading
At some later time the branches need to switch to using the new
Branch Trading processes. Different branches can do this at different
times, thus allowing pilots to be supported on different processes.
However the changes in process at any branch need to occur
immediately after rolling over into a new Cash Account Period. The
system change occurs as part of rolling from a Cash Account Period
into a Branch Trading Period.
The current assumption is that this will occur in blocks of offices over
a four week period with an estimated 4,000 offices per week being
switched over. It must be noted, however, that this assumption needs
ratification once further work, to assess the support needed by the
Branches during cutover, amongst other things, is assessed.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 22 of 37
2.2.9
2.2.10
2.3
IMPACT Programme
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.
Switching into the Branch Trading mode will allow branches to
process Transaction Corrections — including any which may have been
generated since the cut over from CBDB to POL-FS
In order to focus attention and minimise problems it is proposed that
the merging of value and non-value stock takes place at some time
after all the branches have moved over to Branch Trading.
Switch Remuneration Feed into HRSAP
There will be a final run of remuneration feeds from CBDB after the
final branch accounts have been run and branches have moved to
Branch Trading. This will be at least a month after Point 30. The
switch to feeding data from TMS will be made for the following month
— therefore being two months after point 30.
There is an added complication. On the main Pivot feed, Lottery data
is passed only one month in arrears, so the last set of data form CBDB
will exclude such transactions (since they will not have been passed to
CBDB). However since Horizon will have been processing these
transactions it will be able to generate a file containing just the lottery
transactions in that month and this can be manually loaded into HR
SAP, thus ensuring correct remuneration.
Decommissioning Legacy Systems
At some point beyond the completion of migration to S80 legacy
systems will be decommissioned. The precise timing of this needs to
take into account any access to data on these legacy systems. Analysis
needs to be undertaken to determine these access and archiving
requirements but the underlying principle is that this is the last activity
in migration.
MIGRATION ASSUMPTIONS - HORIZON
The following assumptions are made about migration:
a ./ DN from GJ:. The counter will now support some Stock Units
to be operating post Point 30 and others before Point 30
(depending on the state of the individual Stock Unit), and similarly
at Point 50. I
= 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 (if required —
dealing with error notices will be determined as part of the Error
Migration Approach); and introduction of new Housekeeping
functions to replace vouchers.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 23 of 37
IMPACT Programme
Restricting the Housekeeping menus as specified in requirement
will happen at a specified date prior to the final CAP for CBDB
being rolled over at all branches (ie it will not be co-ordinated to a
CAP rollover). In particular this change will take place at the same
time in all branches and will not be available for piloting.
Transactions Corrections will not be able to be processed until the
branch is operating in Branch Trading Mode (ie point 50 in the
migration process). Transactions Corrections received earlier than
point 50 will be retained and can be processed after point 50 until
42 days after they were delivered by POL FS — unless a change
request is invoked.
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 25 in the migration
process). Therefore late data from branches that are still
operating at S60 will then pass the data through the S80
interface (but include a Balancing account) There may be
circumstances under which S80 Transactions from Horizon get
passed to POL FS prior to the Opening Balances.
ForEx will NOT continue to be handled as a single account within
POL FS. To enable proper inventory management of ForEx
separate currency items will need to be created and a change
request (PSOCR00220) has been raised to cater for this.
The CD has not identified the requirement for any special reports
that need to be created to support branch migration. In particular,
the opening Balance from the first “new” Stock Unit Balance will
not match the Closing Balance of the last “old” balance (though
business processes can be defined to allow the two to be manually
reconciled)
Pending completion of POL requirement analysis to define specific
requirements, it has not been possible to address any changes that
may be necessary to handle migration non-value stock products to
value stock products.
The feed to OPTIP will be switched to MIS at a given point after
POL FS is operational (expected to be approximately 10 days
following point 30 in the migration process — i.e. point 40). It is
understood that there is no requirement for parallel running.
[DN from GJ: We will ensure that the same boundaries are used
for Transaction summarisation to HR SAP as for POL FS.]
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 24 of 37
IMPACT Programme
There is no requirement to look at old NB103s — reports which
reconcile banking transactions to the cash account - after CBDB
switch off
2.4 MIGRATION ASSUMPTIONS — BACK END
Balances for Cash and near cash existing by Branch/cash centre
from S60 will not be reloaded at S80
Data cleansing will take place between now and April 2005 - by
the business. This data cleansing can cover anything from
reference data through to errors and suspense.
NRDS will be ready and have all reference data set up before
point 10
All reference data will set up in POL FS by Point 10
POL FS will receive and load opening financial balances for
beginning of year 05/06 from CBDB
POL FS will receive and load monthly financial movements on
CBDB for all financial periods in 05/06 prior to go live.
POL FS will receive and load "open items” due for payment or
receipt for clients & "live" agents from CBDB as at the end of the
final period on CBDB
Open items for former sub postmasters will be received from
FOSACS
Open items for other customers/debtors; vendor/creditors will be
received from other legacy systems to be defined.
The $80 Horizon interface will pass opening balances for Foreign
exchange on hand (by currency), stocks (valued) — volume only,
and suspense items (to be defined) as at the final accounting CAP
on Horizon, to POL FS. These opening balances will be identified
as at the date of the final accounting CAP, no matter when that
CAP is actually rolled.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 25 of 37
2.5
POL00038909
POL00038909
IMPACT Programme
a All financial opening balances will be loaded by Point 30 + 3
weeks (1
week before first financial period end on POL FS).
MIGRATION REQUIREMENTS FROM BRANCH TRADING
cD
Table 8 is copied from the Branch Trading CD and identifies the
requirements for changing the various business processed described in
the Branch Trading CD.
‘4.1.1.1 Perform Transaction Checks
~Periodic. Change: Production of new
reports and exception reports.
Changes implemented in MIS systems no
change at front end. Non-Functional and
Migration requirements to be considered
under the MI part of the Impact
programme.
A4.1.1.3 Automated Reconciliation.
Change: Move from APS/TPS to TMS.
Requirements to be defined as part of
migration work stream
A4.1.2.3 Produce Sales Report to
Assist Remuneration Check. Change:
Different sales report over different
periods.
Could be implemented at any time, would
be beneficial to be implemented in period
A. No need for soft launch.
A4.1.5.1 Receive Automated
Message. Change: Reminders on
Receipt/Delivery of Transaction
Corrections.
Needs to be implemented from the
beginning of phase B, can be
implemented, but not used, from
commencement of implementation. Need
to consider mapping Transaction
Corrections transactions to the cash
account during phase B.
A4.1.5.2 Handle Transaction
Correction. Change: Management of
Transaction Corrections,
Implementation of corrective actions,
etc.
Needs to be implemented from the
beginning of phase B, can be
implemented, but not used, from
commencement of implementation. Need
to consider mapping Transaction
Corrections transactions to the cash
account for during phase B.
Although branches may still be doing cash
accounts, the moment that CBDB is
ceased no cash account errors should be
brought to account and the facility to do
this should be removed. Manual processes
will be set up to deal with this in POL-FS.
Error Notices buttons to be removed at
‘switch over from phase A to phase B, (to
be revisited as part of the Error Migration
Approach) after which process is for
outstanding Error Notices to be converted
to Transaction Corrections.
‘4.1.6.1 Compare Generated with
Actual Cash Held for Stock Unit.
Change: Removal of ONCH
declarations functionality, reminders
on cash declarations.
During phase A, implemented at
implementation of S80. Day 1 phase A.
‘Ad.1.6.2 Create Variance Report
Change: Implementation of new report
— format to be defined, complexity
may affect usability of report produced
may need to re-format to simplify.
During phase A, implemented at
implementation of S80. Day 1 phase A.
DRN; Desktop/RNMS
Version 0.7
© Post Office™ 2004
Page 26 of 37
2.5.1
POL00038909
POL00038909
IMPACT Programme
ich/Requirements
"Change:
A4.1.7.1 Make Good any Outstanding
Variances. Change: Changes to
Suspense Account products.
Prior to going live with S80 there will be
known and unknown values in Suspense.
The known (or legitimate) items should be
mapped across to the new suspense
products so that they can appear in the
new account. For the unknown suspense
items, these should not be taken across,
but we would like the values to be mapped
conto the Cash variance Report so that they
appear as shortages/surplus and will then
be dealt with by the new processes. These
shortages/surpluses should be identified
as a result of this migration mapping.
At commencement of phase C. Need to
clear any values out of the discrepancy
product. Need to consider what to, how
and when (during the first balance of
phase C)?
‘Ad.4.7.2 Stock Checking. Change:
Removal of value information on Stock
reports
Implemented at commencement of phase
c.
Transfer of Non-value stock to be
controlled stock, implemented during
phase C. Need to consider how to obtain
opening balances. Back end controls for
process manual retums need to continue
until this is completed.
A4.1.7.3 Produce Trial Balance.
Change: Change in reports to exclude
stock in balance.
implemented at commencement of phase
C. Must be able to correlate brought
forward figure to carried forward items on
old style reports.
‘A4.1.7.4 investigate Balance
Discrepancies. Change: No change.
A4.1.7.5 Produce Final Balance.
Change: Functionality to control not
being able to complete Trading
Statement with variances.
As for trial balance
A4.1.7.6 Produce and Confirm Trading
Statement. Change: New Report,
change in electronic confirmation
functionality
Implemented at commencement of phase
C. Must be able to correlate brought
forward figure to carried forward items on
old style reports.
Table 8 — Migration Requirements from Branch Trading CD
Mapping of Changes to Migration Phases
Table 9 shows at which phase of migration each aspect of the
functional changes described in the Branch Trading CD will change.
The migration points are described in section 2.2.1
Extending Transaction Retention
10/20
rather than by Value
Stock to be handled by Volume 50
Merging of Value and Non-Value Post 50 See section 2.5.2.3
Stock
Changes to Suspense Products 30 and 50 I 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.
DRN; Desktop/RNMS Version 0.7 Page 27 of 37
© Post Office™ 2004
IMPACT Programme
POL00038909
POL00038909
© Post Office™ 2004
ih
Settlement Transactions 10-25 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 10 and 30 and
shouldn't require the counter to be
at S80.
Changes to Cash Declarations 20
Reporting of Cash Variances 20
Processing of Cash Variances 20
Stock Declarations and Variances I 50
Non-Value Stock Declarations 50 This is removing functionality
Remuneration Reporting 20
Office Snapshot Report 50
Suspense Account Report 20
Counter Weekly Redeemed 50
Savings Stamps Report
APS Transactions Report 20
Event Log 20 Though some new events will not
be generated until point 50
Other reports affected by changes I 50
to Stock Processing
Reprints of Reports 50
Reports proposed to be removed 50 Some may go at 20
Weekly Reports 50 May be able to do it at 20
Changes to Rollover processing _I 50
Branch Trading Reports 50
Remove Extended CAPs 20
Removal of LFS Weekly Stock 10-30 This is a ref data change and so
Reporting functions needs to happen at a fixed time.
It should be OK to do this at any
time between 10 and 30 and
shouldn't require the counter to be
at S80.
POL FS Summarisation at Post 40 This functionality can be removed
Counter by End-Dating the Reference data
that invokes this function through
CAS at any time between points
40 and 50
Maintenance of Office Variances 20
Persistent Object
LFS EOD functionality changes to I 20
handle changes in Cash
Declarations
Simplification of EPOSS Post 40 This functionality can be removed
Reconciliation 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
40 and 50
Protection against lost data 20
Logon Checks: ONCH run for 20
“yesterday”
Logon Checks: Stock Unit in 50
correct Trading Period
Logon Checks: Outstanding 50
Transaction Corrections
Process Transaction Correction 50 This has to occur at point 50
otherwise it will be expensive to
make the changes to support TCs.
ona CAP report
DRN; Desktop/RNMS Version 0.7 Page 2s of 37
POL00038909
POL00038909
IMPACT Programme
porting
Corrections
RDMC 10
LFS 10 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 N/A
TPS Harvesting 10
DRS Host 40 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 40
Transaction Summarisation 10/25
Accept CAPO Data N/A
Generate HR SAP Info 10
Generate POL FS Info 25
Transaction Correction 10
POA Data Warehouse 10
TPS Host 10 and 40 I The main changes take place at
point 10, however some of the
changes to the constraints on the
Harvester Interface tables should
be left until point 40.
Table 9 — Migration of Functions
DRN; Desktop/RNMS Version 0.7 Page 29 of 37
© Post Office™ 2004
IMPACT Programme
Chapter 3 — Detailed Work Activities
POL00038909
POL00038909
3.1 GENERAL
The approach to migration is laid out in Chapter 2 of this document.
This will now act as the baseline approach against which detailed
migration analysis needs to be undertaken. The detailed analysis may
drive changes to the approach through the normal change request
mechanism.
3.2 ROLES AND RESPONSIBILITIES
The responsibility for leading the detailed migration analysis lies with
the Impact Business Change team — primarily Steve Grayston
(Business Change Manager), Ann Clark (Back End), Ben Gildersleve
(Counter) and Mark Kirton (Implementation) The Design Authority
will be the guardians of the strategy and ensure that any proposed
changes resulting from the detailed analysis are assessed against the
strategy.
Key members of and contributors to the migration forum are:
SM _— - Sue Milne
KH _ - Karen Hillsden
CA — - Chris Allen
DP _ - David Parnell
PBo- - Phil Boardman
BG _ - Ben Gildersleve
PBu_ - Paul Butler
GJ - Gareth Jenkins
MK — - Mark Kirton
PG _ - Philip Godden
AH - Alan Holbrook
NS __ - Nigel Stone
AW_ - Alvin West
CR - Chris Ridler
NF _ - Neil Fagan
AG __ - Al Garrett
TW _ - Iwan Williams
Other members and contributors will be required as the analysis
gathers pace.
DRN; Desktop/RNMS Version 0.7 Page 30 of 37
© Post Office™ 2004
IMPACT Programme
3.3 DETAILED ACTIVITIES
Detailed activities have been moved to a separately maintained
document
S80_Migration_Actions_vn.n.doc
This allows the actions to be progressed more effectively.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 31 of 37
POL00038909
POL00038909
IMPACT Programme
DRN; Desktop/RNMS Version 0.7 Page 32 of 37
© Post Office™ 2004
POL00038909
POL00038909
IMPACT Programme
Chapter 4 — Appendix A
POL FS Migration
Ref: _c:\gij\winword\documents\gij documents\notes\polfs_mig.doc
Author: Gareth I Jenkins
Date: 02/09/2004 11:18:00
41 INTRODUCTION
The purpose of this note is to consider in more detail the migration of
the Horizon to POL FS interface at Impact R3.
It is produced following some detailed discussions on migration within
the Fujitsu team and is intended to record the conclusions of that
discussion and to highlight the implications to the Prism POL FS
designers to ensure that it fits in with their thinking.
After a brief conversation with Philip Godden of Prism, it is clear that
some of the aspects considered here have not yet been considered by
Prism, and so this note enables these issues to be brought out and
discussed further if necessary.
This is a working note and any conclusions will be fed back into either
the main Fujitsu Design documents or the Horizon to POL FS AIS as
appropriate.
This has now been updated following further discussions with Philip
Godden, Karen Hillsden and Chris Allen on 20/7/04. In particular it
introduces some further changes to the interface from Horizon to POL
FS and as such will require a CR to be raised.
4.2 MIGRATION OVERVIEW
DRN; Desktop/RNMS Version 0.7 Page 33 of 37
© Post Office™ 2004
IMPACT Programme
Figure 1 shows the overall Migration timeline and is based on a similar
figure in the POL document /mpact Programme Migration Strategy.
The main difference is the inclusion of the additional Point 25, which
indicates the time at which Horizon switches from the AIS for S60 to
the AIS for S80 when feeding POL FS.
Point 10 Point 20 Point 25 Point30 Point 40 Point 50
POLES:
cEDB
From CBDB/OPTip Pros
POL00038909
POL00038909
Figure 2 — Migration Timeline
This paper is primarily looking at what happens at Points 25 and 30
and in general the additional processes needed during the POL FS
migration period which can be defined as the time between Points 25
and 40. The actual Cash Account Period that ends at Point 30 will be
referred to as CAP nn.
Key requirements for the data being passed to POL FS:
= All data currently being passed to POL FS relating to cash — near
cash at S60 needs to continue being passed as branches move from
CAP nn to CAP nn+1.
Such data does, however need to be kept separate for that which is
transacted in CAP nn (or earlier) and that which is for CAP nn+1 (or later).
It is now proposed that the data for CAP nn (or earlier) is included in a
separate set of subfiles with a new record identifier for the subfile header
(eg BLCR3). Note that it is only data in such subfiles that will require a
balancing transaction.
This will require a change to the Horizon to POL FS AIS and also a CR to be
raised since this is work that was not included in the original costings.
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 34 of 37
IMPACT Programme
For simplicity these subfiles containing BLCR3 data might be generated in
separate files from “normal” S80 steady state data, but if this is the case,
these files will still be included in the EOT file.
Although POL FS needs to post such transactions into different
Accounting Periods, it is assumed that this can be done based on the
subfile header and that there is no requirement for Horizon to “falsify” the
Trading Dates to achieve the correct posting. In particular there could be a
subfile of each type (ie BLCR1, BLCR2 and BLCR3) on any given day,
however there will never be more than one subfile of any type for any
branch for any trading day.
Again this needs clarifying in the AIS and Philip needs to confirm that this is
OK.
Any such data for CAP nn (or earlier) will require an appropriate
“Balancing Transaction” to account 999999 such that the sub-file
sent to POL FS balances to zero.
Need to define how this “Balancing account” is to be defined. Will it be
defined as a “normal” Product with appropriate mappings or will be have a
hardcoded “dummy article” such as 999999 to handle this?
Note that it is only subfiles of type BLCR2 and BLCR3 that will contain
balancing transactions. Subfiles of type BLCR1 will always “self balance”
(and Horizon will check this).
Once a branch is fully operating at CAP nn+1, then the transactions
should be completely balanced without any Balancing Transaction.
It cannot be assumed that the move from CAP nn to CAP nn+1 will
occur at the end of a Trading Day (ie it is possible for the data for a
single trading day to have a mixture of transactions for CAP nn and
CAP nn+1).
It cannot be assumed that all Stock Units in a Branch will move
from CAP nn to CAP nn+1 at the same time. For example the
following scenario is valid:
co SU AA tolls into CAP nn+1 at 16:00 on Tuesday (since the
owner of the SU doesn’t normally work on Wednesday)
a SU AA is then used at 17:00 on Tuesday (due to a late rush at
closing time)
o SU BB is rolled over at 16:00 on Wednesday (as normal)
o SU CC is rolled over at 09:30 on Thursday morning (after
entering out of hours transactions — eg for lottery)
o Cash Account is produced at 10:00 on Thursday morning (as
normal)
In this case there will be transactions for both CAP nn and CAP nn+1 on
Tuesday, Wednesday and Thursday and the Cash Account will not be
available for processing until Thursday evening.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 35 of 37
IMPACT Programme
Opening Figures need to be kept separate from normal transactions
and will be passed over in a sub-file with a different Header type
(ie BLCR2 as defined in the AIS)
No opening figures are needed for Cash and Cheques. Since these
will have been maintained in POL FS since $60 migration
As part of our data to define how to extract Opening Figures from the Cash
Account data we need to ensure that we exclude these products.
New opening figures are needed for all ForEx products, since S60
maintained a single total for all currencies and separate per-
currency figures are now required at S80.
The S80 AIS passes data across to POL FS based on Horizon
Products and Modes. At S80, any mapping onto accounts is done
by POL FS based on the Account attribute defined in Horizon
Product Reference Data supplied by POL’s NRDS. system.
However the S60 AIS summarises the transactions from a number
of separate Horizon Products into a single account line. This
mapping is defined in Mapping of Horizon products to POL FS
chart of accounts codes (EA/CDE/001).
The Ref Data AIS is now likely to change slightly but the principle still applies.
Since we will need to explicitly identify those products which need to be
mapped for transactions prior to CAP nn, then it is proposed that this is
done using a separate static set of mapping data (based on EA/CDE/001)
and this will then provide the opportunity for the ForEx products to map
onto separate accounts if they were transacted prior to CAP nn or after
CAP nn.
We need to do some further work to define exactly what these interim mappings
look like or whether we should use the standard S80 mappings “with
exceptions” to handle ForEx.
4.3 FuyitSuU PROPOSAL
The following is what Fujitsu proposes:
At Migration Point 25, we change the Data Centre Processing such
that we start to generate a POLFS file to conform to the S80 AIS,
however we will continue to only send Cash and near-cash
information. Such data will be segregated into separate subfiles
within separate files as described above. This means that we will
potentially generate multiple subfiles for the same branch for the
same trading day, however there will not be more than one subfile
of a given type for the same branch for the same trading day.
These BLCR3 subfiles into a single file will be split across 64 files. However,
we need to do further detailed design before deciding if they are best kept in
separate files (ie making a total of 129 files being delivered each day) or
included with the BLCR1 subfiles.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 36 of 37
IMPACT Programme
It is assumed that it would make no difference to the POL FS Load process.
Philip to confirm.
Horizon will be configured with a list of Products (based on Mapping of
Horizon products to POL FS chart of accounts codes) and only transaction
summaries for products in this list will be passed through to POL FS and a
Balancing Transaction will be calculated to ensure that the sub-file
balances.
described above and will not use the NRDS defined mappings.
POL / Prism to confirm if this is OK.
The mapping will be based on the separate mapping data
We would expect Point 25 to be defined such that no branch wi
yet have rolled over from CAP nn to CAP nn+1
I
It will be up to POL to put in place business processes to ensure that any
branches that are running ahead of the current CAP are brought sufficiently in
line such that this is true.
Our expectation is that Point 25 is between one and two weeks prior to the
normal rollover of branches from CAP nn to CAP nn+1 (ie Point 30).
On a day that contains a mixture of Transactions for CAP nn and
CAP nn+1, the following will happen:
o A subfile with header BLCR3 will be generated for all
transactions in CAP nn (or earlier). This subfile will contain a
Balancing transaction
o A separate subfile with header BLCR1 will be generated for all
transactions in CAP nn+1 (or later). This subfile will not
contain a Balancing transaction
o If the Cash Account was also completed on this day, then a
third subfile with header BLCR2 will be generated for the
Closing figures based on the Cash Account. This subfile will
contain a Balancing transaction
I would expect the majority of branches to only be in this position for one
day.
The processes that generate the Subfiles of types BLCR2 and
BLCR3 could be discarded once we reach Point 40 in the migration
timeline.
Currently the AIS expects all these sub-files to have a Trading date of
“Wednesday” to distinguish them from “normal transactions, however there
will potentially be “normal transactions” for these branches (and perhaps
even for these products) also happening on Wednesday, so is there really any
point in using this false date rather than separating this data based on the fact
that it is in a different sub-file type.
POL00038909
POL00038909
DRN; Desktop/RNMS Version 0.7
© Post Office™ 2004
Page 37 of 37