Single item promotion that was deleted before expiration, still scanning at promotion price.

Scenario:

1. Create single item promotion. Expires in 1 week.

2. Scan item - verify item is discounted.

3. Delete single item promotion.

4. Check PLU maintenance, verify item is no longer linked to promotion.

5. Scan item - should change back to original price. Still shows promotional price.

Expected Results:   Item should revert back to original price.

Actual Results: Still shows promotional price. No longer linked. CRC doesn't show differences. Rebuilt QDX files and sent to lanes. Still scans at promo price.

Reprocess at Late Swipe On - Activate Gift Card on Swipe, not after Tender.

Ring in some items and a gift card. Swipe gift card to activate, scan member card. Ticket reprocesses and ask you to swipe gift card again. Now card has double the amount but transaction asks for original amount.

Customer that turned this in is also seeing different results with same issue. After gift card activate and then swipe card, sometimes it zeroes the entire sale out. They can duplicate this one, however I cannot. I can only duplicate the double amount on gift card.

Negative flag validation should be done according the flags in the batch or the PLU table flags.

Scenario:

1. In PLU batch - touch the Vendor coupon flag and make it BOLD but FALSE

(means will be set to 0, but this property was touched, hence will be updated with FALSE)

2. set a Negative entry flag to TRUE (it becomes BOLD and TRUE)

3. go to PLU and set for same item Negative=TRUE, Vendor coupon = FALSE (also other coupon flags should be false/unset)

4. execute the batch - it will fail with setting the Negative flag over the existing value.

When entering Database Management/Financial/Tender Maintenance and a tender is selected, invalid data is assigned to the tenders. When a control check is highlighted and the backspace key is used to de-select, the control check, another control check takes its place. When you exit the screen and go back in, other control checks appear.

Randomly a record will not be written to SQL. This seems to be a timing issue, and has not been able to be reproduced in the lab.

SmartCard WIC EBT - Claim file should use 'System' Date in Header and Trailer records as well as the Claim file name.  Currently, The header and file name have the working date while the trailer has the system date.

Smartcard WIC EBT - When errors occur with importing either the HCL or APL the lane should not be refreshed with the failing file.  If the import of the HCL receives errors then the lane should not be refreshed with the HCL.  If the import of the APL receives errors then the lane should not be refreshed with the APL.

First EOD for February after a Leap Year will fail if last day of February is still defined as 29.

Scenario:

1.Set System date to January 31st during a Leap Year (2004, 2008, 2012)

2.Set General System Parameter for STORE\Front Office\End of Day\Period\End of Month Definitions for February to 29

3.Run a End of Day\End of Month

4.Set System Date to the next non Leap Day year

5.Sign on a lane and run a transaction to generate some new data for Current Files

6.Run another End of Day with working date = February 1

Expected Results: EOD will run normally

Actual Results: System throws a Run Time Error 13 - Type Mismatch error and EOD aborts. EOD will not run again until the GSP setting for February is set back to 28.

When MFS's and POS's come back up after a power outage and the AutoEOD kicks off during a prohibited time, ISS45 should pop up a screen that says "Auto EOD has started, but system time conflicts with system parameters. Do you want to continue with auto EOD"

*NOTE*

8.1.3.0 if registers go offline i.e. power failure, once the system comes back up ISS45 used to pop up the attached screen 'based on the hours set in GSP for automatic EOD to run' and it would give the retailer the ability NOT to run the EOD until after stores hours.

Scenario:

1.Set up GSP that specifies the auto EOD time.

2.Lane goes offline

3.Lane comes back online after auto-EOD has ran

Expected Results: Customer should get an option to run the EOD on the lane or not

Actual Results: ISS45 does not give the retailer the pop-up or a choice to decline EOD (ignoring the GSP hours for EOD and no message) thereby causing delays in store clerk processing while the EOD runs automatically once the system comes online thereby interrupting front-end activity.

Scenario:

1.Run End of Day on a Stand A Lone MFS1 and a Dual MFS system

2.Check the PCMASTER\BAK folder on MFS1 and MFS2

Expected Results: The PLUTODAY.zip file will exist in the PCMASTER\BAK folder on both MFS1 and MFS2 along with numerous other compressed files (TRB,ELB,EVB,etc...)

Actual Results: PLUTODAY.zip file does not exist on MFS1 or MFS2 on the dual system and no files at all exist in the PCMASTER\BAK folder on MFS2. There is an error in the e-of-day.log file referring to RCOPY Failed.

Can no longer create a zero movers batch Can no longer create a zero movers batch for all items with zero 0 movement.

Scenario:

1. Add two items to the system (1 and 2)

2. Sell item 2 and return item 2

3. Run "Items with No Movement" report for "Today" -- both items are shown

3. Run an EOD

4. Run "Items with No Movement" report for "Yesterday" -- only item 2 is shown

Expected Results: Both items have QTY Sold of 0.00, both should show on the report

Actual Results: Only item 2 is shown on the report.

There are thousands of entries in the RSMSRV.log file with bogus POS numbers and error messages.

Scenario:

1.Open the RSMSRV.log file in the PCMASTER\Log folder

Expected Results: The information in this log will contain useful and relevant information

Automatic EOD does not start, either because if just didn't start, or because the MFS1 has lost power. MFS1 is restarted and you will see a line in POS_SRV_MANAGER that the auto EOD job has been created. But it never starts. There is one entry in the EOD log - EOD Interactive Part : Started. Waiting as long as 30 minutes for the automatic EOD to continue and it never does. But when a manual EOD is started then the auto EOD will begin. The manual EOD will have the correct working date and next working date. The auto EOD will almost always have these dates advanced one day. A manual EOD needs to be run for the next day since it won't run automatically since it already ran.

Deleting a standard promotion from Front Office removes the record from SQL but not QDX. These promotion records are stored in the Brom.qdx file on and are not being removed from the server or the POST.

Scenario:

1.Create a new Single Item Promotion in Front Office

2.Check the number of records in the brom.qdx file on MFS1 and the POST. Also check the PROM_HDR and PROM_ITM tables in SQL on MFS1

3.Delete the promotion from Front Office

4..Check the number of records in the brom.qdx file on MFS1 and the POST. Also check the PROM_HDR and PROM_ITM tables in SQL on MFS1

Expected Results: Records will be removed from SQL and QDX

Actual Results: Records are only removed from SQL

-Enter Member Card #42030573645

-Ring UPC#1, that gives an S&H You Tech $1.00 Coupon

-Ring 2 Diet Pepsi's

-Ring UPC#1, that gives an S&H You Tech $1.00 Coupon

-Hit TOTAL/ENTER

-Hit C to go back into sale

-VOID TRANSACTION

The "I" message for Field 'ff' is sending a 00=Normal Item in Sale Mode for the Voided Items, instead of an 01=Void normal item in sale mode.

Also, showing two B00, Beginning of Sale for Ticket #143.

Voiding Quantities also appears to be an issue.

Voiding individual items, appears to be reporting properly. ISS45 is sending the "I01"= Item Information Message with 01=Void normal item in sale mode.

When wait4plu unzips the plutoday.zip file on the MFS2 it errors out. The plutoday.zip filename needs to have the full path (C:\pcmaster\bak\plutoday.zip) added to it in the dunzip command.

Scenario:

1. Run EOD

2. Verify that the QDX files were unzipped onto the MFS2.

Expected Results: The QDX files have changed.

Actual Results: The QDX files are the one prior to the EOD.

(First appeared in 8.1.6.0-070 as WD# 291163 .)

Cashier cannot cancel out of manager ID entry for override of EFT check decline.   -Found during Elavon certification.

Scenario:

1. Casher tenders check and the check is declined by MTX with the option of a manager override.

2. POS asks for manager ID and password but cashier attempts to cancel by pressing CLEAR.

Expected Results: Tender is cancelled. and POS returns to tender selection state.

Actual Results: POS re-prompts for manager ID password. Cycle continues until valid manager ID/Password is entered or POS is restarted.

Key-entry of PLU in U-Scan Direct mode after Key-entry of Member number at Robot causes Item Not Found error

Scenario:

1. Configure U-Scan to use the keypad for member number entry at start of sale.

2. Enter a Member number using the keypad.

3. Enter Direct mode on the cashier station or the robot.

4. Key-enter a PLU and press ENTER.

Expected Results: Item will sell (if it is on file, of course)

Actual Results: Yellow error box:

Item not Found!

Item Code: 0

Press (C) to continue

EFT Stub receipt displays the wrong information when requesting cash back with a debit card.

Scenario:

1. (WHEN USING A DEMO HOST) ring up a transaction of $5.01

2. Total order

3. Hit EFT

4. Customer swipes card selects debit enters PIN number

5. Customer selects $20.00 cash back

6. When the Is this amount okay box appears the customer selects no.

7. Cashier enters a new amount, $5.01

8. Customer gets prompted for cash back again… which they decline, no cash back this time

9. The customer gets prompted to okay the amount of $5.01

10. The register sends up a debit transaction for $5.01… however, the EFT stub receipt is incorrect: It shows the following: Purchase $20.01 Cash back $15.00 ----------------- Total $5.01

Expected Results: The EFT receipt will display the correct amount as follows: Purchase $5.01 Cash back $15.00 ----------------- Total $20.01 11. Checking the MTX server all of the information within the MTX Server is correct. QA helped me recreate the issue.

Actual Results: EFT Stub receipt displays the wrong information as shown above.

Manually entered check numbers are truncating 1-2 numbers of the Check Number. This only appears with manual entry as a swiped check goes through fine. Per MTX their spec shows that the Check Number field should have a minimum of 8 characters and we are limiting it to 6. The example from the attached journal logs:

04/22/10 10:20:06.936 SERIAL MTX_POS_SET_ExtendedCashierPrompts = Enter Check #,,,,

04/22/10 10:20:06.936 DLL-EX MTX_POS_GET_ManualEntryMICRFlag = True

04/22/10 10:20:06.936 DLL-EX MTX_POS_SET_CheckNumber = 954601

04/22/10 10:20:06.951 DLL-EX MTX_POS_GET_SCATStatus = 1 <Done>

Scenario:

1. Ring up an item, hit total

2. Select check, bypass the scan for manual entry

3. When prompted for the check number, enter "12345678"

4. Log will show that we only send the last 6 digits: 345678

Expected Results: All 8 digits are sent for the Check Number

Actual Results: First two digits are truncated

W hen a tender correct or a void tender is done with EBT food stamp transaction it reports both the void amount and the correct amount to the media, weekly business and deposit report. an EOD or week End will need to be ran to check the other than the media report.

Scenario: before doing the scenario check the EBT food stamp total on the media report

1. ring up $1.00 that is NOT food stampable

2.ring up $100 of food stampable items press total

3.select EBT food and swipe card, enter $99 as the amount

4.press clear and do a void EBT tender, go to step 1 again and then enter the correct amount $100 and then cash out the remainder of the transaction which is $1.

Expected Results: when you look at the media report it should only add the $100 that was purchased.

Actual Results: media report shows both the void amount and the accepted amount

Voiding Check During Transaction Throws Cashier Tender Report Off

Scenario

1. Ring up 10.00 to grocery

2. Total

3. Tender 1.00 check

4. Void check

5. Cash order out

6. Check Cashier Tender report

Expected Results: Cashier tender report does not show the -1.00 in the check field

Actual Results: Cashier tender report shows the -1.00 in the check field which lowers the over/short amount from 10.00 to 9.00

Reports are incorrect after a tender correction was done on a check tendered transaction.

Scenario:

1.Ring up an item for $10

2.Tender with a check for $5

3.Void the check tender for $5

4.Finalize the transaction with cash tender for $10

Expected Results: Cashier is accountable for $10 cash. Check totals on checker reports should be $0.

Actual Results: Checker reports show check totals as (-$5) when it should be $0

Voiding tender in an order causes balancing issues.

Scenario:

1.Ring up a item( we rang in 1.39, 12.99) Item total 15.39

2.Subtotal

3.We rang in a gift cert for 1.20

4.Then we voided this tender

5.Tendered cash for 10.00

6.Tendered another gift cert for the remaining balance of 5.39.

Expected Results: The store balance report should reflect the correct totals

Actual Results: If you look at the store balance report it tells you that the cashier is over and short 4.19. This is the difference between 5.39(the second gift cert) and 1.20(the gift cert that was voided).

It should say there was a gift cert of 5.39 with no over short. We get the 5.39 showing up, but we get the over short of 4.19.

(First appeared in 8.1.6.0 -080 as WD# 212440 .)

POS Weight Display does not function with new Enhanced Graphics.

Scenario:

1. Turn on enhanced graphics in winpos.ini.

2. Configure POS to show live weight in POS Configuration

RouteSrv only sends 11 digits for validation on barcode entry at the pump.

Scenario: Scan a barcode with more than 11 digits (usually the check digit) at the pump.

1. RouteSrv should see the card as a member card, assuming it is set up as one.

2. The RouteSrv console returns MediaMasterType=3, this is credit not member.

Expected Results: RouteSrv should allow configuration of variable barcode lengths.

Actual Results: RouteSrv only allows 11 digit barcodes

Multi-Condition promotion Triggers incorrectly when using a Ticket Spend Condition and a Dept is sold in the trans

Prom 5

Condition 1: Qty=1 (2700037913) - Include in Rew - Allocate Discount To

Condition 2: Ticket Spend = $20 (Exclude 2700037913)

Reward: Free Item = 1

Scenario:

1. Sell $20 in Any Department

2. Total

Expected Results: Promotion does not trigger

Actual Results: Promotion triggers and gives the Dept Sale for Free

With Dynamic Receipt, the option to suppress printing is no longer functional.

Scenario:

1. In GSP, Set Dynamic Receipt parameters on

2. In Checkout Banks, set Suppress Receipt printing to Ask Yes/No

3. At POS on that Checkout Bank, run a transaction

4. When prompted for Print Receipt? Yes/No, Hit No.

Expected Results: Receipt will not print

Actual Results: Receipt Prints

NOTE: Is Suppress Receipt Printing is set to "Always" the receipt will still print

Loyalty Promotions are not being deleted at end of day based on the Housekeeping settings for promotions

Scenario:

1. In GSP, Set Store\Front Office\Housekeeping\Number of days before deleting member promotions to 1 - 30

2. Setup a promotion to expire today

3. Wait the number of days set in the GSP and run end of day

Expected Results: Promotions that are expired and have been expired for the number of days allotted in the housekeeping setting, will be deleted from Loyalty Enhanced Member Promotions

When a large number of target messages are triggered, the XML data that is sent from LPE to POS can exceed 32KB. This causes a crash in WinPOS..

Scenario:

Note: I have production files to make reproducing this easier, but you may not need them. I did not want to attach them due to their size, so please contact me for them

1. Configure a Loyalty promotion to trigger a target message for each item sold

2. Sell this item multiple times in a ticket (in my case it was 8 times)

3. Tender the transaction with cash

Expected Results: No crash

(First appeared in 8.1.5.4-090 as WD# 307500 and 8.1.6.0-070 as WD#307501.)

POS blows up in rtapsclient.dll due to memory issue with TCP.lib.

Scenario:

1. Run Loyalty POS

2. Scan a card

3. Enter Items

4. Total Sale

Expected Results: POS will not blow up

(First appeared in 8.1.5.4-090 as WD# 308232 and 8.1.6.0-060 as WD#308237.)

eWic APL file is not being processed at EOD

Scenario:

1. receive a valid APL file

2. run normal EOD

Expected Results: APL should be imported during the EOD process

PrePay

Scan Card at POS

Select $10 Prepay

Select Pump

Complete Transaction

Fuel Prices Rollback

Complete Fueling

(First appeared in 8.1.6.0-070 as WD# 314807.)

Getting "94 Invalid Use of Null" error every time the Specify Round-Up Department option is clicked. I can then select a department, but will get the error again if going to change it.

Scenario:

1. Click "Specify Round-Up Department" option

Expected Results: No errors.

Actual Results: Get error

(First appeared in 8.1.6.0-070 as WD # 315185.)

(First appeared in 8.1.6.0-080 as WD# 296702 .)

Round-up feature does not work if using the MTX_POS_Empty.dll. This feature works if the POS has a payment terminal and is using the MTX version of the MTX_POS.dll, but does not work if the Emptily dll is used.

Scenario:

1. Load system with the .us version of the POS patch.

2. Try round-up feature.

Expected Results: Cashier should be prompted for the round-up message.

(First appeared in 8.1.6.0-080 as WD# 317346.)

IBM UPOS Keyboard Display causes POS to crash on Win 7.

Scenario:

1. Windows 7 embedded

2. UPOS CCO 1.13

3.Configure IBM OPOS 2x20 keyboard display

5. Run WinPOS

Expected Results: WinPOS runs without crashing

(First appeared in 8.1.6.0-080 as WD# 318163.)

PLU selection criteria batch for zero movers has all items.

(First appeared in 8.1.6.0-100 as WD# 320188.)

POS Weight Display and item highlight does not function with new Enhanced Graphics with the Full Touch screen enabled.

Scenario:

1. Enable system to be set as Full touch.

2. Turn on enhanced graphics in winpos.ini.

3. Configure POS to show live weight in POS Configuration

(First appeared in 8.1.6.0-080 as WD# 321490.)

State APL items are not being populated into the CROSS.QDX file.

Scenario:

1. Process the APL file into the system.

2. Sell the APL items on the lane.

3. Verify that they work with EBT WIC.

Expected Results: Once processed the APL items should now ring up correctly on the lane.

(First appeared in 8.1.5.4-090 as WD# 322190 and 8.1.6.0-080 as WD# 322188.)

Credit 2 Debit Conversion does not preserve Card data. Credit Card/Credit 2 Debit conversion will leave Pin Pad/POS out of sync if Round-up prompt pops during customer entry. Card info is not preserved.

Scenario:

1. Set Credit to be converted.

2. Start Sale

3. Slide card and select credit

4. Total Sale

5. Answer yes or No to round-up prompt (doesn't matter)

6. Press EFT Key on POS.

Expected Results: Pin pad should return to enter pin state.

(First appeared in 8.1.6.0-080 as WD# 324168.)

PLU does not show up in the reconciliation files but it does the claim files. Through investigation, it was determined that in the D4 record of the reconciliation file the TransmissionDateTime is empty. This date gets copied to the CLAIM_DT field in the EBT_WIC_RECONCILIATION table.report uses this field to select the data to display for the E2 records. This date is a MMDDHHMMSS (no year) format.

If a 13 digit loyalty card is scanned at the pump for a pay inside (PAK), when the ticket is recalled there is invalid data instead of the member card. The problem is seen when sending the member card number we get from PumpSrv to Rtaps:

Scenario:

1. At the pump, perform a PAK using a 13 digit loyalty/employee card number at the pump (without the check digit) (8009999990010).

2. Fuel prices at the pump rollback.

3. Pump several gallons.

4. At the POS, recall the PAK.

Expected Results: PAK should be accepted into the ticket at the POS. Customer can pay for the fuel and cashier can finalize the ticket.

Actual Results: Error displays at the POS and PAK is not accepted at the POS so customer cannot pay for the fuel.

(First appeared in 8.1.5.4-100 as WD# 325079 and 8.1.6.0-090 as WD# 325081.)

The Account # is only prompted for manual entry on the pin pad, but the expiration date prompts for manual entry on both POS and pin pad.

Scenario:

1. Set manual entry of expiration date for Pin Pad

2. Ring sale and manual enter credit card.

Expected Results: Account # and Expiration date should only prompt for manual entry on Pin pad.

Catalina broadcast messages are sent in RSM FC48 messages to all POS'. Puts these messages in the "POS queue". The messages arrive quicker than WinPOS removes them, the queue can become full (The queue holds 10 messages). This happens, WinPOS may miss some RSM FC messages. manifested itself in production as a delay when selling liquor items, as WinPOS was making a request to MFS1 for the cashier record (cashier age validation), but the response was lost..

WinPOS discards these FC48 messages, so there is no need for RSMSRV to put them in the "POS queue". Can be safely ignored at the RSMSRV level.

Scenario:

1. Set up two POS terminals

2. "Catalina 1.0" in GSP and "Catalina Local Broadcast" in POS Configuration

3. Cashier Age Validation in GSP

4. A macro tool such as AutoHotkey to sell an item every 100-250 msec on POS 1

5. An age restricted item on POS 2

Expected Results: WinPOS does not experience any delay.

Scenario::

1. 92R keyboard

2. Screen 6-1-2-1-4 #7 "Force supervisor ID barcode when supervisor intervention is required"

NOTE - manager bar code is an EAN13 number with four 8's, four 9's (works in any store) and

a four digit manager number

3. Keyboard - set one key as "Refund" with a keyboard privilege of 5

4. Create a manager with a privilege of 5 (minimum)

5. Create a cashier with a privilege of 0

6. Sign on to post

7. Hit the "Refund" key

8. A pop-up screen will require the manager ID, scan manager card and enter password

9. Perform a refund of some sort

10. Hit the "Refund" key again

11. A pop-up screen will require the manager ID, scan manager card and enter password

12. Perform a refund of some sort

13. Tender the order

14. Note that the manager ID did not print (see attached receipt and EJ printout)

15. Check the EJ for this transaction and the manager ID is shown as having printed

16. In attached examples on one receipt no manager ID printed but two in EJ

On the other receipt one manage ID printed but three printed in the EJ

Expected Results: Supervisor number will print on customer receipt

Ringing large orders and POS crashes with POSW32 .NET error.

Scenario:

1. Stop POS service

2. Extract QDX onto your lane

3. Restart POS Service

4. Start WinPOS

Expected Results: Register does not error and transaction completes properly.

Rounding is calculated incorrectly in some scenarios if the balance due amount has a "1" or "2" in the hundredths place. All rounding calculations should be +/- $0.01 or +/- $0.02.

Issue 1: Rounding is calculated incorrectly in these scenarios if the balance due amount has a "1" or "2" in the hundredths place:

- Over tendering with cash (with rounding enabled)

- Over tendering with cash general tenders when rounding is not enabled (in tender maintenance: cash/general)

- Partial tendering with cash (over tendered) as the final tender

These amounts should round the balance due down $0.01 or $0.02.

Issue 2: When performing a negative total transaction, an "over tender is not allowed in negative total transaction" message is displayed for amounts that should round up. This includes balance amounts with a "3," "4," "8," or "9" in the hundredths place. This occurs in the following scenarios:

- Refund

- Coupon only transaction

Scenario:

1. Add a grocery (tax free) dept item for 3.01

2. Tender $4.00 cash

Scenario: Apply Upgrade Patch up to 8.1.6.0-0800

1. Auto EOD is set up to run

2.Auto EOD runs (for two consecutive days)

3.Auto EOD doesn't run after that

Expected Results: Auto EOD should run

(First appeared in 8.1.6.0-090 as WD# 336297.)

Scenario 1::

1 - Set a Yes/No Tender Control Check for Repeat Card.

2 - Complete a ticket with a credit card.

3 - Start a new ticket and pay with the same card.

4 - EFT is approved.

5 - Control Check triggers - Answer NO.

Expected Results: POS returns to Tender state after reversing the approval with MTX

Actual Results: POS returns to Tender states but does not reverse the approval.

Scenario 2:

1 - Configure EFT Tender to check Bad Account file.

2 - Enter account # in bad account file. Use a confirmation Control Check.

3 - Start a new ticket and pay with this tender.

4 - EFT is approved.

5 - Control Check triggers - Press OK to confirm.

Expected Results: POS returns to Tender state after reversing the approval with MTX

Actual Results: POS returns to Tender states but does not reverse the approval.

Scenario 3:

1 - Configure EFT Tender to use ECCA but do not enter a template number.

2 - Start a new ticket and pay with this tender.

3 - EFT is approved.

4 - Error - INVALID ECCA TEMPLATE NUMBER - Press Clear

Expected Results: POS returns to Tender state after reversing the approval with MTX

Actual Results: POS returns to Tender states but does not reverse the approval.

Scenario 4:

1 - Configure a Card Range for an EFT tender.

2 - Select "Force Authorization"

3 - Start a new ticket and pay with this tender.

4 - EFT is approved.

5 - POS asks for Authorization text. Press CLEAR.

Expected Results: POS returns to Tender state after reversing the approval with MTX

Scenario:

1. Scan a valid loyalty card

2.Ring in 50 or more items, they can be the same or different make sure the total is over 150.00

3.subtotal the order

Expected Results: the order completes and prints

Actual Results: the POsw32 crashes and puts an error on the screen. Upon restarting of the POS application the transaction recovers and allows the order to complete

U-SCAN penny rounding has an issue where change will always be dispensed at the Attendant

Scenario:

1. Set up penny rounding in the GPS

2. Ring an item that will round the change total

3. Tender cash

Expected Results: Receipt and change should dispense from the Robot

Scenario::

1. Set a PLU item to have a price of $2.5. in parameters 2 tab - price comparison, set the type to be: "Bonus Buy Savings", set the price to be $5.00.

2. Turn on DRE.

3. GSP - Store\Post\Presentation\Receipt\Regular printing\Bonus Buy -

PLU comparison Printing type = Summary & Line.

Print Summary report header = Yes

Print Summary report for type 1 = No

Print Summery report for type 2 = Yes

Print Summery report for type 3 = No

Print Summery report for type 4 = No

Print Summery report for type 5 = No

Print Summery report for total = No

Print Summery report Footer = No

Bonus buy savings text for "your Savings today" report = You saved

4. Sell the item you set up.

5. Tender out transaction.

Expected Results: Receipt should print with - "you saved on BONUS BUY $2.5. Also, bottom of receipt should print with - you saved $2.5.

Actual Results: When DRE is on Receipt doesn't print "you saved on BONUS BUY $2.5.

(First appeared in 8.1.5.4-100 as WD# 344359  and 8.1.6.0-100 as WD# 344360.)

1. RSMSRV in ISS45 V8 didn't support general macro call with command 102 (EOD status check)

2. TranRule has bad return codes for RlDeclare2 and RlLock3 functions

3. ConnectToSQL.dll had bad COM reference

(First appeared in 8.1.5.4-100 as WD# 344391 and 8.1.6.0-100 as WD# 344392.)

Scenario::

1. Transaction is finished

2.Customer eligible to receive ProLogic coupons after the end of the order

3.Receipt prints

4.Prologic coupons don't always print.

Expected Results: ProLogic coupons should print as applicable.

Scenario:

1. Go to WIC Link Maintenance

2. Enter a 4 digit PLU in Store PLU/UPC number field

3. Enter a 10 digit UPC in State APL PLU/UPC number field

Expected Results: State APL PLU/UPC number field should not allow more than 5 digits.

Scenario::

1. Using PLU Batches, create opcode 'Sale' batch

2. Either Apply batch or set for apply time in future

3. Reversal batch is created

4. Let Auto EOD run

5. Check PLU Batches next day, reversal batch is missing, but original batch is still in PLU batches as applied

Expected Results: Sale Reversal Batch should still remain until actual archive date is reached, and batch is removed

(First appeared in 8.1.6.0-110 as WD# 347348.)

Scenario: