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: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgppzIShWdMBv.pgp
Description: PGP signature
