POL00278013 - Extract from PO HIT Closing Submission pages 423-429 RE: Big 5: Remming In
POL00278013
POL00278013
Extract from PO HIT Closing Submission pages 423-429
Bug 5: Remming In
1. The key documents:
1.1 PC0203085"; PCO195380.”
1.2 KELacha4221Q?
1.3 Coyne 2, paras 3.56 — 3.66.*
14 Js2.°
Summary
2. Mr Coyne states that Bug 5: Remming In is a bug with lasting financial impact. Post
submits that any discrepancy wot instances of this bug are
eae '
Nature of this issue
3. Mr Coyne has conflated two distinct issues under the heading of “Remming In”:
3.1 Coyne 2, paras 3.56 — 3.59 relate to PCO203085° (“Issue 1”).
3.2. Coyne 2, para 3.60 relates to PC0195380’ and other Peaks associated with KEL
acha42210§ (“Issue 2”).
4. Both issues relate to remming in cash and result in a cash pouch being recorded twice in
error, but the sequence of steps taken by the Subpostmasters to trigger them are
significantly different.
' ¢F/695.1}
2 {F/588}.
3 {F/794}.
* ¢D2/4.1/29} to (D2/4.1/33}.
5 (D1/2/5}.
6 {F/695.1}.
7 4F/588}.
* (F/794}.
POL00278013
POL00278013
Extract from PO HIT Closing Submission pages 423-429
5. Subpostmasters rem in pouches of cash sent to the branch from the Post Office cash
centre. Each pouch has a unique barcode that needs to be scanned by the branch. This
automatically looks up the contents of the pouch so that the branch can confirm that the
physical contents of the pouch match up to the record on Horizon. Horizon then prints a
physical receipt to remin and the cash is then added to the branch cash holdings.
6. If there is a difference between what the system says is in a pouch of cash and the
amount of cash actually in the pouch, the Subpostmaster should raise the issue with
NBSC in order to get a Transaction Correction.
7. A remming error leads to a mismatch between the amounts of cash remmed out to one
place and the amounts remmed in from another. Remming errors are a violation of Data
Entry Accounting and are picked up by Horizon.
8. During his cross-examination Mr Coyne confirmed that he believed these bugs to have
lasting financial impact.’ This is incorrect. While both caused shortfalls in branch
accounts, those shortfalls were cancelled out by Transaction Corrections.
Issue 1
9. As set out in Peak PC0203085, the Subpostmaster started remming in a pouch on Counter
1 by scanning its barcode. The Subpostmaster did not complete the rem but stopped
doing it halfway through, without cancelling it. She then moved to a different counter
and, whilst remaining logged onto Counter 1 and using someone else’s log on details on
Counter 2, scanned the pouch barcode again and the rem was completed as normal. The
Subpostmaster then completed the same on Counter 1, which caused the rem to be
recorded twice and two lots of cash to be added to the branch accounts on Horizon,
creating a shortfall because there was actually only one lot of cash.
10. The duplicate rem would have been clearly recorded and visible to the Subpostmaster in
the transaction log. Rem ins are large, round numbers due to them being cash deliveries
and the resultant shortfall would therefore have been large and noticeable to the
Subpostmaster.
° (Day17/130:9} to {Day17/130:12}.
POL00278013
POL00278013
Extract from PO HIT Closing Submission pages 423-429
11. Horizon keeps a list of all remmed in pouches and if a pouch has been remmed in already,
it will reject the pouch when the barcode is scanned in. However, a pouch is only added
to the remmed in list once the rem in process is fully completed. However, in this case
the Subpostmaster did not complete the rem in process on Counter 1 before she
scanned the same pouch on Counter 2, which led to Horizon allowing the rem to go
through. Had the Subpostmaster cancelled and restarted the process by scanning the
barcode again, Horizon would not have allowed the second rem on Counter 1, because it
would have been recorded as already completed on Counter 2.
12. Mr Coyne states at para. 3.58 of his report that it took ten months to fix this issue.2° This
is inaccurate and it appears that Mr Coyne has muddled the two issues, counting from
the start of Issue 2 (March 2010) to the end of Issue 1 (January 2011). Issue 1 was raised
on 17 August 2010 and a BIMS was issued to Post Office containing information for Post
Office to remedy the discrepancy on 18 August 2010. Fujitsu then developed a fix to
prevent further occurrences.
13. Mr Coyne states at paras. 3.59 of his report that “/t/his bug was only brought to the
attention of Fujitsu/Post Office following notification from the Subpostmaster.”"?_ While
it is correct that the issue was reported by the Subpostmaster, it would have been
spotted by Post Office in any event because Post Office reconciles all rems on Horizon
with cash leaving their cash centre.
14. Mr Coyne’s suggestion at paragraphs 3.59 and 3.60 that the two Issues were related to
Dalmellington and “differing manifestation[s] relating from the same core bug” is not
correct.” Dalmellington was a separate issue that only affected outreach branches
(although both issues had similar symptoms).
15. A fix was implemented on 23 January 2011”. This meant that pouches are temporarily
added to the “remmed in” list once the barcode is scanned, rather than waiting for the
rem to be completed. This was part of the original design of the system, but it was not
properly implemented.
© ¢D2/4.1/30}
4 ¢D2/4.1/30}.
” ¢D2/4.1/30}.
8 (F/695.1}.
POL00278013
POL00278013
Extract from PO HIT Closing Submission pages 423-429
Issue 2
16. In Peak PC0195380, the Subpostmaster started remming in a pouch by scanning in its
barcode and then pressed “PREV” which moved them back one screen. They then
scanned the barcode again. Horizon recorded the same pouch twice but only printed
one receipt. This caused a shortfall in the branch accounts.
17. The duplicate rem would have been evident in the branch’s transaction records.
18. This issue occurred in the pilot phase of HNG-X. A fix was implemented that disabled the
“PREV” button from the rem in process. Thereby eliminating the risk of Subpostmasters
moving back a screen and duplicating the rem in. Affected branches would have been
corrected by ordinary rem checks.
19. Mr Coyne has correctly identified at para. 3.62 of his Supplemental Report that an
associated Peak to KEL acha4221Q was raised after Peak PC0195380 was fixed."* This is
likely to be because it can take a few days for a fix to percolate through the entire
network.
20. Regarding the other Peaks associated with KEL acha4221Q referred to by Mr Coyne in
para 3.63 of Coyne 2:°
20.1.1 PC01955117*; PCO196120"’ and PCO196154"* are all duplicates of Peak
PC0195380"° and were sent by Fujitsu to Post Office to compensate the
Subpostmaster on 4 March 2010, 23 March 2010 and 18 March 2010
respectively.
20.4.2 PC0196671;”° PCO197032;”* PCO197034;” PCO197605;”* PCO197651;
4 (D2/4.1/31}.
'S (F/794}.
6 (F/589}.
"7 (F/595}
8 (F/596}.
© (F/588}.
2 {F/599}.
21 (F/603}.
» (F/604}.
® (F/612}.
POL00278013
POL00278013
Extract from PO HIT Closing Submission pages 423-429
20.1.3
20.1.4
20.1.5
20.1.6
PC0197753*°; PCO197828;° PCO197837;"” PCO197838;** PC0197872;”°
PC0197873;*° PCO198115* are all issues that were detected by Fujitsu. Fujitsu
produced a report that would detect all of them except PC0197605* (because
that did not involve an error and the duplicate rem was intentional). The
report enables MSU to detect any further incidents of the issues and raise a
BIMS without SSC involvement. BIMS were sent to Post Office by Fujitsu to
compensate the relevant Subpostmasters on various dates in April and May
2010.
It is unclear why PCO226230*? is on Mr Coyne’s list, as there is no reference to
KEL acha4221Q within it.
PC0246629** is not a Horizon error, as Mr Coyne correctly identifies. It appears
to be user error.**
PC0251952*° is an operational issue, not a bug. It refers to the branch having
incorrect pouch types.
21. Mr Coyne’s suggestion at para. 3.64 of Coyne 2 that “/tjhe Release PEAK in relation to the
fix for PC0195380 (referenced by Dr Worden and Mr Parker in relation to KEL
acha4221Q) does not document every PEAK that would be impacted by the fix or
reference that the fix specifically applied to KEL acha4221Q. It also does not record
whether it was fully rolled out across the estate as at 19 April 2010 (the date given by Mr
™ 4F/615}.
28 (F/620}.
% (F/622}.
2 {F/623}.
> F/624}.
» {F/626}
2% {F/627}.
3 £F/632}.
» {F/612}.
% (F/1081}.
4 (F/1380}.
% (D2/4.1/32}.
8 FF /1484},
POL00278013
POL00278013
Extract from PO HIT Closing Submission pages 423-429
Parker in his witness statement)””’ is incorrect: that is not the purpose of a Release Peak.
The purpose of a release Peak is to show which software fixes have been issued. The
original Peak PCO195911** stated that the fix was to be rolled out from 19 April 2010
(which is presumably the document from which Mr Parker obtained this information).
The Release Peak says that it was actually rolled out from 22 April 2010.
Conclusion on Bug 5: Remming In
22. These issues occurred because of unusual steps taken by Subpostmasters.
23. Peak PCO0195380 occurred during the pilot phase of Horizon Online and the other Peaks in
Issue 2 led to a report being created by Fujitsu to detect further occurrences and report
them to Post Office so that Post Office could issue Transaction Corrections. The two
branches in Issue 1 were also remediated with Transaction Corrections.
% ¢D2/4.1/32} to {D2/4.1/33}.
8 4F/593.1}.