Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
As I understand it, in the VisaNetAuthorization table RMS is supposed to increment the RequestBatchNumber after each settlement, and roll over after 999 back to 001. Settlement is either manual via Manager at close of business or automatic when reaching 100 transactions in the batch. What we have been seeing occasionally is the number does not properly increment, at times it jumps back to recently used numbers which are then flagged by TSYS as duplicates, when they are really not. When trying to settle one of these false duplicate batches, the user is prompted to delete the duplicate information to complete the settlement. This provides a potential loss of data necessary to complete the day's sales. TSYS is charging us quite a lot of money to rekey the transactions after they have been wiped from RMS. Does anyone else have this issue and a possible solution? All of our batch sizes are default to 100 across all machines.
Our table looks like this:
Batch ID 3148, Response ID 078, Accepted
Batch ID 3149, Response ID 079, Accepted
Batch ID 3150, Response ID 077, Duplicate
Batch ID 3151, Response ID 078, Duplicate
Batch ID 3152, Response ID 079, Duplicate
Batch ID 3153, Response ID 080, Accepted
So as you can see, after batch 3149 was accepted by TSYS, the next batch was somehow created with the response ID of 077. Since IDs 77, 78, and 79 had been recently used, they get flagged as duplicate. Once ID 80 comes in we are good to go. Our procedure to workaround this is to manually increment the batch ID when the issue comes up, but that only works if the user doesn't just click "yes" to delete the dupes.
What logic does RMS use to increment the ResponseID? Is there a way to prevent this?
I remember an issue that RMS had with the incrementing of the batch numbers not so long ago. One of the hotfixes cured it for me. Currently I am on version RMS 2.0.1004
I don't remember which hotfix fixed it.
What version are you running? I did the CU5 update (2.0.2000) and we are having issues with duplicate batches. I think it's something tied to CU5.
We are on 2.0.1004, so Feature Pack 2 with Hotfix #35. We are still in the testing phase of the upgrade.
Bumping for desperation. We have been working with MS Support on this and getting nowhere. Still having the same issue across multiple stores. We had one happen less than 2 weeks ago and the deposit was $4,000 short. Does anyone have any ideas?
I am having the same issue with a customer. Any suggestions on a fix?
No solutions as of yet. We are still waiting to hear from Microsoft, they escalated our case to an engineer who is very slow to respond (think weeks just to reply to emails). We have the following suggestions from Microsoft which may help. We have implemented them but the issue still occurs, perhaps one will work for you:
1. Ensure that the following 7 known causes are not relevant:
1. More than one computer pointing to the same register number.
2. Using the Delete Transactions function in Store Operations Administrator.
3. Using unsupported Credit/Debit Gateways.
4. Using different default batch sizes on one or more of the computers. Supported/Recommended batch size is 100 and should not be changed.
5. Changing VAR Sheet information in the middle of an EDC batch.
6. Running transactions while the batch is being settled.
7. Multiple stores (locations) using the same EDC setup configuration.
2. Install the latest service packs for SQL Server.
3. Go through the following on applicable Operating Systems:
Microsoft has identified a compatibility issue that occurs when you run Microsoft Dynamics Retail Management System RMS Store Operations, Microsoft Dynamics POS 2009, or Microsoft Dynamics - Point of Sale on a computer that runs any of the following Windows Operating Systems:
" Windows Server 2003 and 2008
" Windows Vista Service Pack 1 (SP1)
" Windows XP Service Pack 3 (SP3)
" Windows XP Service Pack 2 (SP2) with hotfix 940569
We strongly recommend that you apply all Windows Critical Updates with Microsoft Update or Windows Update. This will install a fix for this issue automatically together with other important Critical Updates that are missing from your computer. At a minimum, all users who are running any of these Windows Operating Systems should install the following Microsoft Hotfix:
Do not run Store Operations, POS 2009, or Point of Sale until you have installed the fix. This compatibility issue may cause data loss in Store Operations, POS 2009, or Point of Sale databases. For more information about specific problems that may occur in Microsoft Dynamics RMS, refer to the following CustomerSource Hot Topic:
4. Ensure that the HQ Client is not on the database server.
Something you mentioned in your first post caught my eye. You explained:
"Settlement is either manual via Manager at close of business or automatic when reaching 100 transactions in the batch."
I am not familiar with any automatic feature that performs a settlement after 100 transactions (at least I am unaware of this feature and I would be very leery of it if I did) -- I am wondering if you go to a manual mode across your organization and see if this resolves your issue. Automation utilizing scripts or whatever could possibly be messing up your incrementing of batch ids?
Just a thought.
Ah, my mistake, it does not automatically settle at 100, it rolls over into a new batch and still waits to be settled. We are not using any automation, our users still have to settle manually every day.
I had a database for one of my stores begin to do odd increments of quantity sold etc. I also put in a incident help with Microsoft and we did all the upgrades etc. for rms, sql and SBS 2003 Server etc as is being suggested above. None of that actually fixed the problem. The RMS database has worked for me for years without many issues (except when I voluntarily implement hotfixes/Feature Packs etc. before they have been truly vetted). The only solution I have found for when the database becomes quirky is to start over with a fresh database. I have tried restoring from a back-up, but usually the corruption in the database reappears due to the fact my backups came from the corrupted database.
If you are utilizing Headquarters, you can export a new database based on a fresh database created for the exportation of your store's database. Things to watch out for when creating a new database by exporting from Headquarters is to make sure that Headquarters has received a 401 update for the close of the day. This is important because the EDC Batch ID is communicated to Headquarters and if you create the store database prior to the last 401 (with the edc settled, all registers Z'd out etc) you will have a duplicate batch id for that day. This is store specific/store database specific.
I would try this on your problem store(s).
It could be that one or more of your stations/lanes is setup for a batch size other than 100. So when you are batching out for Store Ops Manager, it is closing the batch for number 20 then 21, but some transactions are still under 20 when they shouldnt be.
Go under Admin-> Configuration ->EDC -> Advanced Options ->> Advance and make sure all are set to the same value.
Never had a problem with this and we have multiple customers on SP2 and CU5 and between.
Could you please describe in detail the process of "Our procedure to workaround this is to manually increment the batch ID when the issue comes up"? We think we are having the same issue.