FUJ00066141
FUJ00066141
Peak Incident Management System
[Call Reference PCo0s2148 [Call Logger Customer Call_-- EDSC
Release fTargeted At-- M1 [Top Ref. Ic
(Call Type Live Incidents Priority. IC -- Non-critical
‘Contact, IEDSC [Call Status [Closed -- Reconciliation - resolved
(Target Date 18/08/2000. Effort (Man Days) 0
Summary AD005008 -Receipts and Payments mismatch
[All References [Type Value
ISSCKEL IKEL PSteed5022P him
[Other Ic
[PowerHlelp [:-0008110394
Progress Narrative
Date :11-Aug-2000 09:13:00 User: Customer Call_
CALL PC0052148:Priority C:CallType L - Target 18/08/00 10:13:21
1/08/00 10:00 fad 005008 reports a difference in receipt & payment to’
for CAP20.
1/08/00 10:07 GBogz158
information: please route to John Moran @ MSU.
lf} Call details
Diagnostician name:
customer opened date 11/08/2000 10:00:35
CALL Pc0052148 opened
Date:11-Aug-2000 09:25:00 User:Barbara Longley
Irarget Release updated to CSR-C13_2R
product General/Other/Misc Reconciliation added
the Call record has been transferred to the Team: MSU-Indt Mgt
Hours spent since call received: 0 hours
bate :11-Aug-2000 09:44:00 User:John Moran
INew evidence added - CA line differences Report for CAP 20
IF} Response :
this of
ce is newly migrated but there was no migration error. Please
investigate how the following totals were reported to the cash account.
Receipts Total 568419
Payments Total 56881
Difference -400.00
It have attached the cash account line report to help with investigation.
[END OF REFERENCE 20968483]
Responded to call type L as Category 40 -Incident Under Investigation
the response has been flagged to the gateway team for validation
[the Call record has been transferred to the Team: EDSC
Defect cause updated
Hours spent since call received: .3 hours
to 40:General - User
Date:11-Aug-2000 13:24:00 User:Barbara Longley
The call summary has been changed from
fad 005008 reports a difference in receipt & payme
[the call summary is now:
PADO05008 -Receipts and Payments mismatch
bate:14-Aug-2000 08:02:00 User:Paul Steed
the call record has been assigned to the Team Member: Paul Steed
Defect cause updated to 99:General - Unknown
Hours spent since 0 hours
receive
bate :14-Aug-2000 13:09:00 User:Paul steed
IF} Response +
It have found what I believe to be a MiECCO dif
[END OF REFERENCE 21009511
Responded 11 type L as Category 40 -Incident Under Investigation
the response was delivered to: PowerHelp
erence of £403.16.
bate:14-Aug-2000 14:35:00 User:Paul Steed
INew evidence added - Complete zipped text format message store
lr} Response
It have been unable to track down the £4
[END OF REFERENCE 21015521]
0.00 difference.
Responded to call type L as Category 40 -Incident Under Investigation
the response was delivered to: PowerHelp
the Call record has been transferred to the Team: QFP
Hours spent since call received: 0 hours
FUJ00066141
FUJ00066141
bate:14-Aug-2000 16:29:00 User:Les Ong
the Call record has been transferred to the Team: EPOSS-FP
Hours spent since call received: 0 hours
Date :15-Aug-2000 10:07:00 User:Gerald Barn
the Call record has been transferred to the Team: EPOSS-Dev
Hours spent since call received: .1 hours
Date :15-Aug-2000 10:08:00 User:Gerald Bar:
the call record has been assigned to the Team Member: Gerald Barnes
Hours spent since call received: .1 hours
Date:15-Aug-2000 13:34:00 User:Barbara Longley
7} Response
the Call record has been assigned to EPOSS-Dev Team Membe:
[END OF REFERENCE 21063598]
Responded to call type L as Category 40 -Incident Under Investigation
Gerald Barnes
Date:15-Aug-2000 13:35:00 User:Barbara Longley
Ithe response was delivered to: Powerlelp
pate :15-Aug-2000 14:52:00 User:del(01/01 Denise Jackson)
lore authorised categorisation C
lrarget Release updated to MiClone
the call references have been updated. They are now:-
JoRIGINATOR : Phelp
powerHlelp : B-0008110394
Im Other : c
Date :15-Aug-2000 14:57:00 Use
target Release updated to M1
de1(01/01 Denise Jackson)
bate :17-Aug-2000 17:06:00 User:Gerald Barnes
iF} Response :
fter a lot of investigation it is felt that the likely cause of this is the
£200 unpaid cheque migrated from stock unit BM
__ GRO
lwork is continuing to try and work out why this causes a problem exactly. It
is felt that apart from this all the figures are correct.
[END OF REFERENCE 21169465]
Responded to call type L as Category 40 -Incident Under Investigation
[the response has been flagged to the gateway team for validation
Date :17-Aug-2000 20:11:00 User:
7} Response
It now think I see the problem.
Ithe original MiECCO unpaid cheque is in mode RISD. This is not a defined mode
for EPOSS and the Cash Account mappings for product 5 do not have a place
defined for RISD and hence the action is undefined; but ( and I will confirm
this later ) probably use SC serve customer as default which maps it to
stock. If it had been mapped as a ROOP instead then the cash account would
nave balanced.
(END OF REFERENCE 21172971
Responded to call type L as Category 40 -Incident Under Investigation
Ithe response has been flagged to the gateway team for validation
Date :18-Aug-2000 09:48:00 Use
iF} Response :
Following my last analysis I have found some more.
there is a default for transactions defined in the Cash Account; and in this
case it is as stated SC server customer. My statement that ROOP would have
corrected the problem was not correct - I meant RIOP. At CI4 only there is a
collection ProductModes that gives the allowed modes for a given product - we
erald Barnes
jcould validate against this for each
future.
[END OF REFERENCE 21182004]
Responded to call type L as Category 38 -Potential Problem Identified
Ithe response has been flagged to the gateway team for validation
transaction to detect such problems in
FUJ00066141
FUJ00066141
bate :18-Aug-2000 13:21:00 User:Gerald Barnes
7} Response :
rurther to my earlier statements
already detected thi
—————————
land this transaction points at the failing transaction.
lone way of preventing this problem in the future would be for POCL to provide
la sensible RISD mapping for product 5 mapping it on the receipts side of the
I now see that DailyReconcil
iation had
problem.
cash account ( rather than it being treated as server customer which puts it
on the payments side causing the misbalance ).
[END OF REFERENCE 21209017]
Responded to call type L as Category 62 -No fault in product
Hours spent since received: 27 hours
Defect cause updated to 16:Development - Reference Data
Ihe Call record has been transferred to the Team: EDSC
Ihe response has been routed to the gateway team for validation
Date:18-Aug-2000 13:28:00 User:Barbara Longley
lthe call record has been assigned to the Team Member: Paul Steed
Hours spent since call received: 0 hours
bate:18-Aug-2000 14:08:00 User:Paul steed
Ihe call references have been updated. They are now:—
JORIGINATOR : Phelp
PowerHelp : E-0008110394
lv Other : C
ISSCKEL : PSteed5022P.htm
Ihe Call record has been transferred to the Team: MSU-Indt Mgt
Hours spent since call received: 0 hours
bate:18-Aug-2000 14:30:00 User:Paul Steed
lr} Response :
lcerald Barnes has included the wrong message store line. The one he has
included is from the rollover of the SU, not the original one entered a few
inutes earlier. It does not affect the overall result but note that
[END OF REFERENCE 21214562]
Responded to call type L as Category 40 -Incident Under Investigation
Ithe response was delivered to: PowerHelp
bate :21-Aug-2000 09:34:00 User:John Moran
7} Response
Ihe cause of this mis balance is down to a migration issue.
the ECCO transaction was for product 5.
ithe mode for this migrated transaction was RISD.
here is no corresponding Horizon RISD. The closest is RIOP.
lwhat Horizon does in these cases is migrate the transaction a:
customer transaction by default
serve
his meant the transaction was migrated correctly as a stock increase (Table
5), but incorrectly migrated as a sale of product 5.
fhe net effect of this is that the transaction was reported twice to the
payments table in table 1085, and as a “sale” of 5 which increased cash.
this caused the Cash account to misbalance by 2 * £200.00 = £400.00
[END OF REFERENCE 21241217
Responded to call type L as Category 68 -Administrative Response
Hours spent since call received: .3 hours
Ihe Call record has been transferred to the Team: EDSC
fhe response has been routed to the gateway team for validation
FUJ00066141
FUJ00066141
Date :21-Aug-2000 09:40:00 User:Barbara Longley
the call record has been assigned to the Team Member: Paul Steed
Hours spent since call received: 0 hours
bate :21-Aug-2000 10:01:00 User:Paul steed
i} Response :
[the call logger has been given the reason for the discrepancy (MiECCO) and
nas presumably raised a BIM.
[END OF REFERENCE 21242298]
Responded to call type L as Category 90 -Reconciliation - resolved
Hours spent since call received: 0 hours
CALL PC0052148 closed: Category 90, Type L
the response was delivered to: PowerHelp
bate:21-Aug-2000 10:54:00 User:_Customer Call_
pate and time complete: 21/08/2000 11:56:07
service Complete (Confirmation) Received
Root Cause [Development - Reference Data
Logger ‘Customer Call_ -- EDSC
Subject Product IGeneral/Other/Misc -- Reconciliation (version unspecified)
Assignee Deleted User -- EDSC.
Last Progress [21-Aug-2000 1
54 -- Customer Call _