Hi Axel, > Schöne Grüße > Axel > -- thank you in advance for avoiding the two minus "--" on top of your messages. It is time-consuming to reply your posts, because everything after the -- is interpreted as signature and just cut away. >Written from cell phone. Excuses for typos. >On 5. Juli 2014 13:01:21 MESZ, Mathias Behrle <[email protected]> wrote: >>* Dr. Axel Braun: " Re: [tryton] Attachments to Products vs >> Product-Variants" (Sat, 05 Jul 2014 09:23:37 +0200): >>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... 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. Regards Udo Spallek [1] http://videos.tryton.org/tub2013/TrytonAndInsuranceCoopengo.html -- virtual things Preisler & Spallek GbR München - Aachen Windeckstr. 77 81375 München Tel: +49 (89) 710 481 55 Fax: +49 (89) 710 481 56 [email protected] http://www.virtual-things.biz
signature.asc
Description: PGP signature
