Inter-Store Transfer Lost

Dec 18, 2008 10 Replies

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.
>

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

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

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,

PurchaseOrderEntry tables,

transfers gets into

I have found a few solutions that have helped since I first tackled this problem.

  1. run a report every day to find these problems before the stores do. select po1.StoreID,po1.POTitle,sum(e.quantityordered) as Qty, sum(e.quantityordered*e.price) as Total, Department.Name,po1.DateCreated,po1.LastUpdated,po1.PONumber,po1.[shipTo] from purchaseorder as po1 WITH(NOLOCK) left join purchaseorder as po2 WITH(NOLOCK) on po2.otherpoid = po1.id and po2.otherstoreid = po1.storeid Inner JOIN PurchaseOrderEntry e WITH(NOLOCK) ON po1.ID=e.PurchaseOrderID AND po1.StoreID = e.StoreID LEFT JOIN Item WITH(NOLOCK) on e.ItemID=Item.ID LEFT JOIN Department with(NOLOCK) on Item.DepartmentIDÞpartment.ID where po2.id Is Null and po1.otherstoreid > 0 and po1.status=2 and po1.otherpoid = 0 group by po1.StoreID,po1.POTitle,Department.Name,po1.DateCreated,po1.LastUpdated,po1.PONumber,po1.[shipTo] Order by po1.LastUpdated

  1. transfers that were missed within the last day can often be fixed by backdating a 401 worksheet 1 day to the receiving store

be careful of the next steps because they can cause double transfers to the recieving stores if the problem is just that the recieving store isn't connecting to hq

  1. next step if that doesn't work is to try refreshing the hq entry to forward the transfer. Use the ponumber and storeid from the store that created the transfer update h set h.status=2 from purchaseorder p join hqmessage h on fromstoreid=storeid and attachmentid=p.id where style=2 and h.status=3 and ponumber ='0333505' and storeidr

  1. if there isn't an entry in hqmessage for that transfer, you may need to create it: insert into hqmessage (status, style, fromstoreid, tostoreid, attachmentid, datesent) select 2,2,storeid,otherstoreid,id,datecreated from purchaseorder where ponumber ='0333505' and storeidr

  2. rarely I have found some stubborn transfers that just w> Is there any way of creating a query for transfers that were never received

PurchaseOrderEntry tables,

transfers gets into

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required