Originally Posted by
mc12345678
If I may clarify a little further based on the current implementation.
The custom ID is something self entered (there is no requirement to have use it)
For a product that has a single option name, a customid could be applied to a single option value. (Quantity of product is available in 1, 2, 4, and 8 pieces then each of those options could have its own customid, none, or a mixture of one provided for some and none for the others.)
For a product that has multiple option names for a product (typical example is a shoe that is available in a color and a size) then the current implementation allows a custom ID to be applied to each such pairing of color and size (blue-9, green-10). For a product with three option names, then the combination of three option values would be used to which a single customid could be provided... Assume a shirt that is available in adult and child (two option values for a single option name) that is available in three colors (white, blue, black), and in four different sizes (S, M, L, XL) then some of the combinations available to which each has a customid available would be:
Adult-white-S : shirt1
Child-Blue-M: shirt2
Adult-Black-XL: shirt3
Where shirt1, shirt2 and shirt3 could be the customid that is entered.
With a total of 24 combinations available to be assigned in the above example.
The data (value of the customid) currently is then provided on the invoice, the email, in the order history, etc. (areas where the selected attributes are presented) in some cases in replacement of the model# while the model# is generally still available as well... Where a customid is not provided but the desire is to display customids then the model # is provided instead (whether that be blank or some data).
Bookmarks