FUJ00086720
FUJ00086720
Peak Incident Management System
Call Reference PC0208335 Call Logger _Customer Call_ -- EDSC
Release Targeted At -- HNG-X 04.39 Top Ref PC0210249
Call Type Live Incidents Priority B -- Business restricted
Contact EDSC Call Status Closed -- Administrative Response
Target Date 14/02/2011 Effort (Man Days) 1.00
Summary Phantom Stock Declaration - Billesdon SPSO, FAD 169217 - H1706871
All References Type Value
Product Baseline BRDB_SOFTWARE_INSTALLATION_ POSTMIG08_0439_V003-V002
Product Baseline BRDB_HNGX POSTMIGO8 CHANGES 0439 D002-D001
Call reference PC0211010
TRIOLE for Service 3627663
Product Baseline BRDB_HNGX_POSTMIG08_ CHANGES 0439 _V002
DevintRel-Director Live Supp.Test
Release PEAK PC0210249
Product Baseline BRDB_SOFTWARE INSTALLATION POSTMIG08_0439_V003
Product Baseline BRDB_SOFTWARE_INSTALLATION POSTMIG08_0439 D003-D002
SSCKEL KEL achal357Q
Product Baseline BRDB_HNGX_POSTMIG08_CHANGES. 0439 V002-V001
MSC 04350295912
SSCKEL KEL achal3570
Collections I Name User Date
BIFApproved Lorraine Guiblin 16-Feb-2011 11:13:56
Im
Si ee é User Date
Unknown 14-Feb-2011 15:25:22
Branches will be forced to declare stock when they don"t want to. Apparent reappearance of withdrawn
stock may cause spurious discrepancies. Avoidance action taken so far is only appropriate in the short-term
while very few branches are affected; over the next few months it could be affecting around 10 branches per
week. NBSC aware of problem.
Progress Narrative
fbate:11-Feb-2011 11:50:18 User: Customer Call_
CALL PC0208335 opened
betails entered are:-
sumuary:Phantom Stock Declaration ~ Billesdon SPSO, FAD 169217 - 1706871
call Type:L
call Priority:c¢
ffarget Rele.
lkouted to:EDS
HNG-X R4
_Unassigned_
pate/Time Rai:
Priority: C
contact Name: NB:
contact Phone
originator: XXxxKx
Originator's reference: 3627663
Product Serial No:
Feb 11 2011 10:19AM
boffice rolled from TP10 BP4 to TP10 BP5 on 09/02/2011 and will do the Trading Period balance on 16/02/2011.
fhe office reports the balance done on 09/02/2011 was fine. Then at the end of the day on 10/02/2011 the office did the daily
claration and declared their stamps and went into discrepancies. The system brought up 6 pages of losses and ga hat
jcontained items that are no longer valid stock, such as old first day envelopes and 58 PO saving stamps. The office then called
the helpline and was passed between both NBSC and HSD trying to determine the cause. On the morning of 11/02/2011 the spmr went
FUJ00086720
FUJ00086720
finto declare stock to check and there was an existing declaration there dated 17/02/2010. The office went into the declaration
land confirmed it showed the PO saving stamps and other stock items, some showing as minus stock amounts, that were not correct to
the branch.
Itt somehow seems that the system has somehow picked up this declaration and this is the cause of the discrepancies appearing on
the system. The spmr was told to declare the correct stock figures but is reluctant to do this as this will cause discrepancies
hen she next balances that are not relevant to herself at the moment. The only call reference supplied to the spmr from HSD is
3626603.
can this be investigated to see how it has happened and want can be done to allow the office to balance next week without showing
discrepancies in the balance. I am aware of issues with PO saving stamps reappearing on the system as have a call under
investigation for South Cerney SPSO, FAD 398523, but have not come across a declaration reappearing from nearly 12 months ago.
Incident History:
2011-02-11 10:19:04 [ Rai, Davinder}
INIT : create a new request/incident /problem/change/issue
01-02-11 10:21:00 [ Rai, Davinder]
Jzneun_en_rmg : Open Notification
2011-02-11 10:37:30 [ Rai, Davinder]
neut_en_rmg : Transfer Notification
2011-02-11 10:37:30 [ Rai, Davinder]
I(R : Transfer group from '' to 'HSD IMT?
2011-02-11 10:37:38 [ Rai, Davinder]
LOG : Office name - Billesdon SPSO
ffice FAD - 169217
caller - Joan
Username — JPAQ01
jode 1
2011-02-11 10:37:41 [ Rai, Davinder]
FLD : FIELD='zcbflag’ OLD='NO* NEW="YES'
2011-02-11 10:38:06 [ Rai, Davinder]
ILkoG_: KEL acha3145Q
2011-02-11 10:38:24 [ Rai, Davinder}
joc : Alison J Clark @ NBSC requesting call to be logged!
fter discussions with Anne Chambers it would be feasible for Anne to contact Alison
2011-02-11 10:43:16 [ Rai, Davinder]
Log : I have emailed Alison requesting contact details
lwaiting Alisons Number
2011-02-11 11:48:26 [ Rai, Davinder]
L0G : Anne Chambers currently investigating issue and liasing with NBSC
2011-02-11 11:49:18 [ Rai, Davinder]
IR : Transfer group from ‘SD IMT’ to 'PEAK'
2011-02-11 11:49:18 [ Rai, Davinder]
Jzneut_en_rmg : Transfer Notification
jate:1-Feb-2011 12:10:42 User:Lorraine Guiblin
Product EPOSS & DeskTop -- Counter Common (version unspecified) added.
bate:41-Feb-2011 12:10:47 User:Lorraine Guiblin
fhe Call record has been assigned to the Team Member: Anne Chambers
Progress was delivered to Consumer
jbate:11-Feb-2011 12:36:06 User:Anne Chambers
[Start of Response]
ltooks as if the branch had a stock declaration from TP 10 BP 5 a year ago, when they first migrated.
It have spoken to Paul Mann at NBSC and sent him details of how to get rid of the old declaration (I hope he will share this with
INBSC). He will sort out this branch.
le need to find out whether other branches are going to be affected in the same way. There is already a known problem with
declarations containing withdrawn products, and possibly this problem could result in more of these.
{End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
Jbate:14-Feb-2011 13:39:06 User:Anne Chambers
FUJ00086720
FUJ00086720
fvidence Added ~ Dec Thee guly 2010
IDate:44-Feb-2011 14:42:38 User:Anne Chambers
[Start of Response]
the old declaration has been removed from branch 169217 so they should be able to balance correctly without being forced to
}leclare stock again. NBSC have also been asked to remove a similar old declaration at branch 113818.
the attached spreadsheet shows 137 declarations, of various types, which have not been used since last July. These may be used
lgain unexpectedly once the same TP/BP is reached. The Stock declarations are most likely to cause problems as users will then be
forced to make stock declarations when they probably don't want to (and possibly the declarations include stock of withdrawn
products) .
lArchiving strategy for table BRDB_BRANCH DECL appears to be that declarations are kept indefinitely unless they are zero
leclarations or belong to a stock unit deleted more than 28 days ago.
IBRDB and BRSS have the same entries so we shouldn't need to worry about any Streams problems when removing old entries.
Passing call to development/design to find out how these old entries should be removed - this needs to be done ASAP — and how to
tidy up consistently in future.
[End of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
esponse was delivered to Consumer
jbate:14-Feb-2011 15:17:43 User:John Chariton
KEL acha13570 authorised
JOate:14-Feb-2011 15:25:22 User:Anne Chambers
lA new Business Impact has been adde:
[Branches will be forced to declare stock when they don't want to. Apparent reappearance of withdrawn stock may cause spurious
discrepancies. Avoidance action taken so far is only appropriate in the short-term while very few branches are affected; over the
next few months it could be affecting around 10 branches per week. NBSC aware of problem.
jbate:14-Feb-2011 15:26:36 User:Anne Chambers
lsvidence Added = Declar ed since July 2010
jbate:14-Feb-2011 15:26:41 User:Anne Chambers
lsvidence Deleted - Declarations not used since July 2010
Date:14-Feb-2011 15:27:14 User:Anne Chambers
fhe call Priority has been changed from ¢
the call Priority is now B
jbate:14-Feb-2011 15:28:15 User:Anne Chambers
[Start of Response]
Priority increased to B becasue of potential effects on branch balancing.
[End of Response]
Response code to call type L as Category 40 -- Pending —- Incident Under Investigation
Response was delivered to Consumer
JDate:44-Feb-2011 15:44:17 Uscr:Anne Chambers
Ithe Call record has been transferred to the team: BIF
progress was delivered to Consumer
Date:16-Feb-2011 11:14:21 Uscr:Lorraine Guiblin
[the Call record has been assigned to the Team Member: Gareth Jenkins
progress was delivered to Consumer
Jbate:16-Feb-2011 11:45:59 Uscr:Gareth Jenkins
[this needs to be addressed at 2 levels:
the fix is a change to the BRDB archiving such that any row in BRDB_BRANCH DECL is archived (along with related rows in
JBRDB_BRANCH_DECL ITEM) 6 months (ie 180 days) after the timestamp in update timestamp. This will result in any Declaration being
discarded after € months and so avoid the wrap around issue. Note that discarding an Declaration purely means that a complete
eclaration will be required rather than being able update an old one and so has no impact on the accounts.
However looking at the spreadsheet attached to the peak there are 4 branches that will have an issue in the next month, so we
must either contact the branches and get them to carry out a zero declaration (which I understand Anne has done in the one branch
ith a problem today), or we should raise an MSC to tidy up the data. I propose that an MSC is raised so as to remove any
Declarations that have an update timestamp of July 2010 or older, which then allows time for the fix to be progressed in normal
timescales.
Passing Peak to BRDB Dev to progress.
jDate:16-Feb-2011 11:46:28 Uscr:Gareth Jenkins
lthe Call record has been transferred to the team: BDB-Host-Dev
FUJ00086720
FUJ00086720
Progress was delivered to Consumer
jbate:16-Feb-2011 11:56:39 Uscr:Steve Goddard
the Call record has been assigned to the Team Member: Vishnu Ramachandran
Progress was delivered to Consumer
jate:17-Feb-2011 16:03:01 User:Vishnu Ramachandran
Defect cause updated to 7 : Design - High Level Design
jbate:18-Feb-2011 17:42:19 User:Vishnu Ramachandran
Reference Added:
959
JDate: 18-Feb-2011
{Start of Response]
ISC 04330295912 has been raised to address this issue in the short term. Fix will get rid of all older branch declaractions
beyond 01-AUG-2010.
3:49 User:Vishnu Ramachandran
Msc fix should get applied first in LST BDB Host and subsequently in LIVE BDB Host.
{End of Response]
Response code to call type las Category 38 -- Pending -- Potential Problem Identified
Response was delivered to Consumer
oate:18-Feb-2011 17:44:35 User:Vishnu Ramachandran
[Start of Response]
[End of Response]
Response code to call type L as Category 41 -- Pending -- Product Error Diagnosed
Response was delivered to Consumer
Jbate:4@-Feb-2011 17:49:14 User:Vishnu Ramachandran
product HNG-X Platforms -- Branch Database Server ~ Main (BDB) (version unspecified) added.
bate:18-Feb-2011 17:49:16 User: Vishnu Ramachandran
Product. HNG-x Platforms -- Branch Database Server - Main (BDB) updated to Subject.
18-Feb-2011 18:14:49 Uscr:Vishnu Ramachandran
DEVELOPMENT IMPACT OF FIX:
SPECIFY THE HNG-X PLATFORMS IMPACTED:
lave you used the "HNG-X Platforms" Product Group available under the PRODUCTS button in PEAK to specify all HNGX platforms
impacted by this fix?
b> Yes. Branch Database Server (Main).
are all the platforms in the same deployment group?
b> yes.
IrECHNICAL SUMMARY:
Summarise the impact by technical areas affected, i-e., "this change will affect 3 PL/SQL packages and 1 J2EE web service".
b> This change will affect one Oracle table in Branch database [BRDB_ARCHIVED TABLES}.
LIST OF KNOWN DIMENSIONS DESIGN PARTS AFFECTED BY THE CHANGE:
uist all the known products
b> BRDB SOFTWARE INSTALLATION POSTMIGOT
>> BRDB_HNGX POSTMIGO7 CHANGES
[DEPENDENCTE:
re there any other PEAKs or CPs with interdependencies on the proposed fix?
b> No
are there any clone peaks to take the delivery to a different deployment group? If yes is there any order in which they must be
kieployed?
b> No
lany other dependencies such as Infrastructure changes or technical/configuration changes that will not included in the
pevelopment fix?
b> No
[DEPLOYMENT DETATL:
lboes the fix include procedures that are known not to be packagable by Integration in an automatically deployable baseline
(DPVB)? If so, please comment on the nature and technical complexity of such procedures
b> No
joes the fix require a reboot?
>> No
lboes the fix apply to a tered databas
b> Yes.
FUJ00086720
FUJ00086720
Inf so must the deployment be done to all at the same time?
b> No. BRDB Node 1 only.
DEV EFFORT IN MANDAYS:
b> Total dev effort - 1 man day.
If the Man Days figures will be different to the elapsed duration, please state so here. Also, if there are any constraints on
jwork beginning, please state here.
b> None
HMPACT ON USER:
Benefit of making the fix.
b> Older branch declarations for a recurring TP/BP wont be picked up in Branch Declarations report and the fix would prevent
Iaiscrepancies in stock declarations.
lwhat does the user have to do to get this problem?
b> Roll a branch forward into a TP/BP for which there are old unused branch declaractions from previous year. Once rolled
forward, the user should try and generate the declarations report.
low does it affect them when it occurs?
b> False discrepancies will be reported in the declarations report. Declarations will not balance without the branch manager re-
leclaring the stock.
iow many branches in the estate are likely to be affected by this issue
jbo not state any of the technical solution detail here.
b> In the next few months the forecast is about 10 branches per week as branches will always roll forward to next TP/BP.
IMPACT ON OPERATIONS:
il] the absense of a fix for this issue impact the ability of the operations team to support the HNGX system?
b> No
If so, please comment on the severity of the impact and specify if any workaround for the issue exists.
lsenefit of fix that may not visible to end user.
b> Unused declarations older than 180 days will get archived and purged from Branch database thereby saving database space to
jwhatever extent that might be.
]ZAVE RELEVANT KELS BEEN CREATED OR UPDATED?
state Yes, or if not, why not.
p> Yes. KEL achal357Q authorized.
IMPACT ON TEST:
what independent test coverage/scenarios does development recommend?
[this will often be about the level of regression testing required.
b> Identify a test branch that may have declarations of various stock types that are older than 180 days from current business
jaate. When the archive / purge process in BRDB [BRDBCO04] is run it should get rid of all such older declarations both from BRDB
land BRSS (if streams is configured in the test rig).
hat CIT test coverage does development recommend?
b> Same as above
hat Development test scenarios are needed?
>> Same as above
hat Development test scenarios manual/automated should be promoted to CIT?
b> None
RISKS (of releasing and of not releasing proposed fix):
lwhat live problems will there be if we do not issue this fix?
b> In the next few months more and more branches will rollover into a TP/BP combination for which there might be older branch
declarations. Such branches will face stock declarations discrepancy and won't be able to balance stock accounts unless they do a
jre-declare of stocks (which the end user is reluctant to do).
hat are the risks of this fix having unexpected interactions with other areas?
b> None
iis this a high-risk area in which changes have caused problems in the past?
b> No
should we consider a pilot rollout and of what sort?
b> No
IuIST OF LIKELY DELIVERABLES:
ne BRDB Patch shell script.
Joate:18-Feb-2011 18:20:14 User:Vishnu Ramachandran
Development Cost updated: new cost is 1 (Man Days)
[Start of Response]
Long term fix details -
Update additional criteria column in brdb archived tables for BRDB_BRAN' L table as follows -
FUJ00086720
FUJ00086720
AND
(
( zero decl_yn = 'Y*
IR
(fad_hash, branch accounting code, stock unit)
HN
(
SELECT fad_hash, branch accounting code, stock unit
leRoM brdb branch decl
NUS
SELECT fad hash, branch accounting code, stock unit
FROM brdb branch stock units
HERE NOT (is deleted = 'Y' AND deleted date < (T0_DATE(pkg_brdb common. fn_get_short_date, 'YYYYMMDD') -28))
)
)
jor
(NVL( update timestamp, systimestamp ) < (systimestamp - 180) )
)
[End of Response]
Response code to call type Las Category 41 -- Pending -- Product Error Diagnosed
Response was delivered to Consumer
jbate:18-Feb-2011 18:22:16 Uscr:Vishnu Ramachandran
Action placed on Team:RelMngmntForum
bate:22-Feb-2011 15:54:35 User:Tyrone Cozens
the call Target Release has been moved to:Targeted At -- HNG-X 04.39
ffargeted at 4.39 as agreed in RMF.
Date: 22-Feb-2011 17:19:14 User: Tyrone Cozens
\ction has been removed from the call
Jbate:23-Feb-2011 09:54:00 Uscr:Vishnu Ramachandran
TOP Reference set to: MSC 04330295912
Dat ¢:23-Feb-2011 16:24:55 User:Vishnu Ramachandran
IBRDBPatch0337.sh has been allocated for this fix.
bate:23-Feb-2011 18:02:12 User:Vishnu Ramachandran
[Start of Response]
Patch has been tested in development.
[End of Response]
Response code to call type Las Category 46 -- Pending -- Product Error Fixed
lkesponse was delivered to Consumer
Date:06-Apr-2011 16:20:03 User:PIT Automated User
Reference Added: Product Baseline BRDB SOFTWARE INSTALLATION POSTMIGO8 0439 v003
lkeference Added: Product Baseline BRDB SOFTWARE INSTALLATION POSTMIGO8 0439 vo03-Vv002
lkeference Added: Product Baseline BRDB_HNGX POSTMIGO8 CHANGES 0439 vo02
Reference Added: Product Baseline BRDB_HNGX POSTMIGO8 CHANGES 0439 V002-vo01
Joate: 06-Apr-2011 16:22:12 User:Vishnu Ramachandran
[Start of Response]
IBRDBPatch0337.sh has been allocated for this fix. The patch amends the archive meta-data for BRDB BRANCH DECL. Change is exactly
the same as MSC. This is a catch-up delivery to formalise the MSC change.
[End of Response]
response code to call type lL as Category 48 -- Pending ~~ Fix Released to PIT
Response was delivered to Consumer
jbate:06-Apr-2011 16:23:23 User:Vishnu Ramachandran
[the Call record has been transferred to the team: Dev-Int-Rel
progress was delivered to Consumer
Jbate:07-Apr-2011 16:25:04 Uscr:PIT Automated User
Reference Added: Product Baseline BRDB SOFTWARE INSTALLATION POSTMIGO8 0439 D003-D002
Date: 07-Apr-2011 17:15:04 User: PIT Automated User
Reference Added: Product Baseline BROB_HNGX POSTMIGO8 CHANGES 0439 D002-D001
FUJ00086720
FUJ00086720
fbate:12-Apr-2011 11:02:34 User:Bi? Automated User
[Start of Response]
Assigning to Integrator
[End of Response]
Response code to call type L as Category 48 (Fix Released to PIT)
fhe incident has been transferred to the Team: Dev-Int-Rel
the incident has been assigned to the Team Member: Andrew Moor
progress was delivered to Consumer
jDate:16-May-2011
lkeference Added:
iiyrone Cozens
210249
jbate:16-May-2011 15:27:22 User:Lionel Higman
[Start of Response]
in HNG-X 04.39
[End of Response]
Response code to call type L as Category 49
Response was delivered to Consumer
@ Call record has been transferred to the team: Live Support Team
the Call record has been assigned to the Team Member: Unassigned _
jate:23-Jun-2011 10:53:33 User:Anne Chambers
lkeference Added: Call reference PCO211010
bate:23-dun-2011 10:55:46 User:Anne Chambers
[this fix and the MSC already applied doesn't remove all old declarations - see PC0211010.
[Date:27-dun-2011 10:49:06 Uscr:Sheila Bamber
(the Call record has been assigned to the Team Member: Release to Live
JDate:10-Sep-2012 15:36:11 User:John Budworth
[Start of Response]
Irix for this PEAK applied to live in 2011 via RNT7529A - Release PEAK 210249.
touting to call logger for closure.
[End of Response]
Response code to call type L as Category 60 -- Final -- S/W Fix Available to Call Logger
touting to Call Logger following Final Progress update.
Response was delivered to Consumer
Date: 10-Sep-2012 15:37:36 User:Sudip Sur
[Start of Response]
closing
[End of Response]
lkesponse code to call type L as Category 68 -- Final -- Administrative Response
Routing to Call Logger following Final Progress update.
service Response was delivered to Consumer
Jbate:10-Sep-2012 15:37:36 User:Sudip Sur
CALL PC0208335 closed: Category 68 Type L
jbate:13-Sep-2012 10:05:54 User: _Customer Call_
consumer XXXXXXG@TFS01 has acknowledged the call closure
Root Cause Design - High Level Design
Logger _ Customer Call_ -- EDSC
Subject Product I HNG-X Platforms -- Branch Database Server - Main (BDB) (version unspecified)
Assignee _Customer Call_ -- EDSC
Last Progress 13-Sep-2012 10:05 -- Customer Call_