There is a persistent problem in RMS HQ Environment (220.127.116.11) which I have seen multiple times on the newsgroup whereby transfers which are sent from a store do not necessarily arrive in the receiving stores database.We are Resellers and have a few hundred clients using RMS and this issue affects all of them with a HQ environment.
Firstly, we have the "Automatically create inter store transfers" options checked in HQ Configuration
Secondly, we have the SQL which will fix this and have actually developed a tool with a user interface to simply this process for our end users.
My question is, why is the root cause of the issue still not fixed? It has been claimed to have been resolved in a previous hotfix (Prior to 18.104.22.168) and there has been no subsequent release note to indicate the issue is fixed. We have lodged several support cases with Microsoft and we are either told to upgrade to the latest service pack or they are unable to replicate the issue. I don't think it is being taken seriously.
It appears to be an issue with HQClient. Periodically, HQ Client does not populate the HQMessage table in HQ
This image shows the HQMessage table in the sending store. It has 2 records for attachmentid 6450 (The first 2 records) which is the InterStore Transfer. The other 2 records show a transfer which has been sucessfully downloaded to the receiving store. Aside from the obvious differences, these records are the same, from a logic point of view.
This next screen shows the HQ Client log for the time the HQMessage (Above) was sent to HQ. It has not logged any updates to the HQ Message table. In successful Inter Store Transfers, during the WS401 process, the HQClient Log clearly states when the HQMessage table has been updated.
And the final screen shows that there are no entries in the HQ Databases HQMessage table at all.
To me, this is a clear bug in the way HQClient is operating. And I can't be the only user, or reseller with a pissed off client. This particular client has 27 stores and they are finding 10 transfers a day not being uploaded correctly.
Microsoft - when will this issue be fixed, and is anyone else fed up of this situation?
Also, this happens on all varieties of SQL Server and Windows OS. This example was with Windows 7, SQL Express 2005 SP3 at Store and SQL Server 2008 at HQ.
You have sold hundreds of copies of RMS and this is your most pressing issue?
This has been discussed on the reseller sites many times. The first thing you need to check is that the clocks on each of the stores and HQ server is correct. Even being 10 seconds off will cause this problem. If the approving store's clock is 10 seconds behind of the recieving store, the effective time has already passed.
We suggest to our clients is to set the effective date/time is 15-30 minutes in later then the current time. That seems to solve most worksheet issues especially with so many stores involved.
What do you mean by "effective date/time?" Are you referring to the PC clock (ours are sync-ed with the server automatically) or something within the transfer? I have this problem also and have noticed it happens if both stores poll at the same time and the sending store's polling session finishes after the receiving store.
Yes im a bit confused by this also? What do you mean affective date and time? There is only a option to adjust the effective date and time if you are using worksheets. Is this what you mean to set the effective date and time half an hour in advance in normal day to day use with normal worksheets as a matter of course
And just expanding on the auto created inter store transfers I can understand that timing is of most importance does this then point to the date/time stamp being the condition (Flag) for polling and not the worksheet status?
I wonder if anyone can help me fill these gaps in my knowledge
I will be really interested in your response
Thanks In advance
Yes - This is the most pressing issue. We have worked around many of the issues we have come across by developing addins and tools to work around things. But this one is a fundamental issue. We have one client where this is consistently happening throughout their 27 store estate. They are performing 5-6 transfers per store per day, and about 5 go missing. Its not unreasonable to expect RMS to handle these correctly, as having to sweep up behind RMS everyday when they have purchased the software which is supposed to work is adding to their HR costs.
THe effective date/time is also a non starter - HQ Client should be automatically processing and creating new WS 401s each hour in the setup they want. Its not possible to back/forward date/time these worksheets which are automatically created.
I have managed to recreate this issue twice following the same procedure however the third time I ran the same procedure it did not produce the problem. I know it is to do with the WS401s and I think it is to do with when there are more than 1 401 waiting to be processed - A manual one and an HQ Client created one, but need more time to test this theory.
yes agreed this is an issue we have seen this also in a new client, we are a small new zealand reseller and our second HQ rollout has this issue and has caused massive inventory problems for our customer... stock has litterly left one store and never arrived at the second store and its thrown inventory values out all over the chain.
This is a bug and certainly is NOT fixed in any of the SP packs or hot fixes. We do need this looked at for certain.
Sorry, I was thinking worksheets when I said Effective Date. Transfers are Date Required.
If you look at the Purchase and the InventoryTransferLog tables (the tables that keeps track of POs and Transfers), you will see that the Date Transferred as well as Date (creation date) and Last Updated are counted to the second. If the clock is off, the time may have already passed if the remote computer's clock(s) are wrong.
Also, if one is creating a Transfer or worksheet while a 401 is running for that store, the worksheets and transfers can be whacked too.
Another thing to worry about, never ever change a PO or Transfer number. Let the system create the numbers. If you need more info about the transfer/PO, put it in the comments.
FWIW, we have over 200 bugs/annoyances internally logged for RMS. Remember that RMS has not had a HotFix for 13 months or a Service Pack for 20 months. The highly touted Feature Pack 1 was released 3 months ago, but did not include a single bug fix, it only introduced more buggy features. We are not recommending the installation of it at this time.
in addition to this we have also seen partial transfers...
what happens is some of the transfer comes through and whole sections of items are missing at the recieving store... so they leave store A but only half arrive at store B in the transfer... messy and very confusing...
I have this same issue. My setup consists of 14 stores, 2 warehouses(also set up as stores,) and an hq server. This occurs randomly to a degree...usually on days of heavy interstore transfer(several receiving transfer orders from to different stores never show up) but occassionally it will occur on just one transfer.
All of our stores and the HQ server sync their system clocks with the DC on the network. I've come across other posts in the forum which list all of the SQL scripts to try to locate and "FIX" these transfers.
I'm interested in this add on that you have for working on this issue. Please contact me with more info.
Have you gone through the following KB article?
You experience unexpected results when you try to process inventory transfers in Headquarters or in Store Operations
I'm running RMS 2.0. From the link you posted the majority doesn't apply as the issue I'm seeing is that when the transfer is initiated at the sending store, all items issued, and then all items committed, sending store polls HQ via 401 worksheet, HQ doesn't produce an HQ message entry for the receiving store to receive the transfer. If I use SQL to insert a record for the receiving store in the HQmessage table, then back date a worksheet 401 prior to the HQmessage entry for the receiving store, have the receiving store poll HQ to process the 401 the transfer comes through with no problem.
The corresponding entries for automatically create inter-store receive inventory order and issue orders are checked in the HQ config page.
From that standpoint if it were an issue with HQID values or items not existing in all stores the steps I am following as I mentioned above should not work.
Also we are using the system generated transfer order id number.
also run a 401 but XXX minutes in the past... it will catch up, XXX is the time your stores talk to HQ, if you set to 1 hour, make it 65 minutes in the past...
Sorry its been a long time since I considered this thread.
We were reliably informed that the next feature pack would resolve these issues. But looking at the fix list for FP2 (Which on the whole looks to be a massive let down feature wise) its not even been addressed. Instead, they have just chucked a couple of extra QRPs to highlight the issues further which is very unhelpful.
Chris, our addin is called RTL POS Utilities and is designed to be a quick way to send and receive goods at the POS. The Transfer Out prints a slip to the OPOS printer including a barcode.
At the receiving store, they scan the barcode and it looks for that transfer in the database. If it can;t find it because HQ client screwed it up, it also does a reverse lookup into the HQ database on port 1433 (So needs a VPN/Open port and SQL configured appropriately) and marks the records to be retransmitted and creates a WS401. The store can then process the WS401 and voila, the transfer appears.
There is a bunch more functionality. Check out http://addins.rtl-world.com and click RTL POS Utilities to see the full demo and download a 30 day trial. The feature we're talking about here isn't listed as such, but works brilliantly. Alternatively hit me up on firstname.lastname@example.org and I can help you get it set up, or cal +44 845 450 4905 and I'd be happy to help.
Not sure I'm following you...after running the appropriate SQL scripts I run a 401ws backdated prior to the date of the transfer that is in limbo.
You all might check out the FP2 release last week that makes the process a little easier. Check the Blog page at the top of this one.