Re: [tryton] Attachments to Products vs Product-Variants
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.
Re: [tryton] Attachments to Products vs Product-Variants
Am 09.07.2014 09:08, schrieb Guillem Barba Domingo: El 08/07/2014 13:08, Axel Braun axel.br...@gmx.de mailto: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 Who has developed this ;)
Re: [tryton] Attachments to Products vs Product-Variants
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' solutioneven with some of the large SW manufacturers... signature.asc Description: This is a digitally signed message part.
Re: [tryton] Attachments to Products vs Product-Variants
2014-07-06 11:42 GMT+02:00 Guillem Barba Domingo guillemba...@gmail.com: 2014-07-06 11:37 GMT+02:00 Guillem Barba Domingo guillemba...@gmail.com: 2014-07-05 17:14 GMT+02:00 Dale Scott dalesc...@shaw.ca: On Jul 5, 2014, at 7:30 AM, Cédric Krier cedric.kr...@b2ck.com wrote: On 05 Jul 14:38, Axel Braun wrote: Believe me, we did, and came around exactly that problem. You always seem to not know at all Tryton. For sure that's me, I'm trying to learn fast! ;-) Thanks everyone for your opinions. If I understand correctly, it seems the variation functionality applies best in cases of simple differences that do not affect price (selling S/M/L t-shirt example) or do not trigger other changes (counter-example of car requiring larger generator for climate control variation). If this model does not fit the situation, one can always a) use multiple products and ignore the variation functionality, or b) customize code as needed for the specific situation. That seems fair. Exactly. It's very common to don't require to work with different variants. With this use case the current UX is not the best, but it is a good solution to have the same base code supporting variants and no variants. The current design allow to get any Template's field from product in the code. If you have a product.variant instance variant, you can't have a code that takes the name field from it and it will return the template's name transparently: product_name = variant.name Recovering the original topic of thread, I think it could be useful (I don't know nor investigated if it is hard to implement) that the Template's attachments will be available from product form. Sorry for the noise. I just discovered that the context menu over Many2One field have the Attachments... entry, so there is an easy way to get the attachments of product's template from product form. I still think that have the template's attachment in the product's attachment list is a good option. -- Guillem Barba http://www.guillem.alcarrer.net
Re: [tryton] Attachments to Products vs Product-Variants
On 06 Jul 12:03, Guillem Barba Domingo wrote: I still think that have the template's attachment in the product's attachment list is a good option. I don't think because it will blur the design of attachment popup. If you start to mix the origins, user will never know what he is seeing nor what will be done if it adds one. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgp199h_eQ4AB.pgp Description: PGP signature
Re: [tryton] Attachments to Products vs Product-Variants
2014-07-06 12:36 GMT+02:00 Cédric Krier cedric.kr...@b2ck.com: On 06 Jul 12:03, Guillem Barba Domingo wrote: I still think that have the template's attachment in the product's attachment list is a good option. I don't think because it will blur the design of attachment popup. If you start to mix the origins, user will never know what he is seeing nor what will be done if it adds one. You are right. And the entry in Many2One context menu is pretty enough. -- Guillem Barba http://www.guillem.alcarrer.net
Re: [tryton] Attachments to Products vs Product-Variants
On 05 Jul 11:55, Cédric Krier wrote: On 05 Jul 09:23, Dr. Axel Braun wrote: 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. So please before spreading FUD on the solution which is configurable and working well, test it. Indeed the current design is a quite well balanced between the simple needs and the more complex needs. And about the cost/prices etc., it is a matter of «configuration» to move down the fields to the variant level. The code is design to support that as you can see here: http://hg.tryton.org/modules/stock/file/0f6d3b754d7c/move.py#l546 http://hg.tryton.org/modules/account_stock_continental/file/cba1300f048b/product.py#l271 http://hg.tryton.org/modules/production/file/3eea8c2eb0c7/production.py#l294 http://hg.tryton.org/modules/production/file/3eea8c2eb0c7/production.py#l426 But I agree it is a little bit complex to remove the required from the template but it is not unsolvable. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgpELjE4nXSEc.pgp Description: PGP signature
Re: [tryton] Attachments to Products vs Product-Variants
* 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. 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. 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... 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 -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: [tryton] Attachments to Products vs Product-Variants
Schöne Grüße Axel -- Written from cell phone. Excuses for typos. On 5. Juli 2014 11:55:37 MESZ, Cédric Krier cedric.kr...@b2ck.com wrote: On 05 Jul 09:23, Dr. Axel Braun wrote: 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. So please before spreading FUD on the solution which is configurable and working well, test it. Believe me, we did, and came around exactly that problem. @Matthias: yes, experience is based on 3.0
Re: [tryton] Attachments to Products vs Product-Variants
Schöne Grüße Axel -- Written from cell phone. Excuses for typos. On 5. Juli 2014 13:01:21 MESZ, Mathias Behrle mbeh...@m9s.biz 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
Re: [tryton] Attachments to Products vs Product-Variants
On 05 Jul 14:38, Axel Braun wrote: Believe me, we did, and came around exactly that problem. You always seem to not know at all Tryton. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgpcs_w6O_CQa.pgp Description: PGP signature
Re: [tryton] Attachments to Products vs Product-Variants
On Jul 5, 2014, at 7:30 AM, Cédric Krier cedric.kr...@b2ck.com wrote: On 05 Jul 14:38, Axel Braun wrote: Believe me, we did, and came around exactly that problem. You always seem to not know at all Tryton. For sure that's me, I'm trying to learn fast! ;-) Thanks everyone for your opinions. If I understand correctly, it seems the variation functionality applies best in cases of simple differences that do not affect price (selling S/M/L t-shirt example) or do not trigger other changes (counter-example of car requiring larger generator for climate control variation). If this model does not fit the situation, one can always a) use multiple products and ignore the variation functionality, or b) customize code as needed for the specific situation. That seems fair.
Re: [tryton] Attachments to Products vs Product-Variants
El 05/07/14 13:01, Mathias Behrle ha escrit: 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... Perhaps this could be included like: Implement also list and cost price on variant with a Boolean 'Use prices from template'. 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. I also agree that providing the possibility to define prices on the variant, in addition on the template, would be a useful improvement. Adding list and cost prices and a Boolean 'Use prices from template' on the variants sounds good. It is a similar solution as how taxes and accounts can be defined in the product template or in the product category. -- Jordi Esteve Consultor Zikzakmedia SL jest...@zikzakmedia.com Mòbil 679 170 693 Zikzakmedia SL St. Jaume, 9, baixos, 2a 08720 Vilafranca del Penedès Tel 93 890 2108
Re: [tryton] Attachments to Products vs Product-Variants
On 05 Jul 19:10, Jordi Esteve (Zikzakmedia) wrote: El 05/07/14 13:01, Mathias Behrle ha escrit: 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... Perhaps this could be included like: Implement also list and cost price on variant with a Boolean 'Use prices from template'. 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. I also agree that providing the possibility to define prices on the variant, in addition on the template, would be a useful improvement. Adding list and cost prices and a Boolean 'Use prices from template' on the variants sounds good. It is a similar solution as how taxes and accounts can be defined in the product template or in the product category. There is a big mistake here. Cost price is something really different of list price and so both must be managed differently. I don't think list price should be moved to variant but more the possibility to add an extra per variant. And this is very, very easy to do now because the design was thought for that. For cost price, it think it should probably not move but instead we should compute both the cost price of the template and the cost price of the variant. Just like I explained in previous email about the cost price per warehouse. They are all new indicators. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgp2Kjhyiso1g.pgp Description: PGP signature
Re: [tryton] Attachments to Products vs Product-Variants
El 05/07/14 19:30, Cédric Krier ha escrit: On 05 Jul 19:10, Jordi Esteve (Zikzakmedia) wrote: El 05/07/14 13:01, Mathias Behrle ha escrit: 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... Perhaps this could be included like: Implement also list and cost price on variant with a Boolean 'Use prices from template'. 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. I also agree that providing the possibility to define prices on the variant, in addition on the template, would be a useful improvement. Adding list and cost prices and a Boolean 'Use prices from template' on the variants sounds good. It is a similar solution as how taxes and accounts can be defined in the product template or in the product category. There is a big mistake here. Cost price is something really different of list price and so both must be managed differently. I don't think list price should be moved to variant but more the possibility to add an extra per variant. And this is very, very easy to do now because the design was thought for that. It is more common to define the final price for each variant, instead of template price + extra price. For example tablet 8Gb 250 eur and tablet 16Gb 300 eur instead of tablet 16Gb 250+50 eur. Anyway, it is easy to add (if core module doesn't include it) a field for the variant list price and compute the variant extra price as variant extra price = variant list price - template list price For cost price, it think it should probably not move but instead we should compute both the cost price of the template and the cost price of the variant. Just like I explained in previous email about the cost price per warehouse. They are all new indicators. I don't understand that variant cost price is only an indicator. For example, if you use fixed cost method, the tablet 8Gb and tablet 16Gb has different cost prices, because the second one is more expensive to purchase/produce. How could be introduced the different cost prices for tablet 8Gb and tablet 16Gb variants? -- Jordi Esteve Consultor Zikzakmedia SL jest...@zikzakmedia.com Mòbil 679 170 693 Zikzakmedia SL St. Jaume, 9, baixos, 2a 08720 Vilafranca del Penedès Tel 93 890 2108
Re: [tryton] Attachments to Products vs Product-Variants
On 05 Jul 20:02, Jordi Esteve (Zikzakmedia) wrote: El 05/07/14 19:30, Cédric Krier ha escrit: On 05 Jul 19:10, Jordi Esteve (Zikzakmedia) wrote: El 05/07/14 13:01, Mathias Behrle ha escrit: 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... Perhaps this could be included like: Implement also list and cost price on variant with a Boolean 'Use prices from template'. 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. I also agree that providing the possibility to define prices on the variant, in addition on the template, would be a useful improvement. Adding list and cost prices and a Boolean 'Use prices from template' on the variants sounds good. It is a similar solution as how taxes and accounts can be defined in the product template or in the product category. There is a big mistake here. Cost price is something really different of list price and so both must be managed differently. I don't think list price should be moved to variant but more the possibility to add an extra per variant. And this is very, very easy to do now because the design was thought for that. It is more common to define the final price for each variant, instead of template price + extra price. For example tablet 8Gb 250 eur and tablet 16Gb 300 eur instead of tablet 16Gb 250+50 eur. Anyway, it is easy to add (if core module doesn't include it) a field for the variant list price and compute the variant extra price as The design will allow to do what you suggest, just put 0 in template price. And I think this could be a standard module. For cost price, it think it should probably not move but instead we should compute both the cost price of the template and the cost price of the variant. Just like I explained in previous email about the cost price per warehouse. They are all new indicators. I don't understand that variant cost price is only an indicator. For example, if you use fixed cost method, the tablet 8Gb and tablet 16Gb has different cost prices, because the second one is more expensive to purchase/produce. How could be introduced the different cost prices for tablet 8Gb and tablet 16Gb variants? Because cost prices are really just indicators, you should not confound with the purchase price. Also perhaps your example is wrong and they should not be variants. I think a good way to know if products should be variants or not, it is to think if the global quantity (quantity of template) has a meaning. The canonical example is T-shirt with colors as variant differenciation. In such example, the quantity of T-shirt has a complet valid meaning. With your example, I don't find very meaningful the number of tablets. Also you should remember that product supplier information are on template, so they should normally share the same supplier code, same purhcase price etc. But of course it could still be customize to add variant extra. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ pgppzIShWdMBv.pgp Description: PGP signature
Re: [tryton] Attachments to Products vs Product-Variants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2014 15:30, schrieb Cédric Krier: On 05 Jul 14:38, Axel Braun wrote: Believe me, we did, and came around exactly that problem. You always seem to not know at all Tryton. How does this comment contribute to the topic? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO4WUYACgkQG9b1OutI7yJ9kQCeKtuLufuMTjET0bN7zQGoCbp7 PF4An1hN75xbgtf1tfqpeNHnyN1OWcuQ =DzvY -END PGP SIGNATURE-
[tryton] Attachments to Products vs Product-Variants
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. Dale
Re: [tryton] Attachments to Products vs Product-Variants
On Jul 5, 2014, at 8:59 AM, Dale Scott d...@dalescott.net wrote: 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** Varying Attribute: Platform http://www.amazon.com/Call-Duty-Advanced-Warfare-Xbox-One/dp/B00K308KF4 Here the product is: Call of Duty: Advanced Warfare And the variants are: for PS3, Xbox, PC, PS4 etc **Variation on Two attributes** Varying attributes: Size, Color http://www.amazon.com/Cole-Haan-Lunargrand-Saddle-Oxford/dp/B00HB1PDTE Here the product is: Cole Haan Men's Lunargrand Saddle Oxford And the variants are: 12 sizes X 2 Colors = 24 variants As for your question about attachments: It depends on the nature of the products and variants. For example if you were to use iPhone as a product and the three sizes of 16GB, 32Gb and 64 GB as variants, then the specifications would be different for each variant while the user guide would the same since all of the user instructions for the series is same. Similarly, the images may vary by the iPhone color, but not by the size. So this depends if those documents you attach change by variant or change by product (template). Thanks Regards Sharoon Thomas CEO Chief Software Architect Openlabs Technologies Consulting (P) Limited w: http://www.openlabs.co.in m: +1 813.793.6736 (OPEN) Extn. 200 t: @sharoonthomas - We win when our customers win signature.asc Description: Message signed with OpenPGP using GPGMail
