Dev - Ordering Units of Measure

[Carl Sopchak]

Much to my surprise, OFBiz does not seem to "do" order quantities in units of
measure other than the stock keeping unit.  (I.e., you can't order a "Box" of
something when stock is kept in "Eaches".)  Someone, please let me know if
I'm wrong here!  Or, if anyone has made the mod on a "custom" basis, please
contact me off-list.

Assuming I need to make this change, here is what I propose:

1) Add attributes to the Product entity: skuUom (stock keeping unit UoM), and
customerOrderUom (default customer order quantity UoM; I forsee a
supplierOrderUom in my future, too, but I'm not sure yet).
2) Add the above fields to the Product Entry screen.  Validate that either the
two UoM's are equal, or that there are UomConversion records to go between
the two.
3) Add attributes to the OrderItem entity:  quantityAsOrdered and
quantityAsOrderedUom.
4) Change the entry of order line items so that the quantity that is entered
on the screen is saved in the quantityAsOrdered attribute, and add a
drop-down of units of measure, showing only those units of measure which have
a UomConversion record on file where the uomIdTo = product.skuUom, with the
default value being the product.customerOrderUom, and the selection being
saved in quantityAsOrderedUom.  The quantityAsOrdered would be converted from
the quantityAsOrderedUom to the product.skuUom, and the result stored in
OrderItem.quantity.  (There may be a rounding issue here that convertUom will
have to address...)
5) Change the display of order lines to show the quantityAsOrdered and
quantityAsOrderedUom instead of (or in addition to?) quantity and skuUom.

Here are my questions:

- Overall, does this make sense?  Comments / suggestions / etc. welcome...
- I haven't received my Data Modeling Resource Books yet (on order...), so I'm
assuming the entities mentioned above are the right place to put the
additional attributes.  Please correct me if I'm wrong.
- As for the "drop-down of UoMs" based on the product entered, this may be a
bit difficult on a web page due to the way web browsing works (although I've
seen "dynamic" pages that do similar things).  Is there a standard way to
handle such things in OFBiz?  Should I just display the customerOrderUom, and
supply a pop-up to pick from (based on the productId)?  This does seems a bit
awkward though, particularly for "high volume" order entry.
- Although I'm sure I could find where everything needs to go, if anyone would
like to point me to specific things that would need changing (particularly if
I missed something), it would be most appreciated.

Thanks in advance for the help and comments.

Carl
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

OK, I finally got my Data Model Resource Books on Saturday, and I see that the
author suggests that different ordering UoM's are either different features,
or even different products.  I'm not sure I agree with the different products
view, but I was wondering if anyone has tried implementing multiple ordering
UoM's as product features.  If so, I was wondering how well it worked for
you, and how, specifically, they would get set up.  (Admittedly, I haven't
spent a LOT of time on trying to figure this out yet, but I'd rather spend my
time changing the order entry screens if needed...)

The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You know,
the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8, is a
2x4x8!  We'll be shipping the same pieces, whether they order 200 pieces,
1600 lineal feet, 1067 board feet, or 1 "unit" (those huge "packages" you see
stacked in your local home improvement store).  Further, if they order 1000
board feet, we may very well ship the 1067 BF in a unit.  (Other
rounding-type issues may apply as well.)  If we have only one full unit, and
a customer orders 100 pieces, we break the unit.  In other words, there's
nothing special with the UoM's, except convenience (or habit of the customer)
in ordering.

So, for us, different UoM's are DEFINITELY NOT different products.  (Even the
ream of paper example in the book doesn't fly well with me - thinking about
boxes and pallets of reams of paper, but I'll let that slide for now...)  I'm
not too sure how well ordering will work (particularly during the busy summer
months) with UoM as a feature.

One last question:  If we decide to do the order entry mod described in the
original email, should we do it as part of OFBiz and submit a patch, or
should we keep it as a local mod (since it seems against the data model
apparently employed by OFBiz)?

Any comments or suggestions would be most welcome.

Thanks,

Carl

On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:

> Much to my surprise, OFBiz does not seem to "do" order quantities in units
> of measure other than the stock keeping unit.  (I.e., you can't order a
> "Box" of something when stock is kept in "Eaches".)  Someone, please let me
> know if I'm wrong here!  Or, if anyone has made the mod on a "custom"
> basis, please contact me off-list.
>
> Assuming I need to make this change, here is what I propose:
>
> 1) Add attributes to the Product entity: skuUom (stock keeping unit UoM),
> and customerOrderUom (default customer order quantity UoM; I forsee a
> supplierOrderUom in my future, too, but I'm not sure yet).
> 2) Add the above fields to the Product Entry screen.  Validate that either
> the two UoM's are equal, or that there are UomConversion records to go
> between the two.
> 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
> quantityAsOrderedUom.
> 4) Change the entry of order line items so that the quantity that is
> entered on the screen is saved in the quantityAsOrdered attribute, and add
> a drop-down of units of measure, showing only those units of measure which
> have a UomConversion record on file where the uomIdTo = product.skuUom,
> with the default value being the product.customerOrderUom, and the
> selection being saved in quantityAsOrderedUom.  The quantityAsOrdered would
> be converted from the quantityAsOrderedUom to the product.skuUom, and the
> result stored in OrderItem.quantity.  (There may be a rounding issue here
> that convertUom will have to address...)
> 5) Change the display of order lines to show the quantityAsOrdered and
> quantityAsOrderedUom instead of (or in addition to?) quantity and skuUom.
>
> Here are my questions:
>
> - Overall, does this make sense?  Comments / suggestions / etc. welcome...
> - I haven't received my Data Modeling Resource Books yet (on order...), so
> I'm assuming the entities mentioned above are the right place to put the
> additional attributes.  Please correct me if I'm wrong.
> - As for the "drop-down of UoMs" based on the product entered, this may be
> a bit difficult on a web page due to the way web browsing works (although
> I've seen "dynamic" pages that do similar things).  Is there a standard way
> to handle such things in OFBiz?  Should I just display the
> customerOrderUom, and supply a pop-up to pick from (based on the
> productId)?  This does seems a bit awkward though, particularly for "high
> volume" order entry.
> - Although I'm sure I could find where everything needs to go, if anyone
> would like to point me to specific things that would need changing
> (particularly if I missed something), it would be most appreciated.
>
> Thanks in advance for the help and comments.
>
> Carl
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

From: "Carl Sopchak" <[hidden email]>

> OK, I finally got my Data Model Resource Books on Saturday, and I see that the
> author suggests that different ordering UoM's are either different features,
> or even different products.  I'm not sure I agree with the different products
> view, but I was wondering if anyone has tried implementing multiple ordering
> UoM's as product features.  If so, I was wondering how well it worked for
> you, and how, specifically, they would get set up.  (Admittedly, I haven't
> spent a LOT of time on trying to figure this out yet, but I'd rather spend my
> time changing the order entry screens if needed...)
>
> The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You know,
> the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8, is a
> 2x4x8!  We'll be shipping the same pieces, whether they order 200 pieces,
> 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge "packages" you see
> stacked in your local home improvement store).  Further, if they order 1000
> board feet, we may very well ship the 1067 BF in a unit.  (Other
> rounding-type issues may apply as well.)  If we have only one full unit, and
> a customer orders 100 pieces, we break the unit.  In other words, there's
> nothing special with the UoM's, except convenience (or habit of the customer)
> in ordering.
>
> So, for us, different UoM's are DEFINITELY NOT different products.  (Even the
> ream of paper example in the book doesn't fly well with me - thinking about
> boxes and pallets of reams of paper, but I'll let that slide for now...)  I'm
> not too sure how well ordering will work (particularly during the busy summer
> months) with UoM as a feature.
>
> One last question:  If we decide to do the order entry mod described in the
> original email, should we do it as part of OFBiz and submit a patch, or
> should we keep it as a local mod (since it seems against the data model
> apparently employed by OFBiz)?
>
> Any comments or suggestions would be most welcome.
>
> Thanks,
>
> Carl
>
> On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
> > Much to my surprise, OFBiz does not seem to "do" order quantities in units
> > of measure other than the stock keeping unit.  (I.e., you can't order a
> > "Box" of something when stock is kept in "Eaches".)  Someone, please let me
> > know if I'm wrong here!  Or, if anyone has made the mod on a "custom"
> > basis, please contact me off-list.
> >
> > Assuming I need to make this change, here is what I propose:
> >
> > 1) Add attributes to the Product entity: skuUom (stock keeping unit UoM),
> > and customerOrderUom (default customer order quantity UoM; I forsee a
> > supplierOrderUom in my future, too, but I'm not sure yet).
> > 2) Add the above fields to the Product Entry screen.  Validate that either
> > the two UoM's are equal, or that there are UomConversion records to go
> > between the two.
> > 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
> > quantityAsOrderedUom.
> > 4) Change the entry of order line items so that the quantity that is
> > entered on the screen is saved in the quantityAsOrdered attribute, and add
> > a drop-down of units of measure, showing only those units of measure which
> > have a UomConversion record on file where the uomIdTo = product.skuUom,
> > with the default value being the product.customerOrderUom, and the
> > selection being saved in quantityAsOrderedUom.  The quantityAsOrdered would
> > be converted from the quantityAsOrderedUom to the product.skuUom, and the
> > result stored in OrderItem.quantity.  (There may be a rounding issue here
> > that convertUom will have to address...)
> > 5) Change the display of order lines to show the quantityAsOrdered and
> > quantityAsOrderedUom instead of (or in addition to?) quantity and skuUom.
> >
> > Here are my questions:
> >
> > - Overall, does this make sense?  Comments / suggestions / etc. welcome...
> > - I haven't received my Data Modeling Resource Books yet (on order...), so
> > I'm assuming the entities mentioned above are the right place to put the
> > additional attributes.  Please correct me if I'm wrong.
> > - As for the "drop-down of UoMs" based on the product entered, this may be
> > a bit difficult on a web page due to the way web browsing works (although
> > I've seen "dynamic" pages that do similar things).  Is there a standard way
> > to handle such things in OFBiz?  Should I just display the
> > customerOrderUom, and supply a pop-up to pick from (based on the
> > productId)?  This does seems a bit awkward though, particularly for "high
> > volume" order entry.
> > - Although I'm sure I could find where everything needs to go, if anyone
> > would like to point me to specific things that would need changing
> > (particularly if I missed something), it would be most appreciated.
> >
> > Thanks in advance for the help and comments.
> >
> > Carl

Carl,

I'm not a specialist and sure this is something questionable. Besides Len
Silverston wrote in p. 80 (2d edition) "Most organisations will conclude that
if the same type of product is sold in different units of measure, then it
really is a different product". So he wrote "Most" but not "All". For example in
*most* shops you can pick a bottle out of a pack, but not in *all*. And even in
some shops you may pick a bottle out of some packs (water) but not of all
(beer), at least it's like that here in France.

OK, it was just a rewriting of what you said. My question is (for everybody) :
is there a way to merge this 2 models in one (Mmm if we look at the pack of
bottles example seems hard ;o). Because this seems to come back again and again.

Thanks

Jacques

Jacques

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Carl,

On the do it separately versus a part of OFBiz: there are a lot of benefits for you as well as others to doing it as part of the main project. The downside is that you may get more feedback and review that you want. Sometimes this brings up issues that need to be resolved but that you don't care about, though what often happens is that it turns out that they are issues you really do need to work over.

Whenever doing something based on OFBiz, and especially something that will go back into the project, the most important part is basically what you are doing now: reviewing what exists and deciding how to meet your requirements with existing and/or new features. If it's going back into the project then the duplicated functionality issue is an even bigger one.

=============

For this particular issue I agree that they shouldn't be different products for different UOMs. The general approach is to configure the size in one UOM (preferably consistent across similar products) and convert it in the user interface layer (and perhaps higher level services) to/from what to user prefers.

The UOM stuff you are talking about should, as I mentioned before, be split into 2 sets. The core UOM stuff that does not deal with products (including conversion between varying dimensions, extended UOMs that are industry specific, etc) would go in the "common" component. The extensions to those for dealing with Product specific stuff should go in the "product" component.

In general as much as can be shared should go into lower level components like common, but those can't depend on higher level things in other components like product.

-David



Carl Sopchak wrote:

> OK, I finally got my Data Model Resource Books on Saturday, and I see that the
> author suggests that different ordering UoM's are either different features,
> or even different products.  I'm not sure I agree with the different products
> view, but I was wondering if anyone has tried implementing multiple ordering
> UoM's as product features.  If so, I was wondering how well it worked for
> you, and how, specifically, they would get set up.  (Admittedly, I haven't
> spent a LOT of time on trying to figure this out yet, but I'd rather spend my
> time changing the order entry screens if needed...)
>
> The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You know,
> the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8, is a
> 2x4x8!  We'll be shipping the same pieces, whether they order 200 pieces,
> 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge "packages" you see
> stacked in your local home improvement store).  Further, if they order 1000
> board feet, we may very well ship the 1067 BF in a unit.  (Other
> rounding-type issues may apply as well.)  If we have only one full unit, and
> a customer orders 100 pieces, we break the unit.  In other words, there's
> nothing special with the UoM's, except convenience (or habit of the customer)
> in ordering.
>
> So, for us, different UoM's are DEFINITELY NOT different products.  (Even the
> ream of paper example in the book doesn't fly well with me - thinking about
> boxes and pallets of reams of paper, but I'll let that slide for now...)  I'm
> not too sure how well ordering will work (particularly during the busy summer
> months) with UoM as a feature.
>
> One last question:  If we decide to do the order entry mod described in the
> original email, should we do it as part of OFBiz and submit a patch, or
> should we keep it as a local mod (since it seems against the data model
> apparently employed by OFBiz)?
>
> Any comments or suggestions would be most welcome.
>
> Thanks,
>
> Carl
>
> On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
>> Much to my surprise, OFBiz does not seem to "do" order quantities in units
>> of measure other than the stock keeping unit.  (I.e., you can't order a
>> "Box" of something when stock is kept in "Eaches".)  Someone, please let me
>> know if I'm wrong here!  Or, if anyone has made the mod on a "custom"
>> basis, please contact me off-list.
>>
>> Assuming I need to make this change, here is what I propose:
>>
>> 1) Add attributes to the Product entity: skuUom (stock keeping unit UoM),
>> and customerOrderUom (default customer order quantity UoM; I forsee a
>> supplierOrderUom in my future, too, but I'm not sure yet).
>> 2) Add the above fields to the Product Entry screen.  Validate that either
>> the two UoM's are equal, or that there are UomConversion records to go
>> between the two.
>> 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
>> quantityAsOrderedUom.
>> 4) Change the entry of order line items so that the quantity that is
>> entered on the screen is saved in the quantityAsOrdered attribute, and add
>> a drop-down of units of measure, showing only those units of measure which
>> have a UomConversion record on file where the uomIdTo = product.skuUom,
>> with the default value being the product.customerOrderUom, and the
>> selection being saved in quantityAsOrderedUom.  The quantityAsOrdered would
>> be converted from the quantityAsOrderedUom to the product.skuUom, and the
>> result stored in OrderItem.quantity.  (There may be a rounding issue here
>> that convertUom will have to address...)
>> 5) Change the display of order lines to show the quantityAsOrdered and
>> quantityAsOrderedUom instead of (or in addition to?) quantity and skuUom.
>>
>> Here are my questions:
>>
>> - Overall, does this make sense?  Comments / suggestions / etc. welcome...
>> - I haven't received my Data Modeling Resource Books yet (on order...), so
>> I'm assuming the entities mentioned above are the right place to put the
>> additional attributes.  Please correct me if I'm wrong.
>> - As for the "drop-down of UoMs" based on the product entered, this may be
>> a bit difficult on a web page due to the way web browsing works (although
>> I've seen "dynamic" pages that do similar things).  Is there a standard way
>> to handle such things in OFBiz?  Should I just display the
>> customerOrderUom, and supply a pop-up to pick from (based on the
>> productId)?  This does seems a bit awkward though, particularly for "high
>> volume" order entry.
>> - Although I'm sure I could find where everything needs to go, if anyone
>> would like to point me to specific things that would need changing
>> (particularly if I missed something), it would be most appreciated.
>>
>> Thanks in advance for the help and comments.
>>
>> Carl
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

David,

Thanks for the comments!

My question of "in OFBiz or not" was a check to see if the idea "didn't fit"
with OFBiz philosophy.  Both myself and my client understand the benefits of
keeping changes within OFBiz when it's not a proprietary business process.  
In fact, I have already made some changes to the UoM conversion service that
has been posted in the JIRA (see
http://jira.undersunconsulting.com/browse/OFBIZ-782).

As for too much feedback - no such thing!  I'll listen to all of the ideas (in
fact the UoM change employed Jacopo Cappellato's implementation suggestion),
but when it comes time to implement, my client doesn't want me solving the
world's problems on his dime. ;->  I will always make the change extensible
in those situations, though...

As for where to put the code, maybe I goofed up on that in the UoM change.  I
kept it all in "common", because it was all UoM related, which I figured was
a "common" function.  Are you saying that the product-based portion of the
change (in files services_uom.xml and UomFormulas.xml) should be under
applications/product, not framework/common?  I guess that shouldn't be too
big of a change (but please let me know if it's required/desireable)...  BTW,
how long might it take to get a JIRA patch into the SVN?  Is there anything I
can do to speed it along (like post test results)?  No real time requirement,
I suppose.  Just wonderin'.

Lastly, it's not certain that we will need to make this change (although I
think, long term, it's probably the best way to go), but if we do, I was
thinking of making the functionality based on a "configuration
switch" (customer ordering UoMs? Yes/No).  Is there a place within OFBiz
(database or config file) to store such things?  

Thanks again for the comments, and help.

Carl

On Wednesday, April 05, 2006 19:43, David E. Jones wrote:

> Carl,
>
> On the do it separately versus a part of OFBiz: there are a lot of benefits
> for you as well as others to doing it as part of the main project. The
> downside is that you may get more feedback and review that you want.
> Sometimes this brings up issues that need to be resolved but that you don't
> care about, though what often happens is that it turns out that they are
> issues you really do need to work over.
>
> Whenever doing something based on OFBiz, and especially something that will
> go back into the project, the most important part is basically what you are
> doing now: reviewing what exists and deciding how to meet your requirements
> with existing and/or new features. If it's going back into the project then
> the duplicated functionality issue is an even bigger one.
>
> =============
>
> For this particular issue I agree that they shouldn't be different products
> for different UOMs. The general approach is to configure the size in one
> UOM (preferably consistent across similar products) and convert it in the
> user interface layer (and perhaps higher level services) to/from what to
> user prefers.
>
> The UOM stuff you are talking about should, as I mentioned before, be split
> into 2 sets. The core UOM stuff that does not deal with products (including
> conversion between varying dimensions, extended UOMs that are industry
> specific, etc) would go in the "common" component. The extensions to those
> for dealing with Product specific stuff should go in the "product"
> component.
>
> In general as much as can be shared should go into lower level components
> like common, but those can't depend on higher level things in other
> components like product.
>
> -David
>
> Carl Sopchak wrote:
> > OK, I finally got my Data Model Resource Books on Saturday, and I see
> > that the author suggests that different ordering UoM's are either
> > different features, or even different products.  I'm not sure I agree
> > with the different products view, but I was wondering if anyone has tried
> > implementing multiple ordering UoM's as product features.  If so, I was
> > wondering how well it worked for you, and how, specifically, they would
> > get set up.  (Admittedly, I haven't spent a LOT of time on trying to
> > figure this out yet, but I'd rather spend my time changing the order
> > entry screens if needed...)
> >
> > The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You
> > know, the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8,
> > is a 2x4x8!  We'll be shipping the same pieces, whether they order 200
> > pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge
> > "packages" you see stacked in your local home improvement store).
> > Further, if they order 1000 board feet, we may very well ship the 1067 BF
> > in a unit.  (Other rounding-type issues may apply as well.)  If we have
> > only one full unit, and a customer orders 100 pieces, we break the unit.
> > In other words, there's nothing special with the UoM's, except
> > convenience (or habit of the customer) in ordering.
> >
> > So, for us, different UoM's are DEFINITELY NOT different products.  (Even
> > the ream of paper example in the book doesn't fly well with me - thinking
> > about boxes and pallets of reams of paper, but I'll let that slide for
> > now...)  I'm not too sure how well ordering will work (particularly
> > during the busy summer months) with UoM as a feature.
> >
> > One last question:  If we decide to do the order entry mod described in
> > the original email, should we do it as part of OFBiz and submit a patch,
> > or should we keep it as a local mod (since it seems against the data
> > model apparently employed by OFBiz)?
> >
> > Any comments or suggestions would be most welcome.
> >
> > Thanks,
> >
> > Carl
> >
> > On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
> >> Much to my surprise, OFBiz does not seem to "do" order quantities in
> >> units of measure other than the stock keeping unit.  (I.e., you can't
> >> order a "Box" of something when stock is kept in "Eaches".)  Someone,
> >> please let me know if I'm wrong here!  Or, if anyone has made the mod on
> >> a "custom" basis, please contact me off-list.
> >>
> >> Assuming I need to make this change, here is what I propose:
> >>
> >> 1) Add attributes to the Product entity: skuUom (stock keeping unit
> >> UoM), and customerOrderUom (default customer order quantity UoM; I
> >> forsee a supplierOrderUom in my future, too, but I'm not sure yet).
> >> 2) Add the above fields to the Product Entry screen.  Validate that
> >> either the two UoM's are equal, or that there are UomConversion records
> >> to go between the two.
> >> 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
> >> quantityAsOrderedUom.
> >> 4) Change the entry of order line items so that the quantity that is
> >> entered on the screen is saved in the quantityAsOrdered attribute, and
> >> add a drop-down of units of measure, showing only those units of measure
> >> which have a UomConversion record on file where the uomIdTo =
> >> product.skuUom, with the default value being the
> >> product.customerOrderUom, and the selection being saved in
> >> quantityAsOrderedUom.  The quantityAsOrdered would be converted from the
> >> quantityAsOrderedUom to the product.skuUom, and the result stored in
> >> OrderItem.quantity.  (There may be a rounding issue here that convertUom
> >> will have to address...)
> >> 5) Change the display of order lines to show the quantityAsOrdered and
> >> quantityAsOrderedUom instead of (or in addition to?) quantity and
> >> skuUom.
> >>
> >> Here are my questions:
> >>
> >> - Overall, does this make sense?  Comments / suggestions / etc.
> >> welcome... - I haven't received my Data Modeling Resource Books yet (on
> >> order...), so I'm assuming the entities mentioned above are the right
> >> place to put the additional attributes.  Please correct me if I'm wrong.
> >> - As for the "drop-down of UoMs" based on the product entered, this may
> >> be a bit difficult on a web page due to the way web browsing works
> >> (although I've seen "dynamic" pages that do similar things).  Is there a
> >> standard way to handle such things in OFBiz?  Should I just display the
> >> customerOrderUom, and supply a pop-up to pick from (based on the
> >> productId)?  This does seems a bit awkward though, particularly for
> >> "high volume" order entry.
> >> - Although I'm sure I could find where everything needs to go, if anyone
> >> would like to point me to specific things that would need changing
> >> (particularly if I missed something), it would be most appreciated.
> >>
> >> Thanks in advance for the help and comments.
> >>
> >> Carl
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Carl Sopchak wrote:
> As for too much feedback - no such thing!  I'll listen to all of the ideas (in
> fact the UoM change employed Jacopo Cappellato's implementation suggestion),
> but when it comes time to implement, my client doesn't want me solving the
> world's problems on his dime. ;->  I will always make the change extensible
> in those situations, though...

There are some nice arguments for making things more flexible. If a client is really cheap then you should do what you can a move on. Some clients are just not good to work for and there is no way to avoid certain sorts of losses. There are a lot of reasons for this that I've seen over the years, but having a short range vision or assuming they have all the answers they need for right now and don't want to even consider other things are some common ones.

Anyway... considering flexibility and adaptability during analysis is always a good idea. If the client doesn't like it then it is more difficult for you, but no less necessary. A good consultant, in my opinion, should always do such things and discuss them with the client and in essence acknowledge that not everything is known at the moment and that there is a 100% chance (+/- 0%) that things will change in the company in the future, and they can avoid a lot of pain by considering the possibility now.

> As for where to put the code, maybe I goofed up on that in the UoM change.  I
> kept it all in "common", because it was all UoM related, which I figured was
> a "common" function.  Are you saying that the product-based portion of the
> change (in files services_uom.xml and UomFormulas.xml) should be under
> applications/product, not framework/common?  I guess that shouldn't be too
> big of a change (but please let me know if it's required/desirable)...  BTW,
> how long might it take to get a JIRA patch into the SVN?  Is there anything I
> can do to speed it along (like post test results)?  No real time requirement,
> I suppose.  Just wonderin'.

Yes, this should be split out into changes for the common component and separate ones that can depend on the common component ones but that go in the product component.

As I mentioned before the common component and lower level components in general should never know anything about stuff in higher level components. So yes, that split is important.

As for time to get them in... there are no guarantees and little consistency in this. Si, Jacopo, and I are all trying our best to keep up with Jira issues in addition to reviewing bigger issues that come up and pursue what we have to in order to survive financially.

In other words, there is no funded organization behind OFBiz so things happen when they can. If someone wants things to go faster and has the resources to get that done then it will get done. If not then the only choice is to wait for someone else to pay for what you can't or don't want to pay for. There are certainly many who are investing in OFBiz in this way, but if you want to take advantage of that it does require patience.

For Jira issues there is a LOT of room for help with these by whoever wants to help. This doesn't mean we'll give commit access to just anyone or just anywhere, we do need to have some control over what goes into OFBiz to help keep it stable and such, but there are literally thousands of hours of review of issues and finding or improving solutions that needs to be done. If people want to contribute time that's a great place to do it. Just try the patches and comment on them, or even just vote for issues that are more important to you. This is an opportunity for everyone using OFBiz to express what is important to them. Without that all I can do each week with the hours I set aside for the project is guess at what might be the highest priorities, or just pick the ones I like the best or think I can get done most quickly.

> Lastly, it's not certain that we will need to make this change (although I
> think, long term, it's probably the best way to go), but if we do, I was
> thinking of making the functionality based on a "configuration
> switch" (customer ordering UoMs? Yes/No).  Is there a place within OFBiz
> (database or config file) to store such things?  

It depends on what the setting will affect. This may be best as a per-product setting to change what is presented in the customer (or CSR) facing UI. There are various examples of this already on the Product and related entities.

-David

>
> Thanks again for the comments, and help.
>
> Carl
>
> On Wednesday, April 05, 2006 19:43, David E. Jones wrote:
>> Carl,
>>
>> On the do it separately versus a part of OFBiz: there are a lot of benefits
>> for you as well as others to doing it as part of the main project. The
>> downside is that you may get more feedback and review that you want.
>> Sometimes this brings up issues that need to be resolved but that you don't
>> care about, though what often happens is that it turns out that they are
>> issues you really do need to work over.
>>
>> Whenever doing something based on OFBiz, and especially something that will
>> go back into the project, the most important part is basically what you are
>> doing now: reviewing what exists and deciding how to meet your requirements
>> with existing and/or new features. If it's going back into the project then
>> the duplicated functionality issue is an even bigger one.
>>
>> =============
>>
>> For this particular issue I agree that they shouldn't be different products
>> for different UOMs. The general approach is to configure the size in one
>> UOM (preferably consistent across similar products) and convert it in the
>> user interface layer (and perhaps higher level services) to/from what to
>> user prefers.
>>
>> The UOM stuff you are talking about should, as I mentioned before, be split
>> into 2 sets. The core UOM stuff that does not deal with products (including
>> conversion between varying dimensions, extended UOMs that are industry
>> specific, etc) would go in the "common" component. The extensions to those
>> for dealing with Product specific stuff should go in the "product"
>> component.
>>
>> In general as much as can be shared should go into lower level components
>> like common, but those can't depend on higher level things in other
>> components like product.
>>
>> -David
>>
>> Carl Sopchak wrote:
>>> OK, I finally got my Data Model Resource Books on Saturday, and I see
>>> that the author suggests that different ordering UoM's are either
>>> different features, or even different products.  I'm not sure I agree
>>> with the different products view, but I was wondering if anyone has tried
>>> implementing multiple ordering UoM's as product features.  If so, I was
>>> wondering how well it worked for you, and how, specifically, they would
>>> get set up.  (Admittedly, I haven't spent a LOT of time on trying to
>>> figure this out yet, but I'd rather spend my time changing the order
>>> entry screens if needed...)
>>>
>>> The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You
>>> know, the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8,
>>> is a 2x4x8!  We'll be shipping the same pieces, whether they order 200
>>> pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge
>>> "packages" you see stacked in your local home improvement store).
>>> Further, if they order 1000 board feet, we may very well ship the 1067 BF
>>> in a unit.  (Other rounding-type issues may apply as well.)  If we have
>>> only one full unit, and a customer orders 100 pieces, we break the unit.
>>> In other words, there's nothing special with the UoM's, except
>>> convenience (or habit of the customer) in ordering.
>>>
>>> So, for us, different UoM's are DEFINITELY NOT different products.  (Even
>>> the ream of paper example in the book doesn't fly well with me - thinking
>>> about boxes and pallets of reams of paper, but I'll let that slide for
>>> now...)  I'm not too sure how well ordering will work (particularly
>>> during the busy summer months) with UoM as a feature.
>>>
>>> One last question:  If we decide to do the order entry mod described in
>>> the original email, should we do it as part of OFBiz and submit a patch,
>>> or should we keep it as a local mod (since it seems against the data
>>> model apparently employed by OFBiz)?
>>>
>>> Any comments or suggestions would be most welcome.
>>>
>>> Thanks,
>>>
>>> Carl
>>>
>>> On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
>>>> Much to my surprise, OFBiz does not seem to "do" order quantities in
>>>> units of measure other than the stock keeping unit.  (I.e., you can't
>>>> order a "Box" of something when stock is kept in "Eaches".)  Someone,
>>>> please let me know if I'm wrong here!  Or, if anyone has made the mod on
>>>> a "custom" basis, please contact me off-list.
>>>>
>>>> Assuming I need to make this change, here is what I propose:
>>>>
>>>> 1) Add attributes to the Product entity: skuUom (stock keeping unit
>>>> UoM), and customerOrderUom (default customer order quantity UoM; I
>>>> forsee a supplierOrderUom in my future, too, but I'm not sure yet).
>>>> 2) Add the above fields to the Product Entry screen.  Validate that
>>>> either the two UoM's are equal, or that there are UomConversion records
>>>> to go between the two.
>>>> 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
>>>> quantityAsOrderedUom.
>>>> 4) Change the entry of order line items so that the quantity that is
>>>> entered on the screen is saved in the quantityAsOrdered attribute, and
>>>> add a drop-down of units of measure, showing only those units of measure
>>>> which have a UomConversion record on file where the uomIdTo =
>>>> product.skuUom, with the default value being the
>>>> product.customerOrderUom, and the selection being saved in
>>>> quantityAsOrderedUom.  The quantityAsOrdered would be converted from the
>>>> quantityAsOrderedUom to the product.skuUom, and the result stored in
>>>> OrderItem.quantity.  (There may be a rounding issue here that convertUom
>>>> will have to address...)
>>>> 5) Change the display of order lines to show the quantityAsOrdered and
>>>> quantityAsOrderedUom instead of (or in addition to?) quantity and
>>>> skuUom.
>>>>
>>>> Here are my questions:
>>>>
>>>> - Overall, does this make sense?  Comments / suggestions / etc.
>>>> welcome... - I haven't received my Data Modeling Resource Books yet (on
>>>> order...), so I'm assuming the entities mentioned above are the right
>>>> place to put the additional attributes.  Please correct me if I'm wrong.
>>>> - As for the "drop-down of UoMs" based on the product entered, this may
>>>> be a bit difficult on a web page due to the way web browsing works
>>>> (although I've seen "dynamic" pages that do similar things).  Is there a
>>>> standard way to handle such things in OFBiz?  Should I just display the
>>>> customerOrderUom, and supply a pop-up to pick from (based on the
>>>> productId)?  This does seems a bit awkward though, particularly for
>>>> "high volume" order entry.
>>>> - Although I'm sure I could find where everything needs to go, if anyone
>>>> would like to point me to specific things that would need changing
>>>> (particularly if I missed something), it would be most appreciated.
>>>>
>>>> Thanks in advance for the help and comments.
>>>>
>>>> Carl
>>>>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Adrian Crum]

I'm going to jump in here and add a few thoughts of my own.

First, my apologies to Carl for not being more involved in this after saying I
would help. We had major staff reductions here right after I made that
commitment and now I'm having a hard time just trying to keep up with my
(non-OFBiz) work here.

I think what David is saying is: conversions that are generally usable should go
in the common component. Like feet<->inches, feet<->meters, lbs<->kilos, etc.

Converting lineal feet to board feet is more product specific. The same with
case<->each, container<->gallon, etc.

As far as getting Jira issues committed is concerned - regardless of what David
says, it boils down to whether or not your patch will benefit the few who have
commit priviledges. There has been some really good work submitted to Jira, but
it just sits there. The voting thing was suggested before, but I haven't seen
where that really affects anything. One thing that puzzles me is why Si Chen can
ask to have his Jira issues committed and it gets done without question (and
without voting). What makes his submissions so special?

The best thing to do is submit the patch to Jira and then don't hold your
breath. Just apply the patch to your own copy whenever you update. One day a
committer will find your enhancement useful and will integrate it into the project.

-Adrian


David E. Jones wrote:

>
> Carl Sopchak wrote:
>
>>As for too much feedback - no such thing!  I'll listen to all of the ideas (in
>>fact the UoM change employed Jacopo Cappellato's implementation suggestion),
>>but when it comes time to implement, my client doesn't want me solving the
>>world's problems on his dime. ;->  I will always make the change extensible
>>in those situations, though...
>
>
> There are some nice arguments for making things more flexible. If a client is really cheap then you should do what you can a move on. Some clients are just not good to work for and there is no way to avoid certain sorts of losses. There are a lot of reasons for this that I've seen over the years, but having a short range vision or assuming they have all the answers they need for right now and don't want to even consider other things are some common ones.
>
> Anyway... considering flexibility and adaptability during analysis is always a good idea. If the client doesn't like it then it is more difficult for you, but no less necessary. A good consultant, in my opinion, should always do such things and discuss them with the client and in essence acknowledge that not everything is known at the moment and that there is a 100% chance (+/- 0%) that things will change in the company in the future, and they can avoid a lot of pain by considering the possibility now.
>
>
>>As for where to put the code, maybe I goofed up on that in the UoM change.  I
>>kept it all in "common", because it was all UoM related, which I figured was
>>a "common" function.  Are you saying that the product-based portion of the
>>change (in files services_uom.xml and UomFormulas.xml) should be under
>>applications/product, not framework/common?  I guess that shouldn't be too
>>big of a change (but please let me know if it's required/desirable)...  BTW,
>>how long might it take to get a JIRA patch into the SVN?  Is there anything I
>>can do to speed it along (like post test results)?  No real time requirement,
>>I suppose.  Just wonderin'.
>
>
> Yes, this should be split out into changes for the common component and separate ones that can depend on the common component ones but that go in the product component.
>
> As I mentioned before the common component and lower level components in general should never know anything about stuff in higher level components. So yes, that split is important.
>
> As for time to get them in... there are no guarantees and little consistency in this. Si, Jacopo, and I are all trying our best to keep up with Jira issues in addition to reviewing bigger issues that come up and pursue what we have to in order to survive financially.
>
> In other words, there is no funded organization behind OFBiz so things happen when they can. If someone wants things to go faster and has the resources to get that done then it will get done. If not then the only choice is to wait for someone else to pay for what you can't or don't want to pay for. There are certainly many who are investing in OFBiz in this way, but if you want to take advantage of that it does require patience.
>
> For Jira issues there is a LOT of room for help with these by whoever wants to help. This doesn't mean we'll give commit access to just anyone or just anywhere, we do need to have some control over what goes into OFBiz to help keep it stable and such, but there are literally thousands of hours of review of issues and finding or improving solutions that needs to be done. If people want to contribute time that's a great place to do it. Just try the patches and comment on them, or even just vote for issues that are more important to you. This is an opportunity for everyone using OFBiz to express what is important to them. Without that all I can do each week with the hours I set aside for the project is guess at what might be the highest priorities, or just pick the ones I like the best or think I can get done most quickly.
>
>
>>Lastly, it's not certain that we will need to make this change (although I
>>think, long term, it's probably the best way to go), but if we do, I was
>>thinking of making the functionality based on a "configuration
>>switch" (customer ordering UoMs? Yes/No).  Is there a place within OFBiz
>>(database or config file) to store such things?  
>
>
> It depends on what the setting will affect. This may be best as a per-product setting to change what is presented in the customer (or CSR) facing UI. There are various examples of this already on the Product and related entities.
>
> -David
>
>
>
>>Thanks again for the comments, and help.
>>
>>Carl
>>
>>On Wednesday, April 05, 2006 19:43, David E. Jones wrote:
>>
>>>Carl,
>>>
>>>On the do it separately versus a part of OFBiz: there are a lot of benefits
>>>for you as well as others to doing it as part of the main project. The
>>>downside is that you may get more feedback and review that you want.
>>>Sometimes this brings up issues that need to be resolved but that you don't
>>>care about, though what often happens is that it turns out that they are
>>>issues you really do need to work over.
>>>
>>>Whenever doing something based on OFBiz, and especially something that will
>>>go back into the project, the most important part is basically what you are
>>>doing now: reviewing what exists and deciding how to meet your requirements
>>>with existing and/or new features. If it's going back into the project then
>>>the duplicated functionality issue is an even bigger one.
>>>
>>>=============
>>>
>>>For this particular issue I agree that they shouldn't be different products
>>>for different UOMs. The general approach is to configure the size in one
>>>UOM (preferably consistent across similar products) and convert it in the
>>>user interface layer (and perhaps higher level services) to/from what to
>>>user prefers.
>>>
>>>The UOM stuff you are talking about should, as I mentioned before, be split
>>>into 2 sets. The core UOM stuff that does not deal with products (including
>>>conversion between varying dimensions, extended UOMs that are industry
>>>specific, etc) would go in the "common" component. The extensions to those
>>>for dealing with Product specific stuff should go in the "product"
>>>component.
>>>
>>>In general as much as can be shared should go into lower level components
>>>like common, but those can't depend on higher level things in other
>>>components like product.
>>>
>>>-David
>>>
>>>Carl Sopchak wrote:
>>>
>>>>OK, I finally got my Data Model Resource Books on Saturday, and I see
>>>>that the author suggests that different ordering UoM's are either
>>>>different features, or even different products.  I'm not sure I agree
>>>>with the different products view, but I was wondering if anyone has tried
>>>>implementing multiple ordering UoM's as product features.  If so, I was
>>>>wondering how well it worked for you, and how, specifically, they would
>>>>get set up.  (Admittedly, I haven't spent a LOT of time on trying to
>>>>figure this out yet, but I'd rather spend my time changing the order
>>>>entry screens if needed...)
>>>>
>>>>The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You
>>>>know, the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8,
>>>>is a 2x4x8!  We'll be shipping the same pieces, whether they order 200
>>>>pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge
>>>>"packages" you see stacked in your local home improvement store).
>>>>Further, if they order 1000 board feet, we may very well ship the 1067 BF
>>>>in a unit.  (Other rounding-type issues may apply as well.)  If we have
>>>>only one full unit, and a customer orders 100 pieces, we break the unit.
>>>>In other words, there's nothing special with the UoM's, except
>>>>convenience (or habit of the customer) in ordering.
>>>>
>>>>So, for us, different UoM's are DEFINITELY NOT different products.  (Even
>>>>the ream of paper example in the book doesn't fly well with me - thinking
>>>>about boxes and pallets of reams of paper, but I'll let that slide for
>>>>now...)  I'm not too sure how well ordering will work (particularly
>>>>during the busy summer months) with UoM as a feature.
>>>>
>>>>One last question:  If we decide to do the order entry mod described in
>>>>the original email, should we do it as part of OFBiz and submit a patch,
>>>>or should we keep it as a local mod (since it seems against the data
>>>>model apparently employed by OFBiz)?
>>>>
>>>>Any comments or suggestions would be most welcome.
>>>>
>>>>Thanks,
>>>>
>>>>Carl
>>>>
>>>>On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
>>>>
>>>>>Much to my surprise, OFBiz does not seem to "do" order quantities in
>>>>>units of measure other than the stock keeping unit.  (I.e., you can't
>>>>>order a "Box" of something when stock is kept in "Eaches".)  Someone,
>>>>>please let me know if I'm wrong here!  Or, if anyone has made the mod on
>>>>>a "custom" basis, please contact me off-list.
>>>>>
>>>>>Assuming I need to make this change, here is what I propose:
>>>>>
>>>>>1) Add attributes to the Product entity: skuUom (stock keeping unit
>>>>>UoM), and customerOrderUom (default customer order quantity UoM; I
>>>>>forsee a supplierOrderUom in my future, too, but I'm not sure yet).
>>>>>2) Add the above fields to the Product Entry screen.  Validate that
>>>>>either the two UoM's are equal, or that there are UomConversion records
>>>>>to go between the two.
>>>>>3) Add attributes to the OrderItem entity:  quantityAsOrdered and
>>>>>quantityAsOrderedUom.
>>>>>4) Change the entry of order line items so that the quantity that is
>>>>>entered on the screen is saved in the quantityAsOrdered attribute, and
>>>>>add a drop-down of units of measure, showing only those units of measure
>>>>>which have a UomConversion record on file where the uomIdTo =
>>>>>product.skuUom, with the default value being the
>>>>>product.customerOrderUom, and the selection being saved in
>>>>>quantityAsOrderedUom.  The quantityAsOrdered would be converted from the
>>>>>quantityAsOrderedUom to the product.skuUom, and the result stored in
>>>>>OrderItem.quantity.  (There may be a rounding issue here that convertUom
>>>>>will have to address...)
>>>>>5) Change the display of order lines to show the quantityAsOrdered and
>>>>>quantityAsOrderedUom instead of (or in addition to?) quantity and
>>>>>skuUom.
>>>>>
>>>>>Here are my questions:
>>>>>
>>>>>- Overall, does this make sense?  Comments / suggestions / etc.
>>>>>welcome... - I haven't received my Data Modeling Resource Books yet (on
>>>>>order...), so I'm assuming the entities mentioned above are the right
>>>>>place to put the additional attributes.  Please correct me if I'm wrong.
>>>>>- As for the "drop-down of UoMs" based on the product entered, this may
>>>>>be a bit difficult on a web page due to the way web browsing works
>>>>>(although I've seen "dynamic" pages that do similar things).  Is there a
>>>>>standard way to handle such things in OFBiz?  Should I just display the
>>>>>customerOrderUom, and supply a pop-up to pick from (based on the
>>>>>productId)?  This does seems a bit awkward though, particularly for
>>>>>"high volume" order entry.
>>>>>- Although I'm sure I could find where everything needs to go, if anyone
>>>>>would like to point me to specific things that would need changing
>>>>>(particularly if I missed something), it would be most appreciated.
>>>>>
>>>>>Thanks in advance for the help and comments.
>>>>>
>>>>>Carl
>>>>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Adrian Crum wrote:

> As far as getting Jira issues committed is concerned - regardless of what David
> says, it boils down to whether or not your patch will benefit the few who have
> commit priviledges. There has been some really good work submitted to Jira, but
> it just sits there. The voting thing was suggested before, but I haven't seen
> where that really affects anything. One thing that puzzles me is why Si Chen can
> ask to have his Jira issues committed and it gets done without question (and
> without voting). What makes his submissions so special?
>
> The best thing to do is submit the patch to Jira and then don't hold your
> breath. Just apply the patch to your own copy whenever you update. One day a
> committer will find your enhancement useful and will integrate it into the project.

Nice attitude Adrian. If this were true OFBiz would simply not exist at all.

Why do I pay attention to Si's requests and not as much to others (ie sometimes prioritizing his higher)? Because Si is actively involved in the project and contributes a great deal. He also stays actively involved with Jira and what is happening in the project by compiling his list every week and regularly reviewing the Jira issues and helping with many of them, and identifying other important ones.

If you're not happy with the work done for free in OFBiz then why don't you do something about it. Be creative.

-David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[cjhowe]

I too have felt Adrian's frustrations in the past.
However instead of voicing my frustration, I submitted
the "differences app" patch and went on my campaign
for
individual developers who don't know OFBiz inside and
out (after 18 months of working on OFBiz, I can say
that I'm still in that boat) to NEVER touch OFBiz
code.  Make a "differences app" instead.

Now, I know I go on and on about it.  But really, it's
the solution for the majority of those who don't have
commit privileges.  It's also the solution for not
having to maintain applications that have thousands of
man hours put into making them work.  It's also the
solution to keep you involved with the improvement of
the underlying application you're differencing.

The differences app idea is the same as taking the
idea of the U.S. Highway system.  While the highway
system can take you just about anywhere that you want
to
go, there are heavily congested areas near
metropolitan cities that you would prefer not to go
thorugh.  So you make a Spur.  You still have the
opportunity to go anywhere you want to go, and when
you get to the area you're not too fond of, you take
the Spur.  Now you only have to maintain the Spur and
nothing else.

Now the differences app does fall short in two
circumstances.  One with the EECAs and one with the
SECAs.  You have to disable them by commenting them
out in the OFBiz code if they're not to you're liking.
 Everything else you can work around.  Java files,
widgets, minilangs, freemarker files, beanshell
scripts, SVN updtates, etc.

Now there is a bit of work to do to allow all of the
OFBiz applications to be differenced.  The calls for
the decorator screens need to be dynamic in their
location (like they are in the ecommerce application).
 Other than that, you're good to go.

And then what's even better, sourceforge.net will host
your "project" and give you an SVN of your own so that
YOU have commit privileges (you do need to consider
licensing issues though).  Then when you'come up with
something spectacular that you wnat all the OFBizers
to see, submit a patch for the ofbiz.org website
telling everybody where they can download the SVN,
post something to the maillists, write up a how to for
the wiki, etc.  Don't worry about making a patch for
it (unless you really want to), if it can benefit the
OFBiz project, the committers know OFBiz well enough
to incorporate your code without it.  And they'll be
able to download a differences app and see what it
does instead of having to double check a patch to see
if it's going to break their environment.

Try doing your OFBiz developing this way and I
gaurantee you'll get a lot more done, a lot quicker
and more people can take advantage of it a lot sooner.


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

>
>
> Adrian Crum wrote:
> > As far as getting Jira issues committed is
> concerned - regardless of what David
> > says, it boils down to whether or not your patch
> will benefit the few who have
> > commit priviledges. There has been some really
> good work submitted to Jira, but
> > it just sits there. The voting thing was suggested
> before, but I haven't seen
> > where that really affects anything. One thing that
> puzzles me is why Si Chen can
> > ask to have his Jira issues committed and it gets
> done without question (and
> > without voting). What makes his submissions so
> special?
> >
> > The best thing to do is submit the patch to Jira
> and then don't hold your
> > breath. Just apply the patch to your own copy
> whenever you update. One day a
> > committer will find your enhancement useful and
> will integrate it into the project.
>
> Nice attitude Adrian. If this were true OFBiz would
> simply not exist at all.
>
> Why do I pay attention to Si's requests and not as
> much to others (ie sometimes prioritizing his
> higher)? Because Si is actively involved in the
> project and contributes a great deal. He also stays
> actively involved with Jira and what is happening in
> the project by compiling his list every week and
> regularly reviewing the Jira issues and helping with
> many of them, and identifying other important ones.
>
> If you're not happy with the work done for free in
> OFBiz then why don't you do something about it. Be
> creative.
>
> -David
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

On Thursday, April 06, 2006 21:10, David E. Jones wrote:

> > Carl Sopchak wrote:
> > As for too much feedback - no such thing!  I'll listen to all of the
> > ideas (in fact the UoM change employed Jacopo Cappellato's implementation
> > suggestion), but when it comes time to implement, my client doesn't want
> > me solving the world's problems on his dime. ;->  I will always make the
> > change extensible in those situations, though...
>
> There are some nice arguments for making things more flexible. If a client
> is really cheap then you should do what you can a move on. Some clients are
> just not good to work for and there is no way to avoid certain sorts of
> losses. There are a lot of reasons for this that I've seen over the years,
> but having a short range vision or assuming they have all the answers they
> need for right now and don't want to even consider other things are some
> common ones.

Just to be clear - I don't consider my client cheap.  In fact, this client is
one of, if the THE, best client I have ever had as far as not continually
pounding me to get things done for less money.  But I feel they should be
getting value for the buck.  If it will take me 10 hours to do a mod to meet
their needs, and 50 to do a "complete" mod that satisfies all, I don't expect
the client to pay for the extra 40 hours.  (Nor will I ask them to.)  If the
difference is 10 vs 15 hours, I'd probably do the complete mod, and only
charge for 10.

>
> Anyway... considering flexibility and adaptability during analysis is
> always a good idea. If the client doesn't like it then it is more difficult
> for you, but no less necessary. A good consultant, in my opinion, should
> always do such things and discuss them with the client and in essence
> acknowledge that not everything is known at the moment and that there is a
> 100% chance (+/- 0%) that things will change in the company in the future,
> and they can avoid a lot of pain by considering the possibility now.

I guess I'm a good consultant, then :-)...  Generally, I find adding a feature
in a flexible manner is usually actually easier than more rigid solutions.  
Plus, it has the added benefit that when the client says "well, now I want to
do Y", you get to say "due to my superior design, you can already do that
with the mod I made for X".  The client then (hopefully) thinks "Good, it's
free!", and, hope against hope, "Maybe this guy isn't as expensive as I
thought..." ;->

>
> > As for where to put the code, maybe I goofed up on that in the UoM
> > change.  I kept it all in "common", because it was all UoM related, which
> > I figured was a "common" function.  Are you saying that the product-based
> > portion of the change (in files services_uom.xml and UomFormulas.xml)
> > should be under applications/product, not framework/common?  I guess that
> > shouldn't be too big of a change (but please let me know if it's
> > required/desirable)...  BTW, how long might it take to get a JIRA patch
> > into the SVN?  Is there anything I can do to speed it along (like post
> > test results)?  No real time requirement, I suppose.  Just wonderin'.
>
> Yes, this should be split out into changes for the common component and
> separate ones that can depend on the common component ones but that go in
> the product component.

I'll move them.  As far as the JIRA goes, the two files that belong in the
product component were separate from the .patch file, so the commiter can put
them where they belong.  I'll need to change the reference within
service_uom.xml, which I'll re-post when I have it done.

>
> As I mentioned before the common component and lower level components in
> general should never know anything about stuff in higher level components.
> So yes, that split is important.

Understandable.  Is there a hierarchy described somewhere?  I'm sure most of
it is common sense, but there could be some components that may blur as to
which is "higher" or "lower" than others...

>
> As for time to get them in... there are no guarantees and little
> consistency in this. Si, Jacopo, and I are all trying our best to keep up
> with Jira issues in addition to reviewing bigger issues that come up and
> pursue what we have to in order to survive financially.

That's fine.  I was just wondering if there was any kind of "usual" time
frame.  It actually makes NO difference to me, as we're not even close to
getting to a production environment yet.  But, I must admit, I do get some
satisfaction out of seeing my changes committed to a project.

>
> In other words, there is no funded organization behind OFBiz so things
> happen when they can. If someone wants things to go faster and has the
> resources to get that done then it will get done. If not then the only
> choice is to wait for someone else to pay for what you can't or don't want
> to pay for. There are certainly many who are investing in OFBiz in this
> way, but if you want to take advantage of that it does require patience.

No one ever told me patience was something I lacked...  Hope I didn't come
across that way, and I'm sorry if I did...

>
> For Jira issues there is a LOT of room for help with these by whoever wants
> to help. This doesn't mean we'll give commit access to just anyone or just
> anywhere, we do need to have some control over what goes into OFBiz to help
> keep it stable and such, but there are literally thousands of hours of
> review of issues and finding or improving solutions that needs to be done.
> If people want to contribute time that's a great place to do it. Just try
> the patches and comment on them, or even just vote for issues that are more
> important to you. This is an opportunity for everyone using OFBiz to
> express what is important to them. Without that all I can do each week with
> the hours I set aside for the project is guess at what might be the highest
> priorities, or just pick the ones I like the best or think I can get done
> most quickly.

I appreciate the control required, particularly with a project of such
complexity.  In fact, I would have to seriously reconsider OFBiz viability if
it wasn't there.

And, I must say I *DO* appreciate the efforts that you, Si, and Jacopo put
into the project.  All three of you have already been a great help in our
implementation, and we've barely started.

>
> > Lastly, it's not certain that we will need to make this change (although
> > I think, long term, it's probably the best way to go), but if we do, I
> > was thinking of making the functionality based on a "configuration
> > switch" (customer ordering UoMs? Yes/No).  Is there a place within OFBiz
> > (database or config file) to store such things?
>
> It depends on what the setting will affect. This may be best as a
> per-product setting to change what is presented in the customer (or CSR)
> facing UI. There are various examples of this already on the Product and
> related entities.

I'm thinking this switch would be an "order entry level" type of switch -
either UoMs are displayed and enterable during customer order entry, or they
are not.  If not, OFBiz works as it does today.  If so, all products would
have the ability to enter UoMs.  If there are some products where only one
UoM applies, then it would be the default UoM for the product, and you
wouldn't have to enter anything.

I don't see this working very well as a per-product setting.  This is mainly
due to the fact that the product ID and quantity - and UoM for the quantity
when I put that in - would be entered on the same screen.  By making it
per-product, I think the order entry flow (multiple screens?), or the screens
(showing UoM when unnecessary), or both, could be a bit confusing or awkward.

====

Again, thanks for all of your help.

Carl

>
> -David
>
> > Thanks again for the comments, and help.
> >
> > Carl
> >
> > On Wednesday, April 05, 2006 19:43, David E. Jones wrote:
> >> Carl,
> >>
> >> On the do it separately versus a part of OFBiz: there are a lot of
> >> benefits for you as well as others to doing it as part of the main
> >> project. The downside is that you may get more feedback and review that
> >> you want. Sometimes this brings up issues that need to be resolved but
> >> that you don't care about, though what often happens is that it turns
> >> out that they are issues you really do need to work over.
> >>
> >> Whenever doing something based on OFBiz, and especially something that
> >> will go back into the project, the most important part is basically what
> >> you are doing now: reviewing what exists and deciding how to meet your
> >> requirements with existing and/or new features. If it's going back into
> >> the project then the duplicated functionality issue is an even bigger
> >> one.
> >>
> >> =============
> >>
> >> For this particular issue I agree that they shouldn't be different
> >> products for different UOMs. The general approach is to configure the
> >> size in one UOM (preferably consistent across similar products) and
> >> convert it in the user interface layer (and perhaps higher level
> >> services) to/from what to user prefers.
> >>
> >> The UOM stuff you are talking about should, as I mentioned before, be
> >> split into 2 sets. The core UOM stuff that does not deal with products
> >> (including conversion between varying dimensions, extended UOMs that are
> >> industry specific, etc) would go in the "common" component. The
> >> extensions to those for dealing with Product specific stuff should go in
> >> the "product" component.
> >>
> >> In general as much as can be shared should go into lower level
> >> components like common, but those can't depend on higher level things in
> >> other components like product.
> >>
> >> -David
> >>
> >> Carl Sopchak wrote:
> >>> OK, I finally got my Data Model Resource Books on Saturday, and I see
> >>> that the author suggests that different ordering UoM's are either
> >>> different features, or even different products.  I'm not sure I agree
> >>> with the different products view, but I was wondering if anyone has
> >>> tried implementing multiple ordering UoM's as product features.  If so,
> >>> I was wondering how well it worked for you, and how, specifically, they
> >>> would get set up.  (Admittedly, I haven't spent a LOT of time on trying
> >>> to figure this out yet, but I'd rather spend my time changing the order
> >>> entry screens if needed...)
> >>>
> >>> The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You
> >>> know, the stuff you build houses with.  In our view, a 2x4x8, is a
> >>> 2x4x8, is a 2x4x8!  We'll be shipping the same pieces, whether they
> >>> order 200 pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those
> >>> huge "packages" you see stacked in your local home improvement store).
> >>> Further, if they order 1000 board feet, we may very well ship the 1067
> >>> BF in a unit.  (Other rounding-type issues may apply as well.)  If we
> >>> have only one full unit, and a customer orders 100 pieces, we break the
> >>> unit. In other words, there's nothing special with the UoM's, except
> >>> convenience (or habit of the customer) in ordering.
> >>>
> >>> So, for us, different UoM's are DEFINITELY NOT different products.
> >>> (Even the ream of paper example in the book doesn't fly well with me -
> >>> thinking about boxes and pallets of reams of paper, but I'll let that
> >>> slide for now...)  I'm not too sure how well ordering will work
> >>> (particularly during the busy summer months) with UoM as a feature.
> >>>
> >>> One last question:  If we decide to do the order entry mod described in
> >>> the original email, should we do it as part of OFBiz and submit a
> >>> patch, or should we keep it as a local mod (since it seems against the
> >>> data model apparently employed by OFBiz)?
> >>>
> >>> Any comments or suggestions would be most welcome.
> >>>
> >>> Thanks,
> >>>
> >>> Carl
> >>>
> >>> On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
> >>>> Much to my surprise, OFBiz does not seem to "do" order quantities in
> >>>> units of measure other than the stock keeping unit.  (I.e., you can't
> >>>> order a "Box" of something when stock is kept in "Eaches".)  Someone,
> >>>> please let me know if I'm wrong here!  Or, if anyone has made the mod
> >>>> on a "custom" basis, please contact me off-list.
> >>>>
> >>>> Assuming I need to make this change, here is what I propose:
> >>>>
> >>>> 1) Add attributes to the Product entity: skuUom (stock keeping unit
> >>>> UoM), and customerOrderUom (default customer order quantity UoM; I
> >>>> forsee a supplierOrderUom in my future, too, but I'm not sure yet).
> >>>> 2) Add the above fields to the Product Entry screen.  Validate that
> >>>> either the two UoM's are equal, or that there are UomConversion
> >>>> records to go between the two.
> >>>> 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
> >>>> quantityAsOrderedUom.
> >>>> 4) Change the entry of order line items so that the quantity that is
> >>>> entered on the screen is saved in the quantityAsOrdered attribute, and
> >>>> add a drop-down of units of measure, showing only those units of
> >>>> measure which have a UomConversion record on file where the uomIdTo =
> >>>> product.skuUom, with the default value being the
> >>>> product.customerOrderUom, and the selection being saved in
> >>>> quantityAsOrderedUom.  The quantityAsOrdered would be converted from
> >>>> the quantityAsOrderedUom to the product.skuUom, and the result stored
> >>>> in OrderItem.quantity.  (There may be a rounding issue here that
> >>>> convertUom will have to address...)
> >>>> 5) Change the display of order lines to show the quantityAsOrdered and
> >>>> quantityAsOrderedUom instead of (or in addition to?) quantity and
> >>>> skuUom.
> >>>>
> >>>> Here are my questions:
> >>>>
> >>>> - Overall, does this make sense?  Comments / suggestions / etc.
> >>>> welcome... - I haven't received my Data Modeling Resource Books yet
> >>>> (on order...), so I'm assuming the entities mentioned above are the
> >>>> right place to put the additional attributes.  Please correct me if
> >>>> I'm wrong. - As for the "drop-down of UoMs" based on the product
> >>>> entered, this may be a bit difficult on a web page due to the way web
> >>>> browsing works (although I've seen "dynamic" pages that do similar
> >>>> things).  Is there a standard way to handle such things in OFBiz?
> >>>> Should I just display the customerOrderUom, and supply a pop-up to
> >>>> pick from (based on the productId)?  This does seems a bit awkward
> >>>> though, particularly for "high volume" order entry.
> >>>> - Although I'm sure I could find where everything needs to go, if
> >>>> anyone would like to point me to specific things that would need
> >>>> changing (particularly if I missed something), it would be most
> >>>> appreciated.
> >>>>
> >>>> Thanks in advance for the help and comments.
> >>>>
> >>>> Carl
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

On Thursday, April 06, 2006 21:32, Adrian Crum wrote:
> First, my apologies to Carl for not being more involved in this after
> saying I would help. We had major staff reductions here right after I made
> that commitment and now I'm having a hard time just trying to keep up with
> my (non-OFBiz) work here.

No problem, Adrian.  I had asked you to check for all calls to convertUom, and
add the product parameter where it makes sense.  As it turns out, there were
only a few calls, and none were product-specific.  (I was expecting calls in
order entry and the like, but UoMs are not handled there...)  So what I
thought might be time consuming turned out to be trivial.

And I understand the "changing priorities" thing...

Carl
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Adrian Crum]

David E. Jones wrote:
> Nice attitude Adrian. If this were true OFBiz would simply not exist at all.

It is an attitude based upon fact. We had this discussion about a year ago and a
number of list members stepped forward to agree with my assessment.

I've made contributions in the past and the scenario I described is exactly what
transpired.

I agree with you 100% that SVN commit access should be limited to a select few
people. I also believe those select few carry a responsibility to review and
commit submissions - regardless of who made those submissions or whether or not
it personally benefits the committer.

When one of the priviledged few says they will "just pick the ones I like the
best or think I can get done most quickly" they have failed in their responsibility.

-Adrian

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

And what responsibility would that be?

-David


Adrian Crum wrote:

> David E. Jones wrote:
>> Nice attitude Adrian. If this were true OFBiz would simply not exist at all.
>
> It is an attitude based upon fact. We had this discussion about a year ago and a
> number of list members stepped forward to agree with my assessment.
>
> I've made contributions in the past and the scenario I described is exactly what
> transpired.
>
> I agree with you 100% that SVN commit access should be limited to a select few
> people. I also believe those select few carry a responsibility to review and
> commit submissions - regardless of who made those submissions or whether or not
> it personally benefits the committer.
>
> When one of the priviledged few says they will "just pick the ones I like the
> best or think I can get done most quickly" they have failed in their responsibility.
>
> -Adrian
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

Adrian:
I have a Sourcforge acct that I can give you a branch under the
Contributions.
Yes this would make things more difficult, but the model has been set by
  Si.
This means I would have to run all the submission against the SVN to
make sure they worked.
if enough contribution are there, I will be glad to do this.


Adrian Crum sent the following on 4/7/06 8:17 AM:

> David E. Jones wrote:
>
>>Nice attitude Adrian. If this were true OFBiz would simply not exist at all.
>
>
> It is an attitude based upon fact. We had this discussion about a year ago and a
> number of list members stepped forward to agree with my assessment.
>
> I've made contributions in the past and the scenario I described is exactly what
> transpired.
>
> I agree with you 100% that SVN commit access should be limited to a select few
> people. I also believe those select few carry a responsibility to review and
> commit submissions - regardless of who made those submissions or whether or not
> it personally benefits the committer.
>
> When one of the priviledged few says they will "just pick the ones I like the
> best or think I can get done most quickly" they have failed in their responsibility.
>
> -Adrian
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[cjhowe]

BJ,
I have been waiting for that funtionality on
sourceforge (branch permissions).  I still don't see
it though.  I do see that functionality for CVS, is
that what you're talking about or could you point me
where I can find info to do that for SVN?

--- BJ Freeman <[hidden email]> wrote:

> Adrian:
> I have a Sourcforge acct that I can give you a
> branch under the
> Contributions.
> Yes this would make things more difficult, but the
> model has been set by
>   Si.
> This means I would have to run all the submission
> against the SVN to
> make sure they worked.
> if enough contribution are there, I will be glad to
> do this.
>
>
> Adrian Crum sent the following on 4/7/06 8:17 AM:
> > David E. Jones wrote:
> >
> >>Nice attitude Adrian. If this were true OFBiz
> would simply not exist at all.
> >
> >
> > It is an attitude based upon fact. We had this
> discussion about a year ago and a
> > number of list members stepped forward to agree
> with my assessment.
> >
> > I've made contributions in the past and the
> scenario I described is exactly what
> > transpired.
> >
> > I agree with you 100% that SVN commit access
> should be limited to a select few
> > people. I also believe those select few carry a
> responsibility to review and
> > commit submissions - regardless of who made those
> submissions or whether or not
> > it personally benefits the committer.
> >
> > When one of the priviledged few says they will
> "just pick the ones I like the
> > best or think I can get done most quickly" they
> have failed in their responsibility.
> >
> > -Adrian
> >
> >  
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
> >
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

will reply to you off line.

Chris Howe sent the following on 4/7/06 11:58 AM:

> BJ,
> I have been waiting for that funtionality on
> sourceforge (branch permissions).  I still don't see
> it though.  I do see that functionality for CVS, is
> that what you're talking about or could you point me
> where I can find info to do that for SVN?
>
> --- BJ Freeman <[hidden email]> wrote:
>
>
>>Adrian:
>>I have a Sourcforge acct that I can give you a
>>branch under the
>>Contributions.
>>Yes this would make things more difficult, but the
>>model has been set by
>>  Si.
>>This means I would have to run all the submission
>>against the SVN to
>>make sure they worked.
>>if enough contribution are there, I will be glad to
>>do this.
>>
>>
>>Adrian Crum sent the following on 4/7/06 8:17 AM:
>>
>>>David E. Jones wrote:
>>>
>>>
>>>>Nice attitude Adrian. If this were true OFBiz
>>
>>would simply not exist at all.
>>
>>>
>>>It is an attitude based upon fact. We had this
>>
>>discussion about a year ago and a
>>
>>>number of list members stepped forward to agree
>>
>>with my assessment.
>>
>>>I've made contributions in the past and the
>>
>>scenario I described is exactly what
>>
>>>transpired.
>>>
>>>I agree with you 100% that SVN commit access
>>
>>should be limited to a select few
>>
>>>people. I also believe those select few carry a
>>
>>responsibility to review and
>>
>>>commit submissions - regardless of who made those
>>
>>submissions or whether or not
>>
>>>it personally benefits the committer.
>>>
>>>When one of the priviledged few says they will
>>
>>"just pick the ones I like the
>>
>>>best or think I can get done most quickly" they
>>
>>have failed in their responsibility.
>>
>>>-Adrian
>>>
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

I've decided that we need this mod.  Please see
http://jira.undersunconsulting.com/browse/OFBIZ-826 for the full details.  
(The biggest change from what was originally described is that this is going
to be based on a parameter in catalog.properties.)

Comments and suggestions welcome...

Carl

On Monday, April 03, 2006 19:45, Carl Sopchak wrote:

> OK, I finally got my Data Model Resource Books on Saturday, and I see that
> the author suggests that different ordering UoM's are either different
> features, or even different products.  I'm not sure I agree with the
> different products view, but I was wondering if anyone has tried
> implementing multiple ordering UoM's as product features.  If so, I was
> wondering how well it worked for you, and how, specifically, they would get
> set up.  (Admittedly, I haven't spent a LOT of time on trying to figure
> this out yet, but I'd rather spend my time changing the order entry screens
> if needed...)
>
> The product my client sells is wood: 2x4's, 4x8's, plywood, etc.  You know,
> the stuff you build houses with.  In our view, a 2x4x8, is a 2x4x8, is a
> 2x4x8!  We'll be shipping the same pieces, whether they order 200 pieces,
> 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge "packages" you
> see stacked in your local home improvement store).  Further, if they order
> 1000 board feet, we may very well ship the 1067 BF in a unit.  (Other
> rounding-type issues may apply as well.)  If we have only one full unit,
> and a customer orders 100 pieces, we break the unit.  In other words,
> there's nothing special with the UoM's, except convenience (or habit of the
> customer) in ordering.
>
> So, for us, different UoM's are DEFINITELY NOT different products.  (Even
> the ream of paper example in the book doesn't fly well with me - thinking
> about boxes and pallets of reams of paper, but I'll let that slide for
> now...)  I'm not too sure how well ordering will work (particularly during
> the busy summer months) with UoM as a feature.
>
> One last question:  If we decide to do the order entry mod described in the
> original email, should we do it as part of OFBiz and submit a patch, or
> should we keep it as a local mod (since it seems against the data model
> apparently employed by OFBiz)?
>
> Any comments or suggestions would be most welcome.
>
> Thanks,
>
> Carl
>
> On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
> > Much to my surprise, OFBiz does not seem to "do" order quantities in
> > units of measure other than the stock keeping unit.  (I.e., you can't
> > order a "Box" of something when stock is kept in "Eaches".)  Someone,
> > please let me know if I'm wrong here!  Or, if anyone has made the mod on
> > a "custom" basis, please contact me off-list.
> >
> > Assuming I need to make this change, here is what I propose:
> >
> > 1) Add attributes to the Product entity: skuUom (stock keeping unit UoM),
> > and customerOrderUom (default customer order quantity UoM; I forsee a
> > supplierOrderUom in my future, too, but I'm not sure yet).
> > 2) Add the above fields to the Product Entry screen.  Validate that
> > either the two UoM's are equal, or that there are UomConversion records
> > to go between the two.
> > 3) Add attributes to the OrderItem entity:  quantityAsOrdered and
> > quantityAsOrderedUom.
> > 4) Change the entry of order line items so that the quantity that is
> > entered on the screen is saved in the quantityAsOrdered attribute, and
> > add a drop-down of units of measure, showing only those units of measure
> > which have a UomConversion record on file where the uomIdTo =
> > product.skuUom, with the default value being the
> > product.customerOrderUom, and the selection being saved in
> > quantityAsOrderedUom.  The quantityAsOrdered would be converted from the
> > quantityAsOrderedUom to the product.skuUom, and the result stored in
> > OrderItem.quantity.  (There may be a rounding issue here that convertUom
> > will have to address...)
> > 5) Change the display of order lines to show the quantityAsOrdered and
> > quantityAsOrderedUom instead of (or in addition to?) quantity and skuUom.
> >
> > Here are my questions:
> >
> > - Overall, does this make sense?  Comments / suggestions / etc.
> > welcome... - I haven't received my Data Modeling Resource Books yet (on
> > order...), so I'm assuming the entities mentioned above are the right
> > place to put the additional attributes.  Please correct me if I'm wrong.
> > - As for the "drop-down of UoMs" based on the product entered, this may
> > be a bit difficult on a web page due to the way web browsing works
> > (although I've seen "dynamic" pages that do similar things).  Is there a
> > standard way to handle such things in OFBiz?  Should I just display the
> > customerOrderUom, and supply a pop-up to pick from (based on the
> > productId)?  This does seems a bit awkward though, particularly for "high
> > volume" order entry.
> > - Although I'm sure I could find where everything needs to go, if anyone
> > would like to point me to specific things that would need changing
> > (particularly if I missed something), it would be most appreciated.
> >
> > Thanks in advance for the help and comments.
> >
> > Carl
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev