POL00028466 - Acceptance Proposal for Acceptance Incident 376 - not passing records to TIP due to harvester exceptions caused by missing functions in counter code

Evidence on official site

POL00028466

POL00028466
ion Ale- Aceephee
wc > ICL Pathway Acceptance Proposal Ref: CR/ACD/376
. . Version: 0.3
: ey Acceptance Incident 376 Date: 4/9/99
Document Title: Acceptance Proposal for Acceptance Incident 376
Document Type: Acceptance Proposal
Abstract: This document contains ICL Pathway’s proposal to the
independent Expert in respect of Acceptance Incident 376.
Status: Issued
Distribution: . . Expert:
. hee Peter Copping
ICL Pathway:
P John Pope
Library
POCL:
Calum Craig
John Meagher
Min Burdett
Jeff Austin
Author: JCC Dicks
Comments to: Pathway list
Comments by: 6/9/99
© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 1 of 7

POL00028466

POL00028466

ICL Pathway Acceptance Proposal Ref: CR/ACD/376
Versi 0.3
Acceptance Incident 376 Date: 4/9/99

0 Document control

0.4 Document history

Version Date Reason

0.1 20/8/98 Initial draft for comments

0.2 24/8/99 Version for Expert and workshop 26/8
0.3 4/9/99 Version for Expert and workshop 6/9

0.2 Approval authorities

Name Position Signature Date
JH Benitett-- I Managing Director
JCC Dicks Customer Requirements

Director

0.3 Associated documents

Reference Vers Title Source
TIP Incident Status Report Pathway
Logical Design for EPOSS/TIP Reconciliation Pathway
Controls
Ceasing of Non-Core Products at Outlets Pathway

CS/PRD/065 0.3 Process For Removing Products From Outlets At Pathway
CSR

0.4 Abbreviations
AIS Application Interface Specification

CSR Core System Release

CSR+ Core System Release — Plus (the release after CSR)

EPOS Electronic Point of Sale

EPOSS _ EPOS Service

TIP Transaction Information Processing

TMS Transaction Management Service

TPS TIP Processing System — the Pathway host layer for the TIP stream

© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 2 of 7

POL00028466

POL00028466
aA
ICL Pathway Acceptance Proposal : Ref: CR/ACD/376
. Version: 0.3
Acceptance Incident 376 Date: 4/9/99

0.5 Table of-content

1
2
3
4 — POCL POSITION. ..sscssssssssssssesssssccssveessnscssnssssnsecessesssnessusvscssessnsessssesssnnsesscsssesenee 4
5 PATHWAY POSITION ...ssssssssssssseessecsnecenecscsssscsssssnvsessssnvsansesssanscssvsenscessenvssnsenoes 5

5.1 BACKGROUND.
5.2. MATURITY OF PLAN
5.3. DELIVERY OF ADDITIONAL CONTROLS.
5.4 CORE TO'NON-CORE (AI410)
5.4.1 The position at CSR.....
5.4.2 Further changes applicable at CSR+
5.4.3 AT410 resolution ..ssecseosssessseseseesses

© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 3 of 7

POL00028466

POL00028466
va ICL Pathway Acceptance Proposal Ref: CR/ACD/376
. Version: 0.3
Acceptance Incident 376 Date: 4/9/99

1 = Purpose

This document sets out ICL Pathway’s proposal that Acceptance Incident 376,
currently categorised as Medium by Pathway and High by POCL, should be
recategorised by POCL as Medium, and that the Clearance Plan is satisfactory
and should be agreed.

2 Summary

Pathway contends that there are Clearance Actions that address the three
remaining issues defined by POCL.

The issue relates to not passing records to TIP because of harvester exceptions
caused-by ‘riissing functions in counter code. ICL Pathway has taken measures
to both stop known occurrences and to ensure that any unforeseen occurrences
are reported both to TIP and to ICL Pathway development.

The occurrence of a functionally unrelated incident considered under this
Acceptance Incident, the omission of records from the counter cash account,
concerned only voucher products. This omission is in process of elimination.
In addition procedures have been tightened to minimise the risk of product
withdrawals causing operational difficulties at the counter.

Furthermore, additional reconciliation features that confirm the integrity of
data passing to TIP have been proposed.

3 Criteria

Criterion 831/1 is cited: “The Contractor shall support interface from TMS
and Outlets to Transaction Information Processing (TIP).

4 POCL position
Based upon the minutes of the Acceptance Board Meeting of 18 August 1999,
POCL contended that:
“the plan is still immature”.

“the proposal not to deliver the additional controls until March 2000 is not
acceptable”.

“the latest analysis performed on Incident 410 ... has revealed further
unresolved deficiencies and the workaround for these is not agreed”.

© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 4 of 7

POL00028466

POL00028466
‘ ICL Pathway Acceptance Proposal Ref: CR/ACD/376
. Version: 0.3
Acceptance Incident 376 Date: 4/9/99

5.1

Pathway position °

Background °

During the Live Trial, and since, incidents have occurred that, in POCL’s view,
constitute a potential threat to the integrity of their accounts. These can be
categorised into three groups:

1. Some outlet transactions were not sent to TIP:

° because the harvester deliberately omitted incomplete records,
caused principally by missing modes, and

. because, on one occasion, harvesting started before replication
-_ between recovering correspondence server nodes was complete;

2. Not all transactions were comprehended in the outlet cash account
- because of end-dating of Item Reference Data;

3 Some Cash Account records were not sent to TIP because the pointer

used by the harvester was not available:

° because a counter was re-booted before it could write it; and
. on one occasion, because a second balance process was allowed to
run.

Important advances have been made since the above incidents occurred,
discussed below tinder the same numbers as above:

1. All instances of messages written without harvester-sensitive fields have
been fixed, except one that will be fixed shortly. Accounting integrity
has been safeguarded by establishing routine examination of the Event
Logs to detect and report daily to TIP any harvester exceptions.

The harvester has been enhanced to positively check that the full message
set for an outlet is present on the correspondence server before initiating
harvesting for that outlet.

2. The system is being modified so that the balancing and Cash Account
processes can continue even if an item is end-dated during a period for
which there are transactions.

3. The system has been made robust against inopportune reboots by writing
persistent objects to the message store, enabling controlled restart of the
office balance process after power failure etc.

A change has been made to ensure that multiple balance processes cannot

© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page S of 7

POL00028466

POL00028466
4 “ah
‘ ICL Pathway Acceptance Proposal Ref: CR/ACD/376
. Version: 0.3
. Acceptance Incident 376 Date: 4/9/99

5.2

5.4

5.4.1

run concurrently. In addition a message will be displayed to inform the
user that that the balance process has initiated.

Maturity of plan

The Pathway proposal in this area has now been expanded into the High Level
Design document Logical Design for EPOSS/TIP Reconciliation Controls. The
joint working group has reviewed this in detail. This document provides a
description of how Pathway will provide additional reconciliation between the
Cash Account produced in the outlet and the transactions sent to TIP. It
contains detailed proposals for enhancements to counter processing, harvesting
and the TPS Host.

In addition the joint working group has discussed an interim measure to provide
assurance that the set of cash account records being delivered to POCL is
complete. , This involves adding the lines in the three principal tables and
checking that they total to the relevant table totals.

Delivery of additional controls

Clearance actions:

Provided the document Logical Design for EPOSS/TIP Reconciliation Controls
is agreed through agreement to this proposal by 6/9/99 the enhancements will
be in service by 31/12/99.

Provided the interim measure is agreed through agreement to this proposal by
6/9/99 the enhancements will be in service by 6/10/99.

Core to non-core (Al410)

The position at CSR

AI 410, although related to AI 376 through the generality of reconciliation of
the Cash Account and the TIP stream, is in fact the reverse condition: a record
that was not incorporated in the Cash Account was received by TIP.

This condition was caused by ceasing a voucher product at an outlet by
changing it from a Core product (transacted at all outlets) to Non-core
(transacted at only a subset). This resulted in “end dating” the Item Reference
Data at an outlet that had not received replacement non-core reference data but
had transacted the product earlier in the week. EPOSS did not include
transactions in the Cash Account that had occurred immediately before the
product was end-dated at the outlet.

It had been agreed, for CSR, that Operational Business Change procedures
would screen out cases of Item Reference Data being end-dated, the outlet
would not be able to perform housekeeping functions such as remitting out
remaining inventory in any case. The agreed process for removal from sale is by
use of changes to the Menu Hierarchy.

© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 6 of 7

POL00028466
POL00028466

ICL Pathway Acceptance Proposal : CR/ACD/376
0.
Acceptance Incident 376

Unfortunately neither POCL nor Pathway staff involved had realised that
changing a product from Core to Non core would result in just such a cessation.
Procedure documentation has now been amended to make this case explicit.

ICL Pathway is introducing a change to incorporate voucher product
transactions for end-dated products in the cash account. This will provide full
accounting integrity.

In addition, at POCL’s request, Pathway has produced a summary of all the
procedures surrounding product withdrawal, including those already agreed and
in place, in the document Process For Removing Products From Outlets At CSR.

5.4.2 Further changes applicable at CSR+

A feature, Item Transaction Mode, is scheduled for introduction at CSR+ and
will provide a comprehensive means of controlling the classes of transaction that
can be applied to products. However, in the course of considering these issues
it was fuirther-realised that no provision at CSR+ in interfaces and designs had
been made for the particular case of end-dating Non-core products in individual
outlets.

This issue, ceasing Non-core products at individual outlets at CSR+, has been
addressed in the document Ceasing of Non-Core Products at Outlets, which was
published on 24/8/99.

5.4.3 Al410 resolution
Clearance action:

Provided the document, Ceasing of Non-Core Products at Outlets, is agreed
through agreement to this proposal by 6/9/99 ICL Pathway will implement the
defined functions for CSR+.

© 1999 ICL Pathway Ltd COMMERCIAL IN CONFIDENCE Page 7 of 7

POL00028466
POL00028466

nS

«

oe

Al 376 - Incident analysis

o..
Fy

Deleted SU 4 2
SU double roll 4

Missing mode - Reversal

New SU

SU Name with blank first character
Missing timestamp

Deleted item reference data
Missing mode - OBCS suspend
Missing mode - scales

Replication recovery

Fee migration correction error
Corrupt .dil files on LT2 migration
eae Totats

afajafoa

a] fo ]a Jo }n [ale

@ I.

aul
37

BIS [© Jo JN Jo Jao [® Jo [ro Jo

;
i

leixdiplieds i.
1
{
i
i

8

r

S80 9485
9 4

?__Under investigation
* Nota Pathway fault 4

‘Harvester fix applied

Today

As at Spm Friday 3" Septenber

POL00028466
POL00028466

TIP Incident 376 Status Report 2/09/99

--TIP:No:
I Type/Outlets
hr Week.

Fix wy We 5138.¢
Root cause was s Stock’ Ui

8 — a included.within WP5406 which was distributed to"
858 27320 Root cause was 2 transactions recorded without timestamp

6 1 25211 during a session suspend/transfer operation and therefore not
13 harvested. A harvester fix was issued to cover this situation and

authorisation for the root cause fix (PINICL 25211) has been

POL00028466
POL00028466

This was the subject of AI410, concerning the change of
products from “core” to “non-core”. Changes have been made
to clarify Operational Business Change procedures in this area
which should prevent this problem recurring. The problem
arises only for Voucher transaction values, not for Value Stock.
At Stock Unit Balance time the system requires to access the item
records to obtain the description of the item for inclusion on the
balance report. If the item is not found the balance report prints
‘spaces’ for the description but then fails to create the balance
summary record for the product. This will be corrected to
behave exactly as for Stock Items. Pathway expect to deliver fix
by 14" September.

‘I Deleted stock:unit problem resulted:in TIP ivot bei

{_mode), applied ‘to live estate af
when: TIP requests that. we do so.:

28185
9908020071

This incident describes itself as a summary of similar incidents.
Pathway concurs with the view that they are simple repeats of
known causes, but will confirm this by detailed analysis if TIP

provide information to enable this.

POL00028466
POL00028466

This has the appearance of a transaction not harvested for week

” 9908040139 I 19, although there is no evidence of any transactions with ‘Null’
10 mode in the outlet for this CAP. The call has been passed to the
BSU._ Action with TIP to provide further information.
900 28480 Null mode transactions not harvested for week 19, which was
? 9908110215 .I before both the harvester substitution work-around and the root

cause fix were released.

28527

x : = “ os
insaction not harvested for week 19, which was

3 9908120206 i¢ harvéster substitution work-around and the root
9 cause fix were released.
19
905 28529 Compensating differences between cash and cheque lines. Under
? 2 I 9908120210 I investigation.

28630
9908160158

POL00028466
POL00028466

28847 Ir may be of interest that the value of the discrepancy between
” 1 I 9908200185 I the TIP and Pathway figures appears to correspond to 2 x

21 £230.63. During the balancing of stock unit AA on 18.8.99, a
stock adjustment was made to reduce the value of Cheques
(Product 2) by this amount, with a corresponding increase in
Cash. These two stock adjustment records were later
individually reversed, generating a further 4 transactions for
£230.63, 3 against Cash (Product 1) and 1 against Cheques
(Product 2). Therefore in total 4 Cash transactions (two
positive, two negative) and two Cheques transactions (one
positive and one negative) were written.

Given that there have previously been issues with TIP's rejections
of ‘Existing Reversal’ transactions where the reversal settlement
contained no cross-reference details, is it possible that this has
caused the reconciliation failure? According to the message store
data, the Cash Account for CAP 21 reported Total Receipts =
Total Payments, indicating that the message store data is
complete and accurate.

919

AI 359 2?

been'recorded with a’
stem at this time: (whi
variable holding th

POL00028466
POL00028466

Incident Types

1. Deleted SU

2. SU double roll

3. Missing mode - reversal

4. New SU

S. SU name with blank first character

6. Missing time stamp

7. Deleted Item ref data

8 Missing mode — OBCS suspend

9. Missing_mode - scales

10. I Replication recovery

11, __I Fee migration correction error

12. I Corrupted software file
* I Not Pathway error