Re: Product features, virtuals and variants: an alternative approach.

[Hans Bakker <ma...@antwebsystems.com>]

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

Re: Product features, virtuals and variants: an alternative approach.

[Mridul Pathak <mr...@hotwaxmedia.com>]

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 <ma...@antwebsystems.com>
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
mridul.pathak@hotwaxmedia.com
__________________________________
Office : 509.855.4113
Mobile : +919425926892