David when I read this I had a flashback and found this in my outbox of outlook, an email I sent u quite some time ago and I think maybe could be helpful here? :-D
_Considering Tirams issue with the clothes, I thought of separating the product name and description from the product itself, so that name and description can be related to one or more product IDs.
So it goes for the attributes which can be related to one or more product IDs as well.
That way u can have several product IDs with a shared name and description, like u would want it for things like clothes.
That way u can create one productname called "T-shirt (100% cotton)" with a description like "Good shirt, nice to wear...bla bla bla".
Next u add attributes to the product, and choose one value for each attribute.
That way u can have as many attributes related to one product as u want, but the final result will be, that u have a fixed set of attributes for this single product ID and hence stock and price can be set and maintained.
Practically if we were to create a shirt in 2 colors and 2 sizes, we'd start by creating the name and description, then we add the attribute "Color" and "Size", then we set their values as "Red" and "Medium", then we set stock and price values and press "Save".
Screen remains, but product ID is incremented by one and the two attributes are duplicated and we alter the value for "Color" from "Red" to "White" and leave the Size attribute as it is, because we ofc want to have both colors in both sizes.
Now we do the same for the color attribute and the idea is, that while the GUI gives the user the impression that hes actually adding attributes to the same product, the system is basically creating unique IDs for each combo of attributes.
So what we end up with, would be 4 product IDs linked to the same name and description, so that u dont need to redo all four of them in case u want to change it along the way.
Im thinking GUI wise that itll work kinda the same way as in NBS when u add models, that it adds another row for each attribute assigned to the product.
I did a rough sketch of the structure for the tables involved, i kept it at a minimum though, as its just for illustrating. :-)
The idea is to make an attribute structure that can be build to suit different products, like u might wanna have a collectioon of sizes for shirts and hence create a product attribute like this:
aName = ShirtSize (Where this name will be for internal reference when working in the backoffice)
aDisplayName = Size (The attribute name as itll be shown in the store)
Next u might wanna have a size collection for firecrackers which may be measured in inches, so for those u'd just make the aName something like FirecrackerSize, but for the displayname "Size" would be what u want.
_
Image may be NSFW.
Clik here to view.
_The pDeduct is for a purpose outside the scope of the attribute handling, but i was thinking it could be used (in a very simply way) to handle lot sales, so if u sell let's say cigarette lighters and they come in boxes with 12 pcs, then create one lighter product where pDeduct is set at 1 for selling single pcs, then copy the product and set the pDeduct at 12 and use the pSummary to inform that this is a box of twelve pcs.......something like that. ;-)
_
Cheers. :-P
_Considering Tirams issue with the clothes, I thought of separating the product name and description from the product itself, so that name and description can be related to one or more product IDs.
So it goes for the attributes which can be related to one or more product IDs as well.
That way u can have several product IDs with a shared name and description, like u would want it for things like clothes.
That way u can create one productname called "T-shirt (100% cotton)" with a description like "Good shirt, nice to wear...bla bla bla".
Next u add attributes to the product, and choose one value for each attribute.
That way u can have as many attributes related to one product as u want, but the final result will be, that u have a fixed set of attributes for this single product ID and hence stock and price can be set and maintained.
Practically if we were to create a shirt in 2 colors and 2 sizes, we'd start by creating the name and description, then we add the attribute "Color" and "Size", then we set their values as "Red" and "Medium", then we set stock and price values and press "Save".
Screen remains, but product ID is incremented by one and the two attributes are duplicated and we alter the value for "Color" from "Red" to "White" and leave the Size attribute as it is, because we ofc want to have both colors in both sizes.
Now we do the same for the color attribute and the idea is, that while the GUI gives the user the impression that hes actually adding attributes to the same product, the system is basically creating unique IDs for each combo of attributes.
So what we end up with, would be 4 product IDs linked to the same name and description, so that u dont need to redo all four of them in case u want to change it along the way.
Im thinking GUI wise that itll work kinda the same way as in NBS when u add models, that it adds another row for each attribute assigned to the product.
I did a rough sketch of the structure for the tables involved, i kept it at a minimum though, as its just for illustrating. :-)
The idea is to make an attribute structure that can be build to suit different products, like u might wanna have a collectioon of sizes for shirts and hence create a product attribute like this:
aName = ShirtSize (Where this name will be for internal reference when working in the backoffice)
aDisplayName = Size (The attribute name as itll be shown in the store)
Next u might wanna have a size collection for firecrackers which may be measured in inches, so for those u'd just make the aName something like FirecrackerSize, but for the displayname "Size" would be what u want.
_
Image may be NSFW.
Clik here to view.
_The pDeduct is for a purpose outside the scope of the attribute handling, but i was thinking it could be used (in a very simply way) to handle lot sales, so if u sell let's say cigarette lighters and they come in boxes with 12 pcs, then create one lighter product where pDeduct is set at 1 for selling single pcs, then copy the product and set the pDeduct at 12 and use the pSummary to inform that this is a box of twelve pcs.......something like that. ;-)
_
Cheers. :-P
