We have a tender type (return merchandise card, basically a gift card) that has the option to prevent cashier over tendering checked. We got a report of one card that should have had a balance but was actually 0. When we looked into the card history, we found a negative tender on the card. I ran a query at our HQ, I found 90 entries with negative amounts over the past year. I went through our testing environment and tried every method I could think of, but I have yet to actually get the point of sale to overtender to that tender type. Does anyone know of a reason this could happen? Looking at the journal from the latest incident, it was the only tender type used (ie, did not combine cash and card etc).
I pulled security video from the register but I can't really tell what was entered. I also verified that the tender type options match at the HQ and store levels. I'm launching an investigation with the store and the cashier but from the video, it looks like he called his manager over right away and realized something was wrong. I can provide an example if needed. Any thoughts or help appreciated!
*This post is locked for comments
AX ? lol
seems that theres a bug, yeah , we use separate processing from moneris called ernex, with another terminal for gitftcards, we enter in pos as cash.
for the vouchers , we never had a problem , do you use any 3rd party apps on these ? loyaltee add ons etc etc ?
So to you guys with the .Net conflicts: Which version do you recommend we stick with?
Jesse, ours is set for "voucher" and is also set to prevent over-tendering.
Artsyguy, for your gift cards, are you using the Account or Voucher tender type type? Ours is set to "Other" with a hook and an in-house server dedicated to handling stored value cards. Regardless of the that setup, we still have the box checked to prevent over-tendering in RMS and I have the receipt and journal entry to prove it was actually somehow over-tendered.
There is definitely a bug in RMS regarding gift cards. I've been told that Microsoft knows about it.
We found one when we were doing training. We put money on a gift card then voided the transaction. BUT the card still showed money on it when it was checked, even though the transaction was voided!
Another, we had a gift card transaction that was started then put on hold, then that same card was accidentally sold to someone else for $150. Then the hold sale was recalled and that same card was sold AGAIN for $200. We then had a $200 card that needed to get to $150. We took $50 off of the card. When the card was eventually brought in to be used by the customer, we did a balance check on it, it showed TWO LINE AMOUNTS in the dialog box: "-$50" AND "$200"! When it was swiped as a tender, it came up as a FULL $200 NOT $150! Such a headache.
To fix both the "NON-VOIDED" card and the "$200/$150" card, we had to manually go into the SQL database and do queries to set the cards to 0.
Obviously, there are some serious issues with gift cards and RMS.
I recently updated and added more tender types to our POS menu. I checked all to prevent overtendering. When I processed transactions in our DEV environment, I also noticed the system was ignoring the restriction and allowing overtendering. I checked the Store DB and the HQ DB to make sure all the settings were the same and the prevent overtendering was selected. Everything checked out, but the POS still allowed overtendering. I am getting ready to apply the new CU 5 and I am hoping there is something in there that is going to fix this issue. Although, after reading the accompanying summary I am not very hopeful. There is nothing in there that says it fixes this.
Also I would be curious to remove .net 4 and see if the problem goes away. I had some issues with .net 2.0 programs I wrote after the client upgraded to .net 4. This is why I brought this up.
-Jerry
Hi, guys.
I am interested in the potential conflicts arising with .net 4. But I don't think this has anything to do with this issue. I think this is in the RMS programming and needs to be addressed by the RMS team.
Anyone else have an opinion here?
-Jerry
Hi Josh,
Thanks for the insight. In our latest incident, there was only a single line for tendered payment, which was the return card tender type. In the security footage of the transaction, it appears the customer only handed over one card to the cashier. I also checked the footage and journal from the previous transaction on that register, and no return card was used, and the transaction was completed in full with a Visa payment, so there should not have been any residual tenders left in.
In the query I ran, we had 446,000+ transactions in the past year with that tender type, and 90 of them had negative entries. This means it does not happen often which leads me to believe it is a software glitch of some kind. Still, 90 is a significant amount of potentially unhappy customers. In our case, the tender type "type" is listed as "other" (not voucher or account) as we use an in-house written hook to maintain the card balances on a separate server. This should not be relevant to the issue though, because the "Prevent cashier from overtendering" option is still checked for that tender type, and the hook only comes in to request the card number after the tender is executed. It should not allow an overtender in any case, yet I have the receipt showing that it did.
Hi Gerald,
Thanks for the reply. Our RMS software is at 2.0.1004 (Feature Pack 2, Hotfix 35). We are running on Windows XP SP3 for the registers. On the latest incident, the .Net installed versions on that register are:
Microsoft .NET Framework 1.1 (1.1.4322)
Microsoft .NET Framework 2.0 Service Pack 2 (2.2.30729)
Microsoft .NET Framework 3.0 Service Pack 2 (3.2.30729)
Microsoft .NET Framework 3.5 SP1 (3.5.30729)
Microsoft .NET Framework 4 Client Profile (4.0.30319)
This should be mostly uniform across all stores as well.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,240 Super User 2024 Season 2
Martin Dráb 230,149 Most Valuable Professional
nmaenpaa 101,156