Вы находитесь на странице: 1из 24

CASE NUMBER 1HQ16X01238

ALAN BATES & OTHERS [CLAIMANT]

POST OFFICE LIMITED [DEFENDANT]

JOINT STATEMENT OF

JASON COYNE

AND

DR ROBERT WORDEN

04 SEPTEMBER 2018

D1/1/1
1. Introduction
1.1 This document is centred around the Horizon issues and seeks to set
out the areas where experts agree and/or disagree and their reasons
for doing so.

1.2 The experts wish to set out first an overall framework for this document.
Because the experts may agree or not agree about parts of that
framework, it is addressed in a manner similar to the other issues, as if
it were 'Horizon Issue 0'.

Issue 0 - Approach to the Expert Reports, and to This Joint


Memorandum

Areas of Agreement

The experts agree some grouping of the Horizon issues but have chosen
different detailed groupings.

Jason Coyne Dr Worden

Bugs/Errors/Defects and Controls Bugs in Horizon which could


affect branch accounts.
Issues 1, 3, 4 & 6
Issues 1, 3, 4 and 6

Reconciliation and Transaction Reconciliation and Transaction


Corrections Corrections

Issues 5 & 15 Issues 5 and 15

Horizon Reporting - Facilities for Facilities available to


Subpostmasters Subpostmasters

Issues 2 & 14 Issues 2, 9 and 14

Horizon Shortfalls - Data and Facilities available to Post Office


Reporting for Subpostmasters and
Issues 7, 8, 10, 11, 12, and 13
Post Office

Issues 8 & 9

D1/1/2
Remote Access and Transaction
Amendments

Issues 7, 10, 11, 12 and 13

Each expert's approach to writing his report, and to this joint memorandum
which foreshadows their reports, could broadly be one of three possible
approaches:

a) To focus mainly on negative points found in the disclosed documents


about where Horizon may have fallen short.

b) To focus mainly on those aspects of Horizon which were intended to


achieve robustness and reliability, and the evidence implying that they
succeeded.

c) To provide the court with a clear foundation for understanding the


design and operation of Horizon; then, building on that foundation, to
provide a balanced assessment of the ways in which Horizon
succeeded, whilst addressing any disclosed issues where Horizon may
have fallen short.

On some issues, highlighted below, the experts have not been able to agree
because one or other expert is awaiting clarifications. The experts agree
that after clarification it may be worth meeting again to see if they can
reach more agreement.

Areas of Disagreement

Jason Coyne:

In my opinion the technical issues can be answered without reference to the


Claimants high level allegations document. The issues are about how Horizon
and its interactive components operated and the processes employed by Post
Office and Fujitsu in supporting these systems and the data within.

Whilst my report will take a balanced approach, it is the case that many of
the issues require a deep focus on the occurrences of bugs, errors and defects

D1/1/3
as well as the potential for modification of transactional data. Whilst context
will be provided as to how Horizon should work in typical circumstances, it is
the non-typical operation where focus will be placed.

Dr Worden:

I intend to take the balanced approach (c).

To provide a joint statement at this stage which will be useful to the court,
under each Horizon issue the experts need first to agree what is worth
agreeing having regard to the case which is being alleged. For instance, it
would not help the court for the experts to list a number of detailed points as
agreed, if one or the other expert thinks that those points are irrelevant or
unimportant to the case alleged; or if collectively the points imply a view
which, in the opinion of either expert, is not a balanced view. Therefore, the
areas of agreement may at this stage be limited and more high level.

My approach will also focus on the Horizon system. It will consider Horizon
within its wider business context, but I do not believe that the Horizon issues
extend to offering any opinion on the wider business practices of Post Office.

2. Issues and Position


2.1 Issue 1

Issue 1 - To what extent was it possible or likely for bugs, errors or


defects of the nature alleged at §§23 and 24 of the GPOC and referred {C3/1/8-9}
{C3/3/20-25}
to in §§ 49 to 56 of the Generic Defence to have the potential to (a)
cause apparent or alleged discrepancies or shortfalls relating to
Subpostmasters’ branch accounts or transactions, or (b) undermine
the reliability of Horizon accurately to process and to record
transactions as alleged at §24.1 GPOC? {C3/1/8}

Areas of Agreement:

D1/1/4
Evidence exists that that bugs/errors/defects have caused actual
discrepancies or shortfalls relating to Subpostmasters’ branch
accounts/transactions.

Each time any IT system (including Horizon) is changed there is the


potential to introduce new bugs/errors/defects.

Once bugs/errors/defects are discovered, they take time to resolve and


therefore systems such as Horizon often continue to operate with
bugs/errors/defects with or without workarounds in place.

Theoretically, bugs/errors/defects that existed within Horizon have the


potential to cause apparent or alleged discrepancies or shortfalls in relating
to Subpostmasters’ branch accounts/transactions.

In the event that any specific bug/error/defect had such an effect, the
experts have differing views as to the ‘extent’ of the impact that such
bugs/errors/defects may have had on branch accounts.

Areas of Disagreement

Jason Coyne: As identified by select Known Error Logs (KELs), many


thousands of bugs/errors and defects occurred and many of these known
errors had impacts that recurred in different circumstances, therefore the
reliability of Horizon to accurately process and record transactions is
questionable.

Such facts undermine the reliability of Horizon to accurately process and


record transactions.

Examples:

(i) the Calendar Square/Falkirk bug – which led to Horizon failing to


recognise transfers between different stock units, thereby affecting Branch
accounts;

(ii) the Payments Mismatch defect – which affected at least 62 branches


and was related to the process of moving discrepancies into the local
suspense account, thereby affecting Branch accounts. This defect was not

D1/1/5
capable of being identified by Subpostmasters, who would have believed
from Horizon that their account was balanced when it was not; and

(iii) the Suspense Account bug – which erroneously replicated suspense


account items for 14 branches from 2010 in the same monthly trading
periods in 2011 and 2012, thereby affecting Branch accounts.

In my opinion there is possibility of bugs/errors/defects existing in Horizon


that have not yet been discovered. Further, most bugs/errors/defects that
exist in Horizon have existed for extended periods of time before they were
discovered.

I understand that Horizon had at least 19,842 ‘releases’ of new software, each
one of these could have introduced new bugs/errors/defects.

Dr Worden: My current preliminary view is that undetected


bugs/errors/defects in Horizon were very unlikely to be the cause of
permanent shortfalls or discrepancies in a branch's accounts.

It is necessary to define measures for the 'extent' of issue 1. At least two


measures are possible: the number of such bugs and errors, and their net
expected financial impact on claimants' branch accounts, compared to the
total shortfall experienced by all claimants, which is of the order of £18
million. I intend to assess both measures. The latter measure may be more
useful, because if any set of bugs has expected financial impact much less
than £18M, it can do little to account for the claimants' shortfalls, either
collectively or individually.

I propose to assess these measures from a number of different sources of


information: (a) the defects of Horizon cited by the claimants in para 1.3 of
the outline; (b) the KELs identified by the claimants in para 1.4 of the outline;
(c) other KELs; (d) data on their shortfalls provided by the claimants in their
schedules of information; and (e) data from other sources (if available).

I am still scoping the data needed for (e). If it is available, I will provide it to
Mr Coyne as soon as I have it.

My preliminary analyses of the data on (a) - (d) imply that:

D1/1/6
• For the majority of KELs, (which record known bugs), it can be shown,
from an understanding of the robustness measures built into Horizon
or otherwise, that they would have no permanent impact on branch
accounts.

• The net financial impact on claimants' branch accounts of any other


bugs, including undiscovered bugs, is very small compared to the
claimants' total shortfalls. I am not yet able to quantify this, but I
intend to do so.

2.2 Issue 2

Issue 2 - Did the Horizon IT system itself alert Subpostmasters of


such bugs, errors or defects as described in (1) above and if so how.

Areas of Agreement:

The extent to which any IT system can automatically alert its users to bugs
within the system itself is necessarily limited.

While Horizon has automated checks which would detect certain bugs, there
are types of bugs which would not be detected by such checks,

Areas of Disagreement

Jason Coyne: It is stated by Post Office that in respect of the “Local


Suspense Account” issue, Subpostmasters were notified. How they were
notified has not been set out by Post Office Limited. Further, in respect of the
“Receipts and Payments Mismatch” issue, Post Office has also not been able
to identify or confirm whether Subpostmasters were notified.

Whilst alerts of potential errors at the Counter level might be presented on


screen to the Subpostmaster, this would not provide information on the
further possible effects of the error occurrence in relation to its impact on the
branch accounts. Nor would it provide information on whether its occurrence
was as a result of a bug and/or defect within Horizon.

D1/1/7
Dr Worden: In common with most IT systems, Horizon generates messages
to report the occurrence of certain errors to users and operators. Error
messages displayed on the counter screen or presented on reports alert
subpostmasters to conditions that may indicate the presence of bugs or other
defects as described in issue 1. For the avoidance of doubt, I do not believe
that this question extends to whether Post Office notified Subpostmasters
about errors as an operational practice.

There are automated checks in Horizon which would detect certain bugs, and
alert subpostmasters to them (e.g. a non-balancing basket, caused by some
bug in counter software, would be rejected by BAL/BRDB, giving a message
to the subpostmaster)

2.3 Issue 3

Issue 3 - To what extent and in what respects is the Horizon System


“robust” and extremely unlikely to be the cause of shortfalls in
branches?

Areas of Agreement:

There are different dimensions of robustness, such as robustness against


hardware failure, software defects and user error. The robustness of the
system also depends on the processes around it.

Robustness does not mean perfection; but that the consequences of


imperfection must be managed appropriately. If the extent of imperfection is
too high, this would be very difficult to do which would imply less robustness.

Horizon has evolved since its inception. Therefore, its robustness may have
varied throughout its lifetime. The level of robustness may have increased or
decreased as the system was changed.

The existence of branch shortfalls is agreed. The experts do not agree at this
point as to whether this indicates any lack of robustness.

Areas of Disagreement

D1/1/8
Jason Coyne:

For the purposes of addressing the robustness of Horizon, I have applied the
following definition of robustness:

“The ability to withstand or overcome adverse conditions, namely,


the ability of a system to perform correctly in any scenario, including
where invalid inputs are introduced, with effective error handling.”

In consideration of the likelihood of Horizon to be the cause of shortfalls in


branches, Horizon is not determined to be robust in this regard because:

(a) it contained high levels of bugs, errors and defects as set out under
Issue 1 above which created discrepancies in the branch accounts of
Subpostmasters;

(b) it suffered failures of internal mechanisms which were intended to


ensure integrity of data;

(c) the system did not enable such discrepancies to be detected, accurately
identified and/or recorded either reliably, consistently or at all;

(d) the system did not reliably identify ‘Mis-keying’, which is inevitable in
any system with user input, and did not reliably have in place functionality
to restrict users from progressing a mis-key;

(e) it required numerous processes and workarounds to be in place to allow


Fujitsu to modify data already recorded by Horizon, which would not be
required in a “robust” system; and/or

(f) there were weaknesses and risks of errors and other sources of
unreliability within Horizon.

Dr Worden:

The definition of 'robust' proposed above by Mr Coyne is not adequate, for


reasons given below. The term 'robust' is not, as implied in para 3.1 of the
outline, either ill-defined or a piece of IT public relations. Robustness (which
is closely related to resilience) is an engineering objective, and large parts of
project budgets are devoted to achieving it. It receives its meaning in the
phrase 'robust against... [some risk or threat]', and there are a large number
of risks that business IT systems need to be robust against - such as hardware

D1/1/9
failures, communications failures, power cuts, disasters, user errors or fraud.
These are the dimensions of robustness.

In all these dimensions, robustness does not mean 'be perfect'; it means
'address the risks of being imperfect'. The extent of robustness is to be
interpreted as: in how many dimensions was Horizon robust? and: in each
dimension, how large were the remaining risks?

In my report I shall survey the evidence I have found that Fujitsu paid
sufficient attention to the dimensions of robustness, and that they did so
successfully. I shall also address evidence from Mr Coyne implying that
Horizon fell short of its robustness objectives.

In my current preliminary opinion, Horizon is a highly robust system, and this


has important implications for the other Horizon issues, notably issue 1.

2.4 Issue 4

Issue 4 - To what extent has there been potential for errors in data
recorded within Horizon to arise in (a) data entry, (b) transfer or (c)
processing of data in Horizon?

Areas of Agreement: There are a number of actual reported errors in data


recorded within Horizon arising from (a) data entry, (b) transfer or (c)
processing of data. Therefore, the potential exists. The experts do not agree
as to its ‘extent’.

Areas of Disagreement

Jason Coyne: Extent of errors in data will be advanced in my report.

Dr Worden: This issue is a subset of issue 3, focusing on the specific risks of


data entry, transfer and processing. Robustness in these dimensions does
not require Horizon to be perfect; but the risk of imperfection must be
managed appropriately. In my current preliminary opinion, specific measures
to achieve robustness in these dimensions were successfully built into

D1/1/10
Horizon. Because of those measures, errors of data entry, transfer and
processing were very unlikely to affect branch accounts.

2.5 Issue 5

Issue 5 - How, if at all, does the Horizon system itself compare


transaction data recorded by Horizon against transaction data from
sources outside of Horizon?

Areas of Agreement:

The experts have not yet agreed on the boundaries of Horizon.

Areas of Disagreement

Jason Coyne: Further information on the Claimants case is not required


to respond to this issue.

Since branch accounts could be affected by data communications to/from


Post Office back end systems and third-party clients, I opine that it is
necessary to consider data communications systems within the Horizon
system in order to appropriately report on issues that relate specifically to
branch accounts.

It is presently understood that the process by which the Horizon system


compares transaction data recorded by it against transaction data derived
from sources outside of it is known as Reconciliation. This comprises a
large number of complex electronic systems to monitor transactions but
there is also the ability for manual intervention to establish and correct
erroneous data.

Therefore, considered within my report and as per Schedule 1 Horizon is


defined as:

“the Horizon computer system hardware and software,


communications equipment in branch and central data centres
where records of transactions made in branch were processed, as

D1/1/11
defined in GPOC at §16 and as admitted by Post Office in its Defence {C3/1/5}
{C3/3/12}
at §37”

Processing facilities within the Horizon system considered relevant (but not
limited to) are:

POLSAP/POL FS

Credence

DRS

APS

TES

TPS

External Systems considered relevant are further detailed in my report.

Dr Worden: In their outline, the claimants' current case is 'still being


considered', but they believe that 'errors... in the electronic interface... may
be a significant risk area'. I am still assessing this view.

In addressing this issue, there is a difficulty in defining 'the Horizon system


itself'. I shall survey a number of ways in which comparisons of transaction
data were made (because these were all important parts of the robustness of
Horizon, in its business context). The experts may be able to agree which of
these were parts of 'Horizon itself'.

2.6 Issue 6

Issue 6 - To what extent did measures and/or controls that existed


in Horizon prevent, detect, identify, report or reduce to an
extremely low level the risk of the following:

a. data entry errors;

b. data packet or system level errors (including data


processing, effecting, and recording the same);

D1/1/12
c. a failure to detect, correct and remedy software coding
errors or bugs;

d. errors in the transmission, replication and storage of


transaction record data; and

e. the data stored in the central data centre not being an


accurate record of transactions entered on branch
terminals?

Areas of Agreement:

Whilst Horizon contains measures and controls for detecting system integrity
concerns, the automatic mechanisms have failed in the past. The experts do
not agree as to the ‘extent’ of prevention, detection, identification, reporting
or risk reduction that the automatic and manual control measures deliver.

Areas of Disagreement

Jason Coyne: When known issues or bugs/errors/defects are detected they


are dealt with by Post Office on a cost/benefit basis. Whilst
bugs/errors/defects may have been identified, they were not necessarily fixed
instantaneously, therefore the risk of error was not reduced as far as possible,
but rather was commercially assessed.

Dr Worden: Issue 6 appears, like issue 4, to be another enquiry into specific


dimensions of robustness, as defined in issue 3. its mention of 'levels of risk'
seems to imply this. I shall address all the dimensions of robustness
mentioned in issue 6. For each dimension, in my current preliminary opinion
Horizon was highly robust, and the types of error listed in issue 6 were very
unlikely to affect branch accounts.

It is not possible to fix bugs instantaneously. Practical release management,


to roll out improvements rapidly without adding risk, involves tradeoffs which
I will address in my report.

2.7 Issue 7

D1/1/13
Issue 7 - Were Post Office and/or Fujitsu able to access transaction
data recorded by Horizon remotely (i.e. not from within a branch)?

Areas of Agreement: None agreed.

Areas of Disagreement

Jason Coyne: Further information on the Claimants case is not required


to respond to this issue.

Evidence within a number of technical documents provided by Fujitsu


identifies that the Horizon estate was enabled to be managed remotely. This
is not beyond expected requirements. The nature of providing a support
service as Fujitsu do would require that as a design principle, the Horizon
solution should be completely remotely manageable.

Facilities were available to SSC (Third line support) enabling the access and
modification of transaction data with tools specifically designed for such.

Post Office document (HNG-X Wide Area Network HLD1) states:

“Remote support access to the counter will be provided through the


implementation of an SSH service running on the counter which can
then be accessed from the Secure Access Servers, in the data
centre.”

I have provided document references that show that remote access was
possible to Dr Worden.

Dr Worden: In the Claimants' outline allegations, the Claimants say they are
"still investigating" this issue. So, it is not yet clear to me where my opinions
are required, or what could be agreed.

The above reference to a technical document by Mr Coyne was provided the


day before this joint statement was submitted and I have therefore not yet
had time to consider this new point.

1
POL-0218013

D1/1/14
2.8 Issue 8

Issue 8 - What transaction data and reporting functions were


available through Horizon to Post Office for identifying the
occurrence of alleged shortfalls and the causes of alleged shortfalls
in branches, including whether they were caused by bugs, errors
and/or defects in the Horizon system?

Areas of Agreement:

No agreements.

Areas of Disagreement

Jason Coyne: Further information on the Claimants case is not required


to respond to this issue.

There were extensive report sets available to Post Office for identifying the
occurrence of alleged shortfalls and the causes. Not limited to reports alone,
Post Office also had the ability to request further information in relation to
bugs, errors and/or defects from the various Support Lines. Identified thus
far:

i. The TPS Report Set;

ii. The APS Report Set;

iii. The DRS Report Set;

iv. Reports and Data Obtained via Business the Incident


Management (“BIM”) Process;

v. Reports and Data Obtained via the Problem Management


Procedure;

vi. Information Obtained via Fujitsu; and

vii. Information Obtained from Postmasters.

The TPS, APS and DRS Report Sets along with reports produced in accordance
with the BIM and Problem Management Procedures provided a comprehensive
suite of reports which was available to Post Office. These reports would allow
Post Office to identify the occurrence of alleged shortfalls in the Horizon

D1/1/15
system, and they were underpinned by business processes which would
provide further information in relation to the underlying cause of a given
issue. In addition, Post Office should have been able to obtain any additional
information it required via Fujitsu or the Postmasters themselves.

Dr Worden: As for issue 8, this appears to be a factual issue, and one which
the claimants are 'still investigating'. So, it is not yet clear to me where my
opinions are required, or what the experts can agree on.

I have not yet assessed the relevance or importance of the reports cited by
the claimant in their outline.

2.9 Issue 9

Issue 9 - At all material times, what transaction data and reporting


functions (if any) were available through Horizon to Subpostmasters
for:

a. identifying apparent or alleged discrepancies and


shortfalls and/or the causes of the same; and

b. accessing and identifying transactions recorded on


Horizon?

Areas of Agreement:

The causes of some types of apparent or alleged discrepancies and


shortfalls may be identified from reports or transaction data available to
Subpostmasters.

Other causes of apparent or alleged discrepancies and shortfalls may be


more difficult or impossible to identify from reports or transaction data
available to Subpostmasters, because of their limited knowledge of the
complex back-end systems. Identification requires cooperation of PO staff
and subpostmasters.

Areas of Disagreement

D1/1/16
Jason Coyne: Subpostmasters were able to access limited reports and
receipts produced by the Counter, insofar as what Horizon or a Post Office
department had calculated and transmitted electronically. They would also
be able to see individual transactions and aggregated totals for items and
figures of which fed into Branch externally from the Counter input (i.e., stock
values, Transaction Acknowledgements and Transaction Corrections issued
by other Post Office departments).

These would not necessarily allow a Subpostmaster to determine the cause


of an issue or issues that arose at anything beyond Counter level (and
possibly even those that arose at Counter level).

Dr Worden: My report will comment on the transaction and reporting


functions available to Subpostmasters in Horizon. I do not believe the experts
are being asked to opine on whether or not the reports were adequate. That
would require a wider inquiry into the practical and accounting operations of
a branch beyond the Horizon system.

2.10 Issue 10

Issue 10 - Whether the Defendant and/or Fujitsu have had the


ability/facility to: (i) insert, inject, edit or delete transaction data
or data in branch accounts; (ii) implement fixes in Horizon that had
the potential to affect transaction data or data in branch accounts;
or (iii) rebuild branch transaction data:

a. at all;

b. without the knowledge of the Subpostmaster in


question; and

c. without the consent of the Subpostmaster in question.

Areas of Agreement:In respect of (ii) it is agreed that the very nature of


rolling out fixes within any IT system, including those implemented by Fujitsu
has the potential to affect transaction data or data in branch accounts.

D1/1/17
Areas of Disagreement

Jason Coyne: Further information on the Claimants case is not required


to respond to this issue.

In respect of point (i), it appears that Fujitsu did have the ability to insert,
inject, edit and (potentially) delete transaction data and (ii) had the ability
/facility to implement fixes in Horizon that had the potential to affect
transaction data or data in branch accounts.

Tools and platforms existed specifically for the purpose of accessing and
modifying transaction data, identified thus far are:

(i) Global Branches which would enable the input of transactions within
Horizon as though it had come from an actual Branch;

(ii) the Branch transaction correctional tool;

(iii) the Transaction Information Processing repair tool.

In respect of part (iii), no evidence of branch data rebuilding has been


discovered. However, Fujitsu had the remote access capabilities therefore it
is entirely possible that it could have occurred.

Dr Worden: I am still assessing the claimants' inference at the second para


10.2 of their outline; and their investigations described at their first para 10.2.

2.11 Issue 11

Issue 11 - If they did, did the Horizon system have any permission
controls upon the use of the above facility, and did the system
maintain a log of such actions and such permission controls?

Areas of Agreement:

Usage of the above tools and facilities should be auditable. However, the
maintenance of logs would be dependent upon retention periods and size.

Areas of Disagreement

D1/1/18
Jason Coyne: Further information on the Claimants case is not required
to respond to this issue.

I understand that these permission control procedures require a documented


authorisation. These are called “Master Service Change documents” and
“Operational Control Procedures”.

I have requested disclosure of these documents but Post Office have declined
to provide them.

Dr Worden: In the outline, it is stated that the claimants' case is still being
investigated. I await clarification before I can express an opinion.

2.12 Issue 12

Issue 12 - If the Defendant and/or Fujitsu did have such ability, how
often was that used, if at all?

Areas of Agreement:

No agreements.

Areas of Disagreement

Jason Coyne: Further information on the Claimants case is not required


to respond to this issue.

It is doubtful that the experts will be able to advance this point given that
Post Office has not disclosed Master Service Change (MSC) documents or
Operational Control Procedures (OCP). Post Office have stated that there are
approximately 36,000 MSC and OCP documents, without a review of these
documents the experts will be unable to opine as to how many of these relate
to Post Office/Fujitsu quantification of remote modification of transactional
data.

Dr Worden: In the outline, it is stated that the claimants' case is still being
investigated. I await clarification before I can express an opinion.

D1/1/19
2.13 Issue 13

Issue 13 - To what extent did use of any such facility have the
potential to affect the reliability of Branches’ accounting positions?

Areas of Agreement: None Agreed.

Areas of Disagreement

Jason Coyne: Further information on the Claimants case is not required


to respond to this issue.

The use of the facilities have the potential to affect the reliability of Branches’
accounting positions to a high extent. Not least since:

(a) Their purpose was to modify the transaction(s) itself or create


transactions;

(b) These were largely manual activities and therefore would be


subject to human input error.

Dr Worden: In the outline, it is stated that the claimants' case is still being
investigated. I await clarification before I can express an opinion.

2.14 Issue 14

Issue 14 - How (if at all) does the Horizon system and its
functionality:

a. enable Subpostmasters to compare the stock and cash


in a branch against the stock and cash indicated on
Horizon?

b. enable or require Subpostmasters to decide how to deal


with, dispute, accept or make good an alleged
discrepancy by (i) providing his or her own personal
funds or (ii) settling centrally?

D1/1/20
c. record and reflect the consequence of raising a dispute
on an alleged discrepancy, on Horizon Branch account
data and, in particular:

d. does raising a dispute with the Helpline cause a block


to be placed on the value of an alleged shortfall; and

e. is that recorded on the Horizon system as a debt due to


Post Office?

f. enable Subpostmasters to produce (i) Cash Account


before 2005 and (ii) Branch Trading Statement after
2005?

g. enable or require Subpostmasters to continue to trade


if they did not complete a Branch Trading Statement;
and, if so, on what basis and with what consequences
on the Horizon system?

Areas of Agreement:

None agreed.

Areas of Disagreement

Jason Coyne: Although not mandatory, it is recommended that “Weekly


Balances” are executed on a weekly basis to perform full cash and stock
account auditing.

This also helps to detect any discrepancies. If a discrepancy is discovered and


declared it will be moved into a suspense account until its resolution. The
purpose of this is to act as a separate line in the branch accounts that records
any surpluses or losses whilst allowing the daily trading accounts to balance.
A Subpostmaster has until the Monthly Trading Period Rollover to resolve any
discrepancy (this was weekly prior to 2005). Post 2005 is dealt with under
Issue 15.

The Monthly Trading Period Rollover is mandatory every month and as stated
above requires all discrepancies, including all within the suspense account, to
be resolved. At the end of this process a Branch Trading Statement is

D1/1/21
produced to reflect the cash and stock shown in the accounts matches the
cash and stock held in the branch in addition to any declared discrepancy.

Prior to 2005 Horizon followed a similar process however branches were


required to balance weekly and produced a Horizon “Cash Account”.
Discrepancies were held in a “Suspense Section” that was a part of the
Cash Account. Following the conclusion of any investigation counters were
issued and Error Notice to correct the discrepancy as opposed to a
Transaction Correction.

The value of error notices had to be keyed in manually by the


Subpostmaster on the Housekeeping menu of the Horizon system
following notification from either a client or POCL. However, the losses or
surpluses at the end of a balancing period could still be disputed.

I note that the ability to have a debt suspended pending an investigation


has only been available since August 2005. A loss is recorded as a debt to
the post office in the event the discrepancy is upheld by the Post Office
following any dispute.

Subpostmasters are not able to continue trading until Branch Trading


Statement process is complete. If the Branch Trading Statement is not
completed and therefore, the Monthly Trading Period Rollover is not
completed the Post Office will contact the branch in order to rectify the
situation.

Dr Worden: The question appears mainly factual rather than seeking an


opinion and so, at present, my view is that this issue should be addressed by
way of witness evidence and documents and does not require an opinion to
be given by an expert.

2.15 Issue 15

Issue 15 - How did Horizon process and/or record Transaction


Corrections?

D1/1/22
Areas of Agreement:

None agreed.

Areas of Disagreement

Jason Coyne: The central accounting function decides that it is necessary to


make some adjustment to the Branch accounts. Such adjustments to be made
at branch are necessary when branch transaction data does not align with
client or supplier data. A TC is defined which will carry out the necessary
changes (i.e. the central user will define an amount to be transacted for a
given Product in a given Branch and a corresponding settlement Product).

A daily file of such Transaction Corrections is generated from POL FS and


passed to TPS overnight.

TPS receives this file, validates the data and performs the required
translations using reference data (converting a SAP article ID into a
Horizon Product).

TPS sends messages for the Transaction Corrections to the specified


branches. A single message is written for the appropriate Branch for each
Transaction Correction.

Changes at the Counter enable a person with the required role to be made
aware of the existence of an outstanding TC and apply the correction at
the counter.

The result of processing a TC will normally be the creation of the specified


Transactions, which will be returned to POLFS as part of the normal flow
of Summarised Transaction data at the end of the Trading Day on which
the TC was processed at Branch.

Subpostmasters are advised to log on to Horizon every working day in


order to check for and process TCs as only those with Manager or
Supervisor access should process them.

D1/1/23
D1/1/24

Вам также может понравиться