You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Jonathon -- Improov <jo...@improov.com> on 2007/01/10 04:50:06 UTC
Auto-generated config IDs for configurable products
Jacopo,
This is urgent for me. But first, thanks for your tips below.
Let me describe my requirements before suggesting a solution.
I have a product say PC001 that has probably millions of configurations. OFBiz handles that fine,
with the "Configurable Product" concept. PC001 remains a single product for easy administration,
since it's not possible to create millions of variants and corresponding product IDs.
I need some "product ID rules" to specify say unique "configuration IDs" for each configuration,
but I still want a single product ID "PC001".
For eg, a PC001 that has 2x256RAM and 1x2GB_HD may have "configuration ID" PC001-2AR-1AH, where
the 2nd code "2AR" specifies 2 pieces of 256RAM and the 3rd code "1AH" specifies 1 piece of 2GB
HD. So a PC001 that has 1x512RAM and 3x4GB_HD may have a config ID PC001-1BR-3BH. From this
example, you can deduce that 256RAM and 512RAM have codes "AR" and "BR", respectively. And 2GB HD
and 4GB HD have codes "AH" and "BH", respectively.
Entity GoodIdentification doesn't work for me (Product page -> IDs). It allows only 1 ID for each
type ISBN, Manufacturer (Model) Number, Model Year, SKU, etc.
What about Manufacturing rules (BOM -> Manufacturing Rules)? Will that work?
I think this has a lot to do with your intention to store individual configurations in the
database. Like you said, the entity model already caters for storing individual configurations
(via entity ProductConfigConfig). All we have to do now is to provide AUTOMATED rules for
generating the value for field ProductConfigConfig.configId. I believe this entity isn't used yet,
according to what you said. Right?
I HAVE to implement this right away. I'm calling for suggestions, instructions, guidelines to
direct my development so that what I do can be contributed verbatim back to the community.
Ideas?
Jonathon
Jacopo Cappellato wrote:
> Jonathon,
>
> Jonathon -- Improov wrote:
>> Jacopo,
>>
>> So are you planning to do the "Create multiple Production Runs for
>> Configurable Product" feature? If so, when?
>
> No, I'm sorry but I don't have plans about this at the moment.
>
>> If you want me to do it, can you bring me up to speed quickly so I can
>> put my work back here for public audit? If I were to do it, I'd
>> probably start with the "creation of new production runs based on the
>> configuration id" feature.
>
> I'd suggest looking at the ProductConfig* classes (that handle many of
> the configuration related tasks):
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/src/org/ofbiz/product/config/
>
>
> In particular:
>
http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/src/org/ofbiz/product/config/ProductConfigWrapper.java
>
> is the class that represents a product configuration, so the idea is to
> add a new method to it (something like store()) to store the
> configuration in the db.
> About the data model, here are the entities involved:
> ProductConfig
> ProductConfigItem
> ProdConfItemContent
> ProdConfItemContentType
> ProductConfigOption
> ProductConfigOptionIactn
> ProductConfigProduct
> ProductConfigConfig
> ProductConfigStats
>
> Some of them are still not used by the system; in particular,
> ProductConfigConfig is the entity that should be used to store a
> particular product configuration.
> They are all defined here:
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/entitydef/entitymodel.xml
>
>
> If you want to see how the demo product PC001 is persisted in the db:
>
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/ecommerce/data/DemoConfigurator.xml
>
>
> The user interface to edit the above data is here:
>
> https://demo.dejc.com:8443/catalog/control/FindProductConfigItems
>
> During order entry, you can configure a pc both in the ecommerce and in
> the order manager application (click on the "configurable pc" category
> in the left-hand side and then select the PC001).
>
> Hope this helps,
>
> Jacopo
>
>
>>
>> You mean it takes 0.5 to 1 day of work to do the above feature? Or
>> just to do the "Copy an existing production run" feature? The above
>> feature doesn't seem easy.
>>
>
> Yes, the 1 day estimate was about the "Copy an existing production run"
> feature; the other one is not so easy, even if there is already a lot of
> stuff in place.
>
> Jacopo
>
>> Jonathon
>>
>> Jacopo Cappellato wrote:
>>> Yes, the copy of a production run is not currently implemented (but
>>> it should be a rather easy task, let's say 0.5 to 1 day of work, for
>>> a developer with a good knowledge of OFBiz).
>>> The main reason is that, usually (for non pc - type products) the
>>> production run is quickly created from the bom and the routing (that
>>> both represents the 'template' for the production run).
>>> For pc-like products, the initial plan was to store the configuration
>>> (there is already the entity for this) and then use it in the system
>>> to do various tasks, such as:
>>> - statistics of top sold configurations
>>> - pre-configured items proposed to the customers
>>> - creation of new production runs based on the configuration id (this
>>> is what you would need here)
>>> - planning
>>> - bom explosions
>>> - and, most of all, by storing the configuration there will be no
>>> need to immediately create the production run when the order is
>>> created as is now (having a more flexible system).
>>>
>>> Jacopo
>>>
>>>> Jonathon
>>>
>>>
>>>
>
>
>
Re: Auto-generated config IDs for configurable products
Posted by Jonathon -- Improov <jo...@improov.com>.
Daniel,
Well, I still need to create millions of products with all the different selectable components.
For eg, I still need 5 products of type Marketing Package for 5 types of bicycles with different
sizes of bells. So, I'd need Bicycle-Bell1, Bicycle-Bell2, etc. Also, it doesn't quite serve
built-to-order scenarios.
But the Marketing Package does work to allow for assembly-upon-order or JIT scenarios (thanks Si
Chen and Jacopo!). Fantastic. Now I won't have to pre-assemble the millions of combinations of
bicycles I produce. As long as I have the necessary components in stock for a Marketing Package (a
sort of Product like Bicycle-B-TW for black bicycle with thick wheels), OFBiz counts my components
to calculate my "QOH from Components" value.
Even the determination of stock availability is done on the SO (no "backordered" warning if I have
the required components).
Hey, you're right. The production run is auto-created and auto-completed (mere assembly anyway).
FMI (for my info, self note), production runs (and consequent stock deductions) are created and
completed upon submission of an SO.
One unfortunate side-effect is that my SO states "1 Backordered" when the SO was created BEFORE I
had enough stock, and remained there even after I brought in adequate stock. However, having
"Inventory Receive" automatically assign stock to SOs could be too "smart" for me; I'd like to
determin when and how my stock is used. Simple workaround could be: I create my own production run
after i brought in the component stock?
This question is really for Facility -> Shipping. Why does "Pack Shipment" (calling service
updateShipment) go through even with zero of negative stock?
Jonathon
Daniel Kunkel wrote:
> Hi Jonathon
>
> Marketing components are made via a special attribute in a product
> association's BOM.
>
> It's full name is:
> Marketing Package Auto Explode Component
>
> And, as I said, the components are inventoried separately until you sell
> something... Then, a production run is created and executed, and the
> product is ready to ship. This system works especially well for
> marketing materials, kits, etc etc.
>
> There are even a few other cool features... Like when you order and
> receive products that comprise marketing auto explode components, the
> products are reduced to their component level.
>
> I'll take a quick moment to honor Si and Jacopo for this feature.
> Without their hard work it would still be just an idea sitting in the
> annals of Jira.
>
> Anyway... try creating one...
>
> Thanks
>
> Daniel
Re: Auto-generated config IDs for configurable products
Posted by Daniel Kunkel <Da...@BioWaves.com>.
Hi Jonathon
Marketing components are made via a special attribute in a product
association's BOM.
It's full name is:
Marketing Package Auto Explode Component
And, as I said, the components are inventoried separately until you sell
something... Then, a production run is created and executed, and the
product is ready to ship. This system works especially well for
marketing materials, kits, etc etc.
There are even a few other cool features... Like when you order and
receive products that comprise marketing auto explode components, the
products are reduced to their component level.
I'll take a quick moment to honor Si and Jacopo for this feature.
Without their hard work it would still be just an idea sitting in the
annals of Jira.
Anyway... try creating one...
Thanks
Daniel
On Thu, 2007-01-11 at 02:35 +0800, Jonathon -- Improov wrote:
> Hi Daniel,
>
> Do you mean the Marketing module? I can only find marketing campaigns there, nothing to do with
> products or inventory.
>
> Jonathon
>
> Daniel Kunkel wrote:
> > Jonathan
> >
> > I don't know if you're already familiar with Marketing Packages, or even
> > if they'll apply, but I thought I'd alert you to them since they can be
> > wonderful in the appropriate situation.
> >
> > In some cases where you have "millions of variants" it really comes from
> > a product that has interchangeable parts... colors, sizes, etc. For
> > example, a skateboard with a choice of 10 boards, a choice of 10 wheels,
> > 10 different colored nuts (to attach the wheels) and 10 different trucks
> > (the metal part). In this case, you're only stocking 40 items, but you
> > have 10,000 available products.
> >
> > With marketing packages, you just track the 40 items till a sale is
> > made, then "manufacture" the product per order. I think I've explained
> > this clearly enough that you see the genius of the idea.
> >
> > Anyway, look it up if it applies.
> >
> > Daniel
Re: Auto-generated config IDs for configurable products
Posted by Jonathon -- Improov <jo...@improov.com>.
Hi Daniel,
Do you mean the Marketing module? I can only find marketing campaigns there, nothing to do with
products or inventory.
Jonathon
Daniel Kunkel wrote:
> Jonathan
>
> I don't know if you're already familiar with Marketing Packages, or even
> if they'll apply, but I thought I'd alert you to them since they can be
> wonderful in the appropriate situation.
>
> In some cases where you have "millions of variants" it really comes from
> a product that has interchangeable parts... colors, sizes, etc. For
> example, a skateboard with a choice of 10 boards, a choice of 10 wheels,
> 10 different colored nuts (to attach the wheels) and 10 different trucks
> (the metal part). In this case, you're only stocking 40 items, but you
> have 10,000 available products.
>
> With marketing packages, you just track the 40 items till a sale is
> made, then "manufacture" the product per order. I think I've explained
> this clearly enough that you see the genius of the idea.
>
> Anyway, look it up if it applies.
>
> Daniel
Re: Auto-generated config IDs for configurable products
Posted by Daniel Kunkel <Da...@BioWaves.com>.
Jonathan
I don't know if you're already familiar with Marketing Packages, or even
if they'll apply, but I thought I'd alert you to them since they can be
wonderful in the appropriate situation.
In some cases where you have "millions of variants" it really comes from
a product that has interchangeable parts... colors, sizes, etc. For
example, a skateboard with a choice of 10 boards, a choice of 10 wheels,
10 different colored nuts (to attach the wheels) and 10 different trucks
(the metal part). In this case, you're only stocking 40 items, but you
have 10,000 available products.
With marketing packages, you just track the 40 items till a sale is
made, then "manufacture" the product per order. I think I've explained
this clearly enough that you see the genius of the idea.
Anyway, look it up if it applies.
Daniel
in case you haven't fou
On Wed, 2007-01-10 at 17:24 +0800, Jonathon -- Improov wrote:
> Jacopo,
>
> > unfortunately my time is very limited
>
> Sorry! Thanks for your time. Let me know if you need help.
>
> > I'd say that you have two valid options:
> >
> > a) use the virtual/variants approach, but instead of creating all the
> > variants just create the one you need during order entry. So you'll start
> > with zero variants and after, let's say 100 orders have been entered, you'll
> > have <= 100 variants.
>
> Yeah, I thought of this too. Create variants on-demand. I think my boss' business is B-to-B, not
> B-to-C. So maybe that's why he actually has need for this many configurations (running into
> millions). I'll ask him again if this approach can work. He is currently using another ERP system
> that does exactly what he needs, so it's gonna be hard to argue that this ERP function is not
> mainstream. Maybe it's not mainstream for B-to-C businesses.
>
> > b) complete the implementation of configurable products; however keep in mind
> > that the original goal for this was to address a special kind of product with
> > a huge amount of possible configuration, where each configuration was not so
> > important for the company itself (not worth of having a structured id);
> > instead it was very important to setup a rich and complex form for the
> > configuration
>
> I think I might go with this instead. Your original (or future) intent is to have this
> implementation track every possible configuration ever created, be it for market trends
> assessments or for supply chain adjustments. Your entity ProductConfigConfig already has a field
> configId. If I slap on an additional feature called "rule-based auto-generation of configId", I
> don't think it'll get in the way too much.
>
> > So I'd say that, if your main requirement is that of having, a lot of
> > possible configurations then I'd suggest #a approach.
> > You would also consider to reorganize your manufacturing processes to be
> > more standardized, predictable and efficient (effective resource and
> > materials planning is probably impossible for you now) but I really
> > don't know nothing about your scenario and needs and this is a bit off
> > topic in this list: we just met a lot of customers manufacturing
> > products with millions of configurations, that after they reorganized
> > their processes, marketing strategies, inventory management just ended
> > up with a totally different/efficient product's catalog and drastically
> > reduced the number of configurations (adopting for example many of the
> > JIT approaches).
> > But I'm going too far and this is probably not your situation, and
> > however is off topic for an OFBiz mailing list.
>
> No, I think you made a very good guess of my boss' situation, in my opinion. Let me run this by my
> boss again. Thanks, Jacopo.
>
> His manufacturing does a lot of built-to-order work, though. Not too sure if we can force-fit his
> "products" into a "productization" process (as opposed to sticking with highly-automated
> tailorization). We'll see.
>
> Jonathon
--
Daniel
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!
Daniel Kunkel DanielKunkel@BioWaves.com
BioWaves, LLC http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588 425-895-0050
http://www.Apartment-Pets.com http://www.Illusion-Optical.com
http://www.Card-Offer.com http://www.RackWine.com
http://www.JokesBlonde.com http://www.Brain-Fun.com
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Re: Auto-generated config IDs for configurable products
Posted by Jonathon -- Improov <jo...@improov.com>.
Jacopo,
> unfortunately my time is very limited
Sorry! Thanks for your time. Let me know if you need help.
> I'd say that you have two valid options:
>
> a) use the virtual/variants approach, but instead of creating all the
> variants just create the one you need during order entry. So you'll start
> with zero variants and after, let's say 100 orders have been entered, you'll
> have <= 100 variants.
Yeah, I thought of this too. Create variants on-demand. I think my boss' business is B-to-B, not
B-to-C. So maybe that's why he actually has need for this many configurations (running into
millions). I'll ask him again if this approach can work. He is currently using another ERP system
that does exactly what he needs, so it's gonna be hard to argue that this ERP function is not
mainstream. Maybe it's not mainstream for B-to-C businesses.
> b) complete the implementation of configurable products; however keep in mind
> that the original goal for this was to address a special kind of product with
> a huge amount of possible configuration, where each configuration was not so
> important for the company itself (not worth of having a structured id);
> instead it was very important to setup a rich and complex form for the
> configuration
I think I might go with this instead. Your original (or future) intent is to have this
implementation track every possible configuration ever created, be it for market trends
assessments or for supply chain adjustments. Your entity ProductConfigConfig already has a field
configId. If I slap on an additional feature called "rule-based auto-generation of configId", I
don't think it'll get in the way too much.
> So I'd say that, if your main requirement is that of having, a lot of
> possible configurations then I'd suggest #a approach.
> You would also consider to reorganize your manufacturing processes to be
> more standardized, predictable and efficient (effective resource and
> materials planning is probably impossible for you now) but I really
> don't know nothing about your scenario and needs and this is a bit off
> topic in this list: we just met a lot of customers manufacturing
> products with millions of configurations, that after they reorganized
> their processes, marketing strategies, inventory management just ended
> up with a totally different/efficient product's catalog and drastically
> reduced the number of configurations (adopting for example many of the
> JIT approaches).
> But I'm going too far and this is probably not your situation, and
> however is off topic for an OFBiz mailing list.
No, I think you made a very good guess of my boss' situation, in my opinion. Let me run this by my
boss again. Thanks, Jacopo.
His manufacturing does a lot of built-to-order work, though. Not too sure if we can force-fit his
"products" into a "productization" process (as opposed to sticking with highly-automated
tailorization). We'll see.
Jonathon
Re: Auto-generated config IDs for configurable products
Posted by David Welton <da...@gmail.com>.
On 1/10/07, Jonathon -- Improov <jo...@improov.com> wrote:
> Hi David Welton,
>
> So what are you using?
Code written in house, in PHP. I'm not sure if we'll ever be able to
transition to OFBiz, but it still is worth following for me, because
it illustrates the 'right way' to do a lot of things.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: Auto-generated config IDs for configurable products
Posted by Jonathon -- Improov <jo...@improov.com>.
Hi David Welton,
So what are you using?
Jonathon
David Welton wrote:
>> But I'm going too far and this is probably not your situation, and
>> however is off topic for an OFBiz mailing list.
>
> I'm actually quite happy to read this sort of thing. It's open for
> _business_, after all, and it's usually informative to see how other
> people handle certain tasks/concepts/procedures/ideas, even if we're
> not using OFBiz ourselves.
>
Re: Auto-generated config IDs for configurable products
Posted by Scott Gray <le...@gmail.com>.
+1
David Welton wrote:
>> But I'm going too far and this is probably not your situation, and
>> however is off topic for an OFBiz mailing list.
>
> I'm actually quite happy to read this sort of thing. It's open for
> _business_, after all, and it's usually informative to see how other
> people handle certain tasks/concepts/procedures/ideas, even if we're
> not using OFBiz ourselves.
>
Re: Auto-generated config IDs for configurable products
Posted by David Welton <da...@gmail.com>.
> But I'm going too far and this is probably not your situation, and
> however is off topic for an OFBiz mailing list.
I'm actually quite happy to read this sort of thing. It's open for
_business_, after all, and it's usually informative to see how other
people handle certain tasks/concepts/procedures/ideas, even if we're
not using OFBiz ourselves.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: Auto-generated config IDs for configurable products
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jonathon,
unfortunately my time is very limited at the moment since I'm running
like hell in order to complete some open tasks (and calm my clients)
before I leave for a 3-weeks long business travel.
I'd say that you have two valid options:
a) use the virtual/variants approach, but instead of creating all the
variants just create the one you need during order entry. So you'll
start with zero variants and after, let's say 100 orders have been
entered, you'll have <= 100 variants. You'll need to change the
ecommerce's order detail page to support this. In the backoffice order
entry page the product's lookup screen already support something like
this (in an experimental way, you'll have to test it and possibly fix
some bugs): when you select a virtual product, you can filter its
variants by feature and if the combination doesn't exist, a link will
appear to create it
b) complete the implementation of configurable products; however keep in
mind that the original goal for this was to address a special kind of
product with a huge amount of possible configuration, where each
configuration was not so important for the company itself (not worth of
having a structured id); instead it was very important to setup a rich
and complex form for the configuration
So I'd say that, if your main requirement is that of having, a lot of
possible configurations then I'd suggest #a approach.
You would also consider to reorganize your manufacturing processes to be
more standardized, predictable and efficient (effective resource and
materials planning is probably impossible for you now) but I really
don't know nothing about your scenario and needs and this is a bit off
topic in this list: we just met a lot of customers manufacturing
products with millions of configurations, that after they reorganized
their processes, marketing strategies, inventory management just ended
up with a totally different/efficient product's catalog and drastically
reduced the number of configurations (adopting for example many of the
JIT approaches).
But I'm going too far and this is probably not your situation, and
however is off topic for an OFBiz mailing list.
Jacopo
PS: about the rule to create the configuration ids, I'd suggest to
implement your custom rule in a small service (that take as input the
configuration and returns a config id) to isolate your custom code as
much as possible
Jonathon -- Improov wrote:
> Jacopo,
>
> This is urgent for me. But first, thanks for your tips below.
>
> Let me describe my requirements before suggesting a solution.
>
> I have a product say PC001 that has probably millions of configurations.
> OFBiz handles that fine, with the "Configurable Product" concept. PC001
> remains a single product for easy administration, since it's not
> possible to create millions of variants and corresponding product IDs.
>
> I need some "product ID rules" to specify say unique "configuration IDs"
> for each configuration, but I still want a single product ID "PC001".
>
> For eg, a PC001 that has 2x256RAM and 1x2GB_HD may have "configuration
> ID" PC001-2AR-1AH, where the 2nd code "2AR" specifies 2 pieces of 256RAM
> and the 3rd code "1AH" specifies 1 piece of 2GB HD. So a PC001 that has
> 1x512RAM and 3x4GB_HD may have a config ID PC001-1BR-3BH. From this
> example, you can deduce that 256RAM and 512RAM have codes "AR" and "BR",
> respectively. And 2GB HD and 4GB HD have codes "AH" and "BH", respectively.
>
> Entity GoodIdentification doesn't work for me (Product page -> IDs). It
> allows only 1 ID for each type ISBN, Manufacturer (Model) Number, Model
> Year, SKU, etc.
>
> What about Manufacturing rules (BOM -> Manufacturing Rules)? Will that
> work?
>
> I think this has a lot to do with your intention to store individual
> configurations in the database. Like you said, the entity model already
> caters for storing individual configurations (via entity
> ProductConfigConfig). All we have to do now is to provide AUTOMATED
> rules for generating the value for field ProductConfigConfig.configId. I
> believe this entity isn't used yet, according to what you said. Right?
>
> I HAVE to implement this right away. I'm calling for suggestions,
> instructions, guidelines to direct my development so that what I do can
> be contributed verbatim back to the community.
>
> Ideas?
>
> Jonathon
>
> Jacopo Cappellato wrote:
> > Jonathon,
> >
> > Jonathon -- Improov wrote:
> >> Jacopo,
> >>
> >> So are you planning to do the "Create multiple Production Runs for
> >> Configurable Product" feature? If so, when?
> >
> > No, I'm sorry but I don't have plans about this at the moment.
> >
> >> If you want me to do it, can you bring me up to speed quickly so I can
> >> put my work back here for public audit? If I were to do it, I'd
> >> probably start with the "creation of new production runs based on the
> >> configuration id" feature.
> >
> > I'd suggest looking at the ProductConfig* classes (that handle many of
> > the configuration related tasks):
> >
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/src/org/ofbiz/product/config/
>
> >
> >
> > In particular:
> >
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/src/org/ofbiz/product/config/ProductConfigWrapper.java
>
> >
> > is the class that represents a product configuration, so the idea is to
> > add a new method to it (something like store()) to store the
> > configuration in the db.
> > About the data model, here are the entities involved:
> > ProductConfig
> > ProductConfigItem
> > ProdConfItemContent
> > ProdConfItemContentType
> > ProductConfigOption
> > ProductConfigOptionIactn
> > ProductConfigProduct
> > ProductConfigConfig
> > ProductConfigStats
> >
> > Some of them are still not used by the system; in particular,
> > ProductConfigConfig is the entity that should be used to store a
> > particular product configuration.
> > They are all defined here:
> >
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/entitydef/entitymodel.xml
>
> >
> >
> > If you want to see how the demo product PC001 is persisted in the db:
> >
> >
> http://svn.apache.org/repos/asf/ofbiz/trunk/applications/ecommerce/data/DemoConfigurator.xml
>
> >
> >
> > The user interface to edit the above data is here:
> >
> > https://demo.dejc.com:8443/catalog/control/FindProductConfigItems
> >
> > During order entry, you can configure a pc both in the ecommerce and in
> > the order manager application (click on the "configurable pc" category
> > in the left-hand side and then select the PC001).
> >
> > Hope this helps,
> >
> > Jacopo
> >
> >
> >>
> >> You mean it takes 0.5 to 1 day of work to do the above feature? Or
> >> just to do the "Copy an existing production run" feature? The above
> >> feature doesn't seem easy.
> >>
> >
> > Yes, the 1 day estimate was about the "Copy an existing production run"
> > feature; the other one is not so easy, even if there is already a lot of
> > stuff in place.
> >
> > Jacopo
> >
> >> Jonathon
> >>
> >> Jacopo Cappellato wrote:
> >>> Yes, the copy of a production run is not currently implemented (but
> >>> it should be a rather easy task, let's say 0.5 to 1 day of work, for
> >>> a developer with a good knowledge of OFBiz).
> >>> The main reason is that, usually (for non pc - type products) the
> >>> production run is quickly created from the bom and the routing (that
> >>> both represents the 'template' for the production run).
> >>> For pc-like products, the initial plan was to store the configuration
> >>> (there is already the entity for this) and then use it in the system
> >>> to do various tasks, such as:
> >>> - statistics of top sold configurations
> >>> - pre-configured items proposed to the customers
> >>> - creation of new production runs based on the configuration id (this
> >>> is what you would need here)
> >>> - planning
> >>> - bom explosions
> >>> - and, most of all, by storing the configuration there will be no
> >>> need to immediately create the production run when the order is
> >>> created as is now (having a more flexible system).
> >>>
> >>> Jacopo
> >>>
> >>>> Jonathon
> >>>
> >>>
> >>>
> >
> >
> >
Re: Auto-generated config IDs for configurable products
Posted by David E Jones <jo...@undersunconsulting.com>.
On Jan 9, 2007, at 10:25 PM, Jonathon -- Improov wrote:
> David,
>
> > So, what about virtual/variant products like the Giant Widget?
> What is the
> > reason those won't work?
>
> I have literally millions of configurations for a configurable
> product like PC001. I'd have millions of variants (though just a
> single virtual product) to create if I go the variant way.
So, you're saying you need pre-configured, discrete products that can
be individually inventoried? How would you avoid that? Of course, if
there are millions of _potential_ variants, but not actual, then I'd
say use the configurable product and add something to recognize
matches with pre-configured variations to show shorter projected
shipping times, or interrupt the manufacturing process, or whatever
you need.
> > BTW, just so you know (and this is my opinion ONLY), but the
> "I'll contribute
> > back" argument to get people to help you out, especially ASAP, is
> pretty
> > weak. This is nothing personal and obviously a trend never has
> anything to do
> > with one person, but I don't think that anyone (in the OFBiz
> world anyway)
> > who has come in, guns blazing, promising to help out and
> contribute a lot if
> > only they can get past these few problems or if only someone can
> help them
> > get started, has actually remained involved with the open source
> project for
> > very long, let alone become regular or significant contributor.
> Wow, that
> > turned out to be a long sentence... I'll have to keep thinking
> about how to
> > express that better.
>
> Time will tell if I'm one of those leeches. :)
Well, "leech" is a bit of a strong word and implies something I was
trying to avoid. I think many people are just more optimistic than
realistic and this sort of statement seems to correlate with that.
I'm sure this is true with open source projects, though with OFBiz
I'd guess things can be more shocking as you can crest the first
mountain of technical aspects of the project, and especially if
you're approaching it from a technical background as you start
nearing the top it's staggering to see the next range that is 20x the
size. The same is true if you approach the range from a small
business perspective, or that of one part of a larger business. The
inherent complexity just sucks, and it sounds like you already know
that.
> We (who have been playing in opensource arenas) have all been hit
> by those. Sounds like you've been bitten more than twice, and I'm
> not surprised if that is so.
>
> Of course the "I'll contribute back" carrot is pretty weak. It's
> like saying "Gimme your money first, I promise I'll give you your
> goods".
>
> But I hope you notice clear distinctions in my behavior apart from
> leeches. I've already shown my willingness to "meet the community
> more than halfway" (aka do my homework). I don't just ask for help.
> If nobody has the info I need, I go out to trace through codes and
> then feedback my research to the mailing list.
>
> Now that you mention this "leech" issue, I guess I'll just drop
> certain bad "false humility" habits. I DO unassumingly help to
> flesh out certain topics that have long been left undocumented
> (check out the many cross-references I post to the mailing list in
> a bid to consolidate info). It's not that I don't entirely know
> what I'm talking about (if I know anything at all, ie). It's just a
> habit I have in speaking like I "don't quite know it all". It's a
> journalistic instinct. Yup, I'm not from the IT industry originally
> (which is probably why I need so much help?).
>
> Ultimately, I do want you and the community to know that I'm here
> to help and contribute. Did I lose my senses? No. My current boss
> will tell you I'm an altruistic person (even towards my boss/
> clients) with a strong sense fairness. Pragmatically speaking,
> contributing to the community helps make future upgrades easier,
> helps my boss' ERP system keep in step with OFBiz enhancements and
> updates.
>
> (And I like communities. I'm a social person. I envision a time
> when the concept of "work" is obsolete, where everyone just
> contributes for exploration and advancement, and nobody is in need
> or want.)
>
> As for this thread, I'm serious about having to implement the "rule-
> based config ID generation" for Configurable Products. Don't mind
> telling you, it's a make or break factor. Well, of course, if OFBiz/
> OpenTaps had been comprehensively documented to say there's no such
> feature, my boss would've broken away from OFBiz/OT sooner. I'd
> guess more than a few folks had ventured into OFBiz and been more
> than a bit miffed with "unfulfilled promises", probably caused by
> poor documentation plus unspecified limitations. Especially if the
> complaint is: "I thought the paid consultants said it's so feature-
> strong!". Whatever the case is, I am still STRONGLY CONVINCED that
> OFBiz is a solid framework to build just about anything, even if
> the existing applications don't meet his requirements (yes, he's
> listening in. :P).
Wow, have you _ever_ found a package that listed every possible
combination of business aspects that were not supported by it? Even
on the flip side, how many packages have you found that explicitly
list that feature?
-David
> So, again, I do need suggestions, instructions, guidelines to
> direct my development of this feature. Why? Because it's in my
> utmost interest to have the community track this feature in the
> consolidated SVN. I don't wanna create a feature that breaks
> existing codes.
>
> You could say that I need the community's blessings in my
> development of this feature.
>
> Jonathon
Re: Auto-generated config IDs for configurable products
Posted by Jonathon -- Improov <jo...@improov.com>.
David,
> So, what about virtual/variant products like the Giant Widget? What is the
> reason those won't work?
I have literally millions of configurations for a configurable product like PC001. I'd have
millions of variants (though just a single virtual product) to create if I go the variant way.
> BTW, just so you know (and this is my opinion ONLY), but the "I'll contribute
> back" argument to get people to help you out, especially ASAP, is pretty
> weak. This is nothing personal and obviously a trend never has anything to do
> with one person, but I don't think that anyone (in the OFBiz world anyway)
> who has come in, guns blazing, promising to help out and contribute a lot if
> only they can get past these few problems or if only someone can help them
> get started, has actually remained involved with the open source project for
> very long, let alone become regular or significant contributor. Wow, that
> turned out to be a long sentence... I'll have to keep thinking about how to
> express that better.
Time will tell if I'm one of those leeches. :) We (who have been playing in opensource arenas)
have all been hit by those. Sounds like you've been bitten more than twice, and I'm not surprised
if that is so.
Of course the "I'll contribute back" carrot is pretty weak. It's like saying "Gimme your money
first, I promise I'll give you your goods".
But I hope you notice clear distinctions in my behavior apart from leeches. I've already shown my
willingness to "meet the community more than halfway" (aka do my homework). I don't just ask for
help. If nobody has the info I need, I go out to trace through codes and then feedback my research
to the mailing list.
Now that you mention this "leech" issue, I guess I'll just drop certain bad "false humility"
habits. I DO unassumingly help to flesh out certain topics that have long been left undocumented
(check out the many cross-references I post to the mailing list in a bid to consolidate info).
It's not that I don't entirely know what I'm talking about (if I know anything at all, ie). It's
just a habit I have in speaking like I "don't quite know it all". It's a journalistic instinct.
Yup, I'm not from the IT industry originally (which is probably why I need so much help?).
Ultimately, I do want you and the community to know that I'm here to help and contribute. Did I
lose my senses? No. My current boss will tell you I'm an altruistic person (even towards my
boss/clients) with a strong sense fairness. Pragmatically speaking, contributing to the community
helps make future upgrades easier, helps my boss' ERP system keep in step with OFBiz enhancements
and updates.
(And I like communities. I'm a social person. I envision a time when the concept of "work" is
obsolete, where everyone just contributes for exploration and advancement, and nobody is in need
or want.)
As for this thread, I'm serious about having to implement the "rule-based config ID generation"
for Configurable Products. Don't mind telling you, it's a make or break factor. Well, of course,
if OFBiz/OpenTaps had been comprehensively documented to say there's no such feature, my boss
would've broken away from OFBiz/OT sooner. I'd guess more than a few folks had ventured into OFBiz
and been more than a bit miffed with "unfulfilled promises", probably caused by poor documentation
plus unspecified limitations. Especially if the complaint is: "I thought the paid consultants said
it's so feature-strong!". Whatever the case is, I am still STRONGLY CONVINCED that OFBiz is a
solid framework to build just about anything, even if the existing applications don't meet his
requirements (yes, he's listening in. :P).
So, again, I do need suggestions, instructions, guidelines to direct my development of this
feature. Why? Because it's in my utmost interest to have the community track this feature in the
consolidated SVN. I don't wanna create a feature that breaks existing codes.
You could say that I need the community's blessings in my development of this feature.
Jonathon
Re: Auto-generated config IDs for configurable products
Posted by David E Jones <jo...@undersunconsulting.com>.
Jonathon,
So, what about virtual/variant products like the Giant Widget? What
is the reason those won't work?
BTW, just so you know (and this is my opinion ONLY), but the "I'll
contribute back" argument to get people to help you out, especially
ASAP, is pretty weak. This is nothing personal and obviously a trend
never has anything to do with one person, but I don't think that
anyone (in the OFBiz world anyway) who has come in, guns blazing,
promising to help out and contribute a lot if only they can get past
these few problems or if only someone can help them get started, has
actually remained involved with the open source project for very
long, let alone become regular or significant contributor. Wow, that
turned out to be a long sentence... I'll have to keep thinking about
how to express that better.
Anyway, people here and in most mailing lists help out to help out,
and to generally make the software better for the next "pour soul"
who comes along needing something similar, which may very well be the
person trying to help answer the question! That has certainly
happened to me a few (dozen!) times.
-David
On Jan 9, 2007, at 8:50 PM, Jonathon -- Improov wrote:
> Jacopo,
>
> This is urgent for me. But first, thanks for your tips below.
>
> Let me describe my requirements before suggesting a solution.
>
> I have a product say PC001 that has probably millions of
> configurations. OFBiz handles that fine, with the "Configurable
> Product" concept. PC001 remains a single product for easy
> administration, since it's not possible to create millions of
> variants and corresponding product IDs.
>
> I need some "product ID rules" to specify say unique "configuration
> IDs" for each configuration, but I still want a single product ID
> "PC001".
>
> For eg, a PC001 that has 2x256RAM and 1x2GB_HD may have
> "configuration ID" PC001-2AR-1AH, where the 2nd code "2AR"
> specifies 2 pieces of 256RAM and the 3rd code "1AH" specifies 1
> piece of 2GB HD. So a PC001 that has 1x512RAM and 3x4GB_HD may have
> a config ID PC001-1BR-3BH. From this example, you can deduce that
> 256RAM and 512RAM have codes "AR" and "BR", respectively. And 2GB
> HD and 4GB HD have codes "AH" and "BH", respectively.
>
> Entity GoodIdentification doesn't work for me (Product page ->
> IDs). It allows only 1 ID for each type ISBN, Manufacturer (Model)
> Number, Model Year, SKU, etc.
>
> What about Manufacturing rules (BOM -> Manufacturing Rules)? Will
> that work?
>
> I think this has a lot to do with your intention to store
> individual configurations in the database. Like you said, the
> entity model already caters for storing individual configurations
> (via entity ProductConfigConfig). All we have to do now is to
> provide AUTOMATED rules for generating the value for field
> ProductConfigConfig.configId. I believe this entity isn't used yet,
> according to what you said. Right?
>
> I HAVE to implement this right away. I'm calling for suggestions,
> instructions, guidelines to direct my development so that what I do
> can be contributed verbatim back to the community.
>
> Ideas?
>
> Jonathon
>
> Jacopo Cappellato wrote:
> > Jonathon,
> >
> > Jonathon -- Improov wrote:
> >> Jacopo,
> >>
> >> So are you planning to do the "Create multiple Production Runs for
> >> Configurable Product" feature? If so, when?
> >
> > No, I'm sorry but I don't have plans about this at the moment.
> >
> >> If you want me to do it, can you bring me up to speed quickly so
> I can
> >> put my work back here for public audit? If I were to do it, I'd
> >> probably start with the "creation of new production runs based
> on the
> >> configuration id" feature.
> >
> > I'd suggest looking at the ProductConfig* classes (that handle
> many of
> > the configuration related tasks):
> > http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/
> src/org/ofbiz/product/config/
> >
> >
> > In particular:
> > http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/
> src/org/ofbiz/product/config/ProductConfigWrapper.java
> >
> > is the class that represents a product configuration, so the idea
> is to
> > add a new method to it (something like store()) to store the
> > configuration in the db.
> > About the data model, here are the entities involved:
> > ProductConfig
> > ProductConfigItem
> > ProdConfItemContent
> > ProdConfItemContentType
> > ProductConfigOption
> > ProductConfigOptionIactn
> > ProductConfigProduct
> > ProductConfigConfig
> > ProductConfigStats
> >
> > Some of them are still not used by the system; in particular,
> > ProductConfigConfig is the entity that should be used to store a
> > particular product configuration.
> > They are all defined here:
> > http://svn.apache.org/repos/asf/ofbiz/trunk/applications/product/
> entitydef/entitymodel.xml
> >
> >
> > If you want to see how the demo product PC001 is persisted in the
> db:
> >
> > http://svn.apache.org/repos/asf/ofbiz/trunk/applications/
> ecommerce/data/DemoConfigurator.xml
> >
> >
> > The user interface to edit the above data is here:
> >
> > https://demo.dejc.com:8443/catalog/control/FindProductConfigItems
> >
> > During order entry, you can configure a pc both in the ecommerce
> and in
> > the order manager application (click on the "configurable pc"
> category
> > in the left-hand side and then select the PC001).
> >
> > Hope this helps,
> >
> > Jacopo
> >
> >
> >>
> >> You mean it takes 0.5 to 1 day of work to do the above feature? Or
> >> just to do the "Copy an existing production run" feature? The above
> >> feature doesn't seem easy.
> >>
> >
> > Yes, the 1 day estimate was about the "Copy an existing
> production run"
> > feature; the other one is not so easy, even if there is already a
> lot of
> > stuff in place.
> >
> > Jacopo
> >
> >> Jonathon
> >>
> >> Jacopo Cappellato wrote:
> >>> Yes, the copy of a production run is not currently implemented
> (but
> >>> it should be a rather easy task, let's say 0.5 to 1 day of
> work, for
> >>> a developer with a good knowledge of OFBiz).
> >>> The main reason is that, usually (for non pc - type products) the
> >>> production run is quickly created from the bom and the routing
> (that
> >>> both represents the 'template' for the production run).
> >>> For pc-like products, the initial plan was to store the
> configuration
> >>> (there is already the entity for this) and then use it in the
> system
> >>> to do various tasks, such as:
> >>> - statistics of top sold configurations
> >>> - pre-configured items proposed to the customers
> >>> - creation of new production runs based on the configuration id
> (this
> >>> is what you would need here)
> >>> - planning
> >>> - bom explosions
> >>> - and, most of all, by storing the configuration there will be no
> >>> need to immediately create the production run when the order is
> >>> created as is now (having a more flexible system).
> >>>
> >>> Jacopo
> >>>
> >>>> Jonathon
> >>>
> >>>
> >>>
> >
> >
> >