Hello Scott, Thank you very much for your continuous efforts on this discussion.Please check comments inline
On Mon, Aug 14, 2017 at 11:50 AM, Scott Gray <[email protected]> wrote: > 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. > Yes, fully agreed for the name *uomQuantityIncluded*. > > >> >> >> > 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. > Okay got it, As I understand we need to introduce new field *piecesIncluded* in SupplierProduct entity. This will be just an informative field for supplier product. At the time of receive product value of SupplierProduct.*piecesIncluded* will be copied to Product.*piecesIncluded* which help in maintaining detailed information of product. Please correct me on this, if I understand anything wrong. > > >> >> >> "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. > Agreed! > > 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. > Nice use case let me explain. As system is belongs to painter. So we need to define defaultProductUom(On which product UOM is managed in the system). In this case *defaultProductUom*="Litre". Paint is sell by a supplier and supplier is belongs to USA i.e. supplier product UOM might be Ounce/Gallon/Quarts. Now in supplier product entity *quantityUomId*="Ounce/Gallon/Quarts" *uomQunatityIncluded*="litres in Ounce/Gallon/Quarts". And inventory recieved will be *quantity***uomQuantityincluded*. > > >> > 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. > In SupplierProduct entity we can expire any supplier product record and can create new one. In that case we need to record *uomQuantityIncluded* and *quantityUomId* on order level same as *unitPrice* in OrderItem. Ex:- <SupplierProduct productId="GZ-5005" supplierProductId="GZ-5005-0" quantityUomId="case" unitsIncluded="10" availableFromDate="2005-01-01 00:00:00.000" availableThruDate="2006-01-01 00:00:00.000"/> <SupplierProduct productId="GZ-5005" supplierProductId="GZ-5005-0" quantityUomId="case" unitsIncluded="20" availableFromDate="2006-01-01 00:00:00.000"/> > > >> >> 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] >> > > >> > >> > >
