TAR/GR1TNo.

TAR 332544 (GR1T 347927)

For Product Cash-In Component on 03.01

Problem Performance issues on BNA1 and BNA2, where the confirmation screen
takes over 6 seconds to display after getting the CashInOK event, and a 5
second delay after cardholder chooses Refund from confirmation screen
before the Refund command is called.
Fix Summary The delays are caused by the driver taking between 1.5 – 3 secs to
respond to status commands. To overcome this, the application is re-
written to avoid calling the commands which require a status command to
be sent to the driver. The command causing the problem before
confirmation screen was StackerStatus, this was called 4 times, now it is
only called once. The issue when calling Refund is that the
DeviceAvailability was checked before calling Refund, this is not necessary
as the Refund command will report an error if there is any issue with
device availability, and same handling will progress i.e. send w3 message
to host.
Associated N/A
DLLs

Base Application CustomisationLayer

Catalog(s) None
Fix Description Modify scripts which call StackerStatus more than once and replace
this with a script which calls it once and sets an integer store, then
use the store on each subsequent usage. Also, remove the director
which checks the DeviceAvailability before the Refund active script
host, as it is not necessary.
1) Find and obtain ownership of Set Screen director (580b7na1).
2) Add a new workgroup called Stacker Status and make it the start workgroup.
3) Add a script host to this workgroup called Get Stacker Status and insert the following script:
Sub activate()
Set objWSC = CreateObject("CashinCommonImplementation.WSC")

' Fix for 5s delay before Confirmation Screen shown

StackerStatus.Data = gbna.StackerStatus
objWSC.Debug("StackerStatus = " & StackerStatus.Data)

ActiveWorkGroup.Index = 1

End Sub
4) Set the Variables attribute to GBNA,StackerStatus.
5) Share in the GBNA Control worker (57b7na1) to the Data Objects workgroup of this script host, and
then also add a new Integer Store worker called Stacker Status.
6) Add a pass-thru to the Result 1 workgroup for this script host.
7) Create a workflow connecting the signal ‘Pass-thru - Triggered’ from the ‘Stacker Status’
workgroup to the ‘Is Escrow Full’ workgroup.
8) Now share in the Stacker Status integer store to the Escrow Capacity Available script host
(351b7na1) Data Objects workgroup.
9) Set the Variables attribute to GBNA,NotesInEscrowCount,StackerStatus.
10) Change the script to
Const CIM_STACKER_FULL = 3

Sub activate()

'Debug( "GBNA.MaxItems : " & gbna.MaxItemsOnStacker )

Debug( "GBNA.MaxItemsOnStacker : " & gbna.MaxItemsOnStacker )
Debug( "Notes In Escrow : " & NotesInEscrowCount.Data )
Debug("GBNA CIMStacker Status" & StackerStatus.Data)
'Check whether Escrow is full or not

If ( NotesInEscrowCount.Data >= GBNA.MaxItemsOnStacker Or StackerStatus.Data =

CIM_STACKER_FULL ) Then

ActiveWorkGroup.Index = 2 ' ESCROW FULL ;SO DISABLE THE ADDMORENOTES OPTION

Else

ActiveWorkGroup.Index = 1' ESCROW NOT FULL

End If
 End Sub
11) Make sure this script host is shared into all the areas where it existed before replacing it.
12) Next, find and replace the BNARefund director (215b7na1).
13) Remove the workgroup entitled Check Availability and ensure the signal from Init Flags now goes
straight to the workgroup containing the Refund script host.

14) Make sure this director is shared into all the areas where it existed before replacing it.