POL00039522
POL00039522
Name of Bug Date Jenkins/Chambers I PEAK references I What was said by Jenkins/Chambers
&
Trial Bundle Ref
1. Receipts and Payments _ I Occurred in Gareth Jenkins PEAK PC0204263 I The bug was documented in a report from Mr
Mis-match bug. 2010 dated 16 September I Gareth Jenkins dated 29 September 2010 where it
2010 was stated:
(Ref F/709/1)
“This has the following consequences: There will
be a receipts and payment mismatch corresponding
to the value of discrepancies that were lost. Note
that if the user doesn't check their final balance
report carefully they may be unaware of the issue
since there is no explicit message when a receipts
and payment mismatch is found on the final balance
(the user is only prompted when one is just detected
during a trial balance)”
2.Callendar Square/ Occurred Anne Chambers (Ref F/333.1/3) Fujitsu employee, Anne Chambers, stated in an
Falkirk bug. between the email to Mike Stewart (Fujitsu) in February 2006:
years of 2000
and 2006
“Haven't looked at the recent evidence, but I know
in the past this site had hit this Riposte lock problem
2 or 3 times within a few weeks. This problem has
been around for years and affects a number of sites
most weeks, and finally Escher say they have done
something about it.”
POL00039522
POL00039522
3. Suspense Account bug.
Years of effect
2010 to 2013
Gareth Jenkins
PEAK PC0223870
(Ref F/1045/1)
Mr Gareth Jenkins in 2013 prepared a note
entitled “Local Suspense Problem” (Ref F/1075/1)
which identified that, at that stage, 14 branches had
been affected. He stated:
“The root cause of the problem was that under some
specific, rare circumstances some temporary data
used in calculating the Local Suspense was not
deleted when it should have been, and so was
erroneously re-used a year later. When the SPMR
was asked to clear Local Suspense the actual (ie
incorrect) amount was recorded in the Audit Trail.
This means that there was no corruption in the audit
trail and it accurately reflects the transactions that
occurred in the Branch.
If the BTS from the previous period was taken to
provide a set of Opening Balances and all
transactions that were logged to the audit trail
during the period were taken as adjustments, then
this would show the correct value that should be in
the Local Suspense account.”
He also stated, in a passage that is of interest in
terms of the dispute between the parties about the
use of Audit Data or management data such as
Credence (the Post Office maintains that the latter
are sufficient, the claimants insist the former are the
relevant accurate records) the following:
“As well as passing these Local Suspense
transactions to the normal accounting tables that are
used to update POL SAP and Credence, they are
POL00039522
POL00039522
also written to a table in the Branch Database that
is used to support the printing of the Branch
Trading Statement (BTS) after that Branch has been
fully Balanced.”
Further detail of the problem explained by Mr
Jenkins in the same report was:
“In April 2011 a problem was found with the
archiving strategy related to Stock Units that have
been deleted in a Branch. A consequence of this is
that some changes were made to the archiving
strategy on 3 July 2011. An unintended
consequence of this change was that any Branch
that deleted a Stock Unit at the end of 2010 which
had local suspense transaction in that Stock Unit
before it was deleted were left in the table used for
constructing the BTS. This meant that as Trading
Periods cycle around each year, these BTS records
became visible in 2011 when the same Trading
Period was reached.
The effect of these old records was that after the
BTS was produced an incorrect figure was
generated for the Opening Balance of the Local
Suspense Account for the following period. This
amount corresponded to the value of the historical
record.
These orphaned records were created between 16'"
November 2010 and 9" December 2010.”
POL00039522
POL00039522
Name of Bug
Date
Jenkins/Chambers
PEAK references
&
Trial Bundle Ref
What was said by Jenkins/Chambers
The Note prepared by Mr Jenkins makes it clear
that, despite how the Post Office sought to present
this in their submissions, this problem persisted.
The document states: “This problem was not
reported to Fujitsu in 2011/12 and only affected a
small number of Branches and only for a single
Trading Period. However the two branches with the
largest discrepancies did report the issue to Post
Office Ltd who could see the impact of the problem
in their back end system and wrote off the loss or
gain for the branch but _did not ask Fujitsu_to
investigate further. At the same Trading Period in
2012/13, the problem re-occurred and this time one
of the affected Branches reported the problem to
Fujitsu on 25" February 2013 (Peak 223870)
resulting in a detailed analysis of this issue and
finding the orphaned BTS records. The root cause
was determined by 28" February 2013 and a
preliminary report was sent to Post Office Ltd. A
further update was sent on 14" March 2013 with a
full analysis of the issue and all the affected
branches.”
POL00039522
POL00039522
5. Remming In bug.
Present for
about five
months in
2010 between
March and
August
Anne Chambers
Gareth Jenkins
PEAK PC0203085
(Ref F/695.1/1)
PEAK PC0195380
(Ref F/588/1)
PEAK PC0203085
On 17 August 2010 from Anne Chambers:
“A cash pouch was remmed in twice at branch
126109:
Pouch barcode 399347067204
2p coin £60
S0p coin £250
Sp coin £100
Session 1-350379 16/09/2010 10:08
Session 2-195226 16/09/2010 10:08
The PM cannot reverse the transaction since rem
reversal isn't allowed.
This is NOT another example of the duplicate rem
problem that we have seen in the past, where use of
the Prev key accepted the same pouch twice. In this
case the pouch was processed on both counters...
09:05 c2 get pouch status, retrieve pouch details
09:06 cl get pouch status, retrieve pouch details
09:08 c2 settle pouch delivery
09:08 cl settle pouch delivery
There were some printer problems on counter 2
which probably explain why this was done.”
The other contradictory entry within the same
PEAK is the next day, 18 August 2010 and states,
again from Anne Chambers
POL00039522
POL00039522
“T checked whether there were any exceptions in
the BAL OSR logs for any of the messages, there
was nothing.
Gareth Jenkins thinks that it should not be
possible to complete the rem in on both counters.
Please investigate.” (F/695.1/4)
PEAK PC0195380
This KEL was raised by Anne Chambers on 2
March 2010, updated on 3 May 2011, and the
keywords are remittance, remittence, remin, pouch
and delivery. It can be seen that the following is
included in the KEL:
“Symptoms
The clerk went into the Delivery menu and scanned
two pouches (one of currency and one of coins).
The second pouch was recorded twice on the
system, resulting in a loss of £80.
Two Rem In slips relating to the second pouch were
output, both identical, as well as one for the first
barcode.
In the most recent instance, the same pouch was
remmed in on two different counters at about the
same time.
Problem
This was caused by using the Prev key during / just
after the pouch barcode scans. Now fixed - details
in PC0195380.
POL00039522
POL00039522
Name of Bug
Date
Jenkins/Chambers
PEAK references
&
Trial Bundle Ref
What was said by Jenkins/Chambers
In PC0203085, the same pouch was processed on
both counters...
09:05 c2 get pouch status, retrieve pouch details
09:06 cl get pouch status, retrieve pouch details
09:08 c2 settle pouch delivery
09:08 cl settle pouch delivery
PC0203085 - fix applied Jan 2011.
Solution - ATOS
A transaction log search will prove that the Rem In
has been duplicated.
Send call to SSC, quoting this KEL.
SSC:
Known problems have been fixed, so needs fresh
investigation if it happens again.
POL may need to issue a TC to undo the effects of
the extra rem in (in the meantime the branch will
report a shortage), so MSU need to inform POL via
BIMS.”
6. Remming Out bug.
Identified
February/April
2007
Anne Chambers
PEAK PC0143435
(Ref F/384/1)
Split into two in the Bug Table, 6(i) and 6(ii)
Bug 6(i) was identified as KEL achaS08S. (Ref
F/403/1)
Fujitsu created KEL acha508S to advise branches
to correct the problem manually and ran
automated reports to spot any further occurrences.
POL00039522
POL00039522
Name of Bug
Date
Jenkins/Chambers
PEAK references
&
Trial Bundle Ref
What was said by Jenkins/Chambers
7. Local Suspense Account
issue, not the same as 3.
Suspense Account bug.
Reported in
2010
Anne Chambers
There were four associated KELs, two were raised
by Anne Chambers namely acha5259Q (Ref
F/637/1), (for which there were 6 PEAKs)
and acha5838T (which states there are “two
different but similar problems” and appears in the
text, but not in the list of KELs at the end of the text
by Mr Coyne).
Dr Worden’s comments in the table were that:
“The KEL acha5259Q implies that PO and Fujitsu
were able to identify all occurrences of the problem,
without being notified by any Subpostmaster. I
would therefore expect them to have corrected any
impact on branch accounts as part of normal error
correction processes.
I would not expect evidence of all corrections to
accounts to have survived to the present day.
PEAKS and KELs are not used to record
corrections of financial impact.”
8. Recovery Issues.
Years of effect
from 2010 to
2018
Anne Chambers
PEAK PC0197769
(Ref F/617/1)
PEAK PC0214226
(Ref F/870/1)
Mr Coyne dealt with two different documents in his
report, PC0197769 and KEL acha959T.
The former was created on 15 April 2010 during the
pilot phase of Horizon Online. The root cause of the
issue was identified on 26 April 2010, work on a fix
was started and this was released in early June as
shown in Release PEAK PC0199000 (and then
estate-wide to pilot branches) by mid-June 2010.
POL00039522
POL00039522
Name of Bug Date Jenkins/Chambers I PEAK references I What was said by Jenkins/Chambers
&
Trial Bundle Ref
The reference to the “959T” KEL below is the KEL
whose full title is acha959T which was raised by
Anne Chambers.
KELacha959T is also the very same KEL referred
to in PEAK PC0214226 dated 14 December 2011,
headed “Failed Recovery Transaction(s) 12 Dec
11”
11. Girobank Occurred. Anne Chambers PEAK PC0073855 I In PC0075312, a SPM raised an issue with printing
discrepancies. between May (Ref F/112/1) her giro deposits. The issue was identified as being
and September
2000
PEAK PC0075312
caused by the same root issue as PC0073855 which
was already with the development team. These did
not impact branch accounts.
(Ref F/114/1) The KEL with which they are associated is KEL
AChambers4410R, the same KEL as the PEAK in
Issue 4.
12. Counter-replacement Occurred from I Gareth Jenkins PEAK PC0052823 I PEAK PC0052823 gives a technical explanation
issues. 2000 to 2009 (Ref F/54/1) for this,
It also notes that “Gareth Jenkins viewed this error
on rig with Mike Berrisford.”
19. Post & Go/TA Occurred in Anne Chambers PEAK Anne Chambers records that:
discrepancies in POLSAP. I 2012 PC021943293 “Branch 020511 has many entries in the
PEAK Subfiles_on_hold report. This report should be
PC021870294 monitored (by ?) to make sure problems are
followed up - this should be resolved before closing
this call.
POL00039522
POL00039522
Name of Bug
Date
Jenkins/Chambers
PEAK references
&
Trial Bundle Ref
What was said by Jenkins/Chambers
Horizon is receiving PG data for 6 separate PG tills
at the branch, but only 4 of them have associated
stock units. This causes the entire subfile for the
branch to be Held, and the transaction data is not
being sent to POLSAP. However the TA data for
the 4 tills which are properly associated IS being
sent through, and I think this is probably the cause
of the POLSAP anomalies.
The two unassociated tills are not doing any cash
transactions - this is a known problem (see
PC021870294), and means the PM isn't prompted
to create an association. This may need fixing via
MSC.”
A bug fix to the Horizon system was identified by
Fujitsu, scheduled for implementation 13
September 2012
On 17 September 2012 Anne Chambers herself
reported in the PEAK that:
“Following a change made centrally to facilitate
this, the stock unit associations for the two new Post
and Go terminals have been created by the branch
and all the held external data (43 different days) has
now been processed and passed through to
POLSAP... We strongly recommend that POL
monitor the SubfilesOnHold report which is sent to
them daily, so that any other external terminals with
10
POL00039522
POL00039522
Name of Bug
Date
Jenkins/Chambers
PEAK references
&
Trial Bundle Ref
What was said by Jenkins/Chambers
problems can be investigated quickly in case a
similar correction is needed”.
23. Bureau de change
Arose in 2005,
2006 and 2010
Anne Chambers
PEAK PC0200042
(Ref F/662.1/1)
PEAK PC0200090
(Ref F/663/1)
The solution in one of the KELs, raised by Anne
Chambers namely AChambers2252R is:
“Solution - ATOS
If a PM reports a loss connected with a currency
transaction that was reversed, it is possible that the
reversal had not been carried — out
successfully.<br><br>Ask the PM to check the
Reversal Receipt. If this shows<br><br>Cash
FROM CUSTOMER 750.00<br>Cash TO
CUSTOMER 750.00<br><br>they have reversed.
just the cash settlement part of the transaction,
which has no overall effect. The currency and
margin part of the transaction has not been
teversed.<br><br>Do a transaction log search
using the Session Id from the original receipt, or by
date/time.<br><br>This should show 3 elements -
for example<br> <br>2-29826-2 SC Euro 1-
720.00-<br>2-29826-2 SC Curr Sell Margin 1-
30.00-<br>2-29826-3 sc Cash 1
750.00<br><br>The element which should be
reversed is 2-29826-2 (i.e. Euros and margin). As
long as the PM has not yet rolled over the stock unit,
they should be able to reverse this transaction
now.<br> <br>If the stock unit has been rolled
over, NBSC will have to advise on what can be
11
POL00039522
POL00039522
Name of Bug Date Jenkins/Chambers I PEAK references I What was said by Jenkins/Chambers
&
Trial Bundle Ref
done to resolve the system loss relating to this
transaction.”
24. Wrong branch customer I Occurred in Anne Chambers PEAK PC0128264 I Peak PC0128264 was opened on 4 November
change displayed. 2005 (Ref F/310/1) 2005 as a result of a SPM reporting the issue on 4
November 2005. The matter was passed to
Fujitsu’s development team for a software fix on
PEAK PCO0129791 I around 10 November 2005 and a fix was
(Ref F/317/1) implemented on 18 November 2005.
On 6 December 2005, a further instance was
reported (Peak PC0129791). The root cause was
identified and it was found that this issue related to
Peak PC0128264 which documented the fix that
had been put in place.
The KEL on this was again one authored by Anne
Chambers.
26. TPSC 250 Report. Occurred Anne Chambers PEAK PC0123056 I One PEAK, namely PC0123056, in its entry for 12
between 2005 I Gareth Jenkins (Ref F/287.1/1) July 2005 by Anne Chambers:
and 2009
“Yes this is another instance of KEL
AChambers253L - mails transaction total value
£1.86, prepaid £4.26, so postage label for -£2.40
generated. This has upset the counter
reconciliation figures.”
12
POL00039522
POL00039522
Name of Bug
Date
Jenkins/Chambers
PEAK references
&
Trial Bundle Ref
What was said by Jenkins/Chambers
The software upgrade was accompanied by
something called “S80 Release Note — Deferred
PEAKs List — Counter.” This document is dated 13
October 2005 and is 32 pages long. It “details
PEAKs that are outstanding at S80” and the
approved form of that document is in the trial
bundle. The Technical Design Authority for it was
Gareth Jenkins. (Ref F/303/2)
13