POL00001264
POL00001264
Peak Incident Management System
_Customer Call_ -- EDSC
BI 3 S82R 0512060248
ive Incidents/Defects
i
i
4
i
I
i
i
i
i
:
i
i
i
F/318.1/1
ate:06-Dec-2005 10:35:43 User:_Customer Call_
‘ALL PC0129767 opened
etails entered are:-
ummary:The PM at this branch sent letter to SubPostMaster
ate/Time Raised: Dec 6 2005 10:12AM.
riority: B
‘ontact Name: DENISE MILLER - 7224 3285
roduct Site: 426519
vestigate. Remedy Ref: H14268443.
16/12/05 10:20 uk621573
vidence: Dave Wilcox findings:
16/12/05 - 10:01
ST exhibits the same problem so this is how it goes:-
) Sell a foreign currency (in this case Euro) and
ettle transaction to Cash (probably doesn't matter how you
ettle but Cash is the observed error).
) If you then loot at the transaction log you find that
ere are 3 transactions recorded: Euro value without
argin (-ve)with txn ident with -2 at the end : Margin value
e) also with txn ident also with -2 at the end:
‘ash (+ve) with txn ident with -3 at the end.
}) If you now reverse the Cash transaciton (the one which
as -3 at the end) you get a receipt which shows that the
ull amount has been reversed (i.e. it looks as thought
ou've achieved what you expected) but a balance snapshot shows
learly that the Margin part of the transaction was not
versed (as indicated by the PM in the magazine).
) Now an interesting wrinkle added to this when we
hecked on LST - having done a reversal which told you that you
should give the customer his money, if you now go and try to
verse the transaction with the -2 on the end, you are
lowed to do it, it tells you to give the customer his money
gain! but the end result on the balance snapshot is that
verything appears to be completely OK and doesn't recognise
‘at the two reversals have actually been performed and you've
een told to give the customer his money twice! There is
ite possibly more we can do to show holes in the mechanism
ut this seems to support the information the PM wrote to
ubPostMaster.
6/12/05 10:32 SYSADM
pen OTI: Automatic Open OTI
‘**Updated by Denise Miller at 06/12/2005 10:32:03
16/12/05 10:31 uk621573
EASSIGN: Call # E-0512060248 was Reassigned from Denise Miller,
roup BIM Visits to Group EDSC1
6/12/05 10:12 The PM at this branch sent letter to SubPostMaster (Nov 05) which R.Brunskill passed to David Wilcox to
POL00001264
POL00001264
F/318.1/2
POL00001264
POL00001264
ate:06-Dec-2005 10:43:16 User:Lorraine Elliott
he call summary has been changed from:-
‘The PM at this branch sent letter to SubPostMaster
¢ call summary is now:-
‘AD 426519 sent letter to SubPostMaster
Date:06-Dec-2005 10:46:30 User:Lorraine Elliott
oduct General/Other/Misc -- Unknown General/Other/Misc added.
ate:06-Dec-2005 10:46:36 User:Lorraine Elliott
he Call record has been assigned to the Team Member: Anne Chambers.
‘Progress was delivered to Powerhelp
ate:06-Dec-2005 11:01:50 User:Anne Chambers
The call summary has been changed from:-
‘AD 426519 sent letter to SubPostMaster
The call summary is now:-
'AD426519 - reversals of foreign currency txns
Date:06-Dec-2005 14:05:22 User:_Customer Call_
MPTY 06/12/05 14:01 uk621573 BIM Visits information: @@BIM - This issue has now been escalated by Dave Baldwin.
‘to Dave Hulbert (POL). Can you please upgrade call to 'A’
priority.
F/318.1/3
POL00001264
POL00001264
ate:06-Dec-2005 14:39:40 User:Anne Chambers E
Start of Response] a
clarify: SubPostMaster is a magazine. The Nov 2005 issue contained a letter from the PM who encountered this problem.
pparently the PM phoned the helpdesk at the time. I presume this was NBSC, I can't see any Powerhelp calls.
lly this is user error. The transaction log scarch on the session id displayed 3 entries: for currency, margin, and cash. For the
-xisting reversal, he entered the transaction id for the cash settlement only.
he had entered the transaction id for the currency/margin (they are the same), both parts would have been reversed as he intended.
eversal of a transaction settlement is always allowed but is ineffective - it just reverses cash and settles to cash, as is stated on the
screen and on the reversal receipt. Net impact on anything is nil. A balance snapshot taken after this will still show both the currency I
ving been sold, and the margin. This should have indicated that the reversal had not been done as intended.
ecause the PM then adjusted his stock to remove the currency which he had failed to reverse, the margin for the transaction
mained (because margin is not stock). Hence he had a loss to the value of the margin.
‘an this be corrected via a Transaction Correction?
he Bureau de Change On Demand section of the Operations Manual (dated 20 April 2005) mentions reversals only in passing. The
ureau de Change Pre-Order Service section (27 April 2005) includes a full description of how to reverse a buy-back transaction.
his description is applicable to all bureau transactions. Perhaps the documentation should be reviewed. It is also important that the
usiness help desk understands that sessions are split into separate transactions and that, if a reversal does not appear to have
orked, maybe the wrong transaction was reversed.
it possible for reversal of cash settlements to be prevented? This may not be desirable anyway, sometimes the settlement is 3
versed intentionally if the wrong method of payment had been used (cash instead of cheque say). Or could a warning be output if
¢ transaction being reversed is cash?
enise Miller has asked me to increase the call priority to A. I have not attached evidence, it is easy to reproduce as David Wilcox
as described above. Passing to EPOSS Dev via QFP. a
End of Response] E
‘esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Powerhelp
ours spent since call received: 0 hours.
ate:06-Dec-2005 14:40:00 User:Anne Chambers
ie Call record has been transferred to the team: QFP
ogress was delivered to Powerhelp
ate:06-Dec-2005 14:49:43 User:Anne Chambers 7
he call Priority has been changed from B
he call Priority is now A
ate:06-Dec-2005 15:31:06 User:Lionel Higman
¢ Call record has been assigned to the Team Member: Mark Scardifield
ogress was delivered to Powerhelp.
ate:06-Dec-2005 15:53:09 User:Richard Craig L
he Call record has been transferred to the team: EPOSS-Dev LE
he Call record has been assigned to the Team Member: Ric Craig
rogress was delivered to Powerhelp
F/318.1/4
POL00001264
POL00001264
ate:06-Dec-2005 16:28:31 User:Anne Chambers :
‘ference Added: SSCKEL AChambers2252R. E
ate:06-Dec-2005 16:59:23 User:Richard Craig
he events reported by the PM are slightly more complicated but the essential problem is:
) He attempted to reverse the transaction but reversed the settlement instead.
) He attempted to compensate for the resulting discrepancy by adjusting the stock.
he attached spreadsheet shows the steps involved in the simple case, what happens to the stock and takings and how this results in
¢ takings being short.
ate:06-Dec-2005 17:01:34 User:Richard Craig C
vidence Added - Spreadsheet showing discrepancy resulting from erroneous reversal and stock adjust.
ate:06-Dec-2005 17:10:25 User:Richard Craig
is is not a fault in the system. However, it may be desireable to change the system to better help the PM to reverse transactions
ind also to avoid reversing settlements when this is not the intention. E
assing to design for their input. ij
ate:06-Dec-2005 17:10:39 User:Richard Craig
he Call record has been transferred to the team: ASD
¢ Call record has been assigned to the Team Member: Gareth Jenkins
rogress was delivered to Powerhelp
ate:07-Dec-2005 11:01:33 User:Kevin McKeown
‘ould reversal flag be set to No for settlement items (POL data)? Or would this have a side effect on genuine reversals?
ate:07-Dec-2005 11:22:01 User:Gareth Jenkins
Start of Response]
'm not really clear as to why this has been raised as a PEAK.
s explained above, the root cause is a user error, though it is also clear that the user documentation (which is Post Office Ltd's
sponsibility) could also be clearer. There are many things that we or Post Office could do (some are simple Ref Data changes as
dicated earlier in this PEAK). However we cannot make any changes without guidance from Post Office.
Il I can suggest is that we make Post Office aware of the analysis carried out above and ask them what (if anything) they want to I
lo about it.
End of Response]
esponse code to call type L as Category 94 -- Final -- Advice and guidance given
outing to Call Logger following Final Progress update.
lours spent since call received: 0 hours
ate:07-Dec-2005 11:26:02 User:Lorraine Elliott
he Call record has been assigned to the Team Member: Anne Chambers
rogress was delivered to Powerhelp
F/318.1/5
POL00001264
POL00001264
‘Date:07-Dec-2005 13:49:18 User:Anne Chambers
Start of Response]
.s explained above, the root cause is a user error, though it is also clear that the user documentation (which is Post Office Ltd's
sponsibility) could also be clearer. There are many things that we or Post Office could do (some are simple Ref Data changes as
dicated earlier in this PEAK). However we cannot make any changes without guidance from Post Office.
I can suggest is that we make Post Office aware of the analysis carried out above and ask them what (if anything) they want to
do about it.
Advice and guidance has been given by SSC, Development and Design. This needs to be passed back to POL
I don't know what the correct route is for responding to a letter in Subpostmaster, so am passing the information back for the call
gger to decide how this should be progressed.
End of Response]
esponse code to call type L as Category 94 -- Final -- Advice and guidance given E
Routing to Call Logger following Final Progress update. E
vice Response was delivered to Powerhelp
Date:07-Dec-2005 13:49:18 User: Anne Chambers
CALL PC0129767 closed: Category 94 Type L
Date:07-Dec-2005 13:49:18 User:Anne Chambers
ours spent since call received: 0 hours
Defect cause updated to 39 -- General - User Knowledge
1
Date:07-Dec-2005 14:06:46 User:_Customer Call_
Consumer Phelp has received the call closure
eneral/Other/Misc -
Customer Call
F/318.1/6