POL00069835
POL00069835
Page I of 5
St hen Dilley
From: Pinder Brian}
Sent: 06 November 2006 17:46
To: Stephen Dilley
Ce: graham.c.wardi
k; Sewell Peter (FELO1)
Subject: RE: Post Office Limited -v- Lee Castleton
Importance: High
Stephen
Please see attached response (from Gareth Jenkins) interleaved, in answer to your questions.
Kind Regds Brian
1. Every time that a new customer is served there is a new “session.” Each customer's
transactions are recorded in a “stack.” For each session:
(a) the number of transactions is recorded;
[G13]. The number of transactions is not explicitly recorded. However there is a separate
record for each transaction so the number of transactions can be inferred. NB each MOP
used is also a transaction and so these transactions are also recorded.
(b) the total cost is shown;
[GIJ] Again the total cost is not explicitly recorded. The running total is maintained visually on
the screen, but if multiple payment methods are used, there is no explicit recording of the
total cost in the Audit Trail.
(c) the method of payment is recorded;
[GI] Method of Payment products are just recorded as additional transactions. There is
nothing special about them. Specifically there is nothing to say that they are MOPs (other
than realising that the products related to the transactions are normally used for MOP).
(d) settlement occurs by pressing a button to clear the stack; and
[G13] This is a two stage process:
e A button is pressed to start settlement
« MOP transactions are then recorded until the session is complete (ie value of MOP
transactions equal the value of business transactions). This is frequently achieved with a
shortcut “Fast Cash” MOP which indicates that the exact cash has been tendered.
(e) when the button is pressed to clear the stack, the transaction is complete and
records the information on to the database.
[GIJ] This recording of the transactions occurs when all MOP transactions have been added to
the stack and the net stack value is zero.
2. If machine freezes before the button is pressed to clear the stack, the information is
not recorded because the transaction has not been completed.
[GiJ] Correct. However in some circumstances (ie for specific types of transaction) there may be an
07/11/2006
POL00069835
POL00069835
Page 2 of 5
indication of the transaction having taken place in the Audit Trail and recovery of the terminal (even a few
days 3r) may cause the transaction to complete and to be recorded at recovery time. Also, Transactions
relatiy to Failed Mails Labels are recorded immediately rather than waiting for the stack to be settled.
From: Stephen Dilley
Sent: 06 November 2006 10:38
To: Pinder Brian
ost Office Limited -v- Lee Castleton
Importance: High
Dear Brian,
We're preparing a supplemental witness statement for Greg Booth to cover off the event at
Newby P.O.
Please can you confirm whether the text below is accurate:
1. Every time that a new customer is served there is a new “session.” Each customer's
transactions are recorded in a “stack.” For each session:
(a) the number of transactions is recorded;
(b) the total cost is shown;
(c) the method of payment is recorded;
(d) settlement occurs by pressing a button to clear the stack; and
(e) when the button is pressed to clear the stack, the transaction is complete and records
the information on to the database.
2. If machine freezes before the button is pressed to clear the stack, the information is not
recorded because the transaction has not been completed.
I look forward to hearing from you as soon as possible today.
Kind regards.
Stephen Dilley
Solicitor
for and on behalf of Bond Pearce LLP
From: Pinder Brian (~
Sent: 02 November 2006 1
To: Stephen Dilley
Cc: Tom Beezer; mandy.talbot
martyn. mitchell
Subject: RE: Post Office Limited -v- Lee Castleton
Richard Morgan; graham.c.wardi~
07/11/2006
POL00069835
POL00069835
Page 3 of 5
Stephen
You __jht wish to note that:
Shou the system be restarted (for any reason — including following a “freeze”), there will be evidence of this
in the Audit trail (which we have in fact been examining in this case). Normally the only system restarts
are as part of the overnight “clear desk” function that occurs between 03:30 and 04:00 each day. Any other
restarts can be considered unusual and could be searched for.
Regds Brian
From: Pinder Brian
Sent: 01 November 2006 15:05
To: ‘Stephen Dilley’
Cc: Tom Beezer;
martyn.mitchel?”
Subject: RE: Po:
Richard Morgan; graham.c.war
-v- Lee Castleton
Stephen
On initial investigation I am advised as follows;
‘The gateway was rebooted at about 13:25 on Wed 25th October, possibly because the system froze when printing the
receipt for a postage label. The label itself had been successfully printed at 13:17 (value £1.27).
So the postage label would have been on the stack, but the session was never settled. Any transactions on the stack in
these circumstances are lost (there is a recovery mechanism for banking and AP transactions, but not for other types of
transactions).
The documentation provided to the PM should tell them what to do when the system fails in the middle of a session, or
NBSC should advise.
If the PM took the money for the label although the stack hadn't / couldn't be settled, then he will have a gain.
This is not strictly speaking a transaction being lost, it has always been a fundamental part of the design that the
transaction is not written to the system for accounting purposes until the session is settled, at which point you have a set
of transactions including settlement which net to zero..
Thope this is helpful
Kind Regds Brian
From: Stephen Dilley
Sent: 31 October 2006 16:04
To: Pinder Brian
Cc: Tom Beezer;
martyn.mitchell
Subject: Post Office Limited -v- Lee Castleton
Importance: High
mandy.talbo’ “3 Richard Morgan; graham.c.wardi™
Dear Brian,
One of the witnesses in the Castleton case is Greg Booth who was the temporary sub-
postmaster at Marine Drive branch from 21 April to 28 May 2004. Greg is currently the
manager of the Newbury Post office branch, 401 Scalby Road, Scarborough, YO12 6TQ.
Greg spoke to me last week and reported that his computer froze on Wed 25 or Thurs 26
October 2006 (I will clarify which day) whilst he was serving a customer and part way through a
transaction. The transaction had not been settled. It related to a postage label. When he
logged back in again, the computer had lost the transaction of £1.27. The computer did
07/11/2006
POL00069835
POL00069835
Page 4 of 5
not prompt him to try to recover it. Greg is away this week, but I will be contacting him upon
his “urn to obtain a supplemental witness statement about this point. Prior to then, Greg's
eviacnce was that he had never know the system to lose a transaction. In this particular case,
Greg was £1.27 up because he had taken money from a customer. However, I anticipate the
reverse would have happened if he had been paying money out.
Although this is for a small amount, the principle on the face of it seems concerning because it
suggests that the Horizon system can, (albeit rarely), lose transactions. Castleton's solicitors
will try to exploit any weakness and we must be prepared for a possible attack on this point.
Our Counsel has requested that Fujitsu review the Newbury Post Office's Horizon data for those
days period to see if you can tell whether the system froze and lost the transaction and what
the explanation may be.
We have to serve Witness Statements very shortly. I will have to prepare a supplemental
Witness Statement for Greg Booth dealing with this and may possibly need to take a further
Witness Statement from somebody at Fujitsu, depending on your explanation. Accordingly, I
would be grateful if you could look into this and come back to me as a matter of urgency.
Kind regards.
Yours sincerely
Stephen Dilley
Solicitor
for and on behalf of Bond Pearce LLP
The information in this e-mail and any attachments are confidential and may be legally privileged
and protected by law. The intended recipient only is authorised to access this e-mail and any
attachments. If you are not the intended recipient, please notify the sender as soon as possible and
delete any copies. Unauthorised use, dissemination, distribution, publication or copying of this
communication is prohibited.
Any files attached to this e-mail will have been checked by us with virus detection software before
transmission. You should carry out your own virus checks before opening any attachment. Bond
Pearce LLP accepts no liability for any loss or damage which may be caused by software viruses.
Bond Pearce LLP is a Limited Liability Partnership registered in England and Wales number
0C311430.
Registered Office: 3 Temple Quay, Temple Back East, Bristol, BS1 6DZ.
A list of Members is available from our registered office. Any reference to a Partner in relation to
Bond Pearce LLP means a Member of Bond Pearce LLP. Bond Pearce LLP is regulated by the Law
Society.
The information in this e-mail and any attachments are confidential and may be legally privileged
and protected by law. The intended recipient only is authorised to access this e-mail and any
attachments. If you are not the intended recipient, please notify the sender as soon as possible and
delete any copies. Unauthorised use, dissemination, distribution, publication or copying of this
communication is prohibited.
Any files attached to this e-mail will have been checked by us with virus detection software before
transmission. You should carry out your own virus checks before opening any attachment. Bond
Pearce LLP accepts no liability for any loss or damage which may be caused by software viruses.
07/11/2006
POL00069835
POL00069835
Page 5 of 5
” Bond Pearce LLP is a Limited Liability Partnership registered in England and Wales number
OC 1430.
Registered Office: 3 Temple Quay, Temple Back East, Bristol, BS1 6DZ.
A list of Members is available from our registered office. Any reference to a Partner in relation to
Bond Pearce LLP means a Member of Bond Pearce LLP. Bond Pearce LLP is regulated by the Law
Society.
07/11/2006