Hi Udo, Am Sonntag, 6. Juli 2014, 22:00:23 schrieb Udo Spallek:
> > -- > > thank you in advance for avoiding the two minus "--" on top of your > messages. In fact it is minus-minus-whitespace according to RFC 850... > It is time-consuming to reply your posts, because everything > after the -- is interpreted as signature and just cut away. Agree, cell phone mailing programs have some disadvantages, when trying to quote inline.... > >>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. 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. Hope this gives some food for thoughts Axel PS: Not in all cases this approach of ERP systems specialized for Apparel & Footwear can not be transferred to Retrails systems, so in the shops they have to go back to the 'create additional materials' solution....even with some of the large SW manufacturers...
signature.asc
Description: This is a digitally signed message part.
