Hello Pierre, A JIRA <https://issues.apache.org/jira/browse/OFBIZ-9580> is created for further tracking the improvements.
Thanks & Regards Vaibhav Jain Hotwax Systems, vaibhav.j...@hotwaxsystems.com On Tue, Aug 15, 2017 at 11:22 AM, pierre <pierre.gau...@nereide.biz> wrote: > Hi all, > We made something very similar. > > We use this information of purchasing orders until the reception. > > I am going to supply a patch and more details of what we made in the > course of September (at present I am on holidays) > > Is there Jira to propose a patch? > > Many thanks > > Pierre > > On 14/08/2017 10:43, Jacques Le Roux wrote: > >> Thanks Scott, >> >> Inline too >> >> >> Le 14/08/2017 à 08:20, Scott Gray a écrit : >> >>> Hi Vaibhav, >>> >>> Comments inline. >>> >>> Regards >>> Scott >>> >>> On 11 August 2017 at 02:55, Vaibhav Jain <vaibhav.j...@hotwaxsystems.com >>> > >>> 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 < >>>> scott.g...@hotwaxsystems.com> >>>> 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. >>> >> +1 for uomQuantityIncluded, too late to change? >> >> >>> >>>> 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. >>> >> +1 for putting in piecesIncludedin case of purchase also. >> >> >>> >>> "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. >>> >> +0, I'm undecided on this. Maybe if they are not used for sales then they >> should also not be for purchase, or then they should be in both cases. >> >> Jacques >> >> >>> 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 <vaibhav.j...@hotwaxsystems.co >>>>> m> >>>>> 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, >>>>>> vaibhav.j...@hotwaxsystems.com >>>>>> >>>>>> >> >> > > -- > logoNrd <http://nereide.fr/> > Pierre GAUDIN > Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre > informat...@nereide.fr > 8 rue des Déportés 37000 TOURS > Std: 02 47 50 30 54 - mob: 06 08 40 25 70 > > ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE > <http://www.libre-entreprise.org/> > >
