Am 09.07.2014 09:08, schrieb Guillem Barba Domingo: > > El 08/07/2014 13:08, "Axel Braun" <[email protected] > <mailto:[email protected]>> va escriure: > > > > > >>I can't see the complexity. If you don't want variants, just > don't use > > > >>them. > > > >>When only using menu products, you are just working transparently on > > > >>the first > > > >>variant. > > > > > > > >In most cases you have to attach relationship formulas to product > > > >attributes, like: when ordering a climate control with the car, you > > > >need the bigger generator as well. This adds complexity, but I > agree, > > > >it us more than just a variant. Don't know if Tryton can deal with > > > >that... > > > > > > For me this goes far beyond a conception of variants. > > > > > > Your description sounds like a product configurator, which would be > > > able to add priced options to a basic product. > > > The result could be a new product which is assembled of parts > following > > > certain rule-sets. > > > For your car example, this could be implemented as a sale front-end > > > which defines a BOM, production, approx. delivery date, purchase > > > requests, list price calculation... > > > > Indeed, the variant configuration is the full-blown implementation > of product > > variants > > > > > We have seen a demonstration of a similar implementation for a product > > > configurator specific to insurance products at TUB 2013[1]. Jean > Cavallo > > > from coopengo shows us special insurance products defined by > > > processes, steps and rules. > > > > I remember, yes. > > And having thought more about it, I feel the current implementation of > > variants adds unnecessary complexity for the standard case, as you > have to > > create product template and variant even for standard products. > > Hi Axel, > I think you haven't read my answer to Dal Scott at July 6. > There, I explained why the base product module implements a very > lightweight product template-variant separation. > I also noticed you about a module that improve the UX for simple cases > (without variants), which should be improved with some enhancements as > I detailed in the message. > > > On the other hand, pricing and costing on variant is not possible > (except you > > modify coding, as Cedric explained), so you can not even gain > advantage from > > this. > > > > Under that light, enbling variants via a second module would be the > better > > approach. > > > > [looking over the fence] > > The requirement to cope with product variants is quite common. In > most cases > > it is solved with just adding additional materials for the different > variants > > (shirt sizes and colors, etc). Not the most advanced solution, but > solves the > > problem. > > Specially in the Apparel and footwear market various specialized > solutions > > exist that implement product variants or matrices for color, size, > waist, > > width (and other attributes). > > But nobody would really go the path to implement such a solution for > 'normal' > > products w/o variants, due to the complexity. > > Tryton is a framework, so base modules try to be as simple as posible > (and powerful an extensible). > Otger modules (in core or not) extend them to have "end user" > solutions. These modules could be already implemebted or not. > > About "product configurator", ZikZakMedia developed the > product_variant [1] module which provably provide what you say. > > http://www.bitbucket.org/zikzakmedia/trytond-product_variant >
Who has developed this ;)
