POL00029356
POL00029356
Peak Incident Management System
Call Reference PC0181609 Call Logger _Customer Call_ -- EDSC
Release Reported In -- T86 Top Ref 1190216
Call Type Live Incidents/Defects Priority _ C-- Non-critical
Contact EDSC Call Status Closed -- Avoidance Action Supplied
Target Date 27/05/2009 Effort (Man Days) 0
Summary FAD384238 Payment and receipt mismatch
All References Type Value
SSCKEL KEL obengce3 120K
TRIOLE for Service 1190216
Progress Narrative
Pate:22-May-2009 12:53:53 User: Customer Call_
cALL PC0181609 opened
betails entered are:-
lsummary:Payment recepit mismatch Pm tried to reverse the transact...
‘all Type:1,
call Priority:
lrarget Release
outed to
HNCTDENT MANAGEMENT
Date/Time Raised: May 22 2009 12:33PM
priority: C
contact Name: Ch
contact Phone: {
riginator: XXXXKX@TFSO1
iginator's reference: 1190216
product Serial No:
product Site: 384238
payment recepit mismatch
lpm tried to reverse the transaction
lpm has £12,500 Gain
jould not let her roll over as the £12,500 Gain
could not roll over to TP
Hine
2009-05-22 12:33:32 [ Poulton, Claire]
INIT : create a new request/incident /problem/change/issue
2009-05-22 12:35:57 [ Poulton, Claire]
zneut_en_rmg : Transfer Notification
dent History:
2009-05-22 12:35:57 [ Poulton, Claire]
zneun_en_rmg : Open Notification
2009-05-22 12:36:04 [ Poulton, Claire]
toc _: Payment recepit mismatch
lpm tried to reverse the transaction it reversed the Bureau but not the cash
Jom has £12,500 Gain
jould not let her roll over as the £12,500 Gain
could not roll over to TP
2009-05-22 12:37:08 [ Poulton, Claire]
0G : Where is discrepancy - Cash £12,794, Transaction 14,550 euros
full error message - Payment and receipts mismatch
Juhat report shows discrepancy - Cash declaration
time and date of report printed - 15/05/09 16:59, reversed - 16/05/09 15:32
Last rollover - 13/05/09 18:25 next one is 10/06/09
key strokes ~ PM was trying to balance but this would not let her do this as the discrepancy
stock unit - BCD trying to roll over to BP
POL00029356
POL00029356
005-05-22 12:46:50 I Poulton, Claire)
L0G : Used kel - carde2632N
2009-05-22 12:49:02 [ Poulton, Claire]
LOG : +++ could peak please investigate +++
2009-05-22 12:53:09 [ Poulton, Claire]
IR : Transfer ‘assignee’ from ‘Poulton, Claire’ to '*
Iransfer ‘group' from 'HSH2' to 'PEAK'
2009-05-22 12:53:09 [ Poulton, Claire]
Zneut_en_rmg : Transfer Notification
jDate:22-May-2009 13:09:13 User:Lorraine Elliott
Reference Added: SSCKEL cardc2632N
lDate:22-May-2009 13:09:32 User: Lore.
Product EPOSS & DeskTop -- Unknown
ine Elliott
SPOSS&D-top (version unspe
cified) added.
Dat e:22-May-2009 13:09:48 User:Lorraine Elliott
[fhe call summary has been changed from:—
Payment recepit mismatch Pm tried to reverse the transact...
he call summary is now
fAD384238 Payment recepit mismatch
Date: 22-May-2009 13:09:51 User:Lorraine Elliott
fhe Call record has been assigned to the Team Member: Lina Kiang
Progress was delivered to Consumer
JDate:22-May-2009 1!
Reference Deleted
7:27 User:Lina Kiang
SSCKEL carde2632N
Reference Added: Ls K
bate:22-May-2009 15:47:40 Uscr:Lina Kiang
JDate:22-May-2009 1:
evidence Added - FAI
8:23 User:Lina Kiang
384238-mstore, In
mpleteSummari
Date: 22-May-2009 15:52:39 User:Lina Kiang
Usually the MSU would have raised calls on this FAD since it appeared in 2 IncompleteSummaries and Harvester Exception reports
lated 15/05/09 and 16/05/09. But since this was not done, this problem was not investigated and the exceptions are still sitting
lin the TRT waiting to be actioned.
[these exceptions are related to bureau txns done on 15/05/09 15:59 Mode:SC £12079.46 worth of Euros (which is missing a
settlement line) and a Mode;ER done on 16/05/09 14:30 (which has a cash settlement line). This gave the PM when SU:BDC eventually
rolled into TP(2,2) on 20/05/09 a gain of £12079.71 and a payments and receipts difference of £12079.46.
It thought this might be a quick and easy call but it turned out not to be so since I am on leave next week I am routing this call
to Anne who has dealt with a similar problem PC0175821 (KEL obengc3120K). Sorry, Anne - however unlike PCO175821, nothing has
been done on the TRT and the MSU/POL/PM have not been informed so you are starting with a clean slate.
JDate:22-May-2009 15:52:51 Uscr:Lina Kiang
[the Call record has been assigned to the Team Member: Anne Chambers
Progress was delivered to Consumer
Date: 26-May-2009 15:04:43 Uscr:Anne Chambers
{Start of Response]
[this may need a correction written on the counter, with POL's approval. Or possibly correcting the POLFS feed in such a way that
they can issue a TC? Still thinking about it. Spoke to PM and explained what had happened (they scanned a set of pouches in
reversal too quickly). Next TP rollover is 10th June. PM happy that cause is known and action will be taken.
[End of Response]
lkesponse code to call type L as Category 40 -~ Pending -- Incident Under Investigation
Response was delivered to Consumer
Date: 29-May-2009 09:23:38 User:Anne Chambers
the call summary has been changed from:~
FAD384238 Payment recepit mismatch
[the call summary is now
FAD384238 Payment and receipt mismatch
jDate:29-May-2009 10:09:42 User: Mail Manager_
POL00029356
POL00029356
[External Progress Update Received via Email. ; a
iginator : "Chambers Anne 0" <Anne.Chanbers GRO
lhrrival Date : 29 May 2009 08:39:52 E
subject : FW: PCO181609: Branch 384238 Receipts and Payments mismatch
from: Chambers Anne 0
sent: 28 May 2009 14:59
fto: Drake Claire
cc: Jenkins Gareth GI
subject: PC0181609: Branch 384238 Receipts and Payments mismatch
claire,
As discussed - please send on (with attachment) to Mark Wardle via =
sims.
Branch 384238 (Hanley WHS) had a problem on Friday 15th May, when two -
Jturrency pouches were reversed very close together. As a result, one ~
jral formed Serve Customer transaction was written, for 13500 Euros. The =
value was £12079.46. There was no corresponding settlement line hence =
the session did not net to zero. The following day, the branch reversed =
the transaction, and the reversal settled automatically to cash.
In this case we propose to resolve the effects of the problem by making =
la correction to the data feed to POLFS at the data centre. This leaves =
the branch with a large gain (due solely to the system problem) which =
they Assign to Nominee, but on POLFS the Assigned gain will be negated =
lby our correction, hence centrally the figures are correct.
At the branch
The branch currency holding is correct, because the transaction was =
reversed, but has caused a gain of £12079.46 (because the reversal
settled to cash whereas the original transaction had no settlement
hatsoever). The branch has since rolled the BDC stock unit into a new =
balance period, accepting a gain of £12079.71 which includes a genuine =
lain of 25p. The balance report shows a difference between Receipts and =
Payments of £12079.46.
I have spoken to the Branch Manager and explained that there has been a ~
system problem, caused by rapidly scanning currency pouches when
jreversing them. The next branch TP rollover is scheduled for 10th June.
We suggest that they continue as normal i.e. move the gain to Local
suspense when the stock unit is rolled into the next TP on 10th June,
then clear Local Suspense using Assign to Nominee. This is their normal =
jorocess. It is important that they realise that any discrepancies apart ~
from the £12079.46 caused by this problem must be investigated and
resolved in the usual fashion. Any residual gain / loss can be Assigned
to Nominee as normal. Their Branch Trading Statement will show a Trading
Position of £12079.46 (normally zero).
I have not discussed this with the manager.
I have successfully completed a TP rollover for the branch on a test =
system to confirm that the expected messages are generated and there are
Ino unexpected side-effects.
Data to be sent to POLFS
Since there are unharvested transactions for 15th and 16th May, nothing =
from the branch for those days has yet been sent to POLIS.
Also, the data can only be sent if it nets to zero. This will not be =
the case for 15th May where the settlement line was missing. We will =
Inced to make a correction centrally so it nets to zero, otherwise it =
cannot be sent.
The malformed SC and ER transactions will be repaired sufficiently to =
Ibe sent to POLMIS and POLFS.
An extra entry will be added to the POLFS data for 15th May:
Article NAQ0000017 account 531100 (Agents Debt in Customer Accounts) =
value -£12079.46.
This will
(a) cause the transactions for 15th May to net to zero and thus be sent =
Ito POLFS
(b) negate the entry generated at the branch for account 531100 when =
they complete their TP rollover on 10th June.
(Additional clarification:
Currently TPS_POL FS Summaries Incomp shows 15-May-2009 £0.00, =
H6-May-2009 £12,079.46.
Unharvested transaction values are 15-May-2009 £12,079.46, 16th May =
12,079.46
So once repaired via the TIP repair tool, TPS_POL FS Summaries Incomp =
11 show 15-May-2009 £12,079.46, 16-May-2009 £0.00
Data for 16th May will be sent immediately because no longer any =
jnarvester exception and nets to zero. Correction of ~£12,079.46 will
be applied, by adding a new row to the TPS POL FS Summaries Incomp table =
for 15th May, using the Assign to Nominee account. )
POL00029356
POL00029356
Action by Post Office Ltd
Post Office may want to handle further communication with the branch ~
regarding the next rollover (see above).
The branch reports will show a gain, Assigned to Nominee, which does
Inct exist on POLFS. No further action should be required on POLFS long =
term, but between when the correction is made and llth June, there will =
be a negative gain of £12079.46 in account 531100.
The correction needs to be made at the data centre as soon as possible,
since no data for 15/16 May has yet been sent to POLFS for this branch. =
can Post Office confirm that they are happy for us to make this =
correction to the POLFS feed, and let us know if they will be contacting ~
the branch or whether we should do so.
The attached spreadsheet shows the messages and accounts involved. I'm =
appy to try to answer any further questions.
Anne.
Anne Chambers
Systems Support Centre, Royal Mail Group Account
11, Berkshire RG12_85!
Fujitsu Services Limited, Registered in England no 96056, Registered ~
fice: 22 Baker Street, London W1U 3BW.
This email is only for the use of its intended recipient. Its contents =
lare 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.
\dded evidence item '384238.x1s' from Email attachment
jDate:01-dun-2009 1.
[Start of Response]
OCR 22690 has been raised. Sending to EDSC for progression.
hile returning call, please include file name in which outstanding data was sent to POLFS.
9:33 User:Claire Drake
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
[Date:01-dun-2009 14:33:41 User
lock 22690 App.
Steve Parker
Date:01-dun-2009 16:06:06 Uscr:Anne Chambers
[Start of Response]
It have made the harvester corrections, but I want to make sure they have been processed as expected before making the fimal
change to the incomplete summaries table.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Ikesponse was delivered to Consumer
[Date:02-dun-2009 13:48:05 User:Anne Chambers
[Start of Response]
2 repaired transactions went to POL MIS in files W_135800.TP and W_136800.TP.
lthe data for 16th May was sent to POLFS in file IF20090601065.BLE.
[the branch now has an entry on the Incomplete Summaries report for 15th May (because the correction means that day no longer nets
Ito zero). I have made the database change to include an extra line for account 531100, as described above, so the data will be
sent tonight.
[End of Response]
Response code to call type L as Category 40 -
Response was delivered to Consumer
Pending -- Incident Under Investigation
JDate:03-gdun-2009 0:
9:19 User:Anne Chambers
[Date:03-dun-2009 09:27:29 User:Anne Chambers
[Start of Response]
in addition to data already sent and detailed above, the data for 15th May was sent to POLFS in file 1F20090602065.BLE.
It understand that POL will contact the branch regarding the branch TP rollover. I will keep this call open until this has been
completed so please return the call to me once BIMS activity completed. Thanks.
POL00029356
POL00029356
[End of Response]
Response code to call type L as Category 40 ~~ Pending -- Incident Under Investigation
Response was delivered to Consumer
Date:03-dun-2009 09:27:40 User:Anne Chambers
the Call record has been transferred to the team: MSU-Indt Mgt
progress was delivered to Consumer
Date:04-Jun-2009 13:54:28 User:Claire Drake
[Start of Response]
[thank you Anne.
It have issued the file details and other information to POL.
eturning call as requested.
[End of Response]
Ikesponse code to call type L as Category 40 -- Pending -~ Incident Under Investigation
JDatc:04-Jun-2009 13:54:33 Uscr:Claire Drake
[the Call record has been transferred to the team: EDSC
progress was delivered to Consumer
Jbate:04-dun-2009 14:01:51 Usecr:Lorraine Elliott
the Call record has been assigned to the Team Member: Anne Chambers
Progress was delivered to Consumer
jate:04-Jun-2009 18:16:35 User:Anne Chambers
lsvidence Added = D of correctio
Date:05-dun-2009 1
[Start of Response]
IM should be rolling into a new TP on Wednesday 10th June. If she rings in quoting this call ref and asking to speak to Anne at
Srd line, please let me know immediately via
[End of Response]
response code to call type L as Category 40
esponse was delivered to Consumer
Pending -- Incident Under Investigation
Date:11-Jun-2009 09:55:27 Uscr:Anne Chambers
[Start of Response]
le has rolled over all the stock units but there was a bit of confusion and local suspense was initially cleared to cash. PM
repeated the SU balance and this time cleared LS using Assign to Nominee. So on the balance report the amount transferred to and
from suspense is twice what was expected. But overall everything is correct, and a gain of £11827.48 was assigned to nominee. The
lexpected gain caused by the system problem was £12079.46, so in fact the branch seems to have had a loss of £151.98 in TP 2.
fice rollover not done yet. I phoned to reassure them that all looks ok, PM not available until 10:15.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
JDate:ai-gun-2009 1:
{Start of Response]
Yesterday I rewrote the Sessions object for user SWI001, changing the State from Active to Ended. Counter 5 was unusable and the
ser couldn't be detached from the stock unit. Nothing to do with the original problem, but was preventing SU BB balance, and
Inence the office balance from being completed.
1:05 User:Anne Chambers
fall stock units and the office have now rolled over and the outcome is as predicted. Everything should now be consistent at the
ranch and on POL FS. PM appreciated the help given and is happy to close the call.
[End of Response]
Response code to call type L as Category 70 -- Final -
routing to Call Logger following Final Progress update.
service Response was delivered to Consumer
Avoidance Action Supplied
bate:ai-dun-2009 12:31:05 User:Anne Chambers
CALL PCO181609 closed: Category 70 Type L
bate:4i-dun-2009 12:31:05 User:Anne Chambers
jbefect cause updated to 14 -- Development - Code
jbate:11-Jun-2009 14:25:46 Uscr: Customer Call_
consumer XXXXXX@TFS01 has acknowledged the call closure
POL00029356
POL00029356
Root Cause Development - Code
Logger _Customer Call_ -- EDSC
Subject Product _EPOSS & DeskTop -- Unknown EPOSS&D-top (version unspecified)
Assignee Customer Call_ -- EDSC
Last Progress 11-Jun-2009 14:25 -- Customer Call_