POL00250726
POL00250726
PRIVATE & CONFIDENTIAL — PREPARED FOR CCRC PURPOSES ONLY - DO NOT FORWARD
CCRC INVESTIGATION RE HORIZON CASES
POL RESPONSES TO GRANT THORNTON QUESTIONS
17 AUGUST 2017
GT's questions are in black text. Post Office's answers are in red text.
As discussed at our meeting on 28 July 2017, we set out below our outstanding questions on
the Horizon system. If any of our understanding, as summarised in each question below, is
incorrect we would be grateful if you could correct this.
1.1... We understand that when cash is remitted out from a branch it is shown as a ‘pouch’ on
the transaction logs. Please can you explain how to identify ‘pouches’ in the transaction
logs, ie do they have a specific reference?
The ARQ transaction logs will show the following:
Rem out highlighted below
1 Cash
5610 Cash in Pouches Stock RIAD Rem In Auto distribution
Product
RODP I Dispatch Pouches
I 8509 I
I 6286 I
6287 Rem in Cash from AD
Mode Settlement Product
Counter mode id 106 - ROSP Notes
Counter mode id 107 -ROSP Coin
Counter mode id 108 — ROSP (CRY) Currency
Counter mode id 28 - RODP
1.2. We understand that if the Horizon system is inactive for a certain amount of time it will force
the user to log off, in this instance if a basket was part complete it would be settled to cash. Yes
We also understand that in the event of a power cut or system failure (ie by connectivity) that
the Horizon system will force the user to log off. When the power is restored the Horizon system
will begin a recovery process. Yes
1.2.1. Please can you confirm whether the event logs show the following and if so,
how they would be identified:
(i) Whether there has been a forced user log off due to a period of inactivity; Event code 27
(User logged off from system due to inactivity)
(ii) Whether there has been a forced user log off due to a power cut or system
failure.
In the event of a power failure, the system will be powered off so it cannot record an event code.
However, these incidents can be identified where there are 2 log-ons (12) without a log out (13)
in between.
POL-BSFF-0088789
POL00250726
POL00250726
PRIVATE & CONFIDENTIAL — PREPARED FOR CCRC PURPOSES ONLY - DO NOT FORWARD
As to system failure incidents, this would depend on the nature of the incident, but will likely
manifest in the same way as a power failure ie. two log-ons without a log-off.
1.2.2. In addition, is there a way of identifying any instances where a session was not recovered
following a power cut or system failure in the event logs? The recovery process is run in each
instance but that does not mean that a session needs recovering. Transaction logs indicate: No
recovery required/recovery roll fwd/roll back. The best way to check is in the mode column.
Please note that depending on the date of ARQ extracted the format may be slightly different
and may /may not include the modes/events as above. There have been some additions to
event codes over time.
1.3. We understand that it is possible to transfer discrepancies to the local suspense account at
the end of a trading period. Discrepancies once committed during balancing periods and trading
periods are transferred to the local suspense. At the end of a trading period, all discrepancies in
the suspense account must be resolved either by making good in branch or settling centrally.
Trading period cannot be rolled forward until all losses/gains have been cleared from suspense.
However, it is possible to carry forward suspense items such as rem shortages/surpluses and
pouches ready for dispatch.
1.3.1. Do discrepancies posted to the suspense account form part of the transaction logs? If so,
how would movements to the suspense account be identified?
In the event log code 32 will show what has been committed.
Yes the transaction logs show which discrepancies are posted to the suspense account.
15 Housekeeping entry - records amounts that have
been posted or redeemed from the suspense
account
17 Discrepancy declared in the branch that is
recorded in the branch accounts. Some of these
may not appear in housekeeping (15) as they can
be resolved by physically making good or may be
as a result of errors being found in the branch at
the time of reporting the discrepancy rather than
posting to local suspense account
145 Losses in branch
222 Gains in branch
6295 I Gain to local suspense
6296 I Loss to local suspense
6297 I Gain redeemed from local suspense
6298 I Loss redeemed from local suspense
6486 I Settle centrally to customer account in FSC
We have seen an example of a branch trading statement which details:
* suspense account balance brought forward;
* gains/losses to or from the suspense account; and
* suspense account balance carried forward.
POL-BSFF-0088789_0001
POL00250726
POL00250726
PRIVATE & CONFIDENTIAL — PREPARED FOR CCRC PURPOSES ONLY - DO NOT FORWARD
1.3.2. If not included within the transaction logs, is there any other way of obtaining a listing of
items posted to the suspense accounts during a period as detailed in the branch trading
statement?
All above can be seen in transaction logs. The amounts brought forward relate to cash/bureau
pouches not dispatched and held in suspense or an amount that may relate to for example a
shortage/gain in the remittance received. The trading period cannot be rolled over with an
amount relating to a loss/gain.
There is a report in branch that can be obtained detailing the suspense account entries. A
suspense report is a mandatory requirement of the branch trading balancing procedure and is
required to be retained in branch for 2 years.
1.4. In the example event log that we have been provided with, we can see instances which
state “x Outstanding TC(s) prompted”. Event code 62
1.5. We understand that, once accepted, the transaction correction would show in the
transaction log. Yes
1.5.1 Please can you explain how we would identify these transaction corrections in the
transaction log? In the transaction log a TC would show against the product id for the particular
product. It can also be identified by the mode MG/HD and code 29/30 MG (29) —- means made
good in branch and HD (30) means settled centrally.
1.5.2 Please can you explain what would happen if the transaction correction was not accepted
by the user, ie the user did not agree with the transaction correction? The user can request
more evidence prior to the acceptance of a TC. However, the TC must be accepted prior to the
completion of the BTS. That said, the user can accept and settle centrally and dispute with FSC.
We have some further information on TCs, including screenshots, should you require this.
1.6. Please can you confirm whether any supporting information and documentation (from
Chesterfield) would be available in relation to transaction corrections? Yes, TCs are usually
accompanied by evidence (E shown on Horizon) and the user can also request further evidence
from FSC.
1.7. We understand that it is possible to reverse transactions, by way of a positive stock
adjustment (SAP) or a negative stock adjustment (SAN). How would we identify such
adjustments in the transaction logs? Reversals should be undertaken using the ER (Existing
Reversal process) or RV (New Reversals). The RV is used in instances for example where it is
necessary to adjust stamps on hand when the Horizon figure and the physical stock do not
match. The SA should only be used in the cases such as: of lost /stolen stock; obsolete stock,
special/ordinary stamps when the volume is the same.
Should a stock adjustment be undertaken then in the mode column there will appear SAN/SAP
code 16/18 (now only SA)
1.8. We understand that where a branch has more than one stock unit and can transfer cash
between the stock units, a report called ‘Transfer Reconciliation’ can be printed from Horizon to
confirm that there are no outstanding transfers pending and that all totals sum to zero. Please
can you confirm whether these reports are available? Yes, these reports are available in branch
and can be accessed from the counter printer and back office printer. The trading period cannot
be rolled over with outstanding transfers.
1.9. In relation to ATMs, we understand that each day a ‘Bank Totals’ receipt is obtained from
the ATM in order to input the cash dispensed figure into Horizon. Please can you confirm
POL-BSFF-0088789_0002
POL00250726
POL00250726
PRIVATE & CONFIDENTIAL — PREPARED FOR CCRC PURPOSES ONLY - DO NOT FORWARD
whether the ‘Bank Totals’ receipts are available. The bank total receipts are obtained from the
BOI ATM in branch, this is a mandatory requirement and should be retained by the branch.
BOI provide to FSC dispensed figure totals daily which are correlated with the ATM dispensed
figures on Horizon (Product code 7748) in the serve customer screen.
POL-BSFF-0088789_0003