El 08/07/2014 13:08, "Axel Braun" <axel.br...@gmx.de> 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 > Hope this gives some food for thoughts > Axel Try to search in Tryton's ecosystem before say that something doesn't exists. And if some feature or use case is not supported, think in invest to get it.
