Auto-generating of BOMs from Virtual Product to Variants

[jonwimp]

Is there a way to have rule-based auto-generation of BOMs? Maybe this has already been done?

In general, I have a virtual product that can have thousands of variants. I'd like an automated
way to generate all the possible variants.

One aspect I'm gonna be looking at is rule-based auto-generation of variants' productId. This
shouldn't be difficult, and can easily be linked to the QuickAddVariants page (the checkboxes in
column "All"). If someone is already doing this, let me know so we can collaborate?

The bigger problem I have is the auto-generation of BOMs, the lack thereof rather.

Say I have virtual product Bicycle, and variants Bicycle-abcd, where abcd are variables. I'd like
variable 'a' to be the top-most in hierarchy and 'd' the last. For example, my bicycles could come
with different frame sizes 1 through 5, which will require different BOM components Frame1 to
Frame5. I'd want all variants Bicycle-1bcd to have a BOM component of Frame1, Bicycle-2bcd Frame2,
and so on.

Even a semi-automated process will be alright for now.

I'd suggest an enhancement to the EditProductBom screen. Add a function to list all variants,
search can be constrained by selection of (standard) features. This function can be copied from
"Lookup Variant Product" somehow. Allow "Copy BOM" to apply to a number of variants at once.

Any ideas?

Jonathon

[Scott Gray]

The Quick Add Variants already auto-generates ids you would just need to
alter the code to put the id together in the way you want.

For auto boms have a look at ManufacturingExampleData.xml, there is a
similar example at the bottom of the file to what you are after.  The
screen to play with is the one I incorrectly mentioned the other day,
Manufacturing -> Bill of Materials -> Manufacturing Rules.

Regards
Scott

Jonathon -- Improov wrote:

> Is there a way to have rule-based auto-generation of BOMs? Maybe this
> has already been done?
>
> In general, I have a virtual product that can have thousands of
> variants. I'd like an automated way to generate all the possible
> variants.
>
> One aspect I'm gonna be looking at is rule-based auto-generation of
> variants' productId. This shouldn't be difficult, and can easily be
> linked to the QuickAddVariants page (the checkboxes in column "All").
> If someone is already doing this, let me know so we can collaborate?
>
> The bigger problem I have is the auto-generation of BOMs, the lack
> thereof rather.
>
> Say I have virtual product Bicycle, and variants Bicycle-abcd, where
> abcd are variables. I'd like variable 'a' to be the top-most in
> hierarchy and 'd' the last. For example, my bicycles could come with
> different frame sizes 1 through 5, which will require different BOM
> components Frame1 to Frame5. I'd want all variants Bicycle-1bcd to
> have a BOM component of Frame1, Bicycle-2bcd Frame2, and so on.
>
> Even a semi-automated process will be alright for now.
>
> I'd suggest an enhancement to the EditProductBom screen. Add a
> function to list all variants, search can be constrained by selection
> of (standard) features. This function can be copied from "Lookup
> Variant Product" somehow. Allow "Copy BOM" to apply to a number of
> variants at once.
>
> Any ideas?
>
> Jonathon
>

[jonwimp]

Got it. Thanks, life saver! Will explore that and let you know. OFBiz looking better and better!

Jonathon

Scott Gray wrote:

> The Quick Add Variants already auto-generates ids you would just need to
> alter the code to put the id together in the way you want.
>
> For auto boms have a look at ManufacturingExampleData.xml, there is a
> similar example at the bottom of the file to what you are after.  The
> screen to play with is the one I incorrectly mentioned the other day,
> Manufacturing -> Bill of Materials -> Manufacturing Rules.
>
> Regards
> Scott
>
> Jonathon -- Improov wrote:
>> Is there a way to have rule-based auto-generation of BOMs? Maybe this
>> has already been done?
>>
>> In general, I have a virtual product that can have thousands of
>> variants. I'd like an automated way to generate all the possible
>> variants.
>>
>> One aspect I'm gonna be looking at is rule-based auto-generation of
>> variants' productId. This shouldn't be difficult, and can easily be
>> linked to the QuickAddVariants page (the checkboxes in column "All").
>> If someone is already doing this, let me know so we can collaborate?
>>
>> The bigger problem I have is the auto-generation of BOMs, the lack
>> thereof rather.
>>
>> Say I have virtual product Bicycle, and variants Bicycle-abcd, where
>> abcd are variables. I'd like variable 'a' to be the top-most in
>> hierarchy and 'd' the last. For example, my bicycles could come with
>> different frame sizes 1 through 5, which will require different BOM
>> components Frame1 to Frame5. I'd want all variants Bicycle-1bcd to
>> have a BOM component of Frame1, Bicycle-2bcd Frame2, and so on.
>>
>> Even a semi-automated process will be alright for now.
>>
>> I'd suggest an enhancement to the EditProductBom screen. Add a
>> function to list all variants, search can be constrained by selection
>> of (standard) features. This function can be copied from "Lookup
>> Variant Product" somehow. Allow "Copy BOM" to apply to a number of
>> variants at once.
>>
>> Any ideas?
>>
>> Jonathon
>>
>
>

[Scott Gray]

It's a beautiful concept and is one of things that got me excited when I
started looking at OFBiz.

Jonathon -- Improov wrote:

> Got it. Thanks, life saver! Will explore that and let you know. OFBiz
> looking better and better!
>
> Jonathon
>
> Scott Gray wrote:
>> The Quick Add Variants already auto-generates ids you would just need
>> to alter the code to put the id together in the way you want.
>>
>> For auto boms have a look at ManufacturingExampleData.xml, there is a
>> similar example at the bottom of the file to what you are after.  The
>> screen to play with is the one I incorrectly mentioned the other day,
>> Manufacturing -> Bill of Materials -> Manufacturing Rules.
>>
>> Regards
>> Scott
>>
>> Jonathon -- Improov wrote:
>>> Is there a way to have rule-based auto-generation of BOMs? Maybe
>>> this has already been done?
>>>
>>> In general, I have a virtual product that can have thousands of
>>> variants. I'd like an automated way to generate all the possible
>>> variants.
>>>
>>> One aspect I'm gonna be looking at is rule-based auto-generation of
>>> variants' productId. This shouldn't be difficult, and can easily be
>>> linked to the QuickAddVariants page (the checkboxes in column
>>> "All"). If someone is already doing this, let me know so we can
>>> collaborate?
>>>
>>> The bigger problem I have is the auto-generation of BOMs, the lack
>>> thereof rather.
>>>
>>> Say I have virtual product Bicycle, and variants Bicycle-abcd, where
>>> abcd are variables. I'd like variable 'a' to be the top-most in
>>> hierarchy and 'd' the last. For example, my bicycles could come with
>>> different frame sizes 1 through 5, which will require different BOM
>>> components Frame1 to Frame5. I'd want all variants Bicycle-1bcd to
>>> have a BOM component of Frame1, Bicycle-2bcd Frame2, and so on.
>>>
>>> Even a semi-automated process will be alright for now.
>>>
>>> I'd suggest an enhancement to the EditProductBom screen. Add a
>>> function to list all variants, search can be constrained by
>>> selection of (standard) features. This function can be copied from
>>> "Lookup Variant Product" somehow. Allow "Copy BOM" to apply to a
>>> number of variants at once.
>>>
>>> Any ideas?
>>>
>>> Jonathon
>>>
>>
>>
>
>

[cjhowe]

While that is one avenue to pursue with your
productId, and will certainly make things easier now,
you may wish to consider the long term repercussions
of such a convention.

The productId in OFBiz is largely used as a surrogate
key.  Adding intelligence to this key, while supported
OOTB, really limits your options later for
discontinuation of products, changing versions of the
product, similar named productIds, marketing etc.   If
instead you allow the productId to have no meaning and
push the intelligence onto an alias, or internal name,
etc, you maintain your ability to control the naming
convention as your client's business changes in the
future.  There is the trade-off as this is slightly
more difficult and not OOTB.

Regards,
Chris
--- Jonathon -- Improov <[hidden email]> wrote:

> Got it. Thanks, life saver! Will explore that and
> let you know. OFBiz looking better and better!
>
> Jonathon
>
> Scott Gray wrote:
> > The Quick Add Variants already auto-generates ids
> you would just need to
> > alter the code to put the id together in the way
> you want.
> >
> > For auto boms have a look at
> ManufacturingExampleData.xml, there is a
> > similar example at the bottom of the file to what
> you are after.  The
> > screen to play with is the one I incorrectly
> mentioned the other day,
> > Manufacturing -> Bill of Materials ->
> Manufacturing Rules.
> >
> > Regards
> > Scott
> >
> > Jonathon -- Improov wrote:
> >> Is there a way to have rule-based auto-generation
> of BOMs? Maybe this
> >> has already been done?
> >>
> >> In general, I have a virtual product that can
> have thousands of
> >> variants. I'd like an automated way to generate
> all the possible
> >> variants.
> >>
> >> One aspect I'm gonna be looking at is rule-based
> auto-generation of
> >> variants' productId. This shouldn't be difficult,
> and can easily be
> >> linked to the QuickAddVariants page (the
> checkboxes in column "All").
> >> If someone is already doing this, let me know so
> we can collaborate?
> >>
> >> The bigger problem I have is the auto-generation
> of BOMs, the lack
> >> thereof rather.
> >>
> >> Say I have virtual product Bicycle, and variants
> Bicycle-abcd, where
> >> abcd are variables. I'd like variable 'a' to be
> the top-most in
> >> hierarchy and 'd' the last. For example, my
> bicycles could come with
> >> different frame sizes 1 through 5, which will
> require different BOM
> >> components Frame1 to Frame5. I'd want all
> variants Bicycle-1bcd to
> >> have a BOM component of Frame1, Bicycle-2bcd
> Frame2, and so on.
> >>
> >> Even a semi-automated process will be alright for
> now.
> >>
> >> I'd suggest an enhancement to the EditProductBom
> screen. Add a
> >> function to list all variants, search can be
> constrained by selection
> >> of (standard) features. This function can be
> copied from "Lookup
> >> Variant Product" somehow. Allow "Copy BOM" to
> apply to a number of
> >> variants at once.
> >>
> >> Any ideas?
> >>
> >> Jonathon
> >>
> >
> >
>
>

[Scott Gray]

Personally I can't see the harm myself.  I know from personal experience
that having memorable productId's can dramatically ease the day to day
the usability of most of systems not just OFBiz.  Do you have any
examples of where a memorable productId would cause a problem?

I can see that it may not be suitable for companies with huge product
ranges or short life cycles, but if your product range is pretty
constant it can make life much easier.

Regards
Scott

Chris Howe wrote:

> While that is one avenue to pursue with your
> productId, and will certainly make things easier now,
> you may wish to consider the long term repercussions
> of such a convention.
>
> The productId in OFBiz is largely used as a surrogate
> key.  Adding intelligence to this key, while supported
> OOTB, really limits your options later for
> discontinuation of products, changing versions of the
> product, similar named productIds, marketing etc.   If
> instead you allow the productId to have no meaning and
> push the intelligence onto an alias, or internal name,
> etc, you maintain your ability to control the naming
> convention as your client's business changes in the
> future.  There is the trade-off as this is slightly
> more difficult and not OOTB.
>
> Regards,
> Chris
> --- Jonathon -- Improov <[hidden email]> wrote:
>
>  
>> Got it. Thanks, life saver! Will explore that and
>> let you know. OFBiz looking better and better!
>>
>> Jonathon
>>
>> Scott Gray wrote:
>>    
>>> The Quick Add Variants already auto-generates ids
>>>      
>> you would just need to
>>    
>>> alter the code to put the id together in the way
>>>      
>> you want.
>>    
>>> For auto boms have a look at
>>>      
>> ManufacturingExampleData.xml, there is a
>>    
>>> similar example at the bottom of the file to what
>>>      
>> you are after.  The
>>    
>>> screen to play with is the one I incorrectly
>>>      
>> mentioned the other day,
>>    
>>> Manufacturing -> Bill of Materials ->
>>>      
>> Manufacturing Rules.
>>    
>>> Regards
>>> Scott
>>>
>>> Jonathon -- Improov wrote:
>>>      
>>>> Is there a way to have rule-based auto-generation
>>>>        
>> of BOMs? Maybe this
>>    
>>>> has already been done?
>>>>
>>>> In general, I have a virtual product that can
>>>>        
>> have thousands of
>>    
>>>> variants. I'd like an automated way to generate
>>>>        
>> all the possible
>>    
>>>> variants.
>>>>
>>>> One aspect I'm gonna be looking at is rule-based
>>>>        
>> auto-generation of
>>    
>>>> variants' productId. This shouldn't be difficult,
>>>>        
>> and can easily be
>>    
>>>> linked to the QuickAddVariants page (the
>>>>        
>> checkboxes in column "All").
>>    
>>>> If someone is already doing this, let me know so
>>>>        
>> we can collaborate?
>>    
>>>> The bigger problem I have is the auto-generation
>>>>        
>> of BOMs, the lack
>>    
>>>> thereof rather.
>>>>
>>>> Say I have virtual product Bicycle, and variants
>>>>        
>> Bicycle-abcd, where
>>    
>>>> abcd are variables. I'd like variable 'a' to be
>>>>        
>> the top-most in
>>    
>>>> hierarchy and 'd' the last. For example, my
>>>>        
>> bicycles could come with
>>    
>>>> different frame sizes 1 through 5, which will
>>>>        
>> require different BOM
>>    
>>>> components Frame1 to Frame5. I'd want all
>>>>        
>> variants Bicycle-1bcd to
>>    
>>>> have a BOM component of Frame1, Bicycle-2bcd
>>>>        
>> Frame2, and so on.
>>    
>>>> Even a semi-automated process will be alright for
>>>>        
>> now.
>>    
>>>> I'd suggest an enhancement to the EditProductBom
>>>>        
>> screen. Add a
>>    
>>>> function to list all variants, search can be
>>>>        
>> constrained by selection
>>    
>>>> of (standard) features. This function can be
>>>>        
>> copied from "Lookup
>>    
>>>> Variant Product" somehow. Allow "Copy BOM" to
>>>>        
>> apply to a number of
>>    
>>>> variants at once.
>>>>
>>>> Any ideas?
>>>>
>>>> Jonathon
>>>>
>>>>        
>>>      
>>    
>
>
>  

[Jacopo Cappellato]

Jonathon,

Scott's advices are correct.
I'd like to mention that:

* if you have a virtual product with a BOM and the product has some
variants associated to it without BOM, the system will use the BOM of
the virtual product: there is no need to duplicate the BOMs from the
virtual to the variants; or you can only create the BOM of the variants
products that have a BOM different from that of their virtual

* virtual BOM are also supported: if you have a virtual product T-SHIRT
with selectable features RED, YELLOW and you create as a component for
its BOM another virtual product, CLOTH, with the same selectable
features (RED, YELLOW) and then create the variants for the CLOTH and
for the T-SHIRT, you have implemented a virtual BOM. When you'll create
a production run (or you'll run a BOM simulation) for one of the
T-SHIRT's variant, the system will automatically select the right
variant CLOTH.

* what I have described above are the 'implicit' BOM rules; as Scott
said you can also create 'explicit' rules using the Manufacturing ->
Bill of Materials -> Manufacturing Rules page; for example component
inclusion/exclusion/substitution rules can be implemented as explicit
rules; however, that part of the system should probably need a few
cleanups or improvements

There is more than this, but I don't want to add too many details...

Happy testing,

Jacopo


Scott Gray wrote:

> It's a beautiful concept and is one of things that got me excited when I
> started looking at OFBiz.
>
> Jonathon -- Improov wrote:
>> Got it. Thanks, life saver! Will explore that and let you know. OFBiz
>> looking better and better!
>>
>> Jonathon
>>
>> Scott Gray wrote:
>>> The Quick Add Variants already auto-generates ids you would just need
>>> to alter the code to put the id together in the way you want.
>>>
>>> For auto boms have a look at ManufacturingExampleData.xml, there is a
>>> similar example at the bottom of the file to what you are after.  The
>>> screen to play with is the one I incorrectly mentioned the other day,
>>> Manufacturing -> Bill of Materials -> Manufacturing Rules.
>>>
>>> Regards
>>> Scott
>>>
>>> Jonathon -- Improov wrote:
>>>> Is there a way to have rule-based auto-generation of BOMs? Maybe
>>>> this has already been done?
>>>>
>>>> In general, I have a virtual product that can have thousands of
>>>> variants. I'd like an automated way to generate all the possible
>>>> variants.
>>>>
>>>> One aspect I'm gonna be looking at is rule-based auto-generation of
>>>> variants' productId. This shouldn't be difficult, and can easily be
>>>> linked to the QuickAddVariants page (the checkboxes in column
>>>> "All"). If someone is already doing this, let me know so we can
>>>> collaborate?
>>>>
>>>> The bigger problem I have is the auto-generation of BOMs, the lack
>>>> thereof rather.
>>>>
>>>> Say I have virtual product Bicycle, and variants Bicycle-abcd, where
>>>> abcd are variables. I'd like variable 'a' to be the top-most in
>>>> hierarchy and 'd' the last. For example, my bicycles could come with
>>>> different frame sizes 1 through 5, which will require different BOM
>>>> components Frame1 to Frame5. I'd want all variants Bicycle-1bcd to
>>>> have a BOM component of Frame1, Bicycle-2bcd Frame2, and so on.
>>>>
>>>> Even a semi-automated process will be alright for now.
>>>>
>>>> I'd suggest an enhancement to the EditProductBom screen. Add a
>>>> function to list all variants, search can be constrained by
>>>> selection of (standard) features. This function can be copied from
>>>> "Lookup Variant Product" somehow. Allow "Copy BOM" to apply to a
>>>> number of variants at once.
>>>>
>>>> Any ideas?
>>>>
>>>> Jonathon
>>>>
>>>
>>>
>>
>>

[jonwimp]

Scott,

Currently, it seems Manufacturing Rules does only substitution (including quantity specification)
of Virtual Subassembly components with Real (Variant) Subassembly components, based on product
feature encountered. Is this correct?

Can I specify a Manufacturing Rule that joins a product feature (say "Fully-pumped Wheels" or
"Half-pumped Wheels") to a Routing Task instead of simply to dictate quantity? Say I have 2
different Routing Tasks with different Fixed Assets (machines) to handle the pumping of wheels. I
could have a machine (fixed asset) called "Pump it all up" and another called "Pump it some".

I know, it's not often we have an air-pump machine that can only handle a single pressure setting.
But think about this as efficient labor/resource management. I could have a skilled employee
pumping wheels to variable levels of pressure, and another blindly pumping wheels to full pressure.

This linkage to Routing Task may or may not be critical. My boss will tell me. Can you give a
quick "Yes, OFBiz can do it" answer for now?

Thanks.

Jonathon

Jonathon -- Improov wrote:

> Got it. Thanks, life saver! Will explore that and let you know. OFBiz
> looking better and better!
>
> Jonathon
>
> Scott Gray wrote:
>> The Quick Add Variants already auto-generates ids you would just need
>> to alter the code to put the id together in the way you want.
>>
>> For auto boms have a look at ManufacturingExampleData.xml, there is a
>> similar example at the bottom of the file to what you are after.  The
>> screen to play with is the one I incorrectly mentioned the other day,
>> Manufacturing -> Bill of Materials -> Manufacturing Rules.
>>
>> Regards
>> Scott
>>
>> Jonathon -- Improov wrote:
>>> Is there a way to have rule-based auto-generation of BOMs? Maybe this
>>> has already been done?
>>>
>>> In general, I have a virtual product that can have thousands of
>>> variants. I'd like an automated way to generate all the possible
>>> variants.
>>>
>>> One aspect I'm gonna be looking at is rule-based auto-generation of
>>> variants' productId. This shouldn't be difficult, and can easily be
>>> linked to the QuickAddVariants page (the checkboxes in column "All").
>>> If someone is already doing this, let me know so we can collaborate?
>>>
>>> The bigger problem I have is the auto-generation of BOMs, the lack
>>> thereof rather.
>>>
>>> Say I have virtual product Bicycle, and variants Bicycle-abcd, where
>>> abcd are variables. I'd like variable 'a' to be the top-most in
>>> hierarchy and 'd' the last. For example, my bicycles could come with
>>> different frame sizes 1 through 5, which will require different BOM
>>> components Frame1 to Frame5. I'd want all variants Bicycle-1bcd to
>>> have a BOM component of Frame1, Bicycle-2bcd Frame2, and so on.
>>>
>>> Even a semi-automated process will be alright for now.
>>>
>>> I'd suggest an enhancement to the EditProductBom screen. Add a
>>> function to list all variants, search can be constrained by selection
>>> of (standard) features. This function can be copied from "Lookup
>>> Variant Product" somehow. Allow "Copy BOM" to apply to a number of
>>> variants at once.
>>>
>>> Any ideas?
>>>
>>> Jonathon
>>>
>>
>>
>
>

[Scott Gray]

The only answer I can give at the moment is "don't know".  Jacopo may be
able to answer, I only skimmed over this stuff to make sure it could do
what I needed and am yet to actually use it.

Regards
Scott

Jonathon -- Improov wrote:

> Scott,
>
> Currently, it seems Manufacturing Rules does only substitution
> (including quantity specification) of Virtual Subassembly components
> with Real (Variant) Subassembly components, based on product feature
> encountered. Is this correct?
>
> Can I specify a Manufacturing Rule that joins a product feature (say
> "Fully-pumped Wheels" or "Half-pumped Wheels") to a Routing Task
> instead of simply to dictate quantity? Say I have 2 different Routing
> Tasks with different Fixed Assets (machines) to handle the pumping of
> wheels. I could have a machine (fixed asset) called "Pump it all up"
> and another called "Pump it some".
>
> I know, it's not often we have an air-pump machine that can only
> handle a single pressure setting. But think about this as efficient
> labor/resource management. I could have a skilled employee pumping
> wheels to variable levels of pressure, and another blindly pumping
> wheels to full pressure.
>
> This linkage to Routing Task may or may not be critical. My boss will
> tell me. Can you give a quick "Yes, OFBiz can do it" answer for now?
>
> Thanks.
>
> Jonathon
>
> Jonathon -- Improov wrote:
>> Got it. Thanks, life saver! Will explore that and let you know. OFBiz
>> looking better and better!
>>
>> Jonathon
>>
>> Scott Gray wrote:
>>> The Quick Add Variants already auto-generates ids you would just
>>> need to alter the code to put the id together in the way you want.
>>>
>>> For auto boms have a look at ManufacturingExampleData.xml, there is
>>> a similar example at the bottom of the file to what you are after.  
>>> The screen to play with is the one I incorrectly mentioned the other
>>> day, Manufacturing -> Bill of Materials -> Manufacturing Rules.
>>>
>>> Regards
>>> Scott
>>>
>>> Jonathon -- Improov wrote:
>>>> Is there a way to have rule-based auto-generation of BOMs? Maybe
>>>> this has already been done?
>>>>
>>>> In general, I have a virtual product that can have thousands of
>>>> variants. I'd like an automated way to generate all the possible
>>>> variants.
>>>>
>>>> One aspect I'm gonna be looking at is rule-based auto-generation of
>>>> variants' productId. This shouldn't be difficult, and can easily be
>>>> linked to the QuickAddVariants page (the checkboxes in column
>>>> "All"). If someone is already doing this, let me know so we can
>>>> collaborate?
>>>>
>>>> The bigger problem I have is the auto-generation of BOMs, the lack
>>>> thereof rather.
>>>>
>>>> Say I have virtual product Bicycle, and variants Bicycle-abcd,
>>>> where abcd are variables. I'd like variable 'a' to be the top-most
>>>> in hierarchy and 'd' the last. For example, my bicycles could come
>>>> with different frame sizes 1 through 5, which will require
>>>> different BOM components Frame1 to Frame5. I'd want all variants
>>>> Bicycle-1bcd to have a BOM component of Frame1, Bicycle-2bcd
>>>> Frame2, and so on.
>>>>
>>>> Even a semi-automated process will be alright for now.
>>>>
>>>> I'd suggest an enhancement to the EditProductBom screen. Add a
>>>> function to list all variants, search can be constrained by
>>>> selection of (standard) features. This function can be copied from
>>>> "Lookup Variant Product" somehow. Allow "Copy BOM" to apply to a
>>>> number of variants at once.
>>>>
>>>> Any ideas?
>>>>
>>>> Jonathon
>>>>
>>>
>>>
>>
>>
>
>

[cjhowe]

This is "big picture" discussion and certainly not
cookie cutter, so there are pros and cons on both
sides.  I take the approach that being the programmer,
you have the capability to provide your company or
your client's company the capability to not let
database theory requirements get in the way of them
running their business.

As far as making life easier, you can still do lookups
based on aliases and treat them as if they are unique,
as they certainly need to be unique for the date
(think getProductNameForDate service instead of
getPartyNameForDate).  The burden should be placed on
the programmer to make this seamless, not on the
business to adjust to the peculiarities.

From a competitive perspective, the first potential
problem with using the automated intelligence
productId as the glue to hold together your different
product data is the scenario where a competitor comes
along, is more successful in gaining the mind share of
the sequence of the components for the intelligence
productId.  Their 2KBL34M37 is the equivalent to your
B730HM250, but you carry a different product with ID
2KBL34M37.  You're both in the same industry and
customers mistakenly order your competitors product Id
thinking that you are perhaps a distributor of their
product or them of yours.

Now no solution can prevent this from happening the
first time or even perhaps the tenth time.  However
once you realize the problem, an intelligent primary
key prevents you from taking action without completely
overhauling your database and making assumptions about
your historical data which is perhaps inaccurate.  An
alias primary key lets you come out with a "new"
product line renaming everything under the sun without
changing the underlying product data.

Just to provide a real world business story behind
this, productId naming conventions happen to be an
important consideration with me as I'm in an industry
where manufacturers consistently overlap their
productIds and brand names don't really get plastered
into the heads of the people ordering the product
(medical supplies).  A hospital could be ordering a
"6002" and be meaning to order a diaper or they could
be meaning to order a cardiac catheter surgical prep
kit or a bone saw.  Those three items from the
manufacturers perspective are in diverse enough fields
to never recognize that there is a conflict with
productId.  However, down the supply chain a
distributor is handling all three and perhaps losing
sales for the manufacturer because of their inability
to clarify the end customer's needs.

You may not need to deal with these considerations
(much larger and successful companies have chosen not
to).  But you should do yourself a favor and take the
short amount of time to consider it now and weigh that
against what you end up being locked into.  It's no
skin off my nose if you decide the effort to implement
such a convention isn't worth the flexibility gained
later ( unless you're a medical supply manufacturer
:-) )


Regards,
Chris

--- Scott Gray <[hidden email]> wrote:

> Personally I can't see the harm myself.  I know from
> personal experience
> that having memorable productId's can dramatically
> ease the day to day
> the usability of most of systems not just OFBiz.  Do
> you have any
> examples of where a memorable productId would cause
> a problem?
>
> I can see that it may not be suitable for companies
> with huge product
> ranges or short life cycles, but if your product
> range is pretty
> constant it can make life much easier.
>
> Regards
> Scott
>
> Chris Howe wrote:
> > While that is one avenue to pursue with your
> > productId, and will certainly make things easier
> now,
> > you may wish to consider the long term
> repercussions
> > of such a convention.
> >
> > The productId in OFBiz is largely used as a
> surrogate
> > key.  Adding intelligence to this key, while
> supported
> > OOTB, really limits your options later for
> > discontinuation of products, changing versions of
> the
> > product, similar named productIds, marketing etc.
>  If
> > instead you allow the productId to have no meaning
> and
> > push the intelligence onto an alias, or internal
> name,
> > etc, you maintain your ability to control the
> naming
> > convention as your client's business changes in
> the
> > future.  There is the trade-off as this is
> slightly
> > more difficult and not OOTB.
> >
> > Regards,
> > Chris
> > --- Jonathon -- Improov <[hidden email]> wrote:
> >
> >  
> >> Got it. Thanks, life saver! Will explore that and
> >> let you know. OFBiz looking better and better!
> >>
> >> Jonathon
> >>
> >> Scott Gray wrote:
> >>    
> >>> The Quick Add Variants already auto-generates
> ids
> >>>      
> >> you would just need to
> >>    
> >>> alter the code to put the id together in the way
> >>>      
> >> you want.
> >>    
> >>> For auto boms have a look at
> >>>      
> >> ManufacturingExampleData.xml, there is a
> >>    
> >>> similar example at the bottom of the file to
> what
> >>>      
> >> you are after.  The
> >>    
> >>> screen to play with is the one I incorrectly
> >>>      
> >> mentioned the other day,
> >>    
> >>> Manufacturing -> Bill of Materials ->
> >>>      
> >> Manufacturing Rules.
> >>    
> >>> Regards
> >>> Scott
> >>>
> >>> Jonathon -- Improov wrote:
> >>>      
> >>>> Is there a way to have rule-based
> auto-generation
> >>>>        
> >> of BOMs? Maybe this
> >>    
> >>>> has already been done?
> >>>>
> >>>> In general, I have a virtual product that can
> >>>>        
> >> have thousands of
> >>    
> >>>> variants. I'd like an automated way to generate
> >>>>        
> >> all the possible
> >>    
> >>>> variants.
> >>>>
> >>>> One aspect I'm gonna be looking at is
> rule-based
> >>>>        
> >> auto-generation of
> >>    
> >>>> variants' productId. This shouldn't be
> difficult,
> >>>>        
> >> and can easily be
> >>    
> >>>> linked to the QuickAddVariants page (the
> >>>>        
> >> checkboxes in column "All").
> >>    
> >>>> If someone is already doing this, let me know
> so
> >>>>        
> >> we can collaborate?
> >>    
> >>>> The bigger problem I have is the
> auto-generation
> >>>>        
> >> of BOMs, the lack
> >>    
> >>>> thereof rather.
> >>>>
> >>>> Say I have virtual product Bicycle, and
> variants
> >>>>        
> >> Bicycle-abcd, where
> >>    
> >>>> abcd are variables. I'd like variable 'a' to be
> >>>>        
> >> the top-most in
> >>    
> >>>> hierarchy and 'd' the last. For example, my
> >>>>        
> >> bicycles could come with
> >>    
> >>>> different frame sizes 1 through 5, which will
> >>>>        
> >> require different BOM
> >>    
> >>>> components Frame1 to Frame5. I'd want all
> >>>>        
> >> variants Bicycle-1bcd to
> >>    
> >>>> have a BOM component of Frame1, Bicycle-2bcd
> >>>>        
> >> Frame2, and so on.
> >>    
> >>>> Even a semi-automated process will be alright
> for
> >>>>        
> >> now.
> >>    
> >>>> I'd suggest an enhancement to the
> EditProductBom
> >>>>        
> >> screen. Add a
> >>    
> >>>> function to list all variants, search can be
> >>>>        
> >> constrained by selection
> >>    
> >>>> of (standard) features. This function can be
> >>>>        
> >> copied from "Lookup
> >>    
> >>>> Variant Product" somehow. Allow "Copy BOM" to
> >>>>        
> >> apply to a number of
> >>    
> >>>> variants at once.
> >>>>
> >>>> Any ideas?
> >>>>
> >>>> Jonathon
> >>>>
> >>>>        
> >>>      
> >>    
> >
> >
> >  
>
>

[jonwimp]

Jacopo,

Nice! So, with your implicit rules, I don't even have to touch the Manufacturing Rules.

Take the example ManufacturingExampleData.xml Scott pointed out. I can actually delete the 2 rules
R01 and R02 and it'll all still work. R01 is substitutes WG-COVER-B for WG-COVER if feature is
COLOR:Black, correspondingly for R02 dealing with WG-COVER-S (Silver).

And to further delete rules R03 and R04, I can:

1. Create virtual product WG-WHEELBASE, and variants WG-WHEELBASE-3 and
    WG-WHEELBASE-4 (complete with selectable features for WG-WHEELBASE and
    distinguishing features for variants).

2. Create BOM for WG-WHEELBASE-3 with 3 units of WG-WHEEL-STD; 4 for
    WG-WHEELBASE-4.

3. Remove WG-WHEEL-STD from BOM of WG-FRAME

4. Add WG-WHEELBASE (quantity 1) to BOM of WG-FRAME

Works!

Did you do all these, Jacopo? By the way,
http://ofbizwiki.go-integral.com/Wiki.jsp?page=Manufacturing is down.

Jonathon

Jacopo Cappellato wrote:

> Jonathon,
>
> Scott's advices are correct.
> I'd like to mention that:
>
> * if you have a virtual product with a BOM and the product has some
> variants associated to it without BOM, the system will use the BOM of
> the virtual product: there is no need to duplicate the BOMs from the
> virtual to the variants; or you can only create the BOM of the variants
> products that have a BOM different from that of their virtual
>
> * virtual BOM are also supported: if you have a virtual product T-SHIRT
> with selectable features RED, YELLOW and you create as a component for
> its BOM another virtual product, CLOTH, with the same selectable
> features (RED, YELLOW) and then create the variants for the CLOTH and
> for the T-SHIRT, you have implemented a virtual BOM. When you'll create
> a production run (or you'll run a BOM simulation) for one of the
> T-SHIRT's variant, the system will automatically select the right
> variant CLOTH.
>
> * what I have described above are the 'implicit' BOM rules; as Scott
> said you can also create 'explicit' rules using the Manufacturing ->
> Bill of Materials -> Manufacturing Rules page; for example component
> inclusion/exclusion/substitution rules can be implemented as explicit
> rules; however, that part of the system should probably need a few
> cleanups or improvements
>
> There is more than this, but I don't want to add too many details...
>
> Happy testing,
>
> Jacopo

[Scott Gray]

Good points so I guess it depends on the industry, but knowing an id
versus using a look up everytime you deal your products makes a big
difference to me.

Regards
Scott

Chris Howe wrote:

> This is "big picture" discussion and certainly not
> cookie cutter, so there are pros and cons on both
> sides.  I take the approach that being the programmer,
> you have the capability to provide your company or
> your client's company the capability to not let
> database theory requirements get in the way of them
> running their business.
>
> As far as making life easier, you can still do lookups
> based on aliases and treat them as if they are unique,
> as they certainly need to be unique for the date
> (think getProductNameForDate service instead of
> getPartyNameForDate).  The burden should be placed on
> the programmer to make this seamless, not on the
> business to adjust to the peculiarities.
>
> >From a competitive perspective, the first potential
> problem with using the automated intelligence
> productId as the glue to hold together your different
> product data is the scenario where a competitor comes
> along, is more successful in gaining the mind share of
> the sequence of the components for the intelligence
> productId.  Their 2KBL34M37 is the equivalent to your
> B730HM250, but you carry a different product with ID
> 2KBL34M37.  You're both in the same industry and
> customers mistakenly order your competitors product Id
> thinking that you are perhaps a distributor of their
> product or them of yours.
>
> Now no solution can prevent this from happening the
> first time or even perhaps the tenth time.  However
> once you realize the problem, an intelligent primary
> key prevents you from taking action without completely
> overhauling your database and making assumptions about
> your historical data which is perhaps inaccurate.  An
> alias primary key lets you come out with a "new"
> product line renaming everything under the sun without
> changing the underlying product data.
>
> Just to provide a real world business story behind
> this, productId naming conventions happen to be an
> important consideration with me as I'm in an industry
> where manufacturers consistently overlap their
> productIds and brand names don't really get plastered
> into the heads of the people ordering the product
> (medical supplies).  A hospital could be ordering a
> "6002" and be meaning to order a diaper or they could
> be meaning to order a cardiac catheter surgical prep
> kit or a bone saw.  Those three items from the
> manufacturers perspective are in diverse enough fields
> to never recognize that there is a conflict with
> productId.  However, down the supply chain a
> distributor is handling all three and perhaps losing
> sales for the manufacturer because of their inability
> to clarify the end customer's needs.
>
> You may not need to deal with these considerations
> (much larger and successful companies have chosen not
> to).  But you should do yourself a favor and take the
> short amount of time to consider it now and weigh that
> against what you end up being locked into.  It's no
> skin off my nose if you decide the effort to implement
> such a convention isn't worth the flexibility gained
> later ( unless you're a medical supply manufacturer
> :-) )
>
>
> Regards,
> Chris
>
> --- Scott Gray <[hidden email]> wrote:
>
>  
>> Personally I can't see the harm myself.  I know from
>> personal experience
>> that having memorable productId's can dramatically
>> ease the day to day
>> the usability of most of systems not just OFBiz.  Do
>> you have any
>> examples of where a memorable productId would cause
>> a problem?
>>
>> I can see that it may not be suitable for companies
>> with huge product
>> ranges or short life cycles, but if your product
>> range is pretty
>> constant it can make life much easier.
>>
>> Regards
>> Scott
>>
>> Chris Howe wrote:
>>    
>>> While that is one avenue to pursue with your
>>> productId, and will certainly make things easier
>>>      
>> now,
>>    
>>> you may wish to consider the long term
>>>      
>> repercussions
>>    
>>> of such a convention.
>>>
>>> The productId in OFBiz is largely used as a
>>>      
>> surrogate
>>    
>>> key.  Adding intelligence to this key, while
>>>      
>> supported
>>    
>>> OOTB, really limits your options later for
>>> discontinuation of products, changing versions of
>>>      
>> the
>>    
>>> product, similar named productIds, marketing etc.
>>>      
>>  If
>>    
>>> instead you allow the productId to have no meaning
>>>      
>> and
>>    
>>> push the intelligence onto an alias, or internal
>>>      
>> name,
>>    
>>> etc, you maintain your ability to control the
>>>      
>> naming
>>    
>>> convention as your client's business changes in
>>>      
>> the
>>    
>>> future.  There is the trade-off as this is
>>>      
>> slightly
>>    
>>> more difficult and not OOTB.
>>>
>>> Regards,
>>> Chris
>>> --- Jonathon -- Improov <[hidden email]> wrote:
>>>
>>>  
>>>      
>>>> Got it. Thanks, life saver! Will explore that and
>>>> let you know. OFBiz looking better and better!
>>>>
>>>> Jonathon
>>>>
>>>> Scott Gray wrote:
>>>>    
>>>>        
>>>>> The Quick Add Variants already auto-generates
>>>>>          
>> ids
>>    
>>>>>      
>>>>>          
>>>> you would just need to
>>>>    
>>>>        
>>>>> alter the code to put the id together in the way
>>>>>      
>>>>>          
>>>> you want.
>>>>    
>>>>        
>>>>> For auto boms have a look at
>>>>>      
>>>>>          
>>>> ManufacturingExampleData.xml, there is a
>>>>    
>>>>        
>>>>> similar example at the bottom of the file to
>>>>>          
>> what
>>    
>>>>>      
>>>>>          
>>>> you are after.  The
>>>>    
>>>>        
>>>>> screen to play with is the one I incorrectly
>>>>>      
>>>>>          
>>>> mentioned the other day,
>>>>    
>>>>        
>>>>> Manufacturing -> Bill of Materials ->
>>>>>      
>>>>>          
>>>> Manufacturing Rules.
>>>>    
>>>>        
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> Jonathon -- Improov wrote:
>>>>>      
>>>>>          
>>>>>> Is there a way to have rule-based
>>>>>>            
>> auto-generation
>>    
>>>>>>        
>>>>>>            
>>>> of BOMs? Maybe this
>>>>    
>>>>        
>>>>>> has already been done?
>>>>>>
>>>>>> In general, I have a virtual product that can
>>>>>>        
>>>>>>            
>>>> have thousands of
>>>>    
>>>>        
>>>>>> variants. I'd like an automated way to generate
>>>>>>        
>>>>>>            
>>>> all the possible
>>>>    
>>>>        
>>>>>> variants.
>>>>>>
>>>>>> One aspect I'm gonna be looking at is
>>>>>>            
>> rule-based
>>    
>>>>>>        
>>>>>>            
>>>> auto-generation of
>>>>    
>>>>        
>>>>>> variants' productId. This shouldn't be
>>>>>>            
>> difficult,
>>    
>>>>>>        
>>>>>>            
>>>> and can easily be
>>>>    
>>>>        
>>>>>> linked to the QuickAddVariants page (the
>>>>>>        
>>>>>>            
>>>> checkboxes in column "All").
>>>>    
>>>>        
>>>>>> If someone is already doing this, let me know
>>>>>>            
>> so
>>    
>>>>>>        
>>>>>>            
>>>> we can collaborate?
>>>>    
>>>>        
>>>>>> The bigger problem I have is the
>>>>>>            
>> auto-generation
>>    
>>>>>>        
>>>>>>            
>>>> of BOMs, the lack
>>>>    
>>>>        
>>>>>> thereof rather.
>>>>>>
>>>>>> Say I have virtual product Bicycle, and
>>>>>>            
>> variants
>>    
>>>>>>        
>>>>>>            
>>>> Bicycle-abcd, where
>>>>    
>>>>        
>>>>>> abcd are variables. I'd like variable 'a' to be
>>>>>>        
>>>>>>            
>>>> the top-most in
>>>>    
>>>>        
>>>>>> hierarchy and 'd' the last. For example, my
>>>>>>        
>>>>>>            
>>>> bicycles could come with
>>>>    
>>>>        
>>>>>> different frame sizes 1 through 5, which will
>>>>>>        
>>>>>>            
>>>> require different BOM
>>>>    
>>>>        
>>>>>> components Frame1 to Frame5. I'd want all
>>>>>>        
>>>>>>            
>>>> variants Bicycle-1bcd to
>>>>    
>>>>        
>>>>>> have a BOM component of Frame1, Bicycle-2bcd
>>>>>>        
>>>>>>            
>>>> Frame2, and so on.
>>>>    
>>>>        
>>>>>> Even a semi-automated process will be alright
>>>>>>            
>> for
>>    
>>>>>>        
>>>>>>            
>>>> now.
>>>>    
>>>>        
>>>>>> I'd suggest an enhancement to the
>>>>>>            
>> EditProductBom
>>    
>>>>>>        
>>>>>>            
>>>> screen. Add a
>>>>    
>>>>        
>>>>>> function to list all variants, search can be
>>>>>>        
>>>>>>            
>>>> constrained by selection
>>>>    
>>>>        
>>>>>> of (standard) features. This function can be
>>>>>>        
>>>>>>            
>>>> copied from "Lookup
>>>>    
>>>>        
>>>>>> Variant Product" somehow. Allow "Copy BOM" to
>>>>>>        
>>>>>>            
>>>> apply to a number of
>>>>    
>>>>        
>>>>>> variants at once.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>>        
>>>>>>            
>>>>>      
>>>>>          
>>>>    
>>>>        
>>>  
>>>      
>>    
>
>
>  

[jonwimp]

Chris,

Is this how OFBiz is currently doing things? I can see your point.

But currently, I have a limiting/crippling "time to market" constraint. When building for
flexibility, there can be no end to the quest. Whatever you said of Product IDs, the same may be
said of ProductFeature IDs or any other IDs in OFBiz. Usually, I'm forced to deliver the
application first, see how things run with prototype, then figure out where to go next after
getting a better view. I usually can't decide whether to construct a skyscraper on small plateau
or sprawling shopping mall on large plateau when I haven't even climbed up the plateau to see what
size it really is. Hindsight is cheaper to buy than foresight.

Still, back to your discussion with Product IDs. Can I use fields like "Internal Name" and
"Description" for my storefront? I know the storefront currently displays Product ID. This is a
real problem. I'd like a bit, even if just a tiny amount, of discussion or ideas thrown in at this
moment for this topic.

(To Boss: Any chance you'll be changing your Product IDs like Chris said?)

Jonathon

Chris Howe wrote:

> This is "big picture" discussion and certainly not
> cookie cutter, so there are pros and cons on both
> sides.  I take the approach that being the programmer,
> you have the capability to provide your company or
> your client's company the capability to not let
> database theory requirements get in the way of them
> running their business.
>
> As far as making life easier, you can still do lookups
> based on aliases and treat them as if they are unique,
> as they certainly need to be unique for the date
> (think getProductNameForDate service instead of
> getPartyNameForDate).  The burden should be placed on
> the programmer to make this seamless, not on the
> business to adjust to the peculiarities.
>
>>From a competitive perspective, the first potential
> problem with using the automated intelligence
> productId as the glue to hold together your different
> product data is the scenario where a competitor comes
> along, is more successful in gaining the mind share of
> the sequence of the components for the intelligence
> productId.  Their 2KBL34M37 is the equivalent to your
> B730HM250, but you carry a different product with ID
> 2KBL34M37.  You're both in the same industry and
> customers mistakenly order your competitors product Id
> thinking that you are perhaps a distributor of their
> product or them of yours.
>
> Now no solution can prevent this from happening the
> first time or even perhaps the tenth time.  However
> once you realize the problem, an intelligent primary
> key prevents you from taking action without completely
> overhauling your database and making assumptions about
> your historical data which is perhaps inaccurate.  An
> alias primary key lets you come out with a "new"
> product line renaming everything under the sun without
> changing the underlying product data.
>
> Just to provide a real world business story behind
> this, productId naming conventions happen to be an
> important consideration with me as I'm in an industry
> where manufacturers consistently overlap their
> productIds and brand names don't really get plastered
> into the heads of the people ordering the product
> (medical supplies).  A hospital could be ordering a
> "6002" and be meaning to order a diaper or they could
> be meaning to order a cardiac catheter surgical prep
> kit or a bone saw.  Those three items from the
> manufacturers perspective are in diverse enough fields
> to never recognize that there is a conflict with
> productId.  However, down the supply chain a
> distributor is handling all three and perhaps losing
> sales for the manufacturer because of their inability
> to clarify the end customer's needs.
>
> You may not need to deal with these considerations
> (much larger and successful companies have chosen not
> to).  But you should do yourself a favor and take the
> short amount of time to consider it now and weigh that
> against what you end up being locked into.  It's no
> skin off my nose if you decide the effort to implement
> such a convention isn't worth the flexibility gained
> later ( unless you're a medical supply manufacturer
> :-) )
>
>
> Regards,
> Chris

[cjhowe]

--- Jonathon -- Improov <[hidden email]> wrote:

> Chris,
>
> Is this how OFBiz is currently doing things? I can
> see your point.

This is NOT how OFBiz currently does things.  And
without a community effort to modularize the
components, (IMO) will likely never be the way OFBiz
does things.  The product component and the
manufacturing components feature sets are simply,
individually too rich.  You can't introduce this
concept into the product component without breaking
the manufacturing component (or at least severely
convoluting the conceptualizations as I understand
it).  The value of the manufacturing component is just
too high compared to this benefit for this to be
feasible. If you were able to offer an alternative
product component, then a manufacturing component for
that new product component could be created without
the disruption to the current components.

>
> But currently, I have a limiting/crippling "time to
> market" constraint. When building for
> flexibility, there can be no end to the quest.

Exactly.  I can propose "what ifs" and "ponder this"
all day long as I have the luxury of never having to
satisfy your boss/client's actual need to sell
something :-) . This is the benefit and bane of open
source software.  The lure to create a better
mousetrap when the only mice you have, you keep as
pets.

> Whatever you said of Product IDs, the same may be
> said of ProductFeature IDs or any other IDs in
> OFBiz.

It's been a while since I've played with
ProductFeature IDs, so I may be off a bit on the
concept, but I don't think the same is true because
those IDs remain internal to your organization, don't
they?

> Usually, I'm forced to deliver the
> application first, see how things run with
> prototype, then figure out where to go next after
> getting a better view. I usually can't decide
> whether to construct a skyscraper on small plateau
> or sprawling shopping mall on large plateau when I
> haven't even climbed up the plateau to see what
> size it really is. Hindsight is cheaper to buy than
> foresight.
>
> Still, back to your discussion with Product IDs. Can
> I use fields like "Internal Name" and
> "Description" for my storefront? I know the
> storefront currently displays Product ID. This is a
> real problem. I'd like a bit, even if just a tiny
> amount, of discussion or ideas thrown in at this
> moment for this topic.
>

This is largely simply what you're choosing to show
the user of the site through the UI (except where
there are textbox inputs)  your link information can
have the Product.productId to send to your services
but have the words that show up on the screen be
Product.internalName.

> (To Boss: Any chance you'll be changing your Product
> IDs like Chris said?)
>
> Jonathon
>

Regards,
Chris

[jonwimp]

Chris,

You have the tendency to put a lot of concepts into very few paragraphs!

Without going into all the details of your message and branching off into many "big picture"
concepts, I'll just say this. I agree with you. I believe there is a need for a product lookup
key, an additional level of indirection perhaps. Product IDs do change, in my experience (though
not very very much). It's good to have the flexibility to rebrand my products.

But as OFBiz is already using productId for so many intelligent logics now, we'll have to leave
that "as is", and create a new field like marketingProductId or something. Original field names
may lose their meaning after some evolution, but at least there's less change
management/propagation required as compared to if we did a refactor (even a simple rename of
field). One example of such vestige is the name "org.ofbiz.odbc" entity group (group no longer
requires use of ODBC?).

For now, I'm just concerned with being able to put to my storefront the model number or branded
name I want. My competitor may have popularized WG-9943. So my productId WG-9943 stays, but I let
my customers now order that same product via a new name: WeizerGun-101-Enterprise (I'd like that
compared to WG-9943 anyway). I guess that (plus your feedback) answers my concern raised by you
regarding flexibility to rebrand products.

Jonathon

Chris Howe wrote:

> --- Jonathon -- Improov <[hidden email]> wrote:
>
>> Chris,
>>
>> Is this how OFBiz is currently doing things? I can
>> see your point.
>
> This is NOT how OFBiz currently does things.  And
> without a community effort to modularize the
> components, (IMO) will likely never be the way OFBiz
> does things.  The product component and the
> manufacturing components feature sets are simply,
> individually too rich.  You can't introduce this
> concept into the product component without breaking
> the manufacturing component (or at least severely
> convoluting the conceptualizations as I understand
> it).  The value of the manufacturing component is just
> too high compared to this benefit for this to be
> feasible. If you were able to offer an alternative
> product component, then a manufacturing component for
> that new product component could be created without
> the disruption to the current components.
>
>> But currently, I have a limiting/crippling "time to
>> market" constraint. When building for
>> flexibility, there can be no end to the quest.
>
> Exactly.  I can propose "what ifs" and "ponder this"
> all day long as I have the luxury of never having to
> satisfy your boss/client's actual need to sell
> something :-) . This is the benefit and bane of open
> source software.  The lure to create a better
> mousetrap when the only mice you have, you keep as
> pets.
>
>> Whatever you said of Product IDs, the same may be
>> said of ProductFeature IDs or any other IDs in
>> OFBiz.
>
> It's been a while since I've played with
> ProductFeature IDs, so I may be off a bit on the
> concept, but I don't think the same is true because
> those IDs remain internal to your organization, don't
> they?
>
>> Usually, I'm forced to deliver the
>> application first, see how things run with
>> prototype, then figure out where to go next after
>> getting a better view. I usually can't decide
>> whether to construct a skyscraper on small plateau
>> or sprawling shopping mall on large plateau when I
>> haven't even climbed up the plateau to see what
>> size it really is. Hindsight is cheaper to buy than
>> foresight.
>>
>> Still, back to your discussion with Product IDs. Can
>> I use fields like "Internal Name" and
>> "Description" for my storefront? I know the
>> storefront currently displays Product ID. This is a
>> real problem. I'd like a bit, even if just a tiny
>> amount, of discussion or ideas thrown in at this
>> moment for this topic.
>>
>
> This is largely simply what you're choosing to show
> the user of the site through the UI (except where
> there are textbox inputs)  your link information can
> have the Product.productId to send to your services
> but have the words that show up on the screen be
> Product.internalName.
>
>> (To Boss: Any chance you'll be changing your Product
>> IDs like Chris said?)
>>
>> Jonathon
>>
>
> Regards,
> Chris
>
>

[Jacopo Cappellato]

Jonathon -- Improov wrote:
>
> But as OFBiz is already using productId for so many intelligent logics
> now, we'll have to leave that "as is", and create a new field like
> marketingProductId or something.

Just to clarify this concept: no OFBiz logic is based on the content of
product ids. They are treated as primary keys and so the business logic
already support what Chris suggests.
However, I agree with you that changing the OFBiz's ui to 'hide' the
product id and show one of the GoodIdentification ids would be a big task.

> Original field names may lose their
> meaning after some evolution, but at least there's less change
> management/propagation required as compared to if we did a refactor
> (even a simple rename of field). One example of such vestige is the name
> "org.ofbiz.odbc" entity group (group no longer requires use of ODBC?).
>

Yes, I think that we should change that name to something more generic
in order to avoid confusion: for example "org.ofbiz.external"

Jacopo

> For now, I'm just concerned with being able to put to my storefront the
> model number or branded name I want. My competitor may have popularized
> WG-9943. So my productId WG-9943 stays, but I let my customers now order
> that same product via a new name: WeizerGun-101-Enterprise (I'd like
> that compared to WG-9943 anyway). I guess that (plus your feedback)
> answers my concern raised by you regarding flexibility to rebrand products.
>
> Jonathon
>
> Chris Howe wrote:
>> --- Jonathon -- Improov <[hidden email]> wrote:
>>
>>> Chris,
>>>
>>> Is this how OFBiz is currently doing things? I can
>>> see your point.
>>
>> This is NOT how OFBiz currently does things.  And
>> without a community effort to modularize the
>> components, (IMO) will likely never be the way OFBiz
>> does things.  The product component and the
>> manufacturing components feature sets are simply,
>> individually too rich.  You can't introduce this
>> concept into the product component without breaking
>> the manufacturing component (or at least severely
>> convoluting the conceptualizations as I understand
>> it).  The value of the manufacturing component is just
>> too high compared to this benefit for this to be
>> feasible. If you were able to offer an alternative
>> product component, then a manufacturing component for
>> that new product component could be created without
>> the disruption to the current components.
>>
>>> But currently, I have a limiting/crippling "time to
>>> market" constraint. When building for flexibility, there can be no
>>> end to the quest.
>>
>> Exactly.  I can propose "what ifs" and "ponder this"
>> all day long as I have the luxury of never having to
>> satisfy your boss/client's actual need to sell
>> something :-) . This is the benefit and bane of open
>> source software.  The lure to create a better
>> mousetrap when the only mice you have, you keep as
>> pets.
>>
>>> Whatever you said of Product IDs, the same may be said of
>>> ProductFeature IDs or any other IDs in
>>> OFBiz.
>>
>> It's been a while since I've played with
>> ProductFeature IDs, so I may be off a bit on the
>> concept, but I don't think the same is true because
>> those IDs remain internal to your organization, don't
>> they?
>>
>>> Usually, I'm forced to deliver the application first, see how things
>>> run with
>>> prototype, then figure out where to go next after getting a better
>>> view. I usually can't decide
>>> whether to construct a skyscraper on small plateau or sprawling
>>> shopping mall on large plateau when I
>>> haven't even climbed up the plateau to see what size it really is.
>>> Hindsight is cheaper to buy than
>>> foresight.
>>>
>>> Still, back to your discussion with Product IDs. Can
>>> I use fields like "Internal Name" and "Description" for my
>>> storefront? I know the
>>> storefront currently displays Product ID. This is a real problem. I'd
>>> like a bit, even if just a tiny
>>> amount, of discussion or ideas thrown in at this moment for this topic.
>>>
>>
>> This is largely simply what you're choosing to show
>> the user of the site through the UI (except where
>> there are textbox inputs)  your link information can
>> have the Product.productId to send to your services
>> but have the words that show up on the screen be
>> Product.internalName.
>>
>>> (To Boss: Any chance you'll be changing your Product
>>> IDs like Chris said?)
>>>
>>> Jonathon
>>>
>>
>> Regards,
>> Chris
>>
>>

[Leon Torres-2]

Isn't this what the GoodIdentification entity is all about?

In practice your productIds, internally, should be serial numbers like
100100010.  OFBiz allows the luxury of String IDs, and I would consider it a
huge mistake to fall into the thinking that this is to be the ID that is
marketable, exposable, and what the customer comes to identify with.

You shouldn't rely on these *unique internal identifiers* to drive your product
identity.  There is a huge difference between data representation for purposes
of system processing and human consumption.

- Leon

Jonathon -- Improov wrote:

> Chris,
>
> You have the tendency to put a lot of concepts into very few paragraphs!
>
> Without going into all the details of your message and branching off
> into many "big picture" concepts, I'll just say this. I agree with you.
> I believe there is a need for a product lookup key, an additional level
> of indirection perhaps. Product IDs do change, in my experience (though
> not very very much). It's good to have the flexibility to rebrand my
> products.
>
> But as OFBiz is already using productId for so many intelligent logics
> now, we'll have to leave that "as is", and create a new field like
> marketingProductId or something. Original field names may lose their
> meaning after some evolution, but at least there's less change
> management/propagation required as compared to if we did a refactor
> (even a simple rename of field). One example of such vestige is the name
> "org.ofbiz.odbc" entity group (group no longer requires use of ODBC?).
>
> For now, I'm just concerned with being able to put to my storefront the
> model number or branded name I want. My competitor may have popularized
> WG-9943. So my productId WG-9943 stays, but I let my customers now order
> that same product via a new name: WeizerGun-101-Enterprise (I'd like
> that compared to WG-9943 anyway). I guess that (plus your feedback)
> answers my concern raised by you regarding flexibility to rebrand products.
>
> Jonathon
>
> Chris Howe wrote:
>> --- Jonathon -- Improov <[hidden email]> wrote:
>>
>>> Chris,
>>>
>>> Is this how OFBiz is currently doing things? I can
>>> see your point.
>>
>> This is NOT how OFBiz currently does things.  And
>> without a community effort to modularize the
>> components, (IMO) will likely never be the way OFBiz
>> does things.  The product component and the
>> manufacturing components feature sets are simply,
>> individually too rich.  You can't introduce this
>> concept into the product component without breaking
>> the manufacturing component (or at least severely
>> convoluting the conceptualizations as I understand
>> it).  The value of the manufacturing component is just
>> too high compared to this benefit for this to be
>> feasible. If you were able to offer an alternative
>> product component, then a manufacturing component for
>> that new product component could be created without
>> the disruption to the current components.
>>
>>> But currently, I have a limiting/crippling "time to
>>> market" constraint. When building for flexibility, there can be no
>>> end to the quest.
>>
>> Exactly.  I can propose "what ifs" and "ponder this"
>> all day long as I have the luxury of never having to
>> satisfy your boss/client's actual need to sell
>> something :-) . This is the benefit and bane of open
>> source software.  The lure to create a better
>> mousetrap when the only mice you have, you keep as
>> pets.
>>
>>> Whatever you said of Product IDs, the same may be said of
>>> ProductFeature IDs or any other IDs in
>>> OFBiz.
>>
>> It's been a while since I've played with
>> ProductFeature IDs, so I may be off a bit on the
>> concept, but I don't think the same is true because
>> those IDs remain internal to your organization, don't
>> they?
>>
>>> Usually, I'm forced to deliver the application first, see how things
>>> run with
>>> prototype, then figure out where to go next after getting a better
>>> view. I usually can't decide
>>> whether to construct a skyscraper on small plateau or sprawling
>>> shopping mall on large plateau when I
>>> haven't even climbed up the plateau to see what size it really is.
>>> Hindsight is cheaper to buy than
>>> foresight.
>>>
>>> Still, back to your discussion with Product IDs. Can
>>> I use fields like "Internal Name" and "Description" for my
>>> storefront? I know the
>>> storefront currently displays Product ID. This is a real problem. I'd
>>> like a bit, even if just a tiny
>>> amount, of discussion or ideas thrown in at this moment for this topic.
>>>
>>
>> This is largely simply what you're choosing to show
>> the user of the site through the UI (except where
>> there are textbox inputs)  your link information can
>> have the Product.productId to send to your services
>> but have the words that show up on the screen be
>> Product.internalName.
>>
>>> (To Boss: Any chance you'll be changing your Product
>>> IDs like Chris said?)
>>>
>>> Jonathon
>>>
>>
>> Regards,
>> Chris
>>
>>
>
>

[Scott Gray]

I never suggested a productId should be marketed or used externally, I
simply mean that I would rather type in GZ-1000 than use a look up
because I can't remember that 100100010 relates to a tiny gizmo.

Scott

Leon Torres wrote:

> Isn't this what the GoodIdentification entity is all about?
>
> In practice your productIds, internally, should be serial numbers like
> 100100010.  OFBiz allows the luxury of String IDs, and I would
> consider it a huge mistake to fall into the thinking that this is to
> be the ID that is marketable, exposable, and what the customer comes
> to identify with.
>
> You shouldn't rely on these *unique internal identifiers* to drive
> your product identity.  There is a huge difference between data
> representation for purposes of system processing and human consumption.
>
> - Leon
>
> Jonathon -- Improov wrote:
>> Chris,
>>
>> You have the tendency to put a lot of concepts into very few paragraphs!
>>
>> Without going into all the details of your message and branching off
>> into many "big picture" concepts, I'll just say this. I agree with
>> you. I believe there is a need for a product lookup key, an
>> additional level of indirection perhaps. Product IDs do change, in my
>> experience (though not very very much). It's good to have the
>> flexibility to rebrand my products.
>>
>> But as OFBiz is already using productId for so many intelligent
>> logics now, we'll have to leave that "as is", and create a new field
>> like marketingProductId or something. Original field names may lose
>> their meaning after some evolution, but at least there's less change
>> management/propagation required as compared to if we did a refactor
>> (even a simple rename of field). One example of such vestige is the
>> name "org.ofbiz.odbc" entity group (group no longer requires use of
>> ODBC?).
>>
>> For now, I'm just concerned with being able to put to my storefront
>> the model number or branded name I want. My competitor may have
>> popularized WG-9943. So my productId WG-9943 stays, but I let my
>> customers now order that same product via a new name:
>> WeizerGun-101-Enterprise (I'd like that compared to WG-9943 anyway).
>> I guess that (plus your feedback) answers my concern raised by you
>> regarding flexibility to rebrand products.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> --- Jonathon -- Improov <[hidden email]> wrote:
>>>
>>>> Chris,
>>>>
>>>> Is this how OFBiz is currently doing things? I can
>>>> see your point.
>>>
>>> This is NOT how OFBiz currently does things.  And
>>> without a community effort to modularize the
>>> components, (IMO) will likely never be the way OFBiz
>>> does things.  The product component and the
>>> manufacturing components feature sets are simply,
>>> individually too rich.  You can't introduce this
>>> concept into the product component without breaking
>>> the manufacturing component (or at least severely
>>> convoluting the conceptualizations as I understand
>>> it).  The value of the manufacturing component is just
>>> too high compared to this benefit for this to be
>>> feasible. If you were able to offer an alternative
>>> product component, then a manufacturing component for
>>> that new product component could be created without
>>> the disruption to the current components.
>>>
>>>> But currently, I have a limiting/crippling "time to
>>>> market" constraint. When building for flexibility, there can be no
>>>> end to the quest.
>>>
>>> Exactly.  I can propose "what ifs" and "ponder this"
>>> all day long as I have the luxury of never having to
>>> satisfy your boss/client's actual need to sell
>>> something :-) . This is the benefit and bane of open
>>> source software.  The lure to create a better
>>> mousetrap when the only mice you have, you keep as
>>> pets.
>>>
>>>> Whatever you said of Product IDs, the same may be said of
>>>> ProductFeature IDs or any other IDs in
>>>> OFBiz.
>>>
>>> It's been a while since I've played with
>>> ProductFeature IDs, so I may be off a bit on the
>>> concept, but I don't think the same is true because
>>> those IDs remain internal to your organization, don't
>>> they?
>>>
>>>> Usually, I'm forced to deliver the application first, see how
>>>> things run with
>>>> prototype, then figure out where to go next after getting a better
>>>> view. I usually can't decide
>>>> whether to construct a skyscraper on small plateau or sprawling
>>>> shopping mall on large plateau when I
>>>> haven't even climbed up the plateau to see what size it really is.
>>>> Hindsight is cheaper to buy than
>>>> foresight.
>>>>
>>>> Still, back to your discussion with Product IDs. Can
>>>> I use fields like "Internal Name" and "Description" for my
>>>> storefront? I know the
>>>> storefront currently displays Product ID. This is a real problem.
>>>> I'd like a bit, even if just a tiny
>>>> amount, of discussion or ideas thrown in at this moment for this
>>>> topic.
>>>>
>>>
>>> This is largely simply what you're choosing to show
>>> the user of the site through the UI (except where
>>> there are textbox inputs)  your link information can
>>> have the Product.productId to send to your services
>>> but have the words that show up on the screen be
>>> Product.internalName.
>>>
>>>> (To Boss: Any chance you'll be changing your Product
>>>> IDs like Chris said?)
>>>>
>>>> Jonathon
>>>>
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>
>>
>

[cjhowe]

Leon's comments are right on and a much more straight
forward explanation then what I was about to send.
So, I'll leave it at +1 Leon to avoid confusion.

In regards to the org.ofbiz.odbc, just to clarify,
org.ofbiz.odbc never 'required' odbc.  The naming
convention used there appears to be because UPS
Worldship integration is done most easily using MS
Access databases.  That's an appeasement of UPS, and
never was a requirement for OFBiz.  I'm on the fence
though as whether org.ofbiz.external would necessarily
be a better naming convention.  I think it may just
need <!-- --> commenting because it is a two part
integration as you have to set up UPS to use an
external database as well. The .odbc does push you in
the right direction. So, who knows?



--- Leon Torres <[hidden email]> wrote:

> Isn't this what the GoodIdentification entity is all
> about?
>
> In practice your productIds, internally, should be
> serial numbers like
> 100100010.  OFBiz allows the luxury of String IDs,
> and I would consider it a
> huge mistake to fall into the thinking that this is
> to be the ID that is
> marketable, exposable, and what the customer comes
> to identify with.
>
> You shouldn't rely on these *unique internal
> identifiers* to drive your product
> identity.  There is a huge difference between data
> representation for purposes
> of system processing and human consumption.
>
> - Leon
>
> Jonathon -- Improov wrote:
> > Chris,
> >
> > You have the tendency to put a lot of concepts
> into very few paragraphs!
> >
> > Without going into all the details of your message
> and branching off
> > into many "big picture" concepts, I'll just say
> this. I agree with you.
> > I believe there is a need for a product lookup
> key, an additional level
> > of indirection perhaps. Product IDs do change, in
> my experience (though
> > not very very much). It's good to have the
> flexibility to rebrand my
> > products.
> >
> > But as OFBiz is already using productId for so
> many intelligent logics
> > now, we'll have to leave that "as is", and create
> a new field like
> > marketingProductId or something. Original field
> names may lose their
> > meaning after some evolution, but at least there's
> less change
> > management/propagation required as compared to if
> we did a refactor
> > (even a simple rename of field). One example of
> such vestige is the name
> > "org.ofbiz.odbc" entity group (group no longer
> requires use of ODBC?).
> >
> > For now, I'm just concerned with being able to put
> to my storefront the
> > model number or branded name I want. My competitor
> may have popularized
> > WG-9943. So my productId WG-9943 stays, but I let
> my customers now order
> > that same product via a new name:
> WeizerGun-101-Enterprise (I'd like
> > that compared to WG-9943 anyway). I guess that
> (plus your feedback)
> > answers my concern raised by you regarding
> flexibility to rebrand products.
> >
> > Jonathon
> >
> > Chris Howe wrote:
> >> --- Jonathon -- Improov <[hidden email]> wrote:
> >>
> >>> Chris,
> >>>
> >>> Is this how OFBiz is currently doing things? I
> can
> >>> see your point.
> >>
> >> This is NOT how OFBiz currently does things.  And
> >> without a community effort to modularize the
> >> components, (IMO) will likely never be the way
> OFBiz
> >> does things.  The product component and the
> >> manufacturing components feature sets are simply,
> >> individually too rich.  You can't introduce this
> >> concept into the product component without
> breaking
> >> the manufacturing component (or at least severely
> >> convoluting the conceptualizations as I
> understand
> >> it).  The value of the manufacturing component is
> just
> >> too high compared to this benefit for this to be
> >> feasible. If you were able to offer an
> alternative
> >> product component, then a manufacturing component
> for
> >> that new product component could be created
> without
> >> the disruption to the current components.
> >>
> >>> But currently, I have a limiting/crippling "time
> to
> >>> market" constraint. When building for
> flexibility, there can be no
> >>> end to the quest.
> >>
> >> Exactly.  I can propose "what ifs" and "ponder
> this"
> >> all day long as I have the luxury of never having
> to
> >> satisfy your boss/client's actual need to sell
> >> something :-) . This is the benefit and bane of
> open
> >> source software.  The lure to create a better
> >> mousetrap when the only mice you have, you keep
> as
> >> pets.
> >>
> >>> Whatever you said of Product IDs, the same may
> be said of
> >>> ProductFeature IDs or any other IDs in
> >>> OFBiz.
> >>
> >> It's been a while since I've played with
> >> ProductFeature IDs, so I may be off a bit on the
> >> concept, but I don't think the same is true
> because
> >> those IDs remain internal to your organization,
> don't
> >> they?
> >>
> >>> Usually, I'm forced to deliver the application
> first, see how things
> >>> run with
> >>> prototype, then figure out where to go next
> after getting a better
> >>> view. I usually can't decide
> >>> whether to construct a skyscraper on small
> plateau or sprawling
> >>> shopping mall on large plateau when I
> >>> haven't even climbed up the plateau to see what
> size it really is.
> >>> Hindsight is cheaper to buy than
> >>> foresight.
> >>>
> >>> Still, back to your discussion with Product IDs.
> Can
> >>> I use fields like "Internal Name" and
> "Description" for my
> >>> storefront? I know the
> >>> storefront currently displays Product ID. This
> is a real problem. I'd
> >>> like a bit, even if just a tiny
> >>> amount, of discussion or ideas thrown in at this
> moment for this topic.
> >>>
> >>
> >> This is largely simply what you're choosing to
> show
> >> the user of the site through the UI (except where
> >> there are textbox inputs)  your link information
> can
> >> have the Product.productId to send to your
> services
> >> but have the words that show up on the screen be
> >> Product.internalName.
> >>
> >>> (To Boss: Any chance you'll be changing your
> Product
> >>> IDs like Chris said?)
> >>>
> >>> Jonathon
> >>>
> >>
> >> Regards,
> >> Chris
> >>
> >>
> >
> >
>

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>


> Jonathon -- Improov wrote:
[...snip...]
> > Original field names may lose their
> > meaning after some evolution, but at least there's less change
> > management/propagation required as compared to if we did a refactor
> > (even a simple rename of field). One example of such vestige is the name
> > "org.ofbiz.odbc" entity group (group no longer requires use of ODBC?).
> >
>
> Yes, I think that we should change that name to something more generic
> in order to avoid confusion: for example "org.ofbiz.external"

+1 !
Or what is used for : "org.ofbiz.shipext", next time the same (name reflecting use, semantic in it) ...

Jacques
 
> Jacopo