FUJ00085922
FUJ00085922
To: Newsome, Pet
From: Bansal, Steve (BRAO1)[/O=FUJITSU EXCHANGE ORGANIZATION/OU=EXCHANGE ADMINISTRATIVE GROUP.
(FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=DDC16C49A7C4434695F8FA2B73D]
Sent: Thur 1/14/2016 8:02:37 AM (UTC)
Subject: I FW: In Strictest Confidence Updates on Branch Outreach _ Some Queries Please
FYI
Steve Bansal
Senior Service Delivery Manager
Business & Application Services
Post Office Account
FUJITSU
Berkshire. Rt
or Internally
Mobile’
E-mail:
Web: uk. fujitsu.com
+
eS
& Fujitsu named as
Responsible Business
of the Year
Fujitsu is proud to partner with Action for Children
I-ClO: Global Intelligence for the ClO. Fujitsu's online resource for ICT leaders
Sponsors of the 2015 Rugby World Cup
iw Please consider the environment - do you really need to print this email?
From: Kathryn Alexander [mailto:
Sent: 13 January 2016 17:13
To: Chambers, Anne O <A
Cc: Bansal, Steve (BRAO1
Subject: RE: In Strictest Confidence Updates on Branch Outreach _ Some Queries Please
Hi Anne
Thanks again for the clarification and help with this. I should now be able to update my report on these 2 branches for Angela
Regards
Kath
Kathryn Alexander
Case Review Manager
1* Floor Admin,
Ty Brwydran,
Atlantic Close, Swansea SA7 9F)
00
From: Anne.Chamberst_ GRO I
FUJ00085922
FUJ00085922
Sent: 13 January 2016 17:00
To: Kathryn Alexant
Cc: Steve.BansalG@ = GRO
Subject: RE: In Strictest Confidence Updates on Branch Outreach _ Some Queries Please
Hi Kath,
Some responses inline.
( haven’t looked at the full ARQ data for these two branches, it might provide a little extra information (such as whether there were
connection issues) but I don’t think it would take you any further forward regarding the duplicate pouches.
Anne Chambers.
Systems Support Centre, Post Office Account
Fujitsu
Lovel
Tel: 4
Email
Web: http://uk.fujitsu.com
From: Kathryn Alexander
Sent: 13 January 2016 1
To: Chambers, Anne O
Cc: Bansal, Steve (BRAO:
Subject: RE: In Strictest Confidence Updates on Branch Outreach _ Some Queries Please
8
Hi Anne
Thanks for the information below, and the clarification regarding the issue.
I agree regarding the red herring for the £49500, I looked at it for ages and just couldn’t find a link to the 25K!
I follow the scenarios outlined and just want to be crystal clear in my thinking so have added some comments in red below, if you
can just confirm my thinking that would be great.
Although our investigations into duplicate pouches were intended to find instances when a system issue had resulted in a
duplication, it is also possible for branches to enter the same pouch barcode twice while remming in manually, and thus show a
duplicate in the records that I checked. Just want to understand that your initial investigations looked at duplicate pouches
but not into the detail as we now have with these 2 branches and likely scenarios?
For all branches where I found duplicate barcodes/amount, I then checked for housekeeping transactions and TCs related to rems. I
was using the BLE data that is summarised for POLSAP, which includes the pouch_id and TC refs etc, but doesn’t show all
transactions individually, nor user/till/timestamp. In most cases I found HK/TCs that suggested the problem had been noticed and
resolved. I believe Steve Bansal provided a spreadsheet of all the branches I checked. I couldn’t always tell whether the cause was
the system problem, or the branch entering the same barcode twice in 2 separate sessions.
Normally cash rem ins are done automatically by scanning the barcode, and the contents are found from information held
centrally. If this is done, a barcoded pouch cannot (since Jan 2011) be remmed in more than once. But if there is no information
held centrally (as often seems to be the case when the barcode can’t be scanned and is entered manually), the user will be
prompted to enter the amount manually. You still can’t use the same barcode twice in the same rem-in session, but it is possible to
use the same barcode in separate sessions. It is my understanding that when the barcode details are input manually, HOL will
attempt to match the barcode details of each pouch advice note against the replenishment delivery notice held on the system (this
info cannot be seen on the system though). If the system is unable to match the details then user will need to input the amounts
manually. So this is what is most likely to have happened here.
I understand that it is also possible to use the same barcode on same node provided it is in separate session? Yes, if no
replenishment delivery notice exists. And they don’t need to log out/in again — just exit from the pouch delivery screen, at which
point the rems are committed to the database.
Although everyone seems to be under the impression that all pouch barcodes are unique, I have found that there are a small
number of duplicate barcodes on the system, across different branches, and a few I checked had been entered manually. How can
you tell whether they have been entered manually? Think on some ARQ logs I have seen there is an entry method code? But not on
FUJ00085922
FUJ00085922
the ones I have?
Did you find this as part of the audit of the BLE files for this issue, or is this on general queries raised or perhaps both?
The BLE files each contain data for around 170 branches. My check looked for any duplicate pouches within each file, expecting to
find just those where the ‘outreach’ problem had occurred at a single branch, but I found instances where the same pouch_id had
been used at 2 different branches on the same day, usually with different amounts. I then looked at the counter logs (only available
for 30 days, retrieved on demand) for 3 recent examples — these logs show whether the scanner has read the barcode or whether it
was typed in. In these cases I could see the barcode had been typed in, not scanned, and that the auto-remittance lookup had
found nothing. Far too small a sample to prove that this is always the case, and of course we don’t know why they typed it instead
of scanning it. As far as I know, there is no centrally-held information about the entry method for rem ins, so nothing in the ARQ
output. Only clue is, if done manually, there will only ever be 1 cash line per pouch, but if done automatically there will be one cash
line for each denomination — you could see this in the ARQ data. But many pouches are single denomination anyway.
One final point — the ‘outreach’ problem could theoretically affect non-outreach branches, but it is far less likely to happen, and
certainly isn’t the case for these two instances since the rems were done on different counters. Thank you for clarifying this, I was
confused as these branches didn’t have outreaches.
209311
I have a hypothesis for what happened at branch 209311 on 1/3/2013:
10:58 scan barcode, automatically rem in £26000 (notes of all the same denomination)
11:00 scan second barcode. This doesn’t scan so they enter barcode 301243708327 (as printed on pouch?, nothing held
centrally) and amount £2500. Where did you have this barcode number from? Did I miss it on logs? From the BLE/POLSAP
data — included on the spreadsheet mentioned above.
They then try scanning third pouch, again it won’t scan, and possibly the printed barcode is the same as the second pouch?-
in which case the system says ‘this pouch has already been input’. Put it to one side, with a 4" pouch not yet processed,
finish the session and move on to other tasks. Assume this is because of the impression of all barcode being unique but
they are not?
At 11:21, user on other counter decides to try the third pouch on there. Still won’t scan, but puts it through manually
(separate session so duplicate checks not applied).
11:22 first user, not realising the pouch has been remmed in, goes into Housekeeping and puts the surplus £2500 into
suspense. After realising that this was not necessary, at 11:49 redeems the surplus (having just remmed in the 4" pouch
containing £20000 single denomination).
I can’t prove this from the available evidence, but there’s no evidence ofany the known system error in this instance (Is this from
the available evidence too? sorry if being pedantic here) It’s certainly not the ‘outreach’ problem - your data shows it was done on
two different counters. I haven’t spotted anything else that concerns me. Since there’s no indication that the branch subsequently
had a loss of £2500, it seems highly likely that they did actually receive 2 pouches each containing £2500 that day. Thanks
understand this. It seems the logical sequence. It appears the branch rectified without POL or helpline intervention
157242
I think the £49500 surplus here is a red herring and nothing to do with the duplicate pouch ids. I think 2 genuine pouches with the
same barcode is a more likely cause. Another hypothesis, again not provable: Do you think this could have been issues with the
system and unable to do the transaction - the NBSC call on 15th says suspense and rem issues. There is a call on the 18th that is
referred to Horizon desk advising system on go slow and declining transaction? Could have been problems in the branch? But
nothing linking the 2 calls in the logs from NBSC. Seems unlikely —- most common problem is failure to connect to data centre, but
we can see they were trading and banking txns being authorised. They’d have needed to be able to contact the data centre to do
the housekeeping transaction. But might have had intermittent connection issues.
08:40 pouch 301999011214 remmed in on node 2 (using manual process I assume)
Attempts to process second pouch which has same barcode?, this is not allowed. As same session
As above, is there an entry method code to check? As above where is this number from? Have I missed this? Or are they
not available? As above.
FUJ00085922
FUJ00085922
08:43 pouch 301999011214 remmed in on node 1 (also using manual process I assume) As different session
12:37 3 other pouches remmed in normally. Likely that these were a separate delivery? Not usually, but possible I suppose,
don’t know the branch/area so maybe? Just wondered why the delay. Maybe they were just confused and waited.
13:47 rem surplus of £49500, which was moved to suspense on 15" Feb, redeemed and remmed in (don’t know if this used
the manual process). Can’t tell why they were unable to rem in the cash on the 15", but I wonder if they had now realised,
after doing it in the morning, that it is possible to do a manual rem in even if the bar code won’t scan? So decided to do that
and sort out the problem from the previous week?
Again, given the lack of any subsequent calls or losses, it seems likely that they did receive 2 pouches each containing £25000, as
well as 3 others and resolving problems from the previous week.
Conclusion
My search looked for any duplicate pouch for same day/branch/amount, which is the only reason that we have looked in detail at
these two branches. I don’t see anything to indicate that there was any system fault, nor any unintended impact on the branch
accounts. There is nothing in the branch accounts that suggest any impact on accounts. The account/TCs clear as expected from the
logs and the in branch action has rectified
Thanks again
Regards
Kath
‘ Kathryn Alexander
Case Review Manager
1* Floor Admin,
Ty Brwydran,
Atlantic Close, Swansea SA7 9FJ
From: Anne.Chambersé.
Sent: 12 January 2016 17:29
To: Kathryn Alex:
Cc: Steve.Bansa
Subject: RE: In
ice Updates on Branch Outreach _ Some Queries Please
Kath,
Thanks for sharing your extra information. It helped me to piece together possible scenarios.
Happy to discuss further if necessary but I will only be around for the next couple of days.
Although our investigations into duplicate pouches were intended to find instances when a system issue had resulted in a
duplication, it is also possible for branches to enter the same pouch barcode twice while remming in manually, and thus show a
duplicate in the records that I checked.
Normally cash rem ins are done automatically by scanning the barcode, and the contents are found from information held
centrally. If this is done, a barcoded pouch cannot (since Jan 2011) be remmed in more than once. But if there is no information
held centrally (as often seems to be the case when the barcode can’t be scanned and is entered manually), the user will be
FUJ00085922
FUJ00085922
prompted to enter the amount manually. You still can’t use the same barcode twice in the same rem-in session, but it is possible to
use the same barcode in separate sessions.
Although everyone seems to be under the impression that all pouch barcodes are unique, I have found that there are a small
number of duplicate barcodes on the system, across different branches, and a few I checked had been entered manually.
One final point — the ‘outreach’ problem could theoretically affect non-outreach branches, but it is far less likely to happen, and
certainly isn’t the case for these two instances since the rems were done on different counters.
209311
I have a hypothesis for what happened at branch 209311 on 1/3/2013:
10:58 scan barcode, automatically rem in £26000 (notes of all the same denomination)
11:00 scan second barcode. This doesn’t scan so they enter barcode 301243708327 (as printed on pouch?, nothing held
centrally) and amount £2500.
They then try scanning third pouch, again it won’t scan, and possibly the printed barcode is the same as the second pouch?-
in which case the system says ‘this pouch has already been input’. Put it to one side, with a 4" pouch not yet processed,
finish the session and move on to other tasks.
At 11:21, user on other counter decides to try the third pouch on there. Still won’t scan, but puts it through manually
(separate session so duplicate checks not applied).
11:22 first user, not realising the pouch has been remmed in, goes into Housekeeping and puts the surplus £2500 into
suspense. After realising that this was not necessary, at 11:49 redeems the surplus (having just remmed in the 4" pouch
containing £20000 single denomination).
I can’t prove this from the available evidence, but there’s no evidence of any system error in this instance. Since there’s no
indication that the branch subsequently had a loss of £2500, it seems highly likely that they did actually receive 2 pouches each
containing £2500 that day.
157242
I think the £49500 surplus here is a red herring and nothing to do with the duplicate pouch ids. I think 2 genuine pouches with the
same barcode is a more likely cause. Another hypothesis, again not provable:
08:40 pouch 301999011214 remmed in on node 2 (using manual process I assume)
Attempts to process second pouch which has same barcode?, this is not allowed.
08:43 pouch 301999011214 remmed in on node 1 (also using manual process I assume)
12:37 3 other pouches remmed in normally. Likely that these were a separate delivery?
13:47 rem surplus of £49500, which was moved to suspense on 15"" Feb, redeemed and remmed in (don’t know if this used
the manual process). Can’t tell why they were unable to rem in the cash on the 15", but I wonder if they had now realised,
after doing it in the morning, that it is possible to do a manual rem in even if the bar code won't scan? So decided to do that
and sort out the problem from the previous week?
Again, given the lack of any subsequent calls or losses, it seems likely that they did receive 2 pouches each containing £25000, as
well as 3 others and resolving problems from the previous week.
Conclusion
FUJ00085922
FUJ00085922
My search looked for any duplicate pouch for same day/branch/amount, which is the only reason that we have looked in detail at
these two branches. I don’t see anything to indicate that there was any system fault, nor any unintended impact on the branch
accounts.
Regards, Anne.
Anne Chambers:
Systems Support Centre, Post Office Account
Fujitsu
Lovel Berkshire
Tel: 1 Internally
Email!
Web: http 7/uk-fujitsu:com’
From: Bansal, Steve (BRAO1)
Sent: 12 January 2016 09:59
To: Chambers, Anne O <Anne.Chambers@
Subject: FW: In Strictest Confidence Updates on Branct reach _ Some Queries Please
Hi Anne
Could I ask you to please review the following from POL and where possible respond
Regards
Steve Bansal
Senior Service Delivery Manager
Business & Application Services
Post Office Account
FUJITSU
Lovelace Road, Bracknell, Berkshire. RG12 8SN
Tel: ‘Lor Internally
Mobile: {
E-mail:
Web: uk fujitsu.con
) £/¥) ine)
Fujitsu named as
Responsible Business
of the Year
Fujitsu is proud to partner with Action for Children
I-ClO: Global Intelligence for the ClO. Fujitsu's online resource for ICT leaders
Sponsors of the 2015 Rugby World Cup
A Please consider the environment - do you really need to print this email?
Angela asked me to investigate (following your discussions with her a couple of weeks ago) the two branches
157242 value £25k and 209311 value £2.5k where a resolution is not known.
I have looked at some information and hope you can help with some queries I have please before I go back to
Angela?
« From my discussions with Angela, it is my understanding that these 2 branches were affected by the issue
that may affect branches operating outreach services. It is my understanding that the 2 other issues,
‘using Prev button & pouch remitted at multiple counters’ have been fixed in March 2010 & Jan 2011. Is
FUJ00085922
FUJ00085922
my understanding correct here or am I missing the point?
e The reason for the question is that both of these branches do not operate outreach services and according
to the databases I have looked at, have never operated outreach services. Also the information I have
below would seem to relate to one of the other issues?
209311 - from what I can see from the information I have, it would seem that a cash rem for £2500 has
been remmed in twice (on till 1 & 2 ) One £2500 transaction completed by User ID LLA001, session ID
500306 (who has also completed all other rem in transactions that day) and one of the £2500 transactions
completed by RHOO01, session ID 47783. There is also a Rem surplus, session ID 500321 and this has been
redeemed, session ID 500327. There is no record of the branch contacting NBSC or FSC, so assume that they
have resolved without any contact with POL. Am I correct in thinking that this relates to the remitted at
multiple counters issue?
157242 - This seems to be a bit more confusing, so would appreciate you help with this one please.
From the information I have I can see on 18/02/2013, 4 entries for £25K (Session Ids 408423, 994279,
408525) All of these entries with the exception of Session ID 994279 are completed by JKAOO1 on till 2.
Session ID 994279 is completed by JSI001 on till1. All these entries are under code 24.
Additionally, there has been a Redeem Rem Surplus (2168) on 18/02/13 for £49500 on till 2 by KJAO01,
Session ID 408568.
On 15/02/13 there has been a Redeem Rem Surplus (2168) for £49500 on tilll by JSIO01 followed by a Rem
Discrepancy Surplus (2164) for £99,000 by JSIO01 on till 1. (Sessions IDs 994168 &994169)
Whilst I can understand that there is no overall discrepancy as the £99,000 and 2x £49500 balance off I don’t
understand a couple of things here.
1) The redeemed discrepancy surplus is present prior to the rem discrepancy surplus?
2) Does the 25K on the 18/02/13 (Session IDs 408423 & 994279) relate to the issues that have affected
branches as it is undertaken on separate tills by different users, or is this a red herring and is 2 separate
pouches?
There are no losses/gains relating to any of the above amounts, I have looked at transactions in case any
of the figures have doubled up etc.
Oddly the branch did report an issue to NBSC on 15/02/13 at 11:02:06 advising that they had a Rem in
/suspense account issue, and again at 13:02:45 they advised that they could not rem in the cash; the
resolution was to enter in rem surplus. This may partly explain the order of events on the 15/02/13 but
not the 25K on 18/02/13. Is there any information that I am reading incorrectly, or perhaps Iam
missing something simple here?
If you are able to shed any light on these queries I would appreciate it and I can then update Angela with my
findings.
Hope this makes sense and thanks for your help
Regards
Kath
Kathryn Alexander
Case Review Manager
® 1* Floor Admin,
Ty Brwydran,
Atlantic Cl
ARC 24 24 KR Hf 22 GA 0 28 0 2 KR 2K GR a a a
This email and any attachments are confidential and intended for the addressee only. If you are not the named recipient,
you must not use, disclose, reproduce, copy or distribute the contents of this communication. If you have received this in
error, please contact the sender by reply email and then delete this email from your system. Any views or opinions
FUJ00085922
FUJ00085922
expressed within this email are solely those of the sender, unless otherwise specifically stated.
POST OFFICE LIMITED is registered in England and Wales no 2154540. Registered Office: Finsbury Dials, 20 Finsbury
Street, London EC2Y 9AQ.
FEISS SCI SIISICI ISI CICICIICICGR ACI I ICICI aC ICR a 3 CR 8 a CSR A Ca RR a CSG RR I CSR A CACO oR I ACG
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from
Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be
privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes
End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway,
Birmingham Business Park, Birmingham, B37 7YU.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from
Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be
privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes
End Road, Hayes, Middlesex, UB4 8FE.
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway,
Birmingham Business Park, Birmingham, B37 7YU.