MISSING INTERSTORE TRANSFERS: URGENT

Hi Paul, There could be one reason it is not working. First go to HQ Administrator : Automatically create inter-store receive inventory order (checked it) Automatically create inter-store issue inventory order (checked it optional on your requirement) If selected, Headquarters will automatically create an inventory transfer out order at the store that will need to send the requested shipment. For example, if Store A ran out of a certain item, they would create an inventory transfer in order from Store B. Headquarters would then automatically create an inventory transfer out order at Store B. This allows Store B to quickly identify and respond to the Store A request.

If helpful rate it please.

"Paul Beiruty" wrote:

Hi Akber, Thanks for your feedback but we have already done all this configuration before going live for this client, in fact we have set a very tight security schema where no user has the ability to change any configuration or add static item information at store level.

I believe this is a bug as our ongoing investigation has found this issue at a few HQ clients.

Cheers

-Paul Beiruty

Sometimes Transfer Out on store A and Transfer In on store B doesn't have the same transfer #.

But sometimes transfers do not get to destination. Maybe you should check how often your SO's connect to HQ.

I have the same problem, and didn't find a way to fix it. Please let me know if you find the cause(s) of this problem.

Thank you

JB

"Paul Beiruty" a écrit dans le message de news: snipped-for-privacy@microsoft.com...

I was just talking to our DBA who was tracking down a couple of missing transfers that originated in the store, came up to HQ, and never went down to the store.

He noticed that the placement date and the created date were exactly the same, meaning that the transfer had been "placed" initially and then the store modified the items in it after placement. Apparently this generates a problem on the HQ side and the second half of the issue will never be pushed to the store. I am not a DBA and I deal only with the admin side of things so I can't much elaborate on the issue but I thought this might be of some help. Our DBA is fairly certain that this is the cause of the "disappearing transfer" issue in our case.

Hope that can be of use,

Brandon

Hi Guys

I'm Russell Hatter, now Senior POS consultant for Connect Retail in Australia. I recently worked for POS Partners in Australia who manage the Microsoft Partner Program for Microsoft POS solutions. My role at POS Partners was primarily running the certification training course for Microsoft RMS resellers and supporting these resellers both technicially and pre-sales.

I can say that since the release of Microsoft RMS version 1.3 refresh we have seen a vast improvement in relation to transfers going missing. However I can state categorically that there is a problem and I could name over a dozen sites who experience this issue at least once a week. Microsoft believe that its related to invalid HQ id's or missing item Static data at one of the stores, and in some cases this is correct.

But in the case Paul refers to I can assure that all Item id's are intact and the database is configured correctly. Security is used to lock out the ability to create any static or centrally maintained data at store level but Transfers continue to go missing.

As for Berendon's suggestion it may very well be an issue with the date or time stamp within the database for the transfers. However in the case of a Transfer Out the Placement status will always remain greyed out so users are unable to change the placement status and date associated with the Transfer out. I will run some tests with the Date required and Order date fields however.

If other users / resellers are experiencing this issue please contribute as we may be able to put our heads togeather and come up with a resolution for this long standing issue.

Kind Regards,

Russell Hatter Senior POS Consultant Connect Retail Australia

I know for certain that you absolutely cannot change an inter-store transfer once it has been issued or placed and sent to HQ via WS401.

Once you issue/place a transfer order and the HQ client processes a WS401, any changes made to the order will not be sent to HQ (and therefore not sent to the inter-store target).

Are the missing transfers being generate at the store level or by HQ? Is there any consistency? Is it always a store-generated transfer in/out that fails to auto-generate the corresponding transfer out/in at the other store?

We do a lot of inter-store transfers and AFAIK we've never had one simply fail auto-generate at the other end. I did learn the hard way about the changes not being sent, though...

Tom

I think the "Order has been placed" selection is made by default, so often the requesting store will create an order (blank), then click OK. At this point, it is communicated to HQ, and ultimately the other store. Then, as has been said, if the requesting store makes changes to the order, these changes are not communicated to the sending store. Of course, this is asinine, but may answer your question. I have noticed that if the transfer request is blank, it will not even show up at the sending store, making it really hard to understand why it is "missing."

He noticed that the placement date and the created date were exactly the same, meaning that the transfer had been "placed" initially and then the store modified the items in it after placement. Apparently this generates a problem on the HQ side and the second half of the issue will never be pushed to the store. I am not a DBA and I deal only with the admin side of things so I can't much elaborate on the issue but I thought this might be of some help. Our DBA is fairly certain that this is the cause of the "disappearing transfer" issue in our case.

Hope that can be of use,

Brandon

If for some reason you find that the interstore transfer has gone from one store to HQ but not to the other store then you must check the following.

- In HQ the automatic transfer In and Transfer out options are checked (I am ssuming this is the case)

- All items on the transfer are valid items in HQ (I am assuming that no item was created in the store)

In that instance where you know which transfer has not completed you can try this query and send me your feed back,

Where AttachmentID in (select ID from Purchaseorder where PONumber = ' ')]

Note: please put the Required Inter-store transfer number between ' ' in the above query.

Hope this helps

Afshin Alikhani - [ snipped-for-privacy@retailrealm.co.uk ]

CEO - Retail Realm

The below script will guarantee you hit the specifically requested order from specific store ID.

Update hqmessage

Set status=2 From PurchaseOrder Where PurchaseOrder.ID = hqmessage.attachmentid

And purchaseOrder.StoreID=HQMessage.FromStoreID And purchaseOrder.OtherStoreID=HQMessage.ToStoreID And ponumber='xxx'

And HQMessage.Status=3 And PurchaseOrder.StoreID=x

Where: xxx = POnumber

And x = Source Store ID

Afshin Alikhani - [ snipped-for-privacy@retailrealm.co.uk ] CEO - Retail Realm = = = = = = = = = =

Hi Afshin

Thanks alot!! The script below works a treat to resend a Transfer which never made it to the other end. I still don't understand why this transfer didn't go in the first place..

What are your thoughts on this issue? Do your clients come accross this as a regular occurance?

I know we have spoken about this in the past and I am sorry to go over old ground but its really driving me nuts!

Thanks for your help and keep in touch.

Kind Regards,

Russell Hatter Senior POS C> The below script will guarantee you hit the specifically requested order

Hi Russ,

Frankly this is bug in my opinion. Microsoft in the communication should check and verify that a transfer is recieved at the other end and do some kind of a handshake [or provide the ability to re- synchromise PO and Transfers that come via HQ if they are not all there]. But since this problem has effected us many times especially in the Middle East with large customers we have written this patch to resend the missing transfers.

Hi Afshin

I appreciate your thoughts, perhaps we can work on something to push Microsoft to make the cahnges? With regards to your patch is this available for Connect Retail to purchase through POS Partners? Or is it perhaps bundled with your utilities module?

I was unaware that you had created a patch for this issue it will save us a huge headache!!

Kind Regards,

Russell Hatter

"Afsh> Hi Russ,

Hi Russell,

We have a lot of small SQL fixes that we give away for FREE. This cannot realy be fixed with a program patch it requires you to use the sql statement when you find that a transfer is missing. But I have sent this issue to Microsoft before. Lets hope that they fix it in version 3. Also look at a posting done on 28 Feb by me where I have attached a whole series of fixes for problems that resellers and customers have faced. Keep in touch.