Schöne Grüße Axel -- 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): > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 05.07.2014 07:57, schrieb Sharoon Thomas: >> >> >>>> Hi, I've been attaching documents (e.g. datasheets, >> >>>> specifications, work instructions, gerber files, >> >>>> schematics...) to all the product I have imported. In the >> >>>> process, I found an attachment to a product is not the same >> >>>> as an attachment to a product variant. >> >>>> >> >>>> Can someone explain the basic concept of products and product >> >>>> variants? Should I be attaching documents to the product, or >> >>>> to product variants? What is the difference? How to the user >> >>>> cases differ? Fwiw, I find the product variant grid >> >>>> convenient because it includes the product code for each >> >>>> product in the kanban view. >> >>> >> >>> Explanation by a live example: >> >>> >> >>> **Variation on one attribute** >> >> [....] >> >> >> Makes sense. It seems creating a new product also creates one >> >> variant for that product. In this case (only one variant), does >> >> it matter if you purchase or sell, or otherwise manage, the >> >> product - or the variation? In other words, are the product and >> >> the only variation synonymous for some purposes? >> > >> > You cannot sell a product (template), you always sell, purchase and >> > manage (for stock/inventory) variations. When you have only one >> > variant for a product (template) you are effectively dealing with >> > the product itself. >> > >> > So template itself just seems like a useful collection of real >> > products. >> >> You need to explain this sentence. >> In 99% of all cases you dont need a varaiant to a product. So forcing >> The user to create a variant by default is...unlucky design... > >I assume, that you speak from experiences of Tryton versions < 3.2.
Indeed. In >3.2 just >one default variant is created, whether you create it from menu >products or >variants. > >> Even in software packages that can handle variant configuration, >users >> try to avoid this due to the complexity of this. > >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... >> > However, do remember that it is not possible to have prices on >> > product variations (at least from the standard modules). So, in a >> > way this makes an assumption that all variants have the same and >> > cost price (which is rarely true with at least Openlabs >> > customers). >> >> Interesting. Different price per variant would exactly be what the >> user needs, as Apple is making the big revenues on the 64GB variant >> compared to the 8GB. Similar as car manufacturers make a high profit >> on extras. > >So here you are advocating variants... There us nothing bad about it - if you need it. But having it in general is not the best idea... >Perhaps this could be included like: >Implement also list and cost price on variant with a Boolean 'Use >prices from >template'. > >> Bottom-line: current solution increases complexity without adding >real >> benefit. Ideally this would be configurable (e.g. different material >> type for configurable materials) and have just 'material' for the >> standard, instead of template/variant. > >I prefer the current solution a lot to what it was before, when we had >to enable variants by a second module. It is a minimalistic design as >usual >allowing for extensibility. Nevertheless I agree, that it would be a >welcome >feature to provide the possibility to define prices on the variant in >the base >module. > >Cheers, >Mathias
