Re: Quantity UOM in Supplier Product

[Vaibhav Jain]

Hello Pierre,

A JIRA  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  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 >> >
>>> 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:
>  minimumOrderQuantity="1" orderQtyIncrements="1"/>
> 
 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 

Re: Quantity UOM in Supplier Product

[pierre]

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 


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 


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:
lastPrice="5"

minimumOrderQuantity="1" orderQtyIncrements="1"/>

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 

Re: Quantity UOM in Supplier Product

[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 
wrote:

> Hi Vaibhav,
>
> Comments inline.
>
> Regards
> Scott
>
> On 11 August 2017 at 02:55, Vaibhav Jain 
> 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 > >
>> 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:
>> > > > minimumOrderQuantity="1" orderQtyIncrements="1"/>
>> > > 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
>> 

Re: Quantity UOM in Supplier Product

[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 
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 
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:


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 

Re: Quantity UOM in Supplier Product

[Scott Gray]

Hi Vaibhav,

Comments inline.

Regards
Scott

On 11 August 2017 at 02:55, Vaibhav Jain 
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 
> 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:
> >  > minimumOrderQuantity="1" orderQtyIncrements="1"/>
> >  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.


>
> 

Re: Quantity UOM in Supplier Product

[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 
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:
>  minimumOrderQuantity="1" orderQtyIncrements="1"/>
>  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 
> 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
> >
>

Re: Quantity UOM in Supplier Product

[Scott Gray]

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:



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

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,
vaibhav.j...@hotwaxsystems.com