Filed on behalf of the: Claimant
Witness: Gareth Jenkins
Statement: 1
Exhibits: "eu"
Date made: 2/8/06
IN THE HIGH COURT OF JUSTICE Claim No. HQO5X02706
QUEENS BENCH DIVISION
BETWEEN:
POST OFFICE LIMITED Claimant/Part 20
Defendant
- and -
LEE CASTLETON Defendant/Part
I’ve annotated this using the following conventions:
« All my changes are as Word Revisions in this colour.
« Where they are straight text changes, then that is all
« When they are comments / discussions on the test, they are
highlighted in yellow (like this)
phasise s
comment. In that case I’ve used Turquoise (like this)
Gareth
WITNESS STATEMENT OF GARETH JENKINS
I, GARETH JENKINS of Fujitsu Services, Lovelace Road, Bracknell, Berkshire, RG12
8SN WILL SAY AS FOLLOWS:
1. Iam a Distinguished Engineer employed by Fujitsu. I have worked for Fujitsu
since [September 1973]. I am responsible for [the architectural design of
the Business Applications within Horizon]. 1 have a working knowledge of
the computer system known as Horizon, which is a computerised accounting
system used by Post Office Limited (Post Office).
2. I make this Witness Statement from facts within my own knowledge unless
otherwise stated. References to page numbers in this Witness Statement are to
page numbers of Exhibit “GJ1” to this Witness Statement.
1A_1180744_1 1
FUJ00122284
FUJ00122284
The Horizon System
3.
Each counter position in a Post Office branch has a computer terminal, a touch
sensitive visual display unit, a keyboard, barcode scanner and printer. This
individual system records all transactions input by the counter clerk working at
that counter position. Each clerk logs on to the system by using a password
(there is only one). The transactions performed by each clerk, and the associated
cash and stock level information are recorded by the computer system in a stock
unit. Once logged on, any transactions performed by the clerk must be recorded
and entered on the computer and are accounted for within the user's allocated
stock unit. I understand that the Marine Drive branch where Mr Castleton was
the subpostmaster has 2 counter positions whose transactions are combined
together and recorded as 1 shared stock unit (I didn’t know this before, but am
happy to believe that. I could carry out detailed analysis of the data to prove this
if this is required, but have not done so at this time. Perhaps “I understand”
covers that?). This means that all the cash and stock is contained on 1 balance
sheet as opposed to having a separate stock and cash balance for each terminal.
Every time that a new customer is served by a clerk there is a new “session.” The
price for each product is pre-set into Horizon and cannot be entered by the clerk
into the terminal or determined or. controlled by them [presumably this is
correct? Not necessarily. Some products are defined as “open Priced”
which allows the clerk to enter the price at the time. A good example of
an Open Priced product would be if you were paying a utility bill wehre
the price is as written on the bill. A Typical Fixed Price product would be
a 1st class stamp whose price is fixed at the time of sale (but increases
each year!) Not sure how best to reword the point]. The clerk enters the
Product type and quantity (and where relevant price) the customer wishes to
purchase by using the touch sensitive screen or the keyboard. Each customer’s
transactions are recorded in a “stack.” Once the clerk has finished serving a
customer, the stack is cleared. For each session:
(a) the number of transactions is recorded;
(b) settlement occurs i.e consideration such as cash is transferred one way or
the other, into or out of the till; and
(c) the method of payment is recorded. NB there may be multiple methods of
payment for a single transaction
The Horizon system provides a number of daily and weekly records of all
transactions input into it. It enables Post Office users to obtain computer
summaries for individual clients of Post Office Limited e.g. National Savings Bank,
Giro, Driving Licence Agency and Pension and Allowances (not sure that these last
1A_1180744_1 2
FUJ00122284
FUJ00122284
FUJ00122284
FUJ00122284
2 examples are still valid - though they may have been at the time I think these
reports were removed during 2005). The Horizon system also enables the clerk
to produce a weekly balance of cash and stock on hand combined with the other
transactions performed in that accounting period. The system also allows for
information to be transferred to the main accounting department at Chesterfield
in order for the accounts for each branch to be balanced.
6. The Post Office counter processing functions are provided through a series of
counter applications: the Order Book Control Service (OBCS) that ascertains the
validity of Benefit Agency order books before payment is made (Note OBCS
stopped in May 2005); the Electronic Point of Sale Service (EPOSS) that enables
subpostmasters to conduct general retail trade at the counter and sell products on
behalf of their clients; the Automated Payments Service (APS) provides support
for utility companies and others who provide incremental in-payment (also
handles outpayments since April 2006) mechanisms based on the use of cards
and other tokens and the Logistics Feeder Service (LFS) which supports the
management of cash and value stock movements to and from each branch,
principally to minimise cash held overnight in the branches. [Were these the
systems in place in January to March 2004 which is the relevant time for
this case? Yes. I’ve added in comments about changes, but they were since
March 2004 so probably should not be included. Another key service is on-line
Banking which perhaps ought to be mentioned.]. The counter desktop service and
the office platform service on which it runs provides various common functions for
transaction recording and settlement as well as user access control and session
management.
7. Where local reports are required these are accessed from an icon on the desktop
menu. The user is presented with a parameter driven menu, which enables the
report to be customised to requirements. The report is then populated from
transaction data that is held in the local database and is printed out on the tally
roll printer. Some reports come out on a single A4 printer which is present in
each Office - the printer used depends upon the type of report being produced
and is not controlled by the user. The system also allows for information to be
transferred to the main accounting department at Chesterfield in order for the
office accounts to be balanced. This sentence is true. However transfer of data to
Chesterfield was only triggered by the production of one key report known as the
Cash Account, which needed to be produced in the Branch each Wednesday. Is it
worth clarifying that? Also note that this aspect of the system and co-ordination
with Chesterfield changed in August 2005, but is correct for the time of the case.
8. Ihave produced a diagram at page [ ] [Gareth please can you produce a
diagram? I understand that Jan Holmes of Fujitsu has produced one for
1A_1180744_1 3
another P.O case, so he may be able to provide one I’ve asked Brian to
track this down.]. This presents a simplified view of the components of the
Horizon system, which is further explained below.
Five Layer Model
9.
The basic system operates through five different layers:
(a)
(b)
(c)
(d)
(e)
The Counter Layer where the Post Office Counter Clerk conducts the daily
business of the branch, initiating transactions based on customer demands or
responding to system prompts that originate either in support of the
customer’s transactions or from other parts of the system. All transactions for
a Counter in a branch are replicated across all other Counters in that branch.
Examples of transactions include:
i. Cashing a Benefit Book payment foil.
ii. Selling a Post Office retail product.
iii. Accepting full or part payment against a gas, electricity or other utility
bill.
The Correspondence Server Layer where all transactions for all branches are
stored prior to despatch to other systems, including Audit; or from other
systems prior to despatch to the relevant branches. Transactions are stored
in the Correspondence Server Layer for the same length of time as they are
held at the Counter Layer.
The Agent Layer that acts as the interface between the Correspondence
Server and Host Layers. Agents are either Loading Agents, whereby
information is placed onto the Correspondence Server Layer for onward
despatch to the Counter, or Harvesting Agents, whereby transactions are
copied from the Correspondence Server Layer to a variety of other systems,
including Audit. It may be worth also mentioning that the Agent Layer is
responsible for online authorisations (directly with the External Banking
system or Merchant Acquirer) for Banking and Debit card transactions when
these are carried out.
The Host Layer where transactions from external systems are received and
processed prior to presentation to the Agent Layer and subsequent despatch,
or information relating to transactions already carried out is prepared for
despatch back to the external systems.
The External System Layer from where transactions originate that may have
an effect on the branch and the transactions undertaken there, and to where
1A_1180744_1 4
FUJ00122284
FUJ00122284
FUJ00122284
FUJ00122284
details of transactions undertaken at the branch are sent for subsequent
processing by that system. An example of an External System is the
Electronic Stop Notice System (ESNS), a Benefits Agency system that
provides Stop Notices for Benefit Books that have to be applied by the Post
Master if the Books are presented at the Counter.
(Ff
All transactions conducted at the Post Office Counter, whether initiated by a
customer or as part of the system, are written to the transaction log
associated with that Counter. They are replicated across all other Counters in
the branch for resilience purposes. The transactions are sent back to the
branch’s primary Correspondence Server where they are replicated to the
Correspondence Server at the second Data Centre.
Collecting Transaction Data
10. When a transaction record is written to a Correspondence Server a copy of it is
also written to an Audit File located on the Correspondence Server. Each Audit File
accumulates until approximately. 200,000 (not sure about this figure. The
mechanism has changed at some point since originally implemented in 1998
which will affect the file size and exactly how this works. However I don’t belive
the gory details are likely to be relevant.) records are copied at which point the
file is closed and copied to that Data Centre’s Audit Server. A Checksum Seal
value for that Audit File is calculated and the file stored on the Audit Server until
such time as it is copied to Digital ‘ape (It isn’t copied to tape now. It is
held on a slow access Disc system. Again I’m not sure when this changed, but I
think it was before 2004). This activity continues for as long as the
Correspondence Servers are running. (The Checksum Seal is used during
subsequent data retrieval to provide assurance that the data in the Audit File has
not been altered from the point of storage on the Digital Linear Tape.)
Collecting ‘Other’ Audit Data
11. While the Transaction Data is an important element of the Audit Trail it is by no
means the full extent of data collected. Other files, data, records, scheduling
information, events and transactions back to the External Layer (identified by
black squares on diagram GJ/01), are also collected by the Audit Server during
the day.
1A_1180744_1 5
FUJ00122284
FUJ00122284
Hoarding and Storing Audit Data
I’m not very familiar with this part of the system and perhaps am not the person to
provide this level of detail. I’m happy to confirm that the data is passed to the Audit
server (as in para 10) and that it can be retrieved from there during its lifetime. I
think its lifetime is now at least 7 years (and possibly even 15 years) for all
Transactional Data.
12. At 7:00pm each day the job scheduler starts a process known as Hoarding, when
all files collected during the day and resident on the Audit Server are written to
Digital Linear Tape. Files will be written to one of three pools, depending on the
type of file and its associated retention period. The current pools are
TMSi8months, Non-TMS18months and Non-TMS7years [is this correct? What
were the pools in January to March 2004]?. TMS stands for Transaction
Message Store and these are the transaction files copied from the Correspondence
Server. Non-TMS files are the large number of files, in various formats, that have
been collected from other parts of the Horizon system.
Retrieving, Extracting and Analysing Audit Data
Again, I’m not very familiar with the details of this aspect, but it seems about right
(other than references to DLTs)
13. Audit Data is recovered from the Digital Linear Tapes using standard operational
procedures that have been in use since 1999. On retrieval, and before the file is
presented back to the Data Analyst the Checksum Seal value is re-calculated and
compared to the value at the time of the original collection by the Audit Server.
Both TMS and Non-TMS data can be analysed using other tools to isolate records
that meet selection criteria.
Horizon and Time
14. With one exception the Horizon system consistently records time in GMT and
therefore takes no account of Civil Time Displacements. However, there is an
exceptional category of transactions. “Transfer In” events recorded in the
Transaction Logs which are shown in local time and are therefore subject to
changes from GMT to BST and BST to GMT at appropriate points in the year. The
clock incorporated into the desktop application on the counter visual display units
is however configured to indicate local time. This has been the situation at Marine
Drive branch (FAD 213337) since [insert date] when the Horizon system was
introduced at that particular branch.
I agree with the above. Is it necessary to mention that there were other anomalies
prior to 2001 and that this anomaly was fixed during the winter of 2004-5? Also,
since the relevant time period was Jan - March (ie no BST) does this matter?
1A_1180744_1 6
Mr Castleton’s allegations about Horizon
15.
16.
I understand that Mr Castleton’ asserts that no real losses occurred at the Marine
Drive branch, but that the losses were all theoretical and generated on Horizon by
computer error.
The absolutely fundamental point to note is that Post Office branches operate
along double entry accounting principles.
recorded on the Horizon s) here I
No. That is not what is meant by Double Entry accounting and I don’t
believe that that is true. Double Entry accounting means that for every customer
session, there will be a set of transactions recording sales of goods or services
incuding any benefit outpayments and banking withdrawals, together with Method
of Payment transactions representing the way in which “money” (including cash,
cheques, Debit cards etc) were used to settle the session. The sum of all such
transactions will always be zero. All we can show within Horizon is that for all
business transactions that there are corresponding movements of cash and stock
values within the branch. Reconciliation of Horizon to real world bits of paper is a
manual process. Horizon does produce reports on transactions (as stated earlier)
and these reports can be used to reconcile against the paper trail. Some of the
Paper trail is sent to the Central Processing centre (it is EDS now, but I think it
may have been done in Chesterfield in 2004) but not all of it.] If a user makes an
erroneous entry into their computer terminal and the paperwork sent by the
subpostmaster to the EDS Processing Centre did not match the entry made, an
error notice (which is a correction statement) would be generated. Accordingly,
even if Mr Castleton did experience the problems with computers at the branch
below and even if (which I do not accept for the reasons set out below), that
mean that this causes theoretical losses, this would have been picked up when
the information Mr Castleton recorded into his computer did not correspond with
the paperwork he sent each day to the EDS Processing Centre.
Again, I can’t really speak about what paperwork is sent to the Central systems and
what reconciliation cheks are done since that is part of the Post Office Business
and outside Horizon. My understanding is that checks are done on a random
sampling basis rather than in all cases, but if a statement about this aspect of the
system is required it should be provided by POL staff.
I have the following comments on each of his particular allegations:
The two computer terminals did not communicate with each other properly
1A_1180744_1 7
FUJ00122284
FUJ00122284
Gareth do you have/can you obtain any data to show whether the two
computer terminals did not communicate with each other properly?
I can’t explicitly do that. However a check is made each evening that the two counters
are talking to each other at that time, and if they are not talking to each other,
then that day’s data is not marked for processing that day. The Central systems
would “catch up” when they are back in communication. The Audit Trail would
have details of what happened at each “End of Day” point and I could check from
that whether they were in communication when EOD occurred each night, but that
is not in the data extract that I’ve looked at to date. Also, if the counters were
not communicating, then there should have been calls raised by the Branch to the
Help Desk and I believe that Anne has provided you with the Call logs. Similarly,
if the counters weren’t communicating, then online banking would not be available
from the “slave” counter.
17. Only one computer terminal (known as the gateway node) is connected to the
Correspondence Server. If the two computer terminals in the branch are not
communicating properly this should be clear to the clerk because a message will
appear on screen [what will it say? I'll need to investigate the details.
However at a high level there is the following:
« There should be a yellow band at the bottom of the screen waring
that online transactions are not available
¢ A number of functions will be marked as unavailable on the “slave”
system and attempted use of these on the gateway system will
result in warnings
« Branch Balancing etc is certainly restricted in this way
« EOD will not work (as described above)
]. However, irrespective of whether the two computer terminals are communicating,
every transaction is committed immediately to the hard drive of the local terminal
upon which it is performed (is this the Counter Layer? Yes) so it is not lost.
18. At approximately 6.00pm each day [or each working day? Each day. The
algorithm at that time was slightly more complicated. It is:
« Has the Branch got a configured “closing time” for this day of the week?
o If not, EOD is 7pm
« Is the configured closing time earlier than 6:30pm?
o Ifnot, EOD is 7pm
« EOD is 30 mins after configured closing time
Given that most branches have a closing time of 5:30, then this means 6pm on
normal days, but early closing (often Wednesday and Saturday) will be earlier and
Sunday is often 7pm. However this detail is probablyt irrelevant.
] the system runs through a process of checking that the computer terminals are
communicating with each other. A report is automatically generated if they are
not communicating with each other. [Is the report produced if they are not
1A_1180744_1 8
FUJ00122284
FUJ00122284
communicating at 6pm OR if they have not been communicating during
that day? It is purely if they are not communicating at EOD. Note that this is a
central report and so is not visible to the subpostmaster. Also this report incudes
systems which have no communication with the centre at EOD as well as those
with dead / non communicating counters.]. Once the communication between
terminals is re-established, they automatically catch up with each other and in
turn, the gateway node will automatically update the Correspondence Server.
This means that no data is lost. It is therefore irrelevant whether from time to
time the two terminals did not communicate with each other.
Computer screen freezing
Gareth, other than calls into HSH, do you have/could you obtain any data
to show whether the computer screen was frequently freezing?
Sorry, but I can’t help with this.
19. If the screen at a terminal freezes i.e locks up or fails to respond and has to be
re-booted, it will either record the whole of the session or (more likely) none of it.
It will not record just part of a session. Once the terminal comes back online, it
will tell the clerk at what stage the transaction was at and give the clerk specific
prompts by asking what has happened. For example, the clerk will either be 20
stamps down and the money should be in the till or the 20 stamps will still be
there. It is therefore clear to the clerk whether they need to re-enter the data for
the session that was in progress when the PC crashed. The clerk can also tell
what has happened by going through the transaction log [what do you mean by
this? One of the reports that can be produced from the system is a “transaction
log” which shows all transactions carried out within given criteria (for example all
carried out today between 10:00 and 10:30)]
Blank computer screen
20. If one or other of the terminals goes blank, then the clerk will not be able to
process a transaction during this time. This should therefore be irrelevant and it
is not apparent how this would cause an actual or theoretical loss.
Barcode Card swipe not reading
21. I understand that subpostmasters are told to clean the barcode card swipe
machine regularly to ensure that it works properly. (First I’ve heard of this, but it
seems sensible) If the card swipe machine at a terminal does not read after 3
attempts then this will be clear to the clerk and if the customer is using a debit
card (not just Debit cards. Any other swiped transaction can be manually
entered), the clerk would be able to manually type in the card number, thereby
1A_1180744_1 9
FUJ00122284
FUJ00122284
22.
allowing the transaction to proceed. No money or information will therefore be
lost.
I understand that Mr Castleton asserts that during the period in question the
swipe machine failed regularly. If that had been the case, I would have expected
to have seen numerous calls logged to HSH complaining about this issue, but no
St is are logged. I’ve not looked at the call log, so I’m not sure I can say
Rolling over cash figures - ONCH
23.
24,
ONCH is a report which subpostmasters should print last thing each working day.
It is how the postmaster declares the quantity of cash in the tills overnight and
stands for Overnight cash holding (not, as Mr Castleton asserts, On Hand Cash
Handling). If the subpostmaster fails to print it at the end of each day (ONCH is
actually a process for declaring Cash. Having completed the process, there is an
option to print the report. It is the failure to carry out the process that is
checked, not the fact that the report was printed. As far as Horizon is concerned
there is no need to print the report - just to Declare the cash holding.), the
system will prompt him to do so when he logs.on the next morning. Mr Castleton
states that during cash week 48, (the week ending 25 February 2004) he first
became aware that he was able to print the ONCH report, but that when his
assistant printed it, it appeared to produce a figure that was 4 to 5 times greater
than the actual cash declaration for the day. I think there may be some confusion
here. In addition to the report that can be produced when making the cash
declaration, I belvie that there used to be a report that would provide the weekly
summary figures for all cash declarations done during the current week. I think it
is this latter report that is being referred to in Mr Castleton’s statement.
When printing the ONCH, the clerk is asked to enter a declaration identification
number. They usually enter the same number every day and the same number
ought to be used throughout the branch irrespective of which terminal is used, [is
this because the terminals together form 1 stock unit? Unfortunately it is
rather more complicated than this and depends on exactly how the
branch chooses to operate.
The purpose of a “Declaration ID” is to allow each terminal in a branch to
have separate cash drawers and for each terminal user to declare the
amount of cash in their drawer. The system can then add up these
separate cash declarations to come up with a total amount of cash within
the stock Unit.
1A_1180744_1 10
FUJ00122284
FUJ00122284
However it is also possible to either have a shared cash drawer between the
two tills and thus only make a single cash declaration or to add up all the
cash in separate physical drawers and make a single cash declaration.
All Horizon will do is take the latest declaration for every Declaration Id that
1.
25.
yp
has been used and add them together. As part of the Balancing Process a
list of declaration Ids used (incuding the User, Date, Time and Terminal
at which they were made) is presented to the subpostmaster so that they
can ensure that the correct declarations have been made.
If the clerks mistakenly use separate identification numbers for each terminal, the
system will add the 2 terminals’ figures together. This would explain why the
ONCH figures could have been greater than the actual cash declaration for the
day.
The system uses the ONCH figure to predict how much cash the. branch will need
to service its transactions. However, before cash is released the system will
notify the subpostmaster the amount which it plans to send [how does this
work I can provide a rough indication for your information, but if you want a
statement to cover this you need to get it from Post Office:
« Horizon passes the ONCH figures to Post Office each night
* Post Office’s Cash Planning system uses this, together with Historical data
about cash usage to forcast future cash requirements for each branch
« Cash Planning then produces a “Planned Order” indicating the cash
planned to be sent to a branch in a few days time and sends this to the
branch via Horizon. NB this is just a textual report and all Horizon does is
distribute it to the branch and provide facilities to read and print the report
« If the sibpostmaster is not happy with this, then they phone the cash
centre and ask for it to be changed
* The Cash Centre then despatches cash to the Branch and when it is
received Horizon has functionality to Remit the cash in, which are in effect
transactions that record that the cash is now on the Branch’s “Balance
Sheet”.
As you can see most of this is outside Horizon.
Gareth if Mr Castleton doubled up on the ONCH figures, would the system
think he needed more cash than he did in reality or less cash than he did
in reality need? I assume that it would think he needed less since it
would think he had more than he actually had. Again need POL to
provide a statement on this. However, if the subpostmaster considers that the
proposed amount of cash will either be too great or insufficient, he can telephone
NBSC??? (I think it is the cash centre - ask POL) and ask for this to be corrected.
[Will he then only be sent what cash he asks for? Not sure who gets the
final vote - ask POL. I assume if he asks for less then he'll get less, but if he asks
for more they may want to know why!]
1A_1180744_1 it
FUJ00122284
FUJ00122284
26. If the clerk has mistakenly used separate identification numbers for each terminal
causing the 2 terminals figures to be added together and the ONCH report to be
wrong, but this will not affect the actual amount of cash that the branch has at
that point in time (not sure about the English in this sentence). Each week the
subpostmaster is required to balance the stock unit. This requires him to
physically count the actually cash and stock that he has at the branch and to
declare that in the Final Cash Account for that week which he will sign off as being
accurate [will he keep this and or send it to Chesterfield? Both. There are
two copies of the Final Cash Account printed - one for the branch and one to be
This is too strong. As part of the Balancing process a similar cash
Declaration is done using Declaration Ids exactly like the ONCH declarations. In
2004, these were separate independent declarations, but in 2005 they were
merged to use exactly the same process for both ONCH and Balancing
declarations. As part of balancing all Declarations with separate IDs are taken
and added up and then compared with the System Generated Cash figure which is
produced by analysing all transactions within the cash account period. Any
Difference is highlighted to the subpostmaster as a “Discrepancy” which if the
accept, will adjust the system cash figure to match the amount of cash that has
been declared by the subpostmaster. Therefore if he has “double declared his
cash” and accepts the resulting discrepancy, the system cash figure will be
adjusted to reflect this. I suspect that this may be what has happened. However
it is still Mr Castleton’s responsibility to spot this and not to accept the (false)
discrepancy when he is balancing the system.
Lost transactions
27. Mr Castleton asserts that Horizon failed to record transactions which he knew he
had entered into the Horizon system. For example, if he entered a cheque on to
the system as a cheque, it would allegedly not appear identified as a cheque.
It is very difficult to rprove or disprove this assertion. All that can be done is to look at
what is recorded on the transaction log for any particular time. It is up to the
user to indicate whether Cash or Cheque is sued as a MOP and the system totals
of each will be adjusted appropriately.
28. The system keeps a running total of cash and cheques on hand. The
subpostmaster is responsible for printing off the cheque report which is usually
done at about 4pm each day (called the Cheque listing) and for physically
1A_1180744_1 12
FUJ00122284
FUJ00122284
29,
30.
corroborating that the cheques are there. If he physically has an additional
cheque that does not show on the cheque report but he has instead recorded as
cash, he is able to make an adjustment from cash to cheque.
Once the cheque report is printed, the subpostmasters send it each day with the
cheques to the EDS Processing Centre. (As stated earlier it is EDS now, but I
think it was Chesterfield in 2004. This parr of the process is really Post Office’s
responsibility not mine so I don’t think that detail is really part of my statement.)
The system will then show that the amount of cheques held by the branch is
to pick up that he has
ing th leques and the
ts (I've no idea what
report is
happens about mismatches in the cheque processing. I would assume that there
is a check that the physical cheques match the report and some process for
reconciling mismatches, but I’ve no idea what this process is. Similarly there
needs to be a process for “bounced cheques”, but again I don’t know what it is.)
Each cheque is attributable to a particular branch because details of the
transactions should be recorded [by the subpostmaster? Yes - again a manual
process Also I understand that the cheques and the report are sent together to
the cheque centre, so it should be clear where each chequer has come from since
the branch details are on the report. Again I am speculating.] on the back of the
cheque. Accordingly, if the cheque is erroneously declared on the system as
being cash this will be picked up. However, once it has been picked up it will
make no overall difference to the balance at the branch because fundamentally
payment will have been received from the customer for the transaction whether it
is recorded as being by cash or by cheque.
[Gareth, imagine Castleton mistakenly records a cheque as being cash on
the terminal. The terminal communicates the fact that cash has been
received to the Correspondence Server Layer each day and the terminal’s
hard drive is cleared to zero. [Not sure what you mean by “hard drive is
cleared to zero”. When cheques are listed, they are then Remitted out of
the system which results in the value being removed from the branch
(and ultimately credited to the cheque processing system). Nothing is
actually cleared to zero — just more transactionsa re recorded with the
opposite sign meaning that the total value on hand will be zero.] After
this, at the end of the day Castleton realises he’s missed a cheque so he
manually adds the cheque on to his physical report before submitting it.
(What do you mean by “manually adds”? If you mean writes it on with a
Pen, then I would hope that the central system would spot this and reject
such an amendment. Any adjustment made in the branch should result in
a new report being produced with the correct set of cheques. NB it is just
1A_1180744_1 13
FUJ00122284
FUJ00122284
the values of the cheques that are recorded so having 10 cheques for
£170 tax disc sales (for example) doesn’t distringuish between them)
Will the system now believe that the branch has both cash and cheque i.e
more money than it does? How would this be picked up? Not sure that
this is relevant given the explanation above.] In any event, this would be
reflected at the end of the week as an imbalance of stock or cash because if Mr
Castleton had only sold 1 item, but erroneously inputted into the terminal that he
has been paid both in cash and cheque, he will still have the physical stock at the
branch because he will only have sold it once. In particular, he can only record
either cash or cheque but not both. Any adjustment to the value of cheques
automatically adjusts the value of cash that the system believes to be there. It
can’t count it twice.
Software updates
31.
32.
33.
34,
I understand that Mr Castleton alleges that the Horizon system went offline on
one occasion, that this happens during software updates and that it could have
caused the losses in question.
A software update could result in a desktop being closed and restarted. However,
they are relatively rare and (unless prior agreement is reached with the
subpostmaster) tend only to take place outside of office hours when the
subpostmaster is not using his computer. However, even then I do not believe
that this could result in Horizon causing losses. At pages [ ] are
spreadsheets showing all of the updates for the period January to April 2004 at
the Marines Drive branch. I assume that you are referring to the separate
spreadsheet attached to the email. I’m not sure that I am really qualified to
describe what that says. My guess is that the only potentially “dodgy” activities
are on 2/2/2004 where there was a lot of activity on Counter 2 at 14:19 on what I
think was a Monday. I think I agree with the following analysis, but don’t feel
qualified to attest to it.
In the product column of the attached spreadsheet, I = in store, D = delete, U =
update. Counter one shows that there were no updates between 8.30am and
5.30pm over the period. Counter two shows (with the exception on 2 February)
there were no updates between 8.58am and 10.06pm over the period in question.
On 2 February there were 24 instances of IUD at 2.09pm and 1 instance at
2.10pm, which indicates a process (lasting 1 minute) starting at 2.09pm and
completing at 2.10pm. This is due probably to a counter installation that would
have been with the subpostmaster’s knowledge and consent.
1A_1180744_1 14
FUJ00122284
FUJ00122284
Balance snapshots
35.
36.
A balance snapshot is a printout showing in real time, what balance of what cash
and stock it believes the branch should have, not necessarily what cash the
branch actually does have. It looks at the previous week’s declared cash and
stock and adjusts items as they are sold, so if a clerk forgets to enter an item that
a customer has purchased, the balance snapshot will be inaccurate. Effectively,
the balance snapshot is just a rough tool to allow the subpostmaster to quickly
check transactions through the week. It is not mandatory for a subpostmaster to
print out a balance snapshot. It is not the same as a Final Cash Account.
I am advised that Mr Castleton believes the Horizon system “double counted”
losses because it allegedly failed to recognise the transfer of the money over from
the daily snapshot into the suspense account.
(a) On day 2 of week 49 (27 February 2004), an entry for £3,509.68 is shown as
“loss to A” (Gareth this is document 3),
(b) An Office Copy of the suspense account dated 3 March 2004 states “cash
shortages 27/02/04 loss A to table A £3,509.68”" (Gareth this is document
4).
(c) Mr Castleton then states that the net discrepancy of £3,509.68 is still showing
in the balance snapshot dated 27 February 2004 and the Final Balance dated
4 March 2004 (Gareth these are documents 5 and 6) after it was
purportedly transferred into the suspense account.
I will need to cary a more detailed analysis to explain exactly what is going on here.
37.
The simple reason why the net discrepancy is still showing on the balance
snapshot report after it was transferred into the suspense account is that the
balance snapshot will not (and should not) show the transfer until after the
subpostmaster performs a trial balance [Gareth presumably a trial balance is
different to a Final Balance, because the Final Balance dated 4 March (doc
6) does not show the transfer]. The Horizon system is therefore not “double
counting” losses.
What I can tell is that docs 3, 5 and 6 are incomplete. Doc 3 is the second part of a
report, while docs 5 and 6 are the first part of a report.
The other think is that there is a confusion between what belongs to the Stock Unit
and what belongs to the Branch. The Balance reports (snapshots and final balances)
are at a Stock Unit level, while the Cash Account report covers all Stock Units (OK I
accept for now that there is only one - but I’ve not examined the detail) plus details of
the Suspense Account (Doc 4). Posting items to suspense should adjust the cash
position in the SU and move the “problem” into the Suspense Account. Horizon allows
1A_1180744_1 15
FUJ00122284
FUJ00122284
FUJ00122284
FUJ00122284
this to happen at any time and analysis of the actual transactions can show what has
gone on. However I understand that POL Processes require “permission” to be
obtained before posting to Suspense and this is visible on the Cash Account report
which I belive is something that was checked in Chesterfield (again need POL to define
their processes).
Conclusion
38. There are no grounds for believing that the problems Mr Castleton says he
experienced with his computer would have caused either theoretical or real losses.
However even if the computer did causes losses to be shown on Horizon (which I
do not accept), and/or Mr Castleton had erroneously entered information on the
system this would have been picked up when the paperwork he sent to the EDS
Processing Centre each day did not correspond with what was on the system and
an error notice would have been generated.
Not sure that I can agree to this without looking more closely at what has gone on.
I believe that the facts stated in this witness statement are true.
Signed 00... veseeeeeee
GARETH JENKINS
Date occ
1A_1180744_1 16
1A_1180744_1
FUJ00122284
FUJ00122284
Filed on behalf of the: Claimant
Witness: Gareth Jenkins
Statement: 1
Exhibits: "Gu."
Date made: 2/8/06
IN THE HIGH COURT OF JUSTICE
QUEENS BENCH DIVISION
BETWEEN:
POST OFFICE LIMITED
-and-
LEE CASTLETON
WITNESS STATEMENT OF GARETH
JENKINS
BOND PEARCE LLP
Ballard House
West Hoe Road
Solicitors for the Claimant/Part 20
Defendant
Claim No. HQO5X02706
Claimant/Part 20
Defendant
Defendant/Part 20
Claimant
FUJ00122284
FUJ00122284
Filed on behalf of the: Claimant
Witness G Jenkins
Statement: 1
Exhibits: "oi"
Date made: 2/08/06
IN THE HIGH COURT OF JUSTICE Claim No.
QUEENS BENCH DIVISION
BETWEEN:
POST OFFICE LIMITED Claimant
- and -
LEE CASTLETON Defendant
EXHIBIT "GJ1i"
This is the Exhibit marked “GJ1” referred to in the Witness Statement of Gareth
Jenkins dated August 2006.
1A_1180744_1