POL00073743
POL00073743
“Pinder Brian. To: “Stephen Dilley
‘ GRO ce: "Tom Beezer"
[GRO ! <mandy.talbot¢ <graham.c.ward
<martyn.mitchei
<Peter Sewell,
Subject: RE: Post Office Liinited=
06/11/2006 17:45 Sewell Peter (FELOTY”
(ee ‘Castleton
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;
[GI] 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
e 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 i
with a shortcut “Fast Cash” MOP which indicates that the exact cash has been
tendered. I
(e) when the button is pressed to clear the stack, the transaction is
complete and records the information on to the database.
[G1J] 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
indication of the transaction having taken place in the Audit Trail and recovery of the terminal (even a few
days later) may cause the transaction to complete and to be recorded at recovery time. Also,
Transactions relating to Failed Mails Labels are recorded immediately rather than waiting for the stack to
POL00073743
POL00073743
be settled
From: Stephen Dilley!
Sent: 06 November 2006 10:38
To: Pinder Brian nes
Cc: Tom Beezer; graham.c.wardt
martyn.mitchelf” .
Subject: RE: Po:
Importance: High
v- Lee Castleton
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.
GRO
www. bondpearce.com
From: Pinder Brian}
Sent: 02 November
To: Stephen Dilley
POL00073743
POL00073743
Cc: Tom Beezer; mandy.talbo'
martyn.mitchell
Subject: RE: Post
Stephen
You might wish to note that:
Should 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
} Richard Morgan; graham.c.ward}
Lee Castleton
From: Pinder Brian
Sent: 01 November 2006 15:05
To: ‘Stephen Dilley’
Cc: Tom Beezer; mandy. talbo:
martyn.mitchelli Gi
Subject: RE: Post Office Linitad
Stephen
GRO
-v- Lee Castleton
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.
Tf 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..
T hope this is helpful
Kind Regds Brian
From: Stephen Dilley
Sent: 31 October 2006 16:04
To: Pinder Brian
Cc: Tom Beezer; mandy.talbot_
martyn.mitchelf~
Subject: Post OFicé
Importance: High
Dear Brian,
Richard Morgan; graham.c.ward,
Lee Castleton
POL00073743
POL00073743
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 not prompt him to try to recover it. Greg is away this week, but I will be
contacting him upon his return to obtain a supplemental witness statement about this point.
Prior to then, Greg's evidence 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.
POL00073743
POL00073743
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,
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.