Options Attributes - discussion

[Omar_one]

Based on my understanding, in a parent/child product system, child products serve as variant attributes (e.g., size, color),
if so the inventory quantities should be managed at the child product level, not the parent level. The parent product listing should only reflect this when child products are in stock. Ideally, this system integrates easily with existing shops.

I believe the parent/child structure would enable easier POS integration than traditional options/attributes systems

[burt]

Did anyone yet look into doing something to make this a reality ?
Does anyone have any comments, feedback or advice, ideas etc

[azpro]

if so the inventory quantities should be managed at the child product level, not the parent level.

I agree - and @burt - also awaiting input / feedback / comments ..

[burt]

if so the inventory quantities should be managed at the child product level, not the parent level.

I agree - and @burt - also awaiting input / feedback / comments ..

1. Put a button in the right hand column "Add Child"
1a. When clicked it pops up a modal with a form
Make the form have at the very least "Name, Price, Model/SKU, Qty" & Hidden parent product_id

Why else would Add Child form have input of Qty?

[azpro]

Why else would Add Child form have input of Qty?

Well - For me in this stage the exact way of coding (and thus way of work-flow in admin) is not really important. Can always be altered IMHO for different shopowner needs (eg - added in a tab).

But I do think it is important to get this moving.

[LeeFoster]

You'd also want to consider how to approach child product "options".

For example, t-shirts. If the parent is mens v-neck t-shirt, the child is the colour, how is size handled? Is size the child of the child meaning you have a lot of products or does size then become an option? Though that means you can't track the size "option" the same way.

[burt]

You'd also want to consider how to approach child product "options".

For example, t-shirts. If the parent is mens v-neck t-shirt, the child is the colour, how is size handled? Is size the child of the child meaning you have a lot of products or does size then become an option? Though that means you can't track the size "option" the same way.

Parent: Mens T, V Neck.
- SKU might be T-VN (or whatever the admin sets)

Child: Blue, Small, 3 in stock
- SKU might be T-VN-BS (or whatever)

Child: Red, Small, 1 in stock
- SKU might be T-VN-RS (or whatever)

Child: Red, Medium, 99 in stock
- SKU might be T-VN-RM (or whatever)

Child: Red, Large, 10 in stock
- SKU might be T-VN-RL (or whatever)

Child: Red XXL, Out of Stock
- SKU might be T-VN-RXXL (or whatever)

IE, child is not "one attribute", it is "all attributes". In this case; Colour | Size | SKU.
V-Neck could also be part of the Child instead of part of the Parent.

All depending on what the shopowner wants to suit their own product range.

[azpro]

Hi everyone!

Just wondering - is there really No interest in pushing Phoenix to have a nice grouped_products solution? At least an overhaul of Options - attributes code base.

By not reacting (no interest is also an answer) and interacting on the froum it seems to me we are loosing momentum.

I can easily understand @burt Gary thinking "what / why am I doing this if no one contributes / ineracts / posting?

Agree?

[ecartz]

Parent: Mens T, V Neck.
- SKU might be T-VN (or whatever the admin sets)

Child: Blue, Small, 3 in stock
- SKU might be T-VN-BS (or whatever)

I would strongly advise against encoding attributes in the SKU the way that osC3 did.

1. SKU is not a good place to treat as if it were entirely store owner set. Sometimes it will make more sense to use whatever the manufacturer set.
2. It makes it so that you are doing queries against the SKU, which is a string. And worse, sometimes you want to do partial queries.
3. It makes it so that not even the store owner can determine the format, as the system forces a particular format, which will break at seemingly random times.
4. If you add a new option, you have to redo all your SKUs.

Display the different options in the product name, sure. But for the database, have a single parent product and a set of child products. Then use something like product specifications to associate those with the actual options.

In that case, Parent might be T, V-Neck, White, Large (something needs to be the default) and the children would be other values. Adding a new option is as simple as adding a product specification. Want to show shirts that are available in Large and V-Neck? That's a filter a hook could add to product_searcher.

Now if the store owner wants to set the SKU as T-VN-BS (or whatever), that's fine. So long as the system doesn't force that or rely on it.

[14Steve14]

Sorry, I’ve only just seen this post as I’m not on here as much as I used to be. Here’s my take on the current options/attributes system and where it could be improved. This may get a bit long but may be insightful as to how people use this current system.

We mainly use attributes for downloads, and we have hundreds of them. Setting them up is a bit of a pain at first – long-winded and not intuitive – but once you’ve done a few it’s manageable. I had to show someone recently how to attach a download to a product, and their first reaction was “WTF, that’s not easy”. After a couple of products, though, they got the hang of it so it cannot be that hard.

One improvement would be to integrate attribute assignment directly into the product editing page. The actual creation of options and attributes could stay in one central admin area, but once they’re defined they could be linked into products through a hook or similar. That way, you wouldn’t have to choose from the long product dropdown every time – the product you’re editing would already be preselected. The download file for each product could then be added to each product similar to the way an image is selected. If a product needed more that one download file make it a simple way of adding them, again similar to the way additional images are added. They would then be saved in the products table ready for selection. That would lead to a way of saving the files in different named folders within the download folder, which would make finding them and updating them easier.

The challenge comes with products like T-shirts or shoes that require many attributes and options. To handle those more efficiently, it might help to allow grouping of options so they can be applied more quickly.

Stock control is another issue: ideally, the stock input field in the current product creation page could expand to match the number of options selected. How that would interact with the existing stock system is something I can’t say, but it feels like the logical place to manage it, by keeping everything in one place

Separately, I had Gary create a simple master/slave (bundled product) system some time ago. You could build a new product made up of existing items in the inventory. If the bundle sold, stock for the individual products was reduced automatically. If one of the items went out of stock, the bundle also showed as out of stock. It was straightforward and worked well, though it was never updated to later versions as there wasn’t much interest. With wider input, I think that kind of system could be improved a lot.

As I say, we only use attributes for downloads and nothing else. For products with multiple main attributes and large sets of options, I can’t really comment on how well the current system works.

Finally, I’d be cautious about removing this from core. Attributes are a fundamental part of any ecommerce system. If they were left entirely to a third-party developer, there’s a real risk of the feature being abandoned, locked behind someone’s personal roadmap, or priced out of reach, but there would be nothing wrong with a developer creating an improved system if they thought something could be improved. t the end of the day it could all be hooked together.