A client of ours deals in stone for flooring etc. The stone can be in a variety of sizes and can be cut to become different sized pieces. They dont want to have different items for different sizes of the same stone. The idea of using variants has popped up. This would involve associating a unit of measure per variant. I think this could have pretty wide-reaching implications. Before I start looking at this seriously, has anyone out there been down that road already ?
TIA
Bob
Maybe I’m missing something - why the Unit of Measure? I’d say that what the variant would represent is the size, that is a different value in the same unit of measure
Maybe I’m missing something - why the Unit of Measure? I’d say that what the variant would represent is the size, that is a different value in the same unit of measure
If you’re using variant, why do you need to separate them using the unit of measure again? Variant is, by definition, a variation of the item. i.e., different color, different size, etc.
Instead of variant, why not just differentate the items by using different units of measures setup on the Item Unit of Measure?
Hi,
Don’t think std variant is an option in this case based on the explaination. The stones comes in different sizes from adhoc cutting and the customer does not want to create multiple item codes as well. Costing would also be an issue later on as variants assumes the same costing is used.
I agree Variants with different UoM would be good esp together with Mfg production BOM. However, customisation is required.
If you use variants, then the SKU card would be used for costing and purchasing, so its no problem to have the costs independedent.
maybe you could explain better your costing scenario so we can help you with that. PS did you look at the other thread mentioned above? Is your scenario anything like those examples.
Hi!
I agree, had Navision supported Variant based BOM instead of just item based BOM…life would have been much simpler…with little or no customization.
Coz these customization have far reaching implication on the Planning Engine.(MPS& MRP)
Thanks to everyone who contributed to this discussion. It has all been helpful 
I dont think costing will be an issue. We will not need to hold costs per variant. The variants are simply a way to be able to record the in-stock quantity per size of stone (piece) and to be able to translate between pieces (variant quantity) and area (the base unit of measure) while avoiding the need to hold different items per size of stone.
I am hoping that I can do something simple like associate a UOM with each variant which will convert from pieces to the base UOM (e.g. square feet). Then when processing orders, journals ,etc the operator will be allowed to enter the quantity as the number of pieces (the variant UOM). This will be converted to the ‘Quantity’ field in the base UOM for the item.
The user intends to use lot numbers (correspondng to pallets in the real world). When we come to sell we may be issuing several variants to supply a single order line. I havent worked out the best approach to this yet.
Bob
Thanks to everyone who contributed to this discussion. It has all been helpful
I dont think costing will be an issue. We will not need to hold costs per variant. The variants are simply a way to be able to record the in-stock quantity per size of stone (piece) and to be able to translate between pieces (variant quantity) and area (the base unit of measure) while avoiding the need to hold different items per size of stone.
I am hoping that I can do something simple like associate a UOM with each variant which will convert from pieces to the base UOM (e.g. square feet). Then when processing orders, journals ,etc the operator will be allowed to enter the quantity as the number of pieces (the variant UOM). This will be converted to the ‘Quantity’ field in the base UOM for the item.
The user intends to use lot numbers (correspondng to pallets in the real world). When we come to sell we may be issuing several variants to supply a single order line. I havent worked out the best approach to this yet.
Bob