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 understand your frustration however lets put it in perspective:

2- In the case of Jim Bean you are correct - you are creating an item for purchasing that you do not normally sell [unless a hotel or some large buyer calls you] however not a real problem in the scheme of things. If you want a smoother Purchasing system that has its own unit of purchase we have add-ons that can do this for you (US$495) let me know and I will send you a version to test.

Frankly for the price, flexibility, and amount of money that Microsoft is spending on this product (over 10Million per year) you will not get a better solution. Further, Microsoft version 2 scheduled for 1st Qtr 2006 and version 3 scheduled for 1Q 2008 both promis major improvements in the application. Stick with it and you will be happily surprised.

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

CEO - Retail Realm

Jeff, thank you for addressing my post

My ultimate issue is that Microsoft markets the RMS as if it is a custom soluton for beer/wine/liquor store which can not be further from truth.

As for Jim Beam, I sell them by case and botte. When I sell by case, per bottle cost of Jim Beam 1.75L is $19.99. When I sell by bottle, per bottle cost of Jim Beam 1.75L is $21.99. There IS NO WAY to avoid having a record for the case and record for the bottle.

I will give you another twist. What if a customer buys a case plus 5 bottles? (Total of 11 bottles since there are six bottles in a case). I sill want to give my customer $19.99 bottle price even on the 5 bottles since they bought more than a case quantity in total. I am sure we can do this in Microsoft RMS but it would be complicated to do so.

Oh, it's routine that wine stores give customer 10% discount or per bottle of case if they buy more than 6 or 12 750ML bottles. Do you think default RMS can handle this? The answer is NO!!! You have to get an outside program to do this. Read this post.

Properly designed master table should include following fields: Barcode Description Type Size Unit Qty in Case Unit Cost (Trigger in the table should compute this figure if Unit Qty and Case cost are filled in) Case Cost (Trigger in the table should compute this figure if Unit Qty and Unit cost are filled in) Unit Retail Price Case Retail Price Per Unit Retail Price of case (Trigger in the table should compute this automatically) Pack type 1 Retail Price Pack type 2 Retail Price Pack type 3 Retail Price And all other items that RMS already has on its master table.

Jeff, just curious why you do not sell liquor stores? It is my largest base of customers.

Regards,

Kinnard

Kinnard L. Kohler Business Machines Systems

"H>

Thank you for your input Afshin.

I simply want Micrsoft to admit that their design is not for beer/wine/liquor store.

Yes, the community support of RMS is fantastic. Thanks to people like you. I heard about the fix for parent/child. But what about retail price? I still have to edit child item retail price. I know you understand my problems. I simply want to edit case/pack price on the same record. Not on two different records suggested by RMS. Software is supposed to boost your productivity.

I have a lot of case sales. It's a real problem in the scheme of things.

I have moved > I understand your frustration however lets put it in perspective: > > >

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

Hong, I also own Liquor store and I have no problem. Exemple for Jim beam enter your inventory as case and scan out side the case barcode and Put case price

The Box can be $10 price and if you have 10 items in the Box you are assuming the item price will be $1. This can be a rule for COST but NOT for Price. Most stores that sell Box and Item want the item to be a higher price so that the customer is drawn to buying the box rather than the unit.

Having said that if you wish we can expand our Parent Child Cost fix to include a price logic so that when you change the parent Price the child cost is also automatically updated. However, this would be a special development.

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

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