New field to specify the internal uom of products

[Jacopo Cappellato]

Right now there is no full support for different uoms in purchase/sales
orders and inventory (there are some - not complete - contributions in
Jira that we'll have to review).
Sooner or later I'll have to implement this.

In the meantime, what about adding a new field ("internalUomId") to the
Product entity to specify the uom in which the units are stocked
(InventoryItem) and to which the unit price refers (ProductPrices)?

And what about adding a new unit of measure:
<Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE" abbreviation="unit"
description="Unit"/>
?

This would be useful to specify that a product is sold/purchased/stocked
in units: this would be the default value in the EditProduct form.

Is it ok?

Jacopo

[David E Jones-2]

How would this be different from the existing fields:

       <field name="quantityUomId" type="id"></field>
       <field name="quantityIncluded" type="floating-point"></field>
       <field name="piecesIncluded" type="numeric"></field>

I think what you're proposing for internalUomId sounds like the  
quantityIncluded field and the quantityUomId that goes with it.

I've tried to avoid the idea of a "Unit" or "Each" UOM because it's a  
muddy concept. Of course, it might be needed for some things so if  
something comes up I won't be opposed to it.

For the Product entity this is the intent of the "piecesIncluded"  
field which would basically specify the number of "units" and be  
independent of the quantity and its UOM.

The nice thing is these can then be used together. For example to  
describe a 6 pack of 1.5 liter water bottles you'd have:

quantityUomId: whatever "liter" is
quantityIncluded: 1.5
piecesIncluded: 6

-David


On Sep 5, 2006, at 3:07 AM, Jacopo Cappellato wrote:

> Right now there is no full support for different uoms in purchase/
> sales orders and inventory (there are some - not complete -  
> contributions in Jira that we'll have to review).
> Sooner or later I'll have to implement this.
>
> In the meantime, what about adding a new field ("internalUomId") to  
> the Product entity to specify the uom in which the units are  
> stocked (InventoryItem) and to which the unit price refers  
> (ProductPrices)?
>
> And what about adding a new unit of measure:
> <Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE" abbreviation="unit"  
> description="Unit"/>
> ?
>
> This would be useful to specify that a product is sold/purchased/
> stocked in units: this would be the default value in the  
> EditProduct form.
>
> Is it ok?
>
> Jacopo

[cjhowe]

We have vendors that use multiple breakdowns to (in
most cases) eliminate confusion on packaging.

Might we consider this as a related entity?

Following the beverages example

a case of 20 ounce bottles come in 4 packs of 6

So, for clarity
480 ounces per case
24 each per case
4 packs per case

This is how the one of the superlarge suppliers in my
field handles case pack for clarity.  Certainly
redundant, but very necessary when they're managing
225,000 skus (so they claim).  They're the only
supplier that you understand what you're getting.




--- David E Jones <[hidden email]>
wrote:

>
> How would this be different from the existing
> fields:
>
>        <field name="quantityUomId"
> type="id"></field>
>        <field name="quantityIncluded"
> type="floating-point"></field>
>        <field name="piecesIncluded"
> type="numeric"></field>
>
> I think what you're proposing for internalUomId
> sounds like the  
> quantityIncluded field and the quantityUomId that
> goes with it.
>
> I've tried to avoid the idea of a "Unit" or "Each"
> UOM because it's a  
> muddy concept. Of course, it might be needed for
> some things so if  
> something comes up I won't be opposed to it.
>
> For the Product entity this is the intent of the
> "piecesIncluded"  
> field which would basically specify the number of
> "units" and be  
> independent of the quantity and its UOM.
>
> The nice thing is these can then be used together.
> For example to  
> describe a 6 pack of 1.5 liter water bottles you'd
> have:
>
> quantityUomId: whatever "liter" is
> quantityIncluded: 1.5
> piecesIncluded: 6
>
> -David
>
>
> On Sep 5, 2006, at 3:07 AM, Jacopo Cappellato wrote:
>
> > Right now there is no full support for different
> uoms in purchase/
> > sales orders and inventory (there are some - not
> complete -  
> > contributions in Jira that we'll have to review).
> > Sooner or later I'll have to implement this.
> >
> > In the meantime, what about adding a new field
> ("internalUomId") to  
> > the Product entity to specify the uom in which the
> units are  
> > stocked (InventoryItem) and to which the unit
> price refers  
> > (ProductPrices)?
> >
> > And what about adding a new unit of measure:
> > <Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE"
> abbreviation="unit"  
> > description="Unit"/>
> > ?
> >
> > This would be useful to specify that a product is
> sold/purchased/
> > stocked in units: this would be the default value
> in the  
> > EditProduct form.
> >
> > Is it ok?
> >
> > Jacopo
>
>

[Jacopo Cappellato]

David,

that's great, thanks.
So, if I have a product that I sell in meters (its prices are also
expressed for one meter of the product) and the stock levels are also in
meters, what I have to do is this:

quantityUomId: "meter"
quantityIncluded: 1

Is it correct?

Thanks,

Jacopo


David E Jones wrote:

>
> How would this be different from the existing fields:
>
>       <field name="quantityUomId" type="id"></field>
>       <field name="quantityIncluded" type="floating-point"></field>
>       <field name="piecesIncluded" type="numeric"></field>
>
> I think what you're proposing for internalUomId sounds like the
> quantityIncluded field and the quantityUomId that goes with it.
>
> I've tried to avoid the idea of a "Unit" or "Each" UOM because it's a
> muddy concept. Of course, it might be needed for some things so if
> something comes up I won't be opposed to it.
>
> For the Product entity this is the intent of the "piecesIncluded" field
> which would basically specify the number of "units" and be independent
> of the quantity and its UOM.
>
> The nice thing is these can then be used together. For example to
> describe a 6 pack of 1.5 liter water bottles you'd have:
>
> quantityUomId: whatever "liter" is
> quantityIncluded: 1.5
> piecesIncluded: 6
>
> -David
>
>
> On Sep 5, 2006, at 3:07 AM, Jacopo Cappellato wrote:
>
>> Right now there is no full support for different uoms in
>> purchase/sales orders and inventory (there are some - not complete -
>> contributions in Jira that we'll have to review).
>> Sooner or later I'll have to implement this.
>>
>> In the meantime, what about adding a new field ("internalUomId") to
>> the Product entity to specify the uom in which the units are stocked
>> (InventoryItem) and to which the unit price refers (ProductPrices)?
>>
>> And what about adding a new unit of measure:
>> <Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE" abbreviation="unit"
>> description="Unit"/>
>> ?
>>
>> This would be useful to specify that a product is
>> sold/purchased/stocked in units: this would be the default value in
>> the EditProduct form.
>>
>> Is it ok?
>>
>> Jacopo

[Jacopo Cappellato]

David,

David E Jones wrote:
>
> I've tried to avoid the idea of a "Unit" or "Each" UOM because it's a
> muddy concept. Of course, it might be needed for some things so if
> something comes up I won't be opposed to it.
>

ok, so the convention could be that if the "quantityUomId" is not set,
then the product's uom is implicitly "Unit".

Jacopo

[David E Jones-2]

Sounds about right.

Note that with something like this the "requireAmount" field should  
be set to "Y" and then it will ask for an "amount" in addition to a  
quantity. For example for 20 ropes, 3.5 meters long each:

amount: 3.5
quantity: 20

-David


On Sep 5, 2006, at 10:50 PM, Jacopo Cappellato wrote:

> David,
>
> that's great, thanks.
> So, if I have a product that I sell in meters (its prices are also  
> expressed for one meter of the product) and the stock levels are  
> also in meters, what I have to do is this:
>
> quantityUomId: "meter"
> quantityIncluded: 1
>
> Is it correct?
>
> Thanks,
>
> Jacopo
>
>
> David E Jones wrote:
>> How would this be different from the existing fields:
>>       <field name="quantityUomId" type="id"></field>
>>       <field name="quantityIncluded" type="floating-point"></field>
>>       <field name="piecesIncluded" type="numeric"></field>
>> I think what you're proposing for internalUomId sounds like the  
>> quantityIncluded field and the quantityUomId that goes with it.
>> I've tried to avoid the idea of a "Unit" or "Each" UOM because  
>> it's a muddy concept. Of course, it might be needed for some  
>> things so if something comes up I won't be opposed to it.
>> For the Product entity this is the intent of the "piecesIncluded"  
>> field which would basically specify the number of "units" and be  
>> independent of the quantity and its UOM.
>> The nice thing is these can then be used together. For example to  
>> describe a 6 pack of 1.5 liter water bottles you'd have:
>> quantityUomId: whatever "liter" is
>> quantityIncluded: 1.5
>> piecesIncluded: 6
>> -David
>> On Sep 5, 2006, at 3:07 AM, Jacopo Cappellato wrote:
>>> Right now there is no full support for different uoms in purchase/
>>> sales orders and inventory (there are some - not complete -  
>>> contributions in Jira that we'll have to review).
>>> Sooner or later I'll have to implement this.
>>>
>>> In the meantime, what about adding a new field ("internalUomId")  
>>> to the Product entity to specify the uom in which the units are  
>>> stocked (InventoryItem) and to which the unit price refers  
>>> (ProductPrices)?
>>>
>>> And what about adding a new unit of measure:
>>> <Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE"  
>>> abbreviation="unit" description="Unit"/>
>>> ?
>>>
>>> This would be useful to specify that a product is sold/purchased/
>>> stocked in units: this would be the default value in the  
>>> EditProduct form.
>>>
>>> Is it ok?
>>>
>>> Jacopo
>

[Jacopo Cappellato]

Is it really needed/mandatory?

There are a few issues in the current implementation of the 'amount'
stuff (for example, amounts are ignored when
reservations/issuances/shipments are done) that I'd like to not cope
with now...

And if the product's quantity uom is 'meter', the company buys and sells
the product in meters, and the unit price is for one meter of product...
why do we need the amount field?

Thanks for your help,

Jacopo

David E Jones wrote:

>
> Sounds about right.
>
> Note that with something like this the "requireAmount" field should be
> set to "Y" and then it will ask for an "amount" in addition to a
> quantity. For example for 20 ropes, 3.5 meters long each:
>
> amount: 3.5
> quantity: 20
>
> -David
>
>
> On Sep 5, 2006, at 10:50 PM, Jacopo Cappellato wrote:
>
>> David,
>>
>> that's great, thanks.
>> So, if I have a product that I sell in meters (its prices are also
>> expressed for one meter of the product) and the stock levels are also
>> in meters, what I have to do is this:
>>
>> quantityUomId: "meter"
>> quantityIncluded: 1
>>
>> Is it correct?
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> How would this be different from the existing fields:
>>>       <field name="quantityUomId" type="id"></field>
>>>       <field name="quantityIncluded" type="floating-point"></field>
>>>       <field name="piecesIncluded" type="numeric"></field>
>>> I think what you're proposing for internalUomId sounds like the
>>> quantityIncluded field and the quantityUomId that goes with it.
>>> I've tried to avoid the idea of a "Unit" or "Each" UOM because it's a
>>> muddy concept. Of course, it might be needed for some things so if
>>> something comes up I won't be opposed to it.
>>> For the Product entity this is the intent of the "piecesIncluded"
>>> field which would basically specify the number of "units" and be
>>> independent of the quantity and its UOM.
>>> The nice thing is these can then be used together. For example to
>>> describe a 6 pack of 1.5 liter water bottles you'd have:
>>> quantityUomId: whatever "liter" is
>>> quantityIncluded: 1.5
>>> piecesIncluded: 6
>>> -David
>>> On Sep 5, 2006, at 3:07 AM, Jacopo Cappellato wrote:
>>>> Right now there is no full support for different uoms in
>>>> purchase/sales orders and inventory (there are some - not complete -
>>>> contributions in Jira that we'll have to review).
>>>> Sooner or later I'll have to implement this.
>>>>
>>>> In the meantime, what about adding a new field ("internalUomId") to
>>>> the Product entity to specify the uom in which the units are stocked
>>>> (InventoryItem) and to which the unit price refers (ProductPrices)?
>>>>
>>>> And what about adding a new unit of measure:
>>>> <Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE" abbreviation="unit"
>>>> description="Unit"/>
>>>> ?
>>>>
>>>> This would be useful to specify that a product is
>>>> sold/purchased/stocked in units: this would be the default value in
>>>> the EditProduct form.
>>>>
>>>> Is it ok?
>>>>
>>>> Jacopo
>>

[David E Jones-2]

Will this require using sub-unit quantities? That's something we've  
started moving away from, and I'd prefer to continue that...

-David


On Sep 6, 2006, at 1:50 PM, Jacopo Cappellato wrote:

> Is it really needed/mandatory?
>
> There are a few issues in the current implementation of the  
> 'amount' stuff (for example, amounts are ignored when reservations/
> issuances/shipments are done) that I'd like to not cope with now...
>
> And if the product's quantity uom is 'meter', the company buys and  
> sells the product in meters, and the unit price is for one meter of  
> product... why do we need the amount field?
>
> Thanks for your help,
>
> Jacopo
>
> David E Jones wrote:
>> Sounds about right.
>> Note that with something like this the "requireAmount" field  
>> should be set to "Y" and then it will ask for an "amount" in  
>> addition to a quantity. For example for 20 ropes, 3.5 meters long  
>> each:
>> amount: 3.5
>> quantity: 20
>> -David
>> On Sep 5, 2006, at 10:50 PM, Jacopo Cappellato wrote:
>>> David,
>>>
>>> that's great, thanks.
>>> So, if I have a product that I sell in meters (its prices are  
>>> also expressed for one meter of the product) and the stock levels  
>>> are also in meters, what I have to do is this:
>>>
>>> quantityUomId: "meter"
>>> quantityIncluded: 1
>>>
>>> Is it correct?
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>>> David E Jones wrote:
>>>> How would this be different from the existing fields:
>>>>       <field name="quantityUomId" type="id"></field>
>>>>       <field name="quantityIncluded" type="floating-point"></field>
>>>>       <field name="piecesIncluded" type="numeric"></field>
>>>> I think what you're proposing for internalUomId sounds like the  
>>>> quantityIncluded field and the quantityUomId that goes with it.
>>>> I've tried to avoid the idea of a "Unit" or "Each" UOM because  
>>>> it's a muddy concept. Of course, it might be needed for some  
>>>> things so if something comes up I won't be opposed to it.
>>>> For the Product entity this is the intent of the  
>>>> "piecesIncluded" field which would basically specify the number  
>>>> of "units" and be independent of the quantity and its UOM.
>>>> The nice thing is these can then be used together. For example  
>>>> to describe a 6 pack of 1.5 liter water bottles you'd have:
>>>> quantityUomId: whatever "liter" is
>>>> quantityIncluded: 1.5
>>>> piecesIncluded: 6
>>>> -David
>>>> On Sep 5, 2006, at 3:07 AM, Jacopo Cappellato wrote:
>>>>> Right now there is no full support for different uoms in  
>>>>> purchase/sales orders and inventory (there are some - not  
>>>>> complete - contributions in Jira that we'll have to review).
>>>>> Sooner or later I'll have to implement this.
>>>>>
>>>>> In the meantime, what about adding a new field  
>>>>> ("internalUomId") to the Product entity to specify the uom in  
>>>>> which the units are stocked (InventoryItem) and to which the  
>>>>> unit price refers (ProductPrices)?
>>>>>
>>>>> And what about adding a new unit of measure:
>>>>> <Uom uomId="OTH_unit" uomTypeId="OTHER_MEASURE"  
>>>>> abbreviation="unit" description="Unit"/>
>>>>> ?
>>>>>
>>>>> This would be useful to specify that a product is sold/
>>>>> purchased/stocked in units: this would be the default value in  
>>>>> the EditProduct form.
>>>>>
>>>>> Is it ok?
>>>>>
>>>>> Jacopo
>>>
>

[Jacopo Cappellato]

David,

David E Jones wrote:
 >
 > Will this require using sub-unit quantities? That's something we've
 > started moving away from, and I'd prefer to continue that...
 >
 > -David
 >

no, I agree with you that we should really avoid this (i.e. in inventory
items the qty, reservations, QOH and ATP will always be integers numbers).

I've thought a bit about this, and I think that the trick here is that
the unit in the uom set in Product.quantityUomId should be the minimum
indivisibile entity of a product.
For example, if quantityUomId = "centimeters", this means that we will
purchase, sell (or consume) and stock the product in centimeters (not
millimeters).
And the unit price (in ProductPrice) will be referred to one centimeter
of the product.
In this way, I think, the system will work fine as is now; the only
modification I will do is to store the Product.quantityUomId (in not
null, i.e. if not 'units' or 'each' uom) in the already existing
InventoryItem.uomId (every time newly inventory items are created for
the product).

Is this ok?

And, continuing with the example above, (sorry for the long post, but
this is very similar to the issue I'm facing with
SupplierProduct.lastPrice, discussed in another recent thread) if the
product is consumed/stocked in centimeters but we need to specify the
unit price for one meter (because we will sell it in 'units' of 100
centimeters long) we could represent it in the following way:

Product.quantityUomId: "centimeter"
Product.quantityIncluded: 100
ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100 centimeters of
the product, i.e. one meter)

In order entry, if I enter a quantity of 2, in the cart the new item
will have a quantity of 200 (2*100) and the item amount will be 1$ (0.5*2).

Does this make sense? (I'm not sure it is 100% correct)

Jacopo

[Jacques Le Roux]

> David,
>
> David E Jones wrote:
>  >
>  > Will this require using sub-unit quantities? That's something we've
>  > started moving away from, and I'd prefer to continue that...
>  >
>  > -David
>  >
>
> no, I agree with you that we should really avoid this (i.e. in inventory
> items the qty, reservations, QOH and ATP will always be integers numbers).
>
> I've thought a bit about this, and I think that the trick here is that
> the unit in the uom set in Product.quantityUomId should be the minimum
> indivisibile entity of a product.
> For example, if quantityUomId = "centimeters", this means that we will
> purchase, sell (or consume) and stock the product in centimeters (not
> millimeters).
> And the unit price (in ProductPrice) will be referred to one centimeter
> of the product.
> In this way, I think, the system will work fine as is now; the only
> modification I will do is to store the Product.quantityUomId (in not
> null, i.e. if not 'units' or 'each' uom) in the already existing
> InventoryItem.uomId (every time newly inventory items are created for
> the product).
>
> Is this ok?
>
> And, continuing with the example above, (sorry for the long post, but
> this is very similar to the issue I'm facing with
> SupplierProduct.lastPrice, discussed in another recent thread) if the
> product is consumed/stocked in centimeters but we need to specify the
> unit price for one meter (because we will sell it in 'units' of 100
> centimeters long) we could represent it in the following way:
>
> Product.quantityUomId: "centimeter"
> Product.quantityIncluded: 100
> ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100 centimeters of
> the product, i.e. one meter)
>
> In order entry, if I enter a quantity of 2, in the cart the new item
> will have a quantity of 200 (2*100) and the item amount will be 1$ (0.5*2).
>
> Does this make sense? (I'm not sure it is 100% correct)

I agree : we must set an unit and this can't be sub atomic.

Jacques

> Jacopo
>

[David E Jones-2]

Jacopo,

I think this is fine and if I understand what you're saying right it  
is the way we've been going. In other words we've been punting on the  
issue of selling sub-unit quantities for a while.

-David


On Sep 6, 2006, at 11:00 PM, Jacopo Cappellato wrote:

> David,
>
> David E Jones wrote:
> >
> > Will this require using sub-unit quantities? That's something we've
> > started moving away from, and I'd prefer to continue that...
> >
> > -David
> >
>
> no, I agree with you that we should really avoid this (i.e. in  
> inventory items the qty, reservations, QOH and ATP will always be  
> integers numbers).
>
> I've thought a bit about this, and I think that the trick here is  
> that the unit in the uom set in Product.quantityUomId should be the  
> minimum indivisibile entity of a product.
> For example, if quantityUomId = "centimeters", this means that we  
> will purchase, sell (or consume) and stock the product in  
> centimeters (not millimeters).
> And the unit price (in ProductPrice) will be referred to one  
> centimeter of the product.
> In this way, I think, the system will work fine as is now; the only  
> modification I will do is to store the Product.quantityUomId (in  
> not null, i.e. if not 'units' or 'each' uom) in the already  
> existing InventoryItem.uomId (every time newly inventory items are  
> created for the product).
>
> Is this ok?
>
> And, continuing with the example above, (sorry for the long post,  
> but this is very similar to the issue I'm facing with  
> SupplierProduct.lastPrice, discussed in another recent thread) if  
> the product is consumed/stocked in centimeters but we need to  
> specify the unit price for one meter (because we will sell it in  
> 'units' of 100 centimeters long) we could represent it in the  
> following way:
>
> Product.quantityUomId: "centimeter"
> Product.quantityIncluded: 100
> ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100  
> centimeters of the product, i.e. one meter)
>
> In order entry, if I enter a quantity of 2, in the cart the new  
> item will have a quantity of 200 (2*100) and the item amount will  
> be 1$ (0.5*2).
>
> Does this make sense? (I'm not sure it is 100% correct)
>
> Jacopo
>
>

[Jacopo Cappellato]

David, all,

I'm trying to implement this but I have some doubts and I'd really
appreciate your advices.

Scenario:

let's consider the WG-1111 product, that has quantityIncluded = 50 and
unit price = 59.99$; this means that 50 units of WG-1111 are sold at 59.99$.
This is correctly handled by the system.
However, when you create a sales order for 1 unit of WG-1111 in the
OrderItem entity the following values are stored:
quantity = 1
unitPrice = 59.99

And from the inventory 1 unit is reserved.
This means that in warehouse I'm storing WG-1111 in sets of 50 units.

My goal is different: I'd like to store (and buy from suppliers) WG-1111
in quantity units and sell it in sets of 50 (at the price of 59.99).

Should we change the order entry process so that, if I want to sell
three sets of WG-1111, I have to enter a quantity of 150 (and add a
constraint to the shopping cart to only accept multiple of 50 in orders)
so that in the OrderItem entity the following values are stored:
quantity = 150
unitPrice = 59.99 (for a set of 50 units)
itemAmount = 59.99 * 3

?

But if this is the right approach, how can we express this information:

unitPrice = 59.99 (for a set of 50 units)

?

Should we add a new field to store the units for which the unitPrice is
expressed? Can we reuse the amountSelected field?

Am I totally wrong?

Please help me because as soon as I've figured out how to implement this
I'd like to apply the same pattern to the purcahse orders
(SupplierProduct entity)

Thanks,

Jacopo







Jacopo Cappellato wrote:

> David,
>
> David E Jones wrote:
>  >
>  > Will this require using sub-unit quantities? That's something we've
>  > started moving away from, and I'd prefer to continue that...
>  >
>  > -David
>  >
>
> no, I agree with you that we should really avoid this (i.e. in inventory
> items the qty, reservations, QOH and ATP will always be integers numbers).
>
> I've thought a bit about this, and I think that the trick here is that
> the unit in the uom set in Product.quantityUomId should be the minimum
> indivisibile entity of a product.
> For example, if quantityUomId = "centimeters", this means that we will
> purchase, sell (or consume) and stock the product in centimeters (not
> millimeters).
> And the unit price (in ProductPrice) will be referred to one centimeter
> of the product.
> In this way, I think, the system will work fine as is now; the only
> modification I will do is to store the Product.quantityUomId (in not
> null, i.e. if not 'units' or 'each' uom) in the already existing
> InventoryItem.uomId (every time newly inventory items are created for
> the product).
>
> Is this ok?
>
> And, continuing with the example above, (sorry for the long post, but
> this is very similar to the issue I'm facing with
> SupplierProduct.lastPrice, discussed in another recent thread) if the
> product is consumed/stocked in centimeters but we need to specify the
> unit price for one meter (because we will sell it in 'units' of 100
> centimeters long) we could represent it in the following way:
>
> Product.quantityUomId: "centimeter"
> Product.quantityIncluded: 100
> ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100 centimeters of
> the product, i.e. one meter)
>
> In order entry, if I enter a quantity of 2, in the cart the new item
> will have a quantity of 200 (2*100) and the item amount will be 1$ (0.5*2).
>
> Does this make sense? (I'm not sure it is 100% correct)
>
> Jacopo
>

[Daniel Kunkel]

Jacopo

You've probably already thought of this, but I've been finding the new
Auto Marketing Package system to work excellent for situations like
this, as it let's me take a base set of products and sell them in a wide
variety of combinations while keeping perfect track of inventory and
very clear descriptions of what's being bought and sold.

Thanks

Daniel


On Sun, 2006-09-17 at 12:30 +0200, Jacopo Cappellato wrote:

> David, all,
>
> I'm trying to implement this but I have some doubts and I'd really
> appreciate your advices.
>
> Scenario:
>
> let's consider the WG-1111 product, that has quantityIncluded = 50 and
> unit price = 59.99$; this means that 50 units of WG-1111 are sold at 59.99$.
> This is correctly handled by the system.
> However, when you create a sales order for 1 unit of WG-1111 in the
> OrderItem entity the following values are stored:
> quantity = 1
> unitPrice = 59.99
>
> And from the inventory 1 unit is reserved.
> This means that in warehouse I'm storing WG-1111 in sets of 50 units.
>
> My goal is different: I'd like to store (and buy from suppliers) WG-1111
> in quantity units and sell it in sets of 50 (at the price of 59.99).
>
> Should we change the order entry process so that, if I want to sell
> three sets of WG-1111, I have to enter a quantity of 150 (and add a
> constraint to the shopping cart to only accept multiple of 50 in orders)
> so that in the OrderItem entity the following values are stored:
> quantity = 150
> unitPrice = 59.99 (for a set of 50 units)
> itemAmount = 59.99 * 3
>
> ?
>
> But if this is the right approach, how can we express this information:
>
> unitPrice = 59.99 (for a set of 50 units)
>
> ?
>
> Should we add a new field to store the units for which the unitPrice is
> expressed? Can we reuse the amountSelected field?
>
> Am I totally wrong?
>
> Please help me because as soon as I've figured out how to implement this
> I'd like to apply the same pattern to the purcahse orders
> (SupplierProduct entity)
>
> Thanks,
>
> Jacopo
>
>
>
>
>
>
>
> Jacopo Cappellato wrote:
> > David,
> >
> > David E Jones wrote:
> >  >
> >  > Will this require using sub-unit quantities? That's something we've
> >  > started moving away from, and I'd prefer to continue that...
> >  >
> >  > -David
> >  >
> >
> > no, I agree with you that we should really avoid this (i.e. in inventory
> > items the qty, reservations, QOH and ATP will always be integers numbers).
> >
> > I've thought a bit about this, and I think that the trick here is that
> > the unit in the uom set in Product.quantityUomId should be the minimum
> > indivisibile entity of a product.
> > For example, if quantityUomId = "centimeters", this means that we will
> > purchase, sell (or consume) and stock the product in centimeters (not
> > millimeters).
> > And the unit price (in ProductPrice) will be referred to one centimeter
> > of the product.
> > In this way, I think, the system will work fine as is now; the only
> > modification I will do is to store the Product.quantityUomId (in not
> > null, i.e. if not 'units' or 'each' uom) in the already existing
> > InventoryItem.uomId (every time newly inventory items are created for
> > the product).
> >
> > Is this ok?
> >
> > And, continuing with the example above, (sorry for the long post, but
> > this is very similar to the issue I'm facing with
> > SupplierProduct.lastPrice, discussed in another recent thread) if the
> > product is consumed/stocked in centimeters but we need to specify the
> > unit price for one meter (because we will sell it in 'units' of 100
> > centimeters long) we could represent it in the following way:
> >
> > Product.quantityUomId: "centimeter"
> > Product.quantityIncluded: 100
> > ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100 centimeters of
> > the product, i.e. one meter)
> >
> > In order entry, if I enter a quantity of 2, in the cart the new item
> > will have a quantity of 200 (2*100) and the item amount will be 1$ (0.5*2).
> >
> > Does this make sense? (I'm not sure it is 100% correct)
> >
> > Jacopo
> >
>

[Jacopo Cappellato]

Hi Daniel,

yes, marketing packages are a good way of handling similar processes and
I'm glad to get your positive feedback on them.
However, mine is a different issue: my need is to keep products'
inventory using a very precise uom, let's say millimeters, but express
the price for 1000 millimeter (i.e. 1 meter) of the product (because the
product is sold in quantities that are multiple of 1000 millimeters and
because the unit price for one millimeter could be a very small number
(such as 0.00001$).

Jacopo

Daniel Kunkel wrote:

> Jacopo
>
> You've probably already thought of this, but I've been finding the new
> Auto Marketing Package system to work excellent for situations like
> this, as it let's me take a base set of products and sell them in a wide
> variety of combinations while keeping perfect track of inventory and
> very clear descriptions of what's being bought and sold.
>
> Thanks
>
> Daniel
>

[David E Jones-2]

So, what you're saying is that you want to stock in quantities of 1  
but sell only quantities of 50?

You could have a product (product "A") that represents a single unit  
and put that in inventory but don't make it available for sale, and  
then have another product (product "B") that is available for sale  
that represents 50 of the stocked product and use a marketing package  
or manufactured product to handle the quantity.

In this way you don't need any price attached to product A, and  
instead just have your $59.99 associated with product B. That way  
even if it is a small price that would make the price of product A  
too small to reasonably handle, it will still work fine.

-David


On Sep 17, 2006, at 4:30 AM, Jacopo Cappellato wrote:

> David, all,
>
> I'm trying to implement this but I have some doubts and I'd really  
> appreciate your advices.
>
> Scenario:
>
> let's consider the WG-1111 product, that has quantityIncluded = 50  
> and unit price = 59.99$; this means that 50 units of WG-1111 are  
> sold at 59.99$.
> This is correctly handled by the system.
> However, when you create a sales order for 1 unit of WG-1111 in the  
> OrderItem entity the following values are stored:
> quantity = 1
> unitPrice = 59.99
>
> And from the inventory 1 unit is reserved.
> This means that in warehouse I'm storing WG-1111 in sets of 50 units.
>
> My goal is different: I'd like to store (and buy from suppliers)  
> WG-1111 in quantity units and sell it in sets of 50 (at the price  
> of 59.99).
>
> Should we change the order entry process so that, if I want to sell  
> three sets of WG-1111, I have to enter a quantity of 150 (and add a  
> constraint to the shopping cart to only accept multiple of 50 in  
> orders) so that in the OrderItem entity the following values are  
> stored:
> quantity = 150
> unitPrice = 59.99 (for a set of 50 units)
> itemAmount = 59.99 * 3
>
> ?
>
> But if this is the right approach, how can we express this  
> information:
>
> unitPrice = 59.99 (for a set of 50 units)
>
> ?
>
> Should we add a new field to store the units for which the  
> unitPrice is expressed? Can we reuse the amountSelected field?
>
> Am I totally wrong?
>
> Please help me because as soon as I've figured out how to implement  
> this I'd like to apply the same pattern to the purcahse orders  
> (SupplierProduct entity)
>
> Thanks,
>
> Jacopo
>
>
>
>
>
>
>
> Jacopo Cappellato wrote:
>> David,
>> David E Jones wrote:
>>  >
>>  > Will this require using sub-unit quantities? That's something  
>> we've
>>  > started moving away from, and I'd prefer to continue that...
>>  >
>>  > -David
>>  >
>> no, I agree with you that we should really avoid this (i.e. in  
>> inventory items the qty, reservations, QOH and ATP will always be  
>> integers numbers).
>> I've thought a bit about this, and I think that the trick here is  
>> that the unit in the uom set in Product.quantityUomId should be  
>> the minimum indivisibile entity of a product.
>> For example, if quantityUomId = "centimeters", this means that we  
>> will purchase, sell (or consume) and stock the product in  
>> centimeters (not millimeters).
>> And the unit price (in ProductPrice) will be referred to one  
>> centimeter of the product.
>> In this way, I think, the system will work fine as is now; the  
>> only modification I will do is to store the Product.quantityUomId  
>> (in not null, i.e. if not 'units' or 'each' uom) in the already  
>> existing InventoryItem.uomId (every time newly inventory items are  
>> created for the product).
>> Is this ok?
>> And, continuing with the example above, (sorry for the long post,  
>> but this is very similar to the issue I'm facing with  
>> SupplierProduct.lastPrice, discussed in another recent thread) if  
>> the product is consumed/stocked in centimeters but we need to  
>> specify the unit price for one meter (because we will sell it in  
>> 'units' of 100 centimeters long) we could represent it in the  
>> following way:
>> Product.quantityUomId: "centimeter"
>> Product.quantityIncluded: 100
>> ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100  
>> centimeters of the product, i.e. one meter)
>> In order entry, if I enter a quantity of 2, in the cart the new  
>> item will have a quantity of 200 (2*100) and the item amount will  
>> be 1$ (0.5*2).
>> Does this make sense? (I'm not sure it is 100% correct)
>> Jacopo
>

[Jacopo Cappellato]

David,

really thanks for your help.
This is very similar to what Daniel suggested to do and, even if I
really needed this but on the purchase order/receiving side of the
story, I ended up following your suggestions: I have created a marketing
package (that I order from supplier) and I automatically decompose when
it is received in inventory.

To summarize this interesting conversation, just to be sure to
understand the meaning of all these fields:

Product.unitsIncluded
Product.quantityIncluded
Product.quantityUomId

are just 'descriptive' fields: I mean that their content is intended to
better describe the nature of the product but this information has no
impact in the system (prices and inventory).

On the other hand, the "amount" (that is stored in the
OrderItem.amountSelected field) is used as a multiplier for the unit
price: if a product (with require amount = Y) has a unit price of 2$
(ProductPrice) and you select an amount of 100 then the new unit price
(in the cart/order) is 200; the "amount" will not affect in any way the
quantity issued from inventory that is always the OrderItem.quantity field.
Is this correct?

Jacopo

PS: This makes me think that the amount multiplier has some potential
and could be used also to express small unit prices (amount = 0.0001)...
but the problem is that the new unitPrice is stored in the
OrderItem.unitPrice field that has limited precision... maybe we should
store there the original unit price and just get the order item total
as: OrderItem.quantity * OrderItem.amountSelected * OrderItem.unitPrice


David E Jones wrote:

>
> So, what you're saying is that you want to stock in quantities of 1 but
> sell only quantities of 50?
>
> You could have a product (product "A") that represents a single unit and
> put that in inventory but don't make it available for sale, and then
> have another product (product "B") that is available for sale that
> represents 50 of the stocked product and use a marketing package or
> manufactured product to handle the quantity.
>
> In this way you don't need any price attached to product A, and instead
> just have your $59.99 associated with product B. That way even if it is
> a small price that would make the price of product A too small to
> reasonably handle, it will still work fine.
>
> -David
>

[David E Jones-2]

On Sep 19, 2006, at 2:10 AM, Jacopo Cappellato wrote:

> David,
>
> really thanks for your help.
> This is very similar to what Daniel suggested to do and, even if I  
> really needed this but on the purchase order/receiving side of the  
> story, I ended up following your suggestions: I have created a  
> marketing package (that I order from supplier) and I automatically  
> decompose when it is received in inventory.
>
> To summarize this interesting conversation, just to be sure to  
> understand the meaning of all these fields:
>
> Product.unitsIncluded
> Product.quantityIncluded
> Product.quantityUomId
>
> are just 'descriptive' fields: I mean that their content is  
> intended to better describe the nature of the product but this  
> information has no impact in the system (prices and inventory).

Yes, I believe that is still correct. There could be automation uses  
for these, but I think to date there is not.

> On the other hand, the "amount" (that is stored in the  
> OrderItem.amountSelected field) is used as a multiplier for the  
> unit price: if a product (with require amount = Y) has a unit price  
> of 2$ (ProductPrice) and you select an amount of 100 then the new  
> unit price (in the cart/order) is 200; the "amount" will not affect  
> in any way the quantity issued from inventory that is always the  
> OrderItem.quantity field.
> Is this correct?

I think this is correct, but unfortunately it is also a bug... The  
amount really should be multiplied by the quantity in order to get  
the total to deduct from inventory and so on.


> Jacopo
>
> PS: This makes me think that the amount multiplier has some  
> potential and could be used also to express small unit prices  
> (amount = 0.0001)... but the problem is that the new unitPrice is  
> stored in the OrderItem.unitPrice field that has limited  
> precision... maybe we should store there the original unit price  
> and just get the order item total as: OrderItem.quantity *  
> OrderItem.amountSelected * OrderItem.unitPrice

Isn't it done this way already, ie calculating the order item  
subtotal this way?

-David

>
>
> David E Jones wrote:
>> So, what you're saying is that you want to stock in quantities of  
>> 1 but sell only quantities of 50?
>> You could have a product (product "A") that represents a single  
>> unit and put that in inventory but don't make it available for  
>> sale, and then have another product (product "B") that is  
>> available for sale that represents 50 of the stocked product and  
>> use a marketing package or manufactured product to handle the  
>> quantity.
>> In this way you don't need any price attached to product A, and  
>> instead just have your $59.99 associated with product B. That way  
>> even if it is a small price that would make the price of product A  
>> too small to reasonably handle, it will still work fine.
>> -David
>

[Jacopo Cappellato]

David,

please see my comments inline:

David E Jones wrote:

>
> On Sep 19, 2006, at 2:10 AM, Jacopo Cappellato wrote:
>
>> David,
>>
>> On the other hand, the "amount" (that is stored in the
>> OrderItem.amountSelected field) is used as a multiplier for the unit
>> price: if a product (with require amount = Y) has a unit price of 2$
>> (ProductPrice) and you select an amount of 100 then the new unit price
>> (in the cart/order) is 200; the "amount" will not affect in any way
>> the quantity issued from inventory that is always the
>> OrderItem.quantity field.
>> Is this correct?
>
> I think this is correct, but unfortunately it is also a bug... The
> amount really should be multiplied by the quantity in order to get the
> total to deduct from inventory and so on.
>

Hmmm... but in this way we could have non integer inventory quantities
(since the amount value can be a non integer value)... do we really want
this to happen?

>
>>
>> PS: This makes me think that the amount multiplier has some potential
>> and could be used also to express small unit prices (amount =
>> 0.0001)... but the problem is that the new unitPrice is stored in the
>> OrderItem.unitPrice field that has limited precision... maybe we
>> should store there the original unit price and just get the order item
>> total as: OrderItem.quantity * OrderItem.amountSelected *
>> OrderItem.unitPrice
>
> Isn't it done this way already, ie calculating the order item subtotal
> this way?
>

Not exactly in this way.
For example: if I order an item with original unit price of 15.99,
quantity = 2 and amount = 1.5, in the OrderItem entity the following
values are stored:

quantity = 2
selectedAmount = 1.5
unitPrice = 23.98 (!!! This is the result of 1.5 * 15.99 = 23.985)

and the order item subtotal is (correctly) calculated multiplying the
quantity and the unitPrice: 47.96

Maybe we should instead store in the OrderItem:

quantity = 2
selectedAmount = 1.5
unitPrice = 15.99

and the order item subtotal should be calculated multiplying the
quantity, the unitPrice and the selected amount: 2 * 1.5 * 15.99 = 47.97
But then the selectedAmount should be displayed in all the order view
screens.
Should we try to clean/fix this?
If so, I could put some effort in this but first I'd like to be sure to
understand the intended use of the amount field.

Thanks,

Jacopo

> -David
>
>
>>
>>
>> David E Jones wrote:
>>> So, what you're saying is that you want to stock in quantities of 1
>>> but sell only quantities of 50?
>>> You could have a product (product "A") that represents a single unit
>>> and put that in inventory but don't make it available for sale, and
>>> then have another product (product "B") that is available for sale
>>> that represents 50 of the stocked product and use a marketing package
>>> or manufactured product to handle the quantity.
>>> In this way you don't need any price attached to product A, and
>>> instead just have your $59.99 associated with product B. That way
>>> even if it is a small price that would make the price of product A
>>> too small to reasonably handle, it will still work fine.
>>> -David
>>

[David E Jones-2]

On Sep 19, 2006, at 5:36 AM, Jacopo Cappellato wrote:

> David E Jones wrote:
>> On Sep 19, 2006, at 2:10 AM, Jacopo Cappellato wrote:
>>> On the other hand, the "amount" (that is stored in the  
>>> OrderItem.amountSelected field) is used as a multiplier for the  
>>> unit price: if a product (with require amount = Y) has a unit  
>>> price of 2$ (ProductPrice) and you select an amount of 100 then  
>>> the new unit price (in the cart/order) is 200; the "amount" will  
>>> not affect in any way the quantity issued from inventory that is  
>>> always the OrderItem.quantity field.
>>> Is this correct?
>> I think this is correct, but unfortunately it is also a bug... The  
>> amount really should be multiplied by the quantity in order to get  
>> the total to deduct from inventory and so on.
> Hmmm... but in this way we could have non integer inventory quantities
> (since the amount value can be a non integer value)... do we really  
> want
> this to happen?

I think that non-integer inventory quantities are okay, and for some  
products they are necessary. In fact, is there any way to avoid this  
quite a few manufacturing materials like rope, wire, glue, paint/
lacquer, and so on?

>>> PS: This makes me think that the amount multiplier has some  
>>> potential and could be used also to express small unit prices  
>>> (amount = 0.0001)... but the problem is that the new unitPrice is  
>>> stored in the OrderItem.unitPrice field that has limited  
>>> precision... maybe we should store there the original unit price  
>>> and just get the order item total as: OrderItem.quantity *  
>>> OrderItem.amountSelected * OrderItem.unitPrice
>> Isn't it done this way already, ie calculating the order item  
>> subtotal this way?
> Not exactly in this way.
> For example: if I order an item with original unit price of 15.99,  
> quantity = 2 and amount = 1.5, in the OrderItem entity the  
> following values are stored:
>
> quantity = 2
> selectedAmount = 1.5
> unitPrice = 23.98 (!!! This is the result of 1.5 * 15.99 = 23.985)
>
> and the order item subtotal is (correctly) calculated multiplying  
> the quantity and the unitPrice: 47.96
>
> Maybe we should instead store in the OrderItem:
>
> quantity = 2
> selectedAmount = 1.5
> unitPrice = 15.99
>
> and the order item subtotal should be calculated multiplying the  
> quantity, the unitPrice and the selected amount: 2 * 1.5 * 15.99 =  
> 47.97
> But then the selectedAmount should be displayed in all the order  
> view screens.
> Should we try to clean/fix this?
> If so, I could put some effort in this but first I'd like to be  
> sure to understand the intended use of the amount field.

This is interesting, and a little scary... ;)

I've never actually looked into this in detail as Andy is the one who  
implemented it. I don't think I like this implementation decision  
though, so unless someone sees a reason why it would be better this  
way I think we should change it. I _can_ think of a couple of reasons  
why it is worse: it is not very intuitive, and it could lead to  
inaccurate price calculations.

-David

[Jacopo Cappellato]

David E Jones wrote:
>
  > I think that non-integer inventory quantities are okay, and for some
> products they are necessary. In fact, is there any way to avoid this  
> quite a few manufacturing materials like rope, wire, glue,
> paint/lacquer, and so on?
>

We are actually avoiding non-integer quantities by selecting for each
product the smallest unit of measure that is allowed in the system for
it; for example, if the consumption of rope in production runs is
expressed in millimeters then millimeters is the quantity of inventory
items, purchase prices are expressed in millimeters etc...
This solves a lot of issues but in the same time introduces new ones,
such as the problem I had recently to express unit purchase prices for
very small quantities... but I guess that when we will finally implement
the support for different uoms in sales/purchase/inventory this will be
solved (hopefully).

>
> This is interesting, and a little scary... ;)
>
> I've never actually looked into this in detail as Andy is the one who
> implemented it. I don't think I like this implementation decision
> though, so unless someone sees a reason why it would be better this way
> I think we should change it. I _can_ think of a couple of reasons why it
> is worse: it is not very intuitive, and it could lead to inaccurate
> price calculations.
>

Ok, I think that sooner or later we'll have to fix this part of the
system, and I'd suggest to follow one of the two paths here:

1) in the OrderItem, store the original unitPrice, quantity and amount
and then always get the order item subtotal as
unitPrice*quantity*amount; (we could do this for all the products if we
use the convention of storing 1.0 in the amount field for non-amount
products); however I think we should handle correctly the amount field
in the Invoice, Return etc.... I'm not sure it is correctly done now

2) replace the amount implementation with something new, such as a true
support for different uoms in sales/purchase orders and inventory

Jacopo