1. Home
  2. Point-Of-Sale Software
  3. interstore transfer lost in HQ

interstore transfer lost in HQ

We have had an ongoing problem though all the RMS versions with inter-store transfers not completing from the sending store to the receiving store.

The tell-tale symptom is the sending store will send it through the HQ client and will show up in the PurchaseOrder and PurchaseOrderEntry tables, but the receiving store never gets the transfer, so their corresponding entries never show up in the PurchaseOrder tables.

I think that the cause of this problem happens when the sending store gets delayed while uploading the HQ Client, so by the time the transfers gets into HQ, the receiving store has already synchronized for that time period, and that transfer gets missed.

I have tried updating the sending store's PurchaseOrder entry with LastUpdated and CreationDate, and scheduling a 401 worksheet for the receiving store to go back and update for that time period again, but to no avail.

Does anyone know what the trigger in HQ is to pass the transfer on to the receiving store? My only solution right now is to put the transfer back in the sending store, remove all trace of the original transfer, and recreate the whole thing - tedious.

Reply to
Matt Hurst
Loading thread data ...

We also have this issue constantly. We hear from our stores on a daily basis that they have transfer requests from other locations that are not showing up in their database. The requesting store will call to get an ETA on the items and there will be no records of the request.

I am pinging our database guy to see what his solution currently is and will update if I hear back.

Reply to
Brandon Klassen

Matt - this is a long-known bug with HQ... What your describing is actually a fault with the "placement" status triggering an entry in the HQMessage table.

I'd suggest tackling these one-at-a-time, as assuming that one didn't go through because of this could be erroneous now and then due to a location not setting something to placed, which could eventually create a problem because first you forced the replication by inserting a line into HQMessage, and then someone went and set it to placed auto-creating another line for the same TO. The line inserted, should you chose to, is as follows:

insert into HQMessage (Status,Style,FromStoreID,ToStoreID,AttachmentID,DateSent) (select '2','2',StoreID,OtherStoreID,ID,getdate() from PurchaseOrder where StoreID={originating storeID} and PONumber={full Transfer Order PONumber})

Note that this created the message to replicate, however it's a 401's being processed that'll actually trigger it to check that message and do it, so wait around for the next 401 to be processed or backdate one manually for a time before when you inserted this line and have HQClient connect. Voila.

Cheers!!!

"Matt Hurst" wrote:

Reply to
YidMo

WOW! why didn't I ask the question eons ago?

The next 401 doesn't catch the transfer, but backdat> Matt - this is a long-known bug with HQ... What your describing is actually

Reply to
Matt Hurst

YidMo - I have found that the line actually exists and that the HQMessage.Status only needs to be changed from a 3 to a 2. I use this line:

Update HQMessage Set Status = 2 Where FromStoreID = @ThisStore and Status 3 and AttachmentID In (Select [ID] From PurchaseOrder Where PONumber = @ThisTransNum and StoreID @ThisStore)

This way, I do not need to worry about worksheet 401 as the next c> Matt - this is a long-known bug with HQ... What your describing is actually

Reply to
Otto

Otto, If I could beg a couple of clarifications:

  1. This appears to be a query to address a single transfer failure. Is there a way to stop the frequent failures ongoing?
  2. What is the significance of the style column. All of our hqmessage records have a 3 > YidMo - I have found that the line actually exists and that the
Reply to
Bob Johnson

Reply to
Mark

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.