Auto-generating of BOMs from Virtual Product to Variants

[Jacques Le Roux]

Yes right Chris, a comment is maybe better (though not in log or else... Mmm...)

Jacques

----- Original Message -----
From: "Chris Howe" <[hidden email]>
To: <[hidden email]>
Sent: Friday, January 12, 2007 10:32 AM
Subject: Re: Auto-generating of BOMs from Virtual Product to Variants

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

[Andrew Sykes]

Are you sure this is a set of variants rather than a set of
configurations?

- Andrew

On Fri, 2007-01-12 at 13:18 +0800, 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

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[jonwimp]

Andrew,

I was trying to use Configurable Product at first. But that mechanism doesn't even come close to
what I need; at a minimum, there's no BOM for configurations, which is why production runs are
created immediately upon the creation of an SO for a Configurable Product.

I have since fallen back on Variants. Every aspect of Variants serves my purpose here. So far,
I've only ever tried "Selectable" features, not the rest ("Optional", "Required", etc). So far, it
serves what I need.

Any reason I should be using Configurable Products? Note that my Bicycle-abcd, having 4 variables
a-d in the model number, requires all of those variables. Even a bicycle with no bell is denoted
say by Bicycle-abcN.

Jonathon

Andrew Sykes wrote:

> Are you sure this is a set of variants rather than a set of
> configurations?
>
> - Andrew
>
> On Fri, 2007-01-12 at 13:18 +0800, 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

[Andrew Sykes]

Jonathon,

Sounds like you've pretty well considered the details.

I just wanted to make sure you were aware of the options.

- Andrew

On Fri, 2007-01-12 at 22:02 +0800, Jonathon -- Improov wrote:

> Andrew,
>
> I was trying to use Configurable Product at first. But that mechanism doesn't even come close to
> what I need; at a minimum, there's no BOM for configurations, which is why production runs are
> created immediately upon the creation of an SO for a Configurable Product.
>
> I have since fallen back on Variants. Every aspect of Variants serves my purpose here. So far,
> I've only ever tried "Selectable" features, not the rest ("Optional", "Required", etc). So far, it
> serves what I need.
>
> Any reason I should be using Configurable Products? Note that my Bicycle-abcd, having 4 variables
> a-d in the model number, requires all of those variables. Even a bicycle with no bell is denoted
> say by Bicycle-abcN.
>
> Jonathon
>
> Andrew Sykes wrote:
> > Are you sure this is a set of variants rather than a set of
> > configurations?
> >
> > - Andrew
> >
> > On Fri, 2007-01-12 at 13:18 +0800, 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
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com