* 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
