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
20 Claimant
WITNESS STATEMENT OF GARETH JENKINS
I, GARETH JENKINS of Fujitsu Services, Lovelace Road, Bracknell, Berkshire, RG12
8SN WILL SAY AS FOLLOWS:
1.
I am a Distinguished Engineer employed by Fujitsu. I have worked for Fujitsu
since [insert date]. 1 am responsible for [insert details]. 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).
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.
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 series of
passwords. The transactions performed by each clerk, and the associated cash
and stock level information are recorded by the computer system in a stock unit.
1A_1180744_1 1
FUJ00122280
FUJ00122280
FUJ00122280
FUJ00122280
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 am 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. 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.
4, 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?]. The clerk enters the product type and quantity 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.
5. 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 Counters Limited e.g. National
Savings Bank, Giro, Driving Licence Agency and Pension and Allowances. 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; 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 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
1A_1180744_1 2
FUJ00122280
FUJ00122280
this case?]. 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. 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.
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
another P.O case, so she may be able to provide one]. 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) 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.
(b) The Correspondence 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 Layer for the same length of time as they are held at the
Counter Layer.
(c) The Agent Layer that acts as the interface between the Correspondence and
Host Layers. Agents are either Loading Agents, whereby information is
placed onto the Correspondence Layer for onward despatch to the Counter,
1A_1180744_1 3
or Harvesting Agents, whereby transactions are copied from the
Correspondence Layer to a variety of other systems, including Audit.
(d) 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.
(e) The External System Layer from where transactions originate that may have
an effect on the branch and the transactions undertaken there, and to where
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.
(f) 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
branches 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 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 Linear Tape. 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 4
FUJ00122280
FUJ00122280
FUJ00122280
FUJ00122280
Hoarding and Storing Audit 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
TMS18months, Non-TMS1i8months 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
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.
Mr Castleton’s allegations about Horizon
15. 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.
1A_1180744_1 5
16.
The absolutely fundamental point to note is that Post Office branches operate
along double entry accounting principles. This means that for every transaction
recorded on the Horizon system, there is a corresponding physical document (for
example, a cheque, giro deposit or withdrawal slip or savings bank withdrawal or
deposit slip) that the subpostmaster has to send each day to the EDS Processing
Centre. 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.
I have the following comments on each of his particular allegations:
The two computer terminals did not communicate with each other properly
17.
18.
Gareth do you have/can you obtain any data to show whether the two
computer terminals did not communicate with each other properly?
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?]. 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?) so it is not lost.
At approximately 6.00pm each day [or each working day?] 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
communicating at 6pm OR if they have not been communicating during
that day?]. 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
1A_1180744_1 6
FUJ00122280
FUJ00122280
19.
Gareth, other than calls into HSH, do you have/could you obtain any data
to show whether the computer screen was frequently freezing?
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 audit trail [what do you mean by
this?]
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.
22.
I understand that subpostmasters are told to clean the barcode card swipe
machine regularly to ensure that it works properly. 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, the clerk would be able to manually type in the
card number, thereby 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
such calls are logged.
Rolling over cash figures - ONCH
23.
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, the
system will prompt him to do so when he logs on the next morning. Mr Castleton
1A_1180744_1 7
FUJ00122280
FUJ00122280
24.
25.
26.
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.
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?]. 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]? 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? However, if the subpostmaster considers that the
proposed amount of cash will either be too great or insufficient, he can telephone
NBSC??? and ask for this to be corrected. [Will he then only be sent what
cash he asks for?)
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. 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?]. The Final Cash Account is entirely separate from and has
nothing to do with the ONCH report. The figures in the ONCH report are not
added to the balance in the Final Cash Account. It is therefore completely
irrelevant whether the subpostmaster or his assistant got the ONCH report wrong:
it would not and could not cause a computer generated imaginary loss or an
actual loss.
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.
1A_1180744_1 8
FUJ00122280
FUJ00122280
28.
29,
30.
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
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. The system will then show that the
amount of cheques held by the branch is reduced to zero. If however, the
subpostmaster fails to pick up that he has erroneously recorded a cheque as cash
when submitting the cheques and the report, the cheque will be returned by the
clearing system. Each cheque is attributable to a particular branch because
details of the transactions should be recorded [by the subpostmaster?] 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 Layer each day and the terminal’s hard
drive is cleared to 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. 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?] 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.
Software updates
31.
32.
1 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 and could result in a desktop being closed and restarted.
However, they are relatively rare and (unless prior agreement is reached with the
1A_1180744_1 9
FUJ00122280
FUJ00122280
33.
34.
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.
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.
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.
1A_1180744_1 10
FUJ00122280
FUJ00122280
FUJ00122280
FUJ00122280
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.
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 the 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.
I believe that the facts stated in this witness statement are true.
Signed
GARETH JENKINS
Date ..
1A_1180744_1 it
FUJ00122280
FUJ00122280
Filed on behalf of the: Claimant
Witness: Gareth Jenkins
Statement: 1
Exhibits: "Gut"
Date made: 2/8/06
Claim No. HQO5X02706
IN THE HIGH COURT OF JUSTICE
QUEENS BENCH DIVISION
BETWEEN:
POST OFFICE LIMITED Claimant/Part 20
Defendant
-and-
LEE CASTLETON Defendant/Part 20
Claimant
WITNESS STATEMENT OF GARETH
JENKINS
BOND PEARCE LLP
Ballard House
West Hoe Road
“BX 8257 Plymouth
Ref: SJD3.348035.134
Solicitors for the Claimant/Part 20
Defendant
1A_1180744_1
FUJ00122280
FUJ00122280
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