Add uom to ProductAssoc for BOMs? about mantle-udm HOT 8 CLOSED

The idea behind the Product model is that a given Product record represents not just a type of product but also one unit of the product represents a certain amount of it (amountFixed and amountUomId fields). This is why there is no UOM on the Asset (inventory, etc) entity or the ProductAssoc entity. The quantity on a ProductAssoc record is in terms of the units defined on the associated Product.

In a UI you could allow a user to enter a quantity and UOM, then convert it to a quantity in terms of the Product unit (ie amountFixed quantity in amountUomId UOM). For example if a Product had amountFixed of 5 and amountUomId of pounds (WT_lb IIRC) and a user entered a quantity of 1 cup then it would have to do the math to calculate what 1 cup means related to the Product unit which is 5lb.

If there was a UOM ID on ProductAssoc it would just mean that EVERYWHERE the quantity is used this conversion the Product's unit definition would have to be done. That would be a royal pain, along with being confusing when looking at inventory quantities, issuance quantities, etc.

In short, no, there should not be a UOM on ProductAssoc, or on Asset, AssetDetail, AssetIssuance, AssetReceipt, etc, etc. A Product represent a certain unit of something and if it wasn't that way the data model and services (and UI) would be far more complex and error prone.

from mantle-udm.

Thanks for the feedback David.

I'll go the conversion route as you suggested based on Product entity amountFixed and amountUomId. But without uomId in the ProductAssoc, how would the ingredients list of the recipe be generated with the original uom (cups of flour instead of lbs). Does it make sense to have uomId there just for reference of the original uom used to get the calculated quantity (cups to lbs)?

Also conversion from cups to lbs seems to be a bit messy since one measures volume and the other measures weight and it seems likely that the exact ingredient quantity may be off a little sometimes during conversion calculation (possibly 3/4 or 1 1/2 cups instead of exactly 1 cup).

from mantle-udm.

David,

I ran into some issues while working on ProductAssoc quantity conversions based on Product.amountUomId.

The goal is to generate a recipe ingredients list based on the ProductAssoc entity.

Using the Product.amountUomId seems insufficient because:

1. Conversion from lbs to cups only seems possible to support exact measurement if separate uoms and conversions are created for each product (1cup of flour will weigh different than a cup of oil so 1cupflour uom and 1cupoil uom would have to be created with separate conversions for each).
2. Unless a separate product is created with the uom that needs to appear on the ingredients list (another flour product but with amountUomId of cups instead of lbs), there is no way to derive the original uom for the ingredients list.

Also, the ingredients (bom) list needs to be copied as consumables by ProductionRuns (pending merge of mantle-usl #ad159d9) created to make recipes and the ingredient measurements need to be exact.

After some work on this, adding uomId to ProductAssoc seems to be the best solution. Adding uomId to the other entities you mentioned (Asset, AssetDetail, AssetIssuance, etc.) seems unnecessary because even if the conversion isn't exact, Asset inventory quantity can be adjusted when its off, so those entities could just be assigned the converted value. The only other entity that would need to support uomId is WorkEffortProduct so that ProductionRun consumables can be listed as ingredients with exact measurements.

from mantle-udm.

Are you trying to do a manufacturing bill of materials or some sort of public facing recipe? For manufacturing BOM you'd want the consistency and control of the current model, and the organization would have to choose how they want to model their raw materials. Yes, converting between weight and volume units has issues as it depends on the specific material and for manufacturing purposes this would need to be much more specific than flour vs oil as different flours and different oils would have different density (and so different weight to volume ratios).

IMO if this is targeting toward manufacturing it would be a bad idea to allow this sort of thing. Use consistent units or risk production being off from recipes, or in other words convert units before recording them in the system if the inventory is in a different unit.

from mantle-udm.

The use case I've been describing is for smaller scale manufacturing such as a small bakery where volume measurements might be used more often than weight.

Other than requiring the company to convert their recipes from volume to weight, the only other option not requiring adding the uomId to the Assoc entities would be to create virtual products representing the volume units just to describe the recipe. However, this would face the same conversion issues between volume and weight you mentioned above and the I don't believe functionality exists to derive variants from virtual products yet and convert between them if they contain different uoms. Is that functionality reasonable to implemented if not already?

The volume measurement recipe could be stored separately from the ProductAssoc entity (weight uom) such as in the manufactured product description field but it would cause redundancy when recipes needed to be adjusted because both the description field and the ProductAssoc would have to be changed. Also, if the recipe were needed to be doubled then the doubled volume uom wouldn't be calculated if stored in the description field.

from mantle-udm.

That's not the only other option, if they want to have recipes (bill of materials) in a volume UOM then they should also inventory with a volume UOM. To avoid constant issues a base UOM should be used across the board for each product, either by volume or weight but not a mix like weight UOM for inventory and volume UOM for a bill of materials. I don't see how you could do that without having constant issues, and I don't see how a uomId on ProductAssoc solves this problem... seems it would just make the whole setup more complex and error prone.

If they require receiving inventory by weight but want to track it in a volume UOM then that conversion should be done in the UI on receipt. There are fields on Asset to help with this sort of thing as it is a common requirement (ie Asset.originalQuantity and Asset.originalQuantityUomId).

In general to avoid constant UOM issues in both code and for users (making the system difficult to understand and use) a Product represents a specific quantity (in a specific UOM) of a specific physical item. All product quantities (on Asset, OrderItem, ProductAssoc, etc, etc) are in terms of the 'unit' defined on the Product. If you do anything to break that definition every place you have a productId and a quantity of that product you would have to change both the data model and every service that deals with those fields, and that cascades from there to all sorts of complex UI requirements, UOM conversions all over the places, and a generally more error prone system. I've had these conversations before with all sorts of half-baked ideas involved, not seeing the data flow end-to-end, and I have yet to find a better solution than to treat a Product as representing a specific 'unit' of something.

from mantle-udm.

Thanks for hashing out the issue with me David. I'll go with the consistent uom base you suggested.

As for the virtual/variant functionality I mentioned in my previous message and based on your consistent uoms suggestion, should restricting variants to virtual products with the same uom base be implemented in code or would that be better handled by educating the end user?

from mantle-udm.

I don't know if it would be best to enforce this somehow, but should be handled by variants automatically generated from a virtual product based on selectable features. In general I think that's true, variants should all have the same amountUomId but the amountFixed may vary. Also in general these product setups are somewhat complex and user training is needed to get things right (even basic virtual/variant structures with the features associated with each and all often needs some training and user support when it doesn't work).

from mantle-udm.