FUJ00232850
FUJ00232850
There’s a Peak in my stack...
A checklist guide for Peak stack owners (and support specialists updating Peaks)
Should this be in my stack? If not, then route it to the right Assigned Team
Is the Peak assigned to the correct person (not off sick, still on POA)? If not,
then reassign it
Is it a potential Live Defect? If so, add the ##LiveAffectingDefect Collection
If it is a potential Live Defect, what needs doing to progress it to Defect
Identified or to qualify it as NOT a Live Defect?
If it is a Live Defect, it should be Call Type “L” or “#” — so change it if needed
If it is Call Type “# - Defect Identified”, is it bonded to POL’s SNOW - if so, it
needs to be cloned and then closed (it is ok if it is only bonded to TfSNow)
Is it, or could it be, branch impacting — if so, add the HDR-Fin or HDR-Exp
Collection
If it has a HDR-* Collection — is it being treated as high priority — regardless of
Priority field value?
If it has a HDR-* Collection — is the Impact tab up to date and all fields well
worded so that POL will understand it (see HDR examples below)?
If it does not have a HDR-* Collection — is the Impact tab up to date and all
fields well worded so that POA colleagues will understand it (see non-HDR
examples below)?
Is the Workaround Reference added with Yes selected where a suitable
workaround is in place?
Has anything changed that would mean the ##LiveAffectingDefect or HDR-*
Collections are no longer correct and should be removed? If so, remove them
If it is Defect Identified, when will it be taken to BIF? Set the BIF Action
If it is Defect Identified, and has been approved at BIF, when will it be taken
to PTF? Set the PTF Action
If it is Defect Identified, and has been Targeted in PTF, when will work start
to create the required fix?
Is the Response Category correct?
Is the Product and Product Group correct?
When was it last updated — and is that an acceptable timespan?
Have discussions taken place over email or in meetings that should be added
to the Peak to ensure a full record is available?
How long is it since the Peak was raised — and is that acceptable or does a
review need doing?
*
Do the latest updates read well and make sense? If not, change them and
coach the creator
\s it clear who (specifically) is expected to take the next action? If not, make
it clear and notify the person expected to act
If you are waiting for someone external to your team to take action —
challenge them to make progress
Peaks with the following Response Categories that have the
##LiveAffectingDefect Collection should be Call Type “#” as a fix is needed.
Change it if necessary
41 -- Pending -- Product Error Diagnosed
42 -- Pending -- Documentation Error Diagnosed
Peaks that are Status “F” should have an accurate Root Cause added before
being closed. Make sure it is updated
Peaks recently closed with any of the following Response Categories are
deemed to have been No Fault Found with no fix action needed. Is this
correct? If not, have the Peaks re-opened and corrected
58 -- Final — Documentation Fix Available to Call
Logger
62 -- Final — No fault in product
63 -- Final -- Programme Approved — No Fix
Required
I 64 -- Final — Published Known Error
66 -- Final -- Enhancement Request
68 -- Final -- Administrative Response
70 -- Final - Avoidance Action Required
72 -- Final -- Duplicate Call
94 -- Final -- Advice and guidance given
95 -- Final -- Advice after Investigation
96 -- Final -- Insufficient evidence
97 -- Final -- Unspecified insufficient evidence
98 -- Final -- User error
I 100 -- Final -- Route call to TfS
120 -- Final -- Cloned to create Defect Peak
200 -- Final -- Call withdrawn by user
01.06.2022 (POA Defect & Quality Manager)
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY
FUJ00232850
FUJ00232850
There’s an Incident in my TfSNow Assignment Group...
A checklist guide for TfSNow Assignment Group owners (and support specialists updating TfSNow Incidents)
Should this be in my Assignment Group? If not, then route it to the right *
Assignment Group
Is the Incident assigned to the correct person (not off sick, still on POA)? If
not, then reassign it
Is the Summary field a clear description that others will understand? *
If the Incident is not bonded to POL ServiceNow, does it have the right
Open category?
*
Is it a potential Live Defect? If so, add the LiveAffectingDefect Cl *
If it is a potential Live Defect, what needs doing to progress it toa
confirmed defect or to qualify it as NOT a Live Defect? *
Should POL be aware? If so, the Incident will need to be logged by MAC
with the required specific Categories so it can be bonded to POL *
ServiceNow so POL can be kept updated with progress
Is it, or could it be, branch impacting — if so, ensure MAC are asked to add *
the HDR-Fin or HDR-Exp Cl
If it has a HDR-* Cl —is it being treated as high priority — regardless of
Priority field value?
If it has a HDR-* Cl —is a recent entry in the “Additional comments
(Customer visible)” field up to date and well worded so that POL will
understand it?
Is the State field correctly set?
Is a workaround available (this will show in the Peak — if applicable — as *
the Workaround Reference will be set to Yes)? If so, make sure that the
“Additional comments (Customer visible)” field clearly states this —
especially if this Incident is bonded to POL ServiceNow
Has anything changed that would mean the ##LiveAffectingDefect or HDR-
* Cls are no longer correct and should be removed? If so, remove them
If it is a confirmed defect, when will the resolution action be taken e.g. is
it linked to a TfSNow Change?
When was it last updated — and is that an acceptable timespan?
Have discussions taken place over email or in meetings that should be
added to the Incident to ensure a full record is available?
How long is it since the Incident was raised — and is that acceptable or
does a review need doing?
Do the latest updates read well and make sense? If not, change them and
coach the creator
If the Incident is bonded to POL ServiceNow, does the latest update to the
“Additional comments (Customer visible)” field make it clear to POL what
the status is? If not, add an update that does
Is it clear who (specifically) is expected to take the next action? If not,
make it clear and notify the person expected to act
If you are waiting for someone external to your team to take action —
challenge them to make progress
Is the Incident Suspended as no further Fujitsu action is needed? If so, and
after 10 working days have elapsed, the Incident should be closed
If the Incident is being closed, ensure it has the right Closure code and has
the correct minimum dataset added (as per local work instructions):
o Line of Summary
Root Cause
Resolution
Internal/External
Fujitsu SME
co POLStakeholder
Incidents recently closed should be checked. If they were closed with no
action required by Fujitsu, does the Incident clearly state that? If they
were closed following action taken by Fujitsu, does the Incident clearly
state that?
0000
01.06.2022 (POA Defect & Quality Manager)
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY
HDR Impact Tab — Example
FUJ00232850
FUJ00232850
There’s an Incident in my TfSNow Assignment Group
A checklist guide for TfSNow Assignment Group owners (and support specialists updating TfSNow Incidents)
1:
HORIZON DEFECT REVIEW FORUM - DEFECT SUMMARY
Document Classification:
Document Owner:
Date of Issue:
Fujitsu Confidential - Commercial-in-Confidence
Fujitsu
05/04/2022
IPOL Problem Reference
(Fujitsu Reference
IPC0295579
Date first logged at HDR
(dd'mm/yyyy)
129/07/2021
Fujitsu Title
ICBB-5906 - PBSIL socket management needs refinement to prevent delay after EFT_END Y
[POL Title
[PBSIL needs refinement to prevent delay affer a transaction end
Description
[The current socket handling between PBSIL and Ingenico means that sockets are being opened by PBSIL before point of use, and may therefore be timed out by C3. This can
‘esult in the counter hanging and also results in unnecessary socket activity and confusing logging of socket timeouts.
[Branch Financial Impact or ExperienceI
(Fujitsu HDR-Fin HDR-Exp)
[Experience
[Branch impact described
[The current transaction would not complete and the counter would hang. The clerk would need to restart the counter (power off on) and the recovery process completed
lautomatically following the restart. No receipt will have been printed and so no transaction has taken place as far as the branch is concemed,
[Defect Confirmed (or still under
{Yes
linvestigation)
How found ILST testing on R70.40 Ctr. See PEAK PC0295854. There were 2 issues found as a result of PEAK PC0295854. This represents the fix dealing with sockets being opened by
[PBSIL before point of use.
[PC0299875: Reported as an incident by the branch to POL IT DSD Team.
When found {30/06'2021
IWhen it dates back to (when could it [R70.40
hhave started happening)
[Branches affected yy PBS branches with R70.40 installed
Frequency of occurrence [This issue was raised during LST testing of R70.40, only one instance reported so far in LIVE - see PEAK PC0299739.
fRoot cause lingenico have advised Fujitsu to follow a different approach to socket handling to that supplied in their documentation. This has been implemented, but now requires another
lchange. PBSIL currently “resets” sockets with C3 on receipt of an EFT_END (i.e. closes the socket, and then opens a socket). It only needs to close the socket, and open a
lsocket when needed (ie, when starting a new conversation with C3)
sit detected monitored INo
{Workaround No
{Workaround description WA
Fix required [PBSIL should only open sockets to C3 at point of use.
[Status update [Status update: A fix has been identified (in conjunction with Ingenico), PBSIL will only open a socket to C3 at point of use. Fix implemented and tested.
Next action [BIF & PTF done; Fix completed and tested (see body of PEAK for details and associated Jira). Fix will be released as part of R71.20.
[Target Release Number
[Targeted At HNG-X 71.20 (TMC Counter Follow On Release)
[Target Release date (latest estimate)
[TBC
[External Dependencies
[None
01.06.2022 (POA Defect & Quality Manager)
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY
FUJ00232850
FUJ00232850
There’s an Incident in my TfSNow Assignment Group
A checklist guide for TfSNow Assignment Group owners (and support specialists updating TfSNow Incidents)
HDR Impact Tab — Example 2:
HORIZON DEFECT REVIEW FORUM - DEFECT SUMMARY
Document Classification: Fujitsu Confidential - Commercial-in-Confidence
Document Owner: Fujitsu
Date of Issue: 05/04/2022
POL Problem Reference
[Fujitsu Reference [PCO297878
IDate first logged at HDR
dd 'mm/yyyy)
[Fujitsu Title PBS LST:R71.10 - Transactions with Qty > 0 which appear to have failed
POL Title
Description IWhen a PBS banking or payment transaction is performed, if the transaction is declined (internal status DECLINED or UNDO) then the quantity of the resulting transaction should
Ibe set to zero.
IThe defect is that if such a declined transaction, with internal status UNDO, is not completed and settled successfully, counter recovery incorrectly sets the quantity to one. This has
{no impact on the branch accounts, but it is thought be important as the Postmaster should not be remunerated for any declined plastic transactions, including those with intemal
status UNDO. No customer impact, but there is an impact to the postmaster/clerk owing to remunerated for additional transactions that are not completed
[Branch Financial Impact or Experience
[Experience (Fujitsu HDR-
[Fin HDR-Exp)
[Branch impact described [This has no financial impact on the branch accounts as the transaction will not be recorded, however this may impact positively on branch remuneration
[Defect Confirmed (or still under I Yes
kinvestigation)
[How found [Detected by Fujitsu support when investigating issues with the UNDO process
lWhen found [28/10/2021
IWhen it dates back to (when could [July 2021 - PBS Roll Out
lit have started happening)
[Branches affected [Al PBS branches
[Frequency of occurrence Unknown. Believed to be infrequent.
[Root cause When a PBS banking or payment transaction is performed, if the transaction is declined with internal status UNDO, is not completed and settled successfully, counter recovery
incorrectly sets the quantity to one
lis it detected’ monitored INo
Workaround INo
Workaround description NA,
[Fix required [Counter code change required
[Status update [Fix is known and will incorporated into 72.20.
Next action [Awaiting for the release process for 72.20 to be initiated.
[Target Release Number [Targeted At HNG-X 72.20 (Counter Release)
[Target Release date (latest 29/05/2022
lestimate)
[External Dependencies [None
01.06.2022 (POA Defect & Quality Manager)
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY
FUJ00232850
FUJ00232850
There’s an Incident in my TfSNow Assignment Group...
A checklist guide for TfSNow Assignment Group owners (and support specialists updating TfSNow Incidents)
Non-HDR Impact Tab — Example 1:
LIVE AFFECTING DEFECT - DEFECT SUMMARY
Document Classification: Fujitsu Confidential - Commercial-in-Confidence
Document Owner: Fujitsu
Date of Issue=/01/06/2022
Fujitsu Reference PC0298772
Fujitsu Title LSTRELIND - Counter improvement: detection of corrupt Counter software
Description IFiles on Counter disks can become corrupted. This can go undetected, and lead to errors within the CBA.
IThis PEAK proposes introducing a mechanism to detect such corruptions.
Z
[How found lk small number of Counters have been detected as “corrupted” during reviews of HORice reports, particularly when monitoring new
BA rollout.
When found 23/12/2021
[When it dates back to (when could it have started happening) [HNGA initial release
Frequency of occurrence likely to be rare, but hard to predict as this is not explicitly monitored - hence this PEAK!
Root cause lEuc hardware
s it detected monitored No
Workaround No
Workaround description 7A y
Describe Fix required JProposal and options to discussed and agreed. Likely to involve a start-up/runtime check within the CBA to ensure that all
lbinary files are uncorrupted. Any corruptions would result in an alert which POL can view via HORice, say. Alternatives to be
ldiscussed internally and with POL. 4
[Status update lProposal/options to be drafted.
J
INext action Review with 4lS next week - 06/06/2022 - to review 1) Do Fujitsu counter alerts 2) Will OXC monitor this
Z
[Target Release Number Proposed For HNG-X 72.30 (Counter Release) J
Target Release date (latest estimate) TBC _ ]
TPSNow Changes r ee — I
(Operational Change Date _ : I
[External Dependencies I POL - review/options/approval ]
01.06.2022 (POA Defect & Quality Manager)
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY
FUJ00232850
FUJ00232850
There’s an Incident in my TfSNow Assignment Group...
A checklist guide for TfSNow Assignment Group owners (and support specialists updating TfSNow Incidents)
Non-HDR Impact Tab — Example 2:
Document Classification: Fujitsu Confidential - Commercial-in-Confidence
Document Owner: Fujitsu
Date of Issue:01/06/2022
[Fujitsu Reference 0290147
[Fujitsu Title LSTREL IND - PDL coercion to numbers is flawed
Description lk number of potential logical issues in the Counters POL (Process Definition Language) “parser/interpreter™ can lead to the
Inasking of errors.
[This could lead to unknown problems. y,
IHow found [evelopment reviews
[When found [0170972020
l\When it dates back to (when could it have started happening) IHNGX- Release 1
IFrequency of occurrence None (tentatively)
Root cause ‘ause identified as JEXL 3rd party library used to support PDL processing in the Counter.
lis it detected/monitored No - but this change will introduce alerting
IWorkaround No
Workaround description 7A y
[Describe Fix required Ichanges to the POL “parser/interpreter” on the Counter (part of the CBA) to make the “parser/interpreter™ much stricter,
lparticularly in date type conversion.
[There maybe a range of options available to fix the issue, but waiting investigations to conclude and require subsequent review
vith Post office.
‘ounter (CBA) change plus reference dat
POL refdata.
\Status update Fujitsu Dev have identified potential issues in a subset of counter transactions (PDL) e.g. AP-ADC transactions. An assessment
lteam has been mobilised to determine the impact. There is no indication/evidence of an impact in the live environment at this
Itime. Considerable analysis by Dev has been completed. The investigations will take at least 10 working days and include SV&I
lregression testing, before we are in a position to provide an update.
[Next action ipdate following analysis.
agreed in a meeting (26/05) with Steve Bansal to delay in reporting this issue until after the analysis is completed.
lext_review date 09/06 or 10/06
[Target Release Number Proposed For HNG-X 72.30 (Counter Release)
(Target Release date (latest estimate) TBC I
ITPSNow Changes
[Operational Change Date
[External Dependencies POL - Reference Data
01.06.2022 (POA Defect & Quality Manager)
FUJITSU CONFIDENTIAL — INTERNAL USE ONLY