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