Beer/Wine/Liquor retailers Beware-Microsoft RMS won't meet your ne

soft.public.pos

I admit that Microsoft RMS is versatile and it could work for many other industries. But it is not friendly to liquor store operation. Your website advertises, ?Microsoft Retail Management System is customized to help you.? Can you point me where in your system was customized specifically for a liquor store? There is not even a default database field to store size of bottle!!! Size of bottle is criticial bit of information for my line of work. Your web page I mentioned above was MISLEADING and FALSE.

I am sure you would argue that there are Microsoft partners who implemented Microsoft RMS at hundreds of liquor stores. However, can you tell me for sure that these customers tried out different liquor POS software before they used Microsoft RMS? I certainly wish I demoed your product before the purchase because I would not have bought it. I was led to believe your product was designed to work in liquor stores but I was shocked how difficult it is to use in my store. I would like to return your product and receive a full refund. I feel defrauded by your advertisement.

-- Hong

soft.public.pos

I admit that Microsoft RMS is versatile and it could work for many other industries. But it is not friendly to liquor store operation. Your website advertises, ?Microsoft Retail Management System is customized to help you.? Can you point me where in your system was customized specifically for a liquor store? There is not even a default database field to store size of bottle!!! Size of bottle is criticial bit of information for my line of work. Your web page I mentioned above was MISLEADING and FALSE.

I am sure you would argue that there are Microsoft partners who implemented Microsoft RMS at hundreds of liquor stores. However, can you tell me for sure that these customers tried out different liquor POS software before they used Microsoft RMS? I certainly wish I demoed your product before the purchase because I would not have bought it. I was led to believe your product was designed to work in liquor stores but I was shocked how difficult it is to use in my store. I would like to return your product and receive a full refund. I feel defrauded by your advertisement.

-- Hong

I agree with you, I also own a store where the parent/child is wrong. The basic concept of RMS is backwards when dealing with P/C items. It is really a very simple task. When you receive a parent item you break it down to the smallest selling unit "child". You also update the cost of the "child". RMS does NOT show the correct cost on any child item, This is not a bug in the program, but an ERROR in programming. Any report using this garbage cost, is in fact garbage. The RMS programmers MUST fix this in problem in order to say their program is

I agree 100%. Without the cost update, the COGS numbers (and therefore Profit) that come out of RMS are GARBAGE.

The only solution I have found is to have a custom Excel sheet with some complex functions to find parent/child cost discrepancies. I either use a ton of SQL statements or manually change the cost of all of the child items after every PO receiving.

This is NOT acceptable.

There's gotta be some fancy SQL that can fix child costs in one shot... That would be the best solution.

I'm not sure how this would work in a HQ setting... That adds more wrinkles if you have different costs in each location (I think)...

Hong,

We are currently using this in a liquor store in Montana. This is the solution that we use, may or may not work for you.

We basically keep everything in the system as a bottle count. We don't know what a 'case' is, if you follow. But we do know about a quantity discount, aka a case. So if one of our bars purchases a case, which is 12 bottles, he gets the case price, or 12 bottles.

Hong,

We had the same problem, and Parent/Child was useless for us.

Our dealer gave us a workaround by changing the receive template. But first, on each line item that came in a pack of > 1, we changed the MPQ value (supplier tab) to accurately reflect how many come in a case. We use the individual item cost as the cost for that item, not the case cost.

Now, in the case of an MPQ of 10, if our order came to 10 individual line items, here's basically what happens:

The receive .xml template was modified to: If MPQ > 0, then divide the total ordered by the MPQ. So for an order that generated 10, the PO template ( the printout ) shows an outbound purchase order of one. It also shows the proper single cost of each item, and the proper case cost as the extended.

So, the upshot is, the outbound PO looks like it should, and the math works. On the inbound PO, the program appears to stick to the total individual number of items actually ordered, and receives the proper number to populate the QOH accurately.

It's not without consequence though. You can't use all of the ordering options available when generating POs - but so far it's been the only way to properly implement the classic retail master pack.

After back> I purchased Micrsoft RMS to upgrade my old POS system. This has been a > disaster. >