WD 361098

Total Sale Electronic Coupon Void is missing fields in UMI: Type and Lookup Code.
The Problem :The Universal Marketing Interface (UMI) is missing fields in the case of the void of a total sale electronic coupon. The two fields missing are the Type (which should be 8 - Total Sale) and the Look Up Code (which should represent the amount of the sale).
This same behavior is happening to Department Total type Electronic Coupons.

NOTE: Even though the lookup for a Total Sale type EC is the sale amount, the amount of the coupon is still populated in the Amount field. 
 
Scenario:
1.Enable the UMI Interface
2.Set up a ScanMaster Total Sale Electronic Coupon
3.Ring a sale large enough to receive the total sale electronic coupon
4.Hit total
5.(See the L record in the UMI has the Type field in position 49 marked as an 8 - Total Sale Type and the Look Up Code in position 49-69 as the sale total)
6. Hit CLEAR to return to sale

Expected Results: See the L record in the UMI has the Type field in position 49 marked as an 8 - Total Sale Type and the Look Up Code in position 49-69 as the sale total

Actual Results: See the L record in the UMI has the Type field in position 49 marked as a 0 - (not defined) and the Look Up Code in position 49-69 is all zeros.

WD 364562

USCAN: PICK 5 EC reverses after returning from finish and pay but will never display the discount again.
The EC Pick 5 discount is reduced the first time you press finish and pay. If the customer goes back into the sale the EC discount reversed. This is as expected. But if the customer scans an item not on file, the attendant clears the item not on file message and press finish and pay, USCAN never displays the EC Pick 5 Coupon.

Scenario:
1. Ring up items to satisfy a PICK 5 EC
2. Press Finish and Pay
3. Scan an Item Not on File
4. Clear the Not on File message (Do not add amount and dept)
5. Press Finish and Pay

Expected Results: USCAN should issue the EC discount again and display the correct total

Actual Results: USCAN does not so the EC discount again and the wrong total is displayed

WD 365027

Weight in UMI record doesn't include tare on a void.
It does, correctly, deduct the tare in the weight when the item is initially sold. This makes the weight for the void appear different from the initial sale.

For example (see UMI record in attachment)
Weight = .43 lbs.
Tare = .12 lbs.
Weight shown in sale = .31 lbs.
Weight shown in void = .43 lbs.

Scenario:
1.Turn on UMI / UCI
2. Ring a weighted item with a tare attached
3. Void that item
4. Look in the UMI file
5.
Expected Results: The weight field in the item sold and item voided records are the same with the tare deducted.

Actual Results: The weight in the item sold and item voided records are different with the voided record not deducting the tare amount.

WD 377918

eWIC: POS aborting completion when Item Action Code received.
When the eWIC processor sends an approved completion of an eWIC transaction that also includes an Item with an Item Action Code, the POS is aborting the eWIC transaction and is left requiring payment.
This logic should be changed since the overall eWIC authorization was Approved. In the case where Item Action Codes are received with the approval, they should be treated as information-only and functionally ignored by the POS

Scenario:
1.Ring an Item that causes the eWIC processor to return an Item Action Code such as 26 - Approved for a lower price (Peanut Butter)
2.Tender eWIC

Expected Results: Transaction is approved and POS moves on to next order

Actual Results: Transaction is approved via EFT but the POS is left needing another tender to complete transaction as if the eWIC tender was not accepted

WD 379145

Change amount not showing on Cashier Display.
The Problem : Cashier Display is not showing the change amount after tender is entered and drawer pops open on new NCR 7606 platform

Scenario: NCR 7606, SM 2.9.0-60
1. ring up transaction
2. total
3. enter amount more than total
4. hit cash

Expected Results: drawer pops open and change amount is on bottom of Cashier Display with Close Drawer message at top

Actual Results: drawer pops, the change amount quickly flashes in appropriate place on cashier display but is replaced with $0.00 and there is no close drawer message even though the drawer is open. The Cashier can look at the receipt to get the correct change amount. Was able to correct problem by setting the YCableStatus to 1 and the OpenDrawerSUE to 0 in the Registry under Cash Drawer, NCRCashDrawer.1 and then Model for second setting.

WD 379886

SM2RPAIR.EXE - the repair movement option is not fixing all nulls in the movement records.
The Problem : the repair movement option is not fixing all nulls in the movement records. This was reported by BMC at their Glory Supermarket store.

Scenario:
1. Had a store with RBO start pulling movement and the extract file was failing in RBO due to nulls in the data.
2. It has not been determined how the nulls got in some of the records. It may be a result of an older movement file that was upgraded.

Expected Results: Extract shouldn't have nulls in any field.

Actual Results: Nulls were seen in the blanks field and occasionally in a few movement buckets.

WD 379889

SM2RPAIR.EXE - the movement repair procedure is not fixing all of the nulls in a record.
The Problem : the movement repair procedure is not fixing all of the nulls in a record.

Scenario:
1. Customer started using RBO to extract ScanMaster movement but the extract was causing RBO to fail when importing the extract.
2. I found nulls in several records, mostly in the Blanks field.
3. Ran Sm2rpair on the movement file.

Expected Results: All nulls should have been converted to zeros

Actual Results: Nulls remained in several records.

WD 379943

At EOD on the POS rlaunch.exe gives error, click OK, and reboots lane.
The Problem : PSKILL.EXE is missing from C:\grocery, thus Rlaunch cannot stop the lanehawk application and will force a reboot on the lane.

Scenario: NCR 2.9.0-60, LaneHawk
1. Run EOD on system

Expected Results: EOD runs on POS and ScanMaster restarts with no issues

Actual Results: EOD runs on POS but the error ""File not found in rLaunch2.modMain.Main at line 630" appears and a reboot occurs.

WD 380143

Trying to retrieve a suspended sale results in a 62 error and ScanMaster shut down.
The Problem : Suspend/retrieve, get a error 62 input past end of file hit clear to shut down when trying to retrieve a suspended transaction with 2.9.0-70

Scenario: 2.9.0-70
1. suspend a sale
2. retrieve the sale

Expected Results: At the time of selecting the specific sale to retrieve the cashier screen should show the sale information

Actual Results: At the time of selecting the specific sale to retrieve the cashier screen shows an error 62 input past end of file hit clear to shut down, also the suspended sale is locked and must be unlocked in the system services part of the backoffice or the message "suspend process busy - retry" will appear on the screen, tested on 2.9.0-60 and the suspend/retrieve process works with no issues.

WD 391425

Zero Mover Batches select items with movement.
The Problem : The zero movement batch will actually select items that have movement and will lead to the deletion of valid items

Scenario:
1. create a zero mover batch
2.create a ytd movement batch
3.compare

Expected Results: no same items on both

Actual Results: items with movement appear on zero mover batch as well.  The zero movement batch does not look at movement, but instead looks at the date the item had the its price modified last. If the price was not modified since the date selected with the batch then it is included in the batch even though it could have movement.

WD 393611

Cashier tlogs appearing in multiple Ctlog, not being deleted from F:\Grocery\files.
The Problem : a cashier tlog is being left in F:\grocery\files and also moved to F:\tlog over multiple days causing movement and inventory issues

Scenario: 2.9.0 and past SM versions running with 3rd party software
1.cashier signs on and tlog record opened in F:\grocery\files
2.cashie signs off and is settled and or delayed - moving tlog to f:\tlog
3.check f:\grocery\files

Expected Results: cashier Tlog no longer in this folder.

Actual Results: cashier Tlog still exists and will be moved to F:\tlog again when cashier is settled on another days business.