HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN
1, ITEM TRANSACTION MODES
17/1/98
PROBLEM DEFINITION BUSINESS IMPACT ROOT CAUSE ACTIONS WHO WHEN
A. Itis possible for the POCL ref data 1. Invalid txns at outlet. I © Pathway design problem in I => Pathway system change I TA 30/11/98
and Pathway menu hierarchy to be 2. Files rejected at TIP not using ITMs explicitly to be planned/agreed
out of line with regard to what are because of invalid © Inconsistencies in ref data in I => Errors in testing to be SR
valid item transaction modes. txns testing exacerbate problem addressed by using same
Pathway may therefore allow txns which LRDP will reduce for data (as far as possible).
which Ref Data and TIP see as live Manual edit on rejected
invalid files may be a temporary
expedient for testing,
only
=> Review AIS to assess P Jones
. changes to TIP process
Sow “* and validation rules to
. allow ‘invalid’ txns,
RS OK Assess business impact
> we and procedures to
Ce iz S support
7 => Review ongoing change I Phil
control process on ref Kennedy WadessI
. data - in order to —
minimise risk of invalid
txns
B. Given Problem A, where and how do I 1. Potential missing lines I ¢ Unknown => Assess whether and how I P Jeram
Pathway map invalid ITMs to cash on cash account this situation arises
account lines as they will not have a
mapping for these txns ?
a
POL00028432
POL00028432
17/11/98
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 2
1, ITEM TRANSACTION MODES (continued)
PROBLEM DEFINITION BUSINESS IMPACT ROOT CAUSE ACTIONS .WHO. WHEN
C. Are there other ITM refdata changes I 1. Invalid txns at outlet I © Pathway design problem => Review current Pathway I P Jeram
which may not be not applied at the 2. Files rejected by TIP I © Ref data change control design and agree fixes
right time or incorrectly (eg. Must a process => Review change control Phil
process Kennedy
‘child’ product have the same effective
dates as its parent on Pathway although mote
this may not be the case in ref data? :
Home care stamps may be an example)
POL00028432
POL00028432
POL00028432
POL00028432
17/11/98 I
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 3
2. CASH ACCOUNT MAPPINGS
PROBLEM DEFINITION BUSINESS IMPACT. ROOT CAUSE ACTIONS *_I-WHO. WHEN
A. It is essential to check cash account
mappings are consistently
implemented between POCL and
Pathway and applied at the counter.
B. So far no detailed cash account
mappings exercise has been carried
out by Pathway and or Horizon.
C. Overall checks are planned within
Live Reference Data Proving but not
all instances,
D. Unclear what tests Pathway have or
will carry out.
E. MO and E2E testing is not covering,
all possible combinations.
Items mapped to
incorrect lines may
generate one or more of
a range of problems
including:
1, an imbalanced cash
account
2. settlement errors
3. stock holding errors
4. errors in client
information
5. Mis matches (errors
created in CBDB)
between cash account
and supporting
document
Pathway solution not driven
directly from POCL Ref. Data:
¢ Human intervention can
cause errors in its translation
© Notall required cash
account mappings taken by
Pathway from Ref. Data
© Interface passed via 3
mediums
=> Ref, Data carry out full
cash account mapping,
exercise for the POCL
Ref. Data which includes
internal checking to
CBDB mappings
=> Pathway and or Horizon
carry out full cash
account mapping,
exercise for possible
combinations
=> Develop and test
procedures for the testing
of ongoing changes
which effect cash
account mappings
[Bos bie fre ha .
POL00028432
POL00028432
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 4 17/1198
Chongeo bo bef Pale,
3. MIGRATION TOOLS AND PROCESS
including bus tickets, passports, TV
licence, fishing licence and meals on
wheels).
comprising several products
of differing values, The Ref
Data mapping is a single
product. If this is fixed price,
but the constituent products
are of differing values (e.g.
both colour and b&w TV
licences) the validity rules
dictated by a fixed price
product are broken, It is not
possible to map correctly
therefore the actual
quantities and values. The
only way to comply with the
validity rules is to input
erroneous data on the
Horizon system.
environment to test the new
procedures and MiMan.
PROBLEM DEFINITION BUSINESS ROOT CAUSE ACTIONS WHO WHEN
IMPACT. a o
A. When migrating a manual office 1. Only option I © (1) Mapping table => No code change required to I n/a n/a
(using the MiMan tool) it is not would be to rationalised (to avoid being MiMan
possible to: map to cash excessively large) and only a I => Create 5 migration specific I G Darby 20/11/98 ° dy Cun Werte,
(1) migrate non core value stock (c.g. and unable single product is provided products (for home care
home care stamps). to sell (e.g. a specific Bus ticket or stamps, bus tickets, tok tha fea ty” I
product a single home care stamp) passports, TV licences,
which is not sold by every fishing licence). bk Mo ?
outlet. Since it therefore does I => Amend the Manual G Latham 30/11/98
not appear in Ref Data for mapping table for MiMan
that outlet, MiMan is unable I => Amend the Class B Cash GLatham 30/11/98
to present the User with the Account mapping.
option to migrate this => Incorporate new parameter I S.Warwick 30/12/98 bd QI Dato nsscheo
specific product at this tables into MiMan swe def dokea,
specific outlet, => Amend the procedures to S Grayston 14/12/98
advise the HFSO of the (E Long)
(2) migrate fixed price receipts and © (2) The Cash Account has a action to be taken. .
payments (¢.g. key products number of single line entries I => Establish suitable T Austin 1/1/99
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN
17/11/98
5
PROBLEM DEFINITION BUSINESS ROOT CAUSE - ACTIONS WHO. (WHEN *
IMPACT : neers ‘
B. When migrating an ECCO office Unable to e Reference Data inaccurate (it I => Document requirements for I S Grayston 25/11/98
(using the MiEcco tool) it is not migrate outlet does not identify that this mapping non-existent
possible to: outlet is selling this product), products, fixed price
© migrate a product which appears on products and suspense
the Ecco Counter terminal Disc Mapping table rationalised accounts, 30/12/98
(CTD) but which, according to (to avoid being excessively I => Code of MiEcco will be R Laking &
Reference Data, is not held within large) and only a single modified to map the product I S Warwick
this outlet. product is provided (c.g. a to the default product
© migrate non core value stock (c.g. specific Bus ticket or a single identified by Ecco PLU 000
home care stamps). home care stamp) which is (which in the first instance
© migrate fixed price receipts and not sold by every outlet, will be cash), MiEcco will
payments (e.g. bus tickets, passports, Since it therefore does not also be modified to display
TV licence and fishing licence). appear in Ref Data for that these instances at the end to
© migrate any discrepancies such as outlet, MiEcco is unable to enable the HFSO to take
suspense accounts unless total migrate this specific product action to correct Reference
balance within an office is at this specific outlet. Data and to help with
established prior to the start of any understanding what has -
migration. In the absence of suspense been mapped to the default
account migration facilities product.
we would need to balance => Create 4 migration specific I G Darby 20/11/98
each complete office before products (for uncharged
migrating cach stock unit receipts in and out and
imposes unacceptable unclaimed payments in and
time constraints on out).
migration. => Amend the Ecco mapping G Latham 30/11/98
table for MiEcco (including
PLU’s 000-999 in
accordance with Class B
Ref Data)
=> Amend the Class B Cash G Latham 30/11/98
Account mapping.
=> Incorporate new parameter I S Warwick 30/12/98
tables into MiMan ae
=> Amend the procedures to S Grayston 14/12/98
advise the HFSO of the (& E Long)
action to be taken.
=> Establish suitable T Austin W1/99
environment to test the new
procedures and MiEcco.
POL00028432
POL00028432
POL00028432
oe POL00028432
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 6 17/98
4, COUNTER REPORTING
PROBLEM DEFINITION BUSINESS IMPACT ROOT CAUSE ACTIONS WHO ©:\I WHEN Yn
A. A significant number of errors 1. Internal ¢ Pathway software errors => Fixes required prior to Pathway I 14/12/98 wey,
(approx 40) exist across a range of reconciliation not © Possibly due to spec/design start of MOT . °
counter and office summaries and possible within errors as well => Errors involving more hater r yerkred. ur
stock unit balance reports. Together offices serious issues require .
these errors make it impossible at 2. Incorrect information identification and Naan
present to manage the financial sent to clients assessment if they cannot Mnprslancr, fron
position of an office 3. Cannot produce be fixed quickly.
balanced cash y. .
accounts . Macglos “a
i
I
q
POL00028432
POL00028432
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 7 ITNV98
5. BES PROCESSING .
ohare bdo,
PROBLEM DEFINITION BUSINESS IMPACT ROOT CAUSE ACTIONS WHO WHEN. . 0
A. Voided BES / EPOSS transactions 1. Reconciliation not ¢ Pathway software error => Fix required prior to start I Pathway I 14/12/98 Dwiin (rom
are being sent to TIP with the possible between of MOT vv.
original transaction value instead of PAS and TIP
£0.00. This is being tracked within
PinICL 14575
B. POCL/ TP state they are unable to 1
«ICL Pathway believes this is I => POCL to comment on POCL 30/11/98 [at wd
reconcile the BES Summary file working to specification, as whether spec is as
(BARSF) to PMSRIO1I section 1 difference the encashments themselves required Hit
‘Total Encashed Payments’ as this have taken place. It is Pent
file includes ‘Suspended’ encashed important that POCL / TP
payments, i.e, those payments which reconcile this file to Section
have been suspended by PAS and not 3 of PMSRI101 ‘Adjusted
passed to CAPS duc to ‘DIDVR’ Total Encashed Payments’,
errors etc. and not to Section 1
C. Record/file rejections by TIP are 1, Cannot reconcile e Various - see other => Pathway to investigate Pathway I 30/11/98
also causing discrepancies with PAS problems.
D. PMSR report differences - various I 1. Difficulties in © 9 0f24 incidents have been I => Pathway to complete Pathway I 30/11/98
. aes reconciliation attributable to the testing investigation of other
environment incidents
E. One fallback and recovery incident 1. Invalid accounting, ¢ Pathway software error => This is being tracked Pathway I 30/11/98
was generated during E2E.(This for exceptions within PinICL 17260 and
required the clerk to input a different is thought to be duc toa
amount into the recovery screen at . problem with the
the counter than from the value exception indicator
encashed by the PCHL). In doing so, within the Oracle tables.
this should have created a genuine
fallback and recovery exception and
reported within report PMSR115, as
the BES / EPOSS value posted to fattrron fomleank
TIP should equate to the value cy
recovered by the clerk and value
posted to PMSR should equate to the
value encashed by the PCHL. In
practice, the value posted to TIP
equated to the value encashed by the
PCHL, therefore no difference was
identified.
«
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN
8 17/1/98
6. REFERENCE DATA.
PROBLEM DEFINITION BUSINESS IMPACT ROOT-CAUSE ACTIONS L WHO WHEN
A. In the same way that ITMs could, 1. High level of ¢ Flaws in the end-to-end => The office code version problem is in .
during live running, fall out of disruption at TIP design which may be traced resolution. It has been agreed by TIP, as ‘ Ua
synchronisation between TIP and interface and to design assumptions that minuted by Bruce Talmage on 11
Pathway so could office code, throughout end-to- have since proven to be November, that the only viable way to
versions (aka organisational unit end accounting and false. deal with errors resulting from known
versions), Although current reconciliation process Reference Data inconsistencies across
procedures are designed to minimise Pathway and TIP in the live environment
the likelihood of this happening, it is will be for the TIP interface to accept the
still a possibility. Two types of error record/s in error, overriding or bypassing
may occur at TIP validation: the rejection process as necessary. This
«those in which the incoming record will require a CR to be raised. Until that
fails validation because of CR has been accepted, the current
fundamental processing faults in the practice throughout testing of rejecting,
Pathway system and amending files must continue,
¢ those which fail because of known although this solution is not appropriate
limitations in the end-to-end design beyond testing. (The longer term end-to-
of Ref. Data (of which office code end design issues must also be addressed
versions is one example). — but this activity is not so time critical),
B. There is the possibility that product 1. High level of © Flaws in the end-to-end => Until the product attribute problem is
Altributes will also become out of disruption at TIP design which may be traced confirmed to exist and more clearly
step between Pathway and TIP, in interface and to design assumptions that understood, it is inappropriate to assign
much the same way as ITMs or throughout end-to- have since proven to be actions.
‘office code versions. Horizon testing end accounting and false.
currently understands that Pathway reconciliation process
correctly apply the effective dates for
the application of changes and that
this should not, therefore, be an
issue.(DN - this needs to be
confirmed with both Pathway and
TIP] Should it in fact be an issue, ”
this would again be defined as a
known limitation in the end-to-end
design (see above).
POL00028432
POL00028432
POL00028432
POL00028432
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 9 17/11/98
PROBLEM DEFINITION BUSINESS IMPACT. ROOT CAUSE ._I ACTIONS See + -I WHO... .I WHEN
C. There is the possibility that different I 1. High level of ¢ Flaws in the end-to-end ‘=> Versions and dates of Ref Data must be
sets of Ref Data are being applied disruption at TIP design which may be traced explicitly checked and verified across
across Pathway and UIP. during the interface and to design assumptions that Pathway and TIP to ensure that the same
test phases. Such a situation would throughout end-to- have since proven to be versions are in use on each MO/EZ2E test
generate errors as a result of end accounting and false. environment.
inconsistencies, would potentially reconciliation process
hide other problems and invalidate NOTE:
the objectives achieved in the test we The viability of MO/E2E for proving the
runs. There is no implication that a maintenance of alignment of Ref Data '
specific set of data is required in any across TIP and Pathway must be {
given test phase (eg. That pre-proven examined,
live reference must be used across
MOT and E2E Final), although this
factor will be considered as part of
the detailed re-plan of the test
activity moving forward.
© Asecond part of this issue is that the
scope of testing does not currently
allow the procedures for keeping,
Pathway and TIP aligned in terms of
Ref Data, during live running, to be
oven,
Lp yar arpead reins 5) BY. Deter -
POL00028432
POL00028432
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN 10 IW/1/98
7. FILE DELIVERY
PROBLEM DEFINITION BUSINESS IMPACT ROOT CAUSE ACTIONS I WHO WHEN.
A number of problems exist at a 1. Day today operation I ° E2E2isatestenvironment I => Furtherchecksaretobe I Pathway I 14/12/98
technical operational level in of the system will that was not expected to run included in the system
transferring and accepting files between become difficult to overnight. Many of the set-up scripts to ensure
Pathway and TIP over and above the manage. problems in this phase were all dates are correctly set.
data accuracy within the files : 2. Potential for Pathway created by running the
A. Invalid formats and integrity check and TIP to become overnight processing the
failures on dates and totals more and more out of following day, but with the
B, Delivery not within the required step. clock set to real time (ie
‘time’ slots which leads to errors on I 3. Reconciliation 8am).
which ‘counter day’ is being difficult to achieve.
processed . © The TPS database was sct- => FTMS was inoperable Pathway I 14/12/98 N
C. Long delays in file delivery up with an incorrect date, during MOR3 because of
D. Manual edits required to get files This caused a delay and a problem found in the
through rejection of TIP files Humingbird software. A
produced during the first patch has been received
week until it was diagnosed and tested and will now ‘
and corrected. allow the correct ageawowks
transmission of data. >
e The FTMS system failed to This will allow the TIP _—___—_—»>
work correctly and had to be files to be sent out at the 0, :
bypassed manually. This correct point in the 7 To wns be
manual transmission of files overnight schedule, as quiaprable
‘was not performed at the built into the Maestro
correct point in the Maestro schedule,
schedule and was delayed SLA
until the following morning,
therefore falling outside the
agreed time slots.
¢ Files were rejected by TIP %
and manually edited in an :
attempt to allow TIP to . “ye
process the data through to
the back end systems whilst
discussions (c.g. ITM)
progressed in parallel.
sence
POL00028432
POL00028432
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN MW 17/1/98
7. FILE DELIVERY (contd.)
NOTE:
. .
Whilst it is accepted that there were some software issues in the production of the TIP files which led a TIP rejection, this was a minority - 28% 4 (eo regted
Of the 27 files rejected by TIP:
1
2
3
4
5
6
13 files rejected for invalid date, caused by TPS db vhatabase set-up error. This was corrected on test date 17/11 after which all files should have the correct date
4 files rejected for invalid organisation code/version number
3 files rejected for missing mandatory data field
4 files rejected for invalid Item Transaction Mode (but this is valid according to reference data)
1 file rejected for duplicate OTX record
1 file rejected for incorrect/duplicate end of day marker
Rejections 2 and 4 will be discussed at the Horizon led workshop on the 19/11.
HORIZON TESTING - KEY PROBLEM AREA ANALYSIS AND ACTION PLAN
12- 17/11/98
8, HAPS DIFFERENCES
PROBLEM DEFINITION BUSINESS IMPACT ROOT CAUSE ACTIONS WHO WHEN
‘A. There are inconsistencies in the data. I 1. It will not be possible I * During E2E2 and MOR3 => The Operational Pathway I 14/12/98
being received and reported within to reconcile the PO Pathway has not produced procedure for producing,
the Pathway, HAPS and TIP with HAPS and TIP. the APR reports. This is a APR reports must be put
domains although they should all be process operated by the in place.
derived from the same source Business Support Group that
transactions, we have failed to put in => The ‘Harvesting’
operation. This is designed problems in E2E/MOR
to assist the recognition of must be resolved and
potential reconciliation corrected.
issues prior to the issuc of
files to HAPS and TIP. => Ashorter, more Pathway/ I December
These reports are now being, controlled, dedicated Horizon
produced for MOR3, but this reconciliation test should
will not help where we are be performed.
today,
© Investigations are continuing,
but there appears to be a
problem when Harvesting
the APS data, This has not
been experienced during
System Testing and must be
resolved,
”
POL00028432
POL00028432