Product features, virtuals and variants: an alternative approach.

[hans_bakker]

Good morning! (at least for me it is...)

As I have written before I have a customer who has many variants (>1000)
which do not really fit in categories or configurations and it has to
work with drop-shipments.
This alternative proposal has practically no limit on the number of
variants and is largely compatible with the current implementation.

Please let me know for comments/questions and enhancements and what the
opinion of the community is, and if this is a valuable addition to the
current system.

Regards,
Hans



Current function in OFBiz.
--------------------------
The OFBiz system has a facility to allow the selection of variants of a
basic product called a 'virtual' product, for example a t-shirt. This
shirt can have colors and sizes. These colors and sizes can be defined
in features types. Features relate to these feature types and specify
the actual sizes and colors. These features can be specified on the
virtual product as selectable features and as standard features on the
variant products. Not all feature combinations need to be there if
certain features combinations are not available or compatible. Only
feature combinations which result in existing variant products can be
selected when the product is ordered.

Current implementation.
-----------------------
The current OFBiz implementation builds a variant tree according the
features listed on the virtual product, checks if the related variant is
present. When not found, the feature will not be in the tree and cannot
be selected. This is fine upto about 200 variants. if more variants are
present, the time to built the tree and the size become too big. The
service used is called 'getProductVariantTree' and is called from the
productdetail.bsh program.

Proposed alternative approach.
------------------------------
Instead of creating a variant tree, a feature tree should be created
using the specified features on the virtual product without checking the
available variants. In order to be able to specify incompatibilities
between features the existing entity 'ProductFeatureIactn' should be
used where general (no productId) or specific (with productId)
dependencies or incompatibilities can be specified.
If a feature selection is done at order entry, the related variant
should be found which has all these standard features. If the variant
can be found, the processing is the same as it is now: this variant will
be added to the shoppingcart using the variant prices.
If the variant cannot be found, the system will create the variant
automatically, using the prices in the to be created 'FeaturePrice'
entity similar to the 'ProductPrice' entity. The prices in this table
however are price adjustments to the price specified on the virtual
product.

This new approach can be added to the existing implementation by adding
a field to the product or allow more values in the 'isVirtual' field and
change the processing accordingly.

--
AntWebsystems.com: Quality OFBiz services for competitive rates.....

[SkipDever]

I have this URL

https://localhost:8443/purchasing/control/viewEoqItem?listIterator=org.ofbiz
.base.util.EntityListIteratorContainer@15d9be1&facilityId=PDI(1)-BOTHELL&pro
ductId=ADD-BEGINNER&next=Y&qtyToOrder_o_0=3&session=org.apache.catalina.sess
ion.StandardSessionFacade@1499154&update=Y

Note the
listIterator=org.ofbiz.base.util.EntityListIteratorContainer@15d9be1 part

I have this bit of bsh script called as part of my "viewEoqItem" url:

        EntityListIteratorContainer container = parameters.get("listIterator");
        if(container == null)
        {
                container = new EntityListIteratorContainer(delegator, "productId",
"InventorySoldSummary",
                        conditionList, null, null, UtilMisc.toList("productId"), null);
        }

        context.put("listIterator", container);

And this ftl:

    < input type="hidden" name="listIterator" value="${listIterator}"/>

When the submit button gets pressed, the listIterator is available to the
service called here:

    <request-map uri="updateSingleEoqValue">
        <security https="true" auth="true"/>
        <event type="service" invoke="updateOneEOQRequirement"/>
        <response name="success" type="request-redirect"
value="viewEoqItem"/>
        <response name="error" type="request-redirect" value="viewEoqItem"/>
    </request-map>



However, the listIterator causes a ClassCastException in the bash script the
second time through on the line:

        EntityListIteratorContainer container = parameters.get("listIterator");

Anyone have an idea what I am doing wrong with this?  This is an experiment
to see if I can keep this EntityListIteratorContainer only as long as it
keeps getting passed in URLs.

Hope someone can help.

Skip




No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.8/1339 - Release Date: 3/22/2008
4:43 PM

[Jacopo Cappellato-3]

Hans,

it looks good to me; please see my comment below:

On Mar 26, 2008, at 9:02 PM, Hans Bakker wrote:

> Good morning! (at least for me it is...)
>
> As I have written before I have a customer who has many variants  
> (>1000)
> which do not really fit in categories or configurations and it has to
> work with drop-shipments.
> This alternative proposal has practically no limit on the number of
> variants and is largely compatible with the current implementation.
>
> Please let me know for comments/questions and enhancements and what  
> the
> opinion of the community is, and if this is a valuable addition to the
> current system.
>
> Regards,
> Hans
>
>
>
> Current function in OFBiz.
> --------------------------
> The OFBiz system has a facility to allow the selection of variants  
> of a
> basic product called a 'virtual' product, for example a t-shirt. This
> shirt can have colors and sizes. These colors and sizes can be defined
> in features types. Features relate to these feature types and specify
> the actual sizes and colors. These features can be specified on the
> virtual product as selectable features and as standard features on the
> variant products. Not all feature combinations need to be there if
> certain features combinations are not available or compatible. Only
> feature combinations which result in existing variant products can be
> selected when the product is ordered.
>
> Current implementation.
> -----------------------
> The current OFBiz implementation builds a variant tree according the
> features listed on the virtual product, checks if the related  
> variant is
> present. When not found, the feature will not be in the tree and  
> cannot
> be selected. This is fine upto about 200 variants. if more variants  
> are
> present, the time to built the tree and the size become too big. The
> service used is called 'getProductVariantTree' and is called from the
> productdetail.bsh program.
>
> Proposed alternative approach.
> ------------------------------
> Instead of creating a variant tree, a feature tree should be created
> using the specified features on the virtual product without checking  
> the
> available variants. In order to be able to specify incompatibilities
> between features the existing entity 'ProductFeatureIactn' should be
> used where general (no productId) or specific (with productId)
> dependencies or incompatibilities can be specified.
> If a feature selection is done at order entry, the related variant
> should be found which has all these standard features. If the variant
> can be found, the processing is the same as it is now: this variant  
> will
> be added to the shoppingcart using the variant prices.
> If the variant cannot be found, the system will create the variant
> automatically, using the prices in the to be created 'FeaturePrice'
> entity similar to the 'ProductPrice' entity. The prices in this table
> however are price adjustments to the price specified on the virtual
> product.
>
> This new approach can be added to the existing implementation by  
> adding
> a field to the product or allow more values in the 'isVirtual' field  
> and
> change the processing accordingly.
>

We may also use a new product type for this.

Jacopo


> --
> AntWebsystems.com: Quality OFBiz services for competitive rates.....
>

[Mridul Pathak-2]

Hans,

I have a question regarding the new approach:
As you said that at the time of order entry customer selects a set of
features and if a variant with that particular set of standard features is
not found, a new product is created for that.
My question is, can't it be possible that a customer selects a set of
features for which no variant exists and also the company does not sell such
a product?  In that case a wrong product will be created at the time of
order entry.  For example a company sells Sofa's of different color and
sizes.  Now it may be possible that for small size there are four color
variations and for the medium size only three are available.  In such a case
if a user selects the fourth color variation for the medium size Sofa, a
wrong product will be created at the time of order entry.

For this, if this is a problem at all, we may put constraints on the feature
selection, but I am not sure how and that may be cumbersome.  With the
current implementation based on the Variant tree, I think it is possible to
put such constraints at the time of feature selection.

May be I am getting this wrong, but just a thought from my side.


On Thu, Mar 27, 2008 at 8:32 AM, Hans Bakker <[hidden email]>
wrote:

> Good morning! (at least for me it is...)
>
> As I have written before I have a customer who has many variants (>1000)
> which do not really fit in categories or configurations and it has to
> work with drop-shipments.
> This alternative proposal has practically no limit on the number of
> variants and is largely compatible with the current implementation.
>
> Please let me know for comments/questions and enhancements and what the
> opinion of the community is, and if this is a valuable addition to the
> current system.
>
> Regards,
> Hans
>
>
>
> Current function in OFBiz.
> --------------------------
> The OFBiz system has a facility to allow the selection of variants of a
> basic product called a 'virtual' product, for example a t-shirt. This
> shirt can have colors and sizes. These colors and sizes can be defined
> in features types. Features relate to these feature types and specify
> the actual sizes and colors. These features can be specified on the
> virtual product as selectable features and as standard features on the
> variant products. Not all feature combinations need to be there if
> certain features combinations are not available or compatible. Only
> feature combinations which result in existing variant products can be
> selected when the product is ordered.
>
> Current implementation.
> -----------------------
> The current OFBiz implementation builds a variant tree according the
> features listed on the virtual product, checks if the related variant is
> present. When not found, the feature will not be in the tree and cannot
> be selected. This is fine upto about 200 variants. if more variants are
> present, the time to built the tree and the size become too big. The
> service used is called 'getProductVariantTree' and is called from the
> productdetail.bsh program.
>
> Proposed alternative approach.
> ------------------------------
> Instead of creating a variant tree, a feature tree should be created
> using the specified features on the virtual product without checking the
> available variants. In order to be able to specify incompatibilities
> between features the existing entity 'ProductFeatureIactn' should be
> used where general (no productId) or specific (with productId)
> dependencies or incompatibilities can be specified.
> If a feature selection is done at order entry, the related variant
> should be found which has all these standard features. If the variant
> can be found, the processing is the same as it is now: this variant will
> be added to the shoppingcart using the variant prices.
> If the variant cannot be found, the system will create the variant
> automatically, using the prices in the to be created 'FeaturePrice'
> entity similar to the 'ProductPrice' entity. The prices in this table
> however are price adjustments to the price specified on the virtual
> product.
>
> This new approach can be added to the existing implementation by adding
> a field to the product or allow more values in the 'isVirtual' field and
> change the processing accordingly.
>
> --
> AntWebsystems.com: Quality OFBiz services for competitive rates.....
>
>

--
Thanks & Regards
Mridul Pathak
Hotwax Media
http://www.hotwaxmedia.com
[hidden email]
__________________________________
Office : 509.855.4113
Mobile : [phone]

[hans_bakker]

Hi Mridul.

On Thu, 2008-03-27 at 20:21 +0530, Mridul Pathak wrote:
> .....
> My question is, can't it be possible that a customer selects a set of
> features for which no variant exists and also the company does not sell such
> a product?  

These incompabilities of features can be entered in a existing table
called 'ProductFeatureIactn'. We will add some screens to maintain this
table.

Regards,
Hans

> >
> > Current function in OFBiz.
> > --------------------------
> > The OFBiz system has a facility to allow the selection of variants
> of a
> > basic product called a 'virtual' product, for example a t-shirt.
> This
> > shirt can have colors and sizes. These colors and sizes can be
> defined
> > in features types. Features relate to these feature types and
> specify
> > the actual sizes and colors. These features can be specified on the
> > virtual product as selectable features and as standard features on
> the
> > variant products. Not all feature combinations need to be there if
> > certain features combinations are not available or compatible. Only
> > feature combinations which result in existing variant products can
> be
> > selected when the product is ordered.
> >
> > Current implementation.
> > -----------------------
> > The current OFBiz implementation builds a variant tree according the
> > features listed on the virtual product, checks if the related
> variant is
> > present. When not found, the feature will not be in the tree and
> cannot
> > be selected. This is fine upto about 200 variants. if more variants
> are
> > present, the time to built the tree and the size become too big. The
> > service used is called 'getProductVariantTree' and is called from
> the
> > productdetail.bsh program.
> >
> > Proposed alternative approach.
> > ------------------------------
> > Instead of creating a variant tree, a feature tree should be created
> > using the specified features on the virtual product without checking
> the
> > available variants. In order to be able to specify incompatibilities
> > between features the existing entity 'ProductFeatureIactn' should be
> > used where general (no productId) or specific (with productId)
> > dependencies or incompatibilities can be specified.
> > If a feature selection is done at order entry, the related variant
> > should be found which has all these standard features. If the
> variant
> > can be found, the processing is the same as it is now: this variant
> will
> > be added to the shoppingcart using the variant prices.
> > If the variant cannot be found, the system will create the variant
> > automatically, using the prices in the to be created 'FeaturePrice'
> > entity similar to the 'ProductPrice' entity. The prices in this
> table
> > however are price adjustments to the price specified on the virtual
> > product.
> >
> > This new approach can be added to the existing implementation by
> adding
> > a field to the product or allow more values in the 'isVirtual' field
> and
> > change the processing accordingly.
> >
> > --
> > AntWebsystems.com: Quality OFBiz services for competitive rates.....
> >
> >
>
>

--
AntWebsystems.com: Quality OFBiz services for competitive rates.....

[Mridul Pathak-2]

Thanks Hans for clarifying my doubts.  This is really a nice functionality
and will be very useful if added to OFBiz.


On Fri, Mar 28, 2008 at 6:52 AM, Hans Bakker <[hidden email]>
wrote:

> Hi Mridul.
>
> On Thu, 2008-03-27 at 20:21 +0530, Mridul Pathak wrote:
> > .....
> > My question is, can't it be possible that a customer selects a set of
> > features for which no variant exists and also the company does not sell
> such
> > a product?
>
> These incompabilities of features can be entered in a existing table
> called 'ProductFeatureIactn'. We will add some screens to maintain this
> table.
>
> Regards,
> Hans
>
>
>
> > >
> > > Current function in OFBiz.
> > > --------------------------
> > > The OFBiz system has a facility to allow the selection of variants
> > of a
> > > basic product called a 'virtual' product, for example a t-shirt.
> > This
> > > shirt can have colors and sizes. These colors and sizes can be
> > defined
> > > in features types. Features relate to these feature types and
> > specify
> > > the actual sizes and colors. These features can be specified on the
> > > virtual product as selectable features and as standard features on
> > the
> > > variant products. Not all feature combinations need to be there if
> > > certain features combinations are not available or compatible. Only
> > > feature combinations which result in existing variant products can
> > be
> > > selected when the product is ordered.
> > >
> > > Current implementation.
> > > -----------------------
> > > The current OFBiz implementation builds a variant tree according the
> > > features listed on the virtual product, checks if the related
> > variant is
> > > present. When not found, the feature will not be in the tree and
> > cannot
> > > be selected. This is fine upto about 200 variants. if more variants
> > are
> > > present, the time to built the tree and the size become too big. The
> > > service used is called 'getProductVariantTree' and is called from
> > the
> > > productdetail.bsh program.
> > >
> > > Proposed alternative approach.
> > > ------------------------------
> > > Instead of creating a variant tree, a feature tree should be created
> > > using the specified features on the virtual product without checking
> > the
> > > available variants. In order to be able to specify incompatibilities
> > > between features the existing entity 'ProductFeatureIactn' should be
> > > used where general (no productId) or specific (with productId)
> > > dependencies or incompatibilities can be specified.
> > > If a feature selection is done at order entry, the related variant
> > > should be found which has all these standard features. If the
> > variant
> > > can be found, the processing is the same as it is now: this variant
> > will
> > > be added to the shoppingcart using the variant prices.
> > > If the variant cannot be found, the system will create the variant
> > > automatically, using the prices in the to be created 'FeaturePrice'
> > > entity similar to the 'ProductPrice' entity. The prices in this
> > table
> > > however are price adjustments to the price specified on the virtual
> > > product.
> > >
> > > This new approach can be added to the existing implementation by
> > adding
> > > a field to the product or allow more values in the 'isVirtual' field
> > and
> > > change the processing accordingly.
> > >
> > > --
> > > AntWebsystems.com: Quality OFBiz services for competitive rates.....
> > >
> > >
> >
> >
> --
> AntWebsystems.com: Quality OFBiz services for competitive rates.....
>
>

--
Thanks & Regards
Mridul Pathak
Hotwax Media
http://www.hotwaxmedia.com
[hidden email]
__________________________________
Office : 509.855.4113
Mobile : [phone]

[Mridul Pathak-2]

Please see the comments below.

On Thu, Mar 27, 2008 at 4:57 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Hans,
>
> it looks good to me; please see my comment below:
>
> On Mar 26, 2008, at 9:02 PM, Hans Bakker wrote:
> > Good morning! (at least for me it is...)
> >
> > As I have written before I have a customer who has many variants
> > (>1000)
> > which do not really fit in categories or configurations and it has to
> > work with drop-shipments.
> > This alternative proposal has practically no limit on the number of
> > variants and is largely compatible with the current implementation.
> >
> > Please let me know for comments/questions and enhancements and what
> > the
> > opinion of the community is, and if this is a valuable addition to the
> > current system.
> >
> > Regards,
> > Hans
> >
> >
> >
> > Current function in OFBiz.
> > --------------------------
> > The OFBiz system has a facility to allow the selection of variants
> > of a
> > basic product called a 'virtual' product, for example a t-shirt. This
> > shirt can have colors and sizes. These colors and sizes can be defined
> > in features types. Features relate to these feature types and specify
> > the actual sizes and colors. These features can be specified on the
> > virtual product as selectable features and as standard features on the
> > variant products. Not all feature combinations need to be there if
> > certain features combinations are not available or compatible. Only
> > feature combinations which result in existing variant products can be
> > selected when the product is ordered.
> >
> > Current implementation.
> > -----------------------
> > The current OFBiz implementation builds a variant tree according the
> > features listed on the virtual product, checks if the related
> > variant is
> > present. When not found, the feature will not be in the tree and
> > cannot
> > be selected. This is fine upto about 200 variants. if more variants
> > are
> > present, the time to built the tree and the size become too big. The
> > service used is called 'getProductVariantTree' and is called from the
> > productdetail.bsh program.
> >
> > Proposed alternative approach.
> > ------------------------------
> > Instead of creating a variant tree, a feature tree should be created
> > using the specified features on the virtual product without checking
> > the
> > available variants. In order to be able to specify incompatibilities
> > between features the existing entity 'ProductFeatureIactn' should be
> > used where general (no productId) or specific (with productId)
> > dependencies or incompatibilities can be specified.
> > If a feature selection is done at order entry, the related variant
> > should be found which has all these standard features. If the variant
> > can be found, the processing is the same as it is now: this variant
> > will
> > be added to the shoppingcart using the variant prices.
> > If the variant cannot be found, the system will create the variant
> > automatically, using the prices in the to be created 'FeaturePrice'
> > entity similar to the 'ProductPrice' entity. The prices in this table
> > however are price adjustments to the price specified on the virtual
> > product.
> >
> > This new approach can be added to the existing implementation by
> > adding
> > a field to the product or allow more values in the 'isVirtual' field
> > and
> > change the processing accordingly.
> >
>
> We may also use a new product type for this.

Or may be we can add another field (something like isVirtual) to the entity
and use it in combination with isVariant in the same way it is done for
Virtual and Variant.
Another option can be to add a field in ProductStore or Product itself which
can be used to select one of the two approaches, i.e. use Feature Tree or
Variant Tree for the Virtual/Variant products (we can create enumeration for
this field).  This way the Virtual/Variant logic will remain untouched and
you will just need to specify the approach to be used while dealing with
such products.


>
> Jacopo
>
>
> > --
> > AntWebsystems.com: Quality OFBiz services for competitive rates.....
> >
>
>


--
Thanks & Regards
Mridul Pathak
Hotwax Media
http://www.hotwaxmedia.com
[hidden email]
__________________________________
Office : 509.855.4113
Mobile : [phone]

[Jacques Le Roux]

From: "Mridul Pathak" <[hidden email]>

> Please see the comments below.
>
> On Thu, Mar 27, 2008 at 4:57 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Hans,
>>
>> it looks good to me; please see my comment below:
>>
>> On Mar 26, 2008, at 9:02 PM, Hans Bakker wrote:
>> > Good morning! (at least for me it is...)
>> >
>> > As I have written before I have a customer who has many variants
>> > (>1000)
>> > which do not really fit in categories or configurations and it has to
>> > work with drop-shipments.
>> > This alternative proposal has practically no limit on the number of
>> > variants and is largely compatible with the current implementation.
>> >
>> > Please let me know for comments/questions and enhancements and what
>> > the
>> > opinion of the community is, and if this is a valuable addition to the
>> > current system.
>> >
>> > Regards,
>> > Hans
>> >
>> >
>> >
>> > Current function in OFBiz.
>> > --------------------------
>> > The OFBiz system has a facility to allow the selection of variants
>> > of a
>> > basic product called a 'virtual' product, for example a t-shirt. This
>> > shirt can have colors and sizes. These colors and sizes can be defined
>> > in features types. Features relate to these feature types and specify
>> > the actual sizes and colors. These features can be specified on the
>> > virtual product as selectable features and as standard features on the
>> > variant products. Not all feature combinations need to be there if
>> > certain features combinations are not available or compatible. Only
>> > feature combinations which result in existing variant products can be
>> > selected when the product is ordered.
>> >
>> > Current implementation.
>> > -----------------------
>> > The current OFBiz implementation builds a variant tree according the
>> > features listed on the virtual product, checks if the related
>> > variant is
>> > present. When not found, the feature will not be in the tree and
>> > cannot
>> > be selected. This is fine upto about 200 variants. if more variants
>> > are
>> > present, the time to built the tree and the size become too big. The
>> > service used is called 'getProductVariantTree' and is called from the
>> > productdetail.bsh program.
>> >
>> > Proposed alternative approach.
>> > ------------------------------
>> > Instead of creating a variant tree, a feature tree should be created
>> > using the specified features on the virtual product without checking
>> > the
>> > available variants. In order to be able to specify incompatibilities
>> > between features the existing entity 'ProductFeatureIactn' should be
>> > used where general (no productId) or specific (with productId)
>> > dependencies or incompatibilities can be specified.
>> > If a feature selection is done at order entry, the related variant
>> > should be found which has all these standard features. If the variant
>> > can be found, the processing is the same as it is now: this variant
>> > will
>> > be added to the shoppingcart using the variant prices.
>> > If the variant cannot be found, the system will create the variant
>> > automatically, using the prices in the to be created 'FeaturePrice'
>> > entity similar to the 'ProductPrice' entity. The prices in this table
>> > however are price adjustments to the price specified on the virtual
>> > product.
>> >
>> > This new approach can be added to the existing implementation by
>> > adding
>> > a field to the product or allow more values in the 'isVirtual' field
>> > and
>> > change the processing accordingly.
>> >
>>
>> We may also use a new product type for this.
>
>
> Or may be we can add another field (something like isVirtual) to the entity
> and use it in combination with isVariant in the same way it is done for
> Virtual and Variant.
> Another option can be to add a field in ProductStore or Product itself which
> can be used to select one of the two approaches, i.e. use Feature Tree or
> Variant Tree for the Virtual/Variant products (we can create enumeration for
> this field).  This way the Virtual/Variant logic will remain untouched and
> you will just need to specify the approach to be used while dealing with
> such products.

This sounds like an interesting approach indeed.

Jacues
 
>
>>
>> Jacopo