Hi Vaibhav, Comments inline.
Regards Scott On 11 August 2017 at 02:55, Vaibhav Jain <[email protected]> wrote: > Thank you so much Scott for sharing these details, indeed they are really > helpful. > Kindly see my comments inline. > > > On Thu, Aug 10, 2017 at 3:22 PM, Scott Gray <[email protected]> > wrote: > > > Hi Vaibhav, > > > > It's a good question and mailing list archives (that are available) don't > > really answer the question clearly. At the moment as far as I can tell, > > the quantityUomId and unitsIncluded field do nothing, they're display > only. > > > > I think SupplierProduct.unitsIncluded is the same as > > Product.quantityIncluded, the field types are the same and the names > imply > > similar things. I actually think unitsIncluded is a better name than > > quantityIncluded which is confusing because the number doesn't relate to > > any quantity fields we normally use. > > > > IMO, quantityIncluded name can be better choice, because as my > undestanding > unitsIncluded is used to define units of product (like each, pack etc.) > but we may have products in various UOMs like (weight UOM, Liquid/Volume > UOM e.t.c.) > The confusing part is that quantityIncluded implies it has some relation to the OrderItem.quantity being ordered but that isn't the case. I see your point though. Perhaps a name like uomQuantityIncluded would make more sense. > > > > From the Product entity definition we have this explanation of the > fields: > > "If you have a six-pack of 12oz soda cans you would have > > quantityIncluded=12, quantityUomId=oz, piecesIncluded=6" > > > > piecesIncluded is missing from ProductSupplier but I think the definition > > for quantityIncluded/unitsIncluded can stand without it. > > > > As per my understanding the quantityIncluded defines the quantity included > in the respective quantityUomId and we do not need piecesIncluded here. > The need is really based on the real-world use case. piecesIncluded could have a place in a purchasing use case in the same way it does for a selling use case. > > >> "If you have a six-pack of 12oz soda cans you would have > quantityIncluded=6 quantityUomId=pack" > > As per my understanding, I think, "oz" is a weightUomId and this should be > managed at product level not at SupplierProduct. Please let me know your > thoughts on this. > The purpose of the Product.quantityUomId is to define how we choose to describe our product. Likewise the SupplierProduct.quantityUomId defines how the supplier describes their product. To extend my earlier use-case: If I am a house painter in NZ but I import my paint from the US, then chances are I would be ordering from a supplier who works in fluid ounces, US quarts or gallons. Despite that, I still want to be able to sell paint locally by the litre. > > So I think what we can conclude from this detail is that these fields are > > informative and not functional, and they shouldn't have any bearing > against > > other fields such as lastPrice. > > > > Agreed! > > > > I think there could be room for making use of the fields, an example: > > Let's say you are a house painter and you need to order 12 litres of > paint > > for a job. The supplier has two products available, 2 litre tins @ $10 > and > > 4 litre tins @ $15: > > <SupplierProduct quantityUomId="VLIQ_L" unitsIncluded="2" lastPrice="5" > > minimumOrderQuantity="1" orderQtyIncrements="1"/> > > <SupplierProduct quantityUomId="VLIQ_L" unitsIncluded="4" > lastPrice="3.75" > > minimumOrderQuantity="1" orderQtyIncrements="1"/> > > > > So you tell your amazing OFBiz system that you'd like to order 12 liters > of > > paint, OFBiz will then look at your SupplierProduct records and determine > > which record gives you the best price and fits within the supplier's > > purchasing rules (i.e. you can't order half a tin of paint). OFBiz > > ultimately puts the selection into OrderItem.supplierProductId and sets > the > > unitPrice accordingly. As a second function, OrderItem.supplierProductId > > can then also serve to correctly format the PO that the supplier receives > > so that instead of seeing: > > "Send me 12 litres of paint @ $3.75/litre please" > > they could instead see: > > "Send me 3 units of 4 litre paint @ $15/unit please" > > It wouldn't alter what we see in the OrderItem record, but it could be > used > > for information the supplier receives and perhaps also for shipment > receipt > > verification (if you wanted 4L tins and they sent you 2L tins, maybe > that's > > an issue that needs to be dealt with). > > > > It's a great use case, what I have concluded from this is, > We should use quantityUomId and quantityIncluded fields, > Just additional thought, if we use these fields then these fileds should be > the part of OrderItem entity as well. This will help in maintaining the > information at order item level. > I'm not sure, because the fields are informative and have no financial impact, I don't see that much benefit would be gained from storing the values on OrderItem. I could be wrong, but I'm not sure what it would accomplish. > > Please correct me on this, if I understand anything incorrectly. > > > > I hope that helps. I've made a few assumptions here so if anyone thinks > > > > Indeed very helpful, thanks so much :) > > I'm incorrect please speak up. > > > > Regards > > Scott > > > > > > > > > > > > On 9 August 2017 at 23:31, Vaibhav Jain <[email protected]> > > wrote: > > > > > Hello all, > > > > > > There are two fields, *quant**ityUomId* and *unitsIncluded* in > > > SupplierProduct entity. > > > Can someone please elaborate the use of these fields? > > > > > > After creating a record of SupplierProduct with *quantityUomId*="box" > and > > > *unitsIncluded*="10", created a purchase order but didn't notice any > > > change. > > > > > > How are these fields entertained in the purchase order? > > > > > > Thanks & Regards > > > Vaibhav Jain > > > Hotwax Systems, > > > [email protected] > > > > > >
