One of the constant battles we have during installation is the discussion about Units of Measure (UOM). First, let me explain how and why each system uses UOMs and why it is such a difficult issue.

Solomon UOM Issues
Solomon (SL) is used by many organizations to manage sales of products. Organizations purchase products, bring them into inventory, sometimes reprocess them, and then sell them to customers. They buy them in cases that contain a number of boxes. For my example, let's say 10 boxes. They turn around and sell the product one box at a time. So what SL can do is convert the inventory quantity from 1 case to 10 boxes. This conversion helps at inventory time. If you want to value your inventory in boxes, SL will convert your 10 cases and 3 boxes to 33 boxes. This makes for quick work of inventory valuation. SL maintains a Unit of Measure Conversion table called the INUNIT table. It has a "From Unit" and a "To Unit" with a quantity for each value. So in this instance, 1 Case is equal to 10 Boxes. This seems like quite a logical and simple issue right? Well, not really - even though it seems so easy at the beginning of the process. Let me throw this real world scenario at you... Let’s say that we have this one conversion:
 

Now a month goes by and we bring in a new product and we buy item # 2 in Cases also. However, in this case there are 12 Boxes. So now we go and add this new additional UOM conversion. 

Ok that sounds good. Let’s go and purchase a few more SKU's in Pallets and CASE144's, etc. Now everything converts in the inventory nicely to Boxes, which is good you may say. Until you get an order through your system for Product #2 in CASE144. And you say what happened? Solomon is broken. No, it is not because it is doing its conversion incorrectly. It is because what can be converted when it comes into the inventory can also be sold for any valid convertible UOM. The pivot point becomes the Solomon Stock UOM. Any unit that can be converted to the STOCK UOM is a valid UOM on a sales order. So now any UOM you created is available for selling the product in that quantity. Now you have a big mess on your hands. Try cleaning this up for a few thousand parts with different UOMs that all mean the basic same thing.  The rule to follow is that any unit convertable to the Stock UOM is a valid sales unit of measure.  
 

CRM UOM Issues

CRM is not much better. Basically, it is a pointless exercise. As a required element, you have to maintain it, but it does nothing; currently CRM does not do any UOM conversions. CRM has a Unit Group that needs to be propagated. Inside this unit group you have to put all the UOMs and the correct conversions. But because CRM does nothing with Purchasing or Inventory, the UOM conversion is never used. One more point here: You can't just add products to CRM and start selling them. You need to create "Price List Items" for each product that expresses the correct UOM and price list for each item. So if you have 100 UOMs, you will need to add 100 price list items with every product.

Hopefully, you are now seeing why this is such a complex issue with SL and CRM integration. What you often end up with is a UOM conversion plan in Solomon that allows selling in 20 different UOMs and let’s say you have 5000 parts. You will end up with managing 100,000 price list items in CRM. We have developed the DTS that builds this out in CRM. It is pretty efficient - we can push through a few hundred of these items in a few minutes. Now imagine adding to the UOMs 3 price lists and you go from 100,000 to 300,000 price list items. I wonder about CRM's ability to handle a pricing schema that calculates prices on rules not based on specific data points like price list items.

Our recommendation is:

• Use "Each" as a basic UOM conversion. Instead of Buying 1 Case UOM, buy it in 12 Eaches. Stay away from broad general names. Use specific conversions like Dozen and Gross. Then you can buy 1 DOZEN and stock 12 EA.
• In CRM, build one UOM schedule and put all the UOMs in there and convert each of the UOM's to the Primary unit.

There are still a few more issues that we address when it comes to building the price list items and getting the correct Price into CRM. But that is for another post.