FUJ00156432
FUJ00156432
Response to Rinkfield Report
Ref: c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Author: Gareth I Jenkins
Date: 11/02/2011 12:45:00
Version: 0.2
1. ‘Introduction
I have been asked by Post Office Ltd to produce a response to Zechnical expert’s
report to the Court prepared by Charles Alastair McLachlan, a Director of Amsphere
Consulting Ltd. which I received on Thursday 11" February 2011.
I had seen a draft of this report on Monday 7" February and spent 3 hours with
Professor McLachlan on Tuesday 8" February agreeing a number of changes in the
hope of coming up with a joint report, which Professor McLachlan then produced.
Although there is much agreement in terms of fact, I fell that I am unable to agree with
the way in which the material is presented.
The purpose of this report is to highlight my views on Professor McLachlan’s report
and make it clear what my views are on the various hypotheses and facts.
There are a number of issues raised in Professor McLachlan’s report that are outside
my area of expertise and I believe need to be addressed separately by Post Office Ltd.
T highlight such areas in this report.
I should point out that my expertise relates purely to the Horizon system operated by
Fujitsu on behalf of Post Office Itd and does not extend to Post Office Ltd’s back end
systems or to their business processes. However in my view, any external systems are
not relevant to the accounts as presented by Horizon since all transactions that are
recorded on the system can be shown to have been carried out by a specific user.
2. Background Information on the Horizon system
The Horizon system was initially put together as a pilot in 1996, and following an
extensive pilot was rolled out to all Post Offices between 1999 and 2002. It has
recently been replaced by the Horizon Online system which was piloted at the start of
2010 and the last Horizon system was replaced in September 2010. Horizon is used in
every Post Office in the United Kingdom, which currently means about 11,400
branches. During that time, Horizon has processed millions of transactions cach day
with peak volumes of nearly 20 million transactions in a single day in the run up to
Christmas.
Within Horizon, each Post Office stores details of all its transactions on the Hard disk
of each PC within the Branch. There is a separate PC for each counter position.
Data from the branch is transmitted from each branch to Fujitsu’s Data Centres using a
variety of communications mechanisms. The software used to transmit the data from
the Branches to the Data Centre is specifically designed to ensure that whenever
contact is made between the Branch and the Data Centre any outstanding data is
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page I of 12
FUJ00156432
FUJ00156432
exchanged between the two. In particular for many transactions there is no need for
the Branch to be online.
3. Rinkfield Branch
I am told that Rinkfield has a FAD code of 252418 and I have data for FAD Code
252418 from 1 June 2008 to 30" June 2009. There is a single Stock Unit AA and
three counter positions. Trading Periods are rolled monthly with weekly Balance
Periods (in general). The data shows that there are 3 counter positions.
The following Users operated in the Branch:
User Id Earliest Date I Latest Date
02/06/2008 27/06/2008
02/06/2008 09/04/2009
02/06/2008 06/06/2009
02/06/2008 06/06/2009
04/06/2008 04/06/2009
09/06/2008 19/06/2009
11/06/2008 03/04/2009
04/08/2008 16/08/2008
06/01/2009 03/06/2009
14/04/2009 19/06/2009
08/06/2009 08/06/2009
08/06/2009 08/06/2009
10/06/2009 16/06/2009
10/06/2009 23/06/2009
10/06/2009 30/06/2009
MW: GRO} 11/06/2009 30/06/2009.
FK_GRO} 24/06/2009 30/06/2009
An audit was conducted on 8/6/2009 which discovered a significant Cash Shortfall.
4. Comments on Professor McLachlan’s Report
4.1 Section 1.2
This presents a number of Hypothetical issues which could be of concern.
I have to agree that all such issues could occur on a hypothetical system. However
there is no clear evidence that any of these issues actually applies to the Horizon
system. My concern is that some of the issues are raised as a means of casting doubt
on the system rather than anything concrete.
In particular the issue relating to External systems in 1.2.3 is outside my area of
expertise.
4.2 Section 2.2.1
This section presents a list of requests that have been made for further information. I
feel it is up to Post Office Ltd to address why such requests were not granted.
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 2 of 12
4.3
4.4
4.6
4.7
FUJ00156432
FUJ00156432
In the note at the end of the section, I believe that Professor McLachlan is also happy
that Remittances are correctly processed within Horizon.
Section 2.2.1
Professor McLachlan makes a point of comparing Horizon to a banking system. Over
the years I am aware that Post Office Ltd has gone through a number of changes. In
general, my view has been that they consider themselves to be a retail rather than a
banking organisation. However it is for Post Office Ltd to define their positioning.
As far as Horizon and its operation is concerned we have complied with the
requirements that Post Office Ltd have defined and also assisted Post Office Ltd in
obtaining accreditation with various Financial Institutions that Horizon interfaces to.
In particular there are specific requirements from Post Office Ltd to avoid printing
receipts (or vouchers as Professor McLachlan refers to them). There are a number of
Reports available to provide summaries of transactions as they have been recorded in
the system to aid reconciliation should there be any discrepancies.
Section 2..
This is an example of a hypothetical issue which might possibly have occurred, but for
which there is no evidence of it having occurred. I note that Professor McLachlan
accepts the fact that if the screen was poorly calibrated that a user might be expected
to notice incorrect selection of menu items very easily and hence that there was an
issue.
Section 2.3.2
This section purely says that if the User Interface design was poor, then it might lead
to errors and that Post Office has not allowed an audit of the User Interface design.
There is nothing here that indicates any aspect of the User Interface design that
presents any issues.
Section 2.3.3
The analysis I carried out of failed Debit card transactions is included in the embedded
document in App B of Professor McLachlan’s report.
Although the Fast Cash button is potentially a source of errors, there is nothing to
indicate that its misuse has actually caused any errors.
Section 2.3.4
Training is outside my scope of expertise to it is up to Post Office Ltd to comment on
this section.
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 3 of 12
4.8
4.9
4.10
4.11
4.12
FUJ00156432
FUJ00156432
However I accept that there were significant discrepancies on most days between the
System’s view of the Cash Holding and the Cash that was Declared as being on hand
each day. I also accept that the list of possible explanations for this.
Section 3.1
It might be helpful if Post Office Ltd could explain the circumstances under which they
monitor Discrepancies and under what circumstances they investigate them. It is clear
that there were significant discrepancies at the end of each period, most of which were
settled centrally (meaning that the postmaster wanted the discrepancy deducted from
their pay). I have no knowledge of what are the typical levels of such discrepancies,
but it does seem surprising that they were not investigated. I did note that the largest
such discrepancy was subsequently resolved via Transaction Correction, and so clearly
there was communication between the postmaster and Post Office Ltd in this case.
Section 4.4
I accept that this was the position at the end of the meeting. However I have since
realised that agreeing the report as being a Joint Opinion, meant that I fully accepted
everything in the report. As this report shows, although I accept the facts in the
majority of the report, I do not accept the way in which they are presented. There are
also some minor cases where I do not accept the facts.
Appendix D
I have restricted my analysis of what has happened in Rinkfield to the period 1“ June
2008 to 30" June 2009. I note that the list of Transactions Corrections goes back to
2006. I am also aware that Professor McLachlan has classified them adding in Column
L “Type” based on the words in Text 2.
I have no problem with this classification, but it is not clear what this is attempting to
show and so I cannot comment as to the accuracy of such classification.
Appendix H
I am not completely clear as to how accurately this data has been produced. In
particular I note that the total value in this spreadsheet is £35,134,446.01, while I
make the total value to be £35,127,746.14. In particular as Horizon uses double entry
bookkeeping I am surprised that Professor McLachlan’s total is an odd number of
pence. However I don’t feel it worth looking for the missing £7,000 since I’m not sure
exactly what the relevance of these totals are.
Appendix K
This spreadsheet has taken a subset of the events (excluding the report printed events
of which there are a very large number), and from these extracted those of type
Variance Check Discrepancy. I suspect (but have not checked) that these Variance
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 4 of 12
FUJ00156432
FUJ00156432
Check Discrepancies will correlate fairly well with differences I’ve recorded in column
Difference in sheet Correlation in spreadsheet CashMovements.xlsx described in
section 5.1. The fact that there is a variance on most days may well reflect poor
counting of cash on hand. The fact that such Variances were identified on a regular
basis and not addressed, does reflect on bad practice within the branch. A large
discrepancy should be considered as an indication that something has not been entered
on the system correctly and needs investigating. I note that there are some larger
Discrepancies in this spreadsheet than in my Cash analysis. This is probably due to the
fact that on some occasions the large variance did cause an investigation and
presumably resulted in either further transactions being entered or the Cash on Hand
being re-declared to correct the issue. In my view it is only the last Variance in a day
that is relevant and so I excluded earlier declarations from my analysis.
4.13 Appendix L
All though the spreadsheet embedded in section 14.2 is called Variance Check
Discrepancies by Date, it appears to be providing an analysis of a number of seemingly
arbitrary products. As there is no explanation as to what is the intention behind this
data I am unable to comment further. I believe that we had agreed on Tuesday 8"
February that Professor McLachlan would produce a chart showing Discrepancies
based on the data I provided him with which is part of Appendix B.
5. Analysis included in Professor McLachlan’s Report
The follow reproduces some analysis that I have carried out of data from the Rinkfield
Branch which has been included in Professor McLachlan’s report in Appendix B.
5.1 Cash Oddities
The underlying detail is in spreadsheet CashMovements.xls embedded here.
ee
CashMovements. xis
The spreadsheet is described in Appendix A (section 7).
An analysis has been carried out to correlate the following 3 sets of data:
e Daily cash movements as recorded as Cash transactions on Horizon
e Daily Cash Declarations
e Opening Cash Figures when the Stock unit is balanced (normally weekly)
In particular it would be expected when the Stock Unit is balanced, then the last Cash
Declaration matches :
e the Opening Cash Figure for the next period
e the cumulative System Cash position
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 5 of 12
5.1.1
period
FUJ00156432
FUJ00156432
In general this is the case. However there were a number of occasions when this was
not so. The following subsections examine all these cases and provides and
explanation in each case.
Last Cash Declaration does not match the Opening Cash Figure for the next
This means that the cash position must have changed during the Balancing Process.
The only way that that can happen is when Clearing Local Suspense prior to rolling
over into a new TP.
Looking through all Balances during the year, there is Local Suspense to be cleared at
the end of each Period. It is only cleared to cash once (when there was a surplus) and
that is on 20/08/2008 for £291.74 which is the only example of these not matching.
On two other occasions Local Suspense is cleared by Cheque (when it is below the
£150 Settle Centrally limit) and the other 10 balances were all Settled Centrally (and
were all Losses — a total of £11,817.01).
Last Cash Declaration does not match the Cumulative System Cash Position
A possible explanation for this is that transactions in the new BP were carried out after
the rollover, but on the same day. This can be checked by looking for transactions
after the rollover time and checking to see if the cash values match the Cumulative
Difference and if so there is nothing to worry about. In all cases of mismatches (and
they are listed below), this was the case.
Date Diff Cumulative Difference I Comment
20/08/2008 ~£291.74 £464.26 Cash Txn for -£291.74
and £756.00 done during
/ after balancing
(A&L Cash Deposit)
03/09/2008 £0.00 £520.00 Cash Tx for £520.00
done after balancing
(A&L Cash Deposit)
10/09/2008 £0.00 £580.00 Cash Tx for £10 and
£570.00 done after
balancing
(A&L Cash Deposit)
17/09/2008 £0.00 £810.00 Cash Tx for £810.00
done after balancing
(A&L Cash Deposit)
24/09/2008 £0.00 £300.00 Cash Tx for £300.00
done after balancing
(A&L Cash Deposit of
£500 and Lloyds
withdrawal)
08/10/2008 I £0.00 £300.00 Cash Tx for £300.00
done after balancing
(A&L Cash Deposit)
15/10/2008 I £0.00 £380.58 Cash Tx for £380.58
done after balancing
(A&L Cash Deposit)
22/10/2008 £0.00 £600.00 Cash Tx for £600.00
done after balancing
(A&L Cash Deposit)
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 6 of 12
5.2
FUJ00156432
FUJ00156432
05/11/2008 I £0.00 £762.00 Cash Tx for £762.00
done after balancing
(A&L Cash Deposit)
12/11/2008 I £0.00 £516.16 Cash Tx for £516.16
done after balancing
(A&L Cash Deposit)
03/12/2008 £330.00 Cash Tx for £330.00
done after balancing
(A&L Cash Deposit)
30/12/2008 £0.00 £817.00 Cash Tx for £507.00
(various) and £310.00
done after balancing
(A&L Cash Deposit)
04/03/2009 £0.00 £318.00 Cash Tx for £318.00
done after balancing
(A&L Cash Deposit)
18/03/2009 £0.00 £817.00 Cash Tx for £817.00
done after balancing
(A&L Cash Deposit)
25/03/2009 I £0.00 £300.00 Cash Tx for £300.00
done after balancing
(A&L Cash Deposit)
01/04/2009 £0.00 £39.56 Cash Reversal for
£39.56
13/05/2009 £0.00 £750.00 Cash Tx for £750.00
done after balancing
(A&L Cash Deposit)
20/05/2009 £0.00 £500.00 Cash Tx for £500.00
done after balancing
(A&L Cash Deposit)
03/06/2009 I £0.00 £433.00 Cash Tx for £53.00
(paystation) and £380.00
done after balancing
(A&L Cash Deposit)
When doing this investigation I found that in most cases these transactions were online
cash deposits to A&L (Alliance and Leicester Bank — now part of Santander).
Unfortunately the Transactions Extract did not include the full details of the
transactions so I went to the raw logs and extracted details of all A&L Cash Deposits
during the 13 months. I did that by looking for all records containing the string
<ProductNo>6478</ProductNo> (Product 6478 is an A&L Cash Deposit).
From this I could see that most of these A&L Cash deposits used the same PAN
5603730042295255, which I have subsequently been told belongs to the defendant.
(The exception was on 03/12/2008.)
Looking over all the A&L Deposits there are 288 payments using this PAN for a total
value of £152,556.22. This represents nearly one transaction every day and looking at
them, the bulk of them were carried out outside normal working hours (ie before 9am
or after 5:30pm). Note that there are about 948 A&L Deposits in total.
Analysis of Transactions associated with Rejected Credit Cards
Charles McLachlan has provided me with a spreadsheet Card Product Ids Rejected
Card Payments.xls where he has identified cases where following a failed Debit /
Credit Card payment, the Customer Session has been settled to Cash. This is to
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 7 of 12
support the claim that it may be possible to not notice the fact that the Debit / Credit
Card payment had failed and to press Fast Cash to complete the session and not
realised that no cash has been taken. I had started a similar analysis, and am happy to
accept the 36 Customer Sessions that Charles identifies in sheet Unique FASTCASH
possibles as being the ones that may be relevant.
FUJ00156432
FUJ00156432
I did note that when identifying possible failed Debit / Credit Card payments in sheet Card
Product Ids Rejected Card, then Charles has ignored Product 7343 Maestro Int DC Payment
There are 2 sessions where this was used as a payment and failed:
4 44-252418-3-3643679-1
¢ 44-252418-2-3559281-1
I[L've checked both these
sions and I don’t believe that they merit further investigation.
I also accept that the total cash value of these 36 sessions is £19,775.87. However
rather than examining all of these sessions, I feel that if we examine those for which the
Cash value is £500 or more (8 sessions), then the value of the remaining sessions
(£1,178.60 in total) can be considered immaterial.
Looking at these 8 sessions we have:
Sessionid
Date
User
SaleValue
Comment
44-2524 18-2-3092831-
2
15-Jul-08
£1,564.31
Covered by TC
600021496112542000
44-2524 18-2-3092977-
1
15-Jul-08
£1,564.31
Covered by TC
600021496112542000
44-252418-2-3093049-
1
15-Jul-08
£559.71
Covered by TC
600021496112542000
44-252418-2-3093070-
1
15-Jul-08
-£500.00
Covered by TC
600021496112542000
44-2524 18-2-3552143-
1
19-Mar-09
£827.39
This was reversed in session 44-
252418-3-3831002-1 at 11:56
44-252418-2-3556898-
1
21-Mar-09
£4,988.45
This was reversed in session 44-
252418-2-3556939-1 at 09:24
44-252418-3-3742463-
1
22-Jan-09
£5,733.90
Session 44-252418-2-3440258-1
at 13:26 shows a Cheque for
£5,733.90 being substituted for
cash
44-2524 18-3-3828004-
1
18-Mar-09
£1,527.39
There were 2 reversals in sessions
44-2524 18-2-3548869-1 and 44-
252418-2-3548883-1 totalling this
amount (the original session had
two transactions and so were
reversed separately)
44-2524 18-3-3910478-
1
05-May-
09
£1,331.81
This was reversed in session 44-
252418-2-3647066-1 at 16:48
I believe that this shows that in all cases the failure of the Debit / Credit Card payment
was noticed and so had no long term impact on the Branch’s cash position.
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 8 of 12
6.
6.1
FU.
Further analysis not included in Professor McLachlan’s Report
Back Office Analysis
At the request of Charles McLachlan, I’ve carried out some further analysis —
particularly of Back Office transactions.
These are included in the spreadsheet Discrepancies.xlsx.
&)
Discrepancies. xisx
In order to do this, I’ve extracted all Transactions in the following Modes into a
separate spreadsheet Discrepancies.xlsx in sheet Discrepancies etc:
DDN / DDP (Discrepancies when Balancing)
SAP / SAN (Stock Adjustments)
MG/ HD (Transaction Corrections)
HK (Housekeeping — including Clearing Local Suspense when Balancing)
Ihave further categorised the Mode HK transactions as follows:
Audit
These were carried out by the Auditor on 8/6/2009 to write off the Shortfall
before installing a new Postmaster
BAU
These were normal Business As Usual Housekeeping transactions carried out
using the normal HK menu
I note that they are all related to Rem discrepancies.
I also note that many of the TCs are for Rem Discrepancies. Some of them are
clearly correcting such Remittance errors.
Clear LS
These are the Housekeeping transactions carried out when Rolling over a
Branch to a new TP to clear any identified discrepancies. They are analysed
further in section 6.1.1.
TC
These are where a TC has been accepted for a Rem discrepancy. Such TCs are
normally settled to cash with instructions to then clear the Rem Discrepancy
using HK.
The Transaction Corrections are discussed further in section 6.1.2
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 9 of 12
FUJ00156432
}J00156432
FUJ00156432
FUJ00156432
6.1.1 Clearing Local Suspense
The following table shows the Cash Discrepancies identified for each Period and how
the were settled:
I User. I Date Time ProductNo I Prod Name Amount
I GR i_I 18-Jun-2008 I 17:26:58 I 2 Cheque -£27.44
I KM 17-Jul-2008 17:37:38 I 6486 Settle centrally I -£4,792.32
JCI 20-Aug-2008 I 18:43:05 I 1 Cash £291.74
I KM 17-Sep-2008 I 18:15:14 I 6486 Settle centrally I -£770.11
KI 15-Oct-2008 _I 17:56:12 I 6486 Settle centrally I -£723.89
I AN; 19-Nov-2008 I 18:42:30 I 6486 Settle centrally I -£697.26
KM GRO} I 17-Dec-2008 I 20:44:06 I 6486 Settle centrally I -£189.22
I KM 14-Jan-2009 I 19:23:18 I 2 Cheque -£31.08
I KM 18-Feb-2009 I 19:01:35 I 6486 Settle centrally I -£311.47
I KM 18-Mar-2009 I 18:52:18 I 6486 Settle centrally I -£1,711.88
I KM 15-Apr-2009 _I 18:57:37 I 6486 Settle centrally I -£1,052.99
I KM 20-May-2009 I 17:45:13 I 6486 Settle centrally I -£1,251.57
SU 17-Jun-2009 _I 18:06:20 I 6486 Settle centrally I -£316.30
Note that the system doesn’t allow a User to settle centrally for amounts less than
£150, which is presumably why 2 periods were settled by cheque as the amounts were
small in these cases. The one case where there was a surplus, then the cash was
withdrawn. I note that this was a different User from normal.
T also note that the Settle Centrally on 17/7/2008 relates to TC 6000214961 12542000
and problems on 15 July. (Though the amount doesn’t match exactly.)
Note that it is my understanding that such Losses that are Settled Centrally are likely
to result in subsequent deductions from the postmaster’s remuneration.
6.1.2 Analysis of Transaction Corrections
I have copied in details of Transaction Corrections provided by Post Office Ltd in
Andrew Winn’s witness statement into sheet 7Cs from POL. [ve also extracted all
Transaction Corrections processed in the Branch into sheet TCs in Branch.
I’ve then attempted to correlate them for the overlapping period. I’ve done this as
follows:
e In sheet [Cs in Branch \’ve added in a column J which has the TC reference
for each TC. I’ve identified 2 TCs which do not appear on the POL list (one of
which was after the new Postmaster had taken over and so presumably beyond
the scope of the POL list)
e Insheet TCs from POL I’ve added two columns:
© Prod: This uses a lookup table to convert the Article into a Horizon
Product to make it easier to match with the TCs in Horizon
o OK? To indicate that a matching TC was found
¢ Inote that TC 600040045712542000 is marked in POL’s spreadsheet as being
for £6.30, but was processed in Horizon as £63
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 10 of 12
FUJ00156432
FUJ00156432
7. Appendix A: Description of CashMovements spreadsheet
T have received from Penny Thomas data associated with ARQs 515 to 527 covering
this period. For each month I have the following:
= Transactions Spreadsheet
= Events Spreadsheet
= Raw Horizon data in XML format
Ihave put together the info as follows:
= Transactions.xlsx
Transactions spreadsheets for the full period
I’ve enriched this with details of Product Name and Level info for further
analysis
= Events.xlsx
Events spreadsheets for the full period
Declarations and Rollover Events have been extracted and analysed further
= Tidied.openingFigs.xlsx
Extracts from Raw Logs for Opening Figures for the full period
Cash Opening Figures have been extracted for further analysis
= ~CashMovements.xIsx
Analysis of Cash position from the other 3 sources. The Sheets in this
spreadsheet are:
of type Declaration Complete and then further analysing these to
extract the Type, Value and Till from the Event Text. Checks were
also made for multiple declarations of a given type and Till for a day
and those other than the last were discarded. Checks were also
made for incomplete declarations (ie where no all Tills declared on a
day) and these were also excluded (this only occurred for Stamps).
These were then summed to produce the final declaration for each
day in this sheet
Sheet Useage 2 S e . :: x
Daily Cash This has been derived from the Cash Transactions by adding up the
Movements SaleValue of all Cash Transactions (ie Product 1) from the
Transactions Log for each day.
Cash Declarations This has been derived from the Event Logs by looking for all events
Prod 1 Opening I searched the raw logs for all messages containing the string
Figures “OpeningFiguresid” and from these I extracted all those for
Container (ie Stock Unit) AA for ProdcutNo 1 (ie Cash)
BP Rollover Info In the Event Log I extracted all Events of Type Rollover Complete
and extracted from the Event text the Stock unit, the old and new TP
and BP. From this I was able to identify the dates on which SU
rollovers took place
TP Rollover Info In the Event Log I extracted all Events of Type Branch TP Rolled
and extracted from the Event text the old and new TP. From this I
was able to identify the dates on which Branch rollovers took place
Month Lookup A table to help convert dates from the Riposte format into an Excel
format
Correlation See below
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 11 of 12
FUJ00156432
FUJ00156432
The key sheet here is “Correlation” which pulls together all the info about
Cash for each day during the period. The columns are as follows:
Column
Useage
Date
Date
Note that I have included a “Start Point” column where I've inserted
assumed figures such that the initial period balances correct!
Cash Movement
The sum of all Cash Transactions in all Modes on that date
Copied from Sheet Daily Cash Movements. It is blank if there is no
entry in that sheet (eg Sundays and Bank Holidays when the Branch
is presumably shut)
Cumulative Cash
Cumulative Cash position based on Transactions and an assumed
Start Position such that Difference is zero at first balance period
Declaration
Copied from Sheet Cash Declarations. The entry for the previous
day is carried forward if there is no entry in that sheet (eg Sundays
and Bank Holidays when the Branch is presumably shut)
Opening Figure
Copied from sheet Prod 1 Opening Figures. Itis blank if there is no
entry in that sheet (eg any day when the Branch is not Balanced). In
practice this is only present on Wednesdays.
Diff
This is the difference between the Cash Declaration column and the
Opening Figure column (if not Blank). They should normally be the
same.
Decl Movement
This looks at the differences between successive entries in Column
Declaration to allow comparison with the cash movements.
Difference This looks at the difference between the Cash Movement and the
Decl Movement columns.
Cumulative This looks at the cumulative differences which is a better
Difference comparison. On Balancing days this should normally be zero. On
other days it reflects the accuracy of the daily Cash Declarations.
TP Rollover Set to Y if Date was TP rollover
BP Rollover Set to Y if Date was BP rollover
FUJITSU RESTRICTED (COMMERCIAL IN CONFIDENCE)
c:\gij\pathway\miscdata\0b25.rinkfield\gij.rinkfield.responsev0.2.doc
Page 12 of 12