1. Home
  2. Point-Of-Sale Software
  3. Inter-Store Transfer Lost

Inter-Store Transfer Lost

I am having a problem with Inter-store transfers. They are committed at store and are at HQ but not at Receiving store. Some work some dont. It is random. I found this post from over a year ago that addresses my issue. I hope some one can read and help me make sense of it. Thanks for Any Help.. YidMo 10/9/2007 2:04 PM PST 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:

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
Mark
Loading thread data ...

We have had an ongoing issue with this problem and determined that it happens when there is a polling error on the sending location. (401) The transfer gets closed at HQ and will not sent to recieving location. I usually run a SQL 51 worksheet telling the sending store to reopen and send the transfer again then it will pass to the recieving store. The polling error is usually a deadlock between two polling locations. We poll about 300 locations every night through 4 comm servers.

Paul / Eastern Nati> I am having a problem with Inter-store transfers. They are committed at

Reply to
Paul Houston /

Reply to
Mark
1.Update PurchaseOrder set isplaced = 1 where status = 2 and potype = 3 2.Update HQMessage Set Status = 1 where FromStoreID = 5172 and AttachmentID = 4121

"Paul Houst> We have had an ongoing issue with this problem and determined that it

Reply to
Paul Houston /

Sorry about that

1.Update PurchaseOrder set isplaced = 1 where status = 2 and potype = 3 2.Update HQMessage Set Status = 1 where FromStoreID = 5172 and AttachmentID = 4121

You will need to f> Hey Paul,

Reply to
Paul Houston /

Reply to
Paul Houston /

Reply to
Mark

Reply to
Paul Houston /

Reply to
Mark

PurchaseOrderEntry tables,

transfers gets into

Reply to
Paul Houston /

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.