FUJ00081865
FUJ00081865
Peak Incident Management System
Call Reference PC0195380 Call Logger _ Customer Call_ -- EDSC
Release Targeted At -- HNG-X 01.08 Hot Fix Top Ref CTR_APP_X0108 V046
Call Type Live Incidents/Defects ___ Priority B -- Business restricted
Contact EDSC Call Status Closed -- S/W Fix Available to Call Logger
Target Date —_ 05/03/2010 Effort (Man Days) 0
Summary -FAD506246 Rem In transaction appears twice
All References Type Value
Release PEAK PCO195911
Product Baseline CTR_APP_X0108_V046
SSCKEL : KEL acha4221Q
‘TRIOLE for Service 2080430
Collections Name User Date
: } PrescanCounter : Lorraine Elliott 19-Apr-2010 09:00:01
Progress Narrative
foate:02-Mar-2010 11:06:23 User: Customer Call_
FALL PCO195380 opened
Details entered are:~
Summary:pm did rems in transaction on node 2. pm scanned the barcode...
all Type:
fall Priority:a
ffarget Release: T86
outed to:EDSC - Unassigned_
priority: A
ontact. Namé
contact Pho!
riginator:
lm did rems in transaction on node 2. pm scanned the barcode. checked the rems report the trans appears to have gone in twice.
incident History:
010-03-02 10:59:46 [ Vasse, Anthony]
INIT : create a new request/incident /problem/change/issue
2010-03-02 11:01:39 [ Vasse, Anthony]
Jzneun_en_rmg : Open Notification
010-03-02 11:01:39 [ Vasse, Anthony]
bneut_en_rmg : Transfer Notification
10-03-02 11:01:44 [ Vasse, Anthony]
.0G : su branch manager
ser name bja003
lm went to back office £14
Jom pressed £5 for rems in.
bm pressed pouch delivery nos 21.
om scanned barcode and completed the transaction.
2010-03-02 11:03:05 [ Va:
FLD : FIELD='zcbflag' OLD=
Anthony]
NO! NEW="YES*
2010-03-02 11:03:09 [ Vasse, Anthony]
.OG : session id 1/104754
time of transaction 13:04 on 23/2.
2010-03-02 11:04:02 [ Vasse, Anthony]
toc : pm did not get any error messages.
Jom checked the rems report for the same day.
FUJ00081865
FUJ00081865
che yen is showing twice.
2010-03-02 11:05:35 [ Vasse, Anthony]
IR : Transfer ‘group’ from 'HSH6' to 'PEAK*
010-03-02 11:05:35 [ Vasse, Anthony]
lneut_en_rmg : Transfer Notification
joate:02-Mar-2010 11:13:33 User: Lorraine Elliott
The call summary has been changed from:—
pu did rems in transaction on node 2. pm scanned the barcode...
fhe call summary is no
rAD506246 trans appears twice
[Date:02-Mar-2010 11:13:42 Uscr:Lorraine Elliott
Product EPOSS & DeskTop -~ Counter Common (ver:
ion unspecified) added.
e:02-Mar-2010 11:28:09 User:Lorraine Elliott
fhe Call record has been assigned to the Team Member: Anne Chambers
progress was delivered to Consumer
JDate:02-Mar-2010 12:39:46 User:Anne Chambers
[Start of Response]
It can confirm that on 23rd Feb, node 1 (not 2), user BJAQ03 remmed in Swiss francs, and £80 of 2p coins.
ach barcode appears to have been scanned just once, but the 2p coins transaction wae added to the basket twice, and two identical
heceipts were printed for the coins rem in.
I''m downgrading the call to B because this problem is not preventing them from trading, but I am continuing to investigate.
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Inc:
esponse was delivered to Consumer
dent Under Investigation
jate:02-Mar-2010 12:39:50 User:Anne Chambers
Whe call Priority has been changed from A
he call Priority is now B
[Date:02-Mar-2010 14:37:44 Uscr:Anne Chambers
[Start of Response]
I haven't been able to reproduce this problem, probably because on my test system there are no auto-rems set up. But I think I can
see the probable cause.
the PM scanned a currency barcode (pouch containing 1000 Swiss Francs) then a cash barcode (pouch containing £80 of 2p coins). ‘Then
Inter to continue, and Print.
[he first Delivery Receipt was printed, but then the PM pressed Retry (instead of Continue). This returned him to the screen with
the Print option, but he then pressed Prev twice, back into the barcode scans. Then Enter, Print and forward through the screens as}
xpected,
then two
[this produced 2 delivery receipt 2 barcodes
em In slips for the 2p coin pou
as expected (with jus
= it accepted this pouch twice.
shown), then the Rem In slip for the Swiss Franc
[End of Response]
sponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
joate:02-Mar-2010 15:21:46 User:Anne Chambers
[Start of Response]
Pouch 399345086528, £80 2p coins, was accepted twice at branch 506246 on 23rd February, due to a system problem when the clerk usedI
he Prev button several times during the Delivery acceptance.
this has caused them a loss of £80. They cannot reverse this transaction. The pouch acceptance will show up twice in POLFS as well.
passing call to MSU to inform POL via BIMS - can they issue a TC? (I did initially advise the PM to contact NBSC but she was not
onfident that this would result in an action being taken).
Please then return call to me so I can pass it on to development.
[End of Response]
esponse code to call type L as Category 40 -- Pending -~ In
esponse was delivered to Consumer
dent Under Investigation
[Date:02-Max-2010 15:22:01 Uscr:Anne Chambers
[the Call record has been transferred to the team: MSU-Indt Mgt
rogress was delivered to Consumer
FUJ00081865
FUJ00081865
Date: 02-Mar-2010 15:48:53 Uscr cheryl cara
Chambers
jDate:03-Mar-2010 09:43:12 User:goanne Ball
[Start of Response]
ny thanks.
Final BIMS issued to POL.
Returning call to Anne Chambers as requested
[End of Response]
Ikesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
lesponse was delivered to Consumer
pate:03-Mar-2010 09:43:21 Uscr:doanne Ball
[the Call record has been transferred to the team: EDSC
progress was delivered to Consumer
Te103-Maxr-2010 09:46:50 Uscr:Lorraine Elliott
the Call record has been assigned to the Team Member: Anne Chambers
Progress was delivered to Consumer
Date:03-Mar-2010 10:37:42 User:Anne Chambers
[fhe call summary has been changed from:-
IfAD506246 trans appears twic!
he call summary is now:
"AN506246 Rem In transaction appears twice
Date:03-Mar-2010 1
[Start of Response]
See my update above 02-Mar-2010 14:37:44 .
evidence contains extract from POC.1og and message-log. Please investigate. This problem can
branch to identify, so it does need to be fixed.
[End of Response]
eaponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
6:59 User:Anne Chambers
se losses which are hard for the
Te:03-Mar-2010 10:57:12 User:Anne Chambers
the Call record has been transferred to the team: xCtr_GDC
Progress was delivered to Consumer
[Datc:03-Max-2010 12:26:31 Uscr:Subhra Suklabaidya
[fhe Call record has been transferred to the team: xCtr_¢
the Call reco
M_GDC
rd has been assigned to the Team Member: Chaitanya Pothapragada
ogress was delivered to Consumer
[Date:03-Max-2010 1:
[Start of Response]
6:05 User:Chaitanya Pothapragada
ble to reprodu
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Consumer
the issue, design in progress....
Date:03-Mar-2010 1
[Start of Response]
just seen another example of this in live... this time they scanned the barcodes, then pressed Previous instead of Enter after the
Hast barcode, and then went forward again. They now have a loss of £25,000.
[End of Response]
esponse code to call type L as Category 40 -- Pending -~ Incident Under Investigation
lesponse was delivered to Consumer
5:47 User:Anne Chambers
Date: 04-Mar-2010 11:36:08 Uscr:Lionel Higman
fhe call Target Release has been moved to Targeted At -- HNG-X 01.08 Hot Fix
[Date:04-Max-2010 11:36:23 Uscr:Lionel Higman
eference Deleted: SSCKEL acha42219
[bate:04-Mar-2010 14:30:25 Us:
Chaitanya Pothapragada
FUJ00081865
FUJ00081865
[Start of Response]
luring pouch delivery, When barcode is scanned and hit enter it will land in print/preview/late date page. By this time, the syster
lreates a list of valid barcodes to be processed.
aut while in print/preview/late date page, prev is hit (or) during entering barcodes the cursor is brought to text box where a
uch is already entered and then proceeded furthur, this issue occurs, because of the usage of prev button the pdl engine may
clone the pouch list objects.
le propose to disable the prev button when a valid pouch id is entered in the first page of pouch delivery.
Wwe also noticed that in print/preview/late date page, when print was initially selected(when first pouch receipt was printed), the
ev should be disabled, this is not happening. The prev button is disabled only when preview is done and second pouch receipt is
printed. This should also be fixed.
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Consumer
(Eo:05-Mar-2010 08:03:08 User: customer Call_
Fre have received notification from POL regarding the problems at this office.
SB
mn the 1st of March at the close of business we found that on node 5 the cash was short of £1000. All of the figures for that day
atch the figures presented at the time of each transactions. An instant saver withdrawal for £1000 was transacted that day, but 1
las unable to find this transaction using the online report facility. I feel very anxious as I believe a system error has occurred
ht the time of this transaction.
In the 2nd of March a transaction for a cash withdrawal was completed where the system commanded a member of staff to issue the
froney to the customer on screen but the receipt printed for that transaction printed out a decline slip. The customer was honest
enough to bring back the decline receipt a day later with the money.
n the 2nd of March on node 5 a £220 cash deposit was authorised on screen but twenty minutes later the customer brought back a
receipt that stated the transaction had declined. We contacted the NBSC as and when the customer produced the receipt. The NBSC
stated that the transaction approved on the system and had no idea why the money was not deposited and why the decline slip was
rinted.
rem was scanned in our system and all figures had doubled up. The helpline team was notified at the time to which they seemed
jore confused as to why it happened than me!
Another error occurred on the system when 10 items of postage seemed to disappear for no reason half way through a customer's i
transaction. The system commanded no money to be taken from the customer on screen or by receipt.
transaction on node 2 where a car tax was entered disappeared; the system was not even being uséd when the tax information
Hisappeared from the system as the clerk who was processing the transaction was writing the details of the vehicle on the tax disc!
ithe help desk team simply regarded the matter as a glitch. We were told to complete the transaction again.
[he Helpline team seem not to be sure of any query we bring to them, they are guarded to take ownership to any problem and never
lreply to any calls. It is a shame as the only person we get results with is Garry Elenor which makes no sense as he is part of the
jorizon training team.
since the four days of closure we have lost over £5000 to date. This includes staff wages, retail closure, combined salary and
losses incurred on the counters.
tt has been noted when speaking to a helpline representative in Bangalore our servers are not online all the time and communicatingI
5 there is a software problem. Our cash declarations have not once been received since the new system has taken over.
j@ have no idea when the system will crash and for how long it crashes. Our customers are very upset with the way our business now
trades, as our office had a very low rate of closure which now seems to have spiralled out of control!
i really wish that the new system was not undertaken in our office as it is adding stress on the customers ourselves and our staff.
Ii have a deep reqret in initially volunteering to take part in this new pilot scheme, as I did not expect to have these
complications with such poor services from the helpline.
Infortunately our migration officer is away (Garry Elanor ) leaving us with no one with the means to correct our issue today.
Why should it be my liability to recoup all the losses in this already declining business, when these systems should have adequate
lontingencies for any such problems that could or would arrive. It seems that the helpline have left me for seven hours now without]
ny intention of calling us back as no one again wants to take ownership over this problem.
JDate:05-Mar-2010 08:04:09 User: Customer Call_
[this is the request from POL
4 discussed with Martin, please can you see the issues below raised by the Postmistress at this branch to the National Federation
£ Subpostmasters.
It have had a quick look on Triole and there have been a number of incidents logged recently about a variety of issues. I see that
the branch have been affected by On Line issues today and yesterday.
Hhis one was not on the NBSC list, so I assume this one that you were contacting. Please confirm when you did this and what the
utcome was.
It see from Triole that the issues today (2089849) has only recently been resolved.
Please can you provide a response to the points raised in the letter no later than llam Friday 5th March.
[if you need me to clear this with anyone, please ring me at 9am to advise.
jbate:05-Mar-2010 08:05:10 User: Customer Call_
lt am making enquires into the on line issues Stated but could you provide an update on the other issues by the deadline.
If you need any further information please contact IMT as a matter of urgency so we may contact the office and provide a response
to pol by the deadline.
Ihank you
[bate:05-Max-2010 08:12:41 Uscr: Customer Call_
It have voiced Peak and advised on the 11 am deadline on this call. Reception stated Anne Chambers was dealing with this and she is
not expected in the office this morning.
It have requested that somebody else pick this and I am waiting for an update.
[Date:05-Max-2010 08:23:19 User: Customer Call_
It have asked SMC for the number of the business developement team but they advise this has to be routed through Peak.
FUJ00081865
FUJ00081865
Walt update from Peak-
Also I have mailed CMT for a response regarding the On line issues.
ate :05-Mar-2010 09:12:58 User:Chaitanya Pothapragada
the Call record has been assigned to the Team Member: Suresh Chitikela
Progress was delivered to Consumer
jate:05-Mar-2010 09:28:35 User:Suresh Chitikela
[Start of Response]
Although Chaitanya's explanation about prev may not be totally corr
prev button is not clearing the old data
Hisabling prev button can be proposed for hot fix immediately.
[End of Response]
espons
code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Consumer
Joate:05-Mar-2010 09:29:56 User:Suresh Chitikela
Action placed on Team:xCtr_OSR_SME, User:Steven Porter
ate:05-Mar-2010 10:51:15 User: Steven Porter
[Start of Response]
SME Review:
signficiant number of issues are raised in this peak.
ror each, please state clearly step by step how to reproduce, and what the incorrect outcome is.
[End of Response]
jesponse code to call type L as Category 40 -- Pending -~ Incident Under Investigation
jesponse was delivered to Consumer
[Date:05-Max-2010 10:51:30 Uscr:Steven Porter
ction has been removed from the call
jbate:05-Mar-2010 12:30:00 User:Chaitanya Pothapragada
[Start of Response]
fou need to have auto remin pouch id to reproduce the is
Iso -> Rems & Transfers -> Delivery
can a auto remin barcode -> hit enter -> hit enter to go to Print/Preview/Late Date
Print the delivery receipt, MSG00055 will be displayed. Hit Retry brings to Print/Preview/Late Date
iow hit PREV twice, brings the cursor to the pouch barcode text box where pouchid is already entered.
Hit Enter -> Hit Enter -> Preview -> Hit Enter to complete the usecase
iow, it prints two remittance in slips which means, it processed the same barcode twice.
heck the Rem In report (or) check the RSD table, four rows will be added, it should have only two, because we have scanned only
ne auto remin barcode) .
lgo at Scan pouch barcode page, if a pouch id is scanned and prev is done which brings cursor to the text box where the pouch id
is already entered and then proceed furthur to complete the use case, two remittance in slips will be printed,
processed the same barcode twice.
[End of Response]
esponse code to call type L as Category 40 -- Pending -~ Incident Under Investigation
esponse was delivered to Consumer
which means it
ate:05-Mar-2010 12:32:01 Uscr:Suresh Chitikela
ction placed on Team:xCtr_OSR
SME, User:Steven Porter
[Datc:05-Mar-2010 13:25:35 User:Chaitanya Pothapragada
[Start of Response]
bdecont roller. setSignificant (false);
Ir just tested adding the above line in the code, where prev is going back to screen before list.
[End of Response]
Response code to call type L as Category 40 -- Pending
lkesponse was delivered to Consumer
Incident Under Investigation
Date:07-Mar-2010 19:
[Start of Response]
SME Review:
5:54 User
iteven Porter
[this looks at first like a simple case of a pinch point not being set - I'll look at this on Monday 8th.
[End of Response]
esponse code to call type Las
Category 40 -- Pending -- Incident Under Investigation
FUJ00081865
FUJ00081865
fesponse was delivered to consumer
jate!08-Mar-2010 08:23:14 scr: Steven Porter
[Start of Response]
SME Review:
Having trouble reproducing this easily.
li) Which codebase (CVS branch) are you using to reproduce this?
ii) Which (exact) barcode are you scanning? - Will an "Incoming Stock Pouch" barcode from the "LFS Barcode generator" tool suffice?
lease advise.
[End of Response]
Response code to call type L as Category 40 -- Pending -~ Incident Under Investigation
lkesponse was delivered to Consumer
[Date:08-Max-2010 08:23:17 Uscr:Steven Porter
faction has been removed from the call
Jate:08-Mar-2010 09:
[Start of Response]
i) This issue can be reproduced in any branch, we reproduced in CYR025 08 hotfix.
fii) LFS Barcode Tool is not sufficient. You need to have
Hata in LFS_RDC Header and LFS_RDC Details corresponding to your branch accounting code.
6:36 User:Chaitanya Pothapragada
le are providing data for two auto vem in pouches, one each for cash & currency(pls find attached). Please set up this data with
jour branch accounting code and fad hash.
nce auto rem in is completed and you want to reuse the pouch id, make COUNTER READ TIMESTAMP to null in LFS RDC HEADER and delete
the entries in BRDB POUCH DEL DETAILS
Please let us know, if you need any furthur info (or) clarification.
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
lreaponse was delivered to Consumer
jbate:08-Mar-2010 09:35:07 User:Chaitanya Pothapragada
evidence Added -
[Dat ¢:08-Max-2010 09:39:05 Uscr:Suresh Chitikela
ction placed on Team:xCtr_OSR_SME, User:Steven Porter
Jbate:09-Mar-2010 07:12:46 User:Chaitanya Pothapragada
evidence Added -
(6:09-Mar-2010 07:14:24 Uscr:Chaitanya Pothapragada
[Start of Response]
atch attached for disabling the prev button, once a barcode is successfully scanned.
[End of Response}
esponse code to call type L as Category 40 -~ Pending -- Incident Under Investigation
esponse was delivered to Consumer
Jate:09-Mar-2010 10:06:44 Uscr:Steven Porter
[Start of Response]
SME Review:
t've not looked at the patch - I'm looking at the problem first, really. I understand that marking the screen is
"setSignificant (false)" might solve the problem, but this means the user is unable to go back and scan more barcodes, and has to
start from scratch. It also means they have no way of confirming what barcodes they have scanned (a number appears in history, but
ot the actual barcodes) «
i've looked at the flow through the use-case, and the Retry button on MSG00055 seems wrong (according to Gareth, and I'd agree) -
the retry button takes you back to the same screen (Print/Preview/Late), hence why the pinch point is not picked up. But in any
case, retries should be handled by the printing, not by the use-case. If manual confirmation that the print was successful, then
that option can be passed into the print system as well.
It notice that MSG00055 is used by three PDLs:
ecordPouchReversal .pdl
RecordPreparat ion0fPouchesForCollect ion.pdl
isplayPouchOptions.pdl
bo this logic may be wrong in several places.
It also note that it's only after both pouch receipts are printed that the pinch point is set, and all is OK - prev is disabled.
i also note that _the pouch is added to the basket as soon as it is scanned - this means that even before you get to the
FUJ00081865
FUJ00081865
"Print/Preview/late™ screen there 18 a problem with prev here:
for example:
scan barcode => into basket
rev
scan barcode again -> goes into basket again
then we end up with the same pouch recorded twice.
I've talked this through with Gareth and Ric, and the conclusion is that we should ensure that once a barcode has been
successfully* entered (and gone into the basket), then we should set a pinch point (but ensure that Cancel is still enabled to
low use-case to be abandoned). This will mean the MSG00055 Retry button doesn't really cause us any issues, and can be dealt with
hater as a lower priority peak.
je must ensure that if the user enters a barcode that is not valid, and requires c
correct it.
erection, the user should be allowed to still
jote that this proposal is not too dissimilar to what is being suggested — setSigificant (false) v setPinchPoint(...) is just a
slightly different way of avoiding re-adding the same pouch to the basket twice.
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Consumer
[Date:09-Max-2010 10:06:46 Uscr:Steven Porter
Action has been removed from the call
jbate:09-Mar-2010 13:33:50 User:Chaitanya Pothapragada
[Start of Response]
It tried to set up pinchpoint in two ways :
Inder the line obtainPouchBarcodeBLO.invoke("start", barcodeParams); in RecordPouchDeliveryBLO the below two cases are tried -
h. adcController.setPinchPoint (); is added.
mn first attempt when invalid barcode is added and validation fails, the prev button is disabled. No pouch was added to basket yet.
b. if (validPouches.size()>0) { adcController.setPinchPoint ();
3
[the prev in this case will not be disabled until a pouch is added to the basket. But when on first attempt an invalid pouch id is
entered and prev is hit, it is taking to the screen where the previous barcode is entered in text box with barcode present. This ig
bserved for all invalid barcode entries. Each prev will take to invalid barcode page with the barcode present in the text box.
lease advise.
[End of Response]
esponse code to call type L as Category 40 -- Pending -~ Incident Under Investigation
lkesponse was delivered to Consumer
Date:09-Mar-2010 13:34:26 User:Chaitanya Pothapragada
[the Call record has been transferred to the team: xCtr_BAC_GDC
he Call record has been assigned to the Team Member: Vivek Agnihotri
progress was delivered to Consumer
JDate:09-Mar-2010 1:
[Start of Response]
li dont see above two solutions working perfactly but that is how UI is working when pinch point is set for any screen, it will not
clear the list or data.
steve please advice.
[End of Response]
esponse code to call type Las Category 40 -- Pending -- Incident Under Investigation
lkesponse was delivered to Consumer
7:49 User:Vivek Agnihotri
€6:09-Mar-2010 13:38:06 User:Vivek Agnihotri
Action placed on ‘Team:xCtr_OSR_SME, User:Steven Porter
[Date:09-Mar-2010 1.
[Start of Response]
SME. Guidance
0:13 User
teven Porter
Ihe point I think the pinch point needs to be is just after adding to the basket when the barcode is scanned - and only if it is
not. found in the system already.
in RecordPouchDeliveryBLO.pdl, start method, try adding 4 pinch point at this point:
## pinch point here - on this line??
fiog.debug("Not found in DB: " + pouchBarcode + " Needs to capture detaile....");
i've not tried it, but this would seem like a good first stab.
his sets the pinch point if a) it's not found in the system, but b) has been added to the basket
[End of Response]
FUJ00081865
FUJ00081865
Gaponse code to call type bas Category 40 = Pending -- Incident Under Investigation
lkesponse was delivered to Consumer
Te:09-Mar-2010 14:10:15 User:Steven Porter
\ction has been removed from the call
[Date:09-Mar-2010 1:
[Start of Response]
[fhe approach is working fine for manual entry. This is allowing the user to edit the
5:09 User:Chaitanya Pothapragada
sh and currency during manual remin.
So, along with the above, we also need to set up pinch point at :
H## pinch point here ~ on this line??
hog.debug ("found in DB: " + pouchTd);
[this will disable the prev button, once a valid pouch id is added.
It attached the patch for the above, kindly review.
[End of Response]
Ikesponse code to call type L as Category 40 -- Pending
esponse was delivered to
Incident Under Investigation
(€6:09-Mar-2010 15:38:31 User:Chaitanya Pothapragada
evidence Added ~ tch
Date:09-Mar-2010 15:40:00 User:Suresh Chitikela
fhe Call record has been transferred to the team: xCtr_CSM_GDC
[the Call record has been assigned to the Team Member: Suresh Chitikela
ogress was delivered to Consumer
Date:09-Mar-2010 15:41:05 Uscr:Suresh Chitikela
ction placed on Team:xCtr_OSR_SME, User:Steven Porter
te:09-Mar-2010 15:53:05 User
[Start of Response]
IME Review:
teven Porter
iow I understand the code a bit better, having talked to Ric (this code i
shed.
not very clear to the lay person!)...the correct patch
is atti
jote that my patch includes some comments - please incldue these.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Consumer
Date:09-Mar-2010 15:54:23 User:Steven Porter
all
ction has been removed from the
jbate:09-Mar-2010 16:04:14 User:Chaitanya Pothapragada
[Start of Response]
FIX IMPACT
[IMPACT ON DEVELOPMENT:
Effort in mandays. less than 1 hour
IMPACT ON TEST:
Juto remin and manual pouch delivery to be tested.
nce the barcode is successfully scanned, the prev button will be disabled preventing the cursor to go back to the text box where
the the barcode is successfully scanned. So, user cannot go back to the text box where the barcode is successfully scanned and scanI
gain the same barcode.
fore this fix, the prev button is not disabled when a barcode is 4
barcode to process twice.
ned su used issues of same auto remin
cessfully and this
IMPACT ON USER:
[his fix prevents the same remin barcode to be processed twice.
fter successfully scanning a auto remin barcode, press prev and bring cursor to the text box where barcode was successfully
Iscanned. And again proceed as usual from there, this would result in scanning the same barcode twice. Check in remin report and two
remin delivery receipts will be printed.
IMPACT ON OPERATIONS
jone
FUJ00081865
FUJ00081865
RISKS (of releasing and of not releasing proposed fix):
[his is of low risk and low complexity fix.
[fhe users have chance of scanning the same auto remin barcode twice.
LIST OF LIKELY DELIVERABLES:
RecordPouchDel iveryBLO
ANYTHING ELSE THAT SHOULD BE KNOWN ABOUT THIS CHANGE:
jone
INGX CODE FIX
FIX DESCRIPTION
nce the barcode is successfully scanned, the prev button will be disabled preventing the cursor to go back to the text box where
the the barcode is successfully scanned. So, user cannot go back to the text box where the barcode is successfully scanned and s
lain the same barcode.
lsefore this fix, the prev button is not disabled when a barcode is scanned successfully and this caused issues of same auto remin
arcade to process twice.
anI
IPROPOSED BRANCH
cTRO25_09_HOTFIX
COUNTER JAVA FILES CHANGED
jone
(COUNTER PDL FILES CHANGED
kecordPouchDeliveryBLO
SOUNTER REFDATA FILES CHANGED
SHARED CODE
jone
FILES CHANGED
BAL JAVA CODE FILES CHANGED
jone
OL FILES CHANGED
ione
THER FILES CHANGED
jone
PPROPRIATE CODE COMMENTS
[Incorporated
DEPENDENCIES
ione
RELATED PROBLEMS
jone
LT TESTING EVIDENCE
a
EGRESSION TEST CLASS
ione is needed as this is simple fix disabling the prev button not affecting the transaction at any point.
ISACKWARDS COMPATIBILITY
A
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jesponse was delivered to Consumer
Jbate:09-Mar-2010 16:06:39 User:Suresh Chitikela
ction placed on Team:xCtr_OSR_SME, User:Steven Porter
[Date:09-Mar-2010 16:06:46 Uscr:Suresh Chitikela
Action has been removed from the call
Date:09-Mar-2010 16:15:04 User:Steven Porter
[Start of Response]
ME Review:
All fine.
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jesponse was delivered to Consumer
Eo:10-Mar-2010 07:
[Start of Response]
Whe fix is committed in :
3:54 User:Chaitanya Pothapragada
FUJ00081865
FUJ00081865
Branch : CTRO25 09 HOTFIX
evision : 1.97.82.1
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
JDate:10-Max-2010 07:55:35 Uscr:chaitanya Pothapragada
[fhe Call record has been transferred to the team: xCtr MERGE GDC
Progress was delivered to Consumer
Date:10-Mar-2010 11:13:39 User:Sushama Mudundi
fhe Call record has been transferred to the team: xCtr_CSM GDC
[fhe Call record has been assigned to the Team Member: Chaitanya Pothapragada
progress was delivered to Consumer
joate:10-Mar-2010 11:15:04 User:Chaitanya Pothapragada
[Start of Response]
changing response category
[End of Response]
Response code to call type L as Category 46 -- Pending
fesponse was delivered to Consumer
Product Error Fixed
Pe:10-Mar-2010 11:15:36 User:chaitanya Pothapragada
fhe Call record has been transferred to the team: xCtr_REL GDC
Progress was delivered to Consumer
Date:11-Mar-2010 13:22:14 Uscr:Kishor GaneshRao
[Start of Response]
flested Successfully with CTR APP xX0108 V046 at 4LS CCIT as part of CTR025.09 release, please see below for the testing observation
land the scenarios covered in testing.
[fhe si
cenarios which are mentioned below have been tested and found that the issue mentioned in the original des
leixed:
cription has been
Back office (F14) -> Rems & Transfer (F5) ->Delivery No (21) -> scan the barcode and complete the transaction
so check the Rems report for the same day & make sure there is no wrong/double entry which was not carried out.
But, wherein there are few observations which are noted down while verifying this peak which are as mentioned below:
Observation/other issues noticed:
h. In the pouch delivery print preview page there is a wrong prompt message displayed saying ?Delivery Receipt Not
lprinter/Previewed MSG90980? even after having the receipts previewed/printed.
b. Also there is a Printer Error MSG00180 shown while printing the pouch delivery receipt page.
- And also there is a system error thrown after clicking on Enter button for the second time in print preview page of pouch
Kelivery.
Evidence:
Please see the attachment for the test evidences and for the log files.
jOTE: Please note that these above issues are intermittent I have got these above issues twice out of four attempts.
[End of Response]
Response code to call type L as Category 46 —- Pending
esponse was delivered to Consumer
Product Error Fixed
[pate:di-Mar-2010 13:22:34 Uscr:Kishor GaneshRao
the Call record has been assigned to the Team Member: Kishor GaneshRao
ogress was delivered to Consumer
[Date:di-Max-2010 13:25:54 Uscr:Kishor GaneshRao
evidence Added - Test Evidences i.e. 1
q files & Screenshe
te:l1-Mar-2010 14:42:10 User:John Budworth
eference Deleted: DevIntRel-Director ITU SVaI
jate:11-Mar-2010 14:42:24 User:dohn Budworth
PC 3
eference Adde
Jate:12-Mar-2010 09:31:27 User:Kishor GaneshRao
he call Target Release has been moved to:Targeted At -- HNG-X 01.08 Hot Fix
lkeference Added: Product Baseline CTR APP x0108_v046
[Start of Response]
joving PEAKS ti integration
[End of Response]
FUJ00081865
FUJ00081865
jSaponse code to call type b as category 45
[the Call record has been transferred to the team: Development calls ready for Integration
fhe Call record has been assigned to the Team Member: Unassigned
Date:42-Mar-2010 13:08:14 User: Geoff Inglis
"TR APP. X0108 V046-V045 ready for test.
jate:12-Mar-2010 13:09:38 User:Geoff Inglis
CTR APP_X0108 V046-V045 ready for test
Whe Call record has been transferred to the team: Live Support Team
he Call record has been assigned to the Team Member: Unassigned
Date:25-Mar-2010 1
[Start of Response]
Hested in LST - Please see release peak for details
[End of Response]
lkesponse code to call type L as Category 48 -- Pending -- Fix Released to PIT
lkesponse was delivered to Consumer
0:34 User:Sheila Bamber
[Date:25-Max-2010 17:50:39 Uscr:Sheila Bamber
the Call record has been assigned to the Team Member: Release to Live
Progress was delivered to Consumer
Date:07-Apr-2010 11:39:46 User:Lionel Higman
ction placed on Team:xCtr Temp GDC
Jateri6-Apr-2010 15:52:19 Uscr:gohn Budworth
[Start of Response]
Release RNT9546 for tivoli download product COUNTER X0108 52_2 has completed LST testing and has been applied to Model Office
pranches and will be deployed to live pilot week commencing 19/4/10.
outing to call logger.
[End of Response]
esporise code to call type lL. as Category 60 -- Final -- S/W Fix Released to Call Logger
Routing to Call Logger following Final Progress update.
lkesponse was delivered to Consumer
efect cause updated to 14 -- Development - Code
Date:19-Apr-2010 09:00:06 Uscr:Lorraine Elliott
[fhe Call record has been assigned to the Team Member: Anne Chambers
rogress was delivered to C
nsumer
737:37 User:Anne Chambers
jDate:06-May-2010 11
[Start of Response]
de fix now live. Closing call
nd of Response]
sponse code to call type L as Category 60 -- Final -- S/W Fix Released to Call Logger
outing to Call Logger following Final Progress update.
Service Response was delivered to Consumer
jate:06-May-2010 16:37:37 User:Anne Chambers
CALL PC0195380 closed: Category 60 Type L
[Date:06-May-2010 16:46:14 User: customer Call_
onsumer XXXXXX@TFS01 has acknowledged the call closure
Root Cause Development - Code
Logger _Customer Call_ -- EDSC
Subject Product EPOSS & DeskTop -- Counter Common (version unspecified)
Assignee _Customer Call_ -- EDSC
Last Progress 06-May-2010 16:46 -- Customer Call _