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