Quantity UOM in Supplier Product

[Vaibhav Jain]

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,
[hidden email]

[Scott Gray-3]

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.

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.

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.

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).

I hope that helps.  I've made a few assumptions here so if anyone thinks
I'm incorrect please speak up.

Regards
Scott





On 9 August 2017 at 23:31, Vaibhav Jain <[hidden email]>
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,
> [hidden email]
>

[Vaibhav Jain]

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 <[hidden email]>
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.)


> 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.

>> "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.


> 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.

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 <[hidden email]>
> 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,
> > [hidden email]
> >
>

[Scott Gray-3]

Hi Vaibhav,

Comments inline.

Regards
Scott

On 11 August 2017 at 02:55, Vaibhav Jain <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]>
> > 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,
> > > [hidden email]
> > >
> >
>

[Jacques Le Roux]

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 <[hidden email]>
> 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 <[hidden email]>
>> 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 <[hidden email]>
>>> 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,
>>>> [hidden email]
>>>>

[Vaibhav Jain]

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 <[hidden email]>
wrote:

> Hi Vaibhav,
>
> Comments inline.
>
> Regards
> Scott
>
> On 11 August 2017 at 02:55, Vaibhav Jain <[hidden email]>
> 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 <[hidden email]
>> >
>> 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 <[hidden email]
>> >
>> > 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,
>> > > [hidden email]
>> > >
>> >
>>
>
>

[pierre-29]

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
>> <[hidden email]>
>> 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
>>> <[hidden email]>
>>> 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
>>>> <[hidden email]>
>>>> 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,
>>>>> [hidden email]
>>>>>
>
>

--
logoNrd <http://nereide.fr/>
        Pierre GAUDIN
Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre
[hidden email]
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: [phone]

ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE
<http://www.libre-entreprise.org/>

[Vaibhav Jain]

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,
[hidden email]

On Tue, Aug 15, 2017 at 11:22 AM, pierre <[hidden email]> 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 <[hidden email]
>>> >
>>> 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 <
>>>> [hidden email]>
>>>> 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 <[hidden email]
>>>>> 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,
>>>>>> [hidden email]
>>>>>>
>>>>>>
>>
>>
>
> --
> logoNrd <http://nereide.fr/>
>         Pierre GAUDIN
> Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre
> [hidden email]
> 8 rue des Déportés 37000 TOURS
> Std: 02 47 50 30 54 - mob: [phone]
>
> ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE
> <http://www.libre-entreprise.org/>
>
>